How to Write an Access Control Policy (for ISO 27001 & SOC 2)

The Access Control Policy is one of the most heavily tested documents in any ISO 27001 or SOC 2 engagement. Here is what it must cover, how it maps to the controls auditors check, and how to make it true rather than aspirational.

What an Access Control Policy is and why auditors probe it

An Access Control Policy is the document that governs who can reach which systems and data, under what conditions, and how that access is granted, changed, and removed. It sits underneath your top-level Information Security Policy and translates the principle "only the right people get the right access" into rules the organization actually follows. For most small businesses, startups, MSPs, and regulated professionals, it is one of the first detailed policies an auditor asks to see.

It gets probed hard because access is where most real-world breaches and audit findings begin. A former contractor whose account was never disabled, an engineer with standing production admin rights they no longer need, a shared login with no individual accountability — these are the failures access controls exist to prevent. The policy is the written commitment; the access itself is the control the auditor tests against it.

That is the relationship to keep in mind throughout. The policy documents and requires; the program operates. A clear, current Access Control Policy that matches how accounts are genuinely managed signals a real program. One that describes controls you do not actually run becomes a contradiction the auditor turns into a finding.

The core principles it has to encode

Four principles underpin a credible Access Control Policy, and a strong policy states each one plainly rather than assuming it.

Least privilege means people and systems get the minimum access needed to do their job, and nothing more. It is the default posture: access is denied unless there is a reason to grant it, not granted broadly and trimmed later.

Need-to-know narrows that further for sensitive information. Even users with broad system access should only reach the specific data their role requires — a support agent does not need the full customer database to resolve one ticket.

Separation of duties (often called segregation of duties) ensures no single person controls an entire sensitive process end to end — for example, the person who requests access should not be the one who approves it, and the developer who writes a change should not unilaterally deploy it to production. It is a structural defense against both fraud and error.

Role-based access control (RBAC) is the practical mechanism that makes the first three sustainable. Instead of granting permissions person by person, you define roles, attach the right permissions to each role, and assign people to roles. RBAC makes least privilege auditable and makes the joiner-mover-leaver process tractable as you grow.

What it must cover: accounts, authentication, and privileged access

A useful Access Control Policy covers the full life of an account. Provisioning defines how access is requested, who authorizes it, and how identities are created. The joiner-mover-leaver flow is the spine of this: joiners receive role-appropriate access on day one, movers have access adjusted when they change roles (with old permissions removed, not just new ones added), and leavers are deprovisioned promptly. "Promptly" matters — access that lingers after someone departs is a classic finding, so state a target timeframe and tie deprovisioning to your HR offboarding trigger.

Authentication is the next pillar. The policy should set rules for how identities prove themselves: credential standards, how secrets are stored and handled, and where multi-factor authentication (MFA) is required. MFA on remote access, administrative interfaces, and key systems is now a baseline expectation rather than an enhancement. Note the framing: the policy requires MFA; whether MFA is genuinely enforced everywhere it should be is the control the auditor will test.

Privileged and administrative access needs its own explicit treatment because it carries the most risk. The policy should require that admin rights are granted sparingly, tied to named individuals rather than shared accounts, separated from day-to-day user accounts where practical, logged, and reviewed more frequently than ordinary access.

What it must cover: reviews, remote and third-party access, and logging

Periodic access reviews are how you prove least privilege over time rather than just at provisioning. The policy should require that account owners or system owners review who has access to each significant system on a defined cadence — quarterly for sensitive or privileged access is common, at least annually for the rest — and that any access no longer needed is revoked. The review only counts if it produces dated evidence: who reviewed, what they found, what was removed.

Remote and third-party access deserve explicit rules because they extend your perimeter to people and devices you control less directly. Cover how remote workers connect (VPN or equivalent, MFA, device requirements) and how vendors, contractors, and managed service providers are granted, scoped, time-bounded, monitored, and removed. Third-party accounts are easy to create and easy to forget — name who owns each one and bring them into the same review cycle.

Logging ties it together. The policy should state that access events — logins, privileged actions, access changes, and failures — are logged, protected from tampering, and retained long enough to investigate an incident or satisfy an auditor. Logs are what let you answer the question every reviewer eventually asks: who accessed this, and when?

Mapping it to ISO 27001 Annex A and SOC 2 CC6

Your Access Control Policy supports a specific, recognizable set of controls, and mapping it explicitly makes both audits far easier. In ISO/IEC 27001:2022 Annex A the core anchors are A.5.15 Access control (the overarching requirement), A.5.16 Identity management (how identities are managed across their lifecycle), and A.5.18 Access rights (provisioning, review, and removal of rights). On the technological side, A.8.2 Privileged access rights covers your admin-access rules, A.8.3 Information access restriction backs need-to-know, and A.8.5 Secure authentication underpins your authentication and MFA requirements.

