Access policies define the control layer IAM teams need to govern access

At a glance

What this is: An access policy is a rule set that governs who can access resources, under what conditions, and what they can do once access is granted.

Why it matters: IAM teams need this because access policies sit at the point where human access, service access, and lifecycle controls either stay consistent or drift into exceptions.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Josys's article on access policy and identity governance

Context

Access policy is the governance layer that turns identity decisions into repeatable rules. In practice, it defines who can reach a resource, what conditions must be met, and what actions are allowed after access is granted. For IAM programmes, the key problem is not whether policies exist, but whether they are precise enough to govern human users, service accounts, and other non-human identities without relying on ad hoc exceptions.

Josys frames access policy as a way to centralise control across authentication, authorisation, monitoring, and lifecycle events such as onboarding and offboarding. That is the right problem space, because policy drift usually starts when access decisions are made in disconnected tools and then copied into exceptions. The governance challenge is to keep policy logic consistent as applications, devices, and identities multiply.

Key questions

Q: How should security teams implement access policies across cloud and SaaS apps?

A: Start with a shared policy model that defines who can request access, which conditions must be satisfied, and which approvals are required. Then map the same logic into cloud and SaaS systems so entitlement decisions stay consistent. The goal is not perfect uniformity, but governed consistency with clear exception handling and review.

Q: Why do access policies fail when organisations have many exceptions?

A: Policies fail when exceptions become the operating model instead of the edge case. Every override weakens least privilege, adds review burden, and makes enforcement inconsistent across apps. Once exceptions are unmanaged, policy becomes documentation rather than control, and security teams lose the ability to predict what access really exists.

Q: What signals show that an access policy is no longer working?

A: Look for broad role assignments, repeated manual approvals, stale entitlements, and access that no longer matches job function or business need. In non-human identity environments, the same warning signs include service accounts with unnecessary scope and secrets that remain valid long after they should have been revoked.

Q: How do access policies support identity lifecycle governance?

A: They create a direct link between lifecycle events and access decisions. When someone joins, changes role, or leaves, the policy should update or revoke access without waiting for a separate manual cleanup step. That same discipline applies to service accounts and workload identities that also need timely offboarding.

Technical breakdown

How access policy combines authentication and authorisation

An access policy is not just a list of permissions. It is the decision logic that connects identity verification to authorisation rules, then applies contextual conditions such as device posture, location, time, or behavioural signals. Authentication proves the requester is who they claim to be. Authorisation determines what that requester can do. Policy becomes the layer that binds those two steps into repeatable enforcement rather than manual judgement. In mature environments, policy logic is centralised and evaluated automatically across systems so that the same request receives the same answer, regardless of application or administrator.

Practical implication: map policy decisions to a single source of truth so different apps do not invent different access rules for the same identity.

Least privilege and conditional access in policy design

Least privilege means access should be scoped to the minimum required for the job. Conditional access adds context so that permission is not treated as absolute. In practice, this is how organisations avoid granting broad standing access just because a user or workload once needed it. The strongest policies combine role, attribute, and environmental conditions, then enforce them consistently. Where this fails, teams often end up with static entitlements that outlive the task, the project, or the identity itself, which is exactly where privilege creep starts.

Practical implication: review policies for standing access that should be time-bound or condition-bound instead of permanently assigned.

Monitoring, enforcement, and policy drift

Access policy only works if it is enforced and monitored after the initial grant. Logging shows what was requested and what was allowed. Enforcement blocks violations in real time. Monitoring reveals when rules are being bypassed, when access patterns no longer match the original intent, and when policies need recalibration. The governance weakness is not usually the absence of a rule. It is the accumulation of exceptions, shadow approvals, and misaligned templates that slowly turn policy into documentation rather than control. That is why policy review has to be tied to actual usage, not just periodic certification.

Practical implication: tie policy review to usage evidence so exceptions and stale entitlements do not silently become the new normal.

NHI Mgmt Group analysis

