Change Management Controls

1. Why Change Management Controls Matter

Every organisation changes constantly: new software releases, infrastructure upgrades, process redesigns, organisational restructures, regulatory updates and strategic shifts. Each change introduces risk. Poorly controlled change is one of the most common root causes of system outages, data corruption, security breaches, financial misstatements and compliance failures. For the CRMA candidate, change management controls sit squarely within the domain of Evaluating Risk Management Processes because they are the mechanism by which an organisation ensures that risk is identified, assessed and treated before a change is made, rather than discovered painfully afterwards.

From a risk management assurance perspective, change management controls are important because they:
- Protect the integrity, availability and confidentiality of systems and data.
- Preserve the reliability of financial reporting (unauthorised changes to applications or databases can directly alter financial figures).
- Ensure regulatory and contractual compliance (e.g., SOX, GDPR, PCI DSS, Basel requirements all expect controlled change).
- Prevent unauthorised or fraudulent modifications by enforcing segregation of duties.
- Provide an audit trail that allows management, auditors and regulators to reconstruct what was changed, when, why and by whom.
- Support the organisation's risk appetite by ensuring changes do not silently alter the risk profile.

In the IIA framework, the internal audit activity must evaluate the effectiveness and contribute to the improvement of risk management processes (IIA Standard 2120). Change management is a classic example of a process the auditor evaluates to determine whether management has designed and operated controls that keep risk within acceptable limits.

2. What Are Change Management Controls?

Change management is the structured, formal process through which an organisation requests, evaluates, authorises, tests, implements, documents and reviews changes to its systems, infrastructure, applications, processes or organisational arrangements. Change management controls are the specific policies, procedures and mechanisms embedded in that process to ensure changes are:
- Authorised: approved by appropriate management before work begins and before deployment.
- Assessed: evaluated for risk, impact, cost and benefit.
- Tested: validated in a non-production environment before release.
- Documented: recorded with sufficient detail to support traceability and accountability.
- Segregated: developed, tested and deployed by different individuals to prevent one person from pushing unauthorised code or configuration into production.
- Reviewed: subject to post-implementation review to confirm the change achieved its objective and introduced no adverse effects.

Change management applies to several change categories that exam questions frequently distinguish:
- IT changes: application code, database schemas, operating systems, network configurations, security parameters, cloud settings.
- Business process changes: new workflows, control redesign, outsourcing arrangements.
- Organisational changes: restructuring, mergers, new reporting lines, key personnel turnover.
- Strategic and regulatory changes: new products, market entry, adoption of new standards.

The CRMA exam most commonly focuses on IT change management because it is the most concrete and testable, but the underlying principles (authorisation, assessment, testing, segregation, documentation, review) apply to all change types.

3. How Change Management Controls Work: The Lifecycle

A mature change management process typically follows these stages. Learn them in order and understand the control objective of each.

Stage 1 – Change Request (Initiation)
A formal change request is raised, usually through a ticketing or change management system. The request documents the business justification, scope, systems affected, requestor and proposed timing. Control objective: ensure all changes are formally captured and traceable; no undocumented or verbal changes.

Stage 2 – Risk and Impact Assessment
The change is analysed for its potential effect on operations, security, data integrity, downstream systems, controls and compliance. Risk is rated (e.g., low, medium, high) and this rating drives the level of scrutiny and approval required. Control objective: changes are understood before they are approved; high-risk changes receive proportionately greater oversight.

Stage 3 – Authorisation and Approval
Appropriate management (often a Change Advisory Board or CAB for significant changes) reviews and approves or rejects the change. Approval should come from both the business owner and the technical owner. Control objective: only legitimate, prioritised and acceptable-risk changes proceed; approvals are evidenced.

Stage 4 – Development and Build
The change is developed in a development environment separate from production. Version control systems track code changes. Control objective: production is not affected by work in progress; a history of modifications is maintained.

Stage 5 – Testing and Quality Assurance
The change is tested in a test or staging environment that mirrors production. Testing includes unit, integration, regression, security and user acceptance testing (UAT). Test results are documented and sign-off is obtained from business users. Control objective: the change works as intended and does not break existing functionality or controls.

Stage 6 – Implementation Approval and Scheduling
Separate from the initial approval, a release approval confirms that testing is complete and the change can be moved to production. Changes are scheduled during agreed maintenance windows to minimise disruption. A rollback or back-out plan is prepared. Control objective: deployment is deliberate, timed and reversible.

Stage 7 – Migration to Production
The change is moved into the live environment by someone other than the developer, enforcing segregation of duties. Access to migrate changes to production is restricted to a small group of authorised personnel, and developers should not hold production write access. Control objective: no individual can both write and deploy code, preventing unauthorised or malicious changes.

