Systems Development & Change Management

Why this topic matters

New systems and changes to existing ones are a major source of risk — a flawed change can corrupt financial data across every transaction. The 2026 Information Systems and Controls (ISC) blueprint added tasks on change management, so expect questions on the system development life cycle (SDLC), testing, conversion methods, development approaches, and change controls.

The system development life cycle

Phase	Key activities and controls
1. Planning and feasibility	Business case; economic, technical, operational, and schedule feasibility; project approval and governance (steering committee)
2. Requirements analysis	Gather and document user, business, security, and control requirements; users sign off
3. Design	System architecture, data design, interfaces, and built-in controls (input validation, audit trails, access roles) — cheaper to design in than to add later
4. Development or acquisition	Coding in a separate development environment, or selecting and configuring purchased software (vendor due diligence, contracts, escrow of source code)
5. Testing	Unit testing (individual modules) → integration testing (modules together) → system testing (whole system, including performance and security) → user acceptance testing (users confirm it meets their needs) — in a test environment with test data, never production
6. Implementation and conversion	Data conversion with reconciliations; training; go-live approval
7. Operation and maintenance	Ongoing support; changes follow change management; post-implementation review compares results with the original objectives

Conversion (cutover) methods

Method	Description	Risk and cost
Direct (plunge)	Switch off the old system and start the new one at once	Highest risk, lowest cost
Parallel	Run old and new systems together and compare results	Lowest risk, highest cost
Pilot	Implement in one location or unit first	Limits exposure
Phased	Implement module by module over time	Gradual; interfaces between old and new are needed

Data conversion controls: clean and map data first; reconcile record counts, control totals, and hash totals between old and new systems; have users review converted balances; keep the old data accessible.

Development approaches

Approach	Features	Control focus
Waterfall	Sequential phases; each is completed and approved before the next	Formal sign-offs at each gate; late discovery of problems is costly
Agile (for example, Scrum)	Short iterations (sprints) delivering working software; evolving requirements; close user collaboration	Controls must be built into each sprint — definition of done, testing, documentation, product owner approval
DevOps with continuous integration and continuous delivery	Development and operations collaborate; automated build, test, and deployment pipelines release frequently	Automated tests and approvals in the pipeline; segregation enforced by pipeline permissions; code review; audit logs of deployments
Rapid application development and prototyping	Quick working models refined with users	Prototypes must not become production systems without full testing

Change management

Every change to production — code, configuration, database structure, infrastructure, or patches — should follow a controlled process:

1. Request documented with the business reason.
2. Impact and risk assessment, including effects on financial reporting and security.
3. Authorization by the business owner (and a change advisory board for significant changes).
4. Development in a non-production environment with version control.
5. Testing, including user acceptance, with documented results.
6. Approval to deploy, independent of the developer.
7. Migration to production by someone other than the developer (or an automated, controlled pipeline), with a back-out plan.
8. Post-implementation verification and documentation.

Emergency changes

Urgent fixes may bypass normal steps, but must be logged, limited to authorized people, and reviewed and approved after the fact promptly.

Supporting controls

• Separate environments — development, test, and production — with developers denied write access to production.
• Configuration management — a baseline of approved settings, with monitoring for unauthorized changes.
• Patch management — inventory systems, assess and test vendor patches, deploy based on risk, and track exceptions.
• Detective review — compare production change logs to approved change tickets to catch unauthorized changes.

How it is tested

• Order SDLC phases and match activities to phases.
• Choose a conversion method given risk and cost.
• Identify controls in agile and DevOps environments.
• Identify change management weaknesses and compensating controls.