Access policy is the control plane where identity governance becomes enforceable. Without a policy layer, authentication and authorisation remain isolated events instead of repeatable security decisions. That matters because access in modern enterprises spans humans, service accounts, and workflow identities, all of which need consistent decision logic. The practitioner conclusion is straightforward: if policy is fragmented, governance is fragmented too.

Least privilege fails when organisations treat access as a permanent state rather than a conditional one. Access policies are meant to narrow scope, but static role assignments, broad exceptions, and unmanaged overrides steadily widen it again. This is where IAM and NHI governance intersect, because the same drift that inflates human entitlements also leaves machine identities overexposed. The practitioner conclusion is to treat policy as a living boundary, not a one-time configuration.

Conditional access only has value when context is part of the enforcement model, not an afterthought. Device posture, location, time, and behaviour matter because they reduce blind trust in the request itself. Yet many organisations still enforce policy only at onboarding and then stop watching for drift. That creates a false sense of control. The practitioner conclusion is to align conditional rules with actual runtime conditions, especially where access decisions span multiple tools.

Policy sprawl is a governance problem, not a tooling problem. A central dashboard helps only if the underlying policy model stays coherent across applications and lifecycle events. When onboarding, role changes, and offboarding are handled in separate workflows, policy becomes inconsistent even when the interface looks tidy. The practitioner conclusion is to govern the lifecycle of policy rules with the same discipline used for identities themselves.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The governance path forward is covered in NHI Lifecycle Management Guide, which connects policy decisions to provisioning, rotation, and offboarding.

What this signals

Policy governance now has to cover non-human access as tightly as human access. When service accounts are invisible, policy quality collapses because entitlement review no longer reflects reality. The practical signal is to treat policy centralisation and visibility as the same control problem, especially where application sprawl creates hidden access paths.

Access policy is becoming the glue between IAM, NHI governance, and lifecycle management. The stronger the policy model, the easier it is to connect onboarding, role change, and offboarding to real access outcomes. That is why programmes should align policy design with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and with the NIST Cybersecurity Framework 2.0 functions for govern, protect, detect, and respond.

For practitioners

• Centralise policy decision logic Define who can approve access, which attributes are required, and which conditions must be met before a resource is exposed. Keep those rules in one governed model so application teams do not create conflicting local exceptions.
• Convert standing access into conditional access Replace permanent permissions with time-bound or context-bound rules wherever the task does not require continuous access. Use role, device, and location signals to narrow exposure without creating manual review debt.
• Tie policy review to actual access usage Compare approved entitlements against observed access patterns and flag policies that no longer reflect how teams work. This helps identify stale roles, redundant exceptions, and rules that have drifted away from operational reality.
• Align lifecycle events with policy updates Trigger policy changes when users change role, leave a team, or lose a business need. Make onboarding, role changes, and offboarding update access rules at the same time so access does not outlive purpose.
• Use service account visibility as a policy control test If you cannot see how non-human identities are authorised, your policy model is incomplete. Cross-check service account access against application needs, especially where secrets, tokens, or integrations grant broad reach.

Key takeaways

• Access policy is the control layer that turns identity decisions into repeatable enforcement across people, systems, and workloads.
• Policy drift usually starts with exceptions and stale entitlements, then turns into broad access that no longer matches business need.
• IAM teams should centralise policy logic, tie it to lifecycle events, and review actual usage so access remains bounded by purpose.

Key terms

• Access Policy: A set of rules that determines who can access a resource, under what conditions, and what actions are allowed. In practice, it is the control logic that turns identity and context into consistent enforcement across users, service accounts, and applications.
• Conditional Access: An access model that adds context to the decision, such as device compliance, location, time, or behaviour. It helps limit trust to situations that match the organisation's risk posture, rather than treating every authenticated request as equally safe.
• Least Privilege: The principle that every identity should receive only the access required to complete its task. For non-human identities, this means scoping permissions tightly and revisiting them as integrations, workloads, and business needs change.
• Policy Drift: The gradual gap between written access rules and what is actually enforced in production. Drift appears when exceptions, manual overrides, and inconsistent lifecycle handling accumulate until the policy no longer reflects real access behaviour.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Josys: What is an Access Policy? Read the original.