A.5.8 Information Security in Project Management

Here's what I learned from fifteen years of auditing project security implementations: the organizations that succeed at Control 5.8 don't treat it as a security control at all. They treat it as project hygiene. The ones that fail? They bolt security onto their existing project methodology like an afterthought, creating elaborate documentation that no one follows and checkpoint meetings that everyone endures.

Last month, I audited a mid-sized manufacturing firm where the project manager pulled out a beautifully formatted "Security Requirements Template" during our interview. It had risk matrices, compliance checkboxes, and all the right terminology. But when I asked to see it completed for their current ERP implementation—a project that would handle every piece of sensitive data the company possessed—he admitted it had never actually been used. "We keep meaning to," he said, "but the timelines are always so tight."

That's the fundamental misunderstanding of Control 5.8. Information security in project management isn't about creating new bureaucracy; it's about recognizing that projects are where your future vulnerabilities get designed and built. Every architectural decision, every vendor selection, every integration point becomes part of your attack surface for the next decade. Getting security right during projects isn't overhead—it's the most cost-effective security investment you can make.

Understanding Control 5.8: Beyond the Checkbox

Control 5.8 requires that information security should be integrated into project management. The ISO 27002:2022 guidance is more specific: security risks must be assessed and treated at early stages and periodically throughout the project lifecycle, security requirements must be addressed early, and progress on security risk treatment must be reviewed and tested.

This connects directly to your broader ISMS framework. Your risk assessment process (Clause 6.1.2) should feed into project risk evaluation. Your documented information requirements (Clause 7.5) should include templates and procedures for project security activities. Your operational planning and control (Clause 8.1) ensures these procedures actually get followed rather than gathering digital dust.

The standard also cross-references several related controls that frequently surface in project contexts: Control 8.26 for application security requirements, Control 5.32 for intellectual property rights, and various access management controls that need to be considered during system design phases.

What the Auditor Looks For

When I audit Control 5.8, I'm looking for evidence that security considerations systematically influence project decisions, not just document them. Specifically:

• Integration evidence: Project methodologies that include mandatory security touchpoints, not optional ones
• Early involvement: Security requirements identified during project initiation or requirements phases, not just final reviews
• Decision influence: Examples where security input changed project scope, vendor selection, or architectural decisions
• Proportionate response: Different levels of security involvement based on project risk, not one-size-fits-all approaches
• Competency evidence: Qualified personnel providing security input, not just project managers with a security checklist

The Project Security Lifecycle: Getting It Right

Project Initiation and Security Triage

The most effective organizations I've audited use a project security triage process during initiation. Not every project needs the same level of security scrutiny—updating your office WiFi password policy doesn't require the same rigor as migrating customer databases to a new cloud provider.

Create a simple but mandatory classification mechanism. The best implementations I've seen use a brief questionnaire completed during project approval: Does the project involve personal data? Create new external interfaces? Involve third parties accessing your systems? Change how sensitive information is processed or stored? Based on responses, projects get classified into security involvement categories.

Here's the crucial point: this triage must be mandatory before project approval, not optional guidance. If you can't get budget approval without finance sign-off, you shouldn't get it without security classification either.

Requirements and Design: Where Security Gets Built In

For projects flagged as security-relevant, this phase determines whether you'll spend the next five years living with elegant solutions to the wrong problems. Security requirements must be identified alongside functional requirements, which means someone with actual security expertise needs to participate in early requirements workshops.

I emphasize "expertise" deliberately. I've seen organizations assign a project team member as "security coordinator" without providing any security training or authority. This person becomes a message-passer between the project team and security team, losing crucial context in translation and lacking the knowledge to push back on poor decisions.

The ISO 27002 guidance lists specific areas to consider when determining security requirements: information classification needs, protection requirements for confidentiality/integrity/availability, authentication requirements, access provisioning processes, compliance requirements, and integration with existing security controls like monitoring systems.

Implementation and Testing: Proving It Works

