Information security is to be built into the way projects are managed. Purpose: make sure security risks tied to projects and their deliverables are handled effectively through every stage of the project. Guidance: this applies to every kind of project whatever its size, length, complexity or subject, whether a core business process, ICT, facilities or a support function. The project method should require that security risks are assessed and treated early and at intervals as part of project risk; that security requirements, such as application security (8.26) and intellectual property compliance (5.32), are dealt with early; that risks arising from running the project itself, such as internal and external communications, are handled throughout; and that progress on risk treatment is reviewed and its effectiveness evaluated and tested. Suitable people or bodies, such as a steering committee, check the security work at set stages, and project security responsibilities and authorities are assigned to named roles. Requirements for the product or service are derived from policies and regulation and from threat modelling, incident reviews, vulnerability thresholds and contingency planning, so the design resists known threats. For all project types consider: which information is involved, its classification (5.12) and the business impact of weak security; the confidentiality, integrity and availability needs of the assets; the assurance needed about identities, to set authentication requirements; access provisioning for customers, business users and privileged or technical users including project staff, operators and suppliers; telling users their duties; process-driven needs such as transaction logging, monitoring and non-repudiation; requirements imposed by other controls such as logging or leakage detection interfaces; legal, regulatory and contractual obligations; and the assurance needed that third parties meet the organization's policies, including contract clauses. Other information: waterfall or agile approaches should both support security in a structured way scaled to risk; ISO 21500, ISO 21502 and ISO/IEC 27005 give related guidance.
This control maps to 53 controls across 24 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 5.8 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 53 it maps to, and the evidence behind each claim, over MCP and REST.