If you ask a Project Manager (PM) about their top priorities, they will likely list “Budget,” “Timeline,” and “Scope.” If you are lucky, they might whisper “Quality.” Security? That usually gets tacked on the week before the go-live date.
As an auditor, or someone preparing for an audit, your job with ISO 27001 Annex A 5.8 is to catch that omission. This control requires that information security is integrated into project management, rather than treated as an afterthought.
Auditing this control can be tricky because “projects” can look very different depending on the company. It could be a massive waterfall construction project or a two-week agile sprint. Here is a practical guide on how to audit Annex A 5.8 effectively, regardless of the methodology.
Table of contents
The Core Requirement: What Are You Testing?
The standard requires that “Information security shall be integrated into project management.”
When you audit this, you are testing for integration. You aren’t checking if they have a firewall (that’s a different control). You are checking if the decision to install the firewall was made during the project planning phase, not as a panic move during deployment.
You need to verify three things:
- Identification: Are security risks identified at the start of the project?
- Definition: Are security requirements written into the project scope?
- Review: Is security checked at key milestones?
Step 1: Request the “Project Artifacts” (The Evidence)
You cannot audit a feeling; you need documents. Ask the auditee for a list of recent projects (completed and in-flight). Pick a sample—ideally one large project and one small change initiative.
Look for these specific documents:
1. The Project Charter / Initiation Document (PID)
Open the very first document created for the project. Is there a section for “Security Requirements”?
The Auditor’s Test: If the section is blank or says “TBD,” mark it as an observation. Security objectives should be defined alongside business objectives.
2. The Project Risk Register
Every project has risks (budget overrun, delay). Does it list security risks?
The Auditor’s Test: Look for risks like “Data leakage during migration” or “Vendor fails security assessment.” If the risk register only talks about money and time, they have failed the control.
3. Milestone Sign-offs (Gate Reviews)
Most projects have “gates” where management approves the next phase.
The Auditor’s Test: Check the sign-off criteria. Is there a “Security Review” checkbox? Was it actually checked, or just waved through?
Step 2: The “Agile” Challenge
If you are auditing a software startup, they might laugh if you ask for a “Project Charter.” They use Scrum, Kanban, or XP. How do you audit Annex A 5.8 in an Agile environment?
You look for security in the User Stories and Definition of Done.
Ask to see their Jira/Linear board:
- Security Stories: Are there specific tickets for “Implement MFA” or “Penetration Test”?
- Acceptance Criteria: Does a feature ticket include security constraints? (e.g., “As a user, I want to upload a photo securely…”).
- Definition of Done (DoD): Does the DoD require a code scan or security review before a ticket can be closed?
Step 3: Interviewing the Project Managers
Documents can be faked; interviews reveal the culture. Sit down with a Project Manager and ask these specific questions:
“At what point do you involve the Information Security team?”
Good Answer: “They are part of the kickoff meeting and approve the initial scope.”
Bad Answer: “We usually send them an email a few days before we go live to get the firewall ports opened.” (This is a major non-conformity).
“How do you handle security requirements that threaten the timeline?”
Good Answer: “We treat them like any other critical requirement. If we can’t meet them, we log it as a risk and seek formal acceptance from the risk owner.”
Bad Answer: “We usually push them to ‘Phase 2’ so we don’t miss the launch date.”
Step 4: Common Non-Conformities
1. The “IT Only” Trap
The organization applies security checks to IT software projects but ignores other business projects—like selecting a new HR provider or moving offices. Annex A 5.8 applies to all projects that impact information security.
2. The “Bolted On” Approach
Security testing (like a pen test) happens, but it happens 24 hours before launch. This proves security was not integrated into project management; it was just a final hurdle. The standard wants security in the process, not just at the end.
3. Lack of Templates
If every Project Manager invents their own way of tracking security, the process is not repeatable. You want to see a standard “Project Methodology” that forces security questions to be asked every time.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
How to Fix Gaps Fast
If you are self-auditing and realize you have a gap, the fix is usually about standardization.
- Update the Templates: Add a “Security Implications” field to your Project Charter template today.
- Mandate a Check-in: Create a rule that the CISO (or security lead) must be a “Consulted” party on all new project requests.
- Use Proven Toolkits: You don’t need to reinvent the wheel. Resources like Hightable.io provide ISO 27001 toolkits with pre-built Project Management policies and checklists. Using these templates gives you an immediate, audit-ready structure to prove you are managing security risks in projects consistent.
Conclusion
Auditing ISO 27001 Annex A 5.8 is about verifying that security has a seat at the table. You are looking for evidence that the organization thinks about risk before they build, buy, or change things. If you can find the paper trail (or Jira trail) that shows security constraints were defined early and tracked often, the audit will be a breeze.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
