Annex A 5.8: Information Security in Project Management

Annex a 5.8: information security in project management requirement means you must embed security activities into your project lifecycle so every project identifies security needs, applies proportionate controls, and produces audit-ready evidence. Operationalize it by adding security gates to project intake, design, build, and release, with clear ownership and defined artifacts. ¹

Key takeaways:

• Put security requirements, risk assessment, and control selection into your project methodology, not a separate “security review” after the fact. ¹
• Define trigger events (new project, major change, new third party, new data type) and required evidence bundles per gate. ¹
• Auditors look for repeatability: named owners, consistent gates, approvals, and retained records tied to actual projects. ¹

Annex A 5.8 is a practical control: it asks whether your organization treats projects as a predictable source of security risk and manages that risk systematically through the project management process. A CCO, GRC lead, or security governance owner typically “passes” this control when they can show three things: (1) security is a required workstream in every relevant project, (2) teams follow a consistent set of security steps at defined points, and (3) evidence exists for real projects, not just policy statements. ¹

This requirement matters because projects are where new systems, new data flows, new third parties, and major changes enter production. If security is bolted on late, teams miss threat modeling, logging requirements, access design, data retention decisions, or contract clauses until remediation is expensive and timelines are already committed. Annex A 5.8 pushes you to make security “part of delivery” by building lightweight governance into the delivery pipeline. ¹

For operators, the fastest path is to define a small set of security gates aligned to how your teams actually work (Agile, Waterfall, DevOps), then standardize templates and evidence retention. Daydream-style control cards and evidence bundles help you make the control auditable without turning project management into paperwork. ¹

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A 5.8 (Information Security in Project Management). ¹

Provided excerpt (summary-level): “ISO/IEC 27001:2022 Annex A control 5.8 implementation expectation (Information Security in Project Management).” ¹

Operator interpretation: You must integrate information security activities into project management so projects consistently address security requirements, security risks, and necessary controls through the project lifecycle. Practically, that means security has defined entry/exit criteria in your project workflow, and you can demonstrate it ran for a sample of projects. ¹

Public mapping support: Annex A control 5.8 is indexed in public summaries of the Annex A control set. ²

---

Plain-English interpretation (what the control demands)

Annex a 5.8: information security in project management requirement expects repeatable security-by-design in your delivery process:

• Before work starts: You classify the project’s data/system impact, identify major risks, and set minimum security requirements.
• During delivery: You design and implement controls (access, encryption, logging, supplier controls, secure configuration, testing).
• Before go-live: You verify the controls are in place and approved, and that residual risk is explicitly accepted when needed.
• After go-live: You capture the operational handoff (monitoring, incident response readiness, ownership, documentation). ¹

This is governance. It is also evidence production. Auditors want to see that the steps occur because the process requires them, not because a security champion remembered to ask.

---

Who it applies to (entity and operational context)

Entity scope (typical ISO 27001 certification scope):

• Service organizations delivering products or services where changes and projects can affect confidentiality, integrity, or availability of information. ¹

Operational context (where you must apply it):

• New systems and applications (build, buy, or major configuration).
• Major changes to production systems, infrastructure, identity providers, or network segmentation.
• Data initiatives introducing new data types, new processing purposes, new integrations, or new storage locations.
• Third-party introductions or material changes (outsourced development, managed services, cloud platforms, critical SaaS).
• Mergers, divestitures, and restructures where information flows and responsibilities change. ¹

If your teams use Agile, treat “project” as “epic/initiative” rather than a formal project plan. The control is satisfied by consistent gates, not by a specific methodology.

---

What you actually need to do (step-by-step)

1) Define the control as an auditable “runbook”

Create a single-page control card for Annex A 5.8 with:

• Objective: Security requirements are identified, built, verified, and approved for projects.
• Owner: Usually Security Governance/GRC with delivery ownership in Engineering/PMO.
• In-scope triggers: New systems, major changes, new third party, new data processing, go-live events.
• Process steps: Gates and required artifacts (below).
• Exceptions: How you document risk acceptance and who can approve it. ¹

