ISC S2 M4-M7

Defining Change Management

used to describe the policies, procedures, and resources employed to govern change in an organization.

Change Management may:

• May be initiated from within the organization or imposed from sources outside the Org.

• Will usually have an impact on IT infrastructure such as internal hardware, software applications, and governance no matter the source.

The scope of change to be managed can range:

• From something as routine as implementing a new software update.

• To an initiative more complex and as infrequent as overhauling an organization's core switching architecture.

• Regardless of the scope or size of a change management project, potential risks need to be mitigated to minimize disruption to core business functions and operations.

The Change Management Process

A robust change management process is a key component for successfully ensuring that an organization can keep up with changing application and hardware needs without losing the ability to operate or achieve its strategic objectives.

Change Management Process following steps to change its path from inception to implementation:

1. Identify and define the need for system changes.

2. Design a High-level plan including goals to be achieved because of the system change.

3. Obtain Approval from management for the change.

4. Develop an appropriate Budget and Timeline.

5. Assign personnel responsible for managing the system change.

6. Identify and address potential risks that could occur during the change or post implementation.

7. Provide an implementation road map.

8. Procure necessary resources and train the appropriate personnel.

9. Test the system change.

10. Execute the implementation plan.

11. Review & monitor change implementation & Test as needed to verify effective implementation.

Types of Environments

Changes should be implemented in segregated environments within an organization so that normal business operations are not disrupted.

The types of environment includes:

• Development

• Testing

• Staging

• Production

• Disaster Recovery

Development:

• Software programmers write code to create application prototypes

• There is typically a source code editing tool which is used to create and modify code syntax, automation tools that have preconfigured code, and a debugging tool to help fix errors.

Testing:

• developers test and debug code to identify errors that need to be corrected.

• This environment MAY be considered the same as the development environment

• Some organizations may keep the test environment intentionally separate so that the focus is solely on debugging errors in an application that is mostly complete.

Staging:

• Organizations can test programs that are in their final phases of development in a production-like environment.

• Intended to test functionality, compatibility, security, and performance PRIOR to deployment.

Production:

This is the environment in which an application is deployed and made available to end users.

Disaster Recovery:

Organizations set up this environment to ensure that applications can be restored quickly, save critical data and systems, notify management, and recover in the event of an outage or attack.

Change Management Risks

A key component is to identify the potential risks that could occur as a result of the change.  These risks:

• Are present in all steps of change from acquisition to implementation.

• Can affect existing systems, processes, and employees.

When assessing change management risks in a SOC 2® engagement:

service auditors should refer to the AICPA's trust services criterion CC8.1.

• This criterion recommends service organizations have policies and practices in place that properly authorize, design, develop or purchase, configure, document, test, approve, and implement changes to the company's:

  • Infrastructure

  • Data

  • Applications to meet corporate objective

Selection and Acquisition Risks

Selecting and acquiring new IT resources is a fundamental area in which risks exist in the change management process.  Examples include:

• Lack of Expertise

• Lack of a formal selection and Acquisition Process

Selection and Acquisition Risk: Lack of Expertise

When selecting and acquiring software, there’s a risk that the purchasing agent may lack the expertise or organizational insight to choose software that meets the organization's needs.

Selection and Acquisition Risk: Lack of a formal selection and Acquisition Process

• There is a risk that an organization either does not have or does not follow a formal selection and acquisition process as it pertains to software. 

• This could result in overspending, inappropriate related party transactions or kickbacks or software that does not align with the IT governance strategy.

Examples of Selection and Acquisition Risks

• Software/Hardware Vulnerability and Incompatibility

  • When selecting and acquiring software and hardware packages, there is the risk that proper safeguards and security features that are needed to adequately protect an organization from unauthorized use do not exist.

• There is also the risk that newly acquired hardware and software are incompatible with each other or with existing resources that will remain in production.

To combat Selection and Acquisition Risk, the AICPA's trust services criterion CC5.1 can be applied:

• Recommends companies select/develop controls that help mitigate risks to meet business objectives.

The AICPA also provides the following illustration in its SOC 2® guidance to help provide context to the ways in which this control can be met, from both: 

• The service organization's perspective.

• The service auditor's perspective.

