Access Control Policy Template (ISO/IEC 27001 A.5.15)

Access Control Policy: [Organization name]

Topic-specific policy that sets the rules for who may access which information and systems, how identities are created, changed and removed, how people and machines authenticate, and how access rights are granted, reviewed and revoked. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A controls A.5.15 to A.5.18 (access control rules, identity lifecycle, authentication information, access rights) and the related technological controls A.8.2 (privileged access), A.8.3 (restricting access to information) and A.8.5 (secure authentication), with guidance from ISO/IEC 27002:2022. Password and authenticator rules are aligned with NIST SP 800-63B-4 (July 2025). Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and authority
2. Roles and responsibilities
3. Access control principles
4. Access rules, role catalogue and approvals
5. Identity lifecycle: joiner, mover, leaver
6. Authentication standard
7. Privileged access
8. Access reviews
9. Service, shared and machine accounts
10. Third-party and support access
11. Exceptions
12. Monitoring, metrics and enforcement
13. Size tiers
14. Records and evidence
15. References

1. Purpose, scope and authority

This policy makes sure that access to the information and systems of [Organization name] is granted only to identities that need it for an approved purpose, is limited to what that purpose requires, and is removed promptly when the need ends. It turns the access commitments in the information security policy (DOC-ISMS-001) into rules that the identity provider, the HR process and system owners can apply and that an auditor can test.

The policy applies to:

• every workforce identity: employees, contractors, temporary staff, interns and board members with system access;
• every non-human identity: service accounts, workload identities, API keys, bots and automation accounts;
• every third-party identity: suppliers, partners, auditors and customer staff given access to internal systems;
• every system in the ISMS scope (DOC-ISMS-002): identity provider, productivity suite, cloud consoles, production platforms, source code repositories, databases, network devices, OT systems where in scope, physical access systems that share the identity store.

Where a system cannot meet a rule, the gap is recorded as an exception (section 11) and, if it creates a risk above the acceptance threshold, in the risk register (DOC-ISMS-016). This policy is mandatory; breaches are handled under the disciplinary process for security breaches (isms/security-disciplinary-process, DOC-ISMS-052).

2. Roles and responsibilities

Segregation of duties (A.5.3) applies to access management itself: the person who requests access does not approve it, and the person who provisions access does not approve it for themselves. Administrators of the identity provider are reviewed by someone outside that team.

3. Access control principles

4. Access rules, role catalogue and approvals

4.1 Role catalogue

Each in-scope system has roles recorded in the role catalogue, owned by the system owner and stored in [identity governance tool / controlled spreadsheet / CMDB]. A role entry gives the role name, the entitlements it contains, the highest classification it can reach, the approver, the review cadence and any segregation of duties conflicts.

4.2 Access rules

4.3 Request and approval flow

Every request follows the same path, whether it arrives through the identity governance tool or the ticketing tool. The diagram shows the approvals added for Restricted data and for segregation of duties conflicts (ACC-RULE-003 and ACC-RULE-007). A request that involves Restricted data and a segregation of duties conflict needs both the information owner approval and the recorded compensating control before provisioning.

5. Identity lifecycle: joiner, mover, leaver

5.1 Lifecycle stages

Each identity moves through the states below. HR or procurement events trigger every transition except role-based requests, which follow section 4.3. Dormant accounts (section 5.2) are disabled by an automated job and handled as a leaver if the manager confirms no further need.

5.2 Service levels

5.3 Lifecycle rules

• HR is the trigger for workforce identities; procurement or the sponsoring manager is the trigger for contractors. IT does not create identities from e-mail requests alone.
• Every contractor identity has an end date, a sponsor and a naming convention that marks it as external (for example ext- prefix).
• Movers keep no access from the old role by default. A manager who needs a transition period requests a time-bound exception.
• Leavers' mailbox and files are handled by the manager as set out in the offboarding checklist (DOC-ISMS-053); the identity itself is never reassigned to another person.
• Systems without automated provisioning are listed in the role catalogue with a manual deprovisioning owner, and the monthly reconciliation (section 8) compares their user list with HR.

6. Authentication standard

6.1 Authenticators by access type

SMS and voice one-time codes are restricted: they may be used only as a recovery method for standard users when no other authenticator is available, never for privileged access. NIST SP 800-63B-4 treats authentication over the public telephone network as restricted, which supports this rule.

6.2 Password rules

Where passwords remain, the identity provider enforces these rules, aligned with NIST SP 800-63B-4 section 3.1.1.2:

• minimum length of 15 characters for a password used as a single factor, and at least 8 characters where the password is only one part of MFA (this policy sets [12] characters for that case);
• a maximum length of at least 64 characters, with spaces and all printable characters allowed;
• no composition rules (no forced mix of character types);
• no periodic forced changes; a change is forced when there is evidence or suspicion of compromise;
• every new password is checked against a list of common, expected and known-compromised values, and rejected with an explanation;
• no password hints and no knowledge-based security questions;
• passwords are stored by systems only as salted hashes with an approved algorithm (security/cryptography-standard).

