Most security debt is created inside projects, when deadlines win and nobody with the authority to say "not yet" has asked the security questions in time. ISO/IEC 27001:2022 Annex A control 5.8 asks organisations to integrate information security into project management for every project, whatever its type, size or delivery method. This guide turns that requirement into something a project office can run: which security activities belong at which stage gate, who owns the decisions, what evidence an auditor will look for, and how to make it work for agile teams and small projects without a heavy process. It is written for security managers, PMO leads, delivery managers and ISMS owners. For secure software engineering detail, see the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide; this page covers the project governance around it.
Key takeaways
- Control 5.8 applies to all projects, not just IT builds. Office moves, supplier changes, data migrations, mergers and process redesigns all change risk and all fall in scope.
- Security is a gate criterion, not a review at the end. Classify the project at initiation, agree requirements before design, and make go-live conditional on evidence that the controls work.
- Risk acceptance belongs to the business owner. The project manager runs the process and the security function advises, but residual risk is accepted, in writing, by someone with authority over the service.
- Scale the effort to the risk. A short triage at initiation decides whether a project needs a light checklist or a full threat model, DPIA and penetration test.
- Closure is a security event. Temporary accounts, test environments, project shares and supplier access created during delivery must be removed or handed over before the project is closed.
What ISO 27001 control 5.8 asks for
ISO/IEC 27002:2022 (edition 3, published February 2022) is the guidance companion to the Annex A controls in ISO/IEC 27001:2022. Control 5.8, "Information security in project management", is an organisational control whose purpose is that information security risks related to projects and their deliverables are addressed during project management. It merged two 2013 controls: 6.1.5 (information security in project management) and 14.1.1 (information security requirements analysis and specification).
In practice the control expects four things, which certification auditors usually test through a sample of recent projects:
- Early and repeated risk assessment: security risks are assessed at the start of the project and again at defined points, not only before go-live.
- Requirements before selection or build: confidentiality, integrity and availability needs, legal and contractual obligations and application security requirements (control 8.26) are identified before a product is chosen or development starts.
- Risks from running the project itself: project communications, shared workspaces, contractors and temporary environments are treated as risks in their own right.
- Evidence that treatments work: the effectiveness of agreed controls is tested and the results are recorded.
The same idea appears in other frameworks. NIST SP 800-37 Rev. 2 describes its Risk Management Framework as a system life cycle approach that incorporates security and privacy into the system development life cycle, and NIST SP 800-53 Rev. 5 control SA-3 (System Development Life Cycle) requires security roles and activities to be defined across the life cycle. The UK Government Secure by Design principles make the same point from a delivery angle, starting with "Create responsibility for cyber security risk" and ending with "Embed continuous assurance" and "Make changes securely". See the ISO 27001 Annex A.5 Organisational controls guide for how 5.8 sits with the other organisational controls.
Security activities at each project gate
Most organisations already run stage gates, whether PRINCE2 stage boundaries, a PMO investment committee or a GOV.UK style discovery, alpha, beta and live sequence. Attach security criteria to the gates you already have rather than inventing new ones. The table shows a workable default.
| Gate | Security activity | Output and evidence | Who signs |
|---|---|---|---|
| Idea or mandate | Security triage questionnaire (10 to 15 questions): data types, users, internet exposure, suppliers, integrations, regulatory scope | Security tier (low, medium, high) recorded in the project register | Project manager, reviewed by security partner |
| Initiation or discovery | Initial risk assessment, DPIA screening, data classification, identification of legal and contractual requirements | Entries in the project risk log; DPIA decision recorded with reasons | Business owner and data protection officer |
| Requirements and supplier selection | Security requirements agreed; supplier security questionnaire and contract clauses for any third party | Requirements traceable in the backlog or specification; supplier assessment | Security architect and procurement |
| Design | Architecture review and threat model scaled to the tier; identity and access design, including service accounts and API keys | Threat model, design review record, architecture decision records | Security architect |
| Build and test | Secure coding and configuration standards, code scanning, vulnerability scanning, penetration test for high tier | Scan reports, test results, findings tracked to closure | Delivery lead |
| Go-live or transition | Readiness review: open findings, residual risk, monitoring and logging in place, runbooks, backup and recovery tested | Signed risk acceptance for anything open; operational handover pack | Business owner (risk acceptance), service owner |
| Closure | Removal of temporary access, test data, project environments; handover of risks to the service risk register | Closure checklist with security items ticked and evidenced | Project manager and security partner |
The gates should be pass conditions, not paperwork. A high tier project with an unresolved critical penetration test finding does not go live unless the business owner has accepted that risk in writing, with a date for the fix.
Triage: scaling security to the project
A single process for every project will either crush small changes or wave through large ones. A short triage at initiation solves this. Score each question and map the total to a tier.
| Triage question | Raises the tier when |
|---|---|
| What data will the project create, store or move? | Personal data at scale, special category data, payment card data, credentials or keys, regulated or classified information |
| Will anything be exposed to the internet or to partners? | New public endpoints, APIs, remote access paths or partner connections |
| Does it change identity or access? | New directories, SSO integrations, privileged roles, service accounts or API credentials |
| Are suppliers or cloud services involved? | New SaaS, outsourced development, managed services or offshore delivery |
| Is it business critical? | Outage would stop revenue, safety or a regulated service |
| Does it decommission or migrate anything? | Data migration, system retirement, change of hosting |
- Low tier: checklist only, self-assessed by the project manager, spot-checked by security. Example: replacing meeting room screens.
- Medium tier: security requirements, a lightweight design review and a go-live checklist. Example: a new internal SaaS tool with SSO.
- High tier: named security partner, threat model, DPIA where personal data is involved, independent penetration test and formal risk acceptance. Example: a customer portal, an acquisition integration or a core platform migration.
Keep a "re-triage" trigger: if scope changes (a new supplier, a public interface, a new data type), the project manager re-runs the questionnaire.
Roles and decision rights
Unclear ownership is the main reason project security fails. Write the decision rights into the project governance document, ideally using the organisation's existing RACI. See the IT and Security RACI Template.
| Role | Security responsibility in the project |
|---|---|
| Project sponsor or business owner | Owns the residual risk; approves risk acceptance and any exception at gates |
| Project manager | Runs triage, schedules security activities, keeps security items in the risk log and plan, completes the closure checklist |
| Security partner or architect | Advises on requirements and design, reviews evidence, recommends whether a gate should pass |
| Data protection officer | Advises on DPIA need and outcome, privacy by design requirements |
| Delivery team and suppliers | Implement the agreed controls, produce test evidence, fix findings |
| Service owner (run team) | Accepts operational handover, including monitoring, patching and access reviews |
The security function advises; it should not become the risk owner by default. The UK Government Secure by Design principles describe the same split: risk owners are accountable for cyber security risk and should be senior enough to act on it, with evidence provided to them that controls operate as intended.
Requirements, design and privacy
Security requirements written after a product has been bought are usually negotiated away. Capture them at the requirements gate as testable statements, for example "all administrative access uses phishing-resistant MFA" or "audit logs are forwarded to the SIEM within five minutes". Good sources are the organisation's own policies and baselines, contractual obligations, and standards such as OWASP ASVS for applications. See the Security Requirements and Abuse Cases Guide for how to write and test them.
- Threat modelling: for medium and high tier projects, run a threat model when the design is stable enough to draw, and revisit it when the architecture changes. Record decisions as architecture decision records so the reasoning survives the project. See the Security Architecture Review Guide.
- Data protection: under UK GDPR and EU GDPR Article 35, a DPIA is required before processing that is likely to result in a high risk to individuals, and Article 35(3) lists cases where it is always required. The ICO advises doing a DPIA when in doubt and documenting the reasons if you decide not to. Put the DPIA screening at initiation so the outcome can still change the design. See the DPIA Guide.
- Supplier security: where the project brings in a supplier, the security requirements become contract clauses and due diligence before signature, which is what NIST CSF 2.0 GV.SC-05 and GV.SC-06 ask for.
Where identity fits
Projects are one of the biggest sources of orphaned identities. Integrations need service accounts, pipelines need deployment credentials, suppliers need temporary accounts and testers need privileged access. Each should have a named owner, an expiry date and a decision on who inherits it at handover. Add three items to the design gate: an inventory of every non-human identity the project creates, the secrets storage approach (a vault, not a shared spreadsheet or a configuration file), and the plan for rotating or removing them. See the NHI Offboarding and Decommissioning Guide.
Agile, product and small-team delivery
Control 5.8 applies whatever the delivery method. In agile teams the gates still exist, they are just smaller and more frequent.
- Definition of done: add security items, such as "no new high or critical findings from automated scans" and "new endpoints added to the API inventory", to the team's definition of done.
- Security stories: write security requirements as backlog items with acceptance criteria so they are prioritised and visible, not held in a separate document.
- Release gates: major releases, new external interfaces and changes to authentication trigger a design review, the same as a new project would.
- Product teams without an end date: replace closure with a periodic review, for example quarterly, of access, environments and open risks.
- Small organisations: one person may be project manager and security lead. Keep the triage questionnaire and the go-live checklist; drop formal committees. The evidence auditors look for is the same: a recorded risk assessment and a decision.
Running it: implementation steps
- Inventory current projects. Get the project portfolio from the PMO and triage every active project. This shows where the risk is now and gives you a baseline.
- Agree the gate criteria and RACI. Write a one-page procedure that names the gates, the security criteria for each tier and who signs. Have the PMO, not the security team, publish it.
- Build the templates into the PMO toolset. Add the triage questionnaire, security risk fields and the go-live and closure checklists to the project management tool so they appear by default.
- Pilot with three to five projects. Choose one per tier. Measure how long the security steps take and where teams got stuck, then adjust.
- Roll out by portfolio. Start with new projects; apply the go-live and closure checks to projects already in flight.
- Feed the ISMS. Link project risk logs to the corporate risk register and report results to the ISMS management review.
- Review and roll back where needed. If a gate causes repeated delays without finding anything, simplify it. If a tier keeps producing incidents, raise the bar for that tier.
Detection and measurement
Measure whether security happens in time, not just whether it happens. Useful metrics:
- Triage coverage: percentage of active projects with a recorded security tier (target: all).
- Early engagement: percentage of medium and high tier projects where security requirements were agreed before supplier selection or build started.
- Go-live findings: number of high and critical findings open at go-live, and how many have a signed risk acceptance with a fix date.
- Late surprises: security issues that forced rework after the design gate, tracked as a trend.
- Closure hygiene: temporary accounts, environments and supplier access still active 30 days after project closure.
- Post-go-live incidents: security incidents in the first six months traced to a project decision.
For detection, compare the identity and asset inventories with project closure records: accounts, cloud subscriptions and DNS names tagged with a closed project code should be zero.
Framework mapping
| Framework | Reference | What it covers in a project |
|---|---|---|
| ISO/IEC 27001:2022 Annex A | 5.8 Information security in project management | Security integrated into project management for all projects |
| ISO/IEC 27001:2022 Annex A | 8.26 Application security requirements; 8.27 Secure system architecture and engineering principles | Requirements and design gates |
| ISO/IEC 27001:2022 Annex A | 5.20 Addressing information security within supplier agreements | Supplier selection gate |
| NIST SP 800-53 Rev. 5 | SA-3 System Development Life Cycle; SA-4 Acquisition Process; SA-8 Security and Privacy Engineering Principles; SA-11 Developer Testing and Evaluation | Life cycle roles, acquisition requirements, design principles, testing |
| NIST SP 800-53 Rev. 5 | PL-2 System Security and Privacy Plans; CA-6 Authorization; CM-4 Impact Analyses | Security plan, go-live decision, change impact |
| NIST CSF 2.0 | ID.RA-07; GV.SC-05; GV.SC-06; PR.PS-06 | Changes managed and assessed for risk; supplier requirements and due diligence; secure development |
| UK Government Secure by Design | Principles 1, 3, 9 and 10 | Risk ownership, risk-driven approach, continuous assurance, secure change |
For a wider view of the SA family, see the NIST SP 800-53 SA System and Services Acquisition guide.
Common failure patterns
- Security invited after the contract is signed. Requirements then become change requests the supplier prices or refuses. Put supplier security assessment before selection.
- Test and temporary environments outlive the project. In the Microsoft Midnight Blizzard breach, attackers started from a legacy non-production test tenant account without MFA and an OAuth application with elevated access. Closure checklists that retire test environments and their identities address exactly this.
- Integration projects that connect before they secure. Acquisitions and partner integrations often connect networks or remote access first and harden later. The Change Healthcare breach began at a remote access portal without MFA in an acquired business. See the Identity Integration in M&A Guide.
- Risk acceptance by the wrong person. A project manager or security analyst "accepts" a risk to hit a date. Acceptance must come from the business owner and carry an expiry.
- One-size process. Every project gets the same 80-question form, teams learn to tick boxes, and the high-risk projects get no more attention than the low ones.
- Findings without handover. Open risks stay in a closed project's log where nobody reads them, instead of moving to the service risk register.
Practitioner checklist
- Every active project has a recorded security tier from a short triage questionnaire.
- Security criteria are attached to the existing PMO gates and published by the PMO.
- Decision rights are written down: the business owner accepts residual risk, security advises.
- Security requirements and DPIA screening happen before supplier selection or build.
- Medium and high tier projects have a design review and threat model; high tier projects have an independent penetration test.
- Every non-human identity the project creates has an owner, a vault location and an expiry or handover decision.
- Go-live requires a readiness review with signed acceptance for any open high or critical finding.
- Closure removes temporary accounts, supplier access, test data and environments, and moves open risks to the service register.
- Agile teams carry security in their definition of done and trigger reviews for major changes.
- Coverage, early engagement and closure hygiene metrics are reported to the ISMS management review.
Standards and references
- ISO: ISO/IEC 27002:2022 Information security controls
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: SP 800-37 Rev. 2 Risk Management Framework
- NIST: SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems
- NIST: Cybersecurity Framework 2.0
- UK Government Security: Secure by Design principles
- GOV.UK Service Manual: Securing your information
- ICO: When do we need to do a DPIA?
Related NHI Mgmt Group resources: ISO 27001 Certification Guide · Change Management Security · Secure by Design for UK Government Guide · Security architecture decision records (ADRs)