We have all been there. The project is running late, the budget is tight, and the “Go Live” date is immovable. Then, 48 hours before launch, someone asks, “Wait, is this GDPR compliant?” or “Did we pen-test this?”
Panic ensues. Delays happen. Or worse, you launch anyway and hope for the best.
ISO 27001 Annex A 5.8: Information Security in Project Management is designed to stop this exact scenario. It ensures that security isn’t just a hurdle at the finish line but a companion throughout the race.
Implementing this control doesn’t mean you need to slow down your delivery. In fact, if done right, it speeds you up by preventing the expensive rework that comes from bolting security on at the end. Here is how to implement it effectively.
Table of contents
What is Annex A 5.8 Actually Asking For?
The standard requires that “Information security shall be integrated into project management.”
That is short, but it carries a lot of weight. It applies to all types of projects—not just IT software builds. If you are moving offices, that’s a project with security risks (physical access, paper records). If you are implementing a new HR system, that’s a project (data privacy). Even a marketing campaign can be a project if it involves collecting customer data.
Step 1: Embed Security into Your Methodology
You cannot implement this control if you don’t have a defined way of doing projects. Whether you use PRINCE2, Waterfall, or a loose version of “Agile,” you need to insert security checkpoints into that process.
For Waterfall / Traditional Projects
You need to map security activities to your standard phases:
- Initiation: Identify the security classification of the project. Is it high risk?
- Planning: Define specific security requirements (e.g., “Must use MFA,” “Must be hosted in the EU”).
- Execution: Build the controls.
- Closure: Verify the controls work before handing over to operations.
For Agile / DevOps Projects
If you work in sprints, a “Security Phase” doesn’t work. Instead, you need:
- Security User Stories: Add tickets to the backlog like “As a user, I want my data encrypted so that…”
- Definition of Done (DoD): A feature isn’t “done” until it passes a code scan or a peer security review.
Step 2: The Project Risk Assessment
This is the heart of Annex A 5.8. You cannot secure a project if you don’t know the risks.
At the very start of the project (during the Project Charter or Initiation Document phase), ask three questions:
- What data are we touching? (Public, Internal, Confidential?)
- What could go wrong? (Data leak, service downtime, fraud?)
- What legal rules apply? (GDPR, HIPAA, PCI-DSS?)
You don’t need a 50-page report for every small project. A simple “Security Impact Assessment” checklist is often enough to satisfy the auditor and your own peace of mind.
Step 3: Define Security Requirements Clearly
Vague requirements lead to bad security. Telling a developer to “make it secure” is useless. Telling them “Passwords must be 12 characters and salted” is actionable.
Annex A 5.8 requires you to define these requirements early. This might include:
- Access Control: Who can see this data?
- Logging: What actions need to be recorded?
- Availability: Do we need a backup server?
Step 4: Documenting Compliance (The Evidence)
To pass your audit, you need to prove that security was part of the conversation. Auditors typically look for:
- Project Charters with a “Security Implications” section filled out.
- Risk Registers that list security risks alongside budget and timeline risks.
- Go/No-Go Decisions where security was a sign-off criteria.
If you don’t have these templates, or if your current project documentation is a mess, Hightable.io offers comprehensive ISO 27001 toolkits. Their templates for Project Initiation and Security Risk Assessment are designed specifically to meet Annex A 5.8 requirements without creating unnecessary bureaucracy.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls to Avoid
The “One Size Fits All” Trap
Don’t force a full-blown security audit on a project to repaint the lunchroom. Your process should be scalable. High-risk projects get deep assessments; low-risk projects get a quick checklist.
The “IT Silo”
Don’t assume this is just for the software engineering team. If the Finance team is changing banking providers, that is a project with massive security implications. Ensure your Project Management Policy covers the whole business.
Conclusion
Implementing ISO 27001 Annex A 5.8 is about shifting security “to the left.” By addressing risks at the start of a project, you save money, reduce stress, and ensure that when you finally push the button to go live, you can do so with confidence.
Start by reviewing your current project templates. Add a “Security Risks” field today. It’s a small change that makes a massive difference to your compliance posture.
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.
