ISO 27001 A.5.8: Information Security in Project Management

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.8 asks for information security to be integrated into project management. ISO 27002 says this applies to any type of project, whatever its size, complexity, duration or subject, from initiation through closure.

The Bottom Line: Every project introduces change, and every change introduces risk. If security is not baked into your project management methodology, you are building vulnerabilities into your organization one project at a time.

What the Control Asks For

The ISO 27001:2022 Text

In short:

ISO 27001:2022 Annex A 5.8 asks organizations to build information security into project management.

Do you need this control?

A.5.8 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you run projects that create or change information systems or processes. An organisation with no projects in scope could exclude it, but most have at least IT or product projects, so the usual adaptation is to scale the security steps to project risk.

What ISO 27002:2022 Recommends (in Our Words)

Integrate security into whatever project method you use, for any type of project (business process, ICT, facilities, supporting processes), so that:

• security risks are assessed and treated early and periodically as part of project risks;
• security requirements (for example application security, A.8.26, and intellectual property, A.5.32) are addressed early;
• risks from running the project itself, such as the security of project communications, collaboration tools and project data, are treated throughout;
• progress on risk treatment is reviewed and its effectiveness evaluated and tested;
• security is followed up at predefined stages by suitable people or bodies, such as the steering committee;
• security responsibilities in the project are defined and assigned;
• security requirements for all deliverables are determined, from policies and regulations, and from threat modelling, incident reviews, vulnerability thresholds and contingency planning. ISO 27002 lists what to consider: the information involved and its classification, protection needs, identity assurance, access provisioning, user duties, business-process needs such as logging and non-repudiation, other controls' requirements, and legal and contractual obligations. Supplier deliverables need their security requirements in contracts (A.5.20).

Six Practical Components (good practice, not ISO requirements)

Why Information Security in Project Management Matters

The Cost of Security as an Afterthought

The Indian Context

India's digital transformation is accelerating, and many incidents CERT-In handles trace back to systems deployed without security review. Building security into projects is the cheapest way to avoid that.

For Indian B2B tech companies serving global clients, project security is a competitive differentiator. A SaaS company from Bengaluru that can demonstrate secure project management practices wins enterprise contracts over competitors that cannot.

Scope and Applicability

What Projects Are Covered

Control A.5.8 applies to all projects, regardless of type, size, budget, or duration. This includes:

Exclusions (None)

If you include A.5.8, apply it to every kind of project, scaled to its risk. ISO 27002 says integration applies to projects of any size, complexity or duration; a two-week low-risk project may need only a short checklist.

Organizational Scope

Key Definitions and Terminology

Relationship to Other Controls

Control A.5.8 does not operate in isolation. It intersects with multiple other Annex A controls across all four themes of Annex A (organizational, people, physical and technological).

Organizational Controls (5.x)

People Controls (6.x)

Physical Controls (7.x)

Technological Controls (8.x)

The A.5.8 ↔ A.8.25 ↔ A.8.29 Triad

For software development projects, three controls form a critical triad:

• A.5.8: Ensures security is managed at the project level (planning, governance, resources, risk)
• A.8.25: Ensures security is embedded in the development lifecycle (requirements, design, code, test)
• A.8.29: Ensures security testing is performed before acceptance

Auditors will look for the links between them where all three are in your Statement of Applicability.

Implementation Roadmap (Week-by-Week)

Standard Implementation: 8 Weeks

The following roadmap is designed for growing companies (250-5000 employees) with a moderate project volume (10-30 concurrent projects). Adjust timeline for smaller or larger organizations.

Accelerated Implementation: 4 Weeks

For smaller organizations or those with urgent certification deadlines:

Enterprise Implementation: 12 Weeks

For large organizations with complex PMO structures, multiple methodologies (Waterfall, Agile, SAFe), and global project teams:

Detailed Implementation Guidance

Figure · Tiers

Maturity levels for in project management

Phase 1: Project Initiation, Embedding Security from the Start

The initiation phase is where security requirements are defined, resources are allocated, and the security risk baseline is established. This is the most critical phase. Security decisions made here are far cheaper to change than decisions made after build.

Step 1: Security Classification of the Project

Every project must be classified by security criticality:

Step 2: Security Requirements Elicitation

For each project, security requirements must be elicited from:

1. Business requirements: What data will the project handle? What regulations apply? What is the business impact of a breach?
2. Threat landscape: What threats are relevant to this project type? (Use industry threat intelligence, CERT-In advisories, OWASP Top 10)
3. Regulatory requirements: DPDP Act 2023, RBI Master Direction, SEBI CSCRF (2024), IRDAI Guidelines, PCI DSS, GDPR (if EU customers)
4. Customer contractual requirements: Security clauses in customer contracts, SOC 2 commitments, ISO 27001 certification scope
5. Internal policy requirements: Information security policy, data classification policy, acceptable use policy, password policy

Document all requirements in the Security Requirements Specification (SRS) document.

Step 3: Project Security Risk Assessment

Conduct a project-specific risk assessment covering:

Risk scoring methodology: Use a 5x5 matrix (Likelihood x Impact) with explicit thresholds. For example:

• Risk Score 15-25 (Red): Must be treated before project proceeds; escalate to CISO
• Risk Score 8-14 (Amber): Must be treated before go-live; monitor during project
• Risk Score 1-7 (Green): Accept with monitoring; document in risk register

Step 4: Assign Project Security Officer (PSO)

Every project rated Medium or above must have a named PSO. The PSO is accountable for:

• Ensuring security requirements are defined and tracked
• Conducting security reviews at gates
• Reporting security risks to the project steering committee
• Coordinating with the enterprise security team
• Ensuring security acceptance criteria are met

The PSO does not need to be a full-time security professional but must have completed security training and have access to the security team for guidance.

Phase 2: Project Planning, Security in the Plan

Step 5: Security Work Breakdown Structure

Security activities must be explicit in the project plan with allocated resources, timelines, and budgets. Example WBS for a Critical project:

Rule of thumb: Security should constitute 8-15% of total project effort for Critical projects, 5-10% for High, 3-5% for Medium, and 1-2% for Low.

Step 6: Security Gate Planning

Define the security gates for the project methodology:

Waterfall/Traditional Projects:

• Gate 1: Requirements, Security requirements approved
• Gate 2: Design, Security architecture and threat model approved
• Gate 3: Build, Security coding standards verified; SAST clean
• Gate 4: Test, DAST clean; penetration test passed; no Critical/High vulnerabilities open
• Gate 5: Deployment, Security acceptance criteria met; ops team trained; documentation complete
• Gate 6: Closure, Lessons learned captured; security handover complete

Agile/Scrum Projects:

• Sprint 0: Security requirements and threat model defined
• Every Sprint: Security review in sprint retrospective; SAST/DAST in CI/CD
• Release Planning: Security risk review for release scope
• Pre-Release: Security acceptance criteria verification; penetration test if major release
• Post-Release: Security monitoring validation; incident response readiness check

Step 7: Security Budget Allocation

Security costs must be explicitly budgeted. Typical budget items:

• Security tooling licenses (SAST, DAST, SCA, secrets scanning)
• External security testing (penetration testing, red team)
• Security training for project team
• Security consultant or architect time
• Compliance validation (audit, legal review)
• Security documentation and knowledge management

Phase 3: Design, Security Architecture and Threat Modeling

Step 8: Threat Modeling

For all Critical and High projects, and for any project introducing new architecture or technology, formal threat modeling is mandatory.

Example STRIDE Threat Model for an Indian Fintech Mobile App:

Step 9: Security Architecture Review

The security architecture must be reviewed against:

• Defence in depth: Multiple layers of security controls
• Least privilege: Minimum access required for each component
• Fail secure: System fails to a secure state
• Separation of duties: No single individual has complete control
• Auditability: All security-relevant actions are logged

Phase 4: Build/Development, Secure Implementation

Step 10: Secure Coding and Verification

For software projects:

• Enforce secure coding standards (OWASP ASVS Level 2 for web apps)
• Run SAST on every commit (SonarQube, Checkmarx, Semgrep)
• Run SCA (Software Composition Analysis) to detect vulnerable dependencies (Snyk, OWASP Dependency-Check)
• Run secrets scanning (GitLeaks, TruffleHog) to prevent credential leakage
• Conduct peer code reviews with security focus
• Maintain a security bug bar: No Critical or High vulnerabilities in production code

Step 11: Environment Security

• Maintain strict separation between development, testing, staging, and production environments (A.8.31)
• Production data must never be used in non-production environments without anonymization
• Development environments must have equivalent security controls to production where feasible
• Access to source code repositories must be controlled and logged

Phase 5: Testing, Security Validation

Step 12: Security Testing Pyramid

Step 13: Security Acceptance Criteria

Before any project goes live, the following criteria must be verified and signed off:

Phase 6: Deployment, Secure Go-Live

Step 14: Deployment Security Checklist

• Production environment hardened per security baseline
• All default passwords changed
• Unnecessary services disabled
• Firewall rules reviewed and minimized
• Logging and monitoring configured and verified
• Backup and recovery tested
• Rollback plan documented and tested
• Communication plan for go-live (including security monitoring)
• Business continuity verification

Step 15: Go-Live Security Gate

The final security gate before go-live must include:

1. Review of all security evidence from the project
2. Confirmation that all acceptance criteria are met
3. Verification that no new risks have emerged during testing
4. Sign-off from PSO, CISO, and Project Sponsor
5. Formal authorization to proceed documented

Phase 7: Closure, Knowledge Transfer and Lessons Learned

Step 16: Security Handover to Operations

The project team must transfer to operations:

• All security documentation (architecture, configurations, procedures)
• Security monitoring rules and alerts
• Incident response playbooks for the new system
• Known risks and residual risk acceptance
• Security training materials for end users and administrators
• Contact information for security escalations

Step 17: Lessons Learned

Capture security-specific lessons learned:

• What security risks were underestimated?
• What security controls were more effective than expected?
• What security tools or processes caused delays?
• What would be done differently next time?

Feed these into the organization's security knowledge base and update project security templates accordingly.

Tools, Technologies, and Solutions

Project Management Tools with Security Integration

Security-Specific Development Tools

