ISO 27001 Control A.5.8: Information Security in Project Management

Most security problems that are expensive to fix were cheap to prevent. A new customer portal launches without anyone asking where its data is stored. A migration to a new cloud platform goes live and only afterwards does somebody notice the backup was never configured. A supplier is onboarded for a pilot, the pilot becomes permanent, and no one ever assessed the supplier. A.5.8 is about stopping that pattern by making security a normal part of how projects are planned and run. It is the eighth of 37 organizational controls in Annex A.

The word project is meant broadly. It covers building software, moving offices, introducing a new service, replacing a system, merging with another company or rolling out a new process. Whatever the size, if it creates or changes how information is handled, this control applies.

What the control requires

Annex A control 5.8 of ISO 27001:2022 states that information security shall be integrated into project management.

The key elements:

Information security - confidentiality, integrity and availability of the information the project creates, uses or changes
Integrated - built into the project’s normal steps and decisions, not handled as a separate stream that runs beside it
Project management - whatever method you use, from a formal methodology to a short checklist for small initiatives

A.5.8 is a preventive control in ISO/IEC 27002:2022. It prevents security gaps from being designed into new things. Annex A states the control; ISO 27002 gives guidance, including that information security risks should be assessed and treated at an early stage and reviewed periodically throughout the project, that requirements such as those for application security should be determined, and that responsibilities for information security should be defined and allocated to specified roles in the project. It also suggests considering the information involved, its need for protection and the effect of project activities on the business.

How to implement security in project management

Add security to the project lifecycle

Look at how projects start, run and finish in your organization, and add small security steps at each stage. You do not need a new methodology. A practical pattern looks like this:

Initiation - a short screening question: does this project handle personal or confidential data, change systems, involve a new supplier, or affect how customers access our services? If yes, security is involved from the start
Planning - requirements, risks and responsibilities are written down alongside cost and timeline
Delivery - security checks occur at the same milestones as other quality checks
Go-live - a final review confirms the agreed controls are in place before launch
Closure - temporary access is removed, handover to operations is complete and lessons are captured

The sooner a project asks the screening question, the cheaper every later decision is. A one-page form completed by the project sponsor is often enough to decide whether a deeper review is needed.

Assess risk early and repeat it

Run a proportionate risk assessment when the project is defined, using the same method as the rest of your ISMS. Ask what information the project will touch, who will have access, which suppliers will be involved, what could go wrong and what the business impact would be. Record the risks, decide how to treat them and add the actions to the project plan with owners and dates. Then revisit the assessment when scope changes or at key milestones. This connects directly to clause 8.2, Information security risk assessment, and to clause 6.3, Planning of changes, which requires changes to the ISMS to be carried out in a planned manner.

A small risk note written in the first week is worth more than a long report written in the last.

Define requirements and roles

Turn the risk assessment into concrete security requirements, such as where data may be stored, how users will be authenticated, what logging is needed, how the system will be backed up and who may administer it. Writing requirements early gives suppliers and developers something to build to and gives testers something to test against.

Assign named responsibilities. The project manager is usually accountable for making sure the steps happen, a business owner for accepting residual risk, and a technical lead for implementing controls. Reference your existing information security roles and responsibilities so that projects do not invent their own structure. The sponsor, in line with management responsibilities, should expect security to be reported alongside budget and schedule.

Use gates and keep evidence

Decide what must be true before a project moves forward. A simple go-live checklist might ask:

Has the risk assessment been completed and reviewed?
Have agreed controls been implemented and tested?
Have supplier assessments and contracts been completed?
Is access limited to people who need it, and are test or temporary accounts removed?
Have operations received documentation, monitoring and a contact for incidents?
Has the business owner formally accepted any remaining risk?

Keep the completed checklist with the project records. Do not use real production data for testing unless it is protected, and make sure that temporary arrangements for the project, such as shared accounts or relaxed firewall rules, are tracked and closed. For projects that involve building software, later controls in Annex A on secure development become the technical layer within this governance.

Include physical and people aspects

Projects that change premises, equipment or teams also have security effects. Moving offices touches physical security perimeters and securing offices, rooms and facilities. Hiring contractors for a project brings in screening and confidentiality or non-disclosure agreements. Make sure the project plan reminds teams to cover these.

A.5.1 connection. Policies for information security should state that projects must consider security.

A.5.2 connection. Information security roles and responsibilities provides the roles projects should reuse.

A.5.4 connection. Management responsibilities means project sponsors and managers are expected to apply the rules.

A.6.1 connection. Screening applies to temporary staff and contractors joining projects.

A.7.3 connection. Securing offices, rooms and facilities matters for projects that build or move into new spaces.

Clause 6.3 connection. Planning of changes requires changes to the ISMS to be planned and controlled, a close relative of project governance.

Clause 8.2 connection. Information security risk assessment is the method the project assessment should follow.

Forward reference. Information security in supplier relationships, the secure development life cycle, application security requirements and change management are covered later in the series; each is a place where project security becomes specific.

What auditors check

A defined approach. Auditors ask how security is included in projects and look for a procedure, template or checklist, even a brief one.

Samples of real projects. They pick recent projects and look for a risk assessment, security requirements and a go-live review. A project that skipped them is the most common finding.

Timing. They notice whether security entered at the start or at the end. Evidence dated shortly before launch suggests it was bolted on.

Roles. Named responsibility for security in each project is expected, and auditors check it matches your role descriptions.

Acceptance of risk. Where risks remain at go-live, they expect a record that a suitable person accepted them.

Closure. Removal of temporary access and handover to operations show that the project ended cleanly.

Common mistakes to avoid

Security as a last-week activity. A late review finds problems when changing course is most expensive, so it is often skipped or waived.

One size fits all. Forcing a tiny change through a heavy process makes people avoid the process. Scale the review to the risk.

Only IT projects count. Office moves, new suppliers and process changes affect information security just as much.

No record of decisions. A verbal “it was fine” is not evidence. A short, dated checklist is.

Forgetting the handover. Projects end, systems remain. If operations never learns the security assumptions, the control stops at launch.

Treating temporary as harmless. Shared test accounts and relaxed rules have a habit of becoming permanent.

How 27kay can help

We help organizations add security to the way they already run projects, with a screening question, a light risk note and a go-live checklist that teams will actually use. As part of ISO 27001 implementation, we tailor the process to your size and methods, and prepare the evidence for your audit. For the full picture, see our ISO 27001 knowledge hub.

Think of the last project your team shipped: when was security first mentioned? Get in touch - we will help you make the answer “on day one”.