ISO 27001 A.5.8 - Information Security in Project Management

Requirement

“Information security shall be integrated into project management.”

Plain-language meaning

Projects must handle information security from the start, not as a late review before go-live.

This applies to projects that build, buy, change, configure, integrate, outsource, or retire systems, services, infrastructure, processes, or business capabilities. A project that delivers on time but creates an insecure system has not delivered a fit-for-purpose outcome.

Why this matters

Projects change the organization. They introduce new systems, suppliers, processes, data flows, integrations, user access, and operational dependencies. If security is not built into the project method, security risks are discovered late, ignored under delivery pressure, or pushed into operations as unresolved risk.

A.5.8 is the bridge between project delivery and the Information Security Management System.

Project risk vs information security risk

Do not confuse normal project risk with information security risk.

The project risk register may mention security risks, but it often gets dominated by delivery pressure. Serious information security risks should also connect to the organization-level Risk Assessment or information security risk register.

Implementation guidance

1. Add security into the project method

The project methodology should require information security checkpoints across the project lifecycle.

Minimum checkpoints:

• project initiation;
• requirements analysis;
• design or solution selection;
• supplier or product selection;
• development or configuration;
• testing;
• change approval;
• transition to operations;
• post-implementation review.

Security should not rely on a security team member noticing the project informally.

2. Perform two security risk assessments

At project start, assess two different things:

Both assessments should produce security requirements and controls.

3. Define security requirements with functional requirements

Security requirements must be captured alongside business and functional requirements.

Examples:

• access control and privileged access;
• authentication and MFA;
• logging and monitoring;
• encryption and key management;
• backup and recovery;
• secure configuration;
• segregation of duties;
• data retention and disposal;
• privacy and regulatory requirements;
• supplier security requirements;
• secure development or acquisition requirements;
• incident response and support obligations.

For acquired systems, commercial off-the-shelf software, add-ons, integrations, and customizations must still be assessed. Buying a product does not outsource accountability for security risk.

4. Trace risks to controls

For each material information security risk, the project should show:

• the risk;
• the security requirement;
• the control or design response;
• the owner;
• the test or validation method;
• the implementation status;
• the residual risk decision.

This keeps security from becoming vague “security review completed” paperwork.

5. Reassess security during project change

Project changes should trigger security reassessment when they affect:

• scope;
• architecture;
• suppliers;
• data types;
• integrations;
• access model;
• hosting location;
• user population;
• operational support;
• compliance obligations;
• go-live timeline.

Removing security controls to hit a deadline is not a local project decision. It should be escalated to the appropriate risk owner or governance body.

6. Validate security before transition

Before go-live or handover, verify that security requirements are actually implemented.

Examples:

• security test results;
• access model review;
• vulnerability assessment;
• secure configuration review;
• logging and monitoring validation;
• backup and recovery test;
• supplier assurance review;
• operational support readiness;
• residual risk acceptance.

The transition phase matters because some project controls are temporary, while deliverable controls must survive into operations.

Audit guidance

Auditors should test both the project methodology and a sample of actual projects.

The methodology should require:

• identification of information security objectives;
• information security risk assessment distinct from delivery risk;
• security requirements definition;
• security roles and responsibilities;
• lifecycle checkpoints;
• security review after project changes;
• testing or validation of security requirements;
• controlled transition to operations.

For sampled projects, auditors should look for evidence that security was identified, tracked, tested, and resolved. A project closeout document that says “security approved” is weak unless it links to risks, requirements, controls, tests, and decisions.

Evidence examples

Strong evidence

• Project methodology has security gates and role responsibilities.
• Each sampled project has a security risk assessment.
• Security requirements are traceable to risks and controls.
• Security requirements are tested before acceptance.
• Project changes trigger security reassessment.
• Purchased systems and customizations receive security review.
• Unresolved security issues are escalated and accepted by authorized risk owners.
• Operational handover includes evidence, owners, monitoring, support, and residual risk.

Weak evidence

• Security review happens only near go-live.
• Project risk register mixes delivery risk and security risk without clear ownership.
• Security requirements are generic or copied from a checklist.
• No evidence that requirements were tested.
• COTS products are assumed secure because they are commercial.
• Security controls are removed to meet deadlines without risk approval.
• No handover of security controls into operations.

Common failures

Exam traps

• Project management security is not only for software development. It applies to any project that can affect information security.
• A project risk register is not automatically an information security risk register.
• Commercial software still needs security requirements and assessment.
• Security requirements should be identified early, not after build or purchase.
• Testing should validate security requirements, not only functional requirements.
• Removing a security control for delivery convenience requires proper risk escalation.

Related controls and concepts

• Risk Assessment
• Statement of Applicability
• A.5.2 Information Security Roles and Responsibilities
• A.5.3 Segregation of Duties
• A.5.4 Management Responsibilities
• A.5.7 Threat Intelligence
• Information Security Management System
• Internal Audit
• Management Review

KB-ready summary

A.5.8 requires information security to be integrated into project management. Projects should identify security objectives, assess information security risks separately from delivery risks, define security requirements, trace risks to controls, reassess security after project changes, test security requirements, and hand over enduring controls into operations.

Templates and checklists

• Project Security Requirements Register
• A.5.8 Audit Checklist
• Risk and Control Mapping Table
• RACI Matrix
• Corrective Action Tracker