Service Organization's Perspective:

• Perform annual risk assessments to determine whether identified risks and the controls linked to those risks are adequate.

• If new controls are needed due to new processes, the organization can use the proper change management process to implement them.

Service Auditor's Perspective:

• Obtain and inspect the annual risk assessment performed by the service organization to determine that new controls were implemented to address risks not sufficiently addressed by existing controls.

• The service auditor should inspect a sample of the system change requests to determine whether the proper change management process was used.

Integration Risks

• Once the software has been selected and acquired, it must be integrated into existing Systems & Processes 

• This may prove to be one of the most difficult risks to manage, because there are many nuances that are further complicated by employee perceptions and attitudes toward accepting change.

  • Examples Include

  • User Resistance

  • Lack of Management Support

  • Lack of Stakeholder Support

  • Resource Concerns

  • Business Disruption

  • Lack of System Integration

Integration Risks - User Resistance

• When change occurs (especially technology-related changes), there is often resistance to adoption of the change by employees.

• As a result, there is a risk that employees do not adapt to the change, ignore training, and ultimately do not follow through with change appropriately.

Integration Risks - Lack of Management Support

• If management does not provide both resources and adequate support, this could magnify existing employee resistance.

Integration Risks - Lack of Stakeholder Support

The stakeholders involved in the change may range from employees to suppliers to customers, any of which may have an adverse reaction or disposition toward change.

Integration Risks - Resource Concerns

• Frequently, change can be resource-intensive from both financial and labor perspectives

• As a result, appropriate resources may not be made available for the change, which may lead to ineffective implementation.

Integration Risks - Business Disruption

• When making major changes to IT infrastructure, there is the potential for brief or even prolonged information system failures. 

• These could cause significant disruptions to core functions and could have long-term negative consequences for the organization.

Integration Risks - Lack of System Integration

Due to the ever-changing technological landscape, organizations may operate many different systems, some of which may be legacy systems (original or older software programs) that do not effectively adapt or integrate with more modern systems.

Outsourcing Risks

• When planning a significant IT change or system upgrade, some organizations choose to outsource the change management process.  This may be pursued:

  • As a Cost-Saving approach OR to Leverage the expertise of an external agency.

• Along with the benefits of outsourcing change management come risks.

  • Lack of Organizational Knowledge

  • Uncertainty of the third partys knowledge and management

  • Lack of Security

Outsourcing Risks - Lack of Organizational Knowledge

Outsourcing the change management process could leave the organization vulnerable, because it MUST rely on the third party to FULLY comprehend the organization's business model and needs so the third party can integrate that change into the organization without causing disruption.

Outsourcing Risks - Uncertainty of the third partys knowledge and management

• When outsourcing change management or any IT function, there is a risk that the external party has ineffective or weak management, inexperienced or underqualified staff, or a lack of technology expertise.

  • These risks can cause the outsourcing of IT to fail.

Outsourcing Risks - Lack of Security

• Outsourcing IT functions can lead to transmission of sensitive and confidential data.

• As a result, there is a risk that an external organization does not have sufficient or effective safeguards to make sure that client, customer, employee, or operational information is kept secure.

Change Management and New System Controls

Once all risks in the change management process have been identified, controls are designed to minimize the possibility that the inherent risks will:

• Cause Business Disruptions  OR  Negatively Impact IT Systems.

Change Management Controls include the following:

• Policies and Procedures

• Emergency Change Policies

• Standardized Change Requests

• Impact Assessment

• Authorization

• Segregation of Duties

• Conversion Controls

• Reversion Access

• Pre-implementation testing

• Post implementation testing

• Ongoing Monitoring

Policies and Procedures

Clear change management guidelines are needed to outline how the change management process should be executed, from selection to integration and maintenance.

Emergency Change Policies

Separate contingency policies and procedures provide direction for emergency change situations that allow for an expedited process that still maintains an audit trail and appropriate controls. Emergency changes arise when a crisis or time-sensitive threat requires a quick response, such as an operating system patch that exposes a company to severe security threats.

Impact Assessment

Analysis documenting the effect a change will have on the organization's business activities as well as any potential disruptions will help prepare an organization for successful change implementation.

Segregation of Duties

