# 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 | Field | Value | |---|---| | Document ID | DOC-ISMS-041 | | Version | [1.0] | | Status | [Draft / In review / Approved / Superseded] | | Owner | [@isms-manager] | | Approvers/reviewers | [@ciso], [@head-of-it], [@hr-lead], [@internal-audit] | | Last updated | YYYY-MM-DD | | Classification | [Internal] | | Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, Annex A A.5.15 to A.5.18, A.8.2, A.8.3, A.8.5; guidance ISO/IEC 27002:2022; NIST SP 800-63B-4 (July 2025) | | Next scheduled review | YYYY-MM-DD (at least annually, and after a change of identity provider) | | Scope | [All workforce identities, contractors, service accounts and third parties accessing in-scope systems, as defined in DOC-ISMS-002] | | Identity provider of record | [Name of the identity provider or directory that is the source of truth] | | Authoritative HR source | [HR information system or contractor register that triggers lifecycle events] | | Related documents | DOC-ISMS-001, DOC-ISMS-011, DOC-ISMS-033, DOC-ISMS-040, DOC-ISMS-053, DOC-ISMS-122 | ### Approvals | Role | Name | Decision | Date | |---|---|---|---| | Policy owner | [@isms-manager] | [Prepared] | YYYY-MM-DD | | Head of IT or platform | [@head-of-it] | [Reviewed: rules are enforceable] | YYYY-MM-DD | | HR lead | [@hr-lead] | [Reviewed: lifecycle triggers agreed] | YYYY-MM-DD | | Top management | [@ceo] | [Approved] | YYYY-MM-DD | ### Revision history | Version | Date | Author | Change | |---|---|---|---| | 1.0 *(Example)* | YYYY-MM-DD | [@isms-manager] | First approved policy for the Stage 1 audit | | 1.1 *(Example)* | YYYY-MM-DD | [@isms-manager] | Phishing-resistant MFA made mandatory for all administrators (RISK-014) | ## 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 | Role | Responsibilities | |---|---| | Top management | Approves this policy; accepts residual access risks rated High or above | | ISMS manager (policy owner) | Maintains the policy, reports metrics to the steering committee, coordinates reviews | | System owner | Defines roles for the system, approves access requests, performs or signs off access reviews | | Information owner | Decides who may see a data set and at which classification level (`data/data-classification-policy`) | | Line manager | Requests access for direct reports, confirms the business need, triggers mover and leaver events on time | | HR (and procurement for contractors) | Records joiners, movers and leavers in the authoritative source on or before the effective date | | Identity and access team or IT | Operates the identity provider, provisions and deprovisions, maintains the role catalogue in tools | | Security team | Sets the authentication standard, monitors privileged activity and anomalies, runs exception reviews | | Internal audit | Tests the controls independently as part of the internal audit programme (DOC-ISMS-082) | | Every user | Protects authenticators, uses only granted access, reports suspected misuse (`isms/security-event-reporting-procedure`) | 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 | ID | Principle | What it means in practice | |---|---|---| | ACP-PRN-001 | Least privilege | Grant the minimum rights for the task, for the minimum time; elevated rights are time-bound (section 7) | | ACP-PRN-002 | Need to know | Access to information follows its classification and the owner's decision, not seniority or convenience | | ACP-PRN-003 | Default deny | Anything not explicitly granted is denied; new systems start with no access | | ACP-PRN-004 | Role-based first | Access is granted through roles from the catalogue; individual grants are exceptions with an expiry date | | ACP-PRN-005 | Segregation of duties | Conflicting duties (for example create supplier and approve payment, write code and deploy to production unreviewed) are split or compensated | | ACP-PRN-006 | One person, one identity | Every human has one named identity; shared accounts are prohibited except as in section 9 | | ACP-PRN-007 | Strong authentication | Every interactive login uses MFA; privileged and remote administrative access uses phishing-resistant MFA | | ACP-PRN-008 | Central identity | Systems connect to the identity provider through single sign-on and automated provisioning where the system supports it | | ACP-PRN-009 | Traceability | Every grant, change and removal has a request, an approval and a log entry that can be retrieved for audit | | ACP-PRN-010 | Context-aware access | Access decisions consider device health, location and risk signals where tools allow, in line with `security/zero-trust-architecture` | ## 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. | Role ID | System | Role | Entitlements | Highest class | Approver | Review | |---|---|---|---|---|---|---| | ROLE-001 *(Example)* | Productivity suite | Standard user | Mail, files, chat, calendar | Confidential (C2) | None: automatic from the HR record (ACC-RULE-001) | Semi-annual | | ROLE-014 *(Example)* | Production cloud | Read-only operator | View resources and logs, no data plane | Confidential (C2) | System owner | Quarterly | | ROLE-015 *(Example)* | Production cloud | Platform administrator | Full control, JIT only | Restricted (C3) | System owner plus security | Quarterly | | ROLE-022 *(Example)* | Analytics database | Customer data analyst | Query masked views only | Confidential (C2) | Information owner | Quarterly | | ROLE-030 *(Example)* | Finance system | Accounts payable approver | Approve payments | Confidential (C2) | Finance controller | Quarterly | | [ROLE-NNN] | [system] | [role] | [entitlements] | [class] | [approver] | [cadence] | ### 4.2 Access rules | Rule ID | Rule | |---|---| | ACC-RULE-001 | Birthright access (mail, collaboration, intranet, training platform) is granted automatically from the HR record on the start date and is the only access granted without a request | | ACC-RULE-002 | All other access is requested through [ticketing or identity governance tool], names a catalogue role and a business reason, and is approved by the approver in the catalogue | | ACC-RULE-003 | Access to Restricted (C3) information needs the information owner's approval in addition to the system owner's | | ACC-RULE-004 | Access to production data is through approved roles only; direct database access by engineers is time-bound and logged | | ACC-RULE-005 | Access to source code repositories is limited to engineering roles; write access to protected branches needs code review rules that cannot be bypassed by the author (A.8.4) | | ACC-RULE-006 | Grants outside the catalogue are individual exceptions, carry an expiry date no longer than [90 days] and are listed in the exception register | | ACC-RULE-007 | Requests that would create a segregation of duties conflict are rejected or approved with a recorded compensating control | | ACC-RULE-008 | Access is granted only from devices that meet the endpoint standard (`isms/endpoint-device-byod-policy`) for systems holding Confidential (C2) or Restricted (C3) information | | ACC-RULE-009 | Approvals are recorded in the tool; approvals by chat or e-mail are copied into the request record before provisioning | | ACC-RULE-010 | Information inside applications is restricted by role, tenant and record-level rules so that users see only what their role allows (A.8.3) | ### 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. ```mermaid flowchart TD A["Manager or user raises request"] --> B{"Catalogue role?"} B -- "Yes" --> C["System owner approves"] B -- "No" --> D["Exception request with expiry"] D --> E["Security review and system owner approval"] C --> F{"Restricted data or SoD conflict?"} E --> F F -- "Restricted" --> G["Information owner approves"] F -- "SoD conflict" --> H["Compensating control recorded"] F -- "Neither" --> I["IAM team provisions"] G --> I H --> I I --> J["Requester notified, record closed with evidence"] ``` ## 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. ```mermaid stateDiagram-v2 [*] --> PreHire: HR record created PreHire --> Active: Start date, birthright access Active --> Active: Role-based request approved Active --> Moving: Role or department change Moving --> Active: Old access removed, new roles granted Active --> Suspended: Long leave or investigation Suspended --> Active: Return confirmed by HR Active --> Leaving: Termination date recorded Suspended --> Leaving: Termination date recorded Leaving --> Disabled: Access revoked by deadline Disabled --> Deleted: Retention period ends Deleted --> [*] ``` ### 5.2 Service levels | Event | Trigger | Action | Deadline | |---|---|---|---| | Joiner | HR or procurement record with start date | Create identity, enrol MFA, grant birthright access, issue device | Ready on the start date, not earlier than [2 working days] before | | Mover | HR change of role, department or manager | Grant new roles on approval; remove roles no longer needed | New access on the effective date; old access removed within [5 working days], or the same day for privileged roles | | Leaver (planned) | Termination date in HR | Disable identity, revoke sessions and tokens, remove privileged roles, collect assets (`isms/offboarding-security-checklist`) | By the end of the last working day | | Leaver (urgent) | Dismissal or security concern | Same as planned leaver, coordinated with HR | Within [1 hour] of HR notification | | Contractor end | Contract end date in the contractor register | Disable identity and third-party accounts | By the end of the contract end date | | Long leave | HR record of leave over [30 days] | Suspend identity, keep data | On the first day of leave | | Dormant account | No sign-in for [45 days] | Disable and notify the manager | Weekly automated job | | Identity deletion | Disabled for [90 days] and no legal hold | Delete or archive per retention rules (`data/data-retention-deletion-standard`) | Monthly job | ### 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 | Access type | Minimum requirement | Preferred | |---|---|---| | Standard workforce access through SSO | MFA with an authenticator app (push with number matching or one-time code) | Passwordless: platform passkey or FIDO2 security key | | Remote access to internal networks | MFA plus a compliant managed device | Phishing-resistant MFA plus device certificate | | Administrative and privileged access (section 7) | Phishing-resistant MFA (FIDO2 or passkey bound to the device, or smart card) | Hardware security key kept by the administrator | | Identity provider administrators and break-glass | Phishing-resistant MFA with hardware key; break-glass keys sealed and logged | Two hardware keys per account stored separately | | Third parties | MFA through our identity provider or through a federated identity provider that enforces MFA | Phishing-resistant MFA | | Customer-facing admin consoles operated by staff | Same as administrative access | Same | | Service and machine identities (section 9) | Managed workload identity or short-lived credentials | No long-lived static secrets | 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 | Step | Rule | |---|---| | First enrolment | Done on the first day after identity proofing by HR or the manager (photo ID check in person or by video call) | | Reset or lost authenticator | Identity re-verified through a separate channel (video call with ID, or manager confirmation plus a code sent to the registered device); never by e-mail request alone | | Help desk resets | Logged with the verification method used; help desk staff cannot reset administrators | | Revocation | Authenticators and sessions revoked at leaver, at suspected compromise and at device loss | | Session limits | Standard sessions re-authenticate every [12 hours]; privileged sessions every [1 hour] or at elevation | ## 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 | Scope | Reviewer | Frequency | |---|---|---|---| | Privileged access | All administrator roles, break-glass accounts, Tier 0 and Tier 1 | System owner and security | Quarterly | | Restricted and financial systems | Roles reaching Restricted (C3) data, finance approvers | System or information owner | Quarterly | | Other business systems | All other catalogue roles | System owner or line manager | Semi-annual | | Service and machine accounts | All non-human identities (section 9) | Owning team | Quarterly | | Third-party accounts | All external identities | Sponsor | Quarterly | | HR reconciliation | Active identities against HR and contractor register | IAM team | Monthly | | Identity provider administrators | All identity provider admin roles | CISO or person outside the IAM team | Quarterly | 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 | Rule ID | Rule | |---|---| | SVC-RULE-001 | Every service account has a named owning team, a purpose, the systems it touches and a review date in the service account inventory | | SVC-RULE-002 | Service accounts cannot sign in interactively; interactive use is blocked by policy where the platform allows | | SVC-RULE-003 | Prefer managed workload identities and short-lived tokens; static secrets are stored only in the secrets manager (`security/secrets-management-standard`) | | SVC-RULE-004 | Static secrets that cannot be removed are rotated at least every [90 days] and immediately when a person with access leaves | | SVC-RULE-005 | Shared human accounts are prohibited, except for named cases (for example a meeting-room device or a vendor appliance) approved as exceptions, with credentials in the password manager and access logged | | SVC-RULE-006 | API keys issued to customers or partners have scopes, expiry and a revocation path | | SVC-RULE-007 | AI agents and automation that act with user or system rights are registered as non-human identities with the same rules (`ai-data/ai-usage-policy`) | ## 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). | Exception ID | Rule | System | Compensating control | Expiry | Approver | |---|---|---|---|---|---| | EXC-ACC-001 *(Example)* | ACP-PRN-007 (MFA) | Legacy build server | Reachable only from the admin jump host, which enforces MFA | YYYY-MM-DD | [Risk owner] and [department head], residual 6 Medium | | [EXC-ACC-NNN] | [rule] | [system] | [control] | YYYY-MM-DD | [approver] | ## 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. | Metric ID | Metric | Target | Example result *(Example)* | |---|---|---|---| | ACC-MET-001 | Leavers disabled by the deadline in section 5.2 | 100% | 4 of 4 leavers in the quarter (100%) | | ACC-MET-002 | Workforce identities with MFA enrolled | 100% | 46 of 46 (100%) | | ACC-MET-003 | Administrators using phishing-resistant MFA | 100% | 6 of 7 (86%), one hardware key on order | | ACC-MET-004 | Access review campaigns completed on time | 100% | 3 of 3 campaigns | | ACC-MET-005 | Entitlements removed in reviews (rate, not a target) | Report and explain | 11 of 312 reviewed entitlements (3.5%) | | ACC-MET-006 | Active exceptions past expiry | 0 | 0 | | ACC-MET-007 | Service accounts without an owner | 0 | 2, assigned in the following week | | ACC-MET-008 | Accounts dormant over 45 days still enabled | 0 | 1, disabled at the weekly job | 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 | Topic | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large or multi-site: Quillmere Group (2,400 staff, 6 sites) | |---|---|---|---| | Identity source | One cloud identity provider tied to the productivity suite; HR spreadsheet plus HR tool for 38 employees and a contractor register for 8 contractors | HR information system drives provisioning through SCIM to the identity provider | Group directory federated across 4 countries; separate OT identity domain at the 3 plants with a controlled trust | | Role catalogue | About 20 roles in one controlled spreadsheet maintained by the 0.5 FTE ISMS manager, each role owned by its system owner | Identity governance module, roles per system owner, clinical system roles reviewed by the information owner | Identity governance platform, group role model plus site roles, SoD rule set for finance and plant control systems | | Privileged access | Separate admin identities, JIT through the cloud provider's native tools | Privileged access management tool for the colocation suite and cloud | Tiered model with privileged access workstations, PAM vault, OT jump hosts per plant | | Reviews | Quarterly review run by the ISMS manager with system owners in one meeting | Campaigns in the governance tool, 3-person security team follows up | Campaigns per site and system with regional coordinators; the 14-person security office reports to the CISO | | Leaver deadline | End of last working day, done by hand from the offboarding checklist | Automated from HR, verified daily | Automated, with plant badge and OT account revocation by site security | | Authentication | Passkeys for all staff, hardware keys required for all 7 administrators (ACC-MET-003) | Phishing-resistant MFA for admins and clinical system support, app MFA for others | Phishing-resistant MFA group-wide for IT; OT uses smart cards on shared stations where named login is not yet possible (exception) | ## 14. Records and evidence | Record | Proves | Owner | Location | Retention | |---|---|---|---|---| | Approved policy and revision history | A.5.15 rules are defined and approved | ISMS manager | Document register (DOC-ISMS-028) | Current plus [3] previous versions | | Role catalogue | Roles, approvers, SoD conflicts defined (A.5.15, A.8.3) | System owners | [Tool or controlled file] | Current, plus change history | | Access request and approval tickets | Grants follow the approval rules (A.5.18) | IAM team | [Ticketing tool] | [3 years] | | Joiner, mover, leaver reports against HR | Lifecycle deadlines met (A.5.16) | IAM team | [Tool export, monthly] | [3 years] | | Access review campaign records | Reviews done and removals verified (A.5.18) | System owners | `ops/access-review` records | [3 years] | | MFA enrolment and authentication policy reports | Authentication standard enforced (A.5.17, A.8.5) | Security team | Identity provider reports | [1 year] of monthly exports | | Privileged elevation and break-glass logs | Privileged rules operate (A.8.2) | Security team | Log platform | Per logging standard, at least [1 year] | | Service account inventory | Non-human identities owned and reviewed | Owning teams | [Inventory or CMDB] | Current plus change history | | Exception register | Deviations approved and time-bound | Security team | DOC-ISMS-122 records | Life of exception plus [3 years] | | Metrics reports | Policy performance monitored (clause 9.1) | ISMS manager | Performance report (DOC-ISMS-081) | [3 years] | ## 15. References | Reference | Edition | Use | |---|---|---| | ISO/IEC 27001:2022 + Amd 1:2024 | 2022, Amd 1 published 2024-02-23 | Annex A A.5.3, A.5.15 to A.5.18, A.8.2 to A.8.5 (cited by number) | | ISO/IEC 27002:2022 | 2022 | Guidance for the controls above | | NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management | Final, July 2025 | Password and authenticator rules in section 6 | | ISO/IEC 27001 official page | https://www.iso.org/standard/82875.html | Purchase the standard | | ISO/IEC 27001 Amd 1 official page | https://www.iso.org/standard/88435.html | Amendment | | ISO/IEC 27002 official page | https://www.iso.org/standard/75652.html | Control guidance | 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.