Skip to main content
Identity Authority
Category: Authorization Concepts

Access Policy

Also known as: Access Control Policy
Simply put

An access policy is a set of rules that defines which users can access specific resources, under what conditions, and what actions they may perform. It is the mechanism organizations use to ensure that only authorized people reach the systems and data they are permitted to use, reducing the risk of improper access.

Formal definition

An access policy is a declarative set of rules that governs authorization decisions, determining which principals (users, groups, roles, or services) may perform which actions on which resources, and under what conditions. In attribute-based approaches, access rights are granted by combining attributes together through policy, as described in NIST's access control policy guidance; access policies may also be expressed within other models such as RBAC or PBAC depending on deployment. Policies are typically evaluated at runtime by an authorization engine and, in some platforms (for example AWS IAM), are authored as artifacts attached to identities or resources. Access policies address authorization only and are distinct from authentication, which verifies who the principal is; the specific structure, syntax, and evaluation semantics vary by vendor and deployment context.

Why it matters

Access policies are the operational expression of the principle that only authorized principals should reach the systems and data they are permitted to use. Without a clearly defined and enforced set of rules governing which users can access which resources, under what conditions, and what actions they may perform, organizations lose the ability to constrain improper access. As the University of North Carolina's access control guidance frames it, access controls protect information by only allowing authorized people to access systems, thereby minimizing organizational risk.

Because access policies address authorization rather than authentication, they determine what a verified principal may do, not who that principal is. This distinction matters in practice: a strong authentication posture does not by itself prevent over-privileged access, and conversely, well-scoped policies limit the blast radius when credentials are compromised. Policies that combine attributes, roles, or other conditions allow organizations to express least-privilege intent in a form that can be evaluated consistently rather than relying on ad hoc, manually managed permissions.

The practical stakes rise as access policies scale across many identities and resources. In platforms such as AWS IAM, policies are authored as discrete artifacts attached to identities or resources, which means policy sprawl, overly broad grants, and inconsistent conditions become governance concerns in their own right. Poorly scoped or unreviewed policies can silently accumulate excess privilege, making disciplined authoring, review, and enforcement essential to keeping authorization aligned with what each principal actually needs.

Who it's relevant to

Security Architects
Architects decide which access control model, such as RBAC, ABAC, or PBAC, best expresses an organization's authorization intent, and how policies are structured, attached to identities or resources, and evaluated at runtime. They must ensure policies enforce least privilege while remaining maintainable as the number of principals and resources grows.
IAM Engineers
Engineers author, test, and operate access policies as concrete artifacts, for example in platforms like AWS IAM where policies are attached to users, groups, roles, or resources. They are responsible for translating intended access rules into the correct vendor-specific syntax and evaluation semantics, which vary by platform.
Identity Governance Leads
Governance leads oversee whether existing access policies still reflect what principals are actually permitted to do, guarding against policy sprawl and accumulated excess privilege. Their concern is keeping the granted authorization aligned with organizational intent over the identity lifecycle, distinct from the runtime enforcement of those policies.
Compliance Officers
Compliance officers rely on documented access policies to demonstrate that only authorized people can reach systems and data, minimizing organizational risk as reflected in institutional access control policies. They assess whether policy definitions and their enforcement support the controls required by applicable obligations.
System Administrators
Administrators apply and maintain access policies day to day, attaching them to the appropriate identities and resources and adjusting conditions as needs change. They operate within the structure defined by the chosen platform and model rather than redefining the underlying authorization approach.

Inside Access Policy

Subject conditions
Criteria describing the principal to which the policy applies, such as user attributes, group or role membership, or relationship to a resource. Depending on the access control model in use (RBAC, ABAC, PBAC, or ReBAC), these conditions are expressed as roles, attributes, or relationships.
Resource or object scope
The set of protected resources, actions, or operations the policy governs. This defines what may be acted upon and typically constrains the policy's effect to specific systems, endpoints, or data classes.
Effect (permit or deny)
The authorization decision the policy yields when its conditions are satisfied. Access policies address authorization (what a principal may do), which is distinct from authentication (verifying who the principal is).
Environmental and contextual constraints
Runtime conditions such as time of day, device posture, network location, or risk signals that may qualify a decision. Their availability and meaning vary by deployment and by the policy language or engine used.
Evaluation and enforcement components
At runtime, policies are typically evaluated by a policy decision point (PDP), enforced by a policy enforcement point (PEP), and supplied with attribute data by a policy information point (PIP). These enforcement concerns are separate from IGA lifecycle activities such as provisioning and access certification.
Combining or conflict-resolution logic
Rules that determine the outcome when multiple policies apply to the same request, for example deny-overrides or first-applicable ordering. The specific algorithms available depend on the policy framework and engine configuration.