A few of the topics in this policy belong to adjacent Annex A controls rather than the six above, so cite them correctly: separation of duties is A.5.3 Segregation of duties, the handling of credentials and secrets falls under A.5.17 Authentication information, and access-event logging is A.8.15 Logging. Mapping each rule to the right control — instead of forcing everything under one or two — is what a Statement of Applicability and an internal audit reward.

For SOC 2, access sits at the heart of the Common Criteria series CC6, Logical and Physical Access Controls. The most reliable anchors for this policy are CC6.1 (logical access security over protected information assets), CC6.2 (registering and authorizing users before granting access), and CC6.3 (managing access based on roles and removing it when no longer appropriate). A licensed CPA firm tests these criteria against how your access actually operates, so the cleaner your policy-to-criteria mapping, the more navigable the examination.

Common mistakes, and how to operationalize and evidence it

The same failures recur. The policy describes a clean joiner-mover-leaver process the organization does not actually run; deprovisioning happens eventually rather than promptly; access reviews are claimed but never evidenced; privileged accounts are shared, unlogged, or never revisited; and remote and third-party access live outside the review cycle entirely. Each of these is a contradiction between the written rule and the practice, and auditors test the practice.

Operationalizing the policy means turning each rule into a repeatable action that throws off evidence. Wire deprovisioning to your HR offboarding so departures trigger account removal within your stated window. Put access reviews on the calendar with a named owner and keep the signed-off review records. Manage permissions through roles so least privilege is something you can show, not just assert. Capture access logs and confirm they are retained. The test is simple: for every statement in the policy, ask whether you could produce dated proof tomorrow that it happened.

This is where a well-built template earns its place. The ComplianceDocs ISO 27001 and SOC 2 toolkits each include an editable Access Control Policy with the right sections, sensible default language, and the principles and lifecycle structure already laid out — genuinely the slowest part to write from a blank page. But a template is a starting point you tailor, not a shortcut to compliance. It cannot make you compliant, certified, or attested: ISO certification comes from an accredited certification body and a SOC 2 report from a licensed CPA firm, only after auditing a program that truly operates. Making the policy reflect your reality, enforcing it, reviewing access on schedule, and keeping the evidence is work only your organization can do — and it is exactly what turns the document into a control.

Frequently asked questions

What is the difference between an Access Control Policy and the Information Security Policy?

The Information Security Policy is the top-level, leadership-approved parent document that sets the overall direction of your security program. The Access Control Policy is a detailed sub-policy beneath it, focused specifically on who can access which systems and data and how that access is granted, changed, reviewed, and removed. The parent policy points to it; the Access Control Policy supplies the operational rules. In an ISO 27001 or SOC 2 program, the access policy is one of the most heavily tested of those sub-policies.

Which ISO 27001:2022 controls does an Access Control Policy support?

The core Annex A controls are A.5.15 Access control, A.5.16 Identity management, A.5.18 Access rights, A.8.2 Privileged access rights, A.8.3 Information access restriction, and A.8.5 Secure authentication. Several related topics map to adjacent controls you should cite correctly rather than fold in: separation of duties is A.5.3, credential and secret handling is A.5.17, and access-event logging is A.8.15. Mapping each rule to the right control is what your Statement of Applicability and internal audit will look for.

How does an Access Control Policy relate to SOC 2?

In SOC 2 it supports the Common Criteria series CC6, Logical and Physical Access Controls. The most relevant anchors are CC6.1 (securing logical access to protected assets), CC6.2 (registering and authorizing users before granting access), and CC6.3 (managing access by role and removing it when no longer appropriate). A licensed CPA firm tests these criteria against how your access actually works, not just what the policy says, so a clear policy-to-criteria mapping makes the examination far smoother.

How often should we run access reviews?

On a defined cadence, with quarterly reviews common for sensitive and privileged access and at least annual reviews for ordinary access. The cadence matters less than the evidence: each review should record who performed it, what was checked, and what access was removed. Privileged accounts warrant more frequent review because they carry the most risk. A claimed review with no dated record will not satisfy an ISO 27001 or SOC 2 auditor, since both test whether the practice actually happened.

Does an Access Control Policy template make us compliant or certified?

No. A well-built template gives you the structure, sensible default language, and the principles and account-lifecycle layout already in place, which is the slowest part to build from scratch, but it is a starting point you tailor rather than a shortcut. No document makes an organization compliant, certified, or attested. ISO certification comes from an accredited certification body, and a SOC 2 report from a licensed CPA firm, only after auditing controls that genuinely operate. The policy still has to reflect your reality, be enforced, drive scheduled access reviews, and produce evidence — work only your organization can do.

Related guides: ISO/IEC 27001 · SOC 2

Toolkits that help

← All articles