ISO 27001 Annex A 5.8 Information Security in Project Management Explained

ISO 27001 Information Security in Project Management

ISO 27001 Annex A 5.8 Information security in project management is an ISO 27001 control that requires information security to be integrated into project management.

You will be following a project management methodology and that process will include information security requirements as part of it.

Key Takeaways

ISO 27001 Annex A 5.8 requires organizations to integrate information security requirements into their project management methodology. The objective is “Security by Design and Default”, ensuring that security risks are identified, assessed, and treated at the very start of a project rather than being “bolted on” at the end. Whether you are launching a new product, moving offices, or implementing a new software system, security must be a core part of the project lifecycle to prevent costly rework and data breaches.

Purpose

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.

Definition

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

Requirements

• Methodology Integration: You must have a documented project management process (Agile, Waterfall, etc.) that includes explicit security milestones.
• Early Risk Assessment: Information security risks must be identified and treated during the initiation phase. This includes considering the impact on Confidentiality, Integrity, and Availability.
• Intellectual Property Protection: Projects often create or use high-value IP. You must address how this IP is protected throughout the project life cycle.
• Assigned Security Roles: Every project should have defined roles for information security. This ensures accountability for security deliverables (e.g., pen tests, encryption config).
• Progress Monitoring: Risk treatment effectiveness must be evaluated at key gates in the project. If a risk isn’t mitigated, the project steering committee must formally accept the risk before moving to the next phase.

Audit Focus

1. Project Documentation: “Show me the Project Initiation Document (PID) or Backlog for your last major project. Where were the security requirements defined?”
2. Risk Management Evidence: “Can you prove that you conducted a risk assessment before the execution phase of this project?”
3. The ‘Go-Live’ Sign-off: “Show me the security sign-off for your latest system release. Who authorized that the identified security risks were sufficiently treated?”

FREE Training Video

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 it

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.

Implementation Checklist

Checklist Item	What to Implement	Practical Audit Example
1. Project Initiation Security	Mandatory inclusion of security requirements in the Project Initiation Document (PID).	A signed PID for a new mobile app that lists GDPR compliance and data encryption as primary objectives.
2. Risk Management Integration	A formalised process for conducting information security risk assessments at project start.	A project risk register identifying potential threats to a new cloud database and the specific treatment plan.
3. Environment Segregation	Strict logical or physical separation between development, testing, and production.	Independent Azure subscriptions or AWS accounts for Dev, Test, and Prod with zero cross-talk permitted.
4. Identity and Access Management	Role-based access control (RBAC) and Multi-Factor Authentication (MFA) for all project tools.	Developers granted ‘Contributor’ access to GitHub repositories via Entra ID with mandatory MFA enforced.
5. Project Asset Register	A dedicated inventory for all project-specific assets including code and cloud infrastructure.	A spreadsheet or tool listing all S3 buckets, code repos, and documentation created during the project sprint.
6. Secure Development Policy	Formalised coding standards and secure configuration benchmarks for all project builds.	Code reviews that specifically check against the OWASP Top 10 for any new web-facing components.
7. Data Masking and Protection	Strict prohibition of live production data in test environments unless formally anonymised.	A database refresh script that automatically scrubs PII and replaces it with synthetic data for testing.
8. Authorised Security Testing	Documented Rules of Engagement (RoE) for any penetration testing or vulnerability scanning.	A signed RoE document specifying the IP ranges, timeframes, and tools used for a pre-launch security scan.
9. Incident Reporting Paths	Clearly defined escalation routes for security concerns within the project team structure.	Project meeting minutes where the ‘Security Incident Escalation’ process was briefed to all external contractors.
10. Secure Project Closure	A formal offboarding process to revoke access and archive project data securely.	An offboarding checklist proving all temporary contractor accounts were disabled within 24 hours of project completion.

Project Lifecycle Matrix

