SOX Change Log Checker
Change type

Normal changes: what the auditor reads in them

A normal change goes through the full route: a request, an impact assessment, an approval by someone other than the author, testing, then a scheduled deploy. It is the population an auditor samples most, and the rows where approvals are missing, late or from the author show first here.

How the checker recognises them

Read from the change type column: normal, regular, planned, major or minor.

Findings they raise most often

The clauses that speak to them

4 clauses
COBIT BAI06.01 Evaluate, prioritize and authorize change requests
The clause text

All requests for change are evaluated to determine their impact on business processes and I&T services and to assess whether the change will adversely affect the operational environment and introduce unacceptable risk, and changes are logged, prioritised, categorised, assessed, authorised, planned and scheduled: formal change requests let process owners and IT request changes to processes, infrastructure, systems or applications, with all changes arising only through the change management process and pre-screened for standard changes; requests are categorised (business process, infrastructure, operating systems, networks, applications, packaged software) and related to affected configuration items; they are prioritised on business and technical requirements, resources and legal, regulatory and contractual reasons; each change is formally approved by process owners, service managers and IT technical stakeholders as appropriate, with low-risk frequent changes pre-approved as standard; approved changes are planned and scheduled; every request is evaluated in a structured way with impact analysis on processes, infrastructure, systems, applications, continuity plans and service providers so that all affected components are identified; and the effect of contracted providers on change management is considered, including integration of their processes into the enterprise's.

Evidence an auditor expects: Change log with categorisation, prioritisation, impact analysis and approvals; standard change catalogue
Where it usually falls short: Changes made outside the process by administrators with direct access; Impact analysis that ignores the continuity plan and outsourced components
Source: COBIT 2019
COBIT BAI07.05 Perform acceptance tests
The clause text

Changes are tested independently according to the defined test plan before migration to the live environment: the categorised log of errors found by the development team is reviewed to verify remediation or formal acceptance; final acceptance is evaluated against the success criteria and results are presented understandably to process owners and IT for an informed decision; acceptance is approved with formal sign-off by process owners, third parties as appropriate and IT stakeholders before promotion; testing follows the plan and is designed and conducted by a test group independent from the development team; tests and expected outcomes follow the plan's success criteria; scripted test instructions are assessed and approved by the independent group; an appropriate balance of automated and interactive user testing is used; security tests measure weaknesses and consider security incidents since the plan was written; performance tests cover a range of metrics such as end-user response times and database update performance; fallback and rollback elements of the plan are addressed; and errors are identified, logged and classified with an audit trail of results and communication per the plan.

Evidence an auditor expects: Independent acceptance test results against success criteria; error log with remediation or acceptance; formal sign-off before promotion
Where it usually falls short: Acceptance signed off with significant errors still open; Testing performed by the developers who built the change
Source: COBIT 2019
SOC 2 CC8.1 Change management processes are in place

Named, not quoted: the criteria text is not held in full here.

Evidence an auditor expects: The change management process covering infrastructure, data, software and procedures, including the emergency change route; Change records for the period showing design, development or acquisition, configuration, documentation, testing, approval and implementation; Evidence of segregation between those who develop, approve and implement changes; Testing evidence per change proportionate to its risk, including security testing where relevant; Evidence of rollback capability and of post implementation verification
Where it usually falls short: Emergency changes used routinely, with retrospective approval that is never withheld; Approval and implementation performed by the same person, so the approval is not independent
Source: SOC 2 (Trust Services Criteria)
ISO 27001 8.32 Change management
The clause text

Put changes to facilities and systems through change management procedures.

Evidence an auditor expects: Change requests; Change approvals; Implementation testing; Post implementation reviews
Where it usually falls short: Missing formal approval; No rollback plan documented
Source: ISO/IEC 27001:2022

Other change types

Run the specimen Check your own change log