Cyber Resilience

← ISO 27001 Annex A

A.5.23 Organizational

Information security for use of cloud services

AttributesPreventive C·I·A Protect Supplier relationships security Governance and Ecosystem Protection

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 (14)

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).

AC-20←M →P CA-6→P IR-4→P SR-2←M →P SR-3←M RA-3gov SA-9gov

Why these map — AI rationale (under review)

AC-20partialaligns with — Both address the need to establish security requirements and controls when organizational information is processed or stored on external systems.
AC-20partialcovers — A.5.23 addresses the full slice of cloud-service security requirements within ac-20's broader external-system usage policy, but leaves the non-cloud external systems, trust-relationship establishment, and outright prohibition options uncovered.
CA-6partialaligns with — Both require formal acceptance of residual risk by management before authorizing the use of external services.
CM-7partialaligns with — Both require organizations to restrict and control the functionality and scope of external services to only what is necessary and approved.
IR-4partialaligns with — Both require defined procedures for handling security incidents that occur within the environment of an external service provider.
SR-2partialaligns with — Both emphasize establishing a documented plan to manage supply-chain and third-party risks associated with external providers.
SA-9noneimplements — Both controls require organizations to define security responsibilities, obtain assurance, and manage risks when relying on external service providers for information processing.
CM-7covers — 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 (27)

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).

DE.CM-06gov GV.RR-02gov GV.SC-01gov GV.SC-02gov GV.SC-05gov GV.SC-06gov GV.SC-07gov GV.SC-08gov GV.SC-10gov ID.RA-10gov

Why these map — AI rationale (under review)

GV.SC-02partialaligns with — Defining and communicating roles and responsibilities between the organization and cloud providers satisfies the CSF outcome of establishing coordinated cybersecurity roles for suppliers.
GV.SC-06partialaligns with — The ISO control’s emphasis on pre-acquisition review of cloud agreements and risk assessments mirrors the CSF outcome of performing due diligence before entering supplier relationships.
GV.SC-10partialaligns with — The ISO control’s requirement for exit strategies and continued support after termination of cloud services matches the CSF outcome of including post-contract provisions in supply-chain risk plans.
ID.RA-10partialaligns with — The ISO control requires assessment of cloud service providers prior to use, which aligns with the CSF outcome of assessing critical suppliers before acquisition.
GV.SC-01noneimplements — The ISO control establishes a dedicated program, policies, and processes for managing cybersecurity risks arising from cloud service providers, which directly fulfills the CSF outcome of creating a supply-chain risk management program.
GV.SC-05noneimplements — By requiring the organization to define security requirements, responsibilities, and controls in cloud service agreements, the ISO control satisfies the CSF outcome of embedding cybersecurity requirements into supplier contracts.
GV.SC-07noneimplements — The ISO control mandates risk assessments, residual-risk acceptance, and ongoing monitoring of cloud providers, aligning with the CSF outcome of understanding, recording, and prioritizing supplier risks.
GV.SC-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.
GV.SC-06implements — A.5.23 operationalizes the supplier/cloud due-diligence outcome that GV.SC-06 names within the broader governance/supply-chain-risk domain; the link is by subject membership rather than explicit citation of planning steps.
GV.SC-10implements — 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.
ID.RA-10implements — 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 (4)

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).

V12.3.2←P V13.2.4←P V13.2.5←P V13.3.1←P

Related weaknesses / CWE (5)

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).

CWE-1357→P CWE-200→P CWE-284→P CWE-673←P

Why these map — AI rationale (under review)

CWE-673nonemitigates — Cloud-service governance limits external providers from redefining organizational control spheres.
CWE-1357prevents — Cloud-service security partially overlaps when the untrusted component is cloud-hosted.
CWE-200prevents — Requiring the provider to store and process sensitive data only in approved jurisdictions and to meet confidentiality objectives reduces the probability that data is disclosed to unauthorized parties through mis-configured storage or inadequate isolation.
CWE-284prevents — Explicitly assigning which party manages each access-control mechanism and requiring the provider to enforce the customer's access requirements reduces the chance that authorization decisions are omitted or left to default permissive settings.