Phase	Waterfall (Traditional)	Agile (Scrum/DevOps)	ISO 27001:2022 Control
Initiation	Project Risk Assessment (PID).	Security “User Stories” in Backlog.	Annex A 5.8 / 5.7
Planning	Security Requirements Spec.	Threat Modelling the Feature.	Annex A 5.8 / 8.25
Execution	Build & Config Reviews.	Automated SAST/DAST in Pipeline.	Annex A 5.8 / 8.28
Closure	Go-Live Security Sign-off.	“Definition of Done” (Security Checks).	Annex A 5.8 / 8.29

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 it

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.

Audit Checklist

Audit Check	Audit Requirement (What to Check)	Auditor Evidence Example	GRC Platform Check
1. Project Mandate	Verify that security requirements are defined at the start of every project.	Initial project charter or initiation document with a dedicated security section.	Check the ‘Project Initiation’ workflow for a mandatory security field.
2. Risk Assessment	Confirm that a formal security risk assessment was conducted for the project.	A signed project-specific risk register with identified threats and mitigations.	Review the ‘Risk Module’ for project-linked risk entries.
3. Roles & Responsibilities	Ensure specific security roles are assigned within the project team.	A project RACI matrix defining who is responsible for security sign-off.	Verify the project user group has assigned security owners.
4. Environment Segregation	Check for logical or physical separation between dev, test, and production.	Network diagrams or cloud configuration showing isolated VPCs/subnets.	Check the ‘Asset Register’ for environment classification tags.
5. Secure Coding	Verify the use of secure development standards and peer reviews.	GitHub pull request logs showing security-focused code reviews.	Audit the ‘Policy Library’ for a linked Secure Development Policy.
6. Test Data Protection	Ensure production data is not used in test environments without masking.	Evidence of data masking scripts or anonymised test database refreshes.	Confirm ‘Data Classification’ rules prohibit raw PII in test areas.
7. Security Testing	Confirm vulnerability scans or penetration tests were performed before launch.	A completed penetration test report with evidence of closed ‘High’ findings.	Review the ‘Control evidence’ folder for the latest RoE and report.
8. Third-Party Access	Verify that external consultants have signed NDAs and have limited access.	Signed supplier contracts with ‘Right to Audit’ clauses and MFA logs.	Check the ‘Vendor Management’ module for project-linked third parties.
9. Incident Escalation	Check that project teams know how to report security incidents.	Project meeting minutes where incident reporting processes were briefed.	Verify the project dashboard has a ‘Report Incident’ link.
10. Project Closure	Verify that access is revoked and documentation is archived at project end.	An offboarding checklist confirming developer access was revoked on project close.	Check the ‘User Access Review’ for project-specific account deactivation.

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.

ISO 27001 Annex A 5.8 Mapped to Project Management Methodologies

Methodology	Phase / Ceremony	Annex A 5.8 Implementation (The Audit Requirement)
Waterfall	Requirement Gathering & Analysis	Formalise security requirements within the Business Requirements Document (BRD). I want to see signed-off security specifications before any design work begins.
Waterfall	Testing / UAT	Conduct formal vulnerability scans and penetration testing. Evidence of remediation for ‘High’ risks is mandatory before the project moves to the ‘Go-Live’ phase.
Agile (Scrum)	Backlog Refinement	Embed security ‘User Stories’ and ‘Abuser Stories’ into the product backlog. Security must be part of the prioritisation process, not an afterthought.
Agile (Scrum)	Sprint Review / Definition of Done	Update your ‘Definition of Done’ (DoD) to include security checks. No story is ‘Done’ until it passes automated security linting or peer review.
DevOps / DevSecOps	Continuous Integration (CI)	Automate SAST (Static Analysis) and DAST (Dynamic Analysis) within the pipeline. This provides the continuous audit trail required by Annex A 5.8.
Prince2	Starting Up a Project (SU)	The Project Brief must include the Information Security Strategy. I expect to see the ‘Security Risk Owner’ defined within the Project Board roles.
Prince2	Managing a Stage Boundary (SB)	Review the Project Risk Register. You must prove that security risks identified in the previous stage have been mitigated before the Board authorises the next stage.
Lean	Value Stream Mapping	Identify security bottlenecks as ‘waste’ if they are bolton-ons. Integrate security into the ‘flow’ to ensure compliance does not impede delivery speed.
Kanban	Visualise Workflow	Include ‘Security Review’ as a specific column on your Kanban board. This provides immediate visual evidence to an auditor that security checkpoints are being followed.