Staff use the company password manager for every password that is not covered by single sign-on. Reuse of a work password on any other service is prohibited by the acceptable use policy (DOC-ISMS-040).

6.3 Issuing, resetting and revoking authenticators

7. Privileged access

Privileged access is any access that can change security settings, other users' rights, production systems or large volumes of data. It is governed by the privileged access standard (security/privileged-access-standard). The minimum rules are:

• administrators use a separate privileged identity, never their daily account, and phishing-resistant MFA;
• Tier 0 privileges (control of the identity provider, cloud tenant root or organisation level, key management and the security tooling itself) and Tier 1 privileges (administration of production systems, servers and databases) are granted just in time for a limited duration and removed automatically; standing privilege needs an exception. The tier model is defined in security/privileged-access-standard;
• emergency (break-glass) accounts exist for the identity provider and each cloud tenant, are excluded from conditional access only as far as necessary, are monitored, and every use is reviewed within [1 working day];
• privileged sessions on production are logged and, for Restricted systems, recorded (security/security-logging-standard);
• the number of global administrators is kept to [2 to 4] per tenant;
• privileged roles are reviewed at least quarterly (section 8).

8. Access reviews

Access reviews follow the procedure in ops/access-review. Each review campaign records the population source, the reviewer, decisions and the verification that removals were done.

Review rules:

• reviewers see each identity with its roles, last sign-in and job title, and decide keep, change or remove for each entitlement;
• removals are completed within [5 working days] and verified by a re-export of the user list;
• a reviewer may not review their own access;
• a campaign not completed within [15 working days] is escalated to the ISMS manager and reported to the steering committee.

9. Service, shared and machine accounts

10. Third-party and support access

• Third-party identities are created only for suppliers listed in the supplier register (isms/supplier-register, DOC-ISMS-066) with a signed agreement that contains security and confidentiality terms (isms/supplier-security-agreement-27036, DOC-ISMS-068).
• Each external identity has an internal sponsor, an end date no later than the contract end and the narrowest role that supports the task.
• Vendor remote support sessions are opened on request for a set window, supervised or recorded for production systems, and closed afterwards.
• Federated access from a partner's identity provider is allowed only when the partner enforces MFA and notifies leavers within [1 working day] under the agreement.
• Staff access to customer environments or customer data for support is granted per ticket, time-bound and logged, and the customer is told where contracts require it (isms/customer-security-addendum).

11. Exceptions

Any deviation from this policy (for example a legacy system without MFA, a standing admin right or a shared account) is requested with the security exception request (security/security-exception-request, DOC-ISMS-122). Each exception states the rule, the reason, the risk, compensating controls, the approver and an expiry date. It is approved at the authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner for Low; the risk owner and department head for Medium (top management if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top management with a treatment decision for High, recorded in the risk acceptance record (DOC-ISMS-019). Critical residual risk is not approvable as an exception: treat it or stop the activity. Maximum duration is 12 months for Low or Medium and 6 months for High; at expiry the exception is reassessed, and a renewal is a new decision (DOC-ISMS-122 section 7).

12. Monitoring, metrics and enforcement

The security team monitors sign-in anomalies, privileged role changes, break-glass use and failed MFA patterns through the logging and monitoring process (isms/security-monitoring-procedure). The following metrics are reported [monthly] to the ISMS manager and [quarterly] to the steering committee.

The example results describe one quarter at Quillmere Analytics Ltd (46 staff). Breaches of this policy are investigated by the security team and handled through the disciplinary process (DOC-ISMS-052); repeated control failures are raised as nonconformities (compliance/capa-nonconformity, DOC-ISMS-087).

13. Size tiers

14. Records and evidence

15. References

Related templates: compliance/information-security-policy (DOC-ISMS-001), compliance/statement-of-applicability (DOC-ISMS-011), compliance/acceptable-use-policy (DOC-ISMS-040), isms/offboarding-security-checklist (DOC-ISMS-053), isms/control-evidence-matrix (DOC-ISMS-033), security/privileged-access-standard, ops/access-review, ops/onboarding-checklist, security/secrets-management-standard, security/zero-trust-architecture, data/data-classification-policy, security/security-exception-request (DOC-ISMS-122).

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024, Annex A controls A.5.15 to A.5.18, A.8.2, A.8.3 and A.8.5, with guidance from ISO/IEC 27002:2022. The policy text, rule IDs, examples and guidance are original wording; ISO/IEC text is not reproduced, and the short control labels are descriptions written for this library, not official titles. ISO and IEC standards are copyrighted: obtain the official standards from ISO (https://www.iso.org/standard/82875.html) or your national standards body. Password and authenticator rules summarise NIST SP 800-63B-4 (public domain US government work) in original words. Check the current editions of all referenced standards before use. This is a documentation format, not certification advice. Template licence: MIT.