Compliance
Change records as auditable evidence: controls, approvals, testing, exceptions, and the operational facts regulators expect to reconstruct.
Compliance work becomes fragile when a control exists only as a policy sentence and not as a sequence of observable actions. Auditors and control owners need to trace a material change from request through authorization, implementation, testing, and closure, including the reason an exception was permitted. That makes the ITSM record more than a ticket: it is the bridge between SOX ITGCs, SOC 2 Trust Services Criteria, DORA resilience obligations, and the people who actually change systems. Security, internal audit, platform teams, and application owners often disagree about what counts as sufficient proof, especially when automated delivery replaces a familiar approval screen.
The articles in this collection focus on making that proof defensible without asking operators to manufacture it after the fact. They map control language to evidence sources such as peer review, segregation of duties, implementation logs, validation results, risk acceptance, and post-change review. They also address deadline-driven remediation, where a documented decision to defer or use compensating controls may matter as much as the patch itself. The practical question throughout is whether an independent reviewer can understand what changed, who accepted the residual risk, and why the control operated as designed. That standard exposes weak records early, while there is still time to correct the workflow rather than explain an avoidable gap.
Start here
-
SOC 2 Change Management Controls and Real Audit Questions
Anchors the collection in the evidence questions that expose whether a change-control process actually operates.
-
SOX Change Control Checklist Mapped to Your ITSM Workflow
Translates ITGC expectations into the workflow fields and approvals teams maintain every day.
-
DORA Change Management Checklist for Resilience Teams
Extends the evidence lens to operational resilience, testing, and third-party dependency decisions.
More on Compliance
-
This Week in Change Risk — Week of Aug 24, 2026
A CVSS-10.0 Oracle flaw with CISA's tightest three-day deadline, six more KEV entries, GitHub's outage pledge, and PagerDuty's SRE-agent drop.
-
The Compensating Controls Register Auditors Accept
You deferred a control and promised a compensating one. Here is the register entry that PCI, SOC 2, and NIST assessors sign off on instead of flagging.
-
This Week in Change Risk — Week of Aug 17, 2026
Eight new CISA KEV entries led by a critical VMware vCenter flaw, GitHub's near-8-hour outage post-mortem, and NIS2's October deadline closing in.
-
Risk-Based Patching: How to Defend It to an Auditor
You skipped a Critical CVSS because EPSS said low-risk. Here is the evidence trail that keeps a PCI, SOC 2, or SOX auditor satisfied.
-
This Week in Change Risk — Week of Aug 10, 2026
A CVSS 10 Metabase SQL injection in KEV with named victims, Microsoft's ~400-CVE August Patch Tuesday, and NIS2's October deadline closing in.
-
This Week in Change Risk — Week of Aug 3, 2026
A CVSS 9.8 JetBrains TeamCity RCE in KEV, two GitHub Actions outages in two days, Microsoft's Aug 11 Patch Tuesday, and NIS2 pressure this week.
-
NIS2 Incident Reporting: A 24/72/1-Month CAB Runbook
NIS2 Article 23 gives you 24 hours, 72 hours, and one month to report a significant incident. A CAB runbook for hitting all three deadlines.
-
This Week in Change Risk — Week of Jul 27, 2026
A CVSS 10.0 Arista SD-WAN flaw in KEV, a GitHub Copilot incident, Datadog's DASH launches, and the ECB's AI deadline — the week's change-risk signals.
-
CISA BOD 26-04: Risk-Based Patch Deadlines for CABs
CISA BOD 26-04 replaces the flat 14-day KEV clock with 3, 14, and 60-day risk-based deadlines. What change managers and CABs must rebuild by December.
-
This Week in Change Risk — Week of Jul 20, 2026
KEV batch of 6, a GitHub Actions outage, Datadog's AI incident tooling, and the NIS2 deadline confusion — the week's change-risk signals for CABs.