What evidence do auditors commonly ask for on 5.8 Information security in project management?

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.

What is the most common gap auditors find on 5.8?

Security is only considered for ICT development projects, not facilities or business process projects

ISO/IEC 27002:2022 · Organizational controls

`5.8` Information security in project management

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.

Source: ISO/IEC 27002:2022, 5.8. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.

artefacts

held by a system

at each review

hard

to go live

Policy repository / GRC workspace

where the evidence lives

teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

none for this control

periodic reviewEvidence produced at each review

Stage-gate or steering committee minutes recording review of the security work · Policy repository / GRC workspace
Test or review results showing that security risk treatments were evaluated for effectiveness · Document repository

governing documentDocuments that govern the control

The project management methodology showing mandatory security steps at initiation and at defined stage gates · Document repository
Project risk registers containing information security risks assessed early and revisited during the project · Policy repository / GRC workspace
Documented security requirements for the deliverable, derived from policy, regulation, threat modelling and classification of the information involved · Policy repository / GRC workspace
A project RACI naming who holds security responsibilities and authorities · Policy repository / GRC workspace

First move

No system holds this evidence for you: it is people and documents. Reminders and routing to the owner still save time. Put the document under version control with an owner and review date, and log each review as a record with reviewer and date.

Common gaps auditors find

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

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

5.7 Threat intelligence · 5.9 Inventory of information and other associated assets