.svg){kind=logo}
A contractor’s contract ended six months ago. Their account is still active. They still have read access to production databases.
If that scenario sounds familiar, or if you’re not completely sure it hasn’t happened at your company, you need an access control policy.
An access control policy is a formal document that defines who is authorised to access your organisation’s systems, data, and resources, under what conditions, and how that access is managed across the full employee and contractor lifecycle. It covers how access is requested and approved, who owns the process, how it gets revoked when someone leaves, and what gets reviewed on an ongoing basis. It’s the written foundation that your technical controls enforce.
Without it, access decisions happen informally, inconsistently, and often in ways nobody remembers. With it, you have a clear standard to measure against, evidence to show auditors, and a process that doesn’t depend on whoever happens to be paying attention that day.
Frameworks that require or expect an access control policy:
- SOC 2 (CC6.1, CC6.2, CC6.3)
- ISO 27001 (Annex A 5.15)
- NIST SP 800-53 (AC-1 through AC-25)
- HIPAA (§164.312(a))
- PCI DSS (Requirement 7)
By the end of this guide, you’ll know exactly what to put in your access control policy, how to implement it, and what evidence auditors will actually ask for.
Here’s what I’ll cover:
- What an access control policy is (and the different access control models)
- Who needs one and why it has to be written down
- A complete, free inline template drawn from real compliance programmes
- Step-by-step implementation guide
- Framework mapping for SOC 2, ISO 27001, NIST, HIPAA, and PCI DSS
- What auditors look for in the evidence
Free Template
Download the Access Control Policy Template (PDF)
Pre-built and aligned to SOC 2 CC6.1–CC6.3, ISO 27001 A.5.15, and HIPAA. Ready to customise and distribute.
What Is an Access Control Policy?
Most companies have access controls. Very few have an access control policy.
The distinction matters. Access controls are the technical mechanisms: permissions, roles, MFA settings, IAM configurations. An access control policy is the document that defines the rules those mechanisms enforce. It answers the questions your controls can’t: why this access exists, who approved it, when it gets reviewed, and what happens when someone breaks the rules.
A complete access control policy covers:
- The scope of systems and users it applies to
- The principles that govern access decisions (least privilege, need-to-know, default deny)
- The process for requesting, approving, and revoking access
- Roles and responsibilities: who owns what
- Authentication requirements including MFA
- Review cadence: how often access entitlements are checked
- Exceptions and enforcement
Role Based Access Control Policy: The Most Common Starting Point
Most organisations start with RBAC (role-based access control), and that’s the right call. In a role based access control policy, permissions are mapped to job roles rather than to individuals. Engineering gets one set of permissions. Finance gets another. Admin gets a third. When someone’s role changes, their access changes with it, not whenever someone gets around to updating it manually.
RBAC is easy to implement in any modern identity provider (Okta, Google Workspace, Microsoft Entra ID) and straightforward to audit. You can pull a report showing every role and every person assigned to it. That’s exactly what access reviews need.
Policy based access control (PBAC) goes further: instead of fixed role assignments, access decisions are evaluated against a set of rules that can factor in multiple attributes at once, like department, location, device posture, or time of day. Most early-stage companies should start with RBAC and layer in policy-based rules as their environment matures.
Attribute Based Access Control Policy and Policy Based Access Control Models
Between RBAC and full PBAC sits ABAC (attribute-based access control). An attribute based access control policy grants or denies access based on user attributes rather than a predefined role, making it more flexible than RBAC but simpler to maintain than full policy based access control.
Here’s how the three models compare:
| Access control model | How access is determined | Best suited for | Complexity |
|---|---|---|---|
| RBAC (role-based) | Job role | Startups and SMBs | Low |
| ABAC (attribute-based) | User attributes and conditions | Mid-sized orgs, remote-heavy teams | Medium |
| PBAC (policy-based) | Combined rule evaluation | Enterprise, regulated industries | High |
Most organisations start with RBAC, extend to ABAC as they grow, and reach PBAC when the environment is complex enough to warrant it.
Logical Access Control Policy vs Physical Access Control
An important scoping question: what does your access control policy actually cover?
A logical access control policy governs digital access: user accounts, SSO, MFA settings, application permissions, database roles, API keys, cloud IAM configurations. This is what most IT and infosec teams mean when they talk about access control.
Physical access controls (badge entry, server room logs, visitor management) are a separate concern, typically governed by a physical security policy. Your access control policy should explicitly state it covers logical access only, and reference your physical security policy for building and hardware access. Some frameworks (ISO 27001 Annex A 7.2) require both to be addressed, so having a clear boundary between the two policies makes that mapping straightforward.
Who Owns the IT Access Control Policy?
Ownership varies by company size, but the pattern is consistent:
- Policy owner: CISO, IT Security Manager, or at early-stage startups, the CTO or Head of Engineering
- Technical enforcement: IT or DevOps team (IdP configuration, cloud IAM, access request workflows)
- Access approvals: Team leads and system owners (they approve who gets into their systems)
- Compliance and evidence: Security team or dedicated compliance lead
The IT access control policy needs a named owner. Not a team, not a department. A specific person whose job it is to keep the policy current, run reviews, and make sure evidence is collected. Without that, the policy gets written once and never touched again.
Why Access Control Has to Be Policy-Driven
An engineer leaves on Friday. HR sends the offboarding checklist. IT removes their laptop from MDM. Three months later, during a security review, someone notices the former engineer still has read access to the production database via an old personal access token that was never revoked.
Free Demo
ComplyJet builds your access control policy and tracks the evidence auditors require
Aligned to SOC 2 CC6.1–CC6.3, ISO 27001 A.5.15, HIPAA, and PCI DSS. Ready in hours.
This is the most common access control failure I’ve seen, and it’s almost never a technical problem. The tools can revoke access automatically. The problem is that nobody wrote down the rule, nobody owns the process, and nobody checks.
From a security standpoint: over-privileged accounts are one of the most consistent attack vectors in data breaches. According to the Verizon Data Breach Investigations Report, stolen credentials are the leading method of initial access year after year. When accounts accumulate permissions over time and nobody ever prunes them, you’re building a blast radius far larger than you need. Least privilege only works if it’s enforced consistently, and consistent enforcement requires a written standard.
From a compliance standpoint: every major framework requires documented access control rules. SOC 2 auditors will ask for your policy on day one. ISO 27001 auditors map their controls directly to it. HIPAA makes it a technical safeguard requirement. “We manage access informally” is not a valid audit response.
From an operational standpoint: without a policy, every access decision is a judgement call. How long can a contractor keep access after their project ends? Who approves access to the production database? What’s the SLA for revoking access when someone is terminated? These questions have real answers. Writing them down means new IT staff, new managers, and new contractors all follow the same rules.
Does Your Company Need a Formal Access Control Policy?
Short answer: if you use software, store data, and have more than one person with system access, yes.
Why it matters
Even if none of those apply, access sprawl is a real problem. Stale accounts, over-permissioned users, and undocumented access decisions create risk regardless of your compliance posture.
You specifically need one if you are:
- Pursuing SOC 2 (CC6.1, CC6.2, CC6.3 make up a significant chunk of the Common Criteria, and access control is one of the first things auditors check)
- Working toward ISO 27001 certification (Annex A 5.15 is a required control, not optional)
- A healthcare vendor or covered entity subject to HIPAA (§164.312(a) mandates access controls as a technical safeguard)
- Subject to PCI DSS (Requirement 7 requires documented access control with least-privilege enforcement)
- Selling into enterprise accounts (security questionnaires almost universally include “do you have a documented access control policy?”)
Even if none of those apply, access sprawl is a real problem. Stale accounts, over-permissioned users, and undocumented access decisions create risk regardless of your compliance posture.
When to write it: before your first SOC 2 audit window, before onboarding your first enterprise customer, before you scale past roughly ten employees, after which manual memory-based access management stops being reliable.
What to Cover in Your Access Control Policy
A solid access control policy has thirteen core sections. Here’s what each one needs to include:
| Policy section | What to include |
|---|---|
| Purpose | Why the policy exists: limiting access to authorised parties in accordance with business and security objectives |
| Scope | Which systems, environments, and users are covered (cloud infrastructure, SaaS apps, databases, networks, third-party integrations) |
| Definitions | Least privilege, need-to-know, RBAC, privileged access, MFA, service account |
| Access control principles | Least privilege, need-to-know, separation of duties, default deny |
| Roles and responsibilities | Policy owner, IT/DevOps, team leads/system owners, all employees and contractors |
| Access provisioning | How access is requested, approved, and implemented, including documentation requirements |
| Access reviews | Frequency (quarterly recommended), who conducts them, what gets reviewed, what happens with findings |
| Access revocation | Offboarding timelines, contractor expiry, role-change procedures |
| Authentication requirements | MFA requirements, password standards, session controls |
| Privileged access | Separate rules for admin and root accounts (often references a PAM policy) |
| Exceptions | How exceptions are requested, approved, time-bounded, and tracked |
| Enforcement | What constitutes a violation and what the consequences are |
| Review cadence | Annual minimum, plus triggers for out-of-cycle reviews |
Access Control Policy and Procedures: What’s the Difference?
The access control policy and procedures often get conflated, but they serve different purposes and should live in separate documents.
The policy is the what and why: the rules, principles, and standards. It gets approved by leadership, changes infrequently, and requires a formal review process.
The procedures are the how: step-by-step operational guides (how to submit an access request, how to run a quarterly access review, the IT offboarding checklist). These can be updated by IT or operations without a full policy review cycle.
NIST SP 800-53 AC-1 explicitly requires both: a policy document AND procedures to implement it. Keeping them separate makes both easier to maintain and easier to audit.
User Access Control Policy: Managing Individual Permissions
A user access control policy defines how individual user access is managed across three moments in the employment lifecycle.
Onboarding: access is provisioned based on the user’s role, with only the minimum permissions required to do the job. No access should be granted before the start date or before HR onboarding is complete.
In-employment: when a user changes roles or teams, their previous access gets removed and new access is provisioned based on their new role. This doesn’t happen automatically in most systems unless you build the workflow for it.
Offboarding: all access is revoked within a defined time window (24 hours is common for immediate terminations; one business day for standard departures). The policy should specify this SLA explicitly.
Avoid shared accounts and service accounts without named owners. Both create audit problems that are hard to explain.
Data Access Control Policy Considerations
A data access control policy should follow your data classification levels. If you don’t have a data classification policy, that’s worth adding to your list, because access control decisions for sensitive data need a classification framework to sit on.
Typical tiering:
- Confidential or restricted data (customer PII, health records, payment data): access limited to specific named roles, logged, reviewed quarterly
- Internal data (financial reports, personnel records): access limited to relevant departments, reviewed annually
- Public data: no access restrictions
For databases: direct database access should be restricted to DBAs and senior engineers. Application access runs through service credentials with least-privilege permissions. Production database access should require explicit approval and be logged.
Network Access Control Policy: Defining Your Scope
Network access often gets left out of the main access control policy or treated as a separate concern entirely. That’s fine if you have a dedicated network security policy, but your access control policy should at minimum define the boundary.
A network access control policy typically covers: who requires VPN access and on what terms, how MFA is enforced at the network layer, how production and non-production environments are segmented, and how remote access is authenticated and monitored. Reference your network security policy and remote access policy for the detailed rules.
Access Control Policy Template (Free PDF Download)
Access Control Policy Example: What a Real Policy Looks Like
The template below is the kind of access control policy example that comes out of a real compliance programme. It’s not a skeleton. It’s pre-filled with best-practice content you can use immediately, with placeholders only where your specific values belong.
This is drawn from the policy template we use in ComplyJet, aligned to SOC 2 CC6.1-CC6.3 and ISO 27001 Annex A 5.15.
Access Control Policy PDF: Download the Free Template
Download the access control policy PDF or Word version using the button below. The access control policy pdf includes all sections from the inline template, pre-formatted for immediate use.
Free Template
Download the Access Control Policy Template (PDF)
Pre-built and aligned to SOC 2 CC6.1–CC6.3, ISO 27001 A.5.15, and HIPAA. Ready to customise and distribute.
Access Control Policy
Policy Owner: [Name, Title] Effective Date: [Date] Review Date: [Date + 1 year] Version: 1.0
1. Purpose
To limit access to information and information processing systems, networks, and facilities to authorised parties in accordance with business objectives.
2. Scope
This policy applies to all [Company Name] information systems that process, store, or transmit confidential data. It covers all employees, contractors, consultants, temporary workers, and third-party vendors with access to [Company Name] systems or networks.
| System type | Examples | In scope |
|---|---|---|
| Cloud infrastructure | AWS, GCP, Azure | Yes |
| SaaS applications | Google Workspace, Okta, Slack, GitHub | Yes |
| Production databases | PostgreSQL, MySQL, MongoDB | Yes |
| Internal networks and VPN | Corporate network, VPN gateway | Yes |
| Third-party integrations | APIs, webhooks, external service accounts | Yes |
| Physical access systems | Badge readers, server rooms | No (see Physical Security Policy) |
3. Definitions
| Term | Definition |
|---|---|
| Least privilege | Users are granted only the minimum access required to perform their job function |
| Need-to-know | Access to information is restricted to those with a documented business need |
| RBAC | Role-based access control: permissions assigned to job roles, not individuals |
| Privileged access | Administrative or elevated access to systems, infrastructure, or data |
| MFA | Multi-factor authentication: verification using two or more independent factors |
| Service account | A non-human account used by applications or automated processes |
4. Access Control Principles
[Company Name] applies the following principles to all access decisions:
- Least privilege: Default to the minimum required access. Elevate only when justified and approved by a system owner. Permissions not expressly granted are, by default, prohibited.
- Need-to-know: Access to sensitive data is granted only where there is a documented business need.
- Separation of duties: No single individual should be able to initiate, approve, and complete a sensitive transaction. Where full separation is not feasible, compensating controls (logging, peer review) must be in place.
- Default deny: Access is denied unless explicitly granted.
5. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Policy Owner ([CISO / CTO / IT Manager]) | Maintain and update this policy; ensure enforcement; own the access review programme |
| IT / DevOps team | Implement access controls technically; execute provisioning and revocation; maintain IdP configuration |
| Team leads / system owners | Approve access requests for their systems and teams; notify IT promptly of role changes |
| HR | Trigger onboarding and offboarding workflows; maintain employment status records |
| All employees and contractors | Request access through approved channels; protect credentials; report anomalies immediately |
6. Access Control Policy and Access Model
[Company Name] determines the type and level of access granted to each user based on the principle of least privilege. The primary access model is Role-Based Access Control (RBAC). Wherever feasible, rights and restrictions are allocated to roles rather than individuals. Individual users may be granted additional permissions beyond their role only with approval from the relevant system owner or management.
All privileged access to production infrastructure requires Multi-Factor Authentication (MFA).
7. Access to Networks and Network Services
- Technical access to [Company Name] networks must be formally documented, including the role or approver, grantor, and date
- Only authorised employees and third parties working under a signed contract with a documented business need may access production networks and resources
- Remote connections to production systems must be encrypted and require MFA
- Guest network access may be granted to visitors after registration with office staff, without a formal request
8. Customer Access Management
Where [Company Name] requires programmatic or administrative access to a customer’s environment to deliver contracted services, access must be established as follows:
- Use the cloud provider’s native cross-tenant mechanism (assumed role, service principal, or equivalent). No shared credentials or long-lived keys.
- [Company Name] creates a unique identifier per customer. Customers must not supply or modify this value.
- The delegated role must grant only the permissions necessary for the agreed-upon service. Anything not required is denied by default.
- At contract end or written request, [Company Name] revokes all delegated access within [Revocation SLA] business hours.
9. User Registration and Deregistration
- Only authorised IT administrators may create new user accounts, and only upon receipt of a documented request from an authorised party
- Provisioning requests must include approval from data owners or management authorised to grant system access
- No access may be provisioned earlier than the official employee start date
- User accounts must be promptly disabled or removed when users leave the organisation or contract work ends, within the SLA in Section 11
- User IDs must not be re-used
10. User Access Provisioning
New employees and contractors may not be granted access to [Company Name] production systems until after completing all HR onboarding requirements (signed employment agreement, IP agreement, acknowledgement of information security policies).
All access requests and rights modifications must be documented in an access request ticket. No permissions may be granted without approval from the system owner or management. Records of all access changes must be retained for no less than one year.
11. Access Revocation
| Trigger | Maximum revocation SLA |
|---|---|
| Employee termination (voluntary or involuntary) | [24 hours / 1 business day] |
| Contractor offboarding | On or before the last day of contract |
| Role change (internal) | [2 business days] for revocation of previous role’s access |
| Security incident (suspected compromise) | Immediate |
12. Management of Privileged Access
Privileged access rights must be restricted, managed, and monitored. [Company Name] will ensure privileged access conforms to the following standards:
- Privileged accounts are issued individually. No shared admin credentials.
- Privileged sessions are logged and subject to regular review
- Just-in-time (JIT) access is preferred where the platform supports it: grant elevated access for the minimum duration needed, then revoke automatically
- No single person holds both the ability to provision access and to audit it
- Shared administrative accounts may be used for business continuity purposes only, managed via an approved password manager, and reviewed quarterly
See the [Privileged Access Management Policy] for detailed rules on admin and root account management.
13. User Access Reviews
IT administrators must perform access rights reviews on a [quarterly] basis to verify that user access is limited to systems required for the user’s current job function. All access reviews must be documented.
Access reviews must also be triggered:
- When a user changes role, team, or reporting line
- When a user goes on extended leave
- After a security incident involving credential compromise
14. Segregation of Duties
Conflicting duties and responsibilities must be separated to reduce the risk of unauthorised or unintentional modification of [Company Name] assets. When provisioning access, care must be taken that no single person can access, modify, and approve a transaction without detection. The possibility of collusion must be considered when designing access levels for individuals and teams.
15. Authentication Requirements
MFA is required for all of the following:
- All cloud infrastructure consoles and APIs
- Email and SSO provider (Google Workspace, Okta, Entra ID)
- VPN and remote access systems
- Any application that holds customer data, PII, or payment information
- All privileged accounts
Password requirements are defined in the [Password Policy]. Shared accounts are prohibited. Service accounts must have a named owner and be reviewed quarterly.
16. System and Application Access
Applications must restrict access to authorised users in accordance with this policy. Prior to implementation, systems must be evaluated for:
- Data sensitivity and classification
- Risk to the organisation of unauthorised access or disclosure
- Ability to control user access rights within the application
- Logging and auditing capability
All unnecessary default accounts must be removed or disabled before a system goes into production. Vendor default passwords and credentials must be changed before deployment. Access to program source code must be restricted to authorised personnel based on business need, and logged for audit purposes.
17. Exceptions
Requests for an exception to this policy must be submitted in writing to [Policy Owner]. All exceptions must:
- Include the reason for the exception and the specific requirement being waived
- Specify an alternative control that mitigates the risk
- Include an expiry date (maximum [30/60/90] days)
- Be approved by [CISO / CTO / relevant executive]
- Be logged in the exceptions register
Exceptions are reviewed as part of the annual policy review.
18. Violations and Enforcement
Violations of this policy include but are not limited to: accessing systems without authorisation, sharing credentials, granting access outside the approved provisioning process, and failing to report a suspected account compromise.
Known violations must be reported to [security@company.com]. Violations may result in immediate suspension of access, disciplinary action up to and including termination of employment, and legal action where applicable.
19. Review Cadence
This policy is reviewed annually. Out-of-cycle reviews are triggered by:
- A significant change to systems or infrastructure
- A change in regulatory or compliance requirements
- A security incident involving access control failures
- A significant change in organisational size or structure
20. Version History
| Version | Date | Author | Summary of changes |
|---|---|---|---|
| 1.0 | [Date] | [Author] | Initial version |
How to Write and Roll Out an Access Control Policy
Writing the policy is the easier half. Getting it implemented and generating evidence is where most companies underinvest.
Free Demo
ComplyJet handles policy drafting, approval workflows, and access review evidence
Pre-mapped to SOC 2, ISO 27001, HIPAA, and PCI DSS. Quarterly review reminders built in.
Here’s the full process:
Assign an owner. Name a specific person, not a team. For most early-stage companies, this is the CTO or Head of Engineering until a security hire is made.
Inventory your systems. List every system, application, and data store that requires access controls. Be thorough: cloud consoles, SaaS apps, internal tools, databases, CI/CD pipelines, third-party integrations. This becomes your scope section.
Map your roles. For each system, define who needs access and at what level. Three to five roles covering most of your team is fine to start. Don’t over-engineer the model before you have the people to maintain it.
Customise the template. Fill in the placeholders: owner name, revocation SLAs, review frequency, MFA scope, exception thresholds. The policy should reflect what you actually do (or intend to do), not what you think auditors want to see.
Get leadership sign-off. The policy needs formal approval from a senior stakeholder. For startups, that’s the CEO or CTO. Without this, the policy has no organisational authority.
Distribute and collect acknowledgements. Send the policy to all relevant staff and collect acknowledgements. “Sent it by email” is not enough for most audits. Use a tool that tracks who has read and confirmed receipt.
Implement the technical controls. Configure your IdP to match the policy: enforce MFA, set up role-based groups, build the access request workflow, configure session timeouts.
Run a baseline access review. Before the first formal quarterly review, audit all existing access against the policy. Revoke anything not justified. Document what you found and what you fixed.
Set up ongoing reviews. Schedule quarterly access reviews as a recurring calendar event with a named owner. Keep the records.
Map to compliance controls. In your GRC tool, link the policy to the relevant controls: SOC 2 CC6.1-CC6.3, ISO 27001 Annex A 5.15, HIPAA §164.312(a), PCI DSS Requirement 7.
Collect and retain evidence. Provisioning tickets, offboarding checklists, access review logs, acknowledgement records. Keep them somewhere retrievable. You will need them.
On how to implement policy based access control in practice: start with RBAC in your IdP, enforce MFA across all systems, run quarterly access reviews. Once that’s running cleanly, add attribute-based conditions (device posture, location, department) to handle more complex access scenarios.
Access Control Policy: SOC 2, ISO 27001, NIST, and HIPAA
Access control is one of the most consistently required areas across every major security framework. Here’s how your policy maps to each:
| Framework | Control | What it requires | Key evidence |
|---|---|---|---|
| SOC 2 | CC6.1, CC6.2, CC6.3 | Logical access restricted, least privilege enforced, provisioning and revocation process documented | Signed policy, quarterly access review logs, provisioning and offboarding tickets |
| ISO 27001 | Annex A 5.15 | Access control rules defined; access provisioned based on business need and least privilege | Policy document, access review records |
| NIST SP 800-53 | AC-1 through AC-25 | Policy and procedures documented; least privilege enforced; access reviewed regularly | Policy, procedures, review logs, system configuration evidence |
| HIPAA | §164.312(a) | Unique user IDs; emergency access procedure; automatic logoff; audit controls | User access logs, MFA configuration, audit logs |
| PCI DSS | Requirement 7 | Access to cardholder data restricted to need-to-know; roles documented; least privilege enforced | Access policy, role matrix, quarterly access review |
NIST Access Control Policy Example and Requirements (SP 800-53)
NIST SP 800-53 has the most detailed access control requirements of any commonly referenced framework. The AC (Access Control) family covers 25 controls, from AC-1 (the policy document itself) through to AC-25 (reference monitor).
For most organisations, the critical controls are:
- AC-1: Requires both a formal access control policy document and procedures to implement it. Both must exist. The policy alone is not enough.
- AC-2: Account management: how accounts are created, managed, reviewed, disabled, and removed.
- AC-3: Access enforcement: technical controls that implement the policy rules.
- AC-5: Separation of duties.
- AC-6: Least privilege. The most commonly cited control in audit findings.
- AC-17: Remote access: encryption, MFA, and monitoring requirements.
A NIST access control policy example for AC-6: “Access to [system] is restricted to users whose current role requires it. Administrative access is issued individually, with elevated permissions granted on a time-bound basis only. Quarterly access reviews verify ongoing compliance with this rule.”
Government contractors and FedRAMP-authorised organisations must address all AC controls. For everyone else, AC-1, AC-2, AC-3, AC-5, AC-6, and AC-17 cover the baseline.
Access Control Policy ISO 27001: What Annex A 5.15 Requires
The ISO 27001 access control policy requirement is set out in Annex A 5.15: “Rules to control physical and logical access to information and other associated assets shall be established and implemented based on business and information security requirements.”
What that means in practice:
- A documented policy must exist. Verbal rules don’t count.
- Access must be provisioned based on need-to-know and least privilege.
- Privileged access must be managed separately (Annex A 5.18).
- Access must be reviewed regularly.
- User responsibilities around access (protecting credentials, reporting anomalies) must be communicated (Annex A 6.3).
ISO 27001 auditors look at the policy document, evidence of access reviews, privileged access logs, and how the organisation communicates access control requirements to staff.
ISO 27001 Access Control Policy Template Requirements
When using an ISO 27001 access control policy template, the key step after writing the document is control mapping: annotating each section with the relevant Annex A control so auditors can trace the policy directly to the certification requirements.
| Policy section | ISO 27001 control |
|---|---|
| Access principles and provisioning | A.5.15 (access control policy) |
| User registration and deregistration | A.5.16 (identity management) |
| Authentication requirements | A.5.17 (authentication information) |
| Privileged access management | A.5.18 (access rights) |
| Review and revocation | A.5.18 (access rights) |
| User responsibilities | A.6.3 (information security awareness) |
SOC 2 and PCI DSS Access Control Obligations
SOC 2: CC6.1, CC6.2, and CC6.3 are mandatory Common Criteria. No discretion. Auditors will ask for the policy, provisioning records, access reviews, and offboarding evidence. SOC 2 Type II auditors look for evidence that access reviews happened throughout the audit period, not just in the weeks before the window closes.
PCI DSS: Requirement 7 requires that access to system components and cardholder data be limited to need-to-know. A formal access control policy is required. Roles must be documented. Least privilege must be enforced. Quarterly access reviews covering cardholder data environments are standard.
HIPAA Access Control Requirements
HIPAA §164.312(a)(1) is a technical safeguard requirement: covered entities and business associates must implement technical policies and procedures that allow access to ePHI only to those granted access rights.
The four implementation specifications:
- Unique user identification (required): every user must have a unique identifier. Shared credentials are not permitted.
- Emergency access procedure (required): a defined process for granting access to ePHI in an emergency (break-glass accounts with elevated logging).
- Automatic logoff (addressable): session timeouts on systems handling ePHI.
- Encryption and decryption (addressable): mechanisms for encrypting and decrypting ePHI.
HIPAA doesn’t prescribe a specific access control model. RBAC is the most common compliant approach for healthcare vendors and business associates.
What Auditors Look for in Your Access Control Policy
Auditors don’t just want to see the policy document. They want to see that you actually run it.
Here are the records you need to maintain:
| Record type | What it proves | How to produce it |
|---|---|---|
| Signed access control policy (current version) | Policy exists, is approved, and is in force | Policy document with owner name, approver signature, effective date, and version number |
| Quarterly access review logs | Reviews are being conducted; over-permissioned access is identified and remediated | Export from your IdP (Okta, Google Workspace, Entra ID) plus review sign-off record |
| Access provisioning tickets | Access is granted through an approved workflow, not informally | IT ticketing system (Jira, ServiceNow, Linear) with documented approval trail |
| Offboarding records | Access is revoked promptly when users leave | HR offboarding checklist plus IT account termination confirmation |
| MFA enforcement evidence | Authentication controls are active and enforced | IdP MFA policy screenshot or compliance report |
| Privileged access logs | Admin and root access is monitored | Cloud audit logs (AWS CloudTrail, GCP Audit Logs, Azure Monitor) |
| Exception register | Exceptions to the policy are tracked, time-bounded, and approved | Spreadsheet or GRC tool with open exceptions, approval dates, and expiry dates |
| Employee acknowledgement records | Staff have read and accepted the policy | Acknowledgement tracking log with timestamps and names |
The gap I see most often: provisioning and offboarding records. Companies run access reviews and have the policy, but they can’t show that each individual access grant was approved through a documented workflow. Auditors will spot this.
Where Access Control Goes Wrong: Mistakes to Avoid
These are the mistakes I see most consistently. None of them are obscure edge cases.
Watch out
SOC 2 Type II auditors look for evidence that reviews happened throughout the audit period. A single review before the window opens doesn’t satisfy this.
1. Access is never revoked after offboarding. The most common finding. An employee leaves, HR triggers the process, but IT’s checklist is incomplete: the production database access, the old API key, the third-party integration, all still active months later. The policy says 24 hours. The reality is different.
2. Everyone gets admin access “just in case.” At early-stage startups, it feels safer to give everyone elevated access so nobody gets blocked. In practice, this means the blast radius of any single compromised account is enormous, and cleaning it up before an audit means taking permissions away from people, which creates friction.
3. There’s no formal access request process. Access is granted via Slack message, with no ticket, no documented approval, and no record. Months later, when an auditor asks “can you show me the approval chain for this user’s database access?”, the honest answer is “it was in a DM.”
4. Access reviews are a one-time exercise. Done once before the audit, signed off, never repeated. SOC 2 Type II auditors look for evidence that reviews happened throughout the audit period. A single review before the window opens doesn’t satisfy this.
5. Infrastructure access is excluded. The policy covers Google Workspace, Jira, and Slack. AWS IAM roles, database permissions, GitHub repository access, and API keys are treated informally. These are exactly what auditors scrutinise hardest, because that’s where the most sensitive access lives.
6. Policy and procedures are the same document. One document tries to do both: define the rules and document the operational steps. The result is a policy that gets updated constantly with operational details, making version control messy and formal reviews harder to run.
Access Control Policy at Every Stage: Startup to Enterprise
The right access control programme looks different at ten people than it does at a thousand.
Quick tip
The policy itself can be two pages. It just needs a named owner, a clear scope, the key principles, and a revocation SLA. Get it signed and distributed before your first security questionnaire arrives.
Startups (1 to 30 employees)
Keep it simple. Three to five RBAC roles covering your whole team is fine: engineering, admin, read-only, billing, leadership. Don’t over-engineer the model before you have the people to maintain it.
Use Google Workspace or Okta from day one. Enable MFA immediately, for everyone, on everything. It’s significantly easier to enforce from the start than to retrofit later.
Access reviews: bi-annual is acceptable at this stage. Quarterly once you’re in a SOC 2 audit window.
The policy itself can be two pages. It just needs a named owner, a clear scope, the key principles, and a revocation SLA. Get it signed and distributed before your first security questionnaire arrives.
Growing Companies (30 to 150 employees)
Role proliferation is the biggest risk here. People get promoted, move teams, take on extra responsibilities, and their access accumulates. Before the team gets too large, standardise your roles in your IdP and commit to the model.
Introduce a formal access request workflow if you haven’t already. A ticket with a documented approval is much easier to defend than “we checked with the manager.”
Quarterly access reviews become non-negotiable at this stage. They’re also much less painful if you’ve kept the role model clean from the start.
Start mapping your access control policy to your compliance controls in a GRC tool. This is the stage where that investment pays off.
Enterprises (150 and above)
RBAC alone usually isn’t sufficient at enterprise scale. Move toward ABAC or full policy based access control to handle a large, distributed workforce with complex access requirements.
Just-in-time privileged access should replace standing admin access wherever possible. Tools like CyberArk, BeyondTrust, or cloud-native JIT mechanisms make this operationally manageable.
Access governance platforms (SailPoint, Saviynt) automate provisioning, access reviews, and certification campaigns at scale.
At this size, the access control evidence set is typically the largest of any compliance programme. Invest in automation early. Generating it manually at scale is genuinely unsustainable.
Keeping Your Access Control Policy Audit-Ready with ComplyJet
Writing the policy is one thing. Maintaining the evidence over a 12-month audit period is another.
ComplyJet gives you a pre-built access control policy template aligned to SOC 2 CC6.1-CC6.3 and ISO 27001 Annex A 5.15. You customise it in the product, get it approved through an in-platform workflow, and distribute it to your team for acknowledgement tracking, all in one place.
Control mapping is automatic: once the policy is in place, it’s linked to your SOC 2, ISO 27001, HIPAA, and PCI DSS controls. Quarterly access review reminders are built in. When the auditor asks for the evidence pack, you export it.
For companies going through their first SOC 2 or ISO 27001 audit, the access control section is consistently one of the heaviest evidence requirements. Getting the infrastructure right from the start makes that process significantly less stressful.
FAQs
Access control policy: what is it and what does it cover?
An access control policy is a formal document that defines who is authorised to access your organisation’s systems, data, and resources, under what conditions, and how that access is managed across the employee and contractor lifecycle. It covers access principles (least privilege, need-to-know), the provisioning and revocation process, authentication requirements, access review cadence, and enforcement. It’s the written standard that your technical controls are designed to enforce.
What is policy-based access control?
Policy based access control (PBAC) is a model where access decisions are governed by a set of written rules that evaluate multiple attributes simultaneously: user role, department, device posture, location, time of day. Unlike RBAC, where a fixed role determines access, PBAC can make context-sensitive decisions.
The same user might get full access from a managed device during business hours and read-only access from a personal device after hours. PBAC is more precise than RBAC, but also more complex to configure. Most organisations get there gradually, starting with RBAC and adding attribute-based conditions over time.
Why does access control have to be policy-driven?
Without a written policy, access decisions are made ad hoc. Over time, they accumulate in ways nobody tracks: extra permissions granted for a project and never removed, a contractor account left active after the engagement ends, a former employee still in the GitHub organisation six months later. These are governance failures, not technology failures. A policy creates the written standard that access decisions are measured against, and the evidence base that auditors require.
How do I create an access control policy?
Start with the template in Section 6. Assign an owner, define your scope, fill in your role model, and specify your key thresholds (review frequency, revocation SLA, MFA scope, exception approval process). Get it signed off by the relevant executive. Distribute it to staff and collect acknowledgements. Then implement the technical controls to match what the policy says. The full step-by-step process is in the implementation section above.
What is an example of an access control policy?
The complete inline template in Section 6 is a real example you can use immediately. It covers all 20 sections: purpose, scope, definitions, access principles, roles and responsibilities, access model, network access, customer access, user registration, provisioning, revocation, privileged access, segregation of duties, access reviews, authentication, system access, exceptions, enforcement, review cadence, and version history. It’s drawn from the template used in ComplyJet and is aligned to SOC 2 and ISO 27001.
How do I implement policy-based access control?
Start with RBAC in your identity provider. Assign roles, enforce MFA, and set up access request and revocation workflows. Run quarterly access reviews to validate the model is working. Once that’s running cleanly, add attribute-based conditions to handle more complex access scenarios: department-specific restrictions, device posture requirements, location-based rules. The jump to full policy based access control follows naturally from a mature RBAC foundation.
Which frameworks require an access control policy?
SOC 2 (CC6.1, CC6.2, CC6.3), ISO 27001 (Annex A 5.15), NIST SP 800-53 (AC-1), HIPAA (§164.312(a)), and PCI DSS (Requirement 7) all require or directly reference a documented access control policy. SOC 2 and ISO 27001 additionally require evidence of implementation, including access reviews, provisioning records, and acknowledgements. NIST AC-1 explicitly requires both the policy document and separate procedures.
How often should an access control policy be reviewed?
The policy document itself should be reviewed at minimum annually. Access reviews (checking who has access to what) should happen quarterly. SOC 2 Type II auditors verify that access reviews occurred throughout the audit period, not just in the weeks before the window closes. Out-of-cycle policy reviews are triggered by: a significant change to your systems or infrastructure, a new compliance requirement, a security incident involving access control failures, or a major change in organisational structure.
Related Policies
An access control policy doesn’t operate in isolation. These five policies work directly alongside it:
Remote Access Policy: Defines how employees and contractors access systems from outside the corporate network. Must align with your access control principles on MFA, session controls, and least privilege.
Data Classification Policy: Access decisions for sensitive data should follow your classification tiers. Classification determines what data is sensitive; the access control policy determines who can reach it.
