Change management

What the requirement asks

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. 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

Change management is the control that keeps the system honest. The guidance asks for the request, the risk, the approval, the test and the rollback.

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 documented change management procedure covering infrastructure and software, integrated where practical and one live sample together.

Evidence an assessor asks for

• Change controlThe documented change management procedure covering infrastructure and software, integrated where practical
• Change controlChange records showing impact and dependency assessment, authorization, stakeholder communication, testing and acceptance, deployment plan and fallback
• Change controlEmergency change records with retrospective review and approval
• Change controlEvidence that operating documentation, user procedures and ICT continuity plans were updated after changes
• Change controlReconciliation of changes detected in production (for example from configuration monitoring) against approved change records
• Change controlRecords of patches and updates tested in a segregated environment before deployment

The question an assessor will ask

An assessor will ask for the documented change management procedure covering infrastructure and software, integrated where practical, then trace it to the system it protects. For A.8.32 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Changes are made directly in production without a change record
• Emergency changes are never reviewed after the fact
• Impact assessment ignores dependencies, causing unexpected outages
• Continuity plans and runbooks are not updated after infrastructure changes

Before the next audit

Before the next audit, check one live sample for this gap: changes are made directly in production without a change record.