ISO 27001 Control 5.8 Information Security in Project Management

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

The Purpose of Control 5.8

In my earlier days of being a project manager, when my hair was stronger, and my knees didn’t complain, someone once said to me, “You can’t sprinkle security on a project at the end, Alan. It needs to be baked in from the beginning.” It resonated hard and loud and continues to this day.

And that’s the point of control 5.8: having information security built into project management. By doing so, you’ll be able to;

• Identify and address security risks at the earliest stages – things that really might shape success.
• Ensure deliverables meet organisational security requirements and protect sensitive data.
• Maintain compliance with relevant legal, regulatory, and organisational policies.

If you leave it to an afterthought once a project is delivered, it’ll likely be a crippling blow to the business, as it’ll be too late and too costly.

I was once involved in a project where (late in the day) the client changed the requirements for the software and raised the security bar to such a level that we had to go back through the code, line-by-line and update it over several months and at a cost of hundreds of thousands of pounds. If the sales team and client had their act together in the earlier stages of the project, it would have fundamentally changed our overall approach, and we’d have taken a different path with a quicker, less costly outcome.

How to Meet Control 5.8 Information Security in Project Management

The single most useful thing you can do to satisfy 5.8 is to create (or update) a project approach document that lays out to project managers, and anyone else running a project, exactly how security should be considered along the way. They won’t know unless you tell them, and they certainly won’t ask if it isn’t part of the process they’re used to following. This is a great opportunity to give guidance, training, and a clear “come to me for help” support route when it’s needed.

My full ISO 27001 toolkit includes a downloadable Project Management Guidelines template that covers this directly. But whether you use that or build your own, the document should tell project teams what’s expected at each stage of a project and what good security thinking looks like in practice.

Effectively, you want projects to undertake the following:

1. Early Risk Assessment and Treatment

Every project should start with a security-aware risk assessment during its initiation and planning phases. The whole point is to catch security issues before they’re baked into the design, when they’re cheap to fix, rather than after the system is live, when they’re not.

• Conduct a security risk assessment during the planning phase. For most projects, this can be a quick exercise that captures risks in a table. Start with that data evaluation as your primary input: what data the project handles, where it will sit, who’ll have access, and what could go wrong. Follow my risk scoring approach guidelines.
  
• Reevaluate and adapt risk treatments as the project progresses. Risks shift as the design firms up; what looked manageable at initiation may need different treatment at implementation.

One practical observation: most projects don’t only fail security at design time; they fail it at scope-change time. When a stakeholder asks for “just one small addition”, the security implications often get missed, so make sure you are capturing an evaluation of that aspect. Build a quick security-impact check into your change control process.

2. Defining Security Requirements

Security requirements should be defined at the same time as functional and non-functional requirements, not bolted on afterwards. Treat them as project deliverables in their own right, with acceptance criteria that the project has to meet before going live.

Common areas to cover, depending on the project type:

• Application security. Where the project involves new or modified software, define the security requirements explicitly (authentication, authorisation, input validation, logging, secure development standards).
• Data and intellectual property protection. Identify what data the project will handle, what classification it falls under, and how it will be protected in transit and at rest.
• Security of internal and external communications. If the project involves new integrations, APIs, or third-party data flows, the protection of those communications needs to be in scope from the start.
• Access and identity. Who’ll have access to the system once it’s live, on what basis, and how access will be reviewed and revoked.
• Compliance and regulatory considerations. If the project touches personal data, regulated information, or contractual obligations, these need to be identified up front.

The principle is the same one that runs through the rest of ISO 27001: assume the security requirements need to be specified, not assumed.

3. Ongoing Risk Monitoring

I mentioned it earlier, but once the project is underway, the security risk picture shouldn’t go quiet. Three things keep it alive:

• A standing agenda item around security at project/requirements meetings, even if the answer is “nothing new this week”. Asking the question keeps the topic visible.
• A documented review of security controls at each major project milestone or phase gate. If the control was designed at initiation, has it actually been built in? This may be part of your QA process or something else, but we need to make sure security is implemented and works.
• A trigger-based review whenever the project’s scope, technology, or stakeholders change. New supplier? New data type? New deployment target? Reassess the risk.

For most small projects, this doesn’t need to be elaborate. A quick check during the weekly project standup and a more deliberate review at each phase gate is probably enough. What auditors want to see is risk evaluation, conscious decision-making, and evidence that the questions are being asked, not a 20-page security report at every meeting.

4. Governance and Oversight

Larger projects (and I’m thinking from my own experience in software delivery) benefit from a steering committee or governance body that owns the higher-level security decisions: residual risk acceptance, exception approvals, sign-off on key controls. When running smaller projects, the same role often sits with the project sponsor or MD.

The important thing is that someone with appropriate authority is making the security decisions, not just leaving it to the project manager. A few suggestions;

• Clearly identify who owns the project’s security decisions. This should be named in the project documentation, not assumed. I know it leads to difficult discussions sometimes, but accountability is crucial. If you don’t name some as accountable, it won’t happen.
  
• Build security sign-off into the phase gates. The project shouldn’t move from design to build, or from build to live, without explicit confirmation that the security requirements have been met / QA sign-off, etc.
  
• Make sure the governance body sees the security risk picture, not just the cost and schedule picture. If your steering meeting agenda doesn’t include security, the message that goes back to the project team is that security isn’t a steering-level concern. It is.

5. Closing the Project Properly

When I was in my earlier career as a technology support manager, one of my bugbears was projects finishing and throwing their deliveries over the fence at my team and me, with little or no engagement or handover. So, one commonly missed area worth flagging is project closure. When a project finishes, the security implications need to be carried through into the operational handover.

• Any new system, supplier, or data flow needs to be picked up by the relevant operational owner. Asset register, supplier register, access control records, and monitoring scope all need updating.
  
• Any residual risks accepted during the project need to be transferred to the live risk register, with named owners, not left in the project’s risk log.
  
• Project documentation, including security risk assessments and decisions made, should be retained in accordance with your document retention policy. Auditors may ask for them months later, particularly during an internal audit of operational systems.

My experience (and the statistics back me up) is that most projects don’t fail at the delivery as a whole; they fail at the handover and execuction, where the security thinking that went into the project quietly disappears once the project closes.

Proper closure steps capture the lessons and bake the controls into the ISMS.

An Example of Control 5.8 in the Project Process

What Auditors Will Look For

Control 5.8 is one of the easier controls to evidence at audit, provided you’ve integrated security into your project process. The auditor will normally ask for:

• A Project Management Guidelines document or equivalent that sets out how security is expected to be considered through the project lifecycle
• Examples of recent project documentation showing security risk assessments at the planning stage
• Evidence that security requirements were defined alongside functional requirements, not added afterwards
• Phase gate or milestone records showing security sign-off as part of the gate criteria
• Risk register entries that have been transferred from project risk logs to the operational risk register after closure
• An example of a scope or requirements change that triggered a security reassessment, with the outcome documented

Auditors could also test this verbally with project managers and project sponsors. Maybe questions like: “When did you last identify a security risk in this project?”, “What changed when stakeholder X asked for that additional feature?”, and “Who signed off the security requirements before go-live?”. If the project team can answer these confidently with reference to documented decisions, your 5.8 is working.

Common Issues I Find During Internal Audits

Here’s what I occasionally see when running internal audits:

Security is treated as just a post-delivery checklist.

The project is completed, and then someone runs a security checklist before going live. By that point, design decisions are locked in, and the only options are to accept the risk, delay the go-live, or rebuild parts of the system (have you not read my anecdote!) None of these is a good place to be. Build the security thinking into initiation and planning, not into the last sprint.

