A.5.3 Organizational
Segregation of duties
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (12)
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-5fullcovers — Both controls require the explicit separation of duties that could enable a single individual to subvert security controls or commit fraud.
- AC-6mostlyaligns with — Segregation of duties is a direct mechanism for enforcing least privilege by ensuring no individual accumulates conflicting privileges.
- AC-2partialaligns with — Both address the need to manage role assignments so that conflicting privileges are not granted to the same account.
- AU-6partialaligns with — When full segregation is impractical, both controls rely on monitoring, audit trails, and supervisory review to detect improper actions.
- AC-6covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Aligned NIST CSF 2.0 outcomes (15)
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)
- GV.RR-02mostlyaligns with — By requiring the organization to determine which duties must be segregated and to assign responsibilities accordingly, the control helps establish and communicate clear roles and authorities for cybersecurity risk management.
- PR.AA-05mostlyaligns with — The ISO control's focus on separating conflicting duties and preventing single-person execution of high-risk actions directly supports the CSF outcome of defining, managing, and enforcing access permissions and authorizations.
- ID.AM-05partialaligns with — The control's emphasis on identifying duties that require separation contributes to prioritizing assets and functions based on the impact of potential conflicts or misuse.
- PR.PS-01partialaligns with — Segregation of duties is a foundational configuration practice that the control applies to roles and responsibilities to reduce the risk of unauthorized or erroneous actions.
- GV.RR-02implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- ID.AM-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.AA-05implements — A.5.3 directly operationalizes the separation-of-duties principle that PR.AA-05 explicitly names and requires as part of how access permissions are managed and enforced
- PR.PS-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Related OWASP ASVS 5.0 requirements (10)
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.1partialaligns with — The ISO control's requirement to separate conflicting duties such as requesting versus approving access rights directly supports the ASVS mandate that function-level access be restricted to consumers with explicit permissions.
- V8.2.2partialaligns with — Segregating duties like using versus administering databases or applications aligns with the ASVS requirement that data-specific access be granted only to consumers with explicit permissions for those items.
- V8.3.1partialaligns with — By insisting that authorization decisions be enforced at a trusted service layer rather than by untrusted consumers, the ASVS requirement mirrors the ISO guidance to avoid granting a single individual conflicting roles.
- V8.4.2partialaligns with — The ISO emphasis on layered controls and management supervision for high-risk duties such as administering production systems aligns with the ASVS requirement for multiple security layers around administrative interfaces.
Related weaknesses / CWE (12)
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-250mitigates — Forcing distinct roles for initiating versus executing changes reduces the chance that an individual will run with unnecessary privileges to perform both steps.
- CWE-266mitigates — Segregation of duties reduces blast radius of any single incorrect privilege but does not prevent the assignment itself.
- CWE-267mitigates — Segregation of duties reduces risk of unsafe actions by splitting privileges but does not address unsafe privilege definitions.
- CWE-268prevents — Segregation of duties reduces the chance that two distinct privileges can be combined to perform unsafe actions.
- CWE-269mitigates — Separating duties such as developing software from administering production systems prevents any one person from accumulating excessive privileges that would constitute improper privilege management.
- CWE-284mitigates — By requiring that conflicting actions such as requesting and approving access rights be performed by separate individuals, the control directly blocks a single actor from unilaterally exercising improper access control.
- CWE-653prevents — Segregation of duties directly enforces separation of privilege levels and functions.
- CWE-732mitigates — Requiring separate individuals to request, approve, and implement access rights limits the likelihood that critical resources will be assigned overly permissive or incorrect permissions.
- CWE-842mitigates — Segregation of duties may be undermined by wrong group membership but does not itself prevent the placement error.
- CWE-862mitigates — Segregating the approval of access rights from their implementation provides an independent check that reduces the impact of missing authorization checks in the resulting system configuration.
Mitigated MITRE ATT&CK techniques (276)
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).
T1001.003←MT1003.006→PT1006←MT1014←MT1021.002→PT1021.003→PT1021.008→PT1027.001←MT1027.002←MT1027.006←MT1027.007←MT1027.008←MT1027.010←MT1027.014←MT1027.016←MT1030←MT1036←MT1036.003←MT1036.005←MT1036.008←MT1036.009←MT1037→PT1037.003→PT1037.004→PT1055←MT1055.001←MT1055.002←MT1055.003←MT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1059.008→PT1059.009→PT1068←MT1070←MT1070.003←MT1070.006←MT1070.010←MT1071.004←MT1072→PT1074.002←MT1078→PT1078.001←M →PT1078.002←M →PT1078.003←P →PT1078.004←M →PT1080→PT1090.003←MT1095←MT1098←M →PT1098.001→PT1098.002←P →PT1098.003←M →PT1098.004→PT1098.005←M →PT1098.006←P →PT1098.007←P →PT1102←MT1102.002←MT1110.001→MT1110.003←MT1111←MT1114.003→PT1127←MT1127.001←MT1127.003←MT1133←MT1134←MT1134.001←MT1134.002←MT1134.003←MT1134.004←MT1134.005←MT1136→PT1136.001→PT1136.002→PT1136.003→PT1137.001→PT1137.003→PT1137.004→PT1137.005→PT1137.006→PT1185←MT1195→PT1195.001→PT1195.002→PT1199→PT1202←MT1204.002←MT1204.004←MT1204.005←MT1207←MT1211←MT1216←MT1216.001←MT1216.002←MT1218←MT1218.003←MT1218.004←MT1218.005←MT1218.007←MT1218.008←MT1218.009←MT1218.010←MT1218.011←MT1218.012←MT1218.013←MT1219.003←MT1220←MT1221←MT1222←MT1222.001←MT1222.002←MT1480.001←MT1484←M →PT1484.001←P →PT1484.002←MT1528→PT1535←MT1537←MT1539←FT1542←MT1542.002←MT1543→PT1543.002→PT1543.003→PT1546.003→PT1546.004→PT1546.012←PT1546.013→PT1547.012→PT1548←M →PT1548.001←MT1548.002←M →PT1548.003←M →PT1548.005←M →PT1548.006←MT1550←MT1550.001←FT1550.002←FT1550.003←MT1550.004←FT1553←PT1553.001←MT1553.002←PT1553.003←MT1553.004←PT1553.005←MT1553.006←MT1556←M →PT1556.001←MT1556.003←MT1556.004←MT1556.006←PT1556.007←MT1556.008←MT1556.009←M →PT1563.002→PT1564←MT1564.001←MT1564.004←MT1565→PT1565.001→PT1566.003←MT1571←MT1572←MT1574←MT1574.001←MT1574.010→PT1574.011→PT1574.013←MT1578←M →PT1578.001←MT1578.002←MT1578.003←M →PT1578.004←MT1578.005←M →PT1599←MT1599.001←MT1601.001←PT1601.002←MT1606←MT1606.001←MT1606.002←MT1609→PT1610←PT1611←MT1612←MT1620←MT1621←MT1647←PT1649→PT1651→PT1657→PT1666←M →PT1671←M →PT1677→PT1684←M →PT1685←MT1685.001←MT1685.002←M →PT1685.003←MT1685.004←MT1685.005←MT1685.006←MT1686.002←MT1686.003←MT1687←PT1688←MT1689←PT1690←M
Why these map — AI rationale (under review)
- T1003.006prevents — A.5.3's segregation of conflicting duties (e.g., requesting/approving access rights, using/administering applications or databases) directly constrains the administrative privileges required to perform DCSync, but small-org exceptions, collusion risk, and the fact that some privileged roles remain inherently combined leave a genuine residual slice
- T1021.002prevents — A.5.3's segregation of duties (e.g. separating requesting/approving/implementing access rights, or using/administering applications and databases) directly constrains the acquisition and combined use of administrator-level Valid Accounts needed to access admin shares, but leaves many other vectors (e.g. pass-the-hash, existing sessions, or non-admin lateral movement) untouched.
- T1021.003prevents — A.5.3's segregation of conflicting duties (e.g., requesting/approving/implementing access rights, using/administering applications) can block one individual from both obtaining and misusing the privileged account needed for DCOM lateral movement, but does not stop an already-privileged adversary (or collusion) from using valid accounts for the technique.
- T1021.008prevents — A.5.3's segregation of duties (e.g. separating requesting/approving/implementing access rights, or using/administering systems) directly constrains the abuse path for valid accounts that enable direct cloud VM connections, but leaves many other vectors (e.g. compromised credentials, misconfigured defaults, or non-duty-based privilege escalation) untouched.
- T1037prevents — A.5.3's segregation of conflicting duties (e.g., designing/implementing/reviewing code, developing software vs. administering production systems, using vs. administering applications/databases) directly stops a single actor from both placing and authorizing malicious boot/logon scripts, but leaves open the possibility of collusion, incomplete segregation in small orgs, or abuse by already-privileged administrators who legitimately combine those roles.
- T1037.003prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, or request/approve/implement) directly blocks a single individual from both provisioning a malicious network logon script (via AD/GPO) and retaining the privileges needed to abuse its persistence, though it does not stop all vectors such as collusion, small-org limits, or already-provisioned scripts.
- T1037.004prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, or request/approve/implement) directly constrains the single-admin/root path that enables unaudited modification of RC scripts for persistence, but leaves open collusion, small-org/practical exceptions, non-role-based root access, and systems where RC scripts run without human admin intervention.
- T1059.008prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, or use/admin roles) directly prevents a single insider from using the network CLI to perform conflicting malicious actions like modifying configs or disabling logging, though it does not stop external adversaries or non-conflicting abuse and small orgs may fall back to monitoring.
- T1059.009prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering apps/databases) directly constrains the 'proper permissions' prerequisite for T1059.009 abuse, but leaves many other vectors (e.g., compromised credentials, developer roles, or small-org/practical limits) untouched.
- T1072prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, use/admin, or request/approve/implement access) directly stops a single individual from both acquiring and then abusing broad deployment-tool access for T1072, but leaves open paths via collusion, small-org practicality limits, role-definition gaps, or already-compromised admin accounts that the control itself does not close.
- T1078prevents — A.5.3's segregation of duties and conflicting-role checks directly blocks the permission-overlap and multi-account pivoting slice of T1078 that lets one compromised credential reach high privilege or bypass controls, but leaves the credential-compromise, inactive-account, and single-account abuse vectors untouched.
- T1078.001prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering applications) directly stops a single individual from both creating and then abusing a default account, but leaves the bulk of the technique (factory defaults, post-setup integration accounts, unchanged credentials, and collusion) untouched.
- T1078.002prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering systems) directly constrains the abuse pathways for compromised domain accounts by limiting what a single identity can do even after credential theft, though it does not stop initial compromise methods like credential dumping or password reuse.
- T1078.003prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, using/administering applications or databases, and provisioning roles to avoid conflicts) directly constrains how local accounts can be created, assigned, or reused for abuse, reducing the attack surface for T1078.003; it is only partial because many local accounts (default OS/service accounts, those outside RBAC, or in small orgs where full segregation is impractical) remain reachable and the control does not eliminate credential abuse vectors like dumping or password reuse.
- T1078.004prevents — A.5.3's segregation of conflicting duties/roles (e.g., requesting/approving access rights, using/administering apps or databases, role provisioning to avoid conflicts) directly constrains the misconfigurations and over-privileged cloud accounts that enable T1078.004's privilege escalation, persistence, and lateral movement, but leaves acquisition paths like phishing, brute force, and credential theft untouched.
- T1080prevents — A.5.3's segregation of duties (e.g., separating design/implement/review of code, or developing software from administering production systems) directly blocks single individuals from tainting shared content in code repos or network shares, but leaves many execution paths (e.g., binary infection of non-code files, directory-share pivots via LNK/masquerading, or insider collusion) untouched.
- T1098prevents — A.5.3's segregation of duties (e.g. separating requesting/approving/implementing access rights, or using/administering systems) directly stops a single actor from performing the permission-modifying actions that T1098 requires, but only for the subset of manipulations that cross segregated boundaries; insider collusion, already-elevated single-role abuse, and non-duty-based manipulations (e.g. iterative password changes by a compromised account) remain possible.
- T1098.001prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering applications and databases) directly stops a single compromised individual from unilaterally adding adversary-controlled credentials via APIs or portals, though it leaves gaps for collusion, small-org exceptions, and post-compromise abuse of already-approved high-privilege roles.
- T1098.002prevents — A.5.3 requires segregation of duties (e.g., separating requesting/approving/implementing access rights or using/administering applications) and careful RBAC role definition to stop one individual from unilaterally granting conflicting permissions; this directly blocks the self-delegation and permission-addition steps named in T1098.002 for many (but not all) accounts and small-org edge cases where full segregation cannot be achieved.
- T1098.003detects — A.5.3 explicitly names monitoring of activities, audit trails and management supervision as compensating controls when segregation cannot be fully achieved; these surface the conflicting-role additions named by T1098.003 after they occur.
- T1098.003prevents — A.5.3 requires segregation of conflicting duties/roles (e.g., requesting/approving/implementing access rights, or using/administering systems) and automated conflict detection in RBAC, which directly stops an adversary from unilaterally adding IAM roles/permissions to maintain persistence or escalate; this is a genuine but minority slice of the technique because the control is silent on technical enforcement of least-privilege IAM changes, external tenant role additions, and post-compromise API abuse by already-privileged accounts.
- T1098.004prevents — A.5.3 requires segregation of duties (e.g., separating design/review, approval/execution, or admin/use roles) and role-conflict checks that stop a single actor from both gaining the needed privileges and then modifying authorized_keys; this directly blocks the technique for many (but not all) paths, especially in non-cloud, non-network-device cases where the listed examples apply.
- T1098.005prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering applications and databases) directly blocks the self-enrollment and device-registration paths an adversary uses after credential compromise, but leaves open vectors such as initial device enrollment requiring only username/password, collusion, small-org impracticality, and post-registration abuse like spearphishing or service exhaustion.
- T1098.006prevents — A.5.3 directly requires segregation of conflicting duties/roles (including examples of access-rights and RBAC provisioning) and automated conflict detection, which stops an adversary from unilaterally adding ClusterRoles/RoleBindings or ABAC modifications to their own account; the bounded remainder is small-org exceptions and post-compromise modification of already-valid accounts that bypass initial segregation.
- T1098.007prevents — A.5.3 requires segregation of duties (e.g. requesting/approving/implementing access rights, using/administering applications or databases) that directly blocks an adversary from unilaterally adding groups to their own account for persistence; small-org exceptions, collusion risk, and non-duty-based group additions (e.g. machine accounts) leave a bounded remainder.
- T1110.001prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, using/administering applications, and role provisioning to avoid conflicts) directly constrains the setup and privileges an adversary can leverage for password guessing on accounts and services, preventing the technique from succeeding in most cases, with a bounded remainder for small organizations or sanctioned exceptions where full segregation is impracticable.
- T1114.003detects — A.5.3's guidance explicitly names monitoring of activities, audit trails and management supervision as compensating controls when full segregation cannot be achieved; these surface anomalous or conflicting rule-creation actions (including hidden forwarding rules) after the fact, but only for the subset of environments and role conflicts the organization has chosen to instrument or review.
- T1114.003prevents — A.5.3's segregation of conflicting duties (e.g. requesting/approving/implementing access rights, using/administering applications) directly stops a single compromised or malicious insider from both creating hidden forwarding rules and evading detection or reset, but leaves the technique executable by admins, via collusion, in small orgs using compensating monitoring, or through transport rules.
- T1136prevents — A.5.3's segregation of conflicting duties (e.g., requesting/approving/implementing access rights; using/administering applications) directly stops a single insider from creating privileged persistence accounts without oversight or collusion, but leaves the technique fully available to external adversaries or colluding insiders and does not constrain account creation on all listed platforms.
- T1136.001prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering systems) directly stops a single individual from unilaterally creating a local account for persistence, though it does not address all creation vectors such as initial exploitation or collusion.
- T1136.002prevents — A.5.3's segregation of duties (e.g. separating requesting/approving/implementing access rights, or using/administering systems) directly constrains the privileged path an adversary needs to create a domain account, but does not stop all creation vectors (e.g. via already-compromised high-privilege accounts or collusion).
- T1136.003prevents — A.5.3 requires segregation of duties (e.g., separate individuals for requesting/approving/implementing access rights and for using/administering systems) which directly blocks a single adversary from independently creating and elevating a cloud account for persistence; this covers a genuine but minority slice of the technique given that many creation paths (especially service accounts, low-privilege accounts, or post-compromise manipulation) remain reachable by one actor or via collusion.
- T1137.001prevents — A.5.3's segregation of duties (e.g. separating design/implement/review of code, or using vs. administering applications) constrains the ability for a single individual to both introduce and hide a malicious macro in a template, but does not stop the technique when performed by an already-privileged user, via remote/shared templates, registry hijacking, or in small orgs where full segregation is impractical.
- T1137.003prevents — A.5.3's segregation of duties (e.g., separating design/implement/review of code, or using vs. administering applications/databases) directly constrains the ability of a single individual to both create and deploy a malicious Outlook form for persistence, though it does not stop all vectors such as an already-compromised admin or collusion.
- T1137.004prevents — A.5.3's segregation of duties (e.g., separating design/implement/review of code, or requesting/approving/implementing access rights) constrains the ability for a single individual to introduce and activate a malicious Outlook Home Page URL for persistence, though it does not stop all vectors such as external supply-chain compromise or post-compromise abuse by an already-privileged actor, and small-org exceptions explicitly allow compensating controls instead.
- T1137.005prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering applications) directly blocks a single compromised individual from both gaining initial mailbox access and then adding malicious Outlook rules for persistence, but leaves open the named remainder of collusion, small-org impracticality (with only compensatory monitoring), and post-compromise rule abuse by an already-privileged user.
- T1137.006prevents — A.5.3's segregation of duties (e.g. separating design/implement/review of code, or developing software from administering production systems) constrains the ability for a single individual to both introduce and activate a malicious add-in for persistence, but does not stop an already-privileged user or external compromise from doing so, and small-org exceptions plus collusion risk leave a named remainder
- T1195prevents — A.5.3's segregation of duties and conflicting-role checks directly blocks single-insider manipulation of development tools/environments, code repositories, design-implement-review cycles, and open-source dependency contributions — a named slice of T1195's listed supply-chain stages — but leaves external, multi-party, hardware-shipment, and second-order compromises untouched.
- T1195.001prevents — A.5.3's segregation of duties (e.g., separate design/implement/review, develop/admin, or code-related roles) directly blocks a single insider from inserting malicious code into dependencies, tools, or CI/CD pipelines, but leaves external supply-chain attacks, typosquatting, and abandoned-package hijacks untouched.
- T1195.002prevents — A.5.3's segregation of design/implement/review and develop/administer duties directly blocks a single insider from manipulating source or builds in the supply chain, but leaves external supplier, distribution-mechanism, and compiled-release attacks untouched.
- T1199prevents — A.5.3's segregation of duties (e.g. separating requesting/approving/implementing access rights, or using/administering systems) directly constrains the overly-broad or conflicting third-party permissions that enable T1199 supply-chain compromise, but leaves open non-segregated vectors such as initial trust establishment, collusion, and small-org exceptions.
- T1484prevents — A.5.3's segregation of duties (e.g., separating initiating/approving/executing changes, designing/implementing/reviewing code, or requesting/approving/implementing access rights) directly blocks a single insider from unilaterally modifying domain/tenant policies or GPOs, which is the core of T1484; it is only partial because the technique can still be executed via collusion, compromised accounts with pre-existing permissions, or in small orgs where full segregation is impractical per the control's own guidance.
- T1484.001prevents — A.5.3 requires segregation of conflicting duties (e.g. designing/implementing/reviewing, requesting/approving/implementing access rights, or using/administering systems) and careful RBAC role definition to block one person from unilaterally modifying GPOs; this directly stops the technique for many actors and privilege paths, but leaves a bounded remainder where collusion occurs, small-org practicality limits, or a single high-privilege role (e.g. Domain Admin) can still modify GPOs without violating the segregation rule.
- T1528prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, designing/implementing/reviewing code, and using/administering applications) directly blocks several T1528 vectors such as insider abuse of roles to self-approve OAuth apps or CI/CD token issuance, but leaves the majority of vectors (container compromise, IMDS token requests after initial access, social-engineering OAuth phishing, and refresh-token theft) untouched.
- T1543prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, or request/approve/implement) directly blocks a single actor from both creating/modifying a system process and authorizing its persistence/escalation use, but leaves open collusion, small-org impracticality, non-role-based paths, and post-creation execution.
- T1543.002prevents — A.5.3's segregation of duties (e.g., separating design/implement/review of code, or requesting/approving/implementing access rights) constrains the ability of a single individual to both create/modify a systemd service file and approve its deployment or the associated privilege escalation, but leaves many vectors (generators, symbolic links, direct root edits, or single-role admin workflows in small orgs) untouched.
- T1543.003prevents — A.5.3's segregation of duties (e.g., separating initiating/approving/executing changes, requesting/approving access rights, or designing/implementing/reviewing code) constrains insider or privileged-user abuse that could create or modify Windows services for persistence, but leaves the bulk of the technique (remote adversary use of sc.exe, Registry edits, API calls, BYOVD, or hidden/masqueraded services after initial access) untouched.
- T1546.003detects — A.5.3's explicit guidance to consider monitoring of activities, audit trails, and management supervision when full segregation is impractical directly surfaces anomalous or conflicting use of WMI for event subscriptions, but this is only one compensatory slice of the control and does not mandate instrumentation of the technique itself.
- T1546.004prevents — A.5.3's segregation of duties (e.g. separating design/implement/review of code, or developing software from administering production systems) directly stops a single individual from both modifying the shell config files and later using the resulting persistence, which is exactly what the technique requires; small-org exceptions, collusion risk, and the fact that admin-only modification paths remain reachable keep it from being mostly.
- T1546.013prevents — A.5.3's segregation of duties (e.g., separating design/implement/review of code, or using vs. administering systems) directly stops a single individual from both modifying a PowerShell profile and later executing it under elevated context, which is the core of this persistence/escalation technique; small-org exceptions and the need for supplementary monitoring keep it from full coverage.
- T1547.012detects — A.5.3's monitoring-of-activities clause (when segregation is impractical) can surface anomalous use of privileged APIs, registry changes, or spooler restarts that install a malicious print processor, but this is scoped only to the subset of duties the organization has chosen to segregate and monitor rather than a dedicated detection mechanism.
- T1547.012prevents — A.5.3's segregation of duties (e.g., separating initiating/approving/executing changes, requesting/approving access rights, or using/administering applications and databases) directly constrains the privilege and approval steps needed to add a print processor via API or registry, but leaves residual paths such as collusion, small-org exceptions with monitoring, or already-privileged insiders who can still perform the full chain alone.
- T1548prevents — A.5.3's segregation of duties and role-conflict controls (e.g., separating approval/execution of access rights or admin vs. usage roles) directly stop single individuals from self-authorizing the elevated privileges that T1548 abuses, but this is only a slice of the technique's methods (bypassing UAC/sudo, exploiting specific flaws, etc.) and does not reach all platforms or non-role-based elevation paths.
- T1548.002prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering applications) directly constrains many insider or privilege-escalation paths that rely on one actor controlling conflicting steps to bypass UAC, but leaves technical bypasses (DLL injection, auto-elevated COM objects, eventvwr.exe, lateral movement with stolen creds) untouched.
- T1548.003prevents — A.5.3's core act of separating conflicting duties (e.g. requesting/approving/implementing access rights, using/administering applications or databases) directly stops a single individual from both configuring sudoers and then abusing its poor settings or NOPASSWD entries to escalate, but leaves the technique possible via collusion, small-org exceptions, or misconfigurations that other controls must address.
- T1548.005prevents — A.5.3's segregation of conflicting duties (e.g., requesting/approving/implementing access rights, designing/reviewing code or controls) directly constrains the permission misconfigurations and role-provisioning paths that enable temporary elevated access abuse, but leaves open cases such as collusion, small-org practicality limits, and already-misconfigured JIT/impersonation/pass-role grants that require monitoring or other compensating controls.
- T1556prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, or request/approve/implement access) directly stops a single actor from both modifying the auth process and using the resulting bypass, which is what T1556 requires; small-org exceptions, collusion risk, and non-segregable auth-component roles (e.g., on IaaS/IdP platforms) leave a bounded remainder.
- T1556.009prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or designing/reviewing controls) directly constrains the ability of a single compromised individual to unilaterally modify conditional access policies, thereby preventing the technique in many (but not all) realistic scenarios such as insider threats or single-account compromise.
- T1563.002detects — A.5.3's explicit fallback to monitoring of activities, audit trails and management supervision when full segregation cannot be achieved directly surfaces anomalous use of conflicting duties such as hijacking an RDP session
- T1565prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, approve/execute change, or use/administer) directly blocks single-actor data manipulation paths that rely on unchecked conflicting privileges, though it leaves residual risk from collusion, small-org limits, and complex-system expertise that the control itself flags as needing supplementary monitoring.
- T1565.001prevents — A.5.3's segregation of duties and conflicting-role restrictions (e.g., separating design/implement/review, approve/execute change, or use/administer) directly blocks single-actor paths that would enable undetected stored-data manipulation in business processes, databases, or code, though it leaves technical execution vectors, collusion, and small-org residuals unaddressed.
- T1574.010prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, use/admin) directly blocks single individuals from both introducing and exploiting the permission weakness that enables this hijack, though it does not address technical permission enforcement, non-role-based flaws, or collusion.
- T1574.011prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, request/approve/implement access rights, and role-conflict checks) directly constrains the permission-setting and approval steps that create the flawed Registry ACLs enabling T1574.011, but leaves residual cases such as small-org limits, collusion, or post-provisioning changes unaddressed.
- T1578prevents — A.5.3's segregation of duties (e.g., separating design/implement/review, develop/admin, request/approve/implement) directly stops a single actor from unilaterally modifying cloud compute infrastructure to evade defenses, but small-org exceptions, collusion risk, and non-covered modification vectors (e.g., via compromised high-privilege roles) leave a genuine bounded remainder.
- T1578.003detects — A.5.3's explicit guidance to use monitoring of activities, audit trails and management supervision when full segregation is impractical directly surfaces anomalous or conflicting actions (including cloud instance deletions that could indicate evasion), but only for the subset of duties/roles the organization has chosen to segregate or monitor.
- T1578.005prevents — A.5.3's segregation of conflicting duties (e.g. requesting/approving quota or policy changes, or designing/reviewing configs) directly stops a single compromised individual from unilaterally performing the T1578.005 modifications described, though it leaves open collusion, small-org impracticality, and post-compromise admin-role conflicts that the control itself flags as residual
- T1609prevents — A.5.3's segregation of duties (e.g. separating design/implement/review, develop/admin, use/admin) directly prevents the single-individual accumulation of permissions needed to abuse container admin services or roles for T1609 execution, though small-org exceptions, collusion risk, and non-role-based vectors leave a bounded remainder
- T1649prevents — A.5.3's segregation of duties (e.g. separating requesting/approving/implementing access rights, designing/implementing/reviewing code, and CA-related admin tasks) directly blocks single-user paths to enrollment rights, key access, and certificate forgery that enable T1649, but leaves theft vectors, misconfigurations, and collusion unaddressed.
- T1651prevents — A.5.3's segregation of duties (e.g., separating design/review, admin/use, or approval/execution of changes/access) directly constrains the single-account administrative paths that enable T1651 abuse of cloud management services, but leaves open collusion, small-org impracticality, delegated-provider compromise via T1199, and post-compromise admin use.
- T1657prevents — A.5.3's segregation of duties and role-conflict controls directly block single-insider execution of the conflicting steps (initiate/approve/execute change, request/approve/implement access, design/implement/review code, develop/administer systems, use/administer apps or DBs) that enable many of the technical-theft, BEC, unauthorized-transfer, and insider-fraud paths named in T1657; it has no bearing on purely external social-engineering, ransomware-extortion, or cryptocurrency-network exploitation slices of the technique.
- T1666prevents — A.5.3's segregation of conflicting duties (e.g., requesting/approving/implementing access rights, or designing/reviewing controls) directly stops a single insider from unilaterally performing the privileged actions that enable T1666 (CreateAccount, LeaveOrganization, subscription hijacking), but leaves the technique fully available to colluding actors, compromised accounts, or small-org exceptions where segregation cannot be enforced.
- T1671prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or using/administering applications) directly constrains the high-privileged consent and role-assignment steps that enable malicious OAuth integrations for persistence, but leaves many vectors (co-opting existing integrations, low-priv user consents, post-compromise abuse) untouched.
- T1677prevents — A.5.3's segregation of duties (e.g., separating design/implement/review of code, or initiating/approving/executing changes) directly blocks single-actor pipeline poisoning in Direct and Indirect scenarios and in role-conflict cases, but leaves Public Pipeline Execution (fork-based PRs) and self-hosted runner attacks largely untouched, plus small-org carve-outs and collusion risks.
- T1684prevents — A.5.3's segregation of duties (e.g., separating request/approve/implement access rights or initiate/approve/execute changes) directly blocks a single socially engineered user from completing the full chain of many T1684-induced actions, but leaves single-person approvals, help-desk scenarios, collusion, and non-approval social engineering vectors (e.g., disclosure or direct payload execution) untouched.
- T1685.002prevents — A.5.3's segregation of duties (e.g., separating requesting/approving/implementing access rights, or designing/implementing/reviewing controls) directly blocks a single insider from possessing the permissions needed to disable or modify cloud logging, though it does not stop all paths such as collusion, small-org exceptions, or external compromise granting those permissions.
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)
- A01mitigates — Segregation of duties limits the blast radius and bypass potential of a realized authorization failure (e.g., one person cannot both request+approve rights or design+review code that enforces access), but does not bound or reduce the consequence of most members of the broad A01 class such as path traversal, IDOR, missing function-level checks or CSRF.
- A01prevents — A.5.3 directly prevents the authorization-decision slice of A01 (e.g., conflicting roles for requesting/approving access rights or initiating/executing changes) by mandating separation that stops one person from bypassing controls; it leaves the remainder (path traversal, CSRF, IDOR, missing function-level checks) untouched.
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.