EvidenceSheet

5.15 Access control

Rules that govern both physical entry and logical access to information and associated assets are to be set and applied on the basis of business and information security requirements. Purpose: allow access that is authorized and block access that is not. Guidance: asset owners work out the business and security requirements for access, and a topic-specific access control policy reflecting them is defined and communicated. Requirements and policy consider: which entities need which kinds of access; application security (8.26); physical access backed by entry controls (7.2 to 7.4); dissemination and authorization including need-to-know, and classification levels (5.10, 5.12, 5.13); limits on privileged access (8.2); segregation of duties (5.3); laws, regulations and contracts restricting access to data or services (5.31 to 5.34, 8.3); separation of the access control functions of requesting, authorizing and administering; formal approval of access requests (5.16, 5.18); managing access rights (5.18); and logging (8.15). Rules are put into effect by defining access rights and restrictions and mapping them to entities, which may be people or technical items such as machines, devices or services, and roles for groups of entities simplify management. When defining the rules, keep access rights consistent with classification and with physical perimeter needs, account for every type of connection in distributed environments so entities reach only authorized networks, services and information, and consider how dynamic factors can be reflected. Other information: need-to-know and need-to-use are the usual guiding principles; rules should default to deny (least privilege) rather than default to allow; care is needed over automatic versus user-initiated label changes and system versus administrator permission changes, and over when approvals are set and reviewed. Rules are backed by documented procedures and defined responsibilities, can be implemented as MAC, DAC, RBAC or ABAC, may include dynamic elements such as past access or location and connection type, and can range from whole networks to single data fields, with finer granularity costing more, so business need and risk decide the level.

Source: ISO/IEC 27002:2022, 5.15. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.

6
artefacts
1
held by a system
2
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

  • Procedures supporting the rules for identity, authentication, access rights and privileged access · Identity provider / directory

periodic reviewEvidence produced at each review

  • Evidence of a default-deny design in firewall rules, application roles and cloud IAM policies · Identity provider / directory
  • Records of periodic review of the rules and their approvals · Identity provider / directory

governing documentDocuments that govern the control

  • The topic-specific access control policy, approved and communicated, reflecting owner-defined business and security requirements · Policy repository / GRC workspace
  • Access control rules or role models mapping entities (users, services, devices) to rights, consistent with classification · Policy repository / GRC workspace
  • Separation of request, approval and administration functions in the access management workflow · Policy repository / GRC workspace

First move

Mostly documents and reviews. Pull the 1 system-held artefact from your Identity provider / directory on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.

Common gaps auditors find

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

5.14 Information transfer · 5.16 Identity management