Control Definition
The organization must build information security into its project management practices so security risks are identified and addressed as part of every project, whatever the project's type or subject.
Control Objective
To ensure information security is considered throughout the project lifecycle—from initiation through delivery—by integrating security requirements, risk assessments, and controls into project planning, execution, and handover processes.
What This Really Means
Information security in project management means making security an integral part of every project from the start, not something bolted on at the end. Whether you are developing new software, implementing cloud services, opening new offices, acquiring companies, or launching products, security requirements must be identified during planning, security controls must be built during execution, and security verification must happen before go-live.
Think of it like building safety in construction projects: architects incorporate fire exits and emergency lighting in initial designs, contractors install them during construction, and inspectors verify compliance before building occupancy. Similarly, IT and business projects must incorporate security from day one: identify security requirements in project charter, conduct risk assessment during planning, implement security controls during development, test security before launch, and document security configurations during handover.
This control requires you to establish project security standards defining when and how security is integrated, include security in project governance (security representation in steering committees, security gates in approval processes), allocate budget and resources for security tasks, track security requirements alongside functional requirements, and ensure projects do not go live with unresolved high-severity security issues. The goal is preventing security debt and vulnerabilities introduced by projects rushing to launch without security considerations.
Why It Matters
Most security vulnerabilities and incidents trace back to projects that launched without adequate security: applications deployed with default credentials, cloud services configured with public access, systems integrated without encryption, or mergers completed without security due diligence. Integrating security into projects prevents these failures.
Without security in project management, organizations face:
- •Security Vulnerabilities in New Systems – Projects launch applications with SQL injection, hardcoded credentials, or missing authentication because security was never part of requirements or testing
- •Compliance Violations from Day One – New systems processing personal data without DPDPA compliance, PCI DSS scope expansion without proper segmentation, or cloud deployments violating data residency requirements
- •Technical Debt and Remediation Costs – Fixing security issues post-launch routinely costs an order of magnitude more than building security in; retrofitting encryption, access controls, or audit logging after go-live is expensive and disruptive
- •Project Delays from Late Security Discovery – Security team discovers project in production without their knowledge, forces rollback, and causes business disruption; better to catch in planning phase
- •Incompatible Security Architectures – Projects make technology choices (databases, cloud services, authentication methods) incompatible with corporate security standards, creating long-term management nightmares
Indian organizations often treat security as "IT's problem after launch" rather than integral project consideration. This creates security crises when auditors discover non-compliant systems or breaches occur in newly launched applications.
Implementation Guidance
Define Security Requirements for Project Types
Create security requirement templates by project category: for application development projects—secure coding standards, authentication/authorization requirements, data encryption, security testing, vulnerability management; for infrastructure projects—network segmentation, access controls, logging, hardening standards; for cloud adoption—vendor security assessment, configuration baselines, data classification, backup/DR; for M&A—security due diligence, integration security architecture, identity consolidation. Document mandatory vs. recommended requirements. Publish in project management methodology so project managers know what security deliverables are expected.
Establish Security Gates in Project Approval Process
Integrate security checkpoints at project milestones: (1) Project Initiation—security team reviews project charter, identifies security scope, assigns security representative to project team; (2) Planning Phase—security risk assessment completed, security requirements documented, security budget allocated; (3) Design Phase—security architecture review, threat modeling for applications, security controls design approved; (4) Pre-Production—security testing completed (penetration testing, vulnerability scans, code review), high/critical findings remediated; (5) Go-Live Approval—security sign-off required from CISO or security team before production deployment. Projects cannot proceed to next phase without passing security gate.
Assign Security Roles and Responsibilities in Projects
Define who handles security in projects: appoint Security Champion (from security team) assigned to each major project providing guidance and reviewing deliverables, designate Project Security Lead (from project team) responsible for tracking security requirements and coordinating with security champion, include security team in project steering committee for visibility into decisions, and assign Data Owner to classify project data and approve access. For smaller projects, lightweight involvement (security questionnaire review); for high-risk projects (public-facing apps, customer data processing), dedicated security engineer embedded in project team.
Include Security Tasks in Project Plans and Budgets
Security cannot be unfunded mandate: allocate project budget for security activities (security tool licenses, penetration testing, security consulting, secure development training), schedule security tasks in project timeline with realistic durations (threat modeling: 2-3 days, penetration test: 1-2 weeks including remediation, security architecture review: 3-5 days), and assign resources (security engineer time, developer time for security testing). Track security tasks in project management tool (Jira, Microsoft Project, Asana) alongside functional tasks. Security delays are project delays—factor into critical path.
Conduct Security Risk Assessment During Project Planning
For every project, perform security risk assessment: identify assets introduced or affected (new application, data stores, integrations, third-party services), identify threats (data breach, unauthorized access, service disruption, compliance violations), assess vulnerabilities (coding flaws, misconfigurations, weak authentication), evaluate risks (likelihood × impact), and define mitigating controls with ownership and deadlines. Document in project risk register. Escalate high-severity risks to project steering committee and executive management. Re-assess risks when project scope changes significantly.
Require Security Testing Before Production Deployment
Mandatory security validation before go-live: for custom applications—Static Application Security Testing (SAST) during development, Dynamic Application Security Testing (DAST) in test environment, penetration testing in staging, code review for authentication/authorization logic; for infrastructure—vulnerability scanning of servers/network devices, configuration compliance checks against security baselines (CIS Benchmarks), access control testing; for cloud—cloud security posture assessment (CSPM), misconfiguration detection, IAM policy review. Document findings, require remediation of high/critical vulnerabilities before production deployment. Medium/low findings acceptable with documented risk acceptance.
Document Security Configuration and Handover to Operations
Before project closes, document security implementation for ongoing operations: create security runbook (access control procedures, security monitoring requirements, incident response contacts, backup/recovery procedures, patch management process), update configuration management database (CMDB) with security controls implemented, provide security training to operations team responsible for maintaining system, document residual risks and required ongoing security activities (quarterly access reviews, annual penetration testing), and obtain formal sign-off from security and operations teams. Security handover prevents knowledge loss when project team disbands.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.8:
Documentation
- Project management methodology document incorporating security requirements
- Security requirement templates for different project types
- Project approval/gate process showing security checkpoints
- Sample project security risk assessments
- Project security testing reports and remediation evidence
Interviews
- Project managers about how security is integrated into their projects
- Security team about their involvement in project governance
- Recent project teams about security requirements they implemented
Observations
- Review of active projects showing security tasks in project plans
- Evidence of security gate approvals in project documentation
- Verification that security representatives are included in project steering committees
- Demonstration of security testing conducted before production deployment
Practitioner Insights
A pattern I keep seeing in fintech and startup audits: customer-facing apps pushed to production without any security testing because of an investor or launch deadline. The findings are predictable every time - hardcoded API keys, no input validation, session tokens that never expire. When that surfaces during audit, it forces emergency remediation or shutdown and a customer trust crisis far costlier than the gate would have been. A mandatory security gate requiring penetration testing before production prevents the whole disaster. Never skip security gates for business pressure.
Common mistake: security team learns about projects after they launch. I recommend security representative in every project steering committee and mandatory project registration process where any project spending over certain threshold (say ₹5 lakh or involving customer data) must notify security team during initiation. Allows security to engage early when changes are cheap, not late when retrofitting security is expensive and disruptive.
Common Challenges & Solutions
Challenge
Project managers complain security requirements delay projects and increase costs.
Solution
Shift security left: engage security during planning, not testing. When security is involved early, requirements are built into design rather than forcing late changes. Demonstrate cost of fixing security post-launch: critical vulnerability discovered in production requires emergency patch, rollback, customer notification, potential breach investigation—far more expensive than building security correctly. Track metrics showing projects with early security engagement have fewer production issues and lower total cost. Educate project managers that security prevents costly rework.
Challenge
Security team lacks resources to participate in every project—bottleneck slowing all initiatives.
Solution
Risk-based approach: classify projects by security risk (public-facing apps, customer PII processing = high; internal tools, no sensitive data = low). High-risk projects get dedicated security engineer, medium-risk get security checkpoint reviews, low-risk complete security questionnaire self-assessment. Automate where possible: security scanning integrated into CI/CD pipelines, infrastructure-as-code with security policies enforced via policy-as-code (OPA, Sentinel), cloud configuration monitoring automated (CSPM tools). Train project teams in basic security so they handle routine tasks; security team focuses on high-risk areas.
Challenge
Developers lack security knowledge and build insecure applications despite security requirements.
Solution
Provide security enablement, not just requirements: offer secure coding training (OWASP Top 10, common vulnerabilities), publish secure development guidelines with code examples (how to implement authentication, parameterized queries, encryption), provide pre-approved security libraries and frameworks (avoid everyone building custom crypto), create application security champions program (train one developer per team in security), and offer security office hours where developers can ask questions. Combine with automated security scanning giving developers immediate feedback in IDE and CI/CD pipeline.
Challenge
Security testing (penetration testing) scheduled at end of project leaves no time for remediation before deadline.
Solution
Mandate security testing timeline: for 6-month project, penetration test scheduled at month 5 (not month 6) allowing 4 weeks for remediation before go-live. For critical projects, conduct security testing in phases: architecture review during design, code review during development sprint reviews, vulnerability scanning continuously in CI/CD, penetration test 4-6 weeks before launch. Buffer time in project schedule for security finding remediation. Make "all high/critical security findings resolved" explicit go-live criteria that cannot be waived.
Challenge
Acquisitions and mergers happen rapidly with no time for security due diligence or integration planning.
Solution
Create M&A security playbook executed in parallel with financial/legal due diligence: security team participates in due diligence phase reviewing acquired company's security posture (controls, incidents, vulnerabilities, compliance status), assesses integration risks (incompatible authentication systems, unencrypted data transfers, compliance gaps), defines Day 1 requirements (network segmentation between companies, access restrictions, monitoring), and creates integration security roadmap. Escalate high-risk findings (active breaches, critical vulnerabilities, compliance violations) to M&A decision committee—may affect deal valuation or terms. Security integration is multi-month process; do not assume immediate full integration.
