ISO 27001 · the access control policy
The access control policy, written from a few answers
Most findings in a first audit are about access: an account that outlived its owner, an administrator who is also the developer, a review that never happened, so this page writes the rules that prevent them, from a few answers: one identity per person, how far multi-factor authentication reaches, the roles access is granted by, separate privileged accounts, time-limited third parties, the review cadence, the leaver's last day, the logs, and the exceptions.
The policy
Eleven sections in the order access is granted and taken away; an empty entry is written as a gap to fill, not skipped.
# Access control policy: [company] Policy owner: [the policy owner] · Approved by: [top management] Written on with the free page on getstandardos.com against the Annex A controls of ISO/IEC 27001:2022 on access control, identity management, authentication information, access rights, privileged access, information access restriction and secure authentication. The wording is StandardOS's own. ## 1. Purpose and scope This policy says how [company] gives people and systems access to its information and services, how that access is protected, reviewed and removed, and who decides. It applies to every account on every system inside the scope of the management system, whether held by an employee, a contractor, a supplier or a machine. ## 2. Principles - Least privilege: everyone gets the access their role needs and nothing more, and access is added when a task needs it rather than in advance. - One identity per person: every account belongs to one named person or one named system, shared accounts do not exist, and a break-glass account is sealed, logged and owned. - Deny by default: a new system, a new person and a new role start with no access, and access is granted, not assumed. - An owner for every system: each system has a named owner who approves access to it and answers for its reviews. ## 3. Identities and joiners Every person has one identity in [to be completed], and every service that can use it does; where a service cannot, its account is created by the system owner from the same identity record and listed against it. Group membership in the identity provider is how a role is granted. A joiner gets access on the first day through a request from their manager that names the role; the request, the approval and the accounts created are recorded, and nothing is granted by word of mouth. ## 4. Authentication Multi-factor authentication is on for every account that offers it, with an authenticator app or a hardware key and never SMS where a stronger factor exists; a service without it is an exception under section 11. Passwords are long, unique, generated by and kept in the company password manager, never reused across services and never written into code, tickets or chat; secrets used by systems live in a secrets manager, are rotated when a person with access to them leaves, and are never committed to a repository. ## 5. Access rights and roles Access is granted by role. [Name the roles the company grants access by, each with the systems and the level of access it carries; the role catalogue is owned by the policy owner and reviewed with the access reviews.] When a person changes role, the old role's access is removed on the day the new one is granted; access is never accumulated across roles, and a temporary need is granted with an end date that removes it. ## 6. Privileged access Administrative rights live in separate administrator accounts, used only for administrative tasks and never for mail, browsing or daily work; the everyday account has no elevated rights. Privileged access is granted to named people by the system owner, listed, protected by multi-factor authentication, reviewed at every access review and removed the moment the role no longer needs it; production data is not accessed with privileged rights for development or testing. ## 7. Suppliers and other third parties A supplier, auditor or partner gets access only under a contract, through a named account sponsored by a system owner, limited to the systems and the period the work needs, with an end date that removes it; third-party access is reviewed with the access reviews and revoked when the contract ends. ## 8. Access reviews Every quarter, every system owner reviews every account and every privilege on their system against the role catalogue and the people list, removes what is no longer needed, and records the review, its findings and the removals; [the policy owner] runs the cycle and reports the results to the management review. ## 9. Leavers On a person's last day every account is disabled before they leave the building or the call, their group memberships are removed, secrets they knew are rotated, their devices are returned and wiped, and the removal is recorded; accounts are deleted after the retention period the company sets. ## 10. Logging Logins, failed logins, privilege elevations and changes to access rights are logged on every system that can log them, kept for the period the company sets, protected from change, and read when an incident or an access review calls for it. ## 11. Exceptions An exception to this policy is requested in writing, approved by [the policy owner] with an end date and a compensating measure, listed in the exception register and reviewed with the access reviews; an exception without an end date is a finding. Approved by [top management] on [date]; owned by [the policy owner]; reviewed at least once a year and whenever the company's systems, roles or identity provider change. This policy is written from the answers given. It is not certification advice; the certification body reads the policy for its rules and then samples the accounts, the reviews and the leavers against it, and the record it accepts is the one the company keeps.
In StandardOS the access review runs itself
StandardOS puts every system owner's access review on the calendar at the cadence this policy sets, records who kept and who removed what, and shows the auditor the reviews and the leavers beside the policy.
The acceptable use policyThe information security policyThe Annex A controls