Information security in project management

What the control asks

Information security is to be built into the way projects are managed. Purpose: make sure security risks tied to projects and their deliverables are handled effectively through every stage of the project. Guidance: this applies to every kind of project whatever its size, length, complexity or subject, whether a core business process, ICT, facilities or a support function. The project method should require that security risks are assessed and treated early and at intervals as part of project risk; that security requirements, such as application security (8.26) and intellectual property compliance (5.32), are dealt with early; that risks arising from running the project itself, such as internal and external communications, are handled throughout; and that progress on risk treatment is reviewed and its effectiveness evaluated and tested. Suitable people or bodies, such as a steering committee, check the security work at set stages, and project security responsibilities and authorities are assigned to named roles. Requirements for the product or service are derived from policies and regulation and from threat modelling, incident reviews, vulnerability thresholds and contingency planning, so the design resists known threats. For all project types consider: which information is involved, its classification (5.12) and the business impact of weak security; the confidentiality, integrity and availability needs of the assets; the assurance needed about identities, to set authentication requirements; access provisioning for customers, business users and privileged or technical users including project staff, operators and suppliers; telling users their duties; process-driven needs such as transaction logging, monitoring and non-repudiation; requirements imposed by other controls such as logging or leakage detection interfaces; legal, regulatory and contractual obligations; and the assurance needed that third parties meet the organization's policies, including contract clauses. Other information: waterfall or agile approaches should both support security in a structured way scaled to risk; ISO 21500, ISO 21502 and ISO/IEC 27005 give related guidance.

Purpose in the standard’s terms, in our words: Ensures security risks of projects and their deliverables are addressed throughout the project life cycle.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Identify, Protect; Governance; Governance and ecosystem, Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• The project management methodology showing mandatory security steps at initiation and at defined stage gates
• Project risk registers containing information security risks assessed early and revisited during the project
• Documented security requirements for the deliverable, derived from policy, regulation, threat modelling and classification of the information involved
• Stage-gate or steering committee minutes recording review of the security work
• A project RACI naming who holds security responsibilities and authorities
• Test or review results showing that security risk treatments were evaluated for effectiveness

Where audits commonly find gaps

• Security is only considered for ICT development projects, not facilities or business process projects
• Security requirements are added late, after design decisions are fixed
• Risks from running the project itself, such as insecure sharing with external partners, are ignored
• No stage gate checks whether security treatments actually work

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. Its earlier numbering (06.1.5, 14.1.1) is kept in the register so an older audit file can still be traced. It serves more than one security domain, which is why a domain count taken by row understates the view.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 5.2 Information security roles and responsibilities
• 5.1 Policies for information security
• 5.10 Acceptable use of information and other associated assets

Read the five attributes All 93 controls