ISO 27001A.5 — Information security in project management
A.5.8
Information security in project management
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Integrate information security into project management so projects deliver without introducing unmanaged risk.
Points of focus
- Security requirements identified in projects
- Risks assessed for significant changes
- Security tasks tracked to completion
- Go-live criteria include security acceptance
Implementation notes
Embed security checkpoints in your delivery system (issue templates, RFC reviews, launch docs). Scale rigor with risk — auth and data-path changes get threat modeling; copy tweaks do not. Link project security work to A.8.25–A.8.29 and change management. Keep SoA language honest about how projects inherit ISMS controls.
Audit tip: Walk one recent product launch: where was security in the timeline and what artifacts remain?
Evidence auditors typically request:
- Project/epic templates with security checklist
- Threat-model or design-review tickets
- Launch checklist with security sign-off
- Post-launch residual risk notes
Common gaps
- Security invited after code freeze
- Shadow IT projects bypass change and risk processes
- Checklist ticked without evidence attachments
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.5.8 | This control |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.5.8)
Frequently Asked Questions
No. Define triggers (new trust boundaries, privileged features, personal data flows) so reviews are risk-based.
Name a security or ISMS owner for high-risk launches; document the decision even when the answer is proceed-with-risk.
Often overlaps change and risk themes (CC8 / CC3). One project checklist can feed both programs.