Systems development and change management determine how ideas become production technology and how production technology evolves without losing control. Auditors need to assess whether requirements include necessary controls, development is traceable, testing is appropriate, changes are authorized, deployments are reproducible, emergency work is governed, and completed changes deliver the intended business result. The objective is not to force one development methodology. It is to verify that risk remains controlled whether the organization uses agile teams, DevOps pipelines, packaged software, cloud services, or traditional projects.
The current CISA outline covers project governance, system-development methodologies, control design, implementation testing, configuration and release management, migration, data conversion, post-implementation review, and operational change management. The ISACA certifications connects those subjects to security management and enterprise risk. A strong audit follows the lifecycle from business need through production operation instead of treating “change management” as a single approval ticket.
Start with governance and control requirements
Development controls begin before code is written. Projects should have accountable sponsors, defined objectives, funding, scope, risk ownership, and criteria for success. The auditor should determine whether security, privacy, availability, auditability, data retention, and regulatory requirements are identified early enough to influence architecture rather than being added after implementation.
Requirements should be traceable from business need to design, test, and acceptance. If a critical control such as segregation of duties or encryption appears in a policy but cannot be traced into implementation and testing, the organization may have governance without execution. Traceability is particularly important for regulated systems where the organization needs to show why a control exists and how it was verified.
Project risk should be revisited as scope changes. Agile delivery can change priorities frequently, and cloud platforms can make new capabilities available mid-project. The control process should be flexible enough to incorporate change without allowing teams to bypass risk review because “the project was already approved.”
The risk perspective of CRISC is useful because development decisions should be evaluated against business risk, not only schedule and budget. A delayed feature and an untested access-control change may both affect the project plan, but they create very different enterprise consequences.
Governance should also define how security, privacy, resilience, and compliance requirements enter the backlog. When nonfunctional controls are treated as late review items, teams may discover constraints only after architecture and code are difficult to change. Traceability from requirement to test evidence reduces that risk.
Evaluate segregation of duties across the delivery pipeline
Traditional change processes separated developer, tester, approver, and production administrator roles physically. Modern pipelines automate many of those functions, but the control objective remains: one person should not be able to create, approve, deploy, and conceal a material change without independent oversight. Auditors should examine effective permissions across source control, CI/CD, cloud platforms, and production systems.
Branch protection, required review, deployment approvals, protected environments, and role separation can provide strong automated controls. The auditor should verify the settings and then test actual changes to confirm that bypass paths are not routinely used. Administrator privileges in the source-control platform can undermine several pipeline controls at once.
Small teams may not be able to achieve perfect separation. Compensating controls can include independent post-deployment review, strong logging, restricted production access, automated testing, and management review of high-risk changes. The auditor should evaluate whether the compensation addresses the same risk rather than merely documenting that staffing is limited.
Service accounts used by pipelines also require governance. If a build identity has unrestricted production administration and a nonexpiring secret, human segregation may be irrelevant because compromising the automation account bypasses the process entirely.
Separation can be enforced logically even when small teams wear multiple hats. Independent approval, protected branches, environment permissions, and immutable logs can create compensating controls. Auditors should evaluate the effectiveness of those controls rather than assuming organizational charts alone determine segregation.
Audit source control and code review as evidence
Version control provides a valuable audit trail when commits, pull requests, reviewers, approvals, and release tags are protected. Auditors can trace a production change back to the code change and determine who authored and reviewed it. That evidence is stronger when history cannot be rewritten casually and administrative actions are logged.
Code review should be risk-sensitive. A documentation change does not need the same scrutiny as authentication logic, payment processing, encryption, or infrastructure policy. The audit should determine whether high-risk components have appropriate review requirements and whether reviewers have enough expertise and independence to challenge the change.
Automated scanning can supplement human review. Static analysis, dependency checks, secret detection, infrastructure-policy validation, and license checks can detect classes of problems consistently. The security-development distinction discussed in DevOps, SecDevOps, and SecOps is useful because security controls are most effective when integrated into normal delivery rather than bolted on after release.
Exceptions to review should be visible. If administrators can merge directly during an outage, the process should record who used the override, why, what was changed, and what follow-up review is required. Emergency capability is not necessarily a weakness; invisible emergency capability is.
Code-review evidence should show that reviewers had enough context to challenge the change. Large pull requests, rubber-stamp approvals, or reviewers who authored most of the code may weaken the control. Review quality can be assessed through sampling of high-risk changes and the comments or requested revisions they produced.
Test CI/CD change authorization and deployment control
In automated environments, the deployment pipeline is part of the control system. Auditors should understand which event triggers deployment, which branch or artifact is trusted, which approvals are required, what tests must pass, and which identity executes the release. A change ticket that is approved while the pipeline can deploy unrelated code provides little assurance.
Artifact integrity should be preserved from build to production. Signed images, immutable build outputs, artifact repositories, provenance records, and deployment references can reduce the risk that tested code differs from deployed code. Rebuilding an artifact after approval may introduce unreviewed dependency changes even when the source commit is unchanged.
Deployment permissions should be narrower than general administration. A pipeline needs authority to release the application, not necessarily to change identity policy, disable logging, or modify unrelated infrastructure. Least privilege limits the impact of compromised CI/CD credentials.
Release controls should also support rollback. A safe change process can identify the previous known-good version, preserve database compatibility where necessary, and reverse a deployment without improvisation. The existence of rollback capability is especially important when release frequency is high.
Pipeline permissions should be audited like privileged infrastructure access. A user who can change build definitions, replace deployment credentials, or alter artifact sources may be able to bypass normal application review. Administrative rights over CI/CD tooling therefore belong in the change-control scope.
Audit configuration management and infrastructure changes
Modern systems contain significant behavior outside application code. Cloud resources, network rules, operating-system baselines, Kubernetes manifests, secrets configuration, feature flags, and SaaS settings can alter security or availability without a software release. The change population should therefore include infrastructure and configuration, not just application tickets.
Configuration-management concepts illustrated by Chef and Puppet show why declarative, repeatable configuration can strengthen auditability. Infrastructure as code can provide version history, peer review, automated testing, and reproducible deployment when the organization actually uses the controlled path.
Auditors should look for console drift: production changes made manually outside the managed configuration. Cloud configuration history, drift detection, or reconciliation tools can identify differences between declared and effective state. Frequent drift may indicate that the formal deployment path is too slow or incomplete.
Secrets and environment-specific values need separate controls. Storing credentials directly in configuration repositories can make an otherwise well-controlled change process unsafe. The audit should examine secret stores, access, rotation, and how deployment jobs retrieve sensitive values.
Infrastructure-as-code can improve auditability when repositories are authoritative and production changes flow through controlled pipelines. Direct console changes create configuration drift and should be detected. Auditors can compare deployed state to version-controlled definitions to identify unauthorized or undocumented changes.
Verify testing, readiness, migration, and data conversion
Testing should demonstrate that both functional and control requirements work before production. Unit, integration, security, performance, resilience, user-acceptance, and migration tests may all be relevant depending on the system. The auditor should determine whether test coverage reflects business risk rather than whether a team met an arbitrary percentage.
Test evidence should be tied to the version being deployed. Results from an earlier build do not provide assurance when material code or configuration changed afterward. High-risk defects that are deferred should have documented risk acceptance and ownership instead of disappearing into a backlog.
Data conversion requires special attention because a technically successful migration can still corrupt, omit, duplicate, or misclassify information. Reconciliation totals, record counts, control totals, exception reports, and business-owner validation can provide evidence that converted data is complete and accurate.
Implementation readiness should include operational concerns: monitoring, support documentation, backup, access, incident handling, capacity, and recovery. A system that passes user acceptance but has no monitoring or support owner is not truly ready for production.
Migration testing should include reconciliation and rollback criteria. Record counts, control totals, exception handling, and business-owner validation help establish that converted data is complete and accurate. A technically successful deployment is not sufficient if information is silently lost or transformed incorrectly.
Keep emergency changes controlled without making response impossible
Organizations need a faster path for urgent security fixes and production outages. The audit should verify that the emergency process is clearly defined, limited to genuine urgency, and subject to retrospective review. If most changes are labeled emergency, the standard process is not functioning.
Emergency changes should still be attributable. The organization should know who approved the action, who performed it, what systems changed, what testing was feasible, and what evidence was preserved. High-impact changes may require an incident commander or senior approver even when normal committee scheduling is impossible.
Post-change review is essential because some controls are intentionally compressed during an emergency. The review can verify documentation, testing, rollback outcome, root cause, and whether the temporary change should be incorporated into managed configuration or removed.
The organizational principles in change management are relevant because technical controls succeed only when people understand the process and trust it enough to use it under pressure. An unusable process drives shadow changes.
Emergency processes need defined exit conditions. Temporary privileges, feature flags, bypass approvals, and manual configuration should be removed or regularized after the incident. Post-event review can determine whether urgency was legitimate and whether the emergency path is being used to avoid normal governance.
Perform post-implementation review against the business case
Audit should not end when deployment succeeds. Post-implementation review asks whether the system delivered the promised capability, whether expected controls operate in production, whether costs and performance align with assumptions, and whether unresolved risks remain. It connects project governance to real operational outcomes.
Production evidence may contradict test results. Users may create workarounds, privileged roles may expand, integrations may behave differently under load, or monitoring may reveal failures that did not appear in test. Early operational review can identify these issues before they become accepted normal behavior.
The business case should also be revisited. A system may be technically sound but fail to deliver expected value or create unplanned maintenance burden. The auditor can assess whether benefits, costs, risks, and control obligations are being measured and owned.
Lessons from implementation should feed future projects. Repeated migration errors, approval bottlenecks, or testing gaps indicate process issues that deserve program-level remediation rather than a separate finding on every project.
Benefits realization should be supported by measurable evidence. Availability, cycle time, error rates, control exceptions, operating cost, or customer outcomes can show whether the implemented change achieved its objective. This keeps post-implementation review connected to the original business case.
Use metrics to judge whether change control actually works
Change-management metrics should reveal outcomes, not encourage teams to game the process. Useful measures include failed-change rate, rollback frequency, unauthorized changes, emergency-change percentage, approval bypasses, time to remediate critical vulnerabilities, configuration drift, and incidents caused by change. A high number of approved tickets does not prove good control.
The business value of structured change practices, discussed in effective change management, is strongest when the process enables safe delivery rather than simply slowing it. Auditors should look for evidence that controls reduce incidents while allowing teams to deploy at a cadence appropriate to the business.
Management should investigate patterns. Repeated emergency database changes may reveal inadequate testing; frequent pipeline bypasses may show that approval rules do not fit delivery; recurring rollback may indicate weak release criteria. Metrics are most valuable when they trigger root-cause analysis.
The information-security program lens of CISM reinforces that change controls are part of governance and operations. A mature environment can trace important production changes from requirement to code or configuration, review, test, authorization, deployment, monitoring, and final outcome. That traceability is the core evidence that systems are changing under control.
Metrics should be segmented by risk and change type. A low overall failure rate can hide repeated problems in critical systems or emergency releases. Trend analysis by application, team, severity, and root cause helps auditors see whether the control environment is improving or merely averaging away hotspots.
Remediation testing should verify that recurring causes are reduced, not simply reclassified in reporting.