A.5.8 Organizational
Information security in project management
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
Mapped NIST 800-53 r5 controls (10)
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)
- SA-3mostlyaligns with — Both controls embed security risk assessment, requirements definition, and treatment activities into the project or system-development life cycle so that security is addressed from initiation through delivery.
- CM-3partialaligns with — Both ensure that security-related changes and risk-treatment progress are reviewed and approved at defined project or configuration-control gates.
- PL-2partialaligns with — Both require that security and privacy requirements—including risk treatment and compliance obligations—are documented and reviewed as part of project or system planning artifacts.
- RA-2partialaligns with — Both mandate early and recurring categorization of information assets and assessment of security risks within the context of projects or system initiatives.
- RA-3partialaligns with — Both require that project or system risks be formally assessed and treated, with periodic re-evaluation throughout the life cycle.
Aligned NIST CSF 2.0 outcomes (11)
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.RM-03mostlyaligns with — Embedding information security risk management into every project ensures cybersecurity risk activities are part of enterprise risk management processes.
- ID.RA-05mostlyaligns with — The control requires early and ongoing assessment of information security risks within projects so that risk responses can be prioritized and planned.
- ID.RA-06mostlyaligns with — Project governance must select, prioritize, and track information security risk-treatment actions throughout the project life cycle.
- GV.RR-02partialaligns with — The control mandates that project-specific roles, responsibilities, and authorities for information security are defined and allocated.
- GV.SC-05partialaligns with — Security requirements for third parties and suppliers are explicitly captured in project contracts and agreements.
- ID.RA-04partialaligns with — Projects must identify potential impacts and likelihoods of threats exploiting vulnerabilities when determining information security requirements.
Related OWASP ASVS 5.0 requirements (13)
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)
- V13.1.4partialaligns with — The ISO control's call for determining and scheduling rotation of critical project secrets aligns with the ASVS requirement to document the secrets essential to application security and their rotation schedule.
- V15.1.1partialaligns with — The ISO control's mandate to assess and treat information security risks early and throughout the project lifecycle directly supports the ASVS requirement for documented, risk-based remediation timelines for vulnerable third-party components.
- V2.1.1partialaligns with — Requiring information security requirements to be defined at the earliest project stages aligns with the ASVS need for documented input validation rules that specify how data items must be checked against expected formats and business constraints.
- V2.1.3partialaligns with — The ISO guidance to derive business-process requirements such as transaction logging, monitoring, and non-repudiation maps to the ASVS expectation that business-logic limits and validations are explicitly documented for both per-user and global contexts.
- V6.1.3partialaligns with — Specifying authentication requirements derived from the required level of identity assurance in project security requirements matches the ASVS need to document all authentication pathways together with their security controls.
- V8.1.1partialaligns with — Defining access-provisioning and authorization processes for customers, privileged users, and external suppliers in project requirements corresponds to the ASVS requirement that authorization documentation specify function-level and data-specific access rules based on consumer permissions.
Related weaknesses / CWE (14)
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-1068partialprevents — Project-level design-to-implementation traceability directly reduces divergence between documented design and delivered code.
- CWE-284partialprevents — Embedding security requirements and risk treatment into project governance forces explicit definition of access rules and roles before code or configuration is created, reducing the chance that access-control decisions are omitted or left to default.
- CWE-285partialprevents — Requiring authorization processes and privilege assignments to be specified during project initiation prevents downstream components from receiving overly broad or incorrect rights that would allow unauthorized actions.
- CWE-306partialprevents — Mandating authentication requirements for critical functions at the requirements-gathering stage ensures that essential operations are not left unprotected by missing login or verification mechanisms.
- CWE-435partialprevents — Project-level integration planning can surface interaction issues between components.
- CWE-657partialprevents — Embedding security in project management helps enforce secure design principles from the outset.
- CWE-732partialprevents — Project-level security requirements derived from policy and threat modelling drive the assignment of correct file, resource and configuration permissions rather than leaving them at insecure defaults.
- CWE-862partialprevents — Defining authorization responsibilities and reviewing risk-treatment progress throughout the project lifecycle catches missing authorization checks before the system is deployed.
- CWE-1059nonenone — Project-management security practices include producing design and operational documentation.
- CWE-269nonenone — Early determination of authentication and access-provisioning needs for privileged and technical users limits the introduction of unnecessary or excessive privileges that could later be exploited.
Mitigated MITRE ATT&CK techniques (6)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- T1190partialprevents — Requiring threat modelling and security requirements at project inception leads to design choices that close the common entry points adversaries exploit in public-facing applications.
- T1195partialmitigates — Embedding security requirements and risk treatment early in every project reduces the chance that an adversary can insert malicious code or components into the supply chain before delivery.
- T1059nonemitigates — Defining and enforcing application-security and access-control requirements during project execution limits the opportunities for adversaries to run arbitrary commands through insufficiently secured interfaces or scripts.
- T1078nonemitigates — Specifying authentication, authorization, and privileged-access requirements for all project deliverables reduces the likelihood that attackers can leverage stolen or misused valid accounts.
- T1087nonemitigates — Requiring explicit access-provisioning rules and monitoring during project delivery constrains the reconnaissance value an attacker can obtain by enumerating accounts created or modified for the project.
- T1550nonemitigates — Project-level controls on access provisioning and non-repudiation make it harder for adversaries to abuse stolen tokens or session material to move laterally with alternative authentication material.
Prevented OWASP Web Top 10 (2025) risks (5)
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)
- A02partialmitigates — Mandating that security requirements derived from policies, regulations, and threat modelling be captured in project deliverables reduces the chance that systems are deployed with default or insecure configurations.
- A06partialprevents — Embedding security requirements and risk treatment into project initiation and design phases forces security to be considered before code or architecture is created, directly reducing the likelihood that insecure design patterns are introduced.
- A01noneprevents — Requiring explicit access-provisioning, authorization, and authentication requirements early in projects ensures that access-control rules are defined and implemented rather than left as an afterthought.
- A07noneprevents — Specifying authentication-assurance levels and access-provisioning processes during project planning directly addresses the root causes of weak or missing authentication mechanisms.
- A09noneprevents — Requiring transaction logging, monitoring, and non-repudiation requirements as part of project deliverables ensures that logging and alerting capabilities are designed in rather than omitted.
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.