Authorization in GRC: IAM Series Part 3

So far, the IAM series has focused on authentication, which is the act of verifying someone is who they say they are. But once they are verified and have been granted access to a system, they shouldn’t be allowed to perform every action. For instance, an employee in an organization should not be allowed to modify salary data if their job does not require them to do that.

This is where authorization comes into play. Authorization determines what a user can do after they’ve been authenticated. To put it simply, authentication is using an ID to unlock a building, while authorization determines what rooms can be entered. In this post, we’ll examine authorization from a governance, risk, and compliance (GRC) perspective.

Managing Authorization

Authorization can be implemented in several ways:

Access Control Lists (ACLs): This is a list that explicitly defines who is allowed access to a certain resource or application. While simple to understand, this becomes more difficult to manage when there are more entities.
Role-based access control (RBAC): This is where users are assigned roles and the roles determine what action the user can perform. Compared to Access Control Lists, this is much easier for medium- to large-sized organizations to manage, and it works well when job functions are well-defined and rarely change. It can become difficult to manage if too many roles are created, and in this case, organizations should review roles periodically by merging or removing redundant ones as well as ensuring each role maps directly to a business function.
Attribute-based access control (ABAC): This is where access decisions are based on attributes, such as department and location. This makes this method of control highly flexible. For example, access could only be allowed if the user is part of the Finance department and is using a corporate-owned device.
Policy-based access control (PBAC): This is where rules determine access. It allows for decisions to be made based on context and is considered a policy‑driven implementation of ABAC. For example, access could be granted only during business hours and only in approved geographical locations.

Each of these methods has its use cases as described above. If a GRC professional is working for or auditing an organization that does not have an access control system in place, they should recommend the company use RBAC as it is simple to understand and is not too difficult to manage, unless the organization has highly dynamic access needs, in which case they may benefit more from ABAC or PBAC due to their flexibility.

If the organization uses ABAC or PBAC, GRC professionals should also watch for what is known as policy drift, where policies accumulate over time and are either inconsistent, contradictory, or overly restrictive. There should not be too many policies and the policies should clearly align with business functions and not contain fluff. Organizations should periodically review and either change or remove outdated or redundant policies.

GRC professionals should also make sure that organizations document who is responsible for defining access policies, approving access requests, and maintaining role definitions. This ensures authorization decisions are consistent and auditable. Access approvals should come from business owners and not from IT administrators. This is because business owners should also be accountable for the risks associated with granting access to their systems and data.

Many compliance frameworks like ISO 27001 (A.9), NIST CSF (PR.AC), SOX, and PCI DSS require organizations to implement structured access control processes, which GRC professionals should assess to ensure the organization is compliant.

Authorization Principles

Access controls should never be assigned arbitrarily. Below are some principles that should be taken into consideration when deciding access controls.

Least privilege. This is where people are only given the least amount of access necessary to perform their job function. For example, credit card information should only be able to be accessed by people who need it to perform their job and only when they are performing their job.
Separation of duties. No individual should have enough access to perform sensitive actions without oversight. For example, let’s say an employee handles some of the organization’s intellectual property. One way to implement separation of duties is to ensure they can only view and not edit this information from their main account, and where edit access is approved by two admins who will revoke the access once they no longer need it.
Zero Trust Model. This is a modern security model where no user or device is inherently trusted: they must continuously verify their identity and context. Here, authorization takes into account context like the user identity, location, device health, resource sensitivity, and real-time risk signals.

If access controls are weak, the impact resulting from a compromised account or insider threat increases significantly. GRC professionals should always keep the CIA Triad (confidentiality, integrity, availability) in mind and evaluate how the organization’s current access controls can affect them.

This also requires strong logging and monitoring so that access changes and privileged actions are visible and can be investigated and audited.

Authorization failures impact confidentiality and integrity, so during risk assessments, they typically receive high risk scores and should be prioritized for remediation.

Privileged Identity Management

Privileged Identity Management (PIM) is the process of managing accounts that are highly privileged, such as admin accounts. These are important from a security perspective because they pose the highest risk if compromised. The first question GRC professionals should ask when it comes to PIM is the number of admin accounts. If there are more admin accounts than necessary, then that is a red flag, as then all an attacker needs to do is to gain access to one of those accounts and they’re in the system.

Some tips to follow when it comes to privileged identity management include:

Have the least number of admin accounts possible. Some organizations do not have any admin accounts enabled and instead admin privileges are accessed through just‑in‑time elevation using tools like CyberArk or Microsoft Entra PIM.
Have MFA on these accounts.
Passwords on these accounts need to be significantly complex.

For some organizations, a tool like CyberArk can be used. CyberArk is a privileged access management tool that stores and controls access to privileged admin credentials. However, GRC professionals should make sure it is configured properly and everyone is using the tool as intended. For instance, there could still be an unmanaged admin account some employees use because it’s easier to use it to access admin rights. This would make the tool useless because an attacker would only need to get into that unmanaged account.

If PIM is not managed well, the risk is extremely severe, as privileged accounts can bypass most security controls.

Access Reviews

Like most other aspects of GRC, authorization is not something that is done once. It must be constantly monitored, logged, and changed as necessary. For example, if an employee is working with financial data, their access should be revoked once they change to working in HR or leave the organization. This usually comes in the form of access reviews.

GRC professionals usually follow what is known as the Authorization Lifecycle, which has five steps: Provisioning, Access changes, Periodic reviews, Deprovisioning, and Recertification. These steps ensure access remains appropriate over time. For example, provisioning and deprovisioning ensure access is granted and removed correctly, while periodic reviews and recertification validate that existing access is still justified. Auditors typically review access logs, approval workflows, role definitions, and evidence of periodic access reviews to confirm that authorization controls are functioning as intended, so GRC professionals should ensure that evidence of access reviews is retained for an appropriate period based on regulatory and policy requirements for auditing purposes.

Conclusion

Strong authorization controls ensure that even if an account is compromised, the attacker will not be able to do much damage. In the next post, we’ll explore authorization in Microsoft Entra ID, such as roles, permissions, and privileged access workflows.