Annex 5.8 (A.5.8): information security in project management

The due-diligence questionnaire asks how security enters your delivery process. Your honest answer is a review the week before go-live, and the launch slips while someone argues for a waiver. Annex 5.8 moves that conversation to kickoff, where a design change costs a whiteboard rub-out rather than a release date.

This guide is for delivery heads, engineering managers and compliance leads at UK regulated firms and B2B SaaS companies of 25–250 staff. It covers what the control asks of every project, three light gates that fit sprints or stage plans, the evidence auditors sample, and how to automate the lot.

What is Annex 5.8 and why is it a preventive control?

Annex 5.8 (A.5.8) is the ISO 27001:2022 organisational control that makes security part of how projects are run, not a review bolted on at the end. The control is classed as preventive: catching a flawed design at initiation stops the incident that retrofitting can only apologise for.

In plain English, the control asks you to treat security as a property of how you run projects. Sprints, stages or a hybrid all qualify. The risk thinking is the same machinery as your organisation-wide risk assessment under clause 6.1.2, applied at project grain. For software work, it is the management wrapper around the secure development life cycle (A.8.25) and application security requirements (A.8.26).

Preventive controls sit at the cheap end of security effort. A kickoff conversation costs half an hour. A detective control, such as reviewing logs after launch, runs for the life of the system and only tells you something has already gone wrong.

The control protects confidentiality, integrity and availability together, because projects create, move and expose information in every dimension. It sits inside delivery governance, and its engine is a risk assessment run for each project.

What does information security in project management require for every project?

Information security in project management means the project method itself must force four things: security risks assessed at kickoff and revisited as work evolves, deliverable security requirements fixed early, the risks of running the project managed, and someone checking at defined points that treatment works. The control applies to any project, whatever the delivery style.

The four requirements, in the order a project meets them:

• Risks assessed early and revisited. A kickoff assessment, repeated when scope, suppliers or data change.
• Deliverable requirements fixed early. Security requirements pinned down while changing course is still cheap.
• Project-running risks managed. Contractor access, communication channels and data used along the way.
• Treatment checked at defined points. A named person confirms the controls work.

The third requirement is the one teams forget. A project creates its own exposures: contractors who need access, a chat channel carrying customer extracts, a spreadsheet of test data on a laptop. None of these sit in the deliverable, yet each can leak.

Checking at defined points is what makes the control auditable. A review that happens whenever someone remembers is not defined. A review tied to kickoff, scope change and release is.

The control is method-agnostic and reaches well beyond software. An office move, a CRM migration, an HR restructure and an acquisition all move sensitive information without a single line of code. Believing the control is for IT projects only is the pitfall that catches firms most often, and the non-IT projects are where they are caught.

Why does project security have to start before go-live?

Projects are where change enters the business, so they are where security debt is born. A defect designed in at week two costs a code review comment. Found at go-live, the same defect costs a delayed launch, or it ships. The NCSC's design principles say the worst outcomes can be avoided when security is a core design consideration.

The NCSC cyber security design principles open with establishing the context: knowing every element of a system before choosing its defences. That is a habit of project initiation, not a phase of testing.

The exposures that hurt a 50-person firm are rarely exotic. A CRM migration quietly processes customer data without a DPIA. A contractor's access outlives the engagement by a year. A production dataset lands in a test system with none of production's protections.

By go-live the pressure has inverted. The team is committed, the customer date is public, and every finding becomes a negotiation about whether to waive it. At kickoff the same finding is a task on the backlog.

Security that first appears at the go-live review is not a gate; it is a waiver request.

What are the three security gates every project needs?

Add three light gates to however you already deliver: a 30-minute kickoff risk conversation recorded on one page, a risk revisit whenever scope shifts mid-flight, and a pre-go-live confirmation by a named person. Leftover risks are accepted in writing by someone with authority to accept them.

The three gates, in order:

1. Kickoff. Hold a 30-minute risk conversation and record it on one page: what data, what access, what could go wrong, what we will do about it.
2. Mid-flight. Revisit the risks when scope shifts, such as a new supplier, a new data type or an added integration.
3. Pre-go-live. A named person confirms the security actions happened. Anything left over is accepted in writing by someone entitled to accept it, which closes the loop opened at kickoff.

Write the rules where people already look: a page in your existing project or delivery guide, not a standalone policy nobody opens. Project leads then find the gates in the document they use to start every project.

In agile delivery the gates attach to sprint boundaries rather than stage documents. Security items go into the backlog and the definition of done. The kickoff gate becomes an epic created at backlog refinement, the mid-flight gate a check at sprint planning when scope moves, and the go-live gate a definition-of-done item on the release ticket.

Over-engineering fails too. A 12-gate governance regime for a 40-person firm produces skipped stages, late sign-offs and records written from memory the day before the audit.

A process the team routes around fails the audit as surely as a missing one.

Which five questions should a project lead answer at kickoff?

Every project answers five initiation questions: what information is involved and how sensitive it is, what confidentiality, integrity and availability protection it needs, who gets access and how they are authorised, which laws and contracts apply, and what existing policies already require. UK GDPR and DPIA triggers come first among the laws.

Put these on the one-page kickoff record:

