Information security in project management

What the requirement 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Project management is where security is easiest to lose. The guidance asks for a security role in the project method, a risk gate at defined points and evidence that the gate was used on a real project.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep the project management methodology showing mandatory security steps at initiation and at defined stage gates and one live sample together.

Evidence an assessor asks for

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

The question an assessor will ask

An assessor will ask for the project management methodology showing mandatory security steps at initiation and at defined stage gates, then trace it to the system it protects. For A.5.8 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: security is only considered for ict development projects, not facilities or business process projects.