In this guide you will learn how to implement ISO 27001 Annex A 5.8 Security in Project Management and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
ISO 27001 Annex A 5.8 is an ISO 27001 control that requires information security to be integrated into project management.
Table of contents
- Purpose & Definition
- FREE ISO 27001 Annex A 5.8 Training Video
- Implementation Guide
- What to consider when determining requirements
- How to determine information security requirements
- How to implement ISO 27001 Annex A 5.8
- How to comply
- How to audit ISO 27001 Annex A 5.8
- How to pass the audit
- What will an audit check?
- Top 3 Mistakes People Make and How To Avoid Them
- Further Reading
- ISO 27001 Controls and Attribute Values
- ISO 27001 Annex A 5.8 FAQ
Purpose & Definition
The purpose of ISO 27001 Annex A 5.8 is to ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle.
The ISO 27001 standard defines ISO 27001 Annex A 5.8 as:
Information security should be integrated into project management.
ISO 27001:2022 Annex A 5.8 Information security in project management
ISO 27001 Starter Kit
Instant download of mandatory ISMS core policies and documentation. Verified by Lead Auditors and used by 5,000+ businesses worldwide to pass Stage 1 certification first time.
FREE ISO 27001 Annex A 5.8 Training Video
In this free training video you will learn How to implement ISO 27001 Information Security In Project Management Annex A 5.8) & Pass Your Audit.
Implementation Guide
You are going to be doing some level of project management following your approach and methodology. This is fine. There are many approaches and methodologies, but what ever you do, you will integrate information security ensuring information security risks are addressed as part of the process. You can consider ISO 21500 and ISO 21502 for guidance on concepts and processes for project management.
You are going to have to ensure that
- you have identified, assessed and treated information security risks at an early stage
- you continue to identify, assess and treat risks at points in the project lifecycle
- requirements for information security and intellectual property are addressed early in projects
- risks associated with the execution of projects are considered and treated
- progress on risk treatment is reviewed and its effectiveness evaluated and treated
Your project steering committee or oversight structure is going to check the appropriateness of the information security considerations and activities. The project is going to have roles and responsibilities for information security defined and allocated.
What to consider when determining requirements
- The information that is involved and the information security needs for that information. This would include considering the negative impacts of not having the security controls
- The protection requirements for information and the assets that process, store and transmit it
- Authentication requirements for access to information and the assets that process, store and transmit it
- The processes for providing the access for both customers and business users
- Informing users of their duties and responsibilities
- Compliance to the legal, regulatory and client requirements for information security
How to determine information security requirements
You can determine the requirements for information security in a project using a variety of methods. Some examples would be:
- What are the compliance requirements set in our policies
- What do regulations say about information security
- What laws apply and what requirements do they set
- Considering threat modelling, threat intelligence and actual incidents that have been experienced
How to implement ISO 27001 Annex A 5.8
Implementing security in project management is not a tick-box exercise. It is a fundamental requirement to ensure that every new initiative reduces risk rather than creating it. As a Lead Auditor, I want to see that security is baked into your project lifecycle from initiation to closure. Follow these ten steps to ensure your project management framework meets the gold standard for ISO 27001 compliance.
1. Embed Security into the Project Initiation Document
Define clear information security objectives at the very start of every project. I expect to see these objectives documented in your Project Initiation Document (PID) or project charter. If security isn’t mentioned at the start, you have already failed the audit.
- Identify and document all regulatory and statutory compliance requirements.
- Define the security profile and sensitivity of the data the project will handle.
- Assign a specific budget and resource allocation for security controls.
2. Formalise Project-Specific Risk Assessments
Conduct a structured information security risk assessment for every project milestone. You must move beyond generic organisational risks and focus on the specific threats introduced by the project’s unique scope and technology stack.
- Identify project-specific threats, vulnerabilities, and potential impacts.
- Produce a formal Risk Treatment Plan (RTP) signed off by the project board.
- Integrate all identified risk mitigations directly into the main project plan.
3. Enforce Strict Separation of Environments
Maintain total logical or physical segregation between development, testing, and production environments. This is a non-negotiable requirement to prevent accidental data leaks or unauthorised changes to live systems.
- Provision isolated cloud VPCs or subnets for each environment.
- Implement strict firewall rules and Access Control Lists (ACLs) between stages.
- Ensure that developer access to production is restricted to emergency “break-glass” scenarios only.
4. Provision Identity and Access Management Roles
Apply the principle of least privilege to every project member from day one. I will look for evidence that access is granted based on the specific requirements of the project role rather than broad, “one-size-fits-all” permissions.
- Implement mandatory Multi-Factor Authentication (MFA) for all project tools.
- Review and update IAM roles at every major project phase transition.
- Log and monitor all administrative actions within the project environment.
5. Maintain a Comprehensive Project Asset Register
Track every information asset created or utilised during the project lifecycle. You cannot protect what you have not identified: this includes source code repositories, cloud instances, and sensitive project documentation.
- Document asset ownership and classification for all project deliverables.
- Update the organisational Asset Register as project assets transition to production.
- Ensure all project storage, such as S3 buckets, is tagged for accountability.
6. Implement Secure Coding and Configuration Standards
Standardise your approach to security by mandating specific coding and configuration benchmarks. I expect to see that your developers are following industry-standard frameworks like OWASP or CIS Benchmarks throughout the build.
- Formalise a peer-review process for all code changes with a focus on security.
- Utilise Static Analysis Security Testing (SAST) tools in the build pipeline.
- Apply hardened configuration templates to all project infrastructure.
7. Use Anonymised or Masked Data for Testing
Protect live customer data by ensuring it is never used in development or test environments. If you must use production data for realistic testing, you must prove that it has been formally anonymised or masked.
- Implement automated data masking scripts for database refreshes.
- Obtain formal authorisation before any production data is used for testing.
- Audit the test environment to ensure no PII or sensitive data remains plaintext.
- Validate that masked data cannot be reverse-engineered to identify individuals.
8. Define Rules of Engagement for Security Testing
Authorise and control all security testing activities through a formal Rules of Engagement (ROE) document. This ensures that penetration tests and vulnerability scans are conducted safely and within a defined scope.
- Document the specific timing, tools, and IP ranges permitted for testing.
- Obtain written sign-off from asset owners before testing begins.
- Ensure a clear communication plan is in place for critical vulnerability findings.
9. Establish Security Communication and Escalation Paths
Formalise how security issues and incidents are reported within the project team. There must be no ambiguity: every team member should know exactly how to escalate a security concern to the Project Manager or CISO.
- Include “Security” as a standing agenda item in all project board meetings.
- Define a clear incident reporting workflow specific to the project environment.
- Ensure the project team is aware of the central organisational SOC contacts.
10. Revoke Access and Archive Securely at Project Closure
Complete a formal security review before the project is officially closed. This “housekeeping” step is critical to ensure that temporary access does not become a permanent vulnerability for your organisation.
- Revoke all project-specific access rights for staff and third-party contractors.
- Ensure all final project documentation is archived according to your retention policy.
- Conduct a “Lessons Learned” session to improve future project security.
Check Your Work?
You buit it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let a trained ISO 27001 auditor check your work.
How to comply
To comply with ISO 27001 Annex A 5.8 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to:
- Establish and document your project methodology
- Include steps to identify, assess and treat information security risks at an early stage
- Continue to identify, assess and treat risks at points in the project lifecycle
- Demonstrate the requirements for information security and intellectual property are addressed early in projects
- Document that risks associated with the execution of projects are considered and treated
- Monitor progress on risk treatment and review its effectiveness, that is evaluated and treated
How to audit ISO 27001 Annex A 5.8
1. Formalise Security Requirements in Project Initiation
You must demonstrate that security is a core component of the project’s inception. I expect to see documented security objectives within the initial project mandate or charter. This is not optional. Every project must have a defined security profile based on the sensitivity of the data it handles.
- Review project initiation documents for explicit security milestones.
- Confirm that compliance requirements, such as GDPR or PCI-DSS, are identified early.
- Verify that a budget has been allocated specifically for security controls.
2. Conduct Formal Risk Assessments for Every Project
If you aren’t assessing risk, you aren’t managing a project securely. You must provide evidence of a structured risk assessment conducted at the start of the project and at major milestones. I want to see the identified risks, their impact, and the formal treatment plan signed off by the Project Board.
- Check the risk register for project-specific information security threats.
- Ensure that risk treatment plans are integrated into the project plan.
- Verify that the ‘Risk Owner’ is clearly identified and accountable.
3. Integrate Security into the Development Lifecycle
Whether you use Agile, Waterfall, or DevOps, security must be a constant. I will look for evidence of security user stories, secure coding standards, and gated reviews. If you are deploying code, I want to see that it has passed through a security filter before it hits production.
- Audit the ‘Definition of Done’ to ensure it includes security testing.
- Verify the use of automated SAST and DAST tools in the CI/CD pipeline.
- Confirm that security requirements are revisited during every sprint or phase.
4. Provision Identity and Access Management Roles
Project environments are often high-risk because of temporary access. You must prove that the principle of least privilege is applied to all project members. I will check that IAM roles are strictly defined and that developers do not have ‘God mode’ access to production data or sensitive source code.
- Review the project access control list against the HR starter/leaver list.
- Verify that Multi-Factor Authentication (MFA) is mandatory for all project tools.
- Check for the use of ‘Privileged Access Management’ for administrative tasks.
5. Maintain an Accurate Project Asset Register
You cannot protect what you have not identified. Every project creates assets: code repositories, cloud instances, and documentation. I expect to see a dedicated asset register for the project that tracks these items and assigns a clear owner for each.
- Verify that cloud buckets and databases are tagged with project identifiers.
- Check that all project-related hardware is tracked and managed.
- Confirm that information classification labels are applied to project deliverables.
6. Formalise Third-Party and Vendor Security Reviews
Projects often rely on external consultants or SaaS tools. You must show me that you have vetted these third parties before they were given access to your environment. I want to see signed NDAs and evidence that the vendor’s security posture was reviewed against your standards.
- Audit the contracts for specific ‘Right to Audit’ and security clauses.
- Verify that a Supply Chain Risk Assessment was completed for the project.
- Confirm that external access is revoked immediately upon project completion.
7. Enforce Separation of Environments
This is a major failure point in many audits. You must demonstrate a strict physical or logical separation between development, testing, and production environments. Under no circumstances should live customer data be used in a test environment without formal anonymisation or masking.
- Review the network architecture for segregation between Dev and Prod.
- Verify the process for data masking if production data is ‘shipped’ to test.
- Confirm that test credentials are never reused in production environments.
8. Document Rules of Engagement for Security Testing
Before a project goes live, it needs to be tested. I want to see a formal ‘Rules of Engagement’ (ROE) document for any penetration testing or vulnerability scanning. This proves that testing was authorised, controlled, and did not disrupt business operations.
- Check for signed authorisation forms for all security testing activities.
- Verify that the scope of testing covered all critical project components.
- Confirm that any ‘High’ or ‘Critical’ vulnerabilities were remediated before launch.
9. Establish Clear Security Communication Channels
Security issues must be escalated quickly. I will look for evidence that project teams know how to report a security incident or a ‘near miss.’ There should be a defined path from the project team to the CISO or the central SOC.
- Review project meeting minutes for standing ‘Security’ agenda items.
- Verify that the project team has been trained on the incident reporting process.
- Check that the Project Manager has a direct line to the Security Officer.
10. Conduct a Post-Project Security Review
The audit doesn’t end when the project closes. I want to see a ‘Post-Implementation Review’ that specifically addresses security. Did the controls work? Were there any breaches? This feedback loop is essential for the ‘Continuous Improvement’ required by ISO 27001.
- Verify that all temporary project access and accounts have been revoked.
- Confirm that the final project documentation is securely archived.
- Check the ‘Lessons Learned’ log for security-related improvements.
How to pass the audit
To pass an audit of ISO 27001 Annex 5.8 Information security in project management you are going to make sure that you have followed the steps above in how to comply.
What will an audit check?
The audit is going to check a number of areas. Lets go through the main ones
1. That you have a documented project management process
What ever your approach to projects the process is going to be written down.
2. That you have followed and can evidence you project management process
You have the process, you have included the requirements of the standard and you can evidence that you have followed it at least once or consistently since implementing it, which ever is the greater.
3. That risks are managed
That you have evidence of managing risks which includes for the project that you have identified, assessed and treated them.
Top 3 Mistakes People Make and How To Avoid Them
The top 3 Mistakes People Make For ISO 27001 Annex A 5.8 Information security in project management are
| Common Mistake | The Audit Failure (Why it happens) | Lead Auditor Solution (How to avoid it) |
|---|---|---|
| 1. Lack of a Followed Project Process | Organisations often operate with undocumented “ad-hoc” project methods or have a written policy that does not reflect reality. | Formalise and document your project management process. Crucially, maintain evidence (such as meeting minutes or stage-gate sign-offs) to prove the process is followed. |
| 2. Neglecting Project Risk Management | Information security risks are frequently overlooked during the project lifecycle, resulting in “bolt-on” security at the end. | Integrate risk management into the project lifecycle. Provide documented evidence that you have identified, assessed, and treated security risks specific to the project. |
| 3. Poor Document and Version Control | Using inconsistent version numbers, failing to evidence annual reviews, or leaving tracked comments in “final” audit documents. | Enforce strict version control. Ensure all project documents are reviewed within 12 months, version numbers match across the ISMS, and all “final” files are clean of draft comments. |
Further Reading
- How to Implement ISO 27001:2022 Annex A 5.8: The “No Surprises” Guide
- How to Audit ISO 27001:2022 Annex A 5.8: Information Security in Project Management
- ISO 27001:2022 Annex A 5.8 for Small Business: Project Management Without the Headache
- ISO 27001:2022 Annex A 5.8 for Tech Startups: Security by Design, Not by Accident
- ISO 27001:2022 Annex A 5.8 for AI Companies: Baking Security into Your Models
ISO 27001 Controls and Attribute Values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Identify | Governance | Governance and Ecosystem |
| Integrity | Protect | Protection | ||
| Availability |
ISO 27001 Annex A 5.8 FAQ
Yes, Annex A 5.8 applies to all organisational projects that could impact information security, regardless of whether they are technical in nature.
Includes office relocations and physical security changes.
Applies to marketing campaigns involving personal data collection.
Covers business process outsourcing or supply chain transitions.
Includes mergers, acquisitions, and corporate restructures.
Security is integrated by establishing mandatory security checkpoints and deliverables within every phase of your existing project management framework (e.g., Agile, Prince2, or Waterfall).
Include security requirements in the initial project charter or brief.
Conduct a formalised Information Security Risk Assessment during the design phase.
Assign a security lead or Subject Matter Expert (SME) to the project team.
Execute a final security sign-off before moving to a “live” or production environment.
A security risk assessment should be performed during the project initiation phase and repeated whenever there is a significant change to the project scope, technology, or environment.
Initial feasibility and requirements gathering stage.
Following major design or architectural changes.
Prior to the commencement of user acceptance testing (UAT).
Immediately before the final project “Go-Live” decision.
The Project Manager is ultimately responsible for ensuring security tasks are integrated into the plan, though they work in collaboration with the Chief Information Security Officer (CISO) or security SMEs.
Project Manager: Ensures security milestones are met and resources are allocated.
Security Officer: Provides guidance on technical controls and risk mitigation.
Information Owner: Defines the sensitivity and classification of the data involved.
Project Board: Approves the final risk posture before project closure.
About the author