Indian Market Considerations

Policy and Procedure Templates

Project Security Policy (Template Outline)

1. Purpose and Scope
   1.1 Purpose: Define requirements for integrating information security into all projects
   1.2 Scope: All projects regardless of type, size, or duration
   1.3 Applicability: All employees, contractors, and third parties involved in projects

2. Roles and Responsibilities
   2.1 Project Sponsor: Accountable for project security budget and outcomes
   2.2 Project Manager: Responsible for ensuring security activities are planned and executed
   2.3 Project Security Officer (PSO): Responsible for security requirements, reviews, and acceptance
   2.4 CISO: Accountable for enterprise project security framework and standards
   2.5 Security Architect: Responsible for security architecture and threat modeling
   2.6 Development Team: Responsible for secure implementation and testing

3. Project Security Classification
   3.1 Classification criteria and methodology
   3.2 Classification authority and review process

4. Security Requirements
   4.1 Mandatory security requirements for each classification level
   4.2 Regulatory requirements mapping
   4.3 Customer contractual requirements

5. Security Risk Assessment
   5.1 Timing: Must be completed before project approval
   5.2 Methodology: 5x5 risk matrix
   5.3 Review triggers: Scope change, technology change, threat landscape change

6. Security Gates
   6.1 Gate definitions for Waterfall, Agile, and Hybrid methodologies
   6.2 Gate criteria and evidence requirements
   6.3 Escalation process for failed gates

7. Security Testing and Acceptance
   7.1 Testing requirements by classification
   7.2 Acceptance criteria and sign-off process
   7.3 Exception handling and risk acceptance

8. Security Documentation and Handover
   8.1 Required documentation by classification
   8.2 Handover process to operations
   8.3 Knowledge retention requirements

9. Training and Awareness
   9.1 Project team security training requirements
   9.2 PSO certification requirements
   9.3 Annual refresher training

10. Compliance and Audit
    10.1 Internal audit requirements
    10.2 Evidence retention
    10.3 Non-conformance handling

11. Policy Review
    11.1 Annual review cycle
    11.2 Trigger-based review (incident, regulation change, standard update)

Project Security Procedure (Template Outline)

Procedure: PRJ-SEC-001 Project Security Integration

1. Initiation Phase
   Step 1: Receive project request
   Step 2: Classify project security criticality (Critical/High/Medium/Low)
   Step 3: Assign Project Security Officer (PSO)
   Step 4: Conduct project security risk assessment
   Step 5: Define security requirements and document in SRS
   Step 6: Include security activities in project plan and budget
   Step 7: Obtain security approval for project charter

2. Planning Phase
   Step 8: Create Security Requirements Traceability Matrix (SRTM)
   Step 9: Define security gates and criteria
   Step 10: Plan security testing (SAST, DAST, Pen Test, etc.)
   Step 11: Schedule security training for project team
   Step 12: Plan security documentation deliverables

3. Design Phase
   Step 13: Conduct threat modeling (Critical/High projects)
   Step 14: Develop security architecture
   Step 15: Review security architecture against enterprise standards
   Step 16: Update SRTM with design decisions
   Step 17: Conduct Security Gate 2 (Design Review)

4. Build/Development Phase
   Step 18: Enforce secure coding standards
   Step 19: Execute SAST and SCA on every commit/PR
   Step 20: Execute secrets scanning on every commit
   Step 21: Conduct security-focused code reviews
   Step 22: Maintain security defect tracking
   Step 23: Conduct Security Gate 3 (Build Review)

5. Testing Phase
   Step 24: Execute DAST/IAST on test environment
   Step 25: Conduct security integration testing
   Step 26: Execute penetration testing (if required)
   Step 27: Verify all Critical/High vulnerabilities remediated
   Step 28: Update SRTM with test results
   Step 29: Conduct Security Gate 4 (Test Review)

6. Deployment Phase
   Step 30: Execute deployment security checklist
   Step 31: Verify production environment hardening
   Step 32: Verify logging and monitoring
   Step 33: Verify backup and recovery
   Step 34: Conduct Security Gate 5 (Go-Live Review)
   Step 35: Obtain formal security sign-off

7. Closure Phase
   Step 36: Complete security documentation
   Step 37: Conduct security handover to operations
   Step 38: Update incident response plan
   Step 39: Conduct lessons learned session
   Step 40: Archive project security evidence
   Step 41: Conduct Security Gate 6 (Closure Review)

Security Requirements Traceability Matrix (Template)

Risk Assessment and Treatment

Project-Specific Risk Assessment Methodology

While ISO 27001 requires an organizational risk assessment (Clause 6.1), A.5.8 requires a project-specific risk assessment for each project. This is more granular and focuses on risks introduced by the project itself.

Step 1: Identify Project Security Risks

Use the following categories to identify risks systematically:

Step 2: Analyze Risks

For each identified risk, determine:

• Likelihood (1-5): Probability the risk materializes

  • 1 = Rare (<1% per year)
  • 2 = Unlikely (1-10% per year)
  • 3 = Possible (10-50% per year)
  • 4 = Likely (50-90% per year)
  • 5 = Almost Certain (>90% per year)

