Research by Gartner, the IT Process Institute, and IDC consistently finds that 80% of unplanned IT outages are caused by people and process failures — and more than half of those are triggered directly by changes, configurations, and releases. Not by hardware failures or cyberattacks. By a missed rollback plan, a change applied without CAB approval, a post-implementation review that never happened. The change was known. The process just wasn’t followed.
CheckFlow gives every IT change a structured, pre-built checklist: RFC documentation before it starts, risk assessment and rollback plan required before approval, step-by-step implementation checklist during execution, and a mandatory post-implementation review when it’s done. Every step timestamped, every approver named, every change permanently documented — for SOX audit trails, ISO 27001 Annex A controls, and DORA requirements.
“We had a production incident caused by a change that skipped our normal review process — someone just pushed it through because it looked simple. After that we made CheckFlow mandatory for every change. No change gets implemented without a completed checklist. We haven’t had a change-related incident since.”
- Head of IT Operations, SaaS Company
“Our SOX audit required evidence that every change to financial systems had gone through formal review and approval. We had a paper trail of sorts but it was inconsistent. CheckFlow gave us a clean, timestamped record for every change — who proposed it, who approved it, when it was implemented, and the post-implementation confirmation. Auditor was satisfied on day one.”
- IT Director, Listed Financial Services Company
“80% of unplanned IT outages are caused by people and process failures — more than half triggered by changes, configurations, and releases”
— Gartner / IT Process Institute / IDC
“IT downtime costs an average $14,056 per minute — $23,750 per minute at large enterprises”
— EMA Research / BigPanda 2024
Most change-related outages don’t happen because the engineer didn’t know how to make the change. They happen because one step was skipped, one assumption wasn’t verified, one approval was bypassed “just this once.” The rollback plan wasn’t written down. The testing environment wasn’t equivalent to production. The post-implementation review got skipped because the change “went fine.” The record says it was approved. It doesn’t say when, or by whom. These aren’t competence failures. They’re process failures — and they’re preventable.
The change started at midnight. An hour in, something isn’t right. The engineer starts improvising a rollback. The plan existed in someone’s head — or didn’t exist at all. Requiring a documented rollback plan before a change is approved, not during the incident, is one of the single highest-value steps in any change management process.
The change looked low-risk. The CAB wasn’t meeting until next week. The business needed it done today. So it happened without approval. The change went fine — this time. The problem is that “it looks low-risk” is exactly what engineers say about the changes that cause outages. Enforcement requires a system, not trust.
The change went live. It worked. The ticket was closed. Nobody reviewed whether the documentation needed updating, whether monitoring was correct, whether the CMDB reflected the new state. Six months later the same change is applied in a different context and fails — because the lessons from the first time were never captured.
Senior engineers do thorough pre-implementation reviews. Junior engineers follow whatever they saw someone else do. Emergency changes skip all documentation. The process exists in a wiki page nobody reads. Consistent execution requires a checklist that runs for every change — regardless of who’s doing it.
The system goes live on Monday. Half the managers weren’t briefed. Training wasn’t confirmed completed before go-live. Adoption support wasn’t in place. The technology worked. The change management failed. Sustainable adoption requires the same structured process discipline on the people side as on the technical side.
SOX requires a 7-year audit trail for changes to financial systems. ISO 27001 Annex A 8.32 requires formal change management procedures with documented records. DORA requires evidence of change risk assessment and approval for ICT systems. “We have a change management process” isn’t evidence. Timestamped, named records are.
One checklist per change type. Pre-implementation, implementation, and post-implementation — all documented automatically.
Define the steps for each change type — standard, major, emergency. Pre-implementation: RFC documentation, risk assessment, rollback plan, CAB review, notifications. Implementation: step-by-step execution with go/no-go checkpoints. Post-implementation: service verification, incident monitoring, CMDB update, PIR. Build once; run for every change.
When a change is proposed, start the checklist. Each pre-implementation step must be completed before implementation can begin — including the rollback plan and approvals. During implementation, the engineer works through the sequenced steps. Every completed step is timestamped. Escalation points are built in. The change proceeds by procedure, not by memory.
When the change is complete, the record is already there: who proposed it, who approved it, when each step was completed, and the post-implementation review. SOX, ISO 27001, and DORA audit evidence is generated as a natural output of running the process correctly. No retrospective documentation. No scrambling before the audit.
CheckFlow isn’t an ITSM platform. It doesn’t replace ServiceNow or Jira Service Management. It’s the structured checklist execution layer for teams that need disciplined, documented change management without the complexity and cost of enterprise ITSM. Build your change checklists in CheckFlow, run them alongside your existing incident and ticketing tools, and generate a permanent, timestamped record for every change that touches your infrastructure.
Before any change touches production: RFC documented (change description, scope, affected systems, business justification), risk assessment completed (probability, impact, blast radius), rollback plan written and reviewed, implementation steps documented in full, CAB or approver sign-off obtained, change window confirmed with operations, pre-implementation checks completed. Every step required. Every step timestamped.
Learn MoreThe implementation checklist is the engineer’s guide during the change window: each step in sequence, communication checkpoints built in, go/no-go decision points before proceeding, rollback trigger condition defined. Engineers don’t work from memory — they work through the checklist. Steps are completed in order. Deviations are documented in real time, not reconstructed afterward.
Learn MoreThe PIR doesn’t get skipped because CheckFlow requires it as the final step: service verification completed, monitoring confirmed normal, CMDB updated to reflect the change, any incidents or anomalies during the window documented, lessons learned captured, record archived. Every change has an end state, not just a start state. The PIR is the documentation your SOX auditor, your ISO 27001 auditor, and your DORA examiner will ask for.
Learn MoreEmergencies require faster execution — but faster doesn’t mean undocumented. CheckFlow’s emergency change checklist captures the minimal but essential steps: the problem justifying emergency action, verbal approval obtained from the CAB chair or on-call manager, the change made, the service confirmed restored, and a retrospective review scheduled within 24 hours. Faster than the standard process, still documented, still auditable.
Learn MoreFor software deployments, process changes, and business transformation programmes: stakeholder mapping completed, executive sponsor confirmed, manager briefing delivered, training completed for all affected staff, helpdesk briefed and ready, go-live readiness confirmed by each team lead, post-go-live hypercare schedule in place, 30-day adoption check scheduled. The technical change is only half the work. The people side needs the same structured discipline.
Learn MoreEvery change run in CheckFlow produces a permanent, timestamped record: who proposed the change, who approved it, when each implementation step was completed, and the post-implementation review outcome. SOX requires 7-year retention for financial system change records. ISO 27001 Annex A 8.32 requires documented change management procedures and records. DORA requires evidence of ICT change risk assessment and approval. CheckFlow generates this evidence as the natural output of following the process.
Learn MoreDon’t start from a blank page. Pick a proven IT change management template, customise it to your environment, change types, and approval process, and run it for your next change in minutes. Each one is fully editable in the CheckFlow template designer.
The four phases of a complete IT change management process — and the steps that get skipped when speed beats process.
CheckFlow’s free change management templates cover IT pre-implementation, implementation, post-implementation, and organisational change — ready to run for your next deployment in minutes.
Get the Free Templates
ServiceNow and Jira Service Management are enterprise ITSM platforms — they manage the full IT service management lifecycle including incident management, problem management, change management, and asset management, typically at $130,000+ per year for ServiceNow or $10,000–50,000 per year for Jira Service Management. CheckFlow is the structured checklist execution layer for teams that need disciplined change management documentation without the complexity of an enterprise ITSM platform. Many teams use CheckFlow alongside an existing ITSM tool: the ITSM tracks the change ticket; CheckFlow runs the structured pre-implementation, implementation, and post-implementation checklist and creates the audit record.
Yes. IT change management (managing changes to infrastructure, software, and services) and organisational change management (managing the people side of technology or process adoption) are different disciplines but both benefit from structured checklists. CheckFlow is used for both. IT teams use it for RFC documentation, CAB approval tracking, implementation checklists, and post-implementation reviews. Operations and HR teams use it for organisational change readiness checklists, training completion tracking, manager briefing gates, and go-live readiness sign-offs. The page covers both use cases, with the technical IT change management content primary and organisational change management secondary — reflecting that IT change management is the larger search volume term.
SOX Section 404 requires evidence that changes to financial systems are subject to formal change management controls — request, risk assessment, approval, and documentation — with records retained for 7 years. Every change managed in CheckFlow automatically creates a timestamped, named record: who submitted the RFC, who approved it at CAB, when each implementation step was completed, and the post-implementation review. The complete change record is permanently stored, exportable as a PDF, and searchable by date, change type, system, or approver. This is the audit evidence SOX requires — generated as the natural output of following the process, not reconstructed after the fact.
Yes. ITIL change management distinguishes between standard changes (pre-approved, lower-risk, routine), major changes (higher-risk, requiring full CAB review), and emergency changes (urgent, requiring streamlined but documented approval). CheckFlow lets you build separate templates for each category. Standard changes get a lighter pre-implementation checklist with a single approver. Major changes get the full CAB review and documentation workflow. Emergency changes get a minimal but documented approval and a mandatory retrospective within 24 hours. Each change uses the appropriate template; all produce a complete audit record.
CheckFlow doesn’t have native integrations with ServiceNow, Jira, or Freshservice. Most teams run CheckFlow in parallel with their ticketing system: the ticket tracks the change request and incident management; CheckFlow runs the structured pre-implementation checklist, the step-by-step implementation guide, and the post-implementation review. The CheckFlow record is linked to the ticket in the relevant field. This gives you the structured execution discipline and audit trail of CheckFlow alongside the workflow management of your existing ITSM tool.
Yes. DORA, which became effective January 17, 2025, requires EU financial services firms to demonstrate operational resilience in their ICT change management processes — specifically, evidence of risk assessment and approval for changes to ICT systems, and documentation of the change management lifecycle. CheckFlow’s change management checklists create the RFC documentation, risk assessment, approval record, implementation log, and post-implementation review that DORA examiners look for. The permanent, timestamped record per change is the documentation DORA requires.
CheckFlow is $10 per user per month — priced on the number of engineers, managers, and approvers using the platform to manage and execute changes. A 10-person engineering team running change management through CheckFlow pays $100 per month. For comparison, ServiceNow averages $130,000+ per year in contract value; Jira Service Management for a team of 10 starts at around $800–2,000 per year but can scale significantly with additional features. CheckFlow is designed for the teams that need structured, auditable change management but don’t need (or can’t afford) a full ITSM platform.
Build the change management checklists that ensure every IT change has a documented rollback plan, a confirmed approver, a step-by-step implementation guide, and a post-implementation review — with a permanent audit trail for SOX, ISO 27001, and DORA.
