Learn about SOC 2 special situations, acquisitions, breaches, multi-tenant SaaS, AI systems, model drift, AI training data, and more through the Frequently Asked Questions (FAQs) below. Please schedule a consultation if you are looking for a SOC 2 Readiness Partner or would like to discuss a customized solution for your organization.
Table of Contents
What happens to a SOC 2 program when a company is acquired?
An acquired company’s existing SOC 2 Report remains valid for its stated audit period, acquisition does not void a current report. The acquiring organization must evaluate whether the acquired company’s systems will be incorporated into the acquirer’s SOC 2 scope, and if so, when. If the acquired company’s systems are material to the combined organization’s service delivery, they should be brought into scope for the next examination cycle. Material changes to the control environment resulting from the acquisition, system migrations, personnel changes, policy updates, occurring during an active observation period must be disclosed to the auditor immediately, who will assess their impact on scope and findings.
What happens if a data breach occurs while a SOC 2 audit is in progress?
A data breach during an active Type 2 observation period must be disclosed to the auditor immediately, the auditor assesses whether it represents a failure of in-scope controls or a factor outside the examination boundary.
If the breach was caused by a failure of in-scope controls, it will be documented as an exception. If it was caused by a factor outside scope, the auditor may note it in the system description without generating an exception against in-scope controls. The organization’s incident response documentation, detection timeline, containment steps, notification records, and post-incident review, becomes part of the evidence reviewed during fieldwork. A well-documented, properly executed incident response to a real breach can demonstrate that incident response controls function effectively in practice, a more credible proof of control operation than a tabletop exercise alone.
How does SOC 2 apply to multi-tenant SaaS environments?
Multi-tenant SaaS environments face specific SOC 2 considerations around data isolation, auditors examine whether the architecture prevents one tenant from accessing another tenant’s data at both the application and database layers. Auditors verify whether access controls enforce tenant boundaries, whether logging captures cross-tenant access attempts, and whether the system description accurately represents the multi-tenant architecture. Common findings include insufficient logging of access attempts at tenant boundaries, access configurations that allow privileged users to query across tenant data without documented justification, and system descriptions that understate the multi-tenant nature of the architecture.
Do AI systems fall within SOC 2 examination scope?
AI systems fall within SOC 2 examination scope if they touch in-scope customer data, the determining question is not whether a system uses AI, but whether it processes, stores, or transmits customer data that the examination is intended to provide assurance over. An AI inference pipeline that processes customer inputs and returns outputs is an in-scope system component, no differently than a database or API endpoint. An AI model operating entirely on anonymized internal data with no connection to the customer data environment may fall outside scope. Organizations should map all AI components explicitly during the scoping phase and document which models, pipelines, and data flows are included in the system boundary.
How does the Security criterion apply to AI systems?
The Security criterion applies to AI systems the same way it applies to any in-scope technology component, with several AI-specific considerations that auditors increasingly examine. Access controls must cover the AI application layer, underlying model weights, training data repositories, and API endpoints through which the model is accessed. Organizations must demonstrate that access to model training environments is restricted to authorized personnel, that model weights are protected from unauthorized modification, and that API access to inference endpoints requires authentication and logging. Auditors look for model versioning controls, documentation of which model version is running in production, when it was deployed, and what approval process governed the deployment. A model update that changes system behavior is a change to an in-scope system and must flow through the organization’s change management controls.
How does the Processing Integrity criterion apply to AI-generated outputs?
Processing Integrity controls require adaptation for AI systems because AI models produce probabilistic outputs, where the same input may yield different results across runs, rather than the deterministic outputs that traditional software produces.
For organizations including Processing Integrity in their SOC 2 scope where AI is involved, auditors look for documented acceptable performance thresholds, the error rates, confidence levels, or accuracy benchmarks the organization commits to for each AI system; output monitoring mechanisms that detect when model performance degrades below those thresholds; and model validation records showing that models were tested against defined benchmarks before being deployed to production. Standard Processing Integrity controls must be adapted for AI systems rather than applied unchanged, because accuracy for AI systems depends on task definition and acceptable error thresholds rather than binary correctness.
What is model drift and why does it matter for SOC 2 Processing Integrity?
Model drift is the gradual degradation of an AI model’s accuracy as real-world input distributions shift away from the distributions present in training data, and under SOC 2 Processing Integrity, undetected drift constitutes a control failure.
A model that performed within acceptable accuracy thresholds at deployment may produce materially less accurate outputs months later, not because the model changed, but because the data it is processing has evolved. Organizations must establish a process for monitoring model performance on an ongoing basis, defining the thresholds at which drift triggers a remediation response, retraining, replacement, or human review override, and documenting that process as a control. Auditors examining an AI-enabled system under Processing Integrity will look for evidence that model drift monitoring exists, operates continuously, and has a documented escalation path when performance falls outside acceptable bounds.
How does the Privacy criterion apply to AI training data?
If customer data, including personally identifiable information (PII) or protected health information (PHI), is used to train, fine-tune, or evaluate AI models, the Privacy criterion’s full lifecycle requirements apply to that data in the training context. Organizations must document what customer data is used for training; whether customers have been notified and whether consent mechanisms exist; how training data is stored, secured, and eventually deleted; and what controls prevent training data memorization, the risk that a model reproduces portions of training data in its outputs. Many enterprise customers explicitly prohibit vendors from using their data for AI model training in contract terms. Organizations using AI must review customer agreements for these restrictions and implement controls demonstrating that contractual prohibitions are actively honored.
How does the Confidentiality criterion apply to AI systems?
The Confidentiality criterion applies when AI systems process information that clients or the organization have designated as confidential, proprietary business data, trade secrets, or licensed datasets used as AI context or training material. The specific risk AI introduces is cross-contamination: in multi-tenant AI environments, a model exposed to one client’s confidential data may generate outputs that reveal patterns from that data when queried by a different client. Organizations must demonstrate that their AI architecture prevents cross-tenant data exposure, through model isolation, tenant-specific model instances, or inference-time data segregation controls.
What is the AICPA’s current position on AI and SOC 2?
The AICPA has not published a formal SOC for AI framework, AI-specific Trust Services Criteria, or a dedicated SOC for AI examination type. AI systems that touch in-scope customer data are examined under the existing five Trust Services Criteria, the framework is intentionally technology-neutral and applies to AI components the same way it applies to any other in-scope system component. No authoritative AI-specific SOC guidance has been formally issued, and AI audit engagements remain an emerging area being shaped by regulation, customer demand, and evolving auditor practice. Until formal AICPA AI-specific SOC guidance is issued, organizations should work directly with their auditor to determine how the existing five Trust Services Criteria apply to their AI components.
What practical steps should organizations take to prepare AI systems for SOC 2?
Preparing AI systems for SOC 2 requires six steps: mapping AI components to the system boundary, implementing change management for model deployments, documenting performance thresholds, establishing data lineage, securing model access, and reviewing customer contracts for AI-specific restrictions.
The first step is mapping every AI component, models, training pipelines, inference endpoints, data stores, to the system boundary to determine which are in scope. The second step is implementing change management controls specifically for model deployments: version control, deployment approval records, and rollback procedures. The third step is defining and documenting performance thresholds for each AI system, the monitoring mechanisms that track performance against those thresholds, and the escalation process when thresholds are breached.
The fourth step is documenting the data lineage for every AI model, what training data was used, where it came from, whether customer data was included, and what consent or contractual basis exists. The fifth step is implementing access controls on model weights, training data repositories, and AI infrastructure as rigorously as access controls on production databases. The sixth step is reviewing customer contracts for AI-specific provisions, data use restrictions, model training prohibitions, and notification requirements, and implementing controls demonstrating those obligations are actively honored.
Explore Blogs, Webinars and other Resources
Trusted by Reputed Companies
Accreditations and Associations
* Disclaimer: This list of accreditations is held by our team of employees and consultants.
What Our Clients Say
We used databrackets (formerly EHR 2.0) in our small medical practice for our risk analysis assessment to be in compliance with meaningful use. Their response was fast, the final report is detailed but simple and easy to follow. They were always available to answer our questions.
E. Compres
Pulmonary and Sleep Center of the Valley
I never miss the opportunity to learn something new …that’s why I am always registering to all free seminars offered on the web. databrackets (formerly EHR 2.0) happened to be the friendliest, comprehensive and up-to- date source of HIPAA Privacy and Security updates.
Alexandra V.
Community Healthcare Network
Today’s presentation was great! Thank you for sending the slides. My only feedback is that it would be fabulous to have the slides ahead of time so I could print them and take notes on the slides.Thanks for your time and knowledge today!
T.B., PM
Community Health Network
Particularly interesting was the flow chart on Administrative Simplification. I utilize all of the Security subcategories you list under the Security tile and appreciate knowing that I am hitting all of the relevant topics during my employee training.
Jessica B.
JD, CHC
I have re-worked our original risk assessment….We are using databrackets' (formerly EHR 2.0) Meaningful Use Security Risk Analysis Toolkit and it meets our needs. It was easy to use and I believe that it very beneficial to our meeting meaningful use.
Bill Curtis
Neurosurgical Associates Of Texarkana, TX
Information (webinars) presented by databrackets (formerly EHR 2.0) highlights some of today’s most demanding healthcare topics. The webinars help to direct those operating in today’s rapidly changing environment in the right direction.
Candace M.
Privacy and Security Officer, Springhill Medical Center
Our Growing List of Credentials
0
+
Assessments
0
+
Clients
0
+
Assessment Libraries
0
+
Years of Experience
0
+
No. of Staff Trained
0
+
HIPAA
0
+
SOC 2 Readiness
0
+
Pen Testing
0
+
ISO 27001 Certifications
0
+
Dollars Saved in Compliance Penalties