Access control policy template: the sections auditors actually test

Access control is sampled in almost every audit, and the policy is what you are measured against. A vague policy is not a safe policy - it means the auditor tests you against a reasonable interpretation rather than yours. Precision protects you.

1. Scope

Which systems, which identity types. State explicitly that it covers non-human identities - service accounts, API credentials, workload identities - because that is where most gaps are found and most policies are silent.

2. Principles

• Least privilege - access limited to what the role requires.
• Need to know - separate from least privilege and worth stating.
• Segregation of duties - reference your list of incompatible duties rather than restating it.
• Deny by default.
• Unique identity per person - no shared accounts, with a named exception process if any exist.

3. The decisions the policy must settle

These are what turn a statement of intent into something testable:

• Who approves access, and whether system owners approve in addition to line managers for sensitive systems.
• Provisioning timing - access granted only after approval, never before.
• Revocation timeline on departure. State a figure you can meet; it becomes your audit standard.
• Review frequency per system tier, with who reviews and what evidence the review must produce.
• Privileged access - approval, time limits, monitoring, and whether standing admin rights are permitted at all.
• Authentication requirements by system tier, including where phishing-resistant MFA is mandatory.

Write the review clause carefully. "Access is reviewed periodically" is untestable. "System owners review all user access quarterly for tier 1 systems, recording a decision per account, retained for three years" is testable - and tells your team exactly what to produce.

4. Movers - the clause most policies omit

Joiners and leavers are usually covered; role changes are usually not. State that a role change triggers removal of the previous role's access, not merely addition of the new. Without this clause, privilege accumulates legitimately and your reviews keep finding it.

5. Remote and third-party access

Cover contractors and suppliers explicitly: sponsorship by a named employee, an expiry date set at creation, and the same review cycle. Third-party accounts outliving the engagement is a standard finding.

6. Exceptions

Reference your exception process rather than inventing a parallel one - what must be documented, who approves at each risk level, mandatory expiry, and the compensating control.

7. Evidence the policy should require

Naming these inside the policy makes them happen: approval records per grant, revocation records with timestamps, review records showing a decision per account, privileged session logs, and a periodic reconciliation of the HR leaver list against active accounts.

What to leave out

Technical configuration - password lengths, session timeouts, specific tooling - belongs in a standard beneath the policy. Put it in the policy and every parameter change becomes a policy revision requiring re-approval.

Key takeaways

• Cover non-human identities explicitly - that is where the gaps are.
• Write review clauses so they are testable, with a decision per account.
• Include a mover clause, or privilege accumulates legitimately.
• Keep configuration parameters in a standard, not the policy.