EvidenceSheet

8.32 Change management

Every change to information systems and processing facilities is to pass through the change management procedures. Purpose: keep information secure while changes are carried out. Guidance: introducing new systems or making major changes follows agreed rules and a formal path that documents, specifies, tests and quality-checks the change and manages its roll-out, with management responsibilities and procedures giving adequate control over every change. Change control procedures are documented and enforced so information stays confidential, intact and available from the first design work through every later round of maintenance, and procedures for ICT infrastructure and software are integrated wherever practical. They should cover planning and assessing the impact of changes, taking all dependencies into account; authorizing changes; informing relevant interested parties; testing changes and accepting the test results (8.29); implementing changes with deployment plans; emergency and contingency arrangements including fallback; keeping records of changes covering all of these; updating operating documentation (5.37) and user procedures as needed; and revising ICT continuity plans and the associated response and recovery steps (5.30) where required. Other information: poorly controlled change is a frequent cause of system and security failures, and moving software from development into operation can affect application integrity and availability; software changes affect production and the reverse; good practice is to test ICT components, including patches, service packs and other updates, in an environment separate from both production and development (8.31); production includes operating systems, databases and middleware, and the control covers application and infrastructure changes alike.

Source: ISO/IEC 27002:2022, 8.32. 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.

6
artefacts
3
held by a system
2
at each review
easy
to go live
Source control / CI pipeline
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

  • Change records showing impact and dependency assessment, authorization, stakeholder communication, testing and acceptance, deployment plan and fallback · Source control / CI pipeline
  • Emergency change records with retrospective review and approval · Document repository
  • Records of patches and updates tested in a segregated environment before deployment · Vulnerability scanner / patch tooling

periodic reviewEvidence produced at each review

  • Evidence that operating documentation, user procedures and ICT continuity plans were updated after changes · Policy repository / GRC workspace
  • Reconciliation of changes detected in production (for example from configuration monitoring) against approved change records · SIEM / log platform

governing documentDocuments that govern the control

  • The documented change management procedure covering infrastructure and software, integrated where practical · Policy repository / GRC workspace

First move

Automate the pull from your Source control / CI pipeline. Pull-request approvals, pipeline test results and deployment records from source control, per release.

Common gaps auditors find

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

8.31 Separation of development, test and production environments · 8.33 Test information