This is the fastest way to prevent the common audit failure: “we do security in projects” with no consistent mechanism to prove it.

2) Add security gates to your project lifecycle

Use gates that align to how work flows in your organization. A common pattern:

Gate A — Intake / Initiation

• Complete a short security impact intake (data types, users, environments, integrations, third parties).
• Determine whether a security risk assessment is required and what depth.
• Assign security roles: security reviewer, system owner, delivery owner. ¹

Gate B — Requirements / Design

• Document security requirements (authentication, authorization, logging, encryption, retention, monitoring).
• Confirm architecture decisions that affect security (identity boundaries, trust zones, key management approach).
• Record decisions on third-party use and contract/security requirements if applicable. ¹

Gate C — Build / Configure / Implement

• Track implementation of required controls through tickets/stories.
• Perform appropriate security testing (for example: configuration review, secure code review, vulnerability assessment as relevant).
• Confirm separation of duties and change control for sensitive changes if required by your internal policy set. ¹

Gate D — Pre-release / Go-live

• Run a go-live security checklist: access is least privilege, secrets management is set, logging/alerting is enabled, backups and recovery are defined, incident runbook exists.
• Obtain security approval or documented risk acceptance for known gaps.
• Ensure handoff to operations includes ownership, monitoring, and support model. ¹

Gate E — Post-implementation review (selective)

• For high-impact projects, verify controls operated as expected and capture lessons learned for the methodology. ¹

3) Make it real in tooling (so it runs without heroics)

Pick the systems your delivery teams already use and wire the gates in:

• Jira/Azure DevOps: required fields, workflow states, approvals, linked evidence.
• ServiceNow change: security checklist and approval group for defined change types.
• CI/CD: require security sign-off for production deployment of high-impact services; attach test outputs. ¹

You are aiming for “default on.” Manual emails do not scale and do not audit well.

4) Define “minimum evidence bundle” per gate (and retention location)

Write down what evidence is mandatory for each gate and where it lives. Example:

Gate	Minimum evidence	Where retained
Intake	Security impact intake + scope decision	Ticket + attached form
Design	Security requirements + architecture/security review notes	Design doc repository + link in ticket
Build	Security tasks tracked + test results	Ticket board + CI artifacts
Go-live	Security checklist + approval/risk acceptance	Change record + approval log

This directly addresses a core risk factor: teams cannot show who owns the requirement, how often it runs, or which evidence proves it is operating. ¹

5) Run control health checks and close gaps

Operate Annex A 5.8 like a recurring control:

• Sample recent projects/changes and verify required gates and evidence exist.
• Log findings as remediation tasks with owners and due dates.
• Validate closure by checking the evidence, not by accepting “done” in a chat thread. ¹

Daydream can help by standardizing control cards, defining evidence bundles, and tracking control health checks and remediation to validated closure, so you can answer auditors with a consistent packet per project. ¹

---

Required evidence and artifacts to retain

Keep evidence tied to specific projects. Auditors will pick samples.

Core artifacts (recommended):

• Project register or list of initiatives with scope tags (in-scope vs out-of-scope).
• Security impact intake record (data/system/third-party flags).
• Security requirements checklist mapped to your environment (cloud, on-prem, SaaS).
• Risk assessment output (lightweight for low risk, deeper for high risk).
• Architecture/security review notes and approvals.
• Security testing outputs relevant to the change (scan summaries, review sign-offs).
• Go-live checklist and approval record (or risk acceptance with approver).
• Post-implementation review notes for selected projects.
• Control health check logs and remediation tracking. ¹

Retention approach: Keep artifacts where teams create them, but enforce durable links from the system of record (project ticket/change ticket) to each artifact.

---

Common exam/audit questions and hangups

Auditors and customer assessors commonly probe:

1. “Show me how security is integrated into project management.”
   They will ask for your methodology and then request project samples that demonstrate it. ¹

