Deployment with no matching change: what the rows show and the clause behind it
A deployment in the log that the checker could not tie to any change in the population, by the change reference on the deployment or by time on the same system. Either the population is short, or something reached production outside the change process.
Why reconcile the deployment log against the change tickets before the auditor does?
An auditor samples from the change population you hand over, and a population is only as good as its completeness. The deployment log is the independent record of what reached production; reconciling the two is how the completeness question gets answered before it is asked. COBIT BAI06.03 tracks every change request, BAI10.03 ties configuration to approved changes, and NIST SP 800-53 SI-7 looks for changes nobody authorised. The checker ties each deployment to a change by reference or by time on the same system and lists the rest.
The question the auditor is likely to ask
walkthrough packWhich change record covers this deployment, and is the change population you gave us complete?
The clause behind it
10 clauses in 7 frameworks| Framework | The clause behind it |
|---|---|
| SOX 404 / ICFR | SOX 404 ITGC IT General Controls (ITGC) - Access, Change, Operations |
| PCAOB AS 2201 | AS 2201 ¶22-27 Entity-level controls and the period-end process, including IT general controls |
| COBIT 2019 | COBIT BAI06.03 Track and report change status · COBIT BAI10.03 Maintain and control configuration items |
| SOC 2 (Trust Services Criteria) | SOC 2 CC7.1 Detection and monitoring procedures for security events are in place |
| ISO/IEC 27001:2022 | ISO 27001 8.9 Configuration management · ISO 27001 8.19 Installation of software on operational systems |
| PCI DSS v4.0 | PCI DSS 6.5.2 Requirements confirmed after a significant change |
| NIST SP 800-53 Rev 5 | SP 800-53 SI-7 Software, firmware, and information integrity · SP 800-53 CM-5 Access restrictions for change |
A result shows the frameworks you tick; SOX 404 brings COBIT and AS 2201 with it. PCI DSS clauses show on the cardholder systems only.
SOX 404 ITGC IT General Controls (ITGC) - Access, Change, OperationsThe clause text
ITGC including access management, change management, computer operations, program development, backup, recovery.
Source: SOX 404 / ICFR
AS 2201 ¶22-27 Entity-level controls and the period-end process, including IT general controlsWhat the external auditor does under this standard (context, not a reading of your rows):
What the auditor does under it
Entity-level controls, period-end. Requirements include (a) evaluate Entity-Level Controls including control environment, risk assessment, monitoring, information, communication, COSO components, (b) evaluate the Period-End Financial Reporting Process including procedures used to enter transactions, initiate, authorise, record, process, report period-end financial information, (c) consider IT general controls, IT application controls, (d) consider management override, tone at the top, governance, ethics, (e) document evaluation including significant findings, conclusions, (f) determine extent, nature of further testing based on entity-level conclusions.
Source: PCAOB AS 2201
COBIT BAI06.03 Track and report change statusThe clause text
A tracking and reporting system documents rejected changes and communicates the status of approved, in-process and complete changes, and approved changes are implemented as planned: requests are categorised in tracking (rejected, approved not yet initiated, approved and in process, closed); status reports with performance metrics let management review detailed status and the overall state such as aged analysis; open changes are monitored so approved changes close in a timely fashion by priority; and a tracking and reporting system covers all change requests.
Where it usually falls short: Approved changes that stay open indefinitely with nobody chasing them
Source: COBIT 2019
COBIT BAI10.03 Maintain and control configuration itemsThe 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.
Where it usually falls short: Repository that describes the environment as it was months ago
Source: COBIT 2019
SOC 2 CC7.1 Detection and monitoring procedures for security events are in placeNamed, not quoted: the criteria text is not held in full here.
Where it usually falls short: Configuration monitored at build only, so drift introduced afterwards is never detected; Scanning performed quarterly against an environment that changes daily
Source: SOC 2 (Trust Services Criteria)
ISO 27001 8.9 Configuration managementThe clause text
Establish, document, implement, monitor and review secure configurations for hardware, software, services and networks.
Where it usually falls short: Outdated baselines; Missing change approvals
Source: ISO/IEC 27001:2022
ISO 27001 8.19 Installation of software on operational systemsThe clause text
Securely manage software installation on production systems.
Where it usually falls short: Missing formal approval for installations; No evidence of post‑install verification
Source: ISO/IEC 27001:2022
PCI DSS 6.5.2 Requirements confirmed after a significant changeAfter a significant change, the applicable PCI DSS requirements are confirmed in place on the new or changed systems and the documentation is updated.
A one-line statement; the standard's own text is not quoted here.
Source: PCI DSS v4.0
SP 800-53 SI-7 Software, firmware, and information integrityThe 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.
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
SP 800-53 CM-5 Access restrictions for changeThe 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.
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