Stage 8 – Post-Implementation Review
After deployment, the change is monitored and reviewed to confirm it achieved the intended outcome, did not cause incidents and that documentation is complete. Lessons learned feed back into the process. Control objective: the organisation verifies effectiveness and continuously improves.

Emergency Changes
Not all changes can wait for the full cycle. Emergency changes (e.g., fixing a critical outage or security vulnerability) are permitted to bypass some steps, but they must still be controlled: approval from a designated emergency authority, documentation, and retrospective review and approval by the CAB within a defined period. Exam questions love this area: the key point is that emergency changes are expedited, not exempt. A high volume of emergency changes is itself a red flag suggesting the normal process is being circumvented.

Standard (Pre-Approved) Changes
Low-risk, repetitive, well-understood changes (e.g., routine patching, password resets, adding a standard user account) may be pre-authorised as standard changes, following a documented procedure without CAB review for each instance. This is a legitimate efficiency, provided the categorisation itself is controlled.

4. Key Controls and What They Protect Against

- Formal change policy and procedures: establish expectations and accountability; protects against ad hoc, inconsistent handling.
- Change request logging in a system of record: protects against untracked changes.
- Risk-based classification: ensures effort is proportionate; protects against over-controlling trivial changes and under-controlling critical ones.
- Documented approvals before development and before release: protects against unauthorised changes.
- Separate development, test and production environments: protects against untested code reaching live systems.
- Independent testing and UAT sign-off: protects against functional and control failures.
- Segregation of duties between developers and those who migrate to production: protects against fraud and unauthorised code.
- Restricted and logged production access: protects against direct, uncontrolled modification of live systems and data.
- Version control and configuration management: protects against loss of history and configuration drift.
- Back-out / rollback plans: protects availability if a change fails.
- Automated monitoring and reconciliation of changes: compares actual changes detected in production (e.g., via file integrity monitoring or configuration scanning) against approved change tickets, detecting unauthorised changes.
- Post-implementation review and metrics: protects against repeated failures and supports continuous improvement.

5. How Internal Auditors and Risk Assurance Professionals Evaluate Change Management

When evaluating change management as part of risk management processes, the auditor assesses both design and operating effectiveness:

Design evaluation: Does a policy exist? Does it cover all change types and environments? Are roles and responsibilities (requestor, approver, developer, tester, implementer) defined? Is there a CAB or equivalent? Is there an emergency change procedure? Are environments segregated? Are approval thresholds risk-based?

Operating effectiveness testing: The auditor typically selects a sample of changes from the change management system and traces each through the lifecycle, verifying: request documented, risk assessed, approval evidenced and dated before work started, testing performed and documented, UAT sign-off, release approval, implemented by an authorised person other than the developer, post-implementation review completed.

Critically, the auditor also performs a reverse test: obtain a system-generated list of all changes actually made to production (from logs, version control, or configuration monitoring) and trace them back to approved change tickets. Forward testing (ticket to production) confirms approved changes were handled properly; reverse testing (production to ticket) detects unauthorised changes. Exam questions often test whether you understand that reverse testing is necessary to identify changes that bypassed the process.

Other audit procedures include reviewing production access lists against HR records and job roles, reviewing emergency change volumes and trends, inspecting CAB minutes, interviewing developers and operations staff about actual practice (which may differ from policy), and reviewing incident data to identify change-related failures.

6. Common Weaknesses and Red Flags

- Developers with direct access to production.
- Changes approved after implementation rather than before.
- Same person requesting, approving and implementing.
- Testing performed in production because no test environment exists.
- Missing or incomplete change documentation; approvals obtained by email with no record in the system.
- Excessive use of emergency changes to avoid the normal process.
- No reconciliation between actual production changes and approved tickets.
- Shared or generic administrator accounts that obscure who made a change.
- Vendor or outsourced provider changes not subject to the organisation's change process.
- Cloud and SaaS configuration changes outside the traditional change process.
- No rollback plan; repeated change-related incidents.
- Policy exists but staff are unaware of it or routinely circumvent it (a culture problem, which is a risk management governance issue).

7. Linking Change Management to the Risk Management Framework