2. “How do you decide which projects require deeper security review?”
   Expect to show objective triggers (new data types, internet exposure, privileged access, critical third party). ¹

3. “Where is the evidence, and is it consistent?”
   Inconsistent evidence is a red flag even if teams did the work. ¹

4. “How do you handle exceptions?”
   A missing risk acceptance workflow commonly becomes a nonconformity because it implies unmanaged residual risk. ¹

---

Frequent implementation mistakes (and how to avoid them)

• Mistake: Writing a policy that says ‘security is considered in projects’ but no gates exist.
  Fix: Implement gates in tooling with required fields and approvals. ¹

• Mistake: Treating Annex A 5.8 as an SDLC-only control.
  Fix: Apply it to infrastructure, SaaS configuration, and material changes through change management, not only new code. ¹

• Mistake: Evidence scattered across chat, email, and personal drives.
  Fix: Require links in the ticket/change record to durable repositories. ¹

• Mistake: No explicit ownership.
  Fix: Name an accountable control owner and define RACI across PMO, Engineering, Security, and Procurement for third-party-heavy projects. ¹

• Mistake: Security review happens after build.
  Fix: Put requirements and design review early; late review turns into schedule pressure and risk acceptance by default. ¹

---

Enforcement context and risk implications

ISO 27001 is a certifiable standard, not a regulator, so “penalties” typically show up as audit findings, surveillance audit issues, certification delays, customer contract friction, or increased liability exposure when projects ship with known gaps. The operational risk is straightforward: projects introduce new attack paths, sensitive data handling, and third-party dependencies. Annex A 5.8 reduces the chance that those risks enter production without deliberate review. ¹

---

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Assign an owner and publish the Annex A 5.8 control card (objective, triggers, steps, exceptions). ¹
• Define your gates (intake, design, build, go-live) and the minimum evidence bundle per gate. ¹
• Pilot on a small set of active projects with a lightweight checklist and a single repository structure.

Days 31–60 (make it repeatable in workflow)

• Implement gates in Jira/ADO/ServiceNow workflows: required fields, approval steps, and evidence links.
• Train PMs/engineering leads with a short “how to pass the gate” guide.
• Start a control health check routine and open remediation tickets for missing artifacts. ¹

Days 61–90 (prove operating effectiveness)

• Expand to all in-scope projects/changes based on defined triggers.
• Run a formal sample review of completed projects; package evidence the way an auditor will request it.
• Tune thresholds and templates based on friction points; update the control card and checklists.
• If you use Daydream, standardize evidence bundles and automate reminders/collection so the audit packet is one click, not a scavenger hunt. ¹

Frequently Asked Questions

Does Annex A 5.8 require a specific SDLC (Agile vs Waterfall)?

No. It requires that security activities are integrated into your project management approach and evidenced on real projects. Use gates that match your delivery workflow and tooling. ¹

What counts as a “project” for this control?

Treat any initiative that introduces a new system, materially changes a production system, adds a new third party, or changes data processing as in-scope. Document your triggers so sampling is consistent. ¹

How do we keep this from becoming a paperwork exercise?

Keep gates lightweight and focused on decisions and proof: requirements, review, testing evidence, and approval. Embed it in existing tickets and change records so teams do not maintain parallel documentation. ¹

Do we need a full risk assessment for every project?

Not necessarily. Use an intake screen to determine depth based on impact and exposure, then document the rationale and outcome. Auditors want consistency and traceability. ¹

How should we handle exceptions when a project can’t meet a control before go-live?

Use a documented risk acceptance with scope, compensating controls, an approver with authority, and a remediation due date tracked to closure. Keep it with the project’s evidence bundle. ¹

What’s the fastest way to respond to an auditor sampling request?

Maintain a project evidence packet per initiative: intake, requirements/design review, testing outputs, go-live approval, and any exceptions. If the links are anchored in the project ticket, retrieval is fast and consistent. ¹

Footnotes

1. ISO/IEC 27001 overview

2. ISMS.online Annex A control index