Information Security in Projects Under ISO 27001 A.5.8

Projects change how an organisation works. They introduce systems, suppliers, data flows, facilities, products and temporary access—often before routine control owners are ready to operate them. Treating security as a final approval therefore creates a predictable problem: the project discovers expensive constraints after its design is difficult to change.

ISO/IEC 27001:2022 Annex A control 5.8 addresses information security in project management. It does not prescribe one delivery method or require every project to carry the same control set. The practical objective is to integrate security into the way projects are governed throughout their life cycles, in proportion to the risks involved.

This article explains an evidence-led operating model. It is AuditPrepared guidance, not a reproduction of standard text.

Start by defining what counts as a project

A narrow definition limited to major IT programmes leaves many material changes outside the process. Decide which initiatives must pass through project-security governance. Typical examples include:

• a new cloud service or outsourced process;
• a product feature that changes data collection or access;
• an office move or secure-area redesign;
• a merger, acquisition or business separation;
• a network, identity or endpoint transformation;
• a data migration or analytics initiative; and
• a customer-specific implementation with unusual obligations.

Not every initiative needs a security specialist embedded full time. Use a simple intake that identifies the service, sponsor, delivery owner, information involved, affected users, suppliers, jurisdictions and intended go-live date. The intake should route higher-risk work to deeper review while allowing genuinely low-risk changes to proceed with recorded reasoning.

The ISO 27001 risk score calculator can help teams apply a consistent likelihood-and-impact scale when it matches the organisation’s approved risk method.

Put security gates into the delivery path

Security activities are most effective when connected to existing decisions rather than operated as a parallel process. A practical life cycle has six gates.

1. Initiation

Identify business purpose, information-security relevance, applicable obligations, major dependencies and the accountable sponsor. Decide whether specialist assessment is needed. Evidence may include the project brief, intake decision and assigned owner.

2. Requirements

Translate risks and obligations into measurable requirements. Cover identity, logging, resilience, supplier responsibilities, data handling, privacy, secure development, incident response and decommissioning where relevant. Each requirement should have an owner and acceptance method.

3. Design

Review architecture, trust boundaries, data flows, administrative access and failure modes. Record material decisions and unresolved risks. A diagram alone is not an approval; the evidence should show what was considered, by whom and with what conclusion.

4. Build and verification

Implement requirements and test them. The method may include configuration review, code analysis, vulnerability assessment, recovery exercise, permission testing or supplier assurance. Link findings to remediation or an authorised acceptance decision.

5. Release

Confirm that required safeguards are operating, ownership has transferred, procedures and monitoring exist, residual risks are accepted by an authorised role, and urgent exceptions have expiry dates. Security approval should be one input to a defined go-live decision—not an informal message in a private chat.

6. Closure and change

Transfer assets, risks, records, supplier commitments and open actions into normal operations. Remove temporary access and environments. Capture lessons that can improve future projects. A project is not safely closed while nobody owns its remaining security work.

Make requirements testable

“The solution must be secure” cannot be verified. A useful requirement connects a risk or obligation to an expected condition and a method of acceptance.

Weak statement	Testable security requirement	Possible evidence
Access must be controlled	Privileged access uses named accounts, approved roles and strong authentication before release	Role design, approvals and authentication test
Logs must be available	Defined security events reach the approved monitoring service with synchronised timestamps and retained fields	Event catalogue, sample events and alert result
The service must be resilient	The service recovers within approved objectives during an exercise using the operating team	Recovery record, timings, issues and approval
Supplier security is adequate	Contracted responsibilities cover incident notice, access, assurance and exit for the scoped service	Due diligence, signed terms and monitoring record

Security requirements should reflect the risk assessment, contractual commitments and applicable laws. Do not assume that selecting every possible control improves the project. Excessive requirements can create workarounds and obscure the controls that matter most.

Use the Annex A control lookup to explore relevant control purposes, then document the organisation’s own applicability and implementation decisions.

