Auditing ISO 27001 Annex A 5.8 Information Security in Project Management is the systematic verification that security controls are integrated into project lifecycles. This process validates the Primary Implementation Requirement of defining and testing security requirements from initiation to closure. The Business Benefit ensures secure-by-design deliverables, preventing costly retrofits and mitigating operational risks.
This technical verification tool is designed for lead auditors to establish the legitimacy of organisational information security management during business transitions. Use this checklist to validate compliance with ISO 27001 Annex A 5.8 (Information security in project management) by ensuring security requirements are integrated throughout the project lifecycle.
1. Project Management Methodology Integration Verified
Verification Criteria: The organisation’s formal project management framework explicitly includes information security as a mandatory component for all project types.
Required Evidence: Documented Project Management Policy or Framework (e.g., PRINCE2 or Agile adaptation) showing security integration points.
Pass/Fail Test: If the project management handbook does not mention information security as a core requirement for project initiation, mark as Non-Compliant.
2. Information Security Risk Assessment Completion Validated
Verification Criteria: Every project initiated within the audit period has a recorded information security risk assessment conducted at an early stage.
Required Evidence: Project Risk Registers or Impact Assessments for at least three sampled projects, showing identified security risks and treatment plans.
Pass/Fail Test: If a major project has been initiated without a preliminary security risk assessment, mark as Non-Compliant.
3. Security Requirements Specification Records Present
Verification Criteria: Information security requirements are clearly defined within the project specification or “Definition of Done” (DoD) for technical deliverables.
Required Evidence: Project Requirement Specifications or User Stories containing specific security criteria (e.g., encryption, authentication, or logging needs).
Pass/Fail Test: If project deliverables are defined solely by functional features without explicit security constraints, mark as Non-Compliant.
4. Information Security Role Assignment Confirmed
Verification Criteria: Specific individuals or roles are assigned responsibility for information security within the project team structure.
Required Evidence: Project Org Charts or RACI matrices naming a Security Lead or appointing a security representative to the Project Board.
Pass/Fail Test: If no individual is held accountable for security deliverables within the project team, mark as Non-Compliant.
5. Secure Development and Implementation Standards Verified
Verification Criteria: For technical projects, evidence exists that secure coding or system hardening standards were applied during the implementation phase.
Required Evidence: Code review logs, automated security scanning reports (SAST/DAST), or server hardening checklists completed during the project.
Pass/Fail Test: If technical deliverables are moved to production without evidence of a security review or vulnerability scan, mark as Non-Compliant.
6. Project Milestone Approval via Security Gates Validated
Verification Criteria: The project lifecycle includes formal “Security Gates” where a security sign-off is required before progressing to the next phase.
Required Evidence: Project milestone reports or “Gate Review” minutes showing formal approval from the Information Security Manager or CISO.
Pass/Fail Test: If a project bypassed a mandatory security review to meet a deadline without a formal risk waiver, mark as Non-Compliant.
7. Data Protection Impact Assessment (DPIA) Execution Verified
Verification Criteria: Projects involving the processing of personal data have a completed DPIA or equivalent privacy assessment as required by law.
Required Evidence: Signed DPIA documents for projects involving PII (Personally Identifiable Information) or sensitive data sets.
Pass/Fail Test: If a project processing high-risk personal data lacks a formal DPIA or privacy review, mark as Non-Compliant.
8. Post-Project Security Review and Handover Confirmed
Verification Criteria: At project closure, a formal handover occurs to ensure operational teams are aware of the security controls and residual risks.
Required Evidence: Operational Handover Documents or “Service Transition” records containing security operating procedures.
Pass/Fail Test: If the operational support team has no documentation on how to maintain the security controls implemented by the project, mark as Non-Compliant.
9. Third-Party Project Security Requirements Verified
Verification Criteria: When projects involve external contractors or vendors, security requirements are included in the project-specific contracts or statements of work (SOW).
Required Evidence: Signed Statements of Work (SOW) or Vendor Contracts specifying security standards and right-to-audit clauses for the project.
Pass/Fail Test: If external parties are delivering project components without documented security obligations, mark as Non-Compliant.
10. Project Asset Integration into Asset Register Verified
Verification Criteria: New assets (hardware, software, data) created or acquired during the project are identified and added to the organisational Asset Register.
Required Evidence: Updated Asset Register showing new entries corresponding to project deliverables from the current period.
Pass/Fail Test: If project deliverables have gone live but the hardware/software assets are missing from the central inventory, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Risk Assessment | GRC tool identifies that a “Project Risk” folder exists. | The auditor must verify the quality of the assessment; generic “No risks” entries in a SaaS tool are a major failure. |
| Security Gates | Platform marks a gate as “Pass” because a document was uploaded. | Verify that the person who signed the gate has the technical authority to judge security compliance. |
| Roles & Responsibilities | SaaS tool lists the Project Manager as also being the Security Lead. | Identify the conflict of interest; the PM is incentivised by speed, the Security Lead by safety. These should be distinct. |
| Requirement Definition | Tool records that “Security” was mentioned in a meeting. | Demand specific, measurable security requirements (e.g., “AES-256 encryption”) rather than vague statements. |
| DPIA Integration | GRC tool assumes a DPIA isn’t needed if the “Privacy” checkbox isn’t ticked by the PM. | An auditor must verify a sample of projects to ensure the PM didn’t incorrectly bypass the privacy review. |
| Vendor Security | SaaS tool verifies that the vendor has an ISO 27001 certificate. | An ISO certificate is not enough; verify that the *Statement of Work* specifically covers the project’s security deliverables. |
| Operational Handover | Tool logs the project as “Closed” in Jira/ServiceNow. | Trace the project to the SOC/IT Ops team; verify they actually know how to monitor the new project’s security logs. |
About the author