• Impact (1-5): Severity if the risk materializes

  • 1 = Negligible (no significant impact)
  • 2 = Minor (localized, limited cost)
  • 3 = Moderate (significant cost, regulatory notice)
  • 4 = Major (severe cost, regulatory fine, reputational damage)
  • 5 = Catastrophic (organization-threatening, shutdown risk)

• Risk Score = Likelihood × Impact

Step 3: Evaluate and Treat

Treatment Options:

1. Avoid: Change project scope, design, or approach to eliminate the risk
2. Mitigate: Implement controls to reduce likelihood or impact
3. Share (ISO/IEC 27005 term): purchase insurance or contractually shift liability to a third party
4. Accept: Document and monitor if treatment cost exceeds risk impact

Sample Risk Register for an E-Commerce Platform Project

Audit and Compliance Checklist

Use this checklist during internal audits, certification audits, and customer audits. Each question should be answered with evidence.

Policy and Governance (5 questions)

Risk Assessment (5 questions)

Requirements and Design (5 questions)

Implementation and Testing (5 questions)

Acceptance and Deployment (5 questions)

Closure and Handover (5 questions)

Metrics and KPIs

Project Security KPIs

KPI Dashboard Layout

A sample monthly dashboard for the CISO and PMO:

PROJECT SECURITY DASHBOARD — June 2026
=======================================

Projects Active: 23
Projects Initiated (MTD): 5
Projects Closed (MTD): 4

COVERAGE METRICS
- Security Coverage: 100% (23/23) ✓
- Risk Assessment Completion: 100% (5/5) ✓
- Security Sign-off Rate: 100% (4/4) ✓

QUALITY METRICS
- Gate Pass Rate (First Attempt): 88% (22/25) ⚠️
- Vulnerability Remediation: 100% (12/12) ✓
- Documentation Completeness: 100% (4/4) ✓

EFFICIENCY METRICS
- Avg Security overhead per Project: - Security-Related Delays: 5% (1/20) ✓
- Post-Go-Live Incidents: 0 ✓

ACTIONS
1. Investigate Gate 2 (Design) failures in 3 projects — root cause: incomplete threat models
2. Update threat modeling template based on findings
3. Schedule refresher training for 2 project managers

Common Pitfalls and How to Avoid Them

The 15 Most Common Pitfalls

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Growing Fintech, Secure Payment Platform Project

Organization: Example Payments Pvt. Ltd. (a fictional company), a Bengaluru-based fintech startup with 180 employees, offering payment processing services to 2,500 Indian merchants.

Project: Development and launch of a new "Express Pay" real-time payment platform for UPI and card transactions.

Challenge:

• First-time ISO 27001 certification required to onboard a major e-commerce client
• Project team of 12 developers with limited secure coding experience
• Tight 6-month deadline driven by competitive market pressure
• Regulatory requirements: RBI Master Direction on Digital Payment Security, PCI DSS Level 1, DPDP Act 2023
• Budget constraints: Total security budget of for the project

Implementation Steps:

Step 1, Project Security Policy (Week 1): Example Payments engaged an external security consultant to draft a Project Security Policy tailored to their size. The policy defined two project security levels (Critical for payment systems, Standard for internal tools) and mandated a PSO for all Critical projects.

Step 2, Security Classification and PSO Assignment (Week 1): The Express Pay project was classified as Critical. The CTO was designated as PSO, with an external security architect providing 2 days per week of guidance.

Step 3, Project Security Risk Assessment (Week 2): A dedicated risk assessment identified 18 risks. The top 5 were:

1. Card data leakage through unencrypted logs (Risk Score: 20, Critical)
2. UPI fraud via API manipulation (Risk Score: 16, Critical)
3. Third-party payment gateway vulnerability (Risk Score: 12, High)
4. Insider threat from developer access to production (Risk Score: 10, High)
5. DDoS during festive season launch (Risk Score: 9, Medium)

Step 4, Threat Modeling (Week 3): Using STRIDE, the team identified 34 threats. The most critical, spoofing of merchant API credentials, led to a design change: moving from API-key authentication to mutual TLS with certificate pinning.

Step 5, Security Requirements and SRTM (Week 3): 47 security requirements were defined, covering encryption, authentication, logging, audit trails, and incident response. All were traced through design, code, and test.

Step 6, Secure Development and Testing (Weeks 4-18):

• SAST (SonarQube) integrated into GitHub Actions; every pull request scanned
• SCA (Snyk) tracked 156 dependencies; 3 vulnerable libraries replaced
• DAST (OWASP ZAP) ran nightly against the staging environment
• External penetration testing by an independent tester conducted in Week 16
• 12 Critical/High vulnerabilities found; all remediated by Week 18

Step 7, Security Gates (Throughout): Four gates defined:

• Gate 1 (Design): Threat model and architecture review, passed after one revision
• Gate 2 (Build): SAST clean, no secrets in code, passed on first attempt
• Gate 3 (Test): DAST clean, pen test passed, passed after remediation
• Gate 4 (Go-Live): Security acceptance criteria, ops handover, passed

Step 8, Go-Live and Handover (Week 20): The platform went live with zero security incidents in the first 90 days. Operations received complete documentation, monitoring rules, and an incident response playbook.