Mitigated MITRE ATT&CK techniques (333)

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←M T1001.001←M T1001.002←M T1001.003←M T1006←M T1011←P T1020.001→P T1021→P T1021.007←M →P T1021.008←P →P T1027.001←M T1027.002←M T1027.006←M T1027.007←M T1027.008←M T1027.009←M T1027.010←M T1027.011←M T1027.014←M T1027.018←M T1036.003←M T1036.005←M T1036.008←M T1036.009←M T1036.012←M T1040→P T1048→P T1055←M T1055.001←M T1055.002←M T1055.003←M T1055.004←M T1055.005←M T1055.008←M T1055.009←M T1055.011←M T1055.012←M T1055.013←M T1055.014←M T1055.015←M T1059.009→P T1069.003→P T1070←M T1071←M T1071.001←M T1071.002←M T1071.003←M T1071.004←M T1072→P T1074.002←P T1078→P T1078.001←P →P T1078.004→P T1080→P T1090.002←M T1090.003←M T1090.004←M T1095←M T1098←P →P T1098.001←M →P T1098.002→P T1098.003→P T1098.004→P T1098.005←M →P T1098.006→P T1102←M T1102.001←M T1102.002←M T1102.003←M T1110→P T1110.001→M T1110.003→P T1110.004→P T1111←M →P T1127←M T1127.001←M T1127.003←P T1133←M →P T1134←M T1134.004←M T1136→P T1136.003→P T1137.001→P T1185←M T1190→P T1195→P T1195.002→P T1199←M →P T1202←M T1204.003←P →P T1204.004←M T1207←M T1211←P T1213→P T1213.003→P T1213.004→P T1216←M T1218←M T1218.005←M T1218.007←M T1218.008←M T1218.010←M T1218.011←M T1218.013←M T1221←M T1222←M T1222.001←M T1222.002←M T1480.001←M T1484←M →P T1484.002←M →P T1485←P →P T1485.001←M →M T1486→M T1489←P T1490←M →M T1496←P →P T1496.001←P →P T1496.003→P T1496.004→P T1497←M T1497.002←P T1498←P →P T1498.001←P T1499←P →M T1499.002←P →P T1525→P T1528→P T1530→P T1531→M T1535→P T1537←M →P T1538→P T1539←F →P T1542←M T1542.002←M T1548.005→P T1550←M T1550.001←F →P T1550.002←F T1550.003←F T1550.004←F →P T1552.001→P T1552.005→P T1552.008→P T1553.001←F T1553.002←M T1553.003←M T1553.004←M T1553.005←M T1553.006←M T1555.006→P T1556←M T1556.006←M T1556.007←M →P T1556.009←M →P T1561←M →M T1561.001→M T1561.002→M T1564.001←M T1566→P T1566.003←M →P T1567→P T1567.002←M T1567.004→P T1568←P T1568.002←M T1571←M T1572←M T1574←P T1574.001←M T1574.013←M T1578←M →P T1578.001←M T1578.002←M →P T1578.003←M →M T1578.004←M T1578.005←M →P T1580→P T1583.003←M T1583.007←M T1584←M →P T1584.001→P T1584.007←M →P T1586.003←P →P T1590.001→P T1590.003→P T1595.003→P T1598.001→P T1598.003→P T1599←M T1599.001←P T1600←P T1600.001←P T1601.001←P T1601.002←M T1606←M →P T1606.001←M T1606.002→P T1608.005←M T1610←P →P T1611←P →P T1612←M T1620←M T1621←P →P T1622←F T1647←M T1648→P T1649→P T1651→P T1653←P T1657→P T1665←P T1666←M →P T1671←M →P T1677←M →P T1678←P T1684→P T1684.001→P T1684.002→P T1685←M →P T1685.001←M T1685.002←M →P T1685.003←M T1685.004←M T1685.005←M T1685.006←M T1686←M T1686.001←M →P T1686.002←M T1686.003←M T1687←P T1688←M T1689←P T1690←M

Why these map — AI rationale (under review)

