Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Organisational Control

A.5.8 — Information Security in Project Management

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.8 ISO 27001ISO 27002BSI ISMS.1

A development project delivers a new customer portal on time and under budget. Two weeks after launch, a penetration test reveals an authentication bypass that exposes customer data. The fix requires a six-week redesign of the authentication module. A.5.8 prevents this cycle by requiring that information security is integrated into project management from the outset — across all project types.

Security requirements identified early are cheaper to implement and more effective than those bolted on after the fact. This control ensures that every project considers information security risks throughout its lifecycle.

What does the standard require?

  • Integrate security into the project methodology. Whether the organisation uses waterfall, agile or hybrid approaches, information security must be a defined element in the project framework.
  • Assess security risks at project initiation. Every project must evaluate which information security risks it introduces or affects. This assessment informs the security requirements for the project.
  • Define security requirements for deliverables. Projects that produce systems, applications, processes or services must specify security requirements alongside functional requirements.
  • Review security at project milestones. Security should be verified at defined checkpoints — at design, during implementation, before testing and prior to launch.
  • Apply to all project types. The control covers IT projects, organisational change projects, facility projects and any other initiative that affects information assets.

In practice

Add security gates to the project framework. Define mandatory security checkpoints in the organisation’s project methodology. Common gates: security risk assessment at initiation, architecture security review at design, security testing before release, and a security sign-off before go-live.

Involve the security team early. The Information Security Officer or a designated security consultant should be part of the project kickoff. Early involvement allows security requirements to influence the design rather than constrain the rollout.

Scale the effort to the risk. A low-risk internal process improvement may need only a brief security checklist. A project that introduces a new SaaS platform handling personal data requires a thorough risk assessment, a data protection impact assessment and a supplier security review. Define criteria for categorising project risk levels.

Document security decisions. Record which security requirements were identified, how they were addressed and what residual risks were accepted. This documentation is both a project governance instrument and audit evidence.

Typical audit evidence

Auditors typically expect the following evidence for A.5.8:

  • Project security risk assessments — documented evaluation of security risks per project
  • Security requirements specifications — showing that security was included in project requirements
  • Security gate records — evidence that security checkpoints were executed at defined milestones
  • Security test results — penetration tests, code reviews or vulnerability scans conducted during the project
  • Project methodology documentation — showing where security is embedded in the standard project framework

KPI

% of projects where information security requirements were assessed and documented

This KPI measures how consistently the organisation applies security to its projects. Target: 100%. Track both the total number of active projects and the number with documented security assessments. Projects without an assessment represent unmanaged risk.

Supplementary KPIs:

  • Percentage of projects that passed all defined security gates
  • Number of security findings identified during project reviews (trending downward indicates improving maturity)
  • Average cost of security-related rework per project

BSI IT-Grundschutz

A.5.8 maps to the following BSI requirement:

  • ISMS.1.A9 (Integration of information security into organisational processes and projects) — requires that information security is considered in all projects from inception to completion, including risk assessment, requirement definition and verification.

A.5.8 connects security governance to project delivery:

Sources

Frequently asked questions

Does every project need a security risk assessment?

Yes. ISO 27002 states that information security shall be integrated into project management regardless of the type of project. The depth of the assessment scales with the project's risk profile -- a minor internal tool may need a lightweight checklist, while a customer-facing system requires a full risk assessment.

At which project phase should security be addressed?

From the very beginning. Security requirements should be identified during project initiation and validated at every major milestone. Retrofitting security into a completed project is significantly more expensive and less effective than building it in from the start.

Who is responsible for project-level security?

The project manager is responsible for ensuring that security requirements are addressed. The Information Security Officer or IT Security Officer provides guidance and reviews. Security is a project constraint alongside scope, budget and timeline.