Common questions

Answers to the questions practitioners most commonly ask about Access Policy.

Is an access policy the same thing as a role?
No. A role is a construct in RBAC that groups permissions and is assigned to principals, whereas an access policy is a broader expression of the conditions under which access is granted or denied. Roles can be one input to a policy, but a policy may also evaluate attributes (ABAC), relationships (ReBAC), or other contextual signals depending on the model in use. Treating a policy as merely a role tends to obscure the fact that policy evaluation can incorporate factors well beyond role membership.
Does defining an access policy handle authentication too?
No. Authentication verifies who a principal is, while an access policy governs authorization, what an authenticated principal may do. These are separate steps in an access flow: identification and authentication typically occur first, and the access policy is evaluated afterward to reach an authorization decision. A policy generally assumes an already-authenticated identity and does not itself establish that identity, though it may reference authentication context (such as assurance level) as an input.
Where in a runtime architecture is an access policy actually evaluated?
In most deployments the policy is evaluated at a Policy Decision Point (PDP), which returns a permit or deny decision. The Policy Enforcement Point (PEP) intercepts the request and enforces the PDP's decision, and a Policy Information Point (PIP) supplies additional attributes the PDP needs to evaluate the policy. The exact division of these responsibilities varies by product and profile, and some implementations co-locate PDP and PEP functionality.
How do I keep access policies consistent across multiple applications?
A common approach is to externalize authorization so that policies are defined and managed centrally rather than embedded in each application's code. Depending on configuration, this lets multiple PEPs consult a shared or replicated PDP so the same policy logic is applied uniformly. Consistency also depends on standardizing the attributes and identifiers the policies rely on, which is why directory and provisioning hygiene (for example via LDAP and SCIM) affects policy outcomes even though those are separate concerns.
Which access control model should my policies use?
No single model is universally superior; the choice depends on requirements. RBAC works well when access maps cleanly to job functions and coarse-grained roles suffice. ABAC and PBAC support fine-grained, context-dependent decisions using attributes and centrally managed policies. ReBAC is well suited where access depends on relationships between entities, such as ownership or group membership graphs. Many deployments combine models, and the appropriate mix depends on the granularity, auditability, and manageability you need.
How should access policies relate to periodic access reviews and certifications?
Access policies are primarily a runtime authorization concern, while access reviews and certifications are identity governance and administration (IGA) activities that periodically validate whether granted access remains appropriate. The two should be kept distinct but coordinated: policies determine what is enforced in real time, whereas reviews assess and remediate accumulated entitlements over time. In practice, clear and well-structured policies make governance activities such as certification and segregation-of-duties analysis easier to reason about, but they do not replace those lifecycle processes.

Common misconceptions

An access policy authenticates the user before granting access.
An access policy governs authorization, which determines what an already-identified and authenticated principal may do. Verifying identity is a separate, prior step handled by authentication mechanisms, not by the access policy itself.
Access policies belong to a single access control model, and one model is inherently superior.
Access policies can be expressed in RBAC, ABAC, PBAC, ReBAC, or MAC/DAC terms, and many deployments combine models. The appropriate model depends on requirements and context; none is universally best.
Defining an access policy is the same as managing the access lifecycle.
Authoring and enforcing a policy at runtime (via PDP, PEP, and PIP) is distinct from identity governance concerns such as provisioning, access reviews, certification, and segregation-of-duties enforcement. These lifecycle activities complement but do not replace runtime policy evaluation.

Best practices

Keep authorization policies separate from authentication configuration, and design each so that identification, authentication, and authorization remain distinct, verifiable steps in the access flow.
Choose the access control model (RBAC, ABAC, PBAC, ReBAC, or MAC/DAC) that fits your requirements and context rather than defaulting to one, and document which model each policy relies on.
Define explicit conflict-resolution or combining logic (such as deny-overrides) so that overlapping policies produce predictable decisions, and validate the behavior against your chosen policy engine's supported algorithms.
Centralize evaluation in a PDP with well-defined PEPs and reliable PIP attribute sources, and treat these runtime enforcement components separately from IGA provisioning and certification workflows.
Test policies against representative subject, resource, and contextual conditions before deployment, and account for how behavior may vary by vendor, profile, and deployment configuration.
Pair runtime policy enforcement with periodic access reviews and segregation-of-duties checks so that granted access remains appropriate over time, recognizing that policy authoring alone does not manage the access lifecycle.
Promotional banner for the Pentest Readiness checklist download