Outcome:

• Example Payments achieved ISO 27001 certification with no nonconformities raised against A.5.8 or A.8.25
• Major e-commerce client onboarded within 30 days of go-live
• Security budget of was fully used; total project budget was (security: 17.8%)
• Post-go-live security incident count: 0 in 6 months
• The Project Security Policy and templates were reused for 3 subsequent projects

Key Lessons:

1. Growing fintechs can achieve enterprise-grade project security with focused effort and the right templates
2. External external security expertise for 2 days/week provided sufficient guidance without full-time cost
3. Shift-left testing (SAST on every commit) prevented 80% of vulnerabilities from reaching test environments
4. The PSO role does not require a dedicated security hire if the right person (CTO) is trained and supported

Illustrative Scenario 2: Large Indian Enterprise, Multi-Year ERP Transformation

Listed on NSE and BSE.

Project: "Project Unity", a 3-year SAP S/4HANA ERP implementation replacing 7 legacy systems, covering finance, supply chain, manufacturing, HR, and customer management.

Challenge:

• Largest IT project in the company's 45-year history (budget: )
• Highly sensitive data: chemical formulas, customer contracts, employee records, financial data
• Regulatory exposure: SEBI listing regulations, DPDP Act 2023, OSH Code 2020, environmental regulations
• Multi-vendor ecosystem: SAP implementation partner, infrastructure provider, custom development vendor (local SI), cloud hosting (AWS India)
• 450+ users across 8 locations; complex role mapping from legacy systems
• Zero-downtime requirement for manufacturing plants (24/7 operations)

Implementation Steps:

Step 1, Enterprise Project Security Framework (Months 1-2): The consultant designed a complete Project Security Framework with:

• 4 security classification levels (Critical, High, Medium, Low)
• Methodology-specific playbooks (Waterfall for ERP core, Agile for custom mobile apps, Hybrid for integrations)
• Automated security gates in ServiceNow
• Dedicated PSO role for all Critical/High projects; 3 full-time PSOs hired

Step 2, Project Unity Security Governance (Month 1):

• Project Unity classified as Critical
• A dedicated Security Workstream was created within the program, led by a Senior Security Architect (reporting to CISO and Program Director)
• Monthly Security Steering Committee with CISO, CIO, Program Director, and vendor security leads

Step 3, Program-Level Security Risk Assessment (Month 2): A complete risk assessment identified 47 risks across the program. Top risks:

1. Data corruption during migration from 7 legacy systems (Score: 25, Catastrophic)
2. Unauthorized access to chemical formulas in SAP (Score: 20, Critical)
3. Supplier data leakage during cloud migration (Score: 16, Critical)
4. Inadequate segregation of duties in role design (Score: 15, Critical)
5. Insider threat from disgruntled legacy system administrators (Score: 12, High)

Step 4, Security Architecture and Threat Modeling (Months 2-4):

• Enterprise threat model using PASTA methodology; 78 threats identified
• Security architecture designed for SAP S/4HANA on AWS India (Mumbai region) with:
  • End-to-end TLS 1.3 encryption
  • Field-level encryption for chemical formulas using AWS KMS with HSM
  • Network segmentation: manufacturing OT network isolated from SAP IT network via DMZ
  • Privileged Access Management (CyberArk) for SAP Basis and AWS admin accounts
  • SIEM integration (Splunk) for all SAP security logs

Step 5, Vendor Security Management (Months 1-36):

• All 4 vendors underwent security assessments before contract signing (A.5.9)
• Security clauses in all contracts: right to audit, incident notification (24 hours), data residency (India only), breach liability ( cap)
• Quarterly vendor security reviews with evidence of patch management, access reviews, and training
• Implementation and infrastructure partners required to maintain ISO 27001 certification and provide SOC 2 Type II reports

Step 6, Secure Development and Configuration (Months 4-24):

• SAP security baseline: 400+ configuration parameters hardened per CIS benchmarks
• Custom ABAP code: SAST using CodeProfiler; 67 security findings remediated
• Custom mobile app for plant supervisors: OWASP MASVS Level 2 compliance; penetration testing by an independent specialist
• Integration middleware: API security gateway (Apigee) with OAuth 2.0, rate limiting, and request signing

Step 7, Data Migration Security (Months 20-28):

• 15 TB of legacy data migrated using a secure data pipeline
• Data classification: Public (5%), Internal (55%), Confidential (35%), Secret (5%, chemical formulas)
• Secret data encrypted with customer-managed keys before leaving legacy systems
• Data migration validated with checksums at every stage; 0.001% error rate
• Legacy system data wiped using NIST 800-88 Clear/Purge methods after migration verification

Step 8, Security Testing (Months 24-32):

• SAST/DAST on all custom code (continuous)
• Penetration testing (3 rounds):
  • Round 1 (Month 24): Infrastructure and SAP basis, 23 findings, all remediated
  • Round 2 (Month 28): Application layer, 18 findings, all remediated
  • Round 3 (Month 32): End-to-end system, 9 findings, all remediated
• Red team exercise (Month 30): Simulated APT targeting chemical formula data, 2 attack paths identified, both closed
• Performance and security testing for manufacturing continuity: 99.99% uptime verified under load