Properly separating job roles will help protect assets or information from being utilized improperly. This would include, for example, distinguishing team members who develop and design specific components from employees responsible for placing those components into production.

Authorization

Requiring designated levels of authorization for changes, including material modifications to the initial change plan, is necessary to protect against unauthorized modification to a project's scope.

Conversion Controls

When migrating from an existing system or process to the new ones, conversion controls help minimize data conversion errors related to the impacted IT assets and resources.

Reversion Access

• Some changes may cause unexpected complications; therefore, it is important to have the ability to revert to the prior system or process that existed before the change.

• This can be accomplished through Parallel Implementation in which the organization maintains two environments at the initial onset of the change.

  • One WITH the change implemented (development environment)

  • One WITHOUT the change implemented (production environment).

Pre-implementation testing

Before moving the change into production, testing will help determine if the change is functioning properly and there are no irregularities.

Post implementation testing

After a change is moved into production, reconciling transactions processed in the new environment with those in the previous environment validates proper implementation.

Ongoing Monitoring

Continuous periodic reviews after implementation promote long-term success. Initially, these may occur weekly but can shift to monthly, quarterly, or annually as the change is effective.

Standardized Change Requests

Standardizing change requests by using consistent forms and request protocols helps complete all required changes in a timely fashion

Trust services criteria for SOC 2® engagements require service organizations to identify and assess the potential impact that changes could have on a system of internal control.:

• To accomplish that, organizations should perform an annual risk assessment process that evaluates the following:

  • The economic, regulatory, and physical environment in which the company operates.

  • The business environment, industry, competition, and consumer dynamics.

  • The effect of how new lines of business, modified lines of business, expanding through acquisition, or downsizing through divesting can affect internal control.

  • Management's attitude toward internal controls.

  • Changes in the technology environment.

  • Partnerships with vendors and other businesses.

Service auditors performing SOC 2® engagements should also consider the trust services criteria when testing controls:

• This may involve inspecting management's annual risk assessment to enhance the likelihood that management identified the need to implement new controls to mitigate risks that were not sufficiently addressed.

  • The auditor should sample system change requests to verify that management followed the change management process for new controls that were identified.

Documentation can be a form of change management control in that it provides a log of changes made to a system or process.

• Good documentation practices can help organizations track and manage changes that is:

  • Efficient, Effective, and compliant with relevant regulations and policies.

Documenting system changes helps organizations understand system functionality and evolution over time, which is useful for various reasons, such as:

• Troubleshooting

• Staff training and education

• Improving system performance.

What is a baseline configuration, and why is it important?

a starting point for reconfigurations so that changes are deployed in a consistent and secure environment. Baselines can also be used as a benchmark to compare current progress or performance of a system.

How do baselines help IT teams during system evaluations?

allow IT teams to better understand the root cause of issues and evaluate the effectiveness of changes implemented.

How are checklists used with baselines during system changes?

is often employed when launching from a baseline. Items on the checklist are marked with time stamps as they are completed, providing a linear path so managers can trace preceding steps to understand the changes implemented.

What is a baseline image, and what does it typically include?

a graphical depiction of a system, which outlines important devices, personnel, and their interconnectivity.

How are baseline images used to track system changes?

As changes are made to the system and the image is updated, managers can compare the two for an understanding of the changes.

Baseline Configuration Metrics used may include:

• System Uptime.

• Resource Utilization.

• Failover Time.

If System Uptime Decreases after the implementation

then management would know that the system updates were detrimental and not working as planed.

if Resource Utilization Increased

more computing resources were required

if Failover Time Increased

resulted in a delay of backup resources coming online in a system outage, then the system update may also be considered unsuccessful.

List of items that comprise a system, including:

• Hardware

• Software

• Peripheral Devices

• Other IT assets

The inventory should include:

• The purpose of the component.

• Its Location.

• The Current Status.

• Whether it is functioning properly.

This information can be used to track the following:

• Components that are nearing end of life.

• Repairs and maintenance that have been made.

• Component owners.

• Upgrades and replacements that need to be made.

• Guidance related to troubleshooting.

• Specs such as model types and serial numbers.

• Depending on which change management controls an organization implements, there are different procedures for testing the controls to enhance the likelihood that they are operating as intended. 

  • The procedures will vary based on the:

