Change type

Infrastructure changes: what the auditor reads in them

Infrastructure changes often bypass the application pipeline: a console change, a script run by an engineer, a scaling rule edited in place. They are where deployments with no matching change and one person in all three roles show most often.

How the checker recognises them

Read from the title and system: network, firewall, cluster, server, credentials, scaling, storage and the like.

Findings they raise most often

Deployment with no matching change: Which change record covers this deployment, and is the change population you gave us complete?
One person, three roles: What stops one person from writing, approving and releasing a change, and who reviewed this one after the event?
Deployed their own change: How is a developer prevented from promoting their own change to production, and what compensates where they can?

The clauses that speak to them

4 clauses

COBIT BAI10.03 Maintain and control configuration items

The clause text

An up-to-date repository of configuration items is maintained by populating all configuration changes: all changes to CIs are regularly identified, proposed changes are reviewed against the baseline for completeness and accuracy, configuration details are updated for approved changes, and changes to baselines are created, reviewed and formally agreed whenever needed.

Evidence an auditor expects: Configuration updates tied to approved changes; baseline change approvals
Where it usually falls short: Repository that describes the environment as it was months ago
Source: COBIT 2019

ISO 27001 8.9 Configuration management

The clause text

Establish, document, implement, monitor and review secure configurations for hardware, software, services and networks.

Evidence an auditor expects: Baseline configurations; Change control records; Configuration audit reports; Secure hardening guidelines; Deviation approvals
Where it usually falls short: Outdated baselines; Missing change approvals
Source: ISO/IEC 27001:2022

SP 800-53 CM-5 Access restrictions for change

The clause text

Requires physical and logical access restrictions on who may make changes to the system to be defined, documented, approved and actually enforced, so that only authorized personnel can alter the system.

Evidence an auditor expects: Documented and approved restrictions on who may change what; Access control configuration for production change paths and deployment pipelines; Records showing enforcement, for example rejected unauthorized deployments; Review of privileged change access against the approved list
Where it usually falls short: Developers hold standing write access to production alongside the pipeline; Restrictions documented but not enforced, so the pipeline can be bypassed manually
Source: NIST SP 800-53 Rev 5

SP 800-53 SI-7 Software, firmware, and information integrity

The clause text

Requires integrity verification tools to be employed to detect unauthorized changes to organization-defined software, firmware and information, and requires organization-defined actions to be taken when such unauthorized changes are detected.

Evidence an auditor expects: Defined list of software, firmware and information subject to integrity verification; Integrity monitoring tool configuration and coverage report; Alerts generated by integrity checks and the response records; Documented actions to be taken on detection of unauthorized change
Where it usually falls short: Integrity monitoring produces constant noise from routine change and is therefore ignored; Firmware excluded because tooling only covers the operating system layer
Source: NIST SP 800-53 Rev 5

Other change types

Run the specimen Check your own change log