Step 9, Security Gates (Throughout): 8 major gates across 3 years:

• Gate 1 (Design): Architecture and threat model, passed after 2 revisions
• Gate 2 (Vendor Onboarding): All vendor assessments complete, passed
• Gate 3 (Build, Core): SAP configuration hardened; SAST clean, passed after 1 revision
• Gate 4 (Integration): API security verified; data flows validated, passed
• Gate 5 (Data Migration): Migration integrity verified; legacy data destroyed, passed
• Gate 6 (Test, UAT): Pen test round 2 passed; no Critical/High open, passed after remediation
• Gate 7 (Go-Live Readiness): All acceptance criteria met; ops trained; IR ready, passed
• Gate 8 (Closure): Documentation complete; lessons learned; handover signed, passed

Step 10, Go-Live and Handover (Month 34-36):

• Phased go-live: Plant 1 (Month 34), Plants 2-4 (Month 35), Plants 5-8 + International (Month 36)
• Each phase had a 2-week security monitoring period before next phase
• Operations team received: 4,200 pages of security documentation, 47 runbooks, 12 incident response playbooks, Splunk dashboard templates
• 40-hour security training program for 45 SAP administrators and security staff

Outcome:

• Project Unity went live on schedule with zero security incidents during rollout
• ISO 27001 surveillance audit (Month 38): zero non-conformities in A.5.8, A.5.9, A.8.25, A.8.29
• SEBI compliance review passed without observations
• Post-go-live 12-month security incident count: 3 (all Low severity, detected and contained within 2 hours)
• Total security spend: (10% of project budget)
• Estimated cost of a chemical formula breach: + Crore (competitive advantage, regulatory penalties, customer trust), risk effectively mitigated
• The Project Security Framework was adopted as corporate standard for all subsequent projects

Key Lessons:

1. Large enterprise projects require a dedicated Security Workstream, not just a part-time PSO
2. Multi-year projects benefit from multiple rounds of penetration testing, not just one pre-go-live test
3. Vendor security management must be enforced contractually and verified quarterly
4. Phased go-live with security monitoring periods reduces risk and allows course correction
5. The cost of complete project security (10% of budget) is negligible compared to the cost of a breach in a critical infrastructure sector

Multi-Framework Mapping

ISO 27001:2022 ↔ SOC 2 ↔ PCI DSS ↔ NIST 800-53 ↔ CIS Controls ↔ COBIT 2019 ↔ GDPR/DPDP

Detailed Control Mapping

ISO 27001 A.5.8 → NIST 800-53 Rev 5:

ISO 27001 A.5.8 → CIS Controls v8:

ISO 27001 A.5.8 → COBIT 2019:

Regulatory and Industry Context

India-Specific Regulations

International Regulations

Industry-Specific Context

Roles and Responsibilities (RACI)

Project Security Activities RACI Matrix

Legend:

• R = Responsible (does the work)
• A = Accountable (ultimately answerable; approves)
• C = Consulted (provides input)
• I = Informed (kept updated)

Role Descriptions

Documentation and Evidence Requirements

Suggested Evidence by Phase

Evidence Retention Requirements

Evidence Organization

For audit readiness, organize evidence in a structured repository:

/Project-Security-Evidence/
  /YYYY/
    /[Project-Code]/
      /01-Initiation/
        - Security-Classification.pdf
        - Risk-Assessment.pdf
        - SRS.pdf
        - PSO-Assignment.pdf
      /02-Planning/
        - SRTM.xlsx
        - Security-Plan.pdf
      /03-Design/
        - Threat-Model.pdf
        - Security-Architecture.pdf
        - Architecture-Review-Minutes.pdf
      /04-Build/
        - SAST-Reports/
        - SCA-Reports/
        - Secrets-Scan-Reports/
        - Code-Review-Records/
      /05-Test/
        - DAST-Reports/
        - Pen-Test-Report.pdf
        - Security-Test-Report.pdf
      /06-Deployment/
        - Deployment-Checklist.pdf
        - Security-Acceptance-Signoff.pdf
      /07-Closure/
        - Security-Documentation.pdf
        - Handover-Signoff.pdf
        - Lessons-Learned.pdf
        - Updated-IR-Plan.pdf

Continuous Improvement

The Continuous Improvement Cycle for Project Security

Plan → Do → Check → Act

Plan:

• Review project security metrics quarterly
• Identify trends in security gate failures, vulnerability types, and post-go-live incidents
• Update project security policy, templates, and training based on findings
• Benchmark against industry standards and competitor practices

Do:

• Deploy updated templates and procedures to new projects
• Deliver refresher training to project managers and PSOs
• Implement new security tools or automation
• Run pilot projects with improved practices

Check:

• Measure KPIs before and after changes
• Conduct internal audits of project security implementation
• Gather feedback from project teams on usability of security processes
• Review post-go-live incident data for security root causes

Act:

• Standardize improvements that prove effective
• Eliminate or redesign processes that cause friction without adding value
• Update the organization's knowledge base and playbooks
• Report improvements to management and incorporate into governance

Project Security Maturity Model