• Type of applications.

• The type of Infrastructure components.

• System configurations to which the control is being applied.

• Procedures for testing change management controls for IT resources include multiple components.

• When evaluating change control policies, management should establish acceptance criteria that are measurable and specific so that change can be objectively evaluated.

• Adequately structured acceptance criteria help enhance the likelihood that changes to systems or processes are:

• Clear and Concise

• Properly tested prior to implementation

• Adequately documented

• Approved by stakeholders

• Evaluated so that the impact is understood

• Reviewed and monitored AFTER implementation

Acceptance Criteria - Metrics may be either:

• Quantitative - Measured by the quantity (Number)

• Qualitative - Measured by the quality of something

Metrics Example Include:

• Performance

• Compliance

• Functionality

• Scalability

Metrics - Performance:

• Quantitatively, this may be measured using metrics such as a newly configured system's uptime, downtime, or speed in terms of seconds or minutes. 

• Qualitatively, this could simply be a rating by a testing panel of perceived performance or survey.

Metrics - Compliance:

• This may be measured by an objective Qualitative assessment that renders a Yes or No verdict of compliance.

  • If the Application/Infrastructure component complies, or it does not.

Metrics - Functionality:

This metric would be Qualitative and assess whether an application or infrastructure component performs a target function and how efficient or practical it is to use the system in its intended environment.

Metrics - Scalability:

The ease of the system's ability to scale up or down would be quantitatively measured by using such metrics as the maximum number of transactions that can be processed, users who can be logged on, or customers that a system can handle.

Logging

•  the process of recording events into logs or databases so they can be tracked.

• By capturing communications and changes, companies can determine whether change control policies are being followed as well as investigate known violations of policy.

Types of Logging - Application Logs

• Record application data, such as when an employee accesses or views a table, executes a function, or when an error causes the program to stop functioning.

Types of Logging - Change logs

• Track changes that were requested, approved, and implemented and may be a part of a disaster recovery program.

  • Having a snapshot of these changes will allow IT administrators to restore a system back to a given point in time prior to a change.

Types of Logging - Event Logs

Record various events that occur on a system including directory logs, DNS (Domain Name System) server logs, endpoint logs, security event logs, and basic system logs.

Types of Logging - Firewall Logs

 Record all traffic that flows through a firewall such as packet information containing ports used, IP addresses, protocol used, action taken by the firewall, the reason for the action, and the time and date the packet was transmitted.

Types of Logging - Network logs

• Also referred to as Perimeter logs. Provide intelligence from devices that guard a network's perimeter such as virtual private networks, firewalls, and intrusion detection systems.

  • By monitoring this activity, organizations can detect attacks, identify misconfigured devices, and other potentially threatening behavior.

Types of Logging - Proxy logs

• can control internet access and enhance performance for users.

• The logs for proxy servers show details such as which sites a user visits, the time, and how long the user viewed certain pages.

Event logs - Directory logs

provide data on events involving Active Directory (AD), which is related to Authenticating users, governing privileges for users and groups, and the devices that acces AD.

Event logs - DNS server logs

contain information on source and destination IP addresses, query and response details, time stamps, and errors.

Event logs - Endpoint logs

record events at the device level such as what devices are connect to a laptop, the files or programs installed on that device, and the networks to which it connects.

Event logs - Security event logs

track access to system resources like shared folders, printers, and files.

Event logs - System logs

record events like when a system is started, rebooted, or updated

System Admins should evaluate the results of testing the design and implementation of change control policies.

• Such evaluations include the following:

• Review written change management policies, confirm they are up-to-date, and check for proper acceptance criteria.

• Review documentation for implemented changes and request evidence that the change management policy was followed.

• Confirm that all necessary authorizations were obtained.

• Review whether change requests used a company’s standardized form.

• Request evidence of which employees or teams performed which duties to ensure proper separation of duties.

• Execute testing of change controls and evaluate the results.

• Perform monitoring activities to review all testing results and confirm necessary updates were made post-implementation.

How does monitoring support accountability in change control policies?

supports accountability by holding employees responsible through authenticating a unique user ID, audit trails, and other surveillance methods. These are reviewed for violations or breaches, with unacceptable occurrences resulting in disciplinary action or termination.

