Data Migrations & Their Impact on a SOC 2 Report

Data migrations and SOC 2 reports

Service organization environments are ever-changing. As the organization adapts, the systems used by the service organization change in alignment. This process of migrating to a new application or migrating your infrastructure to the cloud can be significant, not just to the organization, but to the service organization’s users.

What is a Data Migration & When Does it Occur?

A migration is when data is moved from one location to another. This can occur when a new system is introduced and data needs to be moved off of the old application, platform, etc. Service organizations can migrate to a new system or platform for a variety of reasons including changing their system to adapt to a change in services or improving scalability.

Why is a Migration Relevant to a SOC 2?

The audit of a SOC 2 Type II covers a period of time for the operation of controls within the control environment. When a data migration occurs during the audit period it is imperative that auditors have the ability to test the old and new systems, as both have differing control environments and each is relevant to user organizations. Hence, old and new control environments must be included in an audit.


When to inform auditors of migration

When to Tell Your Service Auditor About the Migration for Your SOC 2

When management becomes aware of an upcoming migration, the service organization should inform the auditor as soon as possible. An auditor can provide guidance around evidence collection and potential assessment procedures. If your auditor is aware of the timing of a migration, they can schedule testing before and after the migration to obtain relevant evidence in a timely manner, prior to the old system being decommissioned.

What Could Happen if the Service Auditor isn’t Informed in a Timely Manner?

If the auditor is not informed of a migration until after it has occurred there is a possibility that relevant data becomes unavailable. The inability to provide required evidence from the legacy system could lead to internal control deficiencies. If multiple deficiencies occur they may aggregate to a conclusion that is higher than a deficiency.


What Migration evidence is needed?

What Audit Evidence Will Be Requested for a SOC 2 When a Migration Occurs?

Understanding the Environment: In order to establish an understanding of the old and new environments, the auditor will need to test both environments as they relate to the audit. Therefore, the scope of what will be required will differ depending on which SOC 2 criteria are included in the audit. Prior to decommissioning the old environment, snapshots of point-in-time configurations may include, but are not limited to:

  • Authentication parameters
  • Access lists and security groups
  • Backup configurations and
  • Encryption status

Historical data including patch history and monitoring logs (e.g. alert and authentication logging) may also be relevant. Controls will need to be tested for each system individually.

Approvals: In relation to the migration itself, similar attributes to change management testing should be captured and documented. Meetings with various levels of management will most likely occur in preparation for the migration. Therefore, after the roadmap or migration plan is finalized the service organization should obtain written approval from relevant parties. If individuals from both the business and information technology departments are involved, approvals from both departments should be captured.

Testing: In addition to approvals, the service organization should document all phases of testing. Testing should include the procedures performed prior to the migration through the testing for accuracy and completeness, often thought of as reconciliations, post-migration. Depending on the size of the migration and the number of users involved, testing may be able to be documented properly within a ticketing system.

If the migration is large in size or more complex in nature, consider developing a spreadsheet that delegates responsibility for pre-migration and post-migration testing. Testing should cover the accuracy and completeness of data to establish that data was transferred appropriately. Creating a spreadsheet for testing can also help if the migration has multiple phases. Performing the migration in off-hours may lessen the likelihood of data being transferred inaccurately or incompletely. Additionally, establish a backout plan (i.e. preventative controls) and a process if reconciliations during testing don’t match or data is found to be corrupt.

User Access: As access is granted to the new system, a documented pre-migration and post-migration user access review can evidence that access remained appropriate throughout the data transferring process. This can also assist management in making sure that if temporary access was granted, it gets removed when there is no longer a business need. For example, contractors are often used in data migrations and access often remains once the migration is complete. Such access could result in a control deficiency if the access is no longer required.


Migration description for SOC 2

How Will the Migration Be Described in the SOC 2 Report?

In the description of the SOC 2 report, the change must be described if the migration is:

  • Significant (e.g. migration to cloud infrastructure)
  • Relevant to the service organization’s service commitments
  • Relevant to the service organization’s system requirements
  • Relevant to a broad range of report users

The timing of the data migration project and the difference between the old and new systems will be included in the description as well.

What Happens if the Change Occurred Between Audits?

A gap period occurs if the service organization has two SOC 2 reports that are not in a continuous period, also said, there is a period of time between the end of the prior report and the beginning of the new one. If a significant change occurs during the gap period, service organization management will need to decide if the change will be impactful or relevant to the report users. The section of the report titled “Other Information Provided by the Service Organization” can be used to describe new controls which were implemented as a result of the migration to a new system and controls that were implemented for the purpose of the migration itself. This is only necessary if the controls are not tested by the auditor.


Over the course of this short read we have covered the impact of migrations, how they will be assessed and how they will be described in the SOC 2 report. Executing the project plan for a migration can be a complex task but by including the right people early in the process it can lead to a smooth and compliant transition. Hopefully, the overview will help the service organization prepare for expected migrations and significant changes in the environment.

Linford & Company is an independent CPA firm that specializes in a variety of audit services, including SOC 1 and SOC 2 audits. If you have further questions please review our website and contact us to see how we can further assist you and your organization.