The access control policy template, printed in full
Accounts, passwords, approvals, reviews and leavers, written so the records can prove it.
An access control policy template sets who can reach which systems, how access is approved, how often it is reviewed and how fast it ends when someone leaves. A SOC 2 auditor tests it against the logical access criteria: CC6.1 on restricting access, CC6.2 on approving users before credentials are issued and removing them after, and CC6.3 on role-based access and least privilege.1
The full policy is below. Every number in it is one you can change before you sign.
What an auditor checks
Four populations get pulled from the records this policy governs, and each one is compared with a sentence in the policy.
- Joiners. For each new account, an approval dated before the access was granted.
- Leavers. The termination date from human resources beside the date each access was removed. The template allows 24 hours.
- Access reviews. One record per review the policy promises, each with a decision for every account. The user access review template is that record.
- Multi-factor authentication. The enforcement setting in the identity provider and the cloud console.
The full policy text
The password rule follows National Institute of Standards and Technology (NIST) Special Publication 800-63B-4: no forced changes on a schedule, and a 15 character minimum when a password is the only factor.2 Fill the brackets, then check every window and cadence against what your team really does.
[Company name]
Access Control Policy
- Owner
- [Security owner role]
- Approved by
- [Policy approver role]
- Effective date
- [Effective date]
- Next review
- [Next review date]
- Version
- [Version]
1. Purpose and scope
This policy supports the SOC 2 common criteria CC6.1, CC6.2 and CC6.3 by ensuring access to systems and data is restricted to authorized individuals.
This policy applies to all [In-scope personnel] and [In-scope systems].
2. Identity and authentication
- Unique user IDs: All users are assigned a unique ID. Shared accounts are prohibited.
- Passwords: A password used as the only factor is at least [Minimum password length] characters long. Passwords are managed in [Identity provider] or the Company password manager, and are changed when there is evidence of compromise rather than on a fixed schedule.
- Multi-factor authentication (MFA): MFA is required for all critical systems, including [Cloud provider] and [Identity provider].
3. Requesting and approving access
- Access to an in-scope system is requested in [Ticketing system] and approved by the system owner or the requester's manager before it is granted.
- The person who approves access is never the person who receives it.
- Access is granted by role. Access beyond the role records a reason and an end date.
4. Authorization and access management
- Least privilege: Access is granted based on the principle of least privilege.
- Provisioning and deprovisioning: Formal processes are used to grant, modify, and revoke access in a timely manner. Access is removed within 24 hours of termination.
- Access reviews: User access to in-scope systems is reviewed at least every six months, and access to production and privileged roles at least quarterly. The reviewer is not the person who granted the access, and each review records a keep, reduce or remove decision for every account.
5. Privileged access
Privileged access is restricted to named individuals, requires separate admin accounts, and is reviewed quarterly.
Administrative actions in production are logged, and the logs are kept under the Logging and Monitoring Policy.
6. Joiners, movers and leavers
- Joiners: accounts are created only after the [Human resources system] shows a start date and the access request is approved.
- Movers: when a person changes role, access the new role does not need is removed within 5 business days.
- Leavers: the identity provider account is disabled and live sessions are revoked within 24 hours of the termination date. Access to systems outside single sign-on is removed under the offboarding checklist, and each removal is recorded with its date.
7. Service accounts
Each service account has a named human owner, is used only by the system it serves, and has its credential stored in the secrets manager. The credential is rotated when someone who could read it leaves the Company.
8. Roles and responsibilities
| Role | Held by | Responsibility |
|---|---|---|
| Policy approver | [Policy approver role] | Approves this policy, each new version, and any risk the Company accepts instead of meeting it. |
| Policy owner | [Security owner role] | Maintains this policy, makes sure the controls in it operate, keeps the evidence, and reviews it at least once a year. |
| System owners | [Engineering owner role] | Approve access requests for their systems and take part in access reviews. |
| All personnel | Everyone in scope | Follow this policy and report a suspected breach of it to the [Security owner role]. |
9. Evidence and records
The records below show that this policy operates. Each is dated, kept for at least [Evidence retention period], and stored where an auditor can be given it.
| Record | What it shows | Where it is kept |
|---|---|---|
| Approved policy | This document, signed by the approver, with its version history. | [Documentation system] |
| Access review report | Certifications of user access reviews. | [Evidence storage location] |
| MFA policy configuration | Screenshot of MFA enforcement settings. | [Identity provider] |
| Deprovisioning records | Evidence of timely access revocation. | [Human resources system] |
| Access requests | Tickets showing approval before access was granted. | [Ticketing system] |
| Offboarding checklists | Termination date beside the date each access was removed. | [Evidence storage location] |
10. Exceptions and enforcement
A deviation from this policy needs a written exception approved by the [Security owner role] before it begins. Each exception records the rule not met, the business reason, the compensating control and an expiry date no more than 12 months away. Exceptions are reviewed at each annual review.
A breach of this policy is handled under the Company disciplinary process and may lead to action up to and including termination of employment or contract. A breach that exposes customer data is also handled as a security incident.
11. Review and approval
The [Security owner role] reviews this policy at least once a year and after any significant change to the business, the systems in scope or the risks they face. The [Policy approver role] approves each version. Personnel are told of material changes and acknowledge the current version.
| Version | Date | Summary of change | Approved by |
|---|---|---|---|
| [Version] | [Effective date] | First version. | [Policy approver role] |
Sign-off. Name, signature and date for: Policy approver.
12. Fields to complete
Replace every bracketed field in this document with your own detail, then delete this section.
| Field | What to enter |
|---|---|
| [Company name] | Your legal company name. |
| [Effective date] | The date the approver signs this version. |
| [Version] | Start at 1.0 and increase it each time the document changes. |
| [Security owner role] | The role that runs the security program day to day, for example Chief Technology Officer. |
| [Policy approver role] | The officer who approves policies and accepted risks, for example Chief Executive Officer. |
| [Evidence storage location] | The shared folder or system where evidence is kept. |
| [Documentation system] | Where policies and procedures are published, for example the company wiki. |
| [In-scope personnel] | Who the policy covers, for example employees and contractors with access to company systems. |
| [In-scope systems] | The product, cloud accounts and tools inside the audit boundary. |
| [Identity provider] | The single sign-on directory, for example Google Workspace or Okta. |
| [Cloud provider] | Where production runs, for example AWS, Google Cloud or Azure. |
| [Minimum password length] | At least 15 characters where a password is the only factor. |
| [Human resources system] | Where start and end dates are recorded. |
| [Ticketing system] | Where changes and incidents are tracked, for example Jira or Linear. |
| [Evidence retention period] | How long audit evidence is kept, for example three years. |
| [Engineering owner role] | The role that owns production systems, for example engineering lead. |
| [Next review date] | The date this version must be reviewed by, at most 12 months after the effective date. |
How to adapt it in an afternoon
- Fill the brackets. Identity provider, cloud provider, ticketing system and the human resources system that holds start and end dates.
- Check the windows. 24 hours to remove a leaver and 5 business days for a mover. Change them to numbers you hit on a bad week.
- Pick review cadences you will keep. A review you skip is an exception, so a slower cadence you keep beats a faster one you miss.
- List the systems outside single sign-on. Those are the ones the offboarding checklist exists for.
- Approve it and set the review date. Then run the first access review so the record exists before the audit period opens.
What produces a finding
A leaver whose cloud access outlived the window. A review the policy promised that never happened, or happened with no decisions written down. An administrator who approved their own access. Each is a gap between the written rule and the record, and each appears in the report as an exception rather than as a missing document.
The acceptable use policy carries the rules people follow on their own devices, and the information security policy says who owns this one. How many policies SOC 2 needs covers the rest of the set.
Polara G.R.C. onboarding is $2,000 one time. It writes the thirteen policies in its pack, which cover access control, from your intake answers, with your systems, owners and review dates named, for you to review and approve. No template passes an audit on its own, this one included. An independent licensed U.S. CPA firm tests whether the policy operated.
Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Questions
Does SOC 2 require an access control policy?
Should a password policy force changes every 90 days?
How often should user access be reviewed for SOC 2?
Who approves the access control policy?
Is an access control policy template enough to pass SOC 2?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Onboarding is $2,000 one time, then SOC 2 Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.