1. What information is involved? Customer records, staff data, source code, commercial terms, and how sensitive each is under your classification scheme.
2. What protection does it need? Weigh confidentiality, integrity and availability separately; a billing feed may need integrity more than secrecy.
3. Who gets access, and how are they authorised? Name the roles, the approver and, for contractors, the end date.
4. Which laws and contracts apply? UK GDPR first, then customer contracts with security clauses.
5. What do our own policies already require? Access control, classification and supplier rules apply to the project like any other work.

The first legal check is whether the project needs a DPIA. The ICO guidance on Data Protection Impact Assessments says a DPIA should begin early in a project's life, before processing starts, and run alongside planning and development. A kickoff question that asks whether personal data is in scope is the cheapest trigger you can build.

The common shortcut is to answer all five by pointing at the organisational risk register, which describes the business as it stands.

A risk register that cannot see the new data flow is not a project risk assessment.

Who is accountable for security on a project: the project lead or the security lead?

The project lead is accountable for security actions landing in the plan; the security lead or vCISO is consulted on risk and design, not made the doer of everything. A RACI, or simply named accountable and consulted people in the project plan, makes that visible and stops security being everyone's and no one's job.

Accountability sits with the project lead because the project lead owns the plan. A security action with no line in the plan has no date, no owner and little chance of surviving a sprint squeeze. The security lead brings expertise to risk and design reviews and is the consulted voice at each gate, rather than the person chasing every action.

Make the roles visible in three places:

• A RACI, or named accountable and consulted people, in the project plan.
• Go-live sign-off entries that name who signed.
• Risk records where accepted residual risk carries a signature from someone with authority to accept it.

Firms without an in-house security lead can fill the consulted seat with a fractional CISO, who also makes the residual-risk call at go-live when the project lead cannot.

How do you keep test data, third parties and project closure under control?

Keep development, test and production separated, and never move live customer data into lower environments without masking or anonymising it. Vet third parties before they join, with NDAs signed and access scoped and time-limited. Close every project with a checklist that revokes temporary and contractor accounts, because orphaned project access is a finding auditors reliably harvest.

Test data and environments

The ICO guide to data security under UK GDPR expects measures appropriate to the risk and processes that test whether they work. A test environment holding unmasked customer records is hard to defend against that expectation, because test systems rarely carry production's protections. Masked or synthetic data keeps developers productive and the dataset harmless.

Record the arrangement in the architecture notes: which environments exist, how data reaches them and how it is masked. That note is also your answer when the auditor asks what you tested with.

Third parties

Vetting happens before the contractor joins, not after the first commit. Three steps cover it:

• NDA signed before any project material is shared.
• Supplier security checked in proportion to the data they will touch.
• Access scoped and time-limited from day one, with an end date set at onboarding.

Keep the vetting records and NDAs on file as evidence.

Closure

A short closure checklist does three jobs:

• Revokes temporary and contractor accounts and logs the date.
• Archives project records and risk entries.
• Captures lessons for the next kickoff.

Ghost access and unmasked live data share a cause: each was quicker than the alternative on the day. A checklist and a masking step take the shortcut off the table.

What do auditors sample under Annex A 5.8?

Auditors pick one or two recent projects, a live one and a closed one, and trace the thread from initiation record to risk assessment to gate decisions to closure. On the closed project, contractor access is checked against the revocation trail. Interviews with a project lead test whether the process is practised or laminated.

Expect these questions in the room:

• Walk me through how security entered a recent project at the start.
• Who was accountable for security on it, and who signed off go-live?
• Where is the risk assessment, and what changed because of it?
• What data did you test with, and how do you keep production data out of test?
• When did the contractors' access end, and can you show me?

Each question maps to an artefact: the kickoff one-pager or backlog epic, the per-project risk record, the RACI, the go-live entry, the masking note and the closure checklist. If a project lead can open all of them in a few minutes, the interview is short.

Certification bodies typically grade findings under this control as follows:

• Major: security absent from the project method entirely, with no risk assessment or gates on projects that handle sensitive data.
• Minor: a missed closure step, a thin risk record, or one project that skipped a gate.
• Repeated minors: the same small gaps across several projects can be raised as a major, because they read as a pattern rather than a slip.

Walk your own live and closed projects through the thread before the auditor does. A gap you find yourself is a task; the same gap found on three projects is a pattern.

How do you automate project governance without more paperwork?

Put the gates in the tools delivery already uses. Tracker templates in Linear or Jira pre-seed kickoff, requirements and go-live tasks; CI runs SAST, DAST and dependency scanning against agreed thresholds; closing the project record triggers IdP offboarding; and project risks roll into the corporate register. The tooling's history becomes the evidence.

Four automations carry most of the load:

• Gates in the work tracker. Templates ship with the security tasks pre-seeded, so a project cannot reach "done" with security tasks open. The tracker's history is the gate evidence.
• Definition of done as code. For engineering work, the CI pipeline record is the security-testing evidence, and nobody compiles it by hand.
• Closure automated. Closing the project record flags temporary and contractor accounts in the IdP for revocation and logs completion, so the zombie-access finding disappears.
• Risk records as data. Per-project risk entries live in the same system as the corporate register, so project-born risks reach management review instead of dying with the project.

Humans keep the judgement: who accepts the residual risk, and whether a scope change reopens the assessment. The system does the rest and leaves the trail.

At 50 people this runs on tools you already pay for. A buyer's due-diligence question about delivery security gets answered with a tracker export rather than a promise.

Frequently asked questions