Writing an access management policy is not a documentation exercise. It is the process of forcing your organization to make access governance decisions it has been deferring — sometimes for years.
Your organization has been making access decisions every day. Someone joined and got provisioned. Someone changed roles and kept their old access. Someone left and their accounts sat open for three weeks. A manager approved a contractor's request for production access because it seemed reasonable and there was no clear guidance saying otherwise.
None of these were non-decisions. They were decisions made informally, inconsistently, by whoever was in front of the situation that day. The problem is not that your organization lacks an access governance model. It is that the model exists in fragments, distributed across the mental models of every IT lead, HR business partner, and department manager who has ever dealt with an access request.
An access management policy does not create a governance model from scratch. It forces the one that already exists — implicitly, inconsistently — into the open, makes it explicit, and gets the people responsible for following it to agree on it in writing.
That is a fundamentally different exercise from producing a compliance document. And it is why organizations that approach policy as a documentation task end up with forty-page PDFs nobody follows, while organizations that approach it as a decision-making process end up with eight-page documents that actually change how access works.
In this article:
- The Decisions Your Organization Is Already Making (Just Not Officially)
- Why Most Policies Fail to Force Anything
- The Four Decisions You Cannot Avoid
- Getting Stakeholders to Make Decisions, Not Just Review Yours
- Version 1 Is a Hypothesis, Not a Specification
- How the Policy Improves With Each Iteration
- What the Document Needs to Capture
- The Alignment That Outlasts the Document
- Frequently Asked Questions
The Decisions Your Organization Is Already Making (Just Not Officially)
Before writing a single word of policy, it is worth mapping what is actually happening today. Most access governance programs, when examined honestly, have a de facto policy — a set of informal norms that govern how access decisions get made in practice. The problem is not the absence of decisions. It is that the decisions are invisible, inconsistent, and unowned.
Consider how a few common situations actually play out in a typical mid-market organization.
A new hire's manager submits an IT ticket listing the apps they need. IT provisions what is on the list, sometimes asks a clarifying question, and closes the ticket. Nobody asks whether the list reflects least privilege or whether some of those apps require secondary approval. The informal decision: IT provisions whatever managers request.
An employee moves from the customer success team to the sales operations team. Their manager submits a ticket requesting the new access they need. IT provisions it. Nobody reviews what the employee had before. Nobody removes the CS tools they no longer need. The informal decision: role changes add access, they do not subtract it.
An employee resigns with two weeks notice. Their manager sends an email to IT on their last day. IT deactivates the Okta account. Three SaaS apps that are not in SSO stay active for six more weeks until someone notices during an access review. The informal decision: deprovisioning covers whatever IT can see from the IdP.
A contractor needs access to a project repository. Their sponsor on the engineering team messages IT on Slack. IT grants access. The contract ends. Nobody tells IT. The informal decision: contractor deprovisioning depends on someone remembering to ask.
These are not edge cases. They are the actual access governance model most organizations are running. Writing a real access management policy means naming these patterns, deciding which ones are acceptable and which are not, and replacing informal norms with explicit agreements.
Why Most Policies Fail to Force Anything
The standard approach to access management policy produces a document that fails to change any of the patterns described above. Understanding why is important, because the failure mode is almost always the same.
The policy is assigned to the compliance or security team as a documentation task. They produce a document describing ideal state in compliance language. The document gets reviewed by legal, signed by the CISO, and published to the intranet. The IT lead reads the summary. The HR business partner does not read it at all. Department managers are unaware it exists. The informal norms continue.
This fails because a document that describes what should happen does not displace a practice that has inertia. The IT lead who has been provisioning whatever managers request does not change that behavior because a policy PDF says access decisions belong to application owners. The behavior changes when the application owner has been in a conversation where they explicitly agreed to own those decisions, understands what that means operationally, and has a channel for exercising that accountability.
The document records the decision. The conversation is what makes the decision real.
A policy that is written without that conversation is not a forcing function. It is a compliance artifact that describes a governance model that does not exist, produced for an audience that will never read it, owned by a team that has no operational authority to enforce it.
The first and most important shift in approach: the policy writing process begins with conversations, not drafting.
The Four Decisions You Cannot Avoid
There are four governance decisions that every access management policy must make explicitly. These are the decisions most organizations have been avoiding — not because they are technically complex, but because making them explicit requires cross-functional agreement that is uncomfortable to force.
Who actually owns access decisions?
The avoidance pattern here is defaulting to "IT manages access" as a non-answer that distributes no real accountability. In practice, access decisions have two distinct components: the business judgment about whether a person should have access to a resource, and the technical execution of granting or revoking that access. Conflating them into a single IT responsibility is what creates the provisioning-whatever-managers-request problem.
The policy must name who holds the business judgment for each category of resource. For standard applications, that is typically the direct manager. For sensitive systems — financial data, HR systems, customer PII, production infrastructure — a named secondary approver is required. The policy does not have to resolve every edge case. It has to make clear that IT executing an access request is not the same as IT authorizing it, and that the authorization belongs to a named role.
This is the decision most organizations avoid longest because it shifts accountability onto people who currently have none. Department heads who have been able to approve access informally, without documentation or review, gain explicit ownership of something that can now be audited. Expect resistance. The resistance is evidence that the decision is the right one to force.
What does least privilege actually mean for your roles?
Every policy says "least privilege." Almost none define it. The avoidance pattern is keeping the principle abstract because making it concrete requires role-by-role decisions that are time-consuming and will reveal how inconsistently access has been granted historically.
The forcing function here is the role baseline exercise: for each of your ten most common job roles, what applications does someone in that role get on day one, and at what permission level within each application? A sales development rep gets Salesforce standard user, LinkedIn Sales Navigator, and Slack. Not Salesforce admin. Not the data warehouse. Not GitHub.
Doing this exercise surfaces two uncomfortable things. First, you will find that your current access grants for most roles significantly exceed what the baselines say they should be — because access has accumulated over time with no subtraction process. Second, you will find that managers have strong opinions about what their teams need that do not always match the security team's view of least privilege. The policy writing process is where those tensions get resolved, not suppressed.
The baselines will be wrong in places. That is expected. A documented baseline that is 80% right, reviewed every six months, and refined based on what the access review process surfaces is dramatically more effective than an abstract principle that nobody can operationalize.
What happens when someone changes role?
The mover problem is the most consistently avoided decision in access management, because it requires organizations to confront how badly access has accumulated across role transitions and commit to a cleanup process they may not have the resources to execute cleanly.
The forcing function is asking one specific question in the policy writing session: when an employee moves from role A to role B, what is the explicit process for removing role A's access? Not the provisioning of role B — that is the part organizations have usually thought about. The deprovisioning of role A. Who is responsible for initiating it? What is the trigger? What is the timeframe? What happens if it does not happen within that timeframe?
If the answer is "their manager reviews their access at the next quarterly cycle," that is an acceptable answer — but it needs to be written down, communicated to managers as an explicit accountability, and measured. An answer that lives in one person's head is not a governance decision. It is a single point of failure.
How are exceptions managed, and what happens when they expire?
The exception avoidance pattern is one of the most damaging in access governance: exceptions are granted informally, never expire, and silently become permanent access grants. Most organizations that have run an honest access review find that a significant portion of their access sprawl originated as temporary exceptions that nobody revoked.
The policy must specify an exception process with teeth: how to request, who approves, what the maximum duration is, what the renewal process looks like, and who reviews open exceptions on a regular cadence. The duration limit is the decision most organizations resist because it requires ongoing administrative work. That resistance is worth pushing through, because the alternative is an exception process that has no sunset and therefore no meaningful governance at all.
Getting Stakeholders to Make Decisions, Not Just Review Yours
The most common mistake in the policy writing process is treating stakeholder involvement as a review step rather than a decision-making step. Sending a draft policy to IT, HR, and department heads for comments does not produce alignment. It produces edits that reflect each stakeholder's preferred version of the decisions you already made.
The process that actually works starts with conversations before any drafting happens. The goal of those conversations is not to explain the policy. It is to surface each stakeholder's current mental model of how access decisions work and find the gaps and contradictions between them.
A useful framing for the first conversation with each stakeholder group: "Walk me through what happens when someone on your team needs access to a system they do not currently have." The answers will be different. IT will describe the ticket-based process. Managers will describe what they actually do, which is often a direct message to an IT contact they know. HR will describe the onboarding form. None of them will describe the same process.
That divergence is the raw material for the policy. The drafting process is not about creating a new process from scratch — it is about choosing which of the existing approaches becomes the official one, filling in the gaps, and getting agreement from the people who will live with it.
For each of the four decisions above, the stakeholder conversation needs to reach a specific agreement, not just general alignment. Not "we agree access decisions should have clear ownership" but "we agree that managers own access approval for standard applications, and the security team owns secondary approval for the systems on this list." The specificity is what makes the policy a forcing function. Vague agreement is not a decision.
Version 1 Is a Hypothesis, Not a Specification
One of the most useful reframes for approaching the policy writing process is treating version 1 as documentation of your current best hypothesis about how access governance should work — not a final specification of how it will work.
This framing reduces the pressure on the initial process to produce a perfect document, which almost never happens and is not necessary for the policy to be useful. It also changes the conversation with stakeholders who are reluctant to commit to specifics. "We are documenting what we think should happen, we will test it for six months, and we will come back and fix what does not work" is a much easier agreement to reach than "we are writing the final access governance model for the next three years."
Version 1 might specify a 48-hour SLA for provisioning approved access requests. After one quarter of operation, the data shows IT is meeting that SLA for 60% of requests and the bottleneck is manager approval response time, not IT execution time. The response is not to declare the SLA a failure. It is to investigate whether the approval workflow is workable, add an automated reminder at 24 hours, and update the SLA in version 2 to reflect what is actually achievable given the approval process.
This iteration model has a practical implication for how you scope version 1. Write the decisions you have actually made, in the simplest language that makes them unambiguous, covering the most common cases. Resist the pressure to cover every edge case in the first version. Edge cases belong in version 2, informed by the edge cases that actually arose in the first cycle. A ten-page policy that covers 80% of situations and gets followed is more valuable than a forty-page policy that covers everything and gets ignored.
How the Policy Improves With Each Iteration
The value of treating policy as an iterative document compounds over time in ways that are not obvious when you are writing version 1.
Each policy cycle produces evidence that the current version of the policy either works or does not work in specific ways. Access reviews surface which role baselines are too broad. Exception tracking reveals which access categories generate the most exception requests, which is usually a signal that the baseline for that category needs to be reconsidered. Deprovisioning logs show whether the mover process is being executed within the agreed timeframe.
That evidence should feed directly into the next policy version. The access management policy becomes a running record not just of what your governance model is, but of how it has evolved in response to what you have learned. After three or four cycles, the version history tells a story: what you thought would work, what actually worked, what you changed and why.
This is useful operationally in ways that extend beyond policy management. When a new security team member joins, the version history is a compressed briefing on the reasoning behind the current governance model — not just the rules, but the decisions and learning that produced them. When a department head pushes back on an access requirement, you can explain not just what the requirement is but what problem it was designed to address and what happened in the cycle before it was introduced.
The policy, maintained this way, stops being a compliance artifact and starts being a design document for the security program. One that reflects genuine organizational learning rather than a one-time best-practice exercise.
What the Document Needs to Capture
The document that comes out of the decision-making process should be as short as possible while capturing every decision that has been made. The test for each section is whether it records a specific decision or whether it is there to look comprehensive.
Purpose and scope in two paragraphs. What this policy governs and who it applies to. Not a definition of access management for people who do not know what it means.
Roles and responsibilities with named roles and named accountabilities. Not "the security team is responsible for access governance" but "the CISO owns this policy, IT leads provision approved access within 24 hours of approval, and department managers approve access requests for their direct reports and own the accuracy of their team's quarterly access review." The specificity is what makes the accountability real.
Access decision framework covering the full request-to-provision flow: how access is requested, who approves at each tier, what documentation is required for sensitive system access, what the exception process looks like including duration limits and renewal requirements.
Lifecycle events for all four cases — joiner, mover, leaver, contractor. For each: what triggers the process, who is notified, what access actions occur, and what the completion timeframe is. The mover case needs its own explicit entry, not a footnote.
Review cadence and remediation specifying not just how often reviews happen and who conducts them, but what happens to identified over-provisioned access and by when. A policy that specifies reviews without specifying remediation timeframes is describing a process with no consequence for findings.
Exceptions and escalation capturing the full exception lifecycle: request channel, approval authority, maximum duration, renewal process, and the cadence for security team review of open exceptions.
Policy maintenance naming the owner, the review frequency, and the process for proposing changes between annual reviews.
That is seven sections. In plain operational language, for an organization of 200 to 2,000 employees, this runs eight to twelve pages. If the draft is longer, it is including things that belong in standards or procedures documents. The policy captures decisions. Standards specify requirements. Procedures document steps. Keep them separate.
The Alignment That Outlasts the Document
The most durable output of a well-run access management policy process is not the document. It is the shared mental model that the process created.
When your IT lead, HR business partner, and department heads have sat in the same conversation, worked through the same four decisions, and committed to the same answers in writing, you have something more resilient than a signed PDF. You have organizational memory that persists when the policy document is not in front of anyone.
This is what gives you leverage when the policy is not being followed. When an HR business partner fails to trigger the deprovisioning workflow before an employee's last day, the conversation is not "you violated our access management policy." It is "we agreed that the deprovisioning trigger is the HRIS close date — what happened here and what do we need to change?" The policy gives the conversation a shared reference point. The alignment gives it shared ownership.
It also changes the nature of policy violations from compliance failures into learning opportunities. A process that consistently breaks is a process that needs to be fixed, not a behavior that needs to be disciplined. The policy writing process, done with stakeholders rather than for them, creates the conditions for that kind of honest diagnosis because everyone in the conversation has ownership of both the model and its outcomes.
That is the thing that makes an access management policy a genuine forcing function rather than a compliance artifact. It forces decisions, yes. But the more important thing it forces is accountability — distributed, named, agreed-to accountability that survives the document itself.
Frequently Asked Questions
Why does writing an access management policy surface decisions organizations have been avoiding?
Because making a decision explicit in writing requires agreement from multiple stakeholders, and that agreement requires resolving the tensions between their different mental models. As long as access governance decisions are informal and distributed, each stakeholder can operate from their own version of the rules without those versions ever needing to be reconciled. The policy writing process forces reconciliation. The decisions that surface as difficult or contentious are almost always the ones that have been implicitly made differently by different people — and the ones where the gap between informal practice and stated governance intent is largest.
Should an access management policy be written by the security team or compliance?
Neither should write it alone. Security and compliance need to be in the process because they understand the framework requirements and the enforcement constraints. But the policy captures organizational decisions about ownership and process, and those decisions belong to the people who will live with them. IT, HR, and department leadership need to be active participants in the decision-making conversations, not reviewers of a finished draft. A policy written by security and reviewed by stakeholders will reflect security's mental model. A policy written with stakeholders will reflect organizational reality.
How do you get department heads to engage with the policy writing process?
Frame the conversation around their operational problems, not the security team's governance requirements. A department head cares about their team getting access on day one without a week of IT tickets. They care about not being blindsided in an audit because someone on their team had inappropriate access for two years. They do not care about least privilege as a principle. Lead with the operational failure modes the policy is designed to prevent, and the conversation about what the policy needs to say becomes much easier.
How long should an access management policy be?
Eight to twelve pages for a mid-market organization. The test is whether every section captures a decision that has been made, or whether some sections are there to look comprehensive. Background on access management concepts, generic statements about best practices, and definitions of terms your audience already knows are not policy. They are padding that reduces the probability anyone reads what actually matters. Cut them.
What happens when the policy is not being followed?
Start by asking whether the non-compliance is a behavior problem or a policy problem. If a specific process is routinely not followed, the most likely explanation is that the process as specified is not actually workable for the people responsible for following it. Fix the process before escalating the behavior. If the process is workable and the behavior is the problem, escalation through the department head who participated in the policy writing process is more effective than treating it as a security violation — because that person agreed to the accountability and can own the follow-through within their team.
How detailed should the role-based access baselines in the policy be?
Detailed enough to cover the ten most common roles in your organization, with specific applications and permission levels for each. Not so detailed that maintaining them requires constant policy updates every time a new tool is adopted. The baselines should be specific enough that the most common provisioning scenarios can be handled automatically, with exceptions requiring a documented request. Getting there iteratively — start with ten roles, refine based on access review findings, expand coverage in subsequent versions — is more practical than attempting to design complete baselines from scratch.
.svg)
