Access Control Policy Template

The complete access control policy, free to copy from this page or download as an editable Word document. No sign-up. Replace every [bracketed placeholder] with your own details, delete anything that does not apply, and have it approved before you rely on it. The guide below explains what each section has to contain and what an auditor checks.

10

sections

4

with real wording

7

auditor requests

7

failure modes

The document runs to 10 clauses, none of them long. The work is not the prose - it is deciding who approves what, how fast access comes off, and who signs the reviews. Exact wording is quoted for the 4 clauses that get written badly almost every time.

1. 1

   Purpose

   What it must contain

   The outcome the document exists to produce: everyone holds the access their work needs, only while they need it, and you can show after the fact who held what.

   What the auditor checks

   Purpose is where an auditor decides whether you are managing access or filing a document. A purpose that says only "to comply with the standard" answers nothing.

2. 2

   Scope

   What it must contain

   Who it covers (employees, contractors and third parties) and which systems it covers: the identity provider, cloud platforms, business applications, source code, and physical entry to your sites.

   What the auditor checks

   Scope is the cheapest place to find a gap. Contractors and physical access are the two most commonly left out, and anything outside scope also falls outside your review cycle.

3. 3

   Access control principles

   What it must contain

   Least privilege, need to know, separation of duties, and individual accounts - each written as a rule an approver could apply to a real request rather than a slogan.

   What the auditor checks

   The principles are what you fall back on when a request does not fit any existing role profile. If they are too vague to settle an argument, every grant becomes a negotiation.

   Need to know: access to a data set needs a business reason, not a job title.

   It separates need to know from least privilege, which most policies blur, and it hands the approver a single question they can answer on the ticket. "Everyone in Sales has it" stops being an argument.

4. 4

   Identity and authentication

   What it must contain

   One identity per person in a named identity provider, single sign-on wherever an application supports it, multi-factor authentication for everyone including administrators, and local accounts disabled on anything behind single sign-on.

   What the auditor checks

   This gets sampled directly. An auditor will ask to see enforcement, then look for the local logins that quietly bypass it - the ones created so a contractor could get in on a Friday.

5. 5

   Granting access (joiners)

   What it must contain

   Who requests, who authorizes, what a new starter gets by default, and what happens when someone asks for more than the default. Name the standard role profile per position.

   What the auditor checks

   Without a default profile there is nothing to compare an account against at review time, so every review becomes a debate about whether that access was ever justified.

6. 6

   Changing and removing access (movers and leavers)

   What it must contain

   Movers as a single request naming what to add and what to remove, with a deadline. Leavers as account disabled, sessions and API tokens revoked, and their work reassigned on the final working day.

   What the auditor checks

   This is the clause auditors test hardest, because leaver and mover tickets are easy to sample, carry dates, and cannot be reconstructed after the fact.

   When someone changes role, their manager raises one request stating the access to add and the access to remove; entitlements from the previous role are revoked within five business days.

   One request forces the removal to happen, because two requests means only the first one ever gets done. And five business days is a number a sample either passes or fails; "promptly" cannot be failed, which is exactly why it cannot be passed.

7. 7

   Privileged access

   What it must contain

   Named individuals only, administrator access held on an account separate from everyday work, a named authorizer, session logging with a retention period, and a human owner plus credential rotation for every service account.

   What the auditor checks

   Service accounts are the ones nobody owns and nobody reviews. Once you claim least privilege, they are the first thing an auditor asks you to account for.

8. 8

   Emergency (break-glass) access

   What it must contain

   How many break-glass accounts exist, where the credentials live, what happens automatically when one is used, who reviews that use and how quickly, and that the credentials are rotated afterward.

   What the auditor checks

   Most policies omit this entirely, so real emergencies happen off-policy. An auditor who finds no break-glass clause assumes the answer is a shared administrator login in someone's password manager.

   Any use raises an automatic alert to [Role] and is reviewed within one business day.

   The alert is automatic, so the use is detected without anyone volunteering it, and the review carries a deadline rather than an intention. Where the credentials live and how fast they are rotated afterward are the other two decisions the clause has to settle.

9. 9

   User access reviews

   What it must contain

   Who reviews (the system owner, not the account holder), a cadence split by risk, a recorded decision on every line, and how fast a revocation has to be actioned.

   What the auditor checks

   The completed review is the strongest single piece of evidence you can hand over. This clause is what tells the auditor the record they are holding is the one you promised to produce.

   Every line carries a recorded decision - retain, reduce or revoke.

   "Every line" closes the gap where only the removals get written down, so a retained entitlement reads as a decision somebody made instead of a row nobody opened. Say in the same clause who reviews, and how fast a revocation has to be actioned, so the record leads to a ticket an auditor can follow to the end.

10. 10

    Third parties, exceptions and review

    What it must contain

    Third-party access as time-limited, authorized and reviewed on the same cycle as internal access; an exception route that is requested, risk-assessed, time-limited and recorded; and the document's own owner, review cycle, approver, approval date and version number.

    What the auditor checks

    An undated, unapproved, unversioned policy is a finding on its own. And with no exception route, people work around the policy quietly instead of on the record.

