Information security in project management

Plain-language summary

Building information security into every project from the start — identifying security requirements and risks early, treating them through the project life cycle and checking them before go-live — whatever kind of project it is, not only IT ones.

What the clause is really asking

Security bolted on at the end of a project costs more and works worse. This control asks that security become part of how you run projects, so it applies to every project regardless of type: an ERP upgrade, an office move, a new product line, an outsourcing deal, a website rebuild. In practice that means a security risk assessment early in the project, repeated as the project changes; security requirements defined alongside the business requirements (the classification of the information involved, access needs, legal and contractual obligations, availability); security responsibilities in the project allocated; and a check before go-live that the requirements were met. Risks the project creates should reach the right risk owners rather than stay in a project file. The common misunderstanding is that this applies only to software development. A move to new premises or a new supplier relationship needs it just as much. ISO 9001 organisations can add security gates to their existing design and development or stage-gate process, and clause 6.3 on planning changes points the same way.

What auditors look for

Auditors ask for your project management procedure and look for where security appears: a checklist, a gate, a required risk assessment. They then pick one or two recent projects, preferably one not run by IT, and trace them end to end — the initial security assessment, the requirements, the risk treatment, the pre-go-live review and who signed it off. They check whether new processing of personal information introduced by the project was assessed. They ask the project manager, not the security lead, how security was handled. The hard question: show me a project where the security review changed the design or delayed go-live.

Typical evidence

Project management procedure with security steps or gates; project security checklists or questionnaires; project-level risk assessments; security requirements in project specifications; privacy impact assessments where personal information is processed; gate or go-live approval records with security sign-off; project register showing assessment status; lessons-learned records.

How to comply — recommendations

Add a one-page security checklist to your project initiation template: what information is involved and its classification, personal information and POPIA impact, new suppliers or cloud services, access requirements, legal or contractual requirements, availability needs. Require the checklist at project start and a security sign-off at the go-live or handover gate. For larger projects, run a short risk workshop and move the risks into the main risk register with owners. Keep a project register showing each project's security status. Brief project managers once a year and review two closed projects annually to check the gates were used.

Common nonconformities

Project methodology with no security step; projects outside IT never assessed; security risks identified but never transferred to the risk register; no security sign-off before go-live; personal information impact not considered for new processing; security checklist completed after implementation; project managers unaware of the requirement; no evidence available for recent projects.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.