No ticket reference: what the rows show and the clause behind it
The change shipped with no ticket or change reference on the row, so the request, its reason and its impact assessment cannot be followed from the export.
Does every pull request need a ticket reference for SOX?
The clauses ask for what a ticket carries: COBIT BAI06.01 has formal change requests logged, categorised and assessed, BAI06.04 has each change documented and closed, PCI DSS 6.5.1 asks for the reason and the security impact, and NIST SP 800-53 CM-3 has change decisions documented. A reference on the row is how an auditor follows a change back to its request. The checker lists the shipped changes with the reference column empty; when the export has no reference column at all, it says so instead.
The question the auditor is likely to ask
walkthrough packWhere are the request, the reason and the impact assessment for this change?
The clause behind it
8 clauses in 6 frameworks| Framework | The clause behind it |
|---|---|
| SOX 404 / ICFR | SOX 404 ITGC IT General Controls (ITGC) - Access, Change, Operations |
| COBIT 2019 | COBIT BAI06.01 Evaluate, prioritize and authorize change requests · COBIT BAI06.04 Close and document the changes |
| SOC 2 (Trust Services Criteria) | SOC 2 CC8.1 Change management processes are in place |
| ISO/IEC 27001:2022 | ISO 27001 8.32 Change management |
| PCI DSS v4.0 | PCI DSS 6.5.1 Change control procedures in production |
| NIST SP 800-53 Rev 5 | SP 800-53 CM-3 Configuration change control · SP 800-53 CM-9 Configuration management plan |
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
COBIT BAI06.01 Evaluate, prioritize and authorize change requestsThe 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.
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 BAI06.04 Close and document the changesThe clause text
Whenever changes are implemented, the solution, user documentation and procedures affected by the change are updated: documentation changes are included in the management procedure, including business and IT operational procedures, continuity and disaster recovery documentation, configuration information, application documentation, help screens and training materials; an appropriate retention period is defined for change documentation and pre- and post-change system and user documentation; and documentation is subjected to the same level of review as the change itself.
Where it usually falls short: Recovery documentation describing the system as it was before the change
Source: COBIT 2019
SOC 2 CC8.1 Change management processes are in placeNamed, not quoted: the criteria text is not held in full here.
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 managementThe clause text
Put changes to facilities and systems through change management procedures.
Where it usually falls short: Missing formal approval; No rollback plan documented
Source: ISO/IEC 27001:2022
PCI DSS 6.5.1 Change control procedures in productionChanges to system components in production follow a set procedure that records the reason for the change, its security impact, a documented approval, testing and a way back.
A one-line statement; the standard's own text is not quoted here.
Source: PCI DSS v4.0
SP 800-53 CM-3 Configuration change controlThe clause text
Requires the types of change that fall under configuration control to be defined, proposed changes to be reviewed and approved or rejected with explicit consideration of security and privacy impact, decisions and implemented changes to be documented, change records to be retained for a defined period, and change activity to be monitored and reviewed by the responsible body.
Where it usually falls short: Emergency changes bypass approval and are never retrospectively documented; Impact analysis recorded as a tick box with no security reasoning behind it
Source: NIST SP 800-53 Rev 5
SP 800-53 CM-9 Configuration management planThe clause text
Requires a configuration management plan for the system that sets out roles, responsibilities and processes, establishes how configuration items are identified and managed across the development life cycle, names the configuration items placed under management, is reviewed and approved by defined personnel, and is itself protected from unauthorized disclosure and modification.
Where it usually falls short: Plan describes a process that the delivery teams do not follow; Configuration items never formally identified, so the plan has no subject
Source: NIST SP 800-53 Rev 5