Change Management Processes for Regulated Systems (ITIL, SOX)

Change management for regulated systems must satisfy both operational and audit requirements. SOX Section 404 (Management Assessment of Internal Controls) requires that IT General Controls (ITGCs) covering change management are effective, as changes to financial systems without proper approval and testing can invalidate the integrity of financial reporting. PCAOB AS 2201 (Auditing Standard on Internal Control) requires external auditors to assess the design and operating effectiveness of change management controls for in-scope IT systems. PCI DSS v4.0 Requirement 6.5 requires documented change control processes that include documentation of the security impact of changes, testing for compliance with PCI DSS requirements, and approval by authorized personnel. DORA Article 9(4)(d) requires change management as a component of ICT project and change management. ITIL 4 (IT Infrastructure Library) provides the process framework most widely adopted in regulated financial and healthcare organizations, defining change types (standard, normal, emergency) and the Change Advisory Board (CAB) governance mechanism.

A compliant change management process for regulated systems has seven stages: (1) Change request (RFC) creation with required fields including business justification, risk assessment, affected systems, testing evidence, and rollback plan. (2) Impact assessment reviewing dependencies, change windows, and regulatory scope (does the change affect CDE, ePHI systems, or financial reporting systems?). (3) CAB approval — normal changes require CAB review; emergency changes require post-implementation review with documented business justification. (4) Pre-implementation testing in a representative test environment with documented test results and sign-off. (5) Implementation within the approved change window by authorized personnel with separation of duties (developers must not promote their own code to production — SOX ITGC requirement). (6) Post-implementation validation confirming the change achieved its objective and no unexpected impacts occurred. (7) Change closure with documentation archived for audit. ITSM platforms (ServiceNow, Jira Service Management, BMC Helix) provide workflow automation for all seven stages with audit trail generation.

The separation of duties requirement in change management is a critical SOX ITGC control that many DevOps organizations struggle to implement without slowing release velocity. The traditional model — developer writes code, separate change manager approves, separate operations team deploys — conflicts with CI/CD pipeline models where the same team develops and deploys. The resolution is a four-eyes principle implemented in the deployment pipeline: code must be reviewed and approved by a peer who did not write it (pull request approval in GitHub/GitLab with branch protection rules), and production deployment must be triggered by an automated pipeline rather than manual developer action, with the deployment approval recorded in the ITSM system. This "DevOps-compatible change management" model satisfies SOX ITGC requirements when supported by immutable pipeline execution logs and ITSM-linked deployment records that auditors can inspect.

We design change management processes for regulated environments that satisfy SOX ITGC, PCI DSS, and DORA requirements while supporting modern CI/CD pipelines. Our implementations integrate ITSM workflow automation with source control branch protection, automated deployment pipelines with ITSM-linked approval gates, and audit-ready reporting dashboards for external auditor review.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.