A.5.15 Organizational
Access control
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (13)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- AC-3mostlycovers — ISO A.5.15 establishes the overarching access control policy and rules that enforce who may access what, directly fulfilling the core intent of AC-3.
- AC-6mostlyaligns with — The control explicitly requires restricting privileged access and applying the need-to-know principle, which aligns with the least-privilege objective of AC-6.
- AC-16partialaligns with — Consistency between access rights and information classification is mandated, reflecting the security-attribute usage that AC-16 governs.
- AC-2partialaligns with — A.5.15 addresses the authorization and ongoing management of access rights, which overlaps with the account provisioning and rights-management aspects of AC-2.
- AC-24partialaligns with — The guidance requires formal authorization of access requests and segregation of access-control functions, which supports the access-decision process addressed by AC-24.
- AC-5partialaligns with — Segregation of duties is listed as a required consideration when defining access control rules, matching the separation objective of AC-5.
Aligned NIST CSF 2.0 outcomes (10)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- PR.AA-05fullcovers — The ISO control establishes and enforces policy-based access permissions, entitlements, and authorizations while incorporating the need-to-know principle, segregation of duties, and formal authorization processes.
- PR.AA-01mostlyaligns with — Both require systematic management of identities and credentials for users, services, and hardware, including role-based assignment and lifecycle handling of access rights.
- PR.AA-06mostlyaligns with — The control explicitly integrates physical access requirements with logical access control, ensuring physical entry controls support the overall access policy.
- GV.PO-01partialaligns with — The ISO control requires a topic-specific access control policy derived from organizational context, business requirements, and legal obligations.
- ID.AM-05partialaligns with — Access rights are defined and mapped according to asset classification, criticality, and business impact, aligning with the CSF outcome of prioritizing assets for protection.
Related OWASP ASVS 5.0 requirements (14)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V8.2.1fullcovers — The ISO control’s mandate to implement access rights and restrictions directly implements the ASVS requirement that function-level access be restricted to entities with explicit permissions.
- V8.2.2fullcovers — ISO’s requirement to map access rights to specific information assets aligns with the ASVS rule that data-specific access must be limited to consumers with explicit permissions for those items.
- V8.1.1mostlyaligns with — Both require documented rules that map consumer permissions to function-level and data-specific access restrictions.
- V8.3.1mostlyaligns with — ISO’s emphasis on formal authorization, segregation of duties, and enforcement at a trusted layer mirrors the ASVS requirement that authorization decisions be enforced by a trusted service rather than an untrusted consumer.
- V8.2.3partialaligns with — The ISO guidance on consistency between access rights and information classification supports the ASVS objective of restricting field-level access based on explicit permissions.
- V8.3.3partialaligns with — The ISO principle that access is granted to the originating entity (user, service, or device) aligns with the ASVS rule that object access must be based on the originating subject’s permissions, not any intermediary.
- V8.4.1partialaligns with — ISO’s requirement to consider segregation of duties and need-to-know supports the ASVS objective of preventing cross-tenant operations in multi-tenant environments.
Related weaknesses / CWE (114)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- CWE-284fullprevents — Defining and enforcing explicit access rights and restrictions for each entity directly stops the assignment of permissions that exceed what is required, eliminating the root condition that allows improper access control.
- CWE-202mostlyprevents — Access control limits who can run queries that could expose sensitive information via inference.
- CWE-402mostlyprevents — Access-control mechanisms limit who can receive resources that should remain internal.
- CWE-732mostlyprevents — By requiring owners to determine and document the exact permissions needed for each asset, the control reduces the likelihood that default or overly permissive file and resource permissions will be left in place.
- CWE-921mostlyprevents — Access control policy directly requires protection of sensitive data wherever it is stored.
- CWE-1220partialprevents — Establishes the overarching access-control policy whose granularity directly determines whether the weakness exists.
- CWE-1230partialmitigates — Access-control rules can be extended to metadata objects, though the control is not metadata-specific.
- CWE-1268partialprevents — Defines the overarching access-control policy that should enforce consistent privileges between control and data agents.
- CWE-1323partialprevents — Access-control policies limit who can read or move trace buffers.
- CWE-1334partialprevents — Access control limits who can reach redundant hardware blocks, reducing the chance of unauthorized error injection.
- CWE-15partialprevents — Access control policies underpin the technical restrictions on configuration changes.
- CWE-213partialprevents — Access control can limit exposure to actors whose policies differ from the developer’s.
- CWE-219partialmitigates — Access-control policy defines who may reach files under the web root.
- CWE-250partialprevents — The requirement to restrict privileged access and apply segregation of duties limits the number of processes or accounts that must run with elevated rights, lowering the impact of unnecessary privilege assignments.
- CWE-266partialprevents — Access control policy directly prevents incorrect privilege assignment by defining who may receive which rights.
- CWE-267partialmitigates — Access control policy can limit unsafe privilege use but does not define safe actions for each privilege.
- CWE-268partialprevents — Access control policies can limit the combination of privileges that enable unsafe actions.
- CWE-269partialprevents — Explicit restrictions on privileged access and segregation of duties limit the scope of privileges that can be assigned, reducing the chance that excessive or unnecessary privileges are granted to entities.
- CWE-270partialprevents — Access-control policy defines privilege boundaries but does not guarantee correct switching logic.
- CWE-274partialprevents — Access control policy defines privilege boundaries but does not guarantee correct runtime handling when privileges prove insufficient.
- CWE-278partialprevents — Access control policies can require explicit permission review on object creation or copy, reducing inherited insecure permissions.
- CWE-280partialprevents — Defines access-control policy that should prevent insufficient-privilege situations.
- CWE-283partialprevents — Access control policies can require ownership verification before granting access to critical resources.
- CWE-285partialprevents — Mapping access rights to information classification and business requirements forces correct enforcement of authorization decisions, blocking the incorrect authorization weakness at the policy and implementation stage.
- CWE-286partialprevents — Access control policies rely on accurate user management but do not themselves define user lifecycle processes.
- CWE-288partialprevents — Access control policy directly addresses alternate authentication paths by requiring all channels to enforce authentication.
- CWE-289partialprevents — Access-control policy can mandate canonical-name checks but does not prescribe the technical implementation.
- CWE-290partialprevents — Access control policy reduces spoofing opportunities but does not prescribe authentication mechanisms.
- CWE-291partialprevents — Access-control policy can mandate stronger authentication than IP address alone.
- CWE-308partialprevents — Access control policy can mandate multi-factor authentication but does not prescribe the technical implementation.
- CWE-408partialprevents — Access control policies that enforce authentication before resource-intensive operations directly prevent early amplification.
- CWE-424partialprevents — Access control policy directly requires protection of all entry points to restricted functionality.
- CWE-425partialprevents — Access control policy directly requires authorization checks on all resources, preventing forced browsing.
- CWE-441partialprevents — Access-control rules can limit which upstream identities may cause the product to act on their behalf, reducing confused-deputy risk.
- CWE-527partialprevents — Access control policies directly prevent unauthorized actors from reaching version-control repositories.
- CWE-528partialprevents — Access-control policies can restrict who may read core-dump files, yet the control is broader than this specific weakness.
- CWE-529partialprevents — Access control policy directly requires restricting ACL files to the intended control sphere.
- CWE-530partialprevents — Access control directly limits who can reach backup files, though it does not address how backups are created or stored.
- CWE-540partialprevents — Access control limits who can view or retrieve source code that may contain secrets.
- CWE-566partialprevents — Access-control policy sets the governance expectation that all data access must be authorized, indirectly supporting prevention of CWE-566.
- CWE-612partialprevents — Access control policies directly limit who can query or view the index.
- CWE-638partialprevents — Access control policy directly requires checks on every access, preventing stale privileges.
- CWE-639partialprevents — Access control policy directly requires enforcement of authorization rules that prevent unauthorized access via manipulated keys.
- CWE-642partialprevents — Access control policies directly limit who can read or modify security-critical state data.
- CWE-654partialprevents — Access control policy can mandate multi-factor checks, but does not guarantee implementation.
- CWE-708partialprevents — Access-control policy can mandate correct ownership assignment, but does not prescribe how ownership is technically enforced.
- CWE-842partialprevents — Access control policy defines group membership rules but does not guarantee correct assignment.
- CWE-862partialprevents — Requiring formal authorization of every access request before rights are granted ensures that checks for required permissions are performed, preventing missing authorization checks from being introduced.
- CWE-863partialprevents — Requiring consistency between access rights and classification plus formal approval steps ensures that the authorization logic correctly distinguishes between entities that should and should not be granted access.
- CWE-939partialprevents — High-level access-control policy provides governance context but does not prescribe the technical authorization logic needed for URL-scheme handlers.
- CWE-281nonenone — Access-control policy defines how permissions must be preserved when objects are copied or shared.
- CWE-282nonemitigates — Access control policies can enforce correct ownership assignment and verification for objects.
- CWE-302nonenone — Access-control policy can mandate validation of all identity data, reducing reliance on assumed-immutable fields.
- CWE-309nonenone — Access control policy can mandate stronger primary authentication than passwords.
- CWE-384nonenone — Access-control policy can mandate session invalidation on re-authentication, but does not prescribe the technical mechanism.
- CWE-507nonenone — Access control limits who can introduce or execute Trojan Horse code but does not prevent its presence.
- CWE-645nonenone — Access control policy should define lockout thresholds and recovery procedures to avoid overly restrictive denial-of-service.
- CWE-653nonemitigates — Access control policies establish the boundaries that isolation must enforce.
- CWE-669nonemitigates — Access-control policies limit unintended control over transferred resources.
- CWE-671nonenone — Access control policy defines how administrators can tailor security settings to the environment.
- CWE-673nonemitigates — Access control policies and enforcement directly limit who can define or modify control spheres.
- CWE-837nonenone — Access-control rules can enforce single-use or uniqueness constraints, but the control is broader than this specific weakness.
Mitigated MITRE ATT&CK techniques (8)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- T1078mostlyprevents — Formal authorization, role-based assignment, and periodic review of access rights directly constrain an adversary's ability to leverage stolen or guessed credentials by ensuring only explicitly approved entities retain access.
- T1078.002mostlyprevents — Mapping access rights to verified roles and enforcing need-to-know limits the scope of any compromised domain account.
- T1078.001partialmitigates — Requiring explicit authorization and segregation of privileged access reduces the likelihood that default accounts remain enabled or usable for initial foothold.
- T1078.003partialmitigates — Requiring formal approval and role-based assignment for local accounts shrinks the attack surface an adversary can exploit with stolen local credentials.
- T1078.004partialmitigates — Explicit authorization and segregation of duties for cloud accounts reduce the chance that an adversary can abuse valid cloud credentials obtained through other means.
- T1098partialprevents — Segregation of access request, authorization, and administration functions makes it harder for an adversary to silently create or modify accounts without detection.
- T1098.007nonemitigates — Requiring formal approval and role-based assignment for group membership changes limits an adversary's ability to add accounts to privileged groups for persistence.
- T1136nonemitigates — Mandatory authorization workflows and segregation of duties for account creation reduce the feasibility of an adversary creating new accounts undetected.
Prevented OWASP Web Top 10 (2025) risks (3)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- A01fullprevents — By requiring owners to define, authorize, and enforce access rights according to business needs, classification, and the need-to-know principle, the control directly stops unauthorized entities from reaching data or functions they should not access.
- A02mostlyprevents — Requiring a documented, communicated access-control policy and consistent mapping of rights to roles and classification levels helps prevent default or overly permissive configurations from remaining in applications.
- A07partialmitigates — Formal authorization of access requests, segregation of duties, and management of privileged accounts reduce the chance that weak or missing authentication mechanisms will grant inappropriate entry.
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.