Access control

What the requirement 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 tying 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Access control is expected to follow a policy, not a habit. The guidance asks for the access model, the request and approval route, the review and the removal at exit.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep the topic-specific access control policy, approved and communicated, reflecting owner-defined business and security requirements and one live sample together.

Evidence an assessor asks for

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

The question an assessor will ask

An assessor will ask for the topic-specific access control policy, approved and communicated, reflecting owner-defined business and security requirements, then trace it to the system it protects. For A.5.15 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: the access control policy exists but is not reflected in actual system configurations.