Skip to main content
Change Risk Intel
Section

Compliance

Change control becomes defensible when a reviewer can trace a production decision from request through approval, implementation, and exception handling.

Compliance coverage treats the change record as evidence, not as paperwork generated after the fact. An auditor is usually trying to establish whether a control operated consistently, whether the people approving a change had appropriate authority, and whether the organization can explain departures from its procedure. A ticket with a closed status does not answer those questions by itself. The useful record ties the change to its affected system, stated risk, testing, approvers, execution evidence, and any emergency rationale.

SOX ITGCs, SOC 2 Trust Services Criteria, PCI DSS, DORA, and NIS2 do not create one interchangeable checklist. They place different emphasis on access, resilience, incident handling, third parties, and governance. The common work is translating those expectations into a change process that matches the organization actually operating the services. That includes segregation of duties where it matters, approval paths that cannot be rewritten after execution, and retention of evidence that survives a tool migration or staff turnover.

Emergency changes expose the difference between a documented control and an operationally usable one. A patch or mitigation may need action before the ordinary meeting cadence, but urgency does not eliminate accountability. The record should show who accepted the risk, why the normal path could not be used, what was tested, and what follow-up review occurred. The same discipline applies when a supplier maintenance event or a regulatory reporting clock changes priorities. Good documentation explains the decision under the conditions that existed then, rather than reconstructing a cleaner version later.

This section is for teams aligning ITSM workflow with assurance work without pretending that a product configuration alone creates compliance. It explores the questions that surface during control walkthroughs: who can request, approve, deploy, and close; which evidence is system-generated; how exceptions are reviewed; and whether the stated process works for a real production incident.

Who this section is for

  • IT control owners — Control-to-workflow mappings that make approval and evidence requirements operational.
  • Internal audit teams — Concrete review questions for testing whether change controls actually operated.
  • Compliance leaders — Context for translating overlapping obligations without flattening their distinct requirements.

Questions this section answers

  • What change evidence satisfies an auditor without duplicating the implementation record?
  • How can segregation of duties work during an urgent production fix?
  • Which workflow controls demonstrate that approvals were timely and authorized?
  • How should DORA or NIS2 obligations influence emergency-change documentation?

Start here

How this section is reported

Our compliance reporting reads standards and regulatory material alongside the evidence generated by real ITSM workflows. We do not treat a framework name as proof of a working control. Articles distinguish stated requirements from reasonable implementation choices and pay particular attention to exceptions, approvals, access boundaries, and audit trails. When an issue involves a regulator or formal assurance scope, readers should validate application with their own counsel and assurance professionals.

All Compliance coverage