Improvement Triggers and Actions

FAQ

General Questions

Q1: Does A.5.8 apply to non-IT projects? A: Yes. The standard explicitly states "regardless of the type of project." This includes HR projects, marketing campaigns, office renovations, M&A activities, and research projects. Any project that introduces change to the organization or handles information must address security.

Q2: What is the difference between A.5.8 and A.8.25? A: A.5.8 is the project management control, it ensures security is addressed at the project level (planning, governance, risk, resources). A.8.25 is the technical development control, it ensures security practices are embedded in the software development lifecycle (requirements, design, code, test). For software projects, you need both. A.5.8 governs the project manager; A.8.25 governs the development team.

Q3: Do we need a full-time Project Security Officer for every project? A: No. For Critical projects, a dedicated or heavily supported PSO is recommended. For High projects, a part-time PSO (20-30% allocation) is sufficient. For Medium projects, a trained project manager can act as PSO with security team support. For Low projects, the standard PM process with a security checklist is adequate. The key is that security accountability is named, not that it is a separate headcount.

Q4: How do we handle security in Agile/Scrum projects where requirements change frequently? A: Integrate security into the sprint rhythm: Sprint 0 for threat modeling and security requirements; every sprint for security review in retrospectives; automated SAST/DAST in CI/CD; release planning for security risk review; pre-release for security acceptance. Security in Agile is about continuous attention, not phase gates.

Q5: What percentage of project budget should be allocated to security? A: Industry benchmarks suggest 8-15% for Critical projects, 5-10% for High, 3-5% for Medium, and 1-2% for Low. However, the percentage varies by industry. Fintech and healthcare projects often spend 15-20% on security. A manufacturing IT refresh might spend 3-5%. The key is that security is explicitly budgeted, not treated as a contingency.

Q6: Can we use the same risk assessment for multiple projects? A: Not usually. ISO 27002 says security risks should be assessed and treated as part of each project's risks, and ISO 27001 clause 8.2 requires risk assessment when significant changes are proposed. Each project introduces unique risks based on its scope, technology, data, and third parties. While organizational risks provide context, each project must have its own risk assessment. Using a generic risk assessment is a common audit failure.

Implementation Questions

Q7: We have no formal PMO. Can we still comply with A.5.8? A: Yes. A.5.8 does not require a PMO. It requires that security be addressed in project management. For organizations without a PMO, define a lightweight process: classify the project, assign a PSO, conduct a risk assessment, define security requirements, review at milestones, and sign off before go-live. Use templates to make this repeatable.

Q8: How do we enforce project security when business teams bypass IT for SaaS projects? A: This is shadow IT and a major security risk. Implement a project intake process where all projects, including SaaS procurement, must register with IT/Security. Use a lightweight security assessment for SaaS projects (vendor SOC 2 review, data residency check, DPA requirement). Make it easy to comply, not bureaucratic, but ensure no project goes live without security review.

Q9: What is the minimum viable project security process for a 20-person startup? A: For startups, keep it simple but documented: (1) Security checklist for every project, (2) One person named as security lead (founder/CTO), (3) Risk assessment for any project handling customer data, (4) Security review before go-live, (5) Basic documentation. As you grow, add templates, automated testing, and dedicated PSOs.

Q10: Should security gates be automated or manual? A: Start with manual gates for the first 6-12 months. Once the process is mature, automate what you can: SAST/DAST pass/fail in CI/CD, vulnerability threshold checks, compliance checklist completion in ServiceNow/Jira. Keep human judgment for architecture reviews, threat modeling, and final go-live decisions. Automation should support, not replace, security expertise.

Q11: How do we integrate A.5.8 with our existing SDLC (Waterfall, Agile, DevOps)? A: Map your existing phases to the security activities in the implementation guidance above. For Waterfall, add security gates at the end of each phase. For Agile, add security to Sprint 0 and every sprint retrospective. For DevOps, embed security tools in the CI/CD pipeline and use automated gates. The activities are universal; the timing adapts to your methodology.

Q12: What is the difference between a security gate and a security review? A: A security review is an activity where security is evaluated. A security gate is a decision point where the project cannot proceed until security criteria are met. All gates include reviews, but not all reviews are gates. For example, a monthly security review is informational; a go-live security gate is a hard stop.

Audit and Compliance Questions

Q13: What evidence do auditors typically ask for A.5.8? A: Auditors will sample 3-5 projects (active and closed) and ask for: project classification, risk assessment, security requirements, threat model (if applicable), SAST/DAST reports, pen test report, security acceptance sign-off, and lessons learned. They will also interview the PM and PSO to verify the process is understood and followed.

Q14: Can a project go live with known security vulnerabilities? A: Only if the residual risk is formally accepted by the risk owner (usually the project sponsor or business owner), with the CISO's advice; top management for the highest risks. The acceptance must document the vulnerability, the compensating controls, the risk impact, and the remediation timeline. "We'll fix it later" without formal acceptance is an audit failure and a breach waiting to happen.