For CRMA purposes, connect change management to broader frameworks:
- COSO ERM: change management supports the principles of identifying and assessing risk, implementing risk responses, and reviewing substantial change. COSO explicitly identifies that organisations must assess changes that could significantly affect the system of internal control.
- ISO 31000: change management operationalises risk identification and treatment and embodies the principle that risk management is dynamic and responsive to change.
- COBIT: contains a dedicated management objective for managing changes (BAI06) and managing IT change acceptance and transitioning (BAI07).
- ITIL: provides the widely used change enablement practice, including the concepts of standard, normal and emergency changes and the CAB.
- IIA Standards: Standard 2120 requires evaluation of risk management effectiveness; Standard 2130 requires evaluation of controls; the Three Lines Model positions management as owning the change process, risk/compliance functions as overseeing it, and internal audit as providing independent assurance.

8. How to Answer Exam Questions on Change Management Controls

CRMA questions are typically scenario-based and ask you to identify the best control, the biggest risk, the most appropriate audit procedure, or the most significant deficiency. Use the following approach:

Step 1 – Identify the stage of the lifecycle the question is about. Is it about initiation, approval, testing, deployment, or review? The correct answer usually relates to the control objective of that specific stage.

Step 2 – Identify the control objective being threatened. Ask: is the risk unauthorised change, untested change, undocumented change, or a segregation-of-duties failure? The best answer directly addresses that specific objective.

Step 3 – Prefer preventive and independent controls. When asked for the most effective control, approval before implementation and segregation of duties generally outrank after-the-fact reviews. When asked for the most effective detective control, look for reconciliation of production changes to approved tickets or monitoring/logging.

Step 4 – Distinguish management's role from internal audit's role. Internal audit evaluates and recommends; it does not approve changes, sit on the CAB as a voting member, or design the system. If an answer has internal audit performing a management function, it is usually wrong because it impairs independence.

Step 5 – Think risk-based. Answers that apply identical heavy controls to every change regardless of risk are rarely best. Answers that calibrate approval and testing to the risk of the change usually are.

Step 6 – Watch the direction of testing. If the question concerns detecting unauthorised changes, the answer involves starting from production evidence and tracing back to approvals (reverse testing), not starting from approved tickets.

Exam Tips: Answering Questions on Change Management Controls

- Segregation of duties is the most frequently tested concept. If a scenario mentions a developer who can move code into production, the most significant deficiency is almost always the segregation issue, regardless of other distractors.
- Approval must precede implementation. Any answer describing approval obtained after the change was made indicates a control failure, unless it is a properly documented emergency change with timely retrospective review.
- Emergency changes are expedited, never exempt. They still require documentation, approval by a designated authority and post-event review. A rising trend in emergency changes signals process circumvention.
- Testing must occur outside production. Testing in the live environment is a deficiency.
- Documentation equals evidence. If it is not documented, from an audit perspective it did not happen. Answers that rely on verbal assurance are weak.
- For detecting unauthorised changes, choose reverse tracing or automated monitoring (compare actual production changes to approved tickets), not reviewing approved tickets alone.
- Distinguish design from operation. A documented policy is design; a sample of changes showing consistent compliance is operating effectiveness. Questions asking about operating effectiveness require testing actual transactions.
- Remember the Three Lines Model. Management owns change management; internal audit provides independent assurance. Do not select answers where internal audit approves changes or chairs the CAB.
- Beware the plausible but overbroad answer. Options such as implement additional controls or improve training may be true but rarely address the specific risk in the scenario. Select the answer most directly tied to the identified weakness.
- Consider the risk consequence named in the question. If the question stresses financial reporting, link to application controls and data integrity. If it stresses availability, link to testing and rollback. If it stresses fraud, link to segregation of duties and access.
- Watch for outsourced or cloud scenarios. The organisation remains accountable; vendor changes should be governed by contractual change clauses, SOC reports and the organisation's own oversight. Lack of visibility over provider changes is a risk management gap.
- Use elimination. Discard answers that (a) violate segregation of duties, (b) place internal audit in a management role, (c) approve after the fact without emergency justification, or (d) ignore risk-based proportionality. The remaining option is usually correct.
- Read qualifiers carefully. Words such as most, best, primary, first and greatest signal that several options may be partly correct; you must select the one that most directly satisfies the control objective or addresses the highest risk.

9. Quick Revision Summary

Change management controls ensure that changes to systems, processes and organisations are requested, assessed, authorised, tested, deployed and reviewed in a controlled manner. The core control objectives are authorisation, risk assessment, testing outside production, segregation of duties, restricted production access, documentation, rollback capability and post-implementation review. Emergency changes follow an expedited but still controlled path. Internal auditors evaluate design through policy and procedure review and operating effectiveness through sampling changes forward from ticket to production and backward from production to ticket. In the exam, anchor every answer to the specific lifecycle stage, the control objective at risk, preventive over detective where effectiveness is asked, independence of internal audit, and risk-based proportionality.