Get it written for your organization - your first document is free Card required; no charge today.

Nobody is ever asked to demonstrate least privilege. You are asked for named people, named tickets and dates. The 7 requests below cover most of an access control audit.

? Show me the access control policy.

Satisfies A current version with a named owner, an approver, an approval date and a next review date that has not already passed.

Fails A document with square brackets still in it, or a review date from two years ago.

? Pick three people who left in the last six months. What happened to their accounts?

Satisfies A leaver ticket for each, dated on or before the final working day, and identity provider records showing the account disabled and sessions revoked.

Fails An account still enabled because the person might come back as a contractor.

? Take someone who changed roles. What access did they lose?

Satisfies One request naming both the entitlements added and the entitlements removed, and a system record showing the old group membership is gone.

Fails A grant ticket with no matching revocation. This is the most common access finding there is.

? Show me the last access review for a production system.

Satisfies A completed record with a named reviewer who is not the account holder, a decision against every line, and a completion date.

Fails An export of who currently has access, with no decisions written on it.

? Who holds administrator access to production, and why?

Satisfies A short list of named people, each on an administrator account separate from their everyday one, with multi-factor authentication enforced and a business reason on record.

Fails A shared root login, or an administrator group nobody present can fully account for.

? Has break-glass access been used since the last audit?

Satisfies The automatic alert, the review that followed it inside your stated deadline, and the credential rotation afterward.

Fails No break-glass account at all, which means the last emergency ran on somebody's standing administrator rights.

? Which service accounts and API tokens exist, and who owns them?

Satisfies A list with a named human owner per account, rotation dates, and those accounts included in the same review cycle as people.

Fails Service accounts left out of the review on the grounds that they are not users.

The record several of those questions turn on

A user access review is a periodic check of who holds access to a system, made by the person who owns that system rather than the people in it. Quarterly for privileged and production access, at least annually for the rest. The output is not the export you pulled from your identity provider - it is the record of what you decided about each line of it. Here is one line, filled in.

Scroll the record sideways to read all 9 columns.

None of these are exotic. They are what a competent team produces when the document gets written once and is never tested against what happens on a Friday afternoon. Read your own draft against the list.

• ! Every deadline is the word "promptly"

  Promptly, in a timely manner, as soon as practicable: none of these can be failed by a sample, which is precisely why none of them can be passed either. Put a number against every removal. Same day for leavers, five business days for movers, and say business days so a Friday departure is not quietly a Tuesday one.

• ! Leavers get processed and movers never do

  Leavers get done because somebody notices a laptop that has not come back. Movers are where privilege creep accumulates: adding access is a ticket a manager chases, removing it is nobody's job. One reorganization later a support engineer is still carrying the production administrator rights they picked up during an incident, which is exactly the line the review record above catches.

• ! The access review is an export, not a decision

  Pulling the current user list is the easy tenth of the job. What makes it evidence is the recorded decision beside each line and a completion date at the bottom. A spreadsheet of who has access, with nothing written against any row, proves only that you can run a report.

• ! The reviewer is the person being reviewed

  A team lead signing off their own administrator access is not a review, and an auditor spots it in one glance at the reviewer column. Independence costs nothing to write in and is close to impossible to retrofit once the review has already been signed.

• ! Service accounts and API tokens are out of scope

  Human accounts get tidied up because people leave and somebody notices. Tokens do not leave. They sit in a pipeline nobody has opened in two years, they rarely expire, and they usually hold more access than any person does. Give each one a named human owner and put them in the same review cycle.

• ! Administrator access is the everyday account

  One account reading email in the morning and deploying to production in the afternoon means every phishing link is a production incident. Separate accounts also make the logs readable, because you can tell routine work from privileged work without guessing.

• ! The policy contradicts your other documents

  The onboarding checklist says access is arranged in the first week; this policy says day one. The supplier policy reviews third parties annually; this one says quarterly. Auditors read documents side by side, and a contradiction is worse than a gap because it shows nobody is reading the set as a whole.

Same structure as the guide, with none of the decisions left to you: your identity provider named, your joiner, mover and leaver owners and deadlines set, privileged and break-glass rules written for the systems you actually run, and a review cadence you can defend. It cites A.5.15, carries your branding, and exports to Word, PDF or Excel. The cover in the hero and the body page below are exactly that output, generated for an example company.

Where the guide says [role] or [system], the document says yours; where PolicyMint cannot know a fact, it asks rather than guesses.

Guided review Actual product

The one fact this document could not know stays highlighted in the document and the export. The review explains what is needed and writes your answer in. Nothing is invented. Fictional demo data.

Both routes end with the same 10 clauses. What differs is how many of the decisions inside them you make alone, and who checks the result before an auditor does.

Scroll the table sideways to compare both routes.