Q15: How does A.5.8 relate to DPDP Act 2023 compliance? A: The DPDP Act requires "reasonable security safeguards" (Section 8(5)) and additional safeguards for children's data (Section 9). A.5.8 ensures that these safeguards are designed into projects from the start. Projects handling personal data must include DPDP requirements in their security requirements, conduct a data protection impact assessment (DPIA) for high-risk processing where applicable, and verify compliance before go-live.

Q16: What happens if we fail a security gate? A: The project cannot proceed past the gate until the failure is addressed. The PSO documents the failure, the remediation plan, and the timeline. The project manager reschedules downstream activities. For repeated failures, escalate to the CISO and PMO Director for process review. Failing a gate is not a punishment; it is a mechanism to prevent vulnerable systems from reaching production.

Q17: Do we need penetration testing for every project? A: No. Penetration testing is required for Critical projects and recommended for High projects. Medium projects can use DAST. Low projects may rely on standard hardening and vulnerability scanning. However, if a project handles sensitive data or has internet-facing components, consider pen testing regardless of classification. The goal is risk-appropriate testing, not blanket testing.

Q18: How do we manage project security for outsourced development? A: Apply A.5.19 (Supplier Relationships) alongside A.5.8. Include security requirements in the RFP and contract. Require the vendor to follow your security standards or equivalent (e.g., their ISO 27001). Conduct vendor security assessments. Include security acceptance criteria in deliverables. Require the vendor to provide SAST/DAST reports and pen test results. Include right-to-audit clauses.

Q19: How long should we retain project security evidence? A: We recommend project duration + 7 years. This covers ISO 27001 surveillance audits (3 years), DPDP Act requirements, RBI/SEBI retention rules, and potential legal proceedings. For systems that remain operational long after the project closes, maintain security documentation as long as the system exists.

Q20: Can we use open-source tools for project security? A: Yes. Many excellent open-source tools exist: OWASP ZAP (DAST), SonarQube Community Edition (SAST), OWASP Dependency-Check (SCA), GitLeaks (secrets), OWASP Threat Dragon (threat modeling). Open-source tools are sufficient for compliance if they are properly configured, maintained, and their output is documented. However, enterprise editions often provide better reporting, integration, and support, which may be worth the investment for larger organizations.

References and Further Reading

ISO Standards

1. ISO/IEC 27001:2022: Information security, cybersecurity and privacy protection, Information security management systems, Requirements
2. ISO/IEC 27002:2022: Information security, cybersecurity and privacy protection, Information security controls, Clause 5.8
3. ISO/IEC 27003:2017: Information security management system, Guidance
4. ISO/IEC 27005:2022: Information security risk management
5. ISO/IEC 27007:2020: Guidelines for information security management systems auditing
6. ISO/IEC 27034:2021: Application security, Multiple parts

Indian Regulations and Guidelines

7. Digital Personal Data Protection Act 2023: Government of India, Ministry of Electronics and Information Technology
8. Information Technology Act 2000 (as amended in 2008): Government of India
9. CERT-In Directions 2022: Indian Computer Emergency Response Team, Ministry of Electronics and Information Technology
10. RBI Master Direction on Digital Payment Security Controls: Reserve Bank of India, 2021
11. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024: consolidated and replaced the earlier frameworks for stock exchanges, depositories, clearing corporations and intermediaries
12. SEBI CSCRF (Cybersecurity and Cyber Resilience Framework for SEBI Regulated Entities, 20 August 2024): replaced the earlier cyber security and cyber resilience circulars
13. IRDAI Information and Cyber Security Guidelines: Insurance Regulatory and Development Authority of India, 2023
14. MeitY Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021
15. National Cyber Security Policy 2013: Ministry of Electronics and Information Technology

International Frameworks

16. NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations
17. NIST Cybersecurity Framework (CSF) 2.0: National Institute of Standards and Technology, 2024
18. CIS Controls v8: Center for Internet Security
19. COBIT 2019: Control Objectives for Information and Related Technologies, ISACA
20. PCI DSS v4.0.1: Payment Card Industry Data Security Standard

Secure Development and Project Security

21. OWASP Software Assurance Maturity Model (SAMM): Open Web Application Security Project
22. OWASP Application Security Verification Standard (ASVS) 4.0: Open Web Application Security Project
23. OWASP Top 10:2025: Open Web Application Security Project (2021 edition still widely referenced)
24. Microsoft Security Development Lifecycle (SDL): Microsoft Corporation
25. BSIMM14 (Building Security In Maturity Model): Synopsys
26. SAFECode Fundamentals of Software Security: Software Assurance Forum for Excellence in Code

Threat Modeling and Architecture

27. Adam Shostack, Threat Modeling: Designing for Security: Wiley, 2014
28. Microsoft Threat Modeling Tool Documentation: learn.microsoft.com
29. OWASP Threat Dragon: threatdragon.org

Industry Reports and Statistics

30. Verizon Data Breach Investigations Report (DBIR) 2024: Verizon Business
31. IBM Cost of a Data Breach Report 2024: IBM Security
32. CERT-In Annual Report 2023-2024: Indian Computer Emergency Response Team

Project Management Standards

33. PMBOK Guide 7th Edition: Project Management Institute
34. PRINCE2 7: AXELOS / PeopleCert
35. SAFe 6.0: Scaled Agile Framework