Free Access Control Policy Template
A complete access control policy with 12 sections mapped to ISO 27001:2022, SOC 2, HIPAA, and PCI DSS. Includes dual-approval requirements for admin access, a Role Access Matrix (Appendix A), a formal Exception Process (Appendix B), and an evidence column showing what operational records each clause requires.
Written at the level of specificity that passes actual audits — not a generic framework summary.
No sign-up required. CSV opens in Excel, Google Sheets, and Numbers.
12 sections — what each one proves and what evidence it requires
The "Evidence of Compliance" column is the most important part. Every policy clause is only as strong as the operational evidence that supports it.
Purpose
States that this policy exists to protect confidentiality, integrity, and availability by controlling who can access what. This is the 'existence' evidence — auditors check that a written policy exists and is approved by management.
Frameworks: ISO 27001 A.5.15 / SOC 2 CC6.1
Evidence needed: Signed policy document
Scope
Defines that the policy applies to all employees, contractors, third parties, and automated systems. Auditors look for explicit contractor coverage — a policy that covers only employees leaves a gap.
Frameworks: ISO 27001 A.5.15
Evidence needed: Employment and contractor agreements referencing this policy
Roles and Responsibilities
Assigns the policy to an owner (IT Manager/CISO), designates system owners as the approvers for access to their systems, and makes HR responsible for triggering joiner/leaver workflows. This is what auditors check when they test segregation of duties.
Frameworks: ISO 27001 A.5.2 / SOC 2 CC6.2
Evidence needed: Quarterly management report; role definitions
Access Request and Approval
All requests must be documented with justification, submitted through a formal channel (not verbal), and approved by the system owner before provisioning. Admin access requires dual approval. This section is the primary evidence for CC6.2.
Frameworks: ISO 27001 A.5.18 / SOC 2 CC6.2
Evidence needed: Access request records with approval timestamps
Principle of Least Privilege
Sets the <15% admin target and the requirement for separate admin/day-to-day accounts where feasible. The admin concentration metric is one of the first calculations an auditor makes from your access review data.
Frameworks: ISO 27001 A.5.15 / SOC 2 CC6.3 / PCI DSS 7.1 / HIPAA 164.312(a)(1)
Evidence needed: Access level field in review records; admin % metric
Periodic Access Reviews (90-day)
Requires quarterly reviews for all user access. Specifies that reviews must maintain segregation of duties (no self-review). Defines the 5-business-day escalation path for overdue reviews, and 10-business-day suspension trigger. This section is tested with your access review spreadsheets.
Frameworks: ISO 27001 A.5.18 / SOC 2 CC6.3
Evidence needed: Completed review records with reviewer name and date
Joiner Process
Requires 5-day advance notice from HR. Defines role-based access profiles (Appendix A). Restricts production admin access on Day 1. Requires security awareness training before sensitive data access.
Frameworks: ISO 27001 A.5.18 / SOC 2 CC6.2
Evidence needed: HR notification records; provisioning tickets referencing role profiles
Leaver Process
Access must be revoked on or before last day. Involuntary terminations: within 2 hours. Shared secrets must be rotated within 24 hours. References the Offboarding Checklist Template as the evidence record.
Frameworks: ISO 27001 A.5.18 / SOC 2 CC6.3 / ISO 27001 A.7.3
Evidence needed: Signed offboarding checklists; revocation timestamps
Privileged and Admin Access
Requires a privileged account register listing every admin account. Mandates MFA for all admin and remote access. Requires logs to be retained for 12 months. Unused privileged access must be revoked after 90 days.
Frameworks: SOC 2 CC6.1 / PCI DSS 8.6 / ISO 27001 A.8.2
Evidence needed: Privileged account register; CloudTrail / audit log retention settings; MFA enrollment report
Third-Party and Contractor Access
Third-party access must be time-limited (max 12 months without renewal), scoped to minimum required systems, and backed by a signed NDA. Auditors specifically ask for a contractor access register — a list of all active third-party accounts with expiry dates.
Frameworks: ISO 27001 A.5.19 / SOC 2 CC9.2
Evidence needed: Contractor access register with expiry dates
Remote Access
All remote access must use company-managed VPN or zero-trust gateway. Direct RDP or SSH from personal devices to production is prohibited. MFA required. Logs retained 12 months.
Frameworks: ISO 27001 A.8.20 / SOC 2 CC6.6 / PCI DSS 8.6
Evidence needed: VPN configuration; MFA enrollment report
Enforcement and Exceptions
Policy exceptions require IT Manager/CISO approval with documented compensating controls and an expiry date. Policy must be reviewed annually. Auditors check that the 'last reviewed' date is within 12 months.
Frameworks: ISO 27001 A.5.31 / A.5.1
Evidence needed: Exception register; annual review record
Policy vs evidence: the audit gap most companies fall into
A policy document alone will pass a document review. It will not pass a Type II audit. Here's what auditors call "design testing" vs "operating effectiveness testing":
Design testing (does the policy exist?)
- Written policy document with management approval
- Policy covers all required topics (joiner, leaver, reviews, MFA, least privilege)
- Policy reviewed within the last 12 months
- Policy distributed to all staff (acknowledgement records)
SOC 2 Type I / ISO 27001 initial certification — design testing is sufficient.
Operating effectiveness testing (do you actually follow it?)
- 3–4 completed quarterly access review records with no 90-day gaps
- Access request tickets with documented approval for sampled provisioning events
- Signed offboarding checklists for sampled departures
- MFA enrollment report showing all admin accounts have MFA
SOC 2 Type II / ISO 27001 surveillance audit — operating effectiveness is required.
Good vs weak policy evidence
How to implement this policy in 6 steps
Fill in the document header
Replace all bracketed fields: organisation name, policy owner, approval date, next review date. The approval date must be the date your CEO or management signed off — not today if the policy isn't yet approved.
Customise the Role Access Matrix (Appendix A)
The template includes 7 sample job functions. Add or modify roles to match your org structure. For each role, define: standard systems, access level, and systems requiring additional approval.
Identify your system owners (Section 3.2)
Each system needs a named owner — the manager or technical lead accountable for approving access requests and completing quarterly reviews. Document this in your system inventory, not just verbally.
Connect the policy to your operational records
The Evidence column tells you what operational records each clause requires. Check that all those records exist or can be created: access review spreadsheets, provisioning tickets, offboarding checklists, MFA reports.
Get management approval
Present the policy to your CEO or CISO for signature. Record the approval in the Document History section. Distribute to all employees and collect acknowledgement (an email confirming receipt is sufficient).
Schedule annual review
Set a recurring calendar event for 11 months from today to review the policy before the 12-month deadline. Update the version number and approval date on every review, even if no content changes.
Policy ≠ evidence — the most common audit finding
"The organisation has a documented access control policy. However, during testing of operating effectiveness for controls CC6.2 and CC6.3, management was unable to provide access review records for [system] covering the period [Q2–Q4]. The controls were rated as design-only." A design-only rating on CC6.2 or CC6.3 prevents a clean SOC 2 report. AllowNow generates the operational records — access reviews, provisioning logs, offboarding checklists — that transform your policy into passing evidence.
Generate compliance evidence — freeFrequently asked questions
Does having a policy document count as evidence of compliance?
A policy is necessary but not sufficient. It proves you have documented intent — but auditors will require operational evidence that you actually follow the policy. The most common finding is 'policy exists but evidence of operating effectiveness was not provided.' For every clause in the policy, you need a corresponding evidence record: access review spreadsheets for Section 6, onboarding tickets for Section 7, signed offboarding checklists for Section 8, and so on.
Does this template work for ISO 27001 certification?
Yes — this template is structured around ISO 27001:2022 Annex A control A.5.15 (Access control) and related controls. It maps every section to the specific ISO 27001 clause. For ISO 27001 certification, you'll also need this policy to be included in your Statement of Applicability (SoA) and linked to your risk treatment plan. The template itself is your policy document — the operational evidence comes from your access reviews, provisioning records, and offboarding checklists.
How specific do the business justifications need to be?
Specific enough that a person unfamiliar with the team could understand why admin-level access (and not standard access) is required. 'Engineering team member' is not specific enough. 'Required to configure GitHub Actions secrets, manage branch protection rules, and perform emergency incident response in production' is specific enough. The justification must explain the delta — why does this person need more than the standard access level?
How often does the policy need to be reviewed?
At minimum once per year. ISO 27001 A.5.1 requires periodic review. SOC 2 auditors will check the 'last reviewed' date during a Type II audit. You should also review the policy after: a significant security incident, major changes to your system landscape (acquisitions, new cloud providers), regulatory changes, or significant team structure changes. Record each review in the Document History section at the bottom of the template.
What's the exception process for when a control can't be followed?
The template includes a full exception process (Appendix B): the requester submits a formal request explaining the business reason, IT Manager/CISO documents the risk and compensating controls, High/Critical exceptions require escalation to the board, and all exceptions are given an expiry date and reviewed quarterly. Without a documented exception process, any deviation from the policy — even a justified one — becomes a finding.
Download the policy template
12 sections, Role Access Matrix, Exception Process — no sign-up required.