Access control

What the control asks

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.

Purpose in the standard’s terms, in our words: Ensures access to information and associated assets is authorized and unauthorized access is prevented.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Identity and access management; Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• The topic-specific access control policy, approved and communicated, reflecting owner-defined business and security requirements
• Access control rules or role models mapping entities (users, services, devices) to rights, consistent with classification
• Evidence of a default-deny design in firewall rules, application roles and cloud IAM policies
• Separation of request, approval and administration functions in the access management workflow
• Procedures supporting the rules for identity, authentication, access rights and privileged access
• Records of periodic review of the rules and their approvals

Where audits commonly find gaps

• The access control policy exists but is not reflected in actual system configurations
• Default-allow rules persist in network or cloud environments
• Non-human entities such as service accounts are left outside the access rules
• Access rights are not aligned with classification, so sensitive data is broadly accessible

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. Its earlier numbering (09.1.1, 09.1.2) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 5.16 Identity management
• 5.17 Authentication information
• 5.18 Access rights

Read the five attributes All 93 controls