Managing Access in an Organization

Managing Access Rights in an Organization

Employees may need company email, a CRM, code repositories, and cloud storage to do their work. Access is often granted one request at a time. Over time, people accumulate permissions they no longer use, while former project contributors may still have active accounts.

If an account is compromised or someone accidentally changes important data, excessive permissions can increase the damage. Access needs to be managed throughout a person’s time in each system.

Start by defining what people need to do

Access involves two different questions. Authentication confirms who has signed in. Authorization determines which actions that person is allowed to perform.

For example, an employee may need to view customer records, while only a specific group can edit financial data. These boundaries should be defined before configuring individual systems.

Group permissions into roles

When permissions are assigned separately to every employee, it becomes harder to understand who has access and why. A role-based model makes administration clearer. Permissions are grouped around work responsibilities, and employees receive the roles they need.

For example, an editor may create and update content, while an editorial lead can also publish it. In RBAC, permissions are assigned to roles and users receive access through those roles. NIST describes RBAC as managing access through roles and their associated privileges.

Grant the minimum and require a reason for more

My approach is to give each employee only the permissions required for their current work. If someone needs access beyond that baseline, the request should explain which task requires it, which data or systems it covers, and how long the access is needed.

“It might come in handy” is not a sufficient reason. Elevated access should be approved by the system owner or task lead and limited to the resources required. Once the work is complete, the additional access should be removed.

In a web application, every protected action needs to be checked on the server. Hiding a button in the interface does not restrict access on its own. When a rule for a new action has not been defined, the safer default is to deny access. These practices are recommended in the OWASP Authorization Cheat Sheet.

Revoke access as soon as the work is over

When an employee finishes a project and will no longer contribute to it, revoke their access to that project’s systems right away. There is no reason to wait for the next scheduled access review. This applies to repositories, cloud environments, documents, and other project resources.

When someone moves to another team, review their old permissions against their new responsibilities. When an employee leaves the organization, disable their account and access to company systems immediately. This fits the account lifecycle management described in NIST SP 800-53, control AC-2.

Keep everyday work separate from administration

Employees do not need administrator rights for routine tasks. Elevated privileges should be used only for work that requires them. Enable multifactor authentication for administrative and remote access accounts. CISA also recommends separating standard and privileged accounts and regularly checking whether assigned permissions are still needed. CISA guidance for organizations.

Each employee should have an individual account. Shared logins make it difficult to determine who performed an action and complicate incident reviews.

Separate responsibility for sensitive actions

Some operations need an additional check. For example, it is risky when one account can prepare and approve the same payment.

Splitting these actions between employees helps reduce mistakes and misuse. For each sensitive process, define who performs the action and who approves it.

Assign clear ownership for access

For every system, define who approves access, who assigns roles, and who reviews whether they are still appropriate. A useful starting point is an inventory of systems, roles, and access owners.

Then check who has administrator privileges, whether former project contributors still have active accounts, and what happens to access when someone changes responsibilities or leaves.

Access should match a person’s current work. When the work ends, the permissions granted for it should end as well.