How does monitoring help troubleshoot and solve problems in change control policies?

uses techniques like reviewing audit trails and performing log analysis to identify, diagnose, and troubleshoot problems. Log analysis searches for anomalies, patterns, trends, and unauthorized behavior. Due to the immense volume of data, automated tools are critical for effective analysis.

What is continuous integration and what are its benefits in testing?

involves regularly merging code into a central repository with automated building and testing. It:

• Helps identify bugs faster

• Enhances application quality

• Shortens time to release updates

What are key features and challenges of continuous deployment?

software is automatically created, tested, and deployed to production.

• Minimizes cycle time

• Maintains testing
  Challenges:

• Bugs may be released to live environments

• Difficult for complex, interdependent code

• Cultural shift and need for standardized testing upfront

Two of the most common IT change management methodologies are:

The Waterfall Model & The Agile model

• Traditionally used for software development and IT projects, these models are flexible enough to be applied to modern change management practices across various organizational functions.

• Since the primary difference between the models is Flexibility, some cross-disciplinary change management projects may gravitate toward one or the other.

Waterfall methods

Characterized by different teams of employees performing separate tasks in sequence, with each team:

• Beginning work from the pre-written authoritative agreement of the preceding team

• Then ending work when the business requirements for the team have been met.

  • The project then passes to the next team.

Challenges associated with waterfall method include:

• Requires a great deal of time to complete

• Benefits of the new system are not realized until completion.

• There is no customer input and change can be difficult to manage.

• Some employees may be idle before beginning or after completing their step in the process.

Waterfall method steps

Agile Method

• Created to address issues with the waterfall model

• Uses cross-functional teams focused on prioritized customer needs

• Teams work simultaneously, not linearly

• Shorter deadlines encourage efficiency and require strong communication

• Allows changes in direction during the project based on stakeholder feedback and tech changes

• Final outcome can evolve over the project’s life cycle

The Agile principles are as follows:

• Satisfy the customer with early and continuous delivery of the highest-priority features.

• Welcome change: A change request is an opportunity to be closer to customer needs.

• Deliver working software frequently: Working software is the primary measure of progress.

• Complete only the work REQUESTED by the customer.

• Conduct short, frequent, and regular meetings to maintain focus and make adjustments.

  

Patch Management

is the systematic process of:

• Identifying specific vulnerabilities or software bugs in operating systems or applications

• Addressing them with patches, or fixes, between releases.

• It promotes system security and enhances the likelihood that systems are running smoothly.

An effective patch management process includes: Reactive & Proactive

• Evaluating New Patch Releases: Reactive

• Using A Vulnerability Tool: Proactive

Evaluating New Patch Releases: Reactive  

• As vendors discover new vulnerabilities, they release patches so that organizations can implement fixes. (Reactive)

• IT managers must evaluate those patches, determine how they will impact their company, and then devise plans to implement them (Reactive)

Using A Vulnerability Tool: Proactive

• This helps organizations track security controls and identify weaknesses on their own so that management can identify patches needed, as opposed to waiting until a vendor or external parties discover a vulnerability. (Proactive)

Testing Patches In A Test Environment:

• Implementing patches in a nonproduction environment is critical, if it is possible

  • so that they do not negatively impact system performance if an issue is found.

• Not all companies have the manpower or technical know-how to test patches, so this may only be performed by larger companies in an attempt to prevent company-wide outages.

Approving and Deploying Patches:

After patches have been successfully reviewed and tested by IT administrators, the updates are deployed to the appropriate system during a scheduled downtime to minimize disruptions.

Verifying patches deployed

• Verification of successful patching should be performed after testing and deployment, which should then be followed by monitoring so that any system issues can be identified and resolved after deployment.

Why do organizations use regular patch schedules, and what is a potential risk?

• Regular patch schedules (e.g., monthly or yearly) help companies prepare for updates.

• However, predictable schedules can be exploited by bad actors.

What does the AICPA recommend for SOC 2® compliance regarding patch management?

• Maintain a documented patch management process

• Ensure changes are properly authorized and implemented to meet company objectives

• Service auditors should inspect policies for rules on patch and change management