What does “good” app management look like?
Hello, business app admin.
Don’t worry, we know that’s not your actual name. But if you’re an admin for any tech at your company and don’t sit directly in the IT org chart, you’re effectively a business app owner.
Congratulations!
Perhaps you’re in this situation because you take ownership at work to a whole new level and you want the keys to the kingdom. Go you!
Maybe the app requires you to have administrative permissions to do your job and that power scares you a bit. Ok, maybe a lot. Let’s move away from the spiral of despair and channel that anxiety in a healthy direction.
In this blog, we’re going to do a tour of what “good” app management looks like to make sure you don’t mistakenly screw up the tools that are critical for your team to accomplish their business goals. These best practices and processes have likely already been adopted by your IT team in some form; use this as an opportunity to explore how your organization is already doing this so you don’t have to start from scratch.
1 - Align to business value
In the words of Simon Sinek, start with why. Why did the business decide to spend money on this particular app? What business outcomes were expected on the back of this purchase?
There was a promise in the beginning. There is an expectation of delivery now.
As the admin and business app owner, you ought to know this because it drives how the app is used in day-to-day operations. This will also shape how you communicate the ROI of change because new tools either get integrated into new processes or risk becoming shelfware.
2 - Determine the data sensitivity classification
Every app stores or uses some sort of data. How private should this data be? Unless you’re a fledgling startup, your IT or security team has outlined this in some capacity, so check your company’s data classification policy for details catered to your organization. They’ve done the discovery across a broad set of company assets, so don’t try to reinvent the wheel here.
Generally speaking, there are four classifications of data sensitivity:
- Restricted - This kind of data could cause financial or legal harm to the company and individuals if leaked. Examples: health records, credit card information, company intellectual property, and company financial information.
- Confidential - This is sensitive data that could negatively affect operations if compromised. Examples: license keys, contracts with vendors, and employee reviews.
- Internal - This data could give your competitors an edge or damage your company's reputation. Examples: org charts, sales playbooks, and architecture diagrams.
- Public - This is data that everyone can see, whether they are internal employees, external agencies, customers, media, etc. There are no restrictions on who can see this data.
The data sensitivity level usually drives how stringent the next few best practices are conducted. The more protected the data should be, the more process and paper trail there needs to be when giving or removing access to the app.
3 - Standardize roles and permissions
When someone asks for access to an app you manage, what’s the next logical question?
How much permission do you give them?
Do they need the ability to read, write, and delete? Do they need to be able to add other users to the system? Or do they simply need to view a subsection of the data? Not everyone needs admin access or god mode. It is perfectly ok as the app owner and admin to clarify what the person needs to do their job and assign them the appropriate permissions.
The concept of roles simply standardizes the set of permissions someone gets so you don’t have to personally check all the boxes for features that a single person needs. It also provides admins, like yourself, a way to put into practice a security concept called the “principle of least privilege.” Basically, you narrow someone’s access to the specific data and resources they need to do their job.
For example, perhaps you have a group of business analysts that only need to explore data to create reports and dashboards. These folks don’t need the permission to update or delete data. You can create a role for these business analysts with a set of permissions that allows them to create and update reports and dashboards to their hearts’ delight. Then for every new business analyst that joins the team, they can be assigned that role.
The principle of least privilege is a common form of defense against threat actors who might use credentials found on the dark web to log in as you or your teammate to gain access to the data and resources in the app. (Sidenote: this is also why you shouldn’t reuse passwords).
If a user is set up with keys to the kingdom, as you do as an admin, threat actors are more likely to target this type of user than the business analyst if they want to wreak havoc on your data. The more users with the keys to the kingdom, the more entry points and opportunities there are for threat actors to do harm to the business.
The bottom line for this best practice - group your end users into roles that provide only the “must have” level of permissions they need to do their work.
4 - Form user access request and review workflows
If you work at a company that handles sensitive data like credit card information, customer data, or health records, your IT, security, and compliance teams have processes in place for requesting and reviewing access to work apps. Due to regulatory requirements from PCI DSS, Sarbanes-Oxley, HIPAA, and GDPR, auditors look for evidence showcasing sufficient practice of protecting this sensitive information.
We highly recommend exploring what processes already exist instead of completely reinventing the wheel. This is an opportunity to be a liaison between your team and IT to develop workflows that meet the needs of your team and the center of excellence in IT and security. Some discovery questions might include:
- What does the access request and fulfillment process look like today for IT?
- What information does IT and security require before providing access? Why is this information important?
- How many access requests does IT get on a weekly/monthly basis from my team?
- How frequently do we need to review and certify who has access? Is there a process IT follows for this already?
5 - Connect user lifecycle management to an HR source of truth
Managing the ebb and flow of users in and out of your app is highly disruptive, manual, and stressful. Using an HR source of truth to drive user creation, removal, and updates in your app will probably be the largest time savings you can do as an app owner and admin.
Enterprises large and small may have implemented an identity provider (IDP) like Okta, Microsoft Entra ID, or Ping. Explore if the app you admin can integrate with any of these systems since your identity, IT, or security team probably already integrated the IDP with your HR system of record.
By connecting the user lifecycle management of your app with your HR system of record through your IDP, all that is left to manage manually is third-party access to your app, whether it be consultants, contractors, or agencies.
If your app cannot integrate with a modern IDP, consider using Cerby to automate user lifecycle management for you. Cerby integrates with the IDP and uses this source of truth to automate the onboarding and offboarding of employees in your app. As people join, move teams, or leave, your IDP gets updated, automatically trickling into Cerby and triggering the end user's appropriate lifecycle action.
Interested in seeing how much manual work Cerby can automate for you? Book a demo with our team.