Security requirements are worthless if they're not implemented correctly or at all. This is where many organizations stumble—they document beautiful security architectures but never verify that the actual implementation matches the design.

Build security validation into your testing phases. This doesn't mean a final penetration test (though that has its place); it means ongoing verification that security controls are being implemented as specified. For software development projects, this includes security code reviews, dependency scanning, and configuration validation. For infrastructure projects, it includes access control testing, encryption verification, and monitoring integration.

Common Implementation Pitfalls

The most frequent mistake I encounter is treating security project involvement as a compliance exercise rather than a business enabler. Organizations create elaborate security review processes that project managers circumvent whenever possible because they add time without obvious value.

A financial services company I audited exemplified this problem perfectly. They had implemented comprehensive security gates at every project phase, complete with detailed documentation requirements and formal review meetings. The security team was proud of their thorough process. But when I interviewed project managers privately, I learned they had developed an entire shadow process for getting projects approved without triggering security reviews. They classified obvious security-relevant projects as "maintenance activities" or "infrastructure updates" to avoid the bureaucracy.

The security team was diligently reviewing about 30% of the projects that should have been in scope, blissfully unaware that the majority were bypassing their process entirely.

Making It Practical: Implementation Strategies

Successful Control 5.8 implementation requires embedding security into existing project workflows rather than creating parallel processes. The most effective approach I've observed involves modifying existing project stage gates to include security criteria rather than adding new gates.

For example, if your organization requires business case approval before project initiation, add security classification to the business case template. If you require technical architecture approval before development begins, include security architecture review in that same approval process. This integration prevents security from becoming an additional hurdle that project teams try to circumvent.

Consider also the competency requirements. You need people who understand both project management and security. This might mean training your security staff on project methodologies, or training project managers on security fundamentals. The investment pays dividends in reduced friction and better outcomes.

Agile and DevOps Considerations

Traditional waterfall security gates don't work well with agile methodologies or DevOps practices. Instead of big design reviews, implement continuous security validation. This might include automated security testing in CI/CD pipelines, security user stories in backlogs, and security considerations in sprint reviews.

The principle remains the same—integrate security into existing processes rather than adding parallel ones—but the implementation looks different. Security becomes part of "done" criteria rather than a separate approval step.

Cross-Standard Connections

Control 5.8 frequently intersects with other ISO 27000 family standards. If you handle personal data, ISO 27018 provides additional guidance on privacy considerations in projects. For cloud projects, ISO 27017 offers cloud-specific security guidance that should inform your project requirements. Organizations working with suppliers should consider ISO 27036 requirements for supplier security in project contexts.

These cross-references aren't academic—auditors often examine how well you've integrated these related requirements into your project security approach. A project involving cloud migration, personal data processing, and third-party suppliers needs to address all relevant standards coherently, not treat them as separate compliance exercises.

Measuring Success

How do you know if your Control 5.8 implementation is working? Look for leading indicators of success: security requirements identified early in projects, security input influencing architectural decisions, and security issues caught during development rather than after deployment.

Lagging indicators matter too: reduced security incidents in newly deployed systems, faster security reviews for new systems (because security was considered during design), and positive feedback from project managers about security team involvement rather than complaints about delays and bureaucracy.

The ultimate measure is whether your organization's attack surface is shrinking over time despite deploying new systems and capabilities. That's what effective security project integration delivers—controlled expansion of capabilities without proportional expansion of risk.

Ready to strengthen your project security integration? Join our ISO 27001 Info Hub for practical implementation resources, or contact us for specialized consultation on embedding security into your project methodologies.

Need personalized guidance? Reach our team at ix@isegrim-x.com.

Related Articles

• Annex A.5.1 through A.5.4 — Information Security Policies and Roles
• A.5.5 and A.5.6 — Contact with Authorities and Special Interest Groups
• A.5.7 Threat Intelligence — What Auditors Actually Expect
• A.6.1 through A.6.3 — Screening Employment Terms and Awareness
• A.7.1 through A.7.4 — Physical Perimeters Entry and Securing Facilities