SDLC vs Change Management Controls: What Auditors Should Know

Software development life cycle (SDLC) and change management control frameworks play a critical role in mitigating risks in daily IT operations and large-scale IT projects. Within an organization’s change management policy should be governing principles and corresponding control frameworks that apply to the spectrum of smaller, routine IT initiatives through highly strategic, complex projects. Specifications related to common change management constraints (e.g., cost, scope, time, risk, resources, etc.) should be memorialized as guardrails for control owner tactical direction. Internal auditors need to understand when the different frameworks should be used and what types of controls make up the two frameworks.

SDLC is a structured approach defining a series of phases or stages a software project goes through from inception to deployment and often beyond covering hypercare and support. Change management controls ensure that any changes to existing software systems are properly tested and controlled to minimize risks (e.g., unauthorized or untested change, etc.).  

This article will define the two approaches and provide a perspective on when an organization should use SDLC or change management, so auditors know what to expect when they are in the field. 

When Should Auditors Use an SDLC Approach?

As a framework, SDLC provides a structure (e.g., formal stage gates and sign-off, executive steering, oversight, etc.) for organizing and managing software development activities such as planning, analysis, design, development, testing, deployment, and maintenance. SDLC helps ensure that the project team follows a consistent approach to software development, leading to smoother development processes, better quality software, and reduced costs. The use of SDLC is particularly important for large-scale software development projects where there is a need for a structured approach to ensure that the software is developed according to the requirements, on time, and within budget — for instance, acquisition of technology or new system functionality that could impact the organization’s critical risk and control compliance frameworks (e.g., SOX, HIPAA, GDPR/PII).

From an internal control perspective, SDLC provides a guide for managing risks associated with software development. Each phase of the SDLC is designed to identify and address potential risks to the project, such as project failure due to budget constraints, scope creep, missed milestones, or technical issues that could result in disrupted operations. By using SDLC, project teams can identify risks early in the project and develop appropriate mitigation strategies to minimize the impact of these risks. 

Auditors often play a critical role in enabling project governance within SDLC. They act as proactive risk and control advisors and provide assurance (i.e., pre-implementation reviews) over the SDLC plan by verifying the plan includes formal documentation on all relevant project milestones. These elements include but are not limited to evidence of a formal project charter and the establishment of an executive steering committee; a formal business blueprint (as is/to be analysis); technical requirements documented; evidence of integration and acceptance testing; formal end-user training; and go-live plan for cutover. 

Additionally, post-implementation reviews determine if the controls were applied and documented appropriately. A few high-risk areas include:

• All data conversions (e.g., master files, account balances, etc.) into the production environment were migrated accurately and completely
• Key reports were validated to ensure complete and accurate results
• Automated controls and approval workflows were tested to ensure a baseline of operating effectiveness. 

When Should Auditors Rely on Change Management Controls?

Change management controls are particularly important for managing changes to software systems that are already in use and for smaller-scale updates to the software. Change management controls guide project teams to ensure that any software system changes are properly tested, reviewed, and approved before deployment. These controls help to minimize the risk of introducing issues into the software system that could impact system security and performance, end-user experience, and the integrity (i.e., completeness and accuracy) of the data within a solution. 

An auditor’s objective (through a series of inquiry, observation, inspection, etc.) is to provide reasonable assurance that only appropriately authorized, tested, and approved changes are made to the applications, interfaces, databases, and operating systems that support key information technology solutions. 

Evidencing against the following change management risks is no easy feat:

• Unauthorized or unapproved changes are promoted to the production environment.
• Changes promoted to production are not functioning properly or according to user specifications.
• Key data/programs are intentionally or unintentionally modified.
• Inappropriate users have access to migrate changes into the production environment.

Change management controls may involve evidencing formal documentation to minimize the risk of inappropriate changes made in a production environment:

•  Identifying the need for a change through a ticketing system request.
• Assessing the impact of the change, 
• Testing the change in a controlled environment prior to the change release/migration 
• Obtaining approval for the change prior to the change release/migration and documenting the change completed.
• Evidence that logically the individual within the organization who performs the duty of programming the development or change is different from the individual who moves programs in and out of production. 

In today’s change management landscape with increasingly savvy engineer groups developing in state-of-the-art Platform as a Service (PaaS) environments, it’s important for an auditor to anchor their control evaluation in the four-eyes principle (at least two pairs of eyes on every change) to protect against unauthorized changes. Collecting evidence around a combination of traditional waterfall controls and agile-enabling systematic change management controls — such as protection rules enforcing peer review, automated CI/CD and smoke testing, and integrations between ticketing solutions and deployment solutions — may give an auditor comfort no one single individual may take a change from inception, to development, to production without proper authorization or testing. 

Auditors should use judgment when reviewing the situation to determine which controls would best mitigate the associated risk. 

Step 1: Choose SDLC or Change Management Controls 

Software implementations and software changes regularly occur in most organizations, and managers must choose between the two internal control approaches. IT projects related to existing software may have a large enough scope to warrant using an SDLC, or at least a hybrid, approach. Examples include a major system upgrade introducing significant features, onboarding new modules onto a platform, or an infrastructure change from on-premise to a cloud environment. The table below illustrates when using SDLC or change management controls would be more appropriate. 

Examples of When to Use SDLC or Change Management

• SDLC
  • New purchased software implementation
  • New homegrown software implementation
  • Implementing a new module in a platform
  • Major application upgrade (ex. v9 to v10)
  • Moving from on-premise to cloud 
• Change Management
  • Making configuration changes
  • Pushing minor code changes to production
  • Adding or changing role permissions
  • Minor application upgrade (ex. v9.1 to v9.2)
  • Connecting a reporting solution via an API 

Step 2: Implement Your Controls

Once you know which framework to use, the next step is to implement the right controls. While the controls may have a similar flow that covers the project from start to finish, the formality and intensity of the control will differ.

For example, a new system implementation is likely to include an oversight committee composed of department leaders who will be impacted by the application. That group will approve milestones and affect the direction of the system. On the other hand, stages in a software upgrade might be approved through a simple ticketing system. Here are examples of the controls you might use in both scenarios.  

Examples of SDLC and Change Management Controls

• SDLC
  • Establish an oversight committee
  • Create a project charter
  • Document system requirements
  • Secure the project budget
  • Define roles and responsibilities
  • Identify project risks and controls
  • Establish rollback and contingency plans
• Change Management 
  • Requiring change approvals
  • Using development and production environments
  • Granting temporary access for emergency changes
  • Checking code in and out of repositories
  • Segregation of duties
  • Peer review of changes
  • Controlling access with roles and specified permissions
  • Using automation to reduce human error
  • Back up and recovery processes
  • Update end users
  • Communicate new features

Managing the Control Framework

By using these frameworks effectively, organizations can help ensure their software systems are developed and deployed successfully in a well-controlled manner that will also stand up to scrutiny by internal audit and external assurance providers. As a best practice, managing the control frameworks in a purpose-built platform ensures consistency when the controls are needed — of course, the SDLC controls will also help you with a successful audit and compliance software implementation, too!