Key Takeaways
- After a merger, SOC 2 compliance requires reassessing and updating security controls to align with the Trust Services Criteria for the new combined entity.
- A thorough gap assessment helps you identify what still works, what needs fixing, and how to prioritize remediation across legacy and inherited systems.
- The Pun Group offers comprehensive services that can help you navigate SOC 2 compliance requirements after a business merger.
How to Approach SOC 2 After a Merger?
After a merger, the best approach to obtaining SOC 2 is to start with a solid gap assessment. This helps you determine which controls are already aligned between the two companies and which ones need to be updated or merged.
We recommend using the summer months to dig into this assessment. That gives you enough time to map out what’s working, what’s changed, and where you’ll need extra effort. Once that’s in place, you can kick off your SOC 2 Type 1 audit by September or October.
The Pun Group can treat the merged entity as one company for the audit and keep the same team involved, which means less time getting them up to speed and more focus on the actual work.
Critical Requirements of SOC 2 After a Company Merger
When two companies merge, the control environment changes, sometimes significantly. Hence, you must focus on critical requirements of SOC 2, such as gap assessment, new controls, and employee training.
Your previous SOC 2 Type 2 report may no longer reflect your current risk posture or operational reality. In most cases, a new SOC 2 assessment is necessary to evaluate the post-merger environment and ensure all systems, processes, and controls meet the Trust Services Criteria.
Below are the core SOC 2 relevant areas that must be revalidated post-merger, along with steps for each.
Gap Assessment
One of the defining aspects of SOC 2 is that it doesn’t tell you how to build your controls; it simply asks: Are they designed and operating effectively to meet the Trust Services Criteria? That’s where things get complex after a merger. Now, you’re dealing with two sets of controls, possibly built for different systems, risk postures, or customer expectations.
A gap assessment identifies where controls from both organizations either overlap conflict or are missing entirely. It helps ensure the merged environment is compliant and highlights what needs to be built, fixed, or removed.
What should be done:
- Conduct a full-scope SOC 2 gap assessment. Work with your internal compliance team or a third-party advisor to evaluate your current control environment against the SOC 2 Trust Services Criteria like Security, Availability, Processing Integrity, Confidentiality, and Privacy. Assess both design and operating effectiveness.
- Evaluate both legacy and new systems. Don’t assume existing controls carry over cleanly. Look at inherited tools, infrastructure, platforms, and business processes from both organizations. Are the logging standards the same? Is encryption consistently applied? Are access rights managed using the same rules?
- Identify gaps and conflicts in key areas. Focus especially on:
- Policy and procedural inconsistencies (e.g., incident response, access provisioning)
- Gaps in monitoring and alerting across systems are now considered in-scope
- Vendor and third-party oversight differences
- Uneven control maturity, where one company is stronger than the other
- Misaligned change management or system development practices
- Map findings by risk level. Use a risk-based approach to prioritize remediation efforts. High-impact control areas, like access management, backup/recovery, or endpoint security, should be addressed first, especially if customer data is involved.
- Create a control harmonization roadmap. Use the gap assessment as your integration compass. Document which controls must be retired, merged, redesigned, or created from scratch. Assign control owners and set realistic remediation timelines for your SOC 2 reporting period.
- Loop in your auditor early. Share your findings and roadmap with your SOC 2 assessor. They can help you identify showstoppers versus issues that can be resolved before your next audit window. This collaborative approach shows auditors that you’re actively managing your compliance posture.
3. Policies and Procedures
SOC 2 compliance hinges on having formal, up-to-date policies that are consistently applied across the organization. After a merger, this becomes a challenge. Two sets of policies often exist, developed under different systems, standards, and assumptions. Conflicts in areas like access control, HR procedures, or data retention can lead to confusion, security gaps, and audit risks.
As we put it, “Keeping two sets of rules is like trying to drive a car with two steering wheels. You’ll crash.” When companies fail to unify policies, it wastes time, creates vulnerabilities, and undermines customer trust.
To avoid these pitfalls, leadership must quickly consolidate procedures into a single, coherent framework. SOC 2 does not care where a policy originated. What matters is that it reflects how the organization operates today. A unified approach ensures clarity, protects data, and builds a stronger foundation for compliance.
What should be done:
- Start with a comprehensive policy review. Pull together all relevant policies from both organizations, security, data protection, HR, vendor management, system access, etc. Identify where they overlap, where they conflict, and where there are gaps. Don’t assume one company’s policies are inherently “better”—evaluate them based on your new shared risk profile and SOC 2 expectations.
- Consolidate into a unified policy framework. Merge policies into a consistent framework that applies across the new entity. Ensure the language reflects the merged systems, teams, and infrastructure.
- Maintain version control and leadership approval. For SOC 2 purposes, it’s essential to show when a policy was last updated, who approved it, and that it reflects recent changes. Use a version control system or change log that documents each revision, including post-merger updates.
- Update for the current operational reality. Policies must reflect new tools, processes, organizational structure, and business functions. For example,
- If you’ve adopted a new cloud provider, update your data security and availability standards accordingly.
- If new departments or vendors have been introduced, ensure vendor risk policies are updated to include them.
- If remote work practices vary, unify them under one acceptable use and endpoint protection policy.
4. Employee Training and Awareness
SOC 2 requires organizations to demonstrate that employees are aware of and trained on the policies and procedures that protect customer data, particularly security, confidentiality, and system integrity. Training proves that your workforce understands their responsibilities and how to uphold the controlled environment.
This requirement becomes even more critical after a merger. You now have employees from different organizational backgrounds, each with their tools, norms, and assumptions. Left unaddressed, this disparity can create serious security blind spots and policy violations.
What should be done:
- Deliver comprehensive, post-merger training programs. Roll out updated security awareness and policy training across legacy and new employees. Training should cover:
- Revised access control policies
- New acceptable use policies
- Data handling procedures
- Confidentiality expectations
- Incident response protocols
- Issue and track new policy acknowledgments. Employees should formally acknowledge all revised policies to demonstrate awareness and accountability. They should also maintain digital completion records as part of their SOC 2 evidence.
- Tailor role-based training for high-risk positions. Certain roles, like IT, DevOps, Finance, Legal, and Customer Success, require more than general awareness. Provide deeper, department-specific training on how controls apply to their daily work, especially in areas like:
- System and data access
- Change management
- Handling sensitive customer information
- Vendor risk procedures
- Refresh onboarding materials for new hires. Integrate SOC 2–2-aligned content into your onboarding workflows. Post-merger, every new employee should be onboarded into the current, unified policies, not legacy procedures.
- Track training completion and test comprehension. Use a learning management system (LMS) or internal platform to monitor training participation and comprehension scores. This will support audit readiness and help identify departments needing additional coaching.
- Run post-training assessments or simulations. Consider phishing simulations, role-based quizzes, or scenario-based learning to reinforce retention, especially as your risk landscape changes post-merger.
- Reinforce awareness continuously, not just annually. Use newsletters, intranet banners, manager toolkits, or lunch-and-learns to keep security and compliance top-of-mind throughout the year.
4. Risk Assessment and Monitoring
SOC 2 requires that organizations regularly identify, assess, and mitigate risks that could impact customer data’s security, availability, confidentiality, processing integrity, or privacy.
After a merger, your risk profile shifts to new systems, business processes, vendors, and user groups that introduce new vulnerabilities. A pre-merger risk assessment is no longer valid in this new operating environment.
What should be done:
- Conduct a comprehensive, post-merger risk assessment. Go beyond a surface-level review. Include infrastructure, cloud platforms, third-party integrations, new business units, and inherited operational practices. Make sure the methodology accounts for both technical and procedural risks.
- Update your risk register. Capture known risks from the legacy environment and newly identified risks introduced by the merger. Include detailed risk owner assignments, mitigation plans, and timelines.
- Reevaluate existing risk ratings. A previously low-impact risk might now affect a larger attack surface, broader customer base, or more critical system. Re-score these risks based on the merged entity’s new operational reality.
- Assess inherited vendors and supply chain risks. Determine if newly acquired third parties meet your existing vendor risk management criteria. SOC 2 auditors often expect to see controls in place for vendor selection, monitoring, and offboarding, especially if customer data flows through them.
- Extend monitoring coverage. Your existing SIEM tools, alert rules, and audit logs must cover all production environments and systems brought in through the acquisition, including cloud instances, internal networks, and endpoints.
- Incorporate merger-related risks into ongoing monitoring. Track indicators related to post-integration friction, access management failures, policy violations, system outages, or increased incident response activity.
5. Scope and Audit Planning
For SOC 2 compliance to remain valid, your audit scope must accurately reflect your organization’s current structure. This includes systems, services, people, and physical or cloud environments, which change significantly post-merger.
Failing to update your audit scope can result in misalignment between what’s being tested and how your business now operates.
What should be done:
- Redefine the system in scope. This includes identifying all in-scope applications, infrastructure components, business processes, data repositories, and customer-facing services from acquiring and acquired entities. Be clear about boundaries—what’s included and what’s not.
- Update the written system description. This document (Section III of a SOC 2 report) is foundational. It must reflect the new organizational structure, ownership, control responsibilities, third-party dependencies, and data flow patterns.
- Reassess the applicable Trust Services Criteria. Depending on what the acquired company offers (e.g., new SaaS platforms, customer services, or data processing functions), you may need to expand the SOC 2 scope to include additional criteria, like Confidentiality or Privacy.
- Coordinate early with your auditor. Notify your audit firm as soon as the merger is confirmed. Provide them with an outline of what’s changing so they can assess whether a mid-cycle scoping change is needed or if a full re-audit is required.
- Revise your audit readiness plan. Integration efforts take time. Some systems and controls won’t align immediately. Create a roadmap for when inherited systems will meet SOC 2 expectations, and work with your auditor to stage testing accordingly.
Revalidate hosting locations and compliance zones. If the merger introduces new cloud regions, colocation facilities, or global processing centers, confirm that data residency, access control, and monitoring are compliant and within scope.
Can we delay our SOC 2 audit until integration is complete?
Technically, yes. But it’s risky. Delaying too long can result in lapsed compliance, affect customer trust, or delay contracts. The better approach is to start with a readiness assessment while integration is still ongoing.
What happens to the previous SOC 2 reports from each company?
Those reports become historical references. They may still be useful for internal tracking or legacy customer assurance, but don’t apply to the new, merged entity. Auditors and customers will want to see how controls are applied in the current combined environment, which requires a new audit aligned with the updated scope.
Do we need to retrain employees already SOC 2 attested by their previous company?
Yes, because the policies, systems, and responsibilities have likely changed. SOC 2 requires evidence that employees are trained on the current control environment, not just what they knew at their previous company. A focused, post-merger training rollout helps reinforce consistent practices and avoid accidental non-compliance due to outdated knowledge.