T1020.001prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policies, risk management, roles, control allocation, agreements, monitoring, incident handling, and exit strategies for cloud services (including IaaS), which can prevent adversaries from abusing native traffic mirroring features for exfiltration when properly configured and monitored, but leaves residual risk from misconfigurations, sub-contracted providers, or on-premises network devices.
T1021prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control clauses in agreements, and monitoring of cloud-provider commitments constrain adversary use of valid accounts against IaaS/SaaS remote services, but leave on-premises, non-cloud, and improperly-negotiated instances untouched.
T1021.007prevents — A.5.23 requires defining, communicating and enforcing topic-specific policy, risk management, roles, shared responsibilities, access-control requirements in agreements, MFA-capable auth where appropriate, incident handling, monitoring of service characteristics, and exit strategies; this constrains the T1021.007 technique in the policy, agreement, and governance layer but does not stop an already-compromised valid account from being used to log in.
T1021.008prevents — A.5.23 requires defining/managing cloud security requirements, roles, access controls, agreements, risk assessments, and monitoring that can constrain improper direct VM access via valid accounts, but does not mandate or enforce specific technical mechanisms (e.g. MFA, just-in-time access, or removal of default privileged console methods) that would stop the technique from running.
T1040prevents — A.5.23's policy, risk assessment, agreement provisions (e.g. encryption, access controls, malware protection, jurisdiction), and monitoring of cloud services can prevent sniffing of cleartext traffic in IaaS cloud environments by mandating proper TLS and controls, but this is limited to cloud usage and does not address on-premises Linux/macOS/Windows/network device sniffing or unencrypted protocols outside managed cloud agreements.
T1048prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, approved locations/jurisdictions, sub-contractor rules, monitoring, incident handling, and exit strategies) and shared-responsibility definition constrain many cloud exfil paths (esp. IaaS/SaaS console/API downloads) but leave non-cloud vectors, on-prem protocols, and unenforceable provider-side controls as a large residual.
T1059.009prevents — A.5.23's policy, risk assessment, role definition, control allocation, agreement provisions (access controls, incident handling, monitoring, change notification) and exit strategies directly constrain many abuse vectors of cloud APIs, but cannot prevent all (e.g. valid credentialed use after compromise or insider abuse).
T1069.003prevents — A.5.23 mandates defining, communicating, and enforcing topic-specific policy, roles, responsibilities, access-control requirements in agreements, and monitoring of cloud services, which constrains the adversary's ability to freely enumerate groups/permissions via authenticated tools and APIs; however, it does not eliminate the technique for all authenticated sessions or all cloud configurations.
T1072prevents — A.5.23's policy, risk assessment, shared-responsibility definition, agreement provisions (access controls, incident handling, change notification, backup, exit strategies) and ongoing monitoring directly constrain abuse of cloud-based deployment tools (AWS SSM, Intune, Azure Arc, GCP Deployment Manager) by setting selection criteria, required controls, and detection of failures, but leave on-premises/enterprise tools (SCCM, HBSS, Altiris), local-credential abuse, and non-cloud network devices mostly untouched.
T1078prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus explicit controls for cloud account management, access controls, roles/responsibilities, monitoring, and agreements that mandate MFA-capable auth and incident handling, which stops many (but not all) valid-account abuses in IaaS/SaaS/identity-provider platforms; it leaves local/domain/Windows/Linux accounts, inactive accounts, and non-cloud pivot paths untouched.
T1078.001prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-assessed controls (including access management, credential handling, change notification, and exit strategies) for cloud services; this directly constrains abuse of cloud-provider default accounts (e.g. AWS root, Kubernetes service accounts) but leaves non-cloud defaults, on-prem appliances, and post-setup defaults (e.g. vpxuser) outside its cloud-service scope.
T1078.004prevents — A.5.23's policy, risk assessment, role/responsibility definition, agreement provisions (access controls, MFA-supporting clauses, incident handling, monitoring), and exit strategies directly constrain many acquisition paths and misconfigurations that enable T1078.004, but cannot stop all credential-theft vectors (phishing, brute force on unscreened accounts) or every possible role-assumption flaw.
T1080prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements, malware-protection clauses, incident-handling procedures, change-notification rules, and backup provisions for cloud/shared services constrain the cloud/SaaS slice of T1080 (tainting of internal code repos or SaaS-shared storage) but leave the on-premises network-drive, binary-infection, and directory-share-pivot vectors on Windows/Linux/macOS untouched.
T1098prevents — A.5.23 requires defining, communicating, and enforcing policies, roles, responsibilities, access controls, and agreements that constrain how cloud accounts/permissions are managed and monitored, which prevents many forms of account manipulation in IaaS/SaaS/Identity Provider platforms; it does not reach on-prem, Linux, Windows, or non-cloud vectors named in the technique.
T1098.001prevents — A.5.23 requires defining/managing cloud security requirements, roles, access controls, agreements addressing confidentiality/integrity/availability, risk assessments, and monitoring of cloud usage, which constrains many avenues for adversaries to add unauthorized credentials (e.g., via policy, agreements, and oversight); however, it is governance-oriented and does not technically block the APIs or actions once an adversary has sufficient permissions.
T1098.002prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, roles/responsibilities, access control requirements in cloud agreements, and monitoring of cloud services (including Office 365/Google Workspace), which constrains the adversary technique of granting extra mailbox/folder permissions for persistence; however, it is governance-oriented and does not technically block the Add-MailboxPermission cmdlet or console actions when an account is already compromised.
T1098.003prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, roles/responsibilities, access-control requirements in agreements, risk assessments, and monitoring of cloud services (including IAM), which constrains the ability of an adversary to add roles/permissions for persistence; however, it is governance-level and does not technically block the APIs or actions when an account is already compromised.
T1098.004prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control clauses in agreements, and change-notification requirements can constrain adversary use of cloud APIs/CLI to add SSH keys to authorized_keys on IaaS VMs, but the control is silent on on-host file modification, non-cloud platforms (Linux/macOS/ESXi/Network Devices), and does not guarantee enforcement of the preventive clauses.
T1098.005prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, roles, shared responsibilities, selection criteria, access controls, incident handling, monitoring, and explicit provisions in cloud agreements (including MFA-related access controls and change notifications) that directly constrain adversary device registration in cloud MFA/IdP systems such as Okta, Duo, Entra ID, or Intune; this stops the technique at the policy/enforcement layer for covered cloud usage but leaves gaps for non-cloud identity providers, legacy self-enrollment paths, and on-premises device registration.
T1098.006prevents — A.5.23's policy, risk assessment, role/responsibility definition, access-control requirements in agreements, and monitoring of cloud-service characteristics directly constrain the cloud-provider-side RBAC/ABAC modifications that realize T1098.006 in managed Kubernetes offerings, but leave the local/container orchestration slice and the post-compromise modification of already-valid accounts untouched.
T1110prevents — A.5.23 requires defining/managing access controls, MFA-capable agreements, failed-login handling, and monitoring in cloud SLAs, which can block many online brute-force attempts on cloud accounts; it does not address offline attacks, non-cloud vectors, or guarantee enforcement strength.
T1110.001prevents — A.5.23 requires topic-specific policy, risk assessment, shared-responsibility definition, access-control requirements in cloud agreements, MFA-capable authentication strength proportionate to data sensitivity, and monitoring/reporting of failures, all of which stop password guessing against cloud/SaaS/Office 365/IaaS services from succeeding; the bounded remainder is on-premises or non-cloud vectors (e.g. local SSH, RDP, LDAP on non-cloud assets) that the control does not address.
T1110.003prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, MFA-capable auth, incident handling, monitoring), and shared-responsibility definition for cloud services constrain password spraying against cloud/SaaS/SSO/federated targets (explicitly called out in the TTP), but do not reach on-premises, non-cloud, or unmanaged services that the technique also targets.
T1110.004prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, MFA-capable auth, incident handling, monitoring), and shared-responsibility definition directly constrain credential-stuffing success vectors on cloud/SaaS/SSO targets, but leave on-premises, non-cloud, and non-negotiable-provider gaps untouched.
T1111prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-managed cloud agreements that can mandate MFA-appropriate controls (e.g., secure token handling, access controls, incident response for MFA compromise, and provider capabilities), which prevents some interception vectors when MFA is delivered via cloud services, but leaves the majority of on-premises/local MFA interception techniques (keyloggers, hardware token capture, local device compromise) untouched.
T1133prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, incident handling, change notification, sub-contractor controls), and monitoring of cloud services constrain many external remote service configurations and shared-responsibility exposures but leave slices such as unauthenticated exposed container APIs, Tor hidden services, and non-cloud remote services untouched.
T1136prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, roles, responsibilities, access controls, risk assessments, and cloud agreements that can constrain or block unauthorized account creation in cloud tenants, but leaves local/system-level creation, non-cloud platforms, and implementation gaps unaddressed.
T1136.003prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, roles/responsibilities, selection criteria, shared-responsibility controls, agreements addressing access controls, and monitoring of cloud services; this constrains the creation of unauthorized accounts (including low-privilege ones for persistence) in governed environments but leaves residual gaps for insider abuse, misconfigurations, or unmonitored sub-contracted services.
T1137.001prevents — A.5.23's topic-specific policy, risk assessment, macro-handling clauses in agreements, and controls for trusted locations/macros constrain the technique on managed cloud-hosted Office instances but leave local client-side template abuse and enterprise policy gaps untouched.
T1190prevents — A.5.23's policy, risk assessment, control allocation, agreement provisions (access controls, malware protection, secure locations, incident support, backups, change notification) and ongoing monitoring directly constrain many cloud-specific slices of T1190 (IaaS/container misconfigs, weak IAM, exposed services, sub-contractor risks) but leave non-cloud platforms, unpatched software bugs, and on-prem public-facing apps untouched.
T1195prevents — A.5.23 requires defining, risk-assessing, and contractually mandating security requirements, responsibilities, controls, incident handling, monitoring, and exit strategies for cloud services (including sub-contractors and supply-chain elements like updates or third-party providers), which constrains many supply-chain manipulation vectors in cloud contexts but leaves non-cloud, hardware, open-source dependency, and pre-contract manipulation slices untouched.
T1195.002prevents — A.5.23 requires defining security requirements, selection criteria, risk assessments, agreements addressing integrity/malware/access controls, sub-contractor clauses, and exit strategies for cloud services, which can prevent some supply-chain manipulation vectors (e.g., compromised updates or sub-contracted providers) but leaves many others (e.g., upstream source-code manipulation before cloud involvement) unaddressed.
T1199prevents — A.5.23's policy, risk assessment, role/responsibility definition, control allocation, agreement provisions (access controls, sub-contractor rules, incident support, change notification), and monitoring of cloud/third-party providers directly constrain the elevated-access and shared-responsibility vectors that enable T1199 supply-chain compromise, but leaves residual paths (e.g., non-cloud contractors, unmonitored legacy relationships, or post-agreement compromise of the provider itself).
T1204.003prevents — A.5.23's policy, risk assessment, selection criteria, shared-responsibility definition, agreement provisions (malware protection, access controls, standards, sub-contractor vetting, incident support), and ongoing monitoring directly constrain the supply and mistaken deployment of backdoored images in IaaS/container environments, but cannot stop an adversary from uploading one or a user from still selecting it.
T1213prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements in agreements, and monitoring of cloud services directly constrain the cloud-hosted repository misconfigurations that the technique explicitly highlights as the dominant exploitation path.
T1213.003prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements in agreements, incident-handling procedures, and monitoring of cloud services directly constrain the SaaS code-repository vector that T1213.003 names, but do not reach the internal/on-premises repository case or block post-compromise collection once access is already obtained.
T1213.004prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements, incident-handling procedures, monitoring approach, and exit/backup provisions for cloud services (including SaaS CRM) directly constrain the post-breach mining technique on cloud-hosted instances, but leave on-premises CRM, incomplete implementations, and pre-breach access entirely unreached.
T1484prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-assessed agreements that explicitly address access controls, change notification, and configuration/infrastructure integrity for cloud identity/tenant services; this constrains many of the tenant-policy modifications named in T1484 (especially federation, trust, and GPO-like settings in cloud IdPs) but leaves on-premises AD GPO abuse and already-compromised admin sessions untouched.
T1484.002prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, sub-contractor rules, change notification, incident handling), and monitoring of cloud/identity services constrain many trust-modification vectors in cloud tenants but leave on-premises AD, non-cloud identity providers, and insider/admin abuse of legitimate trust changes largely unreached.
T1485prevents — A.5.23's policy, risk assessment, shared-responsibility definition, backup/restore provisions, incident handling, exit strategies, and change-notification requirements directly constrain or block many cloud-specific vectors of T1485 (e.g., unauthorized deletion of storage objects, VMs, or infrastructure via poorly governed CSP access), but leave on-premises, non-cloud, and insider-abuse vectors untouched.
T1485recovers — A.5.23 explicitly requires agreements to include backup/restore capabilities, exit strategies, and support for returning data/configs, which enables recovery from cloud-side data destruction (the technique's explicit cloud vector); this is only a slice of the full technique that also covers on-prem/local overwriting and worm-like propagation.
T1485.001prevents — A.5.23 requires defining policies, risk assessments, roles/responsibilities, cloud agreements addressing data protection/backup/availability, incident handling, monitoring, and exit strategies (including lifecycle-impacting changes), which can prevent adversaries from gaining the permissions or unchecked ability to set destructive lifecycle policies in many cases, but leaves residual gaps in enforcement, sub-contractor controls, and technical permission enforcement.
T1485.001recovers — A.5.23 explicitly requires agreements to include backup/restore provisions for data and configuration plus exit strategies that support availability and return of owned information, directly enabling recovery from lifecycle-triggered deletion of cloud objects.
T1486recovers — A.5.23 explicitly requires agreements to include backup/restore provisions for data and configuration plus exit strategies that return owned data, directly enabling recovery of the encrypted state addressed by T1486 (including in cloud/IaaS).
T1486responds — A.5.23 explicitly requires defining procedures for handling incidents related to cloud services, dedicated provider support during incidents, and maintaining contacts for mutual exchange/reporting of security events including failures, which enacts containment/eradication once ransomware encryption is underway in cloud environments (the technique's explicit IaaS slice).
T1490recovers — A.5.23 explicitly requires agreements to mandate provider backup/restore capabilities, exit strategies, and support for recovering organization-owned data/snapshots/configs when cloud-based recovery features are targeted by T1490.
T1496prevents — A.5.23's policy, risk assessment, shared-responsibility definition, SLA provisions (access controls, malware protection, incident support, backups, change notification, exit strategies) and ongoing monitoring directly constrain several cloud-specific hijacking vectors (cryptomining on IaaS, spam abuse of messaging services, unauthorized bandwidth resale) but leave non-cloud platforms, sub-contracted unmanaged instances, and post-breach execution outside its reach.
T1496.001prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements, incident-handling procedures, monitoring approach, and exit strategies directly constrain cloud-specific hijacking vectors (e.g., exposed APIs, unauthorized compute usage, sub-contracted abuse) but leave non-cloud platforms, endpoint compromise paths, and post-breach execution untouched.
T1496.003prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policies, risk management, shared responsibilities, selection criteria, incident handling, monitoring, and contractual provisions (e.g., access controls, malware protection, sub-contractor rules, backup, change notification) for cloud services; this constrains the cloud-hosted messaging/OTP infrastructure that adversaries abuse for SMS pumping on SaaS platforms, but leaves residual gaps such as non-cloud vectors, incomplete enforcement, or pre-existing vulnerable forms.
T1496.004detects — A.5.23 explicitly requires defining procedures for handling cloud incidents, monitoring/evaluating ongoing cloud use to manage risks, obtaining assurance on provider controls, maintaining close contact for mutual exchange of security information, and mechanisms to monitor service characteristics and report failures, which surfaces anomalous resource-intensive SaaS usage like spam/LLMJacking but only as a named slice of the full technique (e.g., does not mandate specific detection instrumentation or cover all enabling/pre-hijack behaviors).
T1496.004prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, incident handling, monitoring, change notification, exit strategies), and shared-responsibility definition directly constrain the abuse vectors (unauthorized enablement, hijacking of SaaS for resource exhaustion/spam/LLMJacking) when services are selected and contracted, but cannot stop post-compromise adversary use of already-authorized SaaS credentials or sub-contracted abuse outside the agreement's reach.
T1498prevents — A.5.23's policy, risk assessment, shared-responsibility definition, incident-handling procedures, monitoring approach, and agreement provisions for DDoS-capable controls (access management, malware protection, backup, notification of changes, dedicated incident support) constrain or block several vectors and impacts of network DoS when services are cloud-hosted, but do not stop the core technique of bandwidth exhaustion from external botnets or spoofed floods.
T1498recovers — A.5.23 requires defining exit strategies, backup/restore support in agreements, and availability commitments that enable recovery of service and data post-DoS impact, but this is limited to cloud-specific usage and does not broadly restore availability for non-cloud or on-premises targets.
T1499prevents — A.5.23's policy, risk assessment, SLA provisions (e.g. availability objectives, backup, incident support, change notification, access controls, malware protection) and monitoring of cloud-provider commitments can stop some classes of endpoint DoS that rely on weak cloud configurations or unmonitored provider failures, but leaves the bulk of resource-exhaustion, botnet, spoofing and application-layer techniques on IaaS/containers unaddressed.
T1499recovers — A.5.23 explicitly requires agreements to include backup/restore capabilities, exit strategies, and support for service availability when exiting cloud services, directly enabling recovery of availability after an endpoint DoS impacting hosted services (especially IaaS).
T1499.002prevents — A.5.23 requires defining, agreeing, and enforcing cloud-specific security requirements, controls, SLAs, incident handling, monitoring, and exit strategies that can include rate limiting, resource quotas, DDoS protections, and provider-managed availability measures, which prevent many service exhaustion floods in IaaS cloud environments but leave on-premises, non-cloud, and certain volumetric or misconfiguration-based cases untouched.
T1499.002recovers — A.5.23 explicitly requires agreements to include backup of data/configuration, support/availability during exit, and procedures for handling incidents tied to cloud services, enabling recovery of state after a service-exhaustion DoS (especially on IaaS platforms).
T1525prevents — A.5.23 requires defining, communicating and enforcing topic-specific policy, risk assessment, roles/responsibilities, control allocation, secure agreements, monitoring, incident handling and exit strategies for cloud services; this constrains the ability of an adversary who has already gained access to freely implant a malicious image in a victim registry by mandating controls that can block unauthorized registry writes and image changes, but leaves a genuine residual slice (e.g., insider or sub-contractor actions, incomplete enforcement, or images outside monitored scopes) so the prevention is not the bulk of the class.
T1528prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, incident handling, sub-contractor requirements, monitoring), and shared-responsibility definition directly constrain many cloud/SaaS/IaaS token-theft vectors (e.g., weak OAuth grants, unmanaged identities, unmonitored sub-contractors), but leave residual paths such as social-engineering consent, container compromise inside the tenant boundary, and CI/CD pipeline token theft that the clause does not address.
T1530prevents — Mandating contractual controls on data location, encryption, and access restrictions directly constrains an attacker’s capacity to collect data stored in cloud object storage without detection.
T1530detects — A.5.23 explicitly requires defining procedures for handling cloud-related incidents, maintaining close contact with providers for mutual exchange of security information, monitoring service characteristics, and reporting failures to commitments, which surfaces knowledge of access or misconfiguration events against T1530 but only for organization-managed aspects and agreed provider reporting, leaving the dominant initial-access vector (public buckets or credential abuse) outside guaranteed detection scope.
T1531prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control clauses in agreements, incident-handling procedures, and change-notification requirements constrain how cloud/SaaS/IaaS accounts can be manipulated or revoked at the provider level, but do not stop on-premises account deletion, local passwd/esxcli use, or post-compromise execution of the technique.
T1531recovers — A.5.23 explicitly requires agreements to include backup/return of configuration files, source code, data owned by the customer plus support and availability for an appropriate time frame when exiting the cloud service, directly enabling recovery of account access and resources after T1531-style removal (especially in SaaS/IaaS contexts).
T1535prevents — A.5.23 requires defining cloud service selection criteria, approved locations/jurisdictions, risk assessments, monitoring of service characteristics, and advance notification of changes including new jurisdictions, which directly constrains use of unmonitored or detection-poor regions and thereby stops the technique from succeeding in many cases, but leaves residual where selection criteria or monitoring are incompletely enforced.
T1537prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, roles, controls allocation, agreements, monitoring, incident handling, and exit strategies for cloud services, which directly constrains the legitimate pathways (e.g. access controls, sharing mechanisms, backup procedures, sub-contractor rules) adversaries abuse for T1537; this is a genuine but minority slice because the control is governance-oriented and cannot stop all post-compromise abuse of valid cloud APIs or insider-like transfers once access is obtained.
T1538prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, roles, access controls, monitoring, incident handling, and risk acceptance for cloud services, which can prevent dashboard access via stolen credentials when those policies enforce MFA, least-privilege roles, or monitoring that blocks the technique; however, it is governance-level and leaves many configuration-specific dashboard exposures (e.g., overly permissive IAM) as residual.
T1539prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control clauses, incident-handling procedures, and monitoring requirements for cloud services constrain cookie-theft vectors that target SaaS/cloud-auth cookies (e.g. via provider-side protections, MFA enforcement, or exit strategies), but leave untouched the many local-browser, malware, JS-injection, and proxy-based vectors on non-cloud endpoints.
T1548.005prevents — A.5.23 requires defining, communicating, and enforcing policies, roles, responsibilities, access controls, risk assessments, and agreements that directly address temporary elevated access mechanisms (JIT, impersonation, PassRole) and their misconfigurations, closing many but not all escalation paths (e.g., residual risks accepted by management or unmonitored sub-contractor changes remain).
T1550.001detects — A.5.23 explicitly requires defining procedures for handling cloud-related incidents, maintaining close contact with providers for mutual exchange of security information, monitoring service characteristics, and reporting failures to commitments, which surfaces token-abuse anomalies in the cloud/SaaS layer but leaves non-cloud vectors, provider-side detection gaps, and custom implementations outside its defined scope.
T1550.001prevents — A.5.23 requires defining/managing cloud-specific security requirements, shared responsibilities, access controls, agreements, monitoring, incident handling, and exit strategies that can stop many token-theft paths (e.g., via provider-managed access controls, MFA-equivalent token protections, sub-contractor clauses, and misuse monitoring), but leaves residual gaps such as client-side token theft, misconfigured permissions, and non-negotiable SaaS agreements that still allow the technique.
T1550.004detects — A.5.23 explicitly requires defining procedures for handling cloud-related incidents, obtaining assurance on provider controls, monitoring/evaluating ongoing cloud use for risks, maintaining close contact with providers for mutual exchange of security information including failure reporting, and supporting digital evidence gathering; this surfaces session-cookie abuse in cloud/SaaS environments as anomalous behavior or incident but only for the subset of cloud services under agreement (not all possible web apps or non-cloud vectors), leaving a large remainder.
T1550.004prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, shared responsibilities, access-control requirements in cloud agreements, MFA-supporting controls, incident handling, monitoring, and exit strategies that directly constrain session-cookie theft and reuse in cloud/SaaS environments, but leaves residual gaps in non-cloud platforms, implementation details, and post-compromise cookie import.
T1552.001prevents — A.5.23's policy, risk assessment, shared-responsibility definition, agreement provisions (access controls, malware protection, backup handling, change notification), and monitoring directly constrain insecure credential storage in cloud/container configs and logs, but leave on-premises file-system and non-cloud credential files untouched.
T1552.005prevents — A.5.23 requires defining/managing cloud security requirements, shared responsibilities, access controls, agreements addressing confidentiality/integrity/availability, and risk assessments that can prevent the technique when the CSP implements metadata protections (e.g. IAM roles, IMDSv2) and the customer enforces them; this is only a slice of the class because the control is governance-oriented, does not mandate specific technical blocks, and leaves residual paths (e.g. SSRF, misconfigurations) unaddressed.
T1552.008prevents — A.5.23's policy, risk assessment, shared-responsibility definition, agreement provisions (access controls, malware protection, incident handling, backups, change notification) and ongoing monitoring directly constrain many cloud-hosted chat scenarios (SaaS/Office Suite) where credentials are exposed, but leave residual paths such as on-endpoint collection, sub-contractor gaps, and non-cloud comms channels unaddressed.
T1555.006prevents — A.5.23 requires defining/managing cloud security requirements, roles, access controls, agreements, risk assessments, and monitoring that can block insufficiently-privileged access to secrets managers, but does not stop the technique when an adversary already holds sufficient privileges (the technique's explicit precondition).
T1556.007prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, shared responsibilities, selection criteria, controls allocation, agreements addressing access controls/MFA/incident support/backups, change notification, and ongoing monitoring for cloud services (including hybrid identity setups), which constrains many vectors for backdooring hybrid auth processes but leaves residual gaps such as on-premises compromise paths, incomplete enforcement of agreements, and non-cloud-managed components.
T1556.009prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-managed agreements that mandate cloud providers implement and maintain access controls (including conditional/IAM policy enforcement) meeting organizational requirements; this constrains the adversary technique on managed cloud services but leaves residual gaps for direct privileged modification of policies, sub-contracted providers, and non-negotiable pre-defined agreements.
T1561recovers — A.5.23 explicitly requires agreements to include backup/restore provisions for data and configuration plus exit strategies that support availability of services after an incident, directly enabling recovery from disk-wipe effects on customer-owned assets.
T1561.001recovers — A.5.23 explicitly requires agreements to include backup/restore provisions for data and configuration plus exit strategies that support availability of services, directly enabling recovery from disk-wipe impact (the technique's core availability goal).
T1561.002recovers — A.5.23 explicitly requires cloud agreements to mandate provider backup/restore capabilities for data and configuration plus exit strategies that preserve/return owned information, directly enabling recovery from a disk-structure wipe that has already rendered systems unbootable.
T1566prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, malware protection, incident handling, sub-contractor controls), and monitoring of cloud services can prevent some phishing vectors that rely on compromised cloud accounts, third-party SaaS platforms, or sub-contracted services, but leaves the dominant vectors (e.g., direct email spoofing, social engineering, attachments/links targeting endpoints) untouched.
T1566.003prevents — A.5.23's topic-specific policy, risk management, shared-responsibility definition, cloud-service agreements, monitoring of providers, and exit strategies can constrain or prohibit use of risky third-party services (e.g. personal webmail/social media) that adversaries exploit for spearphishing, but this is only a slice of the technique's surface (organizational policy on external services does not stop all adversary-created accounts, rapport-building, or user behavior on permitted services).
T1567prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, data handling, incident support, sub-contractor rules, backups, change notification) and monitoring of cloud services can block many legitimate-web-service exfiltration paths when the service is organizationally approved/used, but leaves open unvetted SaaS, sub-contracted providers, and non-cloud web services that the technique also names.
T1567.004prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, incident handling, monitoring, data handling, sub-contractor rules), and exit strategies can block many webhook-based exfiltration paths that rely on abused SaaS/collaboration services or unvetted cloud usage, but leaves residual cases (e.g., direct manual posts, insider-enabled links, or approved services with blended HTTPS traffic) unaddressed.
T1578prevents — A.5.23's policy, risk assessment, role definition, agreement provisions (access controls, incident handling, change notification, backup), and monitoring directly constrain many T1578 vectors (e.g. unauthorized creation/deletion/modification of instances or snapshots) but leave residual paths via legitimate-but-abused admin privileges or unmonitored sub-contractor changes.
T1578.002prevents — A.5.23 requires defining, communicating, and enforcing policies, risk assessments, roles, controls allocation, agreements, monitoring, and exit strategies for cloud services, which can constrain unauthorized or risky instance creation in IaaS; however, it is governance-oriented and does not directly block the technical execution of the technique.
T1578.003detects — A.5.23 explicitly requires defining procedures for handling cloud incidents, obtaining assurance on provider controls, monitoring/evaluating ongoing cloud use for risks, maintaining close contact with providers for mutual exchange and failure reporting on service characteristics, and gathering digital evidence — all of which surface the deletion (or its forensic gap) once it occurs, but only for the subset of instances covered by the organization's monitoring scope, agreements, and provider capabilities.
T1578.003recovers — A.5.23 explicitly requires defining exit strategies, support/availability for exit, backup of data/configuration, and returning owned information (including at termination), which directly enables recovery of state after an adversary deletes a cloud instance.
T1578.005prevents — A.5.23 requires defining, communicating, and enforcing policies, roles, responsibilities, selection criteria, risk assessments, agreements, and monitoring for cloud services (including access controls, change notification, and configuration management), which constrains the ability of adversaries (or insiders) to unilaterally modify quotas, tenant policies, or deployment settings without detection or approval processes.
T1580prevents — A.5.23 requires defining, communicating, and enforcing policies, roles, responsibilities, access controls, monitoring, incident handling, and agreements that can constrain or block many discovery paths (e.g., least-privilege IAM, approved locations, change-notification rules, and monitoring of service characteristics), but cannot prevent all legitimate-API or post-compromise enumeration in IaaS environments where some discovery remains inherent to authorized use.
T1584prevents — A.5.23's policy, risk assessment, agreement provisions, shared-responsibility definition, and monitoring requirements for cloud services directly constrain an organization's own use or acquisition of compromised third-party cloud infrastructure, closing that named slice of T1584; the remainder (adversary compromise of non-cloud infrastructure, botnets, domains, or other adversaries' infra) is untouched.
T1584.001prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, roles, agreements, access controls, incident handling, monitoring, and exit strategies for cloud services, which directly prevents the vector of compromising a cloud service (e.g. AWS Route53) to hijack domains; this is only a slice of the full technique that also includes email compromise, social engineering help desks, renewal gaps, subdomain hijacking via dangling DNS, and domain shadowing.
T1584.007prevents — A.5.23 requires defining/managing security requirements, risk assessments, shared responsibilities, access controls, incident handling, monitoring, and exit strategies for cloud services (including serverless), which can prevent some compromises of serverless infrastructure used in targeting, but leaves residual risks from unaddressed vulnerabilities, misconfigurations, or provider-side issues.
T1586.003prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, MFA-capable auth, incident handling, monitoring), and shared-responsibility definition directly constrain several compromise vectors (weak credentials, poor access config, undetected incidents) for customer-managed cloud accounts, but leave untouched reconnaissance, phishing-for-info, token theft, third-party credential markets, and provider-side privileged accounts.
T1590.001prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policies, risk assessments, agreements, shared responsibilities, access controls, data location/jurisdiction rules, incident handling, monitoring, and exit strategies for cloud services, which can prevent exposure of domain properties via cloud APIs (e.g., Office 365 autodiscover) by mandating secure configurations and agreements; however, it does not address non-cloud exposures like WHOIS, DNS data sets, active scanning, or phishing for information.
T1590.003prevents — A.5.23's policy, risk assessment, agreement provisions, sub-contractor controls, and monitoring of cloud/third-party relationships directly constrain discovery and exploitation of MSP/contractor trust dependencies that arise from cloud usage, but leave non-cloud third-party trusts, public data exposure, and pre-existing relationships untouched.
T1595.003prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, monitoring, sub-contractor controls, change notification), and ongoing review can block or constrain many cloud-specific wordlist scans (e.g. public buckets, hidden portals) via contractual and configuration means, but leaves the generic web-crawling slice of the technique untouched.
T1598.001prevents — A.5.23's topic-specific policy, risk management, shared-responsibility definitions, incident-handling procedures, monitoring approach, and requirements for provider agreements (e.g., access controls, malware protection, incident support) constrain the use of third-party cloud/social services and reduce the attack surface for spearphishing via them, but do not stop the adversary technique itself from being executed against users.
T1598.003prevents — A.5.23's topic-specific policy, risk assessment, shared-responsibility definition, incident-handling procedures, monitoring approach, and agreement provisions for access controls/malware protection/support can constrain cloud-based delivery or response to spearphishing links (especially when the cloud service is email, collaboration, or web hosting), but the control is governance-oriented and does not stop the social-engineering technique itself.
T1606prevents — A.5.23 requires defining/managing cloud-specific security requirements, shared responsibilities, access controls, agreements addressing confidentiality/integrity/availability, and monitoring of cloud services, which constrains many (but not all) cloud-hosted forging paths such as abuse of AssumeRole/GetFederationToken or weak token issuance; it does not reach on-prem, non-cloud, or non-SaaS/IaaS vectors named in the technique.
T1606.002prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus explicit controls (access management, MFA-capable agreements, incident handling, monitoring of service characteristics, and risk acceptance) that can stop forged SAML tokens from succeeding in many cloud/SaaS/IdP scenarios, but leaves residual paths (e.g., compromised on-prem signing certs, non-negotiable SLAs, sub-contracted providers, or non-cloud identity providers) untouched.
T1610prevents — A.5.23's policy, risk assessment, role definition, control allocation, agreement provisions (access controls, malware protection, incident handling, change notification, backup), and monitoring directly constrain many deployment vectors and insecure configurations for cloud/K8s containers, but do not block all means (e.g., local Docker APIs, malicious images at runtime, or sub-contractor bypasses).
T1611prevents — A.5.23 requires defining security requirements, selection criteria, roles, shared responsibilities, controls allocation, agreements addressing access controls/malware/backup/isolation, risk assessments, and monitoring of cloud services, which constrains many container/VM escape vectors (e.g. privileged containers, bind mounts, sub-contractor risks) but leaves residual paths such as unaddressed kernel exploits, unmonitored ESXi hypervisor flaws, or incomplete enforcement of isolation in multi-provider setups.
T1621prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-managed cloud agreements that can mandate MFA-appropriate authentication strength, access controls, and incident handling for cloud/IaaS/SaaS/IdP usage, which constrains the MFA-fatigue bypass technique in those environments but leaves non-cloud platforms, legacy MFA, and unenforced policy slices untouched.
T1648prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk assessment, shared-responsibility delineation, selection criteria, access-control requirements, incident-handling procedures, monitoring, and exit strategies for cloud services (including serverless), which constrains many abuse vectors in T1648 but leaves residual paths such as legitimate-but-maliciously-configured functions or sub-contracted services that still allow arbitrary code execution.
T1649prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements in agreements, and monitoring of cloud providers constrain certificate issuance, storage, and sub-contractor handling in cloud environments, but do not reach on-premises AD CS misconfigurations, golden-certificate forgery via root-key compromise, or local theft via crypto APIs that dominate the technique.
T1651prevents — A.5.23's policy, risk assessment, role/responsibility definition, control allocation, agreement provisions (access controls, incident handling, monitoring), and exit strategies directly constrain abuse of cloud admin services for command execution in IaaS VMs, but only for customer-managed portions and do not block all admin-compromise or provider-side paths.
T1657prevents — A.5.23's policy, risk assessment, shared-responsibility definition, contract provisions (access controls, incident handling, backups, exit strategies, sub-contractor rules) and monitoring directly block or raise the bar for several T1657 vectors (BEC/social-engineering transfers, ransomware extortion, account compromise in cloud/SaaS environments) but leave non-cloud technical theft, pure social-engineering outside cloud, and many pre-cloud financial-theft paths untouched.
T1666prevents — A.5.23 requires defining, communicating, and enforcing policies, roles, responsibilities, controls allocation, agreements, risk assessments, monitoring, incident handling, and exit strategies for cloud services, which directly constrains the ability of adversaries (internal or via compromised accounts) to freely modify hierarchies without detection or policy violation in many cases, but leaves residual gaps for privileged accounts or unmonitored changes.
T1671detects — A.5.23 explicitly requires defining procedures for handling cloud incidents, maintaining close contact with providers for mutual exchange of security information, monitoring service characteristics, and reporting failures to commitments, which surfaces anomalous or malicious OAuth integrations after they are created/used.
T1671prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy, risk management, roles/responsibilities, selection criteria, shared-responsibility delineation, incident handling, monitoring, and explicit agreement provisions on access controls, MFA-supporting tokens, sub-contractor vetting, and change notification; these directly constrain the OAuth consent, application creation, and integration-persistence pathways named in T1671, but leave open the residual slice of already-consented malicious apps, insider consent from high-privilege accounts, and unmonitored legacy integrations that survive account disablement.
T1677prevents — A.5.23's policy, risk assessment, shared-responsibility definition, access-control requirements, incident-handling procedures, change-notification rules, and exit-strategy mandates for cloud CI/CD services constrain several poisoning vectors (especially public-pipeline and self-hosted-runner scenarios) but do not stop direct or indirect injection by an authorized insider or compromised account.
T1684prevents — A.5.23's topic-specific policy, risk management, role definitions, incident handling procedures, monitoring approach, and awareness of social-engineering vectors in cloud/SaaS consent mechanisms and vendor/help-desk scenarios constrain the technique in the cloud-service slice but leave the bulk of human-targeted social engineering (phishing, voice, scare tactics across non-cloud channels) untouched.
T1684.001prevents — A.5.23's policy, risk assessment, agreement provisions (access controls, incident handling, sub-contractor vetting, notification of changes), and monitoring of cloud providers directly constrain impersonation risks when the technique uses or targets cloud services (e.g., vendor impersonation via SaaS email or sub-contracted providers), but this is only a slice of the broad social-engineering technique that succeeds via non-cloud vectors and human factors.
T1684.002prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-managed cloud agreements that can mandate SPF/DKIM/DMARC configurations, access controls, and incident handling for cloud email services, thereby preventing many (but not all) email-spoofing vectors when those services are in scope.
T1685prevents — A.5.23's policy, risk assessment, SLA provisions (e.g. malware protection, monitoring, incident support, backups, change notification) and shared-responsibility definition for cloud services constrain some vectors of T1685 that target cloud monitoring agents, logging pipelines, or cloud defensive tools, but do not reach on-host, network-device, or non-cloud tampering techniques that dominate the class.
T1685.002prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-managed controls (including logging-related requirements in agreements, monitoring, incident handling, and provider capabilities) that can stop an adversary from disabling/modifying cloud logging when those controls are contractually mandated and implemented; this reaches only a slice because pre-defined non-negotiable agreements, residual risks accepted by management, and incomplete coverage of all sub-contractor or multi-provider scenarios leave real gaps where the technique can still succeed.
T1686.001prevents — A.5.23 requires defining, communicating, and enforcing topic-specific policy plus risk-managed controls (incl. access controls, agreements mandating provider-managed firewalls/security groups, monitoring, and change notification) that can stop an adversary from successfully modifying cloud firewalls when followed; it does not guarantee prevention because pre-defined non-negotiable agreements, residual accepted risks, and incomplete implementation leave exploitable gaps.

Prevented OWASP Web Top 10 (2025) risks (4)

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).

A02←P →P A07←P A09←M

Why these map — AI rationale (under review)

A02mitigates — A.5.23 requires defining, agreeing and monitoring cloud-specific security configurations, responsibilities, baselines and change notifications, which bounds the attack surface left by weak defaults or incomplete hardening in cloud settings, but does not itself harden, configure or remove the misconfigured elements.

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.