ISO 27001 Annex A 5.8 focuses on ensuring that information security is considered and managed throughout the lifecycle of projects.
The purpose is to make sure that security is not treated as something to address only after a project is completed.
Information security should be considered:
- When a project is initiated
- During project planning
- During requirements definition
- During design and development
- During implementation
- During testing
- Before deployment
- During project closure
Simple explanation
A.5.8 means information security should be built into project management from the beginning rather than being added at the end.
For example, if a company is developing a new SaaS application, security requirements should be considered before development starts—not after the application is ready for customers.
Why is A.5.8 important?
Projects often introduce significant changes to an organization’s:
- Technology
- Processes
- Applications
- Infrastructure
- Data
- Suppliers
- Business operations
- Customer services
If security is not considered during the project, vulnerabilities or compliance issues may become expensive to fix later.
Good project security management can help organizations:
- Identify security risks early
- Define security requirements
- Protect sensitive information
- Prevent unauthorized access
- Reduce vulnerabilities
- Meet compliance requirements
- Protect customer data
- Manage third-party risks
- Avoid security issues during deployment
- Ensure security controls are implemented before go-live
Simple principle
Security should be part of the project plan—not a last-minute checklist before launch.
What does A.5.8 require?
The organization should integrate information security requirements and risk management into its project management processes.
This means that projects should consider security based on:
- Project objectives
- Information being processed
- Systems being developed or changed
- Business impact
- Security risks
- Legal and regulatory requirements
- Customer requirements
- Privacy requirements
- Third-party involvement
- Technology architecture
The level of security management should be proportionate to the project’s size, complexity and risk.
Which projects should consider A.5.8?
A.5.8 can apply to many types of projects.
Examples include:
- New software development
- SaaS product development
- Cloud migration
- ERP implementation
- CRM implementation
- Mobile application development
- Website development
- Infrastructure upgrades
- Data migration
- New office or data-center implementation
- AI implementation
- New payment system
- New customer portal
- Acquisition of a new technology
- Major business-process changes
- Integration with third-party systems
Not every small operational task needs a large formal security project process.
The organization should determine an appropriate level of security based on risk.
Activities required to implement A.5.8
1. Identify security requirements at project initiation
Security should be considered when the project is being planned.
Questions may include:
- What information will the project process?
- Is sensitive or personal information involved?
- Will customer data be processed?
- Will the system be internet-facing?
- Will third parties have access?
- What regulations apply?
- What security controls are required?
- What customer security requirements exist?
Example
A SaaS startup plans to develop a customer portal.
Before development begins, the project team identifies requirements for:
- Authentication
- Authorization
- Encryption
- Logging
- Secure development
- Vulnerability management
- Backup
- Data protection
- Incident management
These requirements become part of the project requirements.
2. Perform security risk assessment
Security risks should be identified during project planning.
For example:
| Risk | Impact | Likelihood | Treatment |
|---|---|---|---|
| Unauthorized access | High | Medium | MFA + access controls |
| Data leakage | High | Medium | Encryption + DLP controls |
| Vulnerable application | High | Medium | Secure SDLC + testing |
| Third-party compromise | High | Medium | Vendor assessment |
| Data loss | High | Low | Backup + recovery testing |
The risk assessment should be appropriate to the project’s complexity.
3. Define security responsibilities
Project responsibilities should be clearly assigned.
For example:
| Responsibility | Owner |
|---|---|
| Project security requirements | Project Manager |
| Security architecture | Security/Engineering |
| Privacy requirements | Privacy/Compliance |
| Application security | Development Team |
| Security testing | Security/QA |
| Risk approval | Risk Owner |
| Final security review | Security Lead |
In a small startup, one person may perform several roles.
4. Include security requirements in project planning
Security activities should be incorporated into the project plan.
For example:
Project Plan
Phase 1 – Requirements
- Identify security requirements
- Identify compliance requirements
- Identify data classification
↓
Phase 2 – Design
- Security architecture review
- Access-control design
- Encryption requirements
- Data-flow review
↓
Phase 3 – Development
- Secure coding
- Code review
- Dependency management
- Secrets management
↓
Phase 4 – Testing
- Vulnerability testing
- Security testing
- VAPT where appropriate
- Access-control testing
↓
Phase 5 – Deployment
- Production security configuration
- Logging and monitoring
- Backup
- Access review
↓
Phase 6 – Go-Live
- Security approval
- Risk acceptance where applicable
- Evidence collection
This ensures security is built into the project lifecycle.
5. Consider legal and regulatory requirements
Projects should identify applicable legal, regulatory and contractual requirements.
Depending on the organization, this could include:
- GDPR
- DPDP Act
- HIPAA
- PCI DSS
- RBI requirements
- Customer contractual requirements
- Industry-specific requirements
- ISO 27001 requirements
- Data residency requirements
Example
If a project will process customer personal information, privacy and data-protection requirements should be identified before the system is designed.
6. Consider third-party and supplier risks
Many projects depend on external providers.
Examples:
- Cloud providers
- SaaS applications
- Developers
- Consultants
- API providers
- Payment providers
- Managed service providers
The project should determine:
- What information will be shared?
- What access will the supplier receive?
- What security controls are required?
- What contractual protections are required?
- How will supplier security be assessed?
7. Include security testing
Security testing should be planned rather than performed only when someone remembers it before launch.
Depending on the project, testing may include:
- Vulnerability assessment
- VAPT
- Penetration testing
- Secure code review
- Dependency scanning
- Configuration review
- Access-control testing
- API security testing
- Cloud security assessment
- Security architecture review
The testing approach should be appropriate to the risk.
8. Establish security gates before deployment
Projects can use security checkpoints before moving to the next stage.
For example:
Security Gate 1 – Design
Are security requirements defined?
↓
Security Gate 2 – Development
Have security requirements been implemented?
↓
Security Gate 3 – Testing
Have identified security risks been tested?
↓
Security Gate 4 – Production
Are critical security issues resolved or formally accepted?
↓
Security Gate 5 – Go-Live
Has the appropriate person approved the security status?
This is particularly useful for software and technology projects.
9. Manage changes during the project
Project requirements often change.
For example:
The project originally planned to process only employee information.
Later, the business decides to process customer payment information.
This change may introduce new:
- Security risks
- Privacy requirements
- Compliance requirements
- Access controls
- Encryption requirements
- Testing requirements
Therefore, significant project changes should be reviewed for their security impact.
10. Maintain security documentation and evidence
The organization should retain appropriate evidence throughout the project.
Examples:
- Project security requirements
- Risk assessments
- Security architecture
- Data-flow diagrams
- Security review records
- Security test results
- VAPT reports
- Vulnerability reports
- Risk acceptance records
- Security approval
- Change records
The amount of documentation should be proportionate to the project.
Startup Example
Consider a SaaS startup launching a new AI-powered customer platform.
The project involves:
- Customer data
- AI APIs
- Cloud infrastructure
- Third-party SaaS tools
- Internet-facing applications
Project starts
The team identifies:
Data
Customer and personal information.
↓
Security Requirements
Authentication, authorization, encryption and logging.
↓
Compliance
Customer contractual requirements and applicable privacy requirements.
↓
Architecture
Cloud security and network design reviewed.
↓
Development
Secure coding and dependency management implemented.
↓
Testing
Application security testing and vulnerability assessment performed.
↓
Deployment
Production configuration and monitoring implemented.
↓
Go-Live
Open critical security issues are addressed or formally accepted by the appropriate risk owner.
This demonstrates that security was integrated into the project rather than added after development.
Simple Startup Approach
A startup does not necessarily need a large Project Security Management Office.
A practical approach can be:
- Identify whether the project has security implications.
- Identify the information and systems involved.
- Identify applicable security and compliance requirements.
- Perform a basic security risk assessment.
- Define security requirements.
- Assign security responsibilities.
- Include security activities in the project plan.
- Perform appropriate security testing.
- Resolve or formally accept significant risks.
- Retain evidence.
Simple rule
If a project changes technology, data, systems, access or business processes, ask what security impact the change creates.
Example Project Security Checklist
| Security Question | Yes/No/N/A |
|---|---|
| Does the project process sensitive information? | |
| Does it process personal data? | |
| Is the system internet-facing? | |
| Are third parties involved? | |
| Are new user accounts or privileges required? | |
| Are new APIs introduced? | |
| Are new cloud services introduced? | |
| Are regulatory requirements applicable? | |
| Have security requirements been defined? | |
| Has a security risk assessment been completed? | |
| Has security architecture been reviewed? | |
| Has appropriate security testing been performed? | |
| Have critical vulnerabilities been addressed? | |
| Are unresolved risks formally accepted? | |
| Has security approval been obtained before go-live? |
Example Project Security Register
| Project | Security Requirement | Risk | Owner | Status | Evidence |
|---|---|---|---|---|---|
| Customer Portal | MFA | Unauthorized access | IT Lead | Implemented | Test Record |
| Mobile App | Secure API | Data exposure | Security Lead | In Progress | VAPT |
| Cloud Migration | Encryption | Data exposure | Cloud Lead | Implemented | Configuration |
| AI Platform | Data protection | Information leakage | Security Lead | In Progress | Risk Assessment |
A.5.8 Audit Evidence
An auditor may look for evidence such as:
Project planning
- Project plans
- Project charters
- Project security requirements
- Security checklists
Risk management
- Project risk assessments
- Security risk registers
- Risk treatment plans
- Risk acceptance records
Security design
- Architecture diagrams
- Data-flow diagrams
- Security design reviews
- Access-control design
Security testing
- VAPT reports
- Vulnerability scans
- Code review results
- Security test cases
- Remediation evidence
Approval
- Security sign-off
- Go-live approval
- Risk-owner approval
- Change-management records
A.5.8 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Are information security requirements considered during project planning? | Project Security Requirements |
| Are security risks identified? | Project Risk Assessment |
| Are security responsibilities assigned? | RACI / Project Plan |
| Are applicable legal and regulatory requirements identified? | Compliance Assessment |
| Are security requirements incorporated into project activities? | Project Plan |
| Are third-party security risks considered? | Supplier Assessment |
| Is security testing performed where appropriate? | Test Reports |
| Are significant security issues addressed before deployment? | Remediation Records |
| Are unresolved risks formally accepted? | Risk Acceptance |
| Are major project changes reviewed for security impact? | Change Records |
| Is security approval obtained before go-live where appropriate? | Security Sign-off |
| Is project security evidence retained? | Project Documentation |
Common Mistakes
1. Checking security only before go-live
Security should not be a final checklist.
Security requirements should be considered from the beginning.
2. Assuming developers are automatically responsible for security
Security responsibilities should be explicitly assigned.
3. No security requirements in the project plan
If security activities are not planned, they can easily be forgotten or delayed.
4. Ignoring project changes
A change in scope can introduce completely new security risks.
For example:
Internal application → Customer-facing application
may significantly change the security requirements.
5. Performing testing without fixing findings
Security testing is useful only when identified issues are evaluated and appropriately addressed.
6. No evidence
The project team may say:
“Security was considered during development.”
The auditor may ask:
“Show me where.”
Maintain reasonable evidence of security decisions and activities.
Practical Implementation Model
A simple A.5.8 implementation model is:
Project Initiation
↓
Identify Security Requirements
↓
Identify Risks
↓
Define Security Controls
↓
Design & Development
↓
Security Testing
↓
Risk Review
↓
Security Approval
↓
Deployment
↓
Project Closure & Lessons Learned
Policy vs. Process vs. Evidence
| Element | Example |
|---|---|
| Policy | Information security requirements shall be considered throughout the lifecycle of projects. |
| Process | Projects identify security requirements, assess risks, implement controls and perform appropriate security reviews before deployment. |
| Evidence | Project security checklist, risk assessment, architecture review, VAPT report, remediation records and security approval. |
The objective is not to create excessive project documentation.
The objective is to ensure that security is considered when decisions are made—not after those decisions have already created security problems.
Useful Resources
Recommended documents
- Project Security Checklist – [Insert Draft Document Link]
- Project Security Requirements Template – [Insert Draft Document Link]
- Project Risk Assessment Template – [Insert Draft Document Link]
- Security Architecture Review Template – [Insert Draft Document Link]
- Secure Development Checklist – [Insert Draft Document Link]
- Security Testing Checklist – [Insert Draft Document Link]
- Go-Live Security Approval Form – [Insert Draft Document Link]
Related ISO 27001 controls
A.5.8 can work closely with:
- A.5.1 – Policies for information security
- A.5.2 – Information security roles and responsibilities
- A.5.8 – Information security in project management
- A.5.19 – Information security in supplier relationships
- A.5.23 – Information security for use of cloud services
- A.5.31 – Legal, statutory, regulatory and contractual requirements
- A.8.25 – Secure development life cycle
- A.8.26 – Application security requirements
- A.8.29 – Security testing in development and acceptance
- A.8.32 – Change management
Final Takeaway
ISO 27001 Annex A 5.8 is about making information security part of project management from the beginning to the end of a project.
A practical organization should be able to answer:
What security requirements does this project have?
What security risks could the project introduce?
Who is responsible for managing them?
What security controls have been implemented?
Has appropriate security testing been completed?
Who approved the security risk before go-live?
For startups, the approach can remain simple:
Identify → Assess → Plan → Implement → Test → Approve → Deploy → Review
The objective is not to slow projects down with unnecessary compliance activities.
It is to make sure that security keeps pace with the project instead of becoming a problem after the project is completed.