Security-by-Design Map

Project Phase	The “Healthy” Project (Annex A 5.8 Compliant)	The “Audit-Fail” Project (Bolt-On Security)	Lead Auditor Impact Assessment
Project Initiation	Security requirements and compliance mandates are defined within the Project Brief.	Security is not mentioned; focus is entirely on speed-to-market and functionality.	Fail: You cannot retroactively fix a project that was designed with fundamentally insecure requirements.
Planning & Design	A formal project-specific risk assessment is conducted and signed off by the Board.	General organisational risks are used; no project-specific threat modelling is performed.	Fail: I want to see a Project Risk Register, not just a link to the main organisational ISMS register.
Development / Build	Secure coding standards (OWASP) and peer reviews are mandatory ‘Definition of Done’ items.	Developers use unverified libraries and copy-paste code without security oversight.	Fail: Lack of peer reviews or SAST/DAST evidence in the pipeline is a major nonconformity.
Testing / UAT	Security testing and vulnerability scans are performed in a segregated test environment.	Live production data is ‘shipped’ to a test environment to save time on data masking.	Fail: Using PII in test environments is a breach of both Annex A 5.8 and GDPR.
Go-Live / Launch	Final security sign-off is a mandatory stage-gate before production deployment.	Security is called in 48 hours before launch to ‘give it the once-over.’	Fail: Security cannot ‘bless’ a project at the 11th hour. This is the definition of a bolt-on failure.
Post-Closure	Temporary project access is revoked and all technical documentation is securely archived.	Contractor accounts remain active for months; project docs are left in unmanaged cloud folders.	Fail: Zombie accounts are one of the most common findings in a surveillance audit.

ISO 27001 Annex A 5.8 for Non Technical Projects

Non-Technical Project Example	Information Security Risk (The ‘Audit-Fail’)	Mandatory Audit Evidence (Annex A 5.8 Compliant)
Office Relocation or Move	Unauthorised access to physical assets and the insecure disposal of sensitive paper records or old hardware.	A physical security risk assessment for the new premises and a signed certificate of destruction for all disposed data.
Marketing Campaign / New Landing Page	Uncontrolled collection of PII (Personally Identifiable Information) and lack of privacy notices leading to GDPR breaches.	A Data Protection Impact Assessment (DPIA) and evidence that the lead capture tool uses encryption and MFA.
HR Restructure or Redundancy Project	Breach of confidentiality regarding sensitive employee data and delayed revocation of access for leavers.	A project-specific NDA for the HR team and a timed access revocation log for all affected staff.
New Supplier Procurement	Sharing sensitive organisational intellectual property with a third party before they are formally vetted.	A Supplier Risk Assessment and a signed contract containing the ‘Right to Audit’ and security compliance clauses.
Merger or Acquisition (M&A)	Integration of an insecure legacy network into the secure organisational perimeter without due diligence.	A security due diligence report and a formal transition plan for aligning the new entity with the existing ISMS.

Applicability across different business models

Business Type	Applicability & Interpretation	Examples of Control
Small Businesses	The “New Thing” Checklist. You don’t use Prince2. Compliance means simply checking security whenever you do something new (e.g., “New CRM Project”). It prevents you from picking a cheap vendor that leaks data.	• Project Initiation Document (PID): Adding a single section called “Security Risks” to your project proposal template. • Vendor Selection: Checking if the new “Booking System” has 2FA and encryption before paying the invoice, not after.
Tech Startups	Agile Security Stories. Security cannot be a “Blocker” at the end. It must be a “Feature” in the backlog. Auditors look for security tickets in Jira/Linear alongside functional requirements.	• Definition of Done (DoD): Adding “Security Unit Tests Passed” and “SAST Scan Clean” to the DoD for every sprint. • Security Champion: Assigning a developer in the squad to wear the “Security Hat” during planning poker to ask, “How could this feature be hacked?”
AI Companies	Model Risk Assessment. Projects often involve gathering massive datasets. Security in Project Management means assessing the legal/privacy risk of that data before training begins.	• Data Privacy Impact Assessment (DPIA): Making a DPIA a mandatory “Gate” before any project moves from “Research” to “Training Phase.” • Poisoning Checks: Including a project milestone to test the model for adversarial attacks or data poisoning vulnerabilities before public release.

Applicable Laws and Related Standards

Standard or Law	Relevant Requirement	Relationship to Annex A 5.8
NIST CSF 2.0	GV.SC (Supply Chain) & PR.DS (Data Security)	NIST requires security to be integrated into the system development life cycle (SDLC). Annex A 5.8 provides the governance framework to meet these NIST outcomes during project execution.
NIS2 Directive (EU)	Article 21 (Risk Management)	NIS2 mandates “security in network and information systems acquisition, development and maintenance.” Annex A 5.8 is the primary mechanism for proving this compliance during infrastructure projects.
DORA (Digital Operational Resilience Act)	Article 8 (ICT Risk Management)	Financial entities must manage ICT risk across all project phases. Annex A 5.8 ensures that security risk assessments are conducted at every milestone, as required by DORA.
UK Data (Use and Access) Act 2025	Reduced Admin / High Security Thresholds	This evolution of UK GDPR requires “appropriate technical and organisational measures.” Annex A 5.8 proves that data protection is considered during the design phase of any project handling personal data.
UK Cyber Security and Resilience Bill	Managed Service Provider (MSP) Reporting	Expands mandatory reporting for MSPs. Implementing Annex A 5.8 ensures that security incidents within project environments are identified and reported in line with these new UK requirements.
GDPR (EU & UK)	Article 25 (Privacy by Design and Default)	Annex A 5.8 is the direct operational implementation of Privacy by Design. It ensures that data protection impact assessments (DPIAs) are integrated into project initiation.
SOC2 (Trust Services Criteria)	Common Criteria (CC) Series	SOC2 requires evidence of change management and secure system development. Annex A 5.8 provides the “what to check” for auditors reviewing project-related system changes.
EU AI Act & AI Standards (ISO 42001)	Risk Management & Data Governance	AI projects carry extreme data risks. Annex A 5.8 provides the project management framework required to manage the unique data lifecycle risks associated with AI model training and deployment.
CIRCIA (USA)	72-Hour Incident Reporting	Mandates rapid reporting for critical infrastructure. Annex A 5.8 ensures project teams have the communication paths established to report breaches within these strict US timeframes.
EU Product Liability Directive (Update)	Strict Liability for Software Flaws	Extends liability to providers for cybersecurity flaws. Annex A 5.8 mitigates legal risk by proving that “due professional care” was taken during the software project lifecycle.
ECCF (European Cybersecurity Cert. Framework)	Harmonised Security Labels	Annex A 5.8 ensures that the development of products meets the baseline security requirements necessary to achieve EU-wide certification and labeling.
HIPAA (USA)	Technical Safeguards (45 CFR § 164.312)	Requires security for health information in motion and at rest. Annex A 5.8 ensures these safeguards are designed into any project involving Protected Health Information (PHI).
CCPA / CPRA (California)	Consumer Privacy Rights	Requires businesses to implement reasonable security procedures. Annex A 5.8 provides the evidence of “reasonable security” for any project affecting California residents’ data.

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

FAQ

About the author