Clarify ownership across project and operations

The project manager coordinates delivery but rarely owns every information risk. Assign responsibilities explicitly:

• the sponsor owns the business outcome and major trade-offs;
• the project manager integrates security activities into delivery;
• the risk owner decides treatment and accepts remaining exposure within authority;
• architects and technical owners design and implement safeguards;
• legal, privacy and procurement owners interpret their requirements;
• the security function advises, reviews and escalates; and
• the operational service owner accepts the production capability and ongoing obligations.

Where one person holds several roles, preserve the decisions and authority. Independence may be important for some testing or approval, particularly where the delivery team would otherwise approve its own unresolved weakness.

The existing RACI guide for ISO 27001 helps distinguish accountability from execution without creating unnecessary committees.

Govern agile and iterative delivery

Short iterations do not remove the need for security governance. They change its cadence. Add security criteria to epics, stories or work items; review architecture when trust boundaries change; and include security acceptance in the definition of done where relevant.

For continuous delivery, use automated tests for repeatable conditions and human review for context-dependent decisions. A pipeline can identify a vulnerable dependency or missing configuration, but it cannot determine every legal obligation or accept business risk.

The Scrum delivery guide for ISO 27001 shows how backlog ownership, sprint evidence and governance can coexist.

Control exceptions without hiding them

Projects face deadlines. A mature process allows an authorised, time-bound exception when the organisation understands the exposure and compensating measures. Record:

• the unmet requirement;
• affected information and service;
• risk assessment and business reason;
• temporary safeguards;
• approving authority;
• expiry or review date; and
• permanent action owner.

An exception is not a silent waiver. Repeated extensions may indicate unrealistic requirements, inadequate resources or weak accountability. Report overdue and high-impact exceptions to the appropriate governance forum.

Build an audit trail that proves operation

Design evidence shows the process exists: governance rules, intake criteria, gate definitions, role assignments and security requirement standards. Operating evidence shows that real projects followed it.

For a sample, an auditor could trace:

1. the original project intake and risk triage;
2. security requirements back to risks or obligations;
3. design decisions and reviewer competence;
4. test results and finding resolution;
5. release approval and residual-risk decisions;
6. transfer to operational owners; and
7. removal of temporary access after closure.

Sample by risk and variety. Include a high-impact project, a supplier-led project, an agile release stream, a project with an exception and a recently closed initiative. Compare the project record with identity, change, monitoring and asset systems rather than relying only on the project manager’s folder.

Pass, partial and fail examples

Pass: Security criteria were applied at defined gates, requirements were tied to risk, tests demonstrated operation, and residual decisions had authorised owners. Open work transferred into normal governance.

Partial: Reviews occurred, but late timing caused several urgent exceptions and evidence of operational handover was inconsistent.

Fail: Security was requested only before release, major decisions were undocumented, and temporary access remained after project closure.

These examples describe evidence maturity; they do not predict a certification decision.

Measure whether the model helps

Useful measures include the proportion of in-scope projects triaged before design, high-risk requirements verified before release, overdue exceptions, late security findings, temporary access removed on time and recurring lessons across projects. Interpret results with context: a rise in identified findings may reflect earlier detection rather than worsening security.

Review trends with project and service leadership. If teams routinely bypass the process, investigate friction, unclear thresholds or inadequate capacity. Continual improvement means changing the operating model when evidence shows it is not producing timely, reliable decisions.

Practical conclusion

Project security works when it influences ordinary delivery decisions from initiation through closure. Define which projects are in scope, scale the review to risk, express requirements in testable terms and make ownership explicit. Then retain evidence of the decisions, tests, exceptions and handover that occurred.

The result is not an extra approval layer. It is a way to prevent projects from transferring unknown exposure into operations.

This article was cross-checked against the official ISO/IEC 27001 overview. The gate model, evidence examples and sampling approach are original AuditPrepared guidance.