So, there’s evidence, but it’s not really what the control is looking for, so it’d earn an NC, I’m afraid.

No documented project management approach.

The organisation does projects (who doesn’t), but there’s no written guidance on how security should be considered through the lifecycle. That means every project manager makes it up, and you’ll get widely differing results depending on the project, the project manager, and whether they remembered to do it.

Scope changes that skip security review.

I’d lay a heavy bet that the project’s change control process captures cost and schedule impact but doesn’t include a security impact check. Three sprints into a major software delivery, the project looks nothing like the one whose risk assessment was approved at initiation. So, it’s important that the change process (RFCs, etc) capture some kind of evaluation on the security impact, even if it’s “none”.

No security sign-off at phase gates.

Well, this boils my blood anyway, as an ex-governance/project manager over the past 30 years: Projects that move from design to build to live without explicit checkpoints. Security should be part of those checkpoint evaluations, not just barrelled through with the PM signing off at the gate themselves, with nobody else doing so.

Steering committees that never see security.

The cost and schedule update is on every agenda; security isn’t. No mention of it in the PID/Project Mandate. The implicit message to the project team is clear: deliver on time and on budget; security can wait.

How does ISO 27001 Control 5.8 link to other clauses and controls

Control 5.8 connects to several other parts of the ISMS because projects often introduce new systems, suppliers, and risks that other controls must manage.

Understanding the relationships helps you avoid documenting the same thing in multiple places.

• Clause 6.1 – Risk assessment: Project-level risk assessments should feed your organisational risk register, not run as separate exercises.
• Control 5.2 – Roles and responsibilities: 5.8 specifically requires security decisions to be allocated to named roles within projects.
• Controls 5.19 to 5.21 – Supplier relationships: New suppliers introduced through projects need to pass through your supplier management process before going live.
• Control 5.23 – Use of cloud services: Projects introducing new cloud services must satisfy 5.23 before deployment, not after.
• Controls 8.25 to 8.30 – Secure development cluster: Software projects need to align with your secure development standards.
• Control 8.32 – Change management: The change control process should include a security impact check on project scope changes.

SME Implementation Checklist for Control 5.8

A short check you can run against any project to make sure security is being considered properly. If you can tick all five, you’re meeting the control.

• Project Management Guidelines exist, and the project team has read them. One document that outlines the expected security thinking for project teams at each phase.
• Security risk assessment is done at the start of the project, not the end. Identifies the data involved, who’ll access it, and what could go wrong.
• Security requirements are written into the project alongside functional ones. Treated as deliverables with acceptance criteria, not afterthoughts.
• Scope changes trigger a security check. Built into the change control process, not relying on someone remembering to ask.
• Clean handover at project closure. New systems, suppliers, and residual risks transferred to operational ownership with named owners.

If you can produce evidence for all five at the audit (or at least that’s your plan going forward with supporting documents), you’re done.

FAQs

Conclusion

Information security in project management is one of those controls that pays back disproportionately painfully if you get it right. Building security into projects from the start saves the much higher costs of retrofitting later, and the practitioner’s story earlier on this page is a small example of what the alternative looks like in practice.

For most SMEs, satisfying 5.8 doesn’t require a heavyweight project methodology. A documented project management approach that outlines the expected level of security thinking at each phase, a security-impact check built into change control, and a clean handover from project to operational ownership at closure are sufficient. Keep it proportionate, keep the evidence as you go, and you’ll have control that genuinely makes projects safer rather than just satisfying the audit.

If you’d like a ready-made Project Management Guidelines template alongside the wider ISMS documents, the Iseo Blue ISO 27001 Toolkit includes both. Or if you’d rather talk through how to integrate security into your specific project process, the free 30-minute consultation is genuinely free and genuinely 30 minutes.

Author Background

This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.

With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.

Qualifications: Certified ISO 27001 Lead Auditor (ANAB-accredited certification),
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.

Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.

Alan Parker