ISO 27001 A.5.8: Build Security into Project Decisions

What A.5.8 requires in practice

Annex A control A.5.8 asks that information security be integrated into project management. The key idea is integration: security considered inside the project from the start, not bolted on at the end or handled by a separate process nobody consults.

This applies to projects of any kind that touch information, such as building a system, moving a service, changing a process or onboarding a customer. The organisation decides how to embed security in its method. Typical elements are considering risks and requirements at the outset, assigning responsibility within the project, and revisiting security as the project changes and before it finishes.

The control does not prescribe a methodology, a checklist or a particular gate. Small projects can use light arrangements, while larger ones may need more structured steps. The test is whether security risks and requirements are visibly considered in how projects are planned, approved and delivered.

Examine two different sources of exposure

First consider the information and activities used to run the project: supplier exchanges, tender material, temporary access and collaboration spaces. Then consider the service, facility or process the project will deliver. A project can protect its own documents while producing an insecure operational arrangement, or deliver a well-designed service while mishandling sensitive development information.

Identify an owner for both perspectives. Project management coordinates decisions, but relevant business, technical and information owners need to contribute. The security specialist should not become the default approver of requirements that only the customer or operational owner can define.

Translate business needs into assessable requirements

Early questions should establish what information is involved, how it will be used and what harm could follow loss, alteration or inappropriate disclosure. Consider customer commitments and applicable obligations with competent input. Convert the important findings into requirements that the project can evaluate, rather than a general instruction to “be secure”.

A useful requirement identifies the expected outcome and the evidence needed before acceptance. It may concern who can access a service, how recovery will be demonstrated or which supplier responsibilities must be agreed. Connect application-specific work with application security requirements where relevant, without treating every project as a software-development project.

Revisit risk when a decision changes the assumptions

Use the project’s existing decision points to reconsider material changes. A different provider, delivery location, information flow or operating model can invalidate earlier assumptions. Short iterative projects can address this through their normal planning and acceptance work; longer programmes may use formal review gates. The method should expose relevant decisions in time.

Define who can accept unresolved risk and what happens when the acceptance evidence is incomplete. A project manager’s authority over schedule does not automatically include authority to accept a significant operational security exposure. Record the decision and its conditions, including work that will continue after handover.

Why project security matters to the business

Problems found late in a project are the most expensive to fix. A weakness designed into a new service can mean rework, delayed launches of the service to customers or a risk the business must live with. Considering information security early costs far less and avoids unwelcome surprises when an assessor or customer reviews the finished result.

Projects are also where new suppliers, data flows and access arrangements appear, so they are a frequent source of unnoticed exposure. Integrating security into normal project governance means decisions are made with the right information, owners know what they are accepting and the ISMS stays in step with how the business actually changes.

How to implement A.5.8

Add security to the project routine you already have instead of creating a separate approval track. The aim is to make the right question appear at the right time, without adding bureaucracy to small initiatives. Smaller changes, such as a new tool adopted by one team, deserve a lighter route than a major programme, but should not be invisible.

1. Define which projects trigger security attention, using simple criteria such as use of sensitive information, new suppliers or changes to access.
2. Include a short security question set at project start to identify risks and requirements.
3. Name a person within each relevant project who is responsible for security considerations and knows whom to ask.
4. Make sure identified risks are recorded, owned and handled in the project plan, not parked.
5. Revisit security at significant points, particularly before go-live or handover to operations.
6. Review closed projects for lessons and adjust the method where the same gaps recur.
7. Include suppliers and external developers in the same approach, so work done outside the business is not an exception.

Evidence an auditor expects for A.5.8

Common nonconformities with A.5.8

Weaknesses usually reveal security being treated as a late step. Findings usually appear when auditors follow a single project from its start to its handover.

• Sampled projects show no sign that information security was considered before delivery.
• Security reviews happen only after a system is already built or live.
• Risks raised by the project team have no owner or outcome recorded.
• Small changes and supplier-led projects bypass the process entirely.
• Security requirements were identified, but were not tested or confirmed before the system went live.

Illustrative construction example: a temporary design environment

Illustrative BPO example: launching a new client service

A hypothetical BPO provider transfers a client process to a new delivery site. The project plan initially covers staffing and productivity but overlooks who will own archived customer records and temporary migration accounts. A security review identifies those issues before the first production transfer.

The operational owner agrees the record arrangements, and IT defines the migration-access lifecycle. Handover checks confirm that temporary rights were removed and the responsible team can retrieve the required evidence. The project does not close merely because the new site handled its first successful transaction.

Make handover an explicit security decision

Operations needs usable information about implemented controls, residual issues, responsibilities and supporting suppliers. Check that the team accepting the service has the capability and resources to operate it. An unresolved project issue should not disappear when the project workspace is archived.

Relevant evidence may sit in requirements, risk assessments, test results, approvals and handover records. ISO 27001 does not mandate a separate project-security template. The link to supplier security relationships is important when project contractors become operational providers or leave behind services that nobody has agreed to maintain.

Common weaknesses include security reviews occurring too late to influence design, assumptions never revisited after scope changes and acceptance based on a supplier’s presentation instead of relevant evidence. Sample one completed project and trace a security requirement from initial need to operational ownership. Then examine a changed requirement to see whether the process worked under pressure.