SOC 2 HIPAA Mapping: A Practical Crosswalk Guide
SOC 2 HIPAA Mapping. Learn how to map SOC 2 controls to HIPAA requirements. This guide covers overlaps, gaps, and evidence strategies for AI agent systems.
A SOC 2 report can support a HIPAA assessment while leaving the central healthcare question unanswered: does the evidence cover every system that handles electronic protected health information? HIPAA requires safeguards specifically for electronic protected health information (ePHI), not merely a generally secure platform. That distinction matters when an AI agent can reach databases, external tools, or credentials beyond its documented boundary, as reflected in the HHS overview of HIPAA Security Rule requirements.
A useful SOC 2 HIPAA mapping connects requirements to controls, controls to evidence, and evidence to the configuration deployed. For AI-agent systems, a control table without those connections leaves reviewers with assertions they can't independently trace.
Why SOC 2 and HIPAA Are Not Interchangeable
Consider a hypothetical procurement review. An engineering manager submits a platform's SOC 2 report after a healthcare customer requests HIPAA evidence. The report includes access reviews, monitoring procedures, and incident-response controls. The manager assumes the request is satisfied.
The customer's compliance reviewer asks different questions. Which components handle ePHI? Which tool providers are business associates? Where are the permitted-use decisions and breach-notification procedures? Those questions require evidence beyond the report's general security controls.
SOC 2 and HIPAA are complementary, not interchangeable. SOC 2 originated as an AICPA attestation framework for evaluating controls over systems and information. HIPAA is a federal law with healthcare-specific obligations. The AICPA Trust Services Criteria provide the SOC 2 evaluation structure, not an automatic determination of HIPAA compliance.
| Comparison point | SOC 2 | HIPAA |
|---|---|---|
| Assurance model | Attestation against selected Trust Services Criteria | Federal legal obligations |
| Scope | A defined system and applicable criteria | Applicable regulated activities and protected information |
| Shared evidence | Access reviews, monitoring, risk management, incident response | Relevant safeguards supported by that evidence |
| What still needs testing | Whether controls cover the stated system | Whether HIPAA-specific duties and ePHI safeguards are addressed |
Evidence reuse is not requirement substitution
The correct response isn't to discard the report. It's to identify exactly which evidence supports a HIPAA obligation and what remains unproven.
An access review might establish that administrators were authorized for a production database. It doesn't necessarily establish that an agent using that database has an appropriately restricted service credential. Reviewers must examine the agent's access separately rather than infer coverage from the human-access process.
Practical rule: Reuse evidence only after confirming that its scope, subject, and control objective match the requirement being assessed.
A defensible mapping records the relationship, not just the apparent similarity. It identifies the control owner, relevant systems, evidence location, and rationale for reuse. When the relationship is partial, the reviewer records the missing evidence instead of marking the requirement complete.
Understanding the Two Frameworks
SOC 2 organizes evaluation around Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is typically the common baseline, while the other categories apply according to the selected scope. HIPAA's Security Rule instead organizes protections for ePHI through administrative, physical, and technical safeguards.
The distinction is easier to understand when the assurance models are viewed together.
Why the regulatory history matters
HIPAA was enacted on August 21, 1996. HHS published the final Privacy Rule in December 2000 and finalized the Security Rule in February 2003. Most covered entities faced Privacy Rule compliance by April 14, 2003, followed by Security Rule compliance by April 20, 2005. The Breach Notification Rule applied to breaches occurring on or after September 23, 2009, as documented through the HHS HIPAA security resources and regulatory background.
These separate obligations explain why cybersecurity evidence alone doesn't settle the assessment. A technical safeguard can protect information without establishing whether its use or disclosure was permitted. An incident-response record can document containment without resolving breach-notification accountability.
The distinction changes how reviewers should organize their work:
- SOC 2 scope: Identify the defined system and selected Trust Services Criteria before deciding which evidence is reusable.
- HIPAA applicability: Establish the organization's role and the ePHI involved before selecting safeguards.
- Evidence coverage: Verify that each artifact addresses the actual component, activity, and obligation under review.
A crosswalk is a hypothesis until tested
A control crosswalk states that a control may support a requirement. Evidence coverage establishes whether the control applies to the relevant environment and operates as represented.
For example, a logging policy can support a proposed audit-control relationship. Reviewers still need evidence that the agent's tool calls reach the intended logging system and that the records identify the relevant activity. A policy describes intent. Configuration and operational evidence establish the implementation.
That separation prevents a familiar assessment error: treating a well-written control description as proof that every connected component is covered.
Mapping Shared Controls Across Both Frameworks
Start with control objectives, not matching terminology. A useful crosswalk asks what a control prevents, detects, or governs, then identifies the corresponding HIPAA safeguard.
The following table is an analyst's working crosswalk, not an authoritative equivalence table. The SOC 2 column names relevant criterion areas rather than claiming that every control in an area satisfies the corresponding HIPAA obligation.
SOC 2 to HIPAA Control Mapping
| Control Area | SOC 2 Criterion | HIPAA Safeguard |
|---|---|---|
| Logical access | Security, logical-access controls | Access control and information-access management |
| Identity verification | Security, authentication controls | Person or entity authentication |
| Activity logging | Security, system monitoring | Audit controls and information-system activity review |
| Data integrity | Security; Processing Integrity where selected and relevant | Integrity safeguards |
| Protected communications | Security; Confidentiality where selected | Transmission security |
| Risk assessment | Security, risk-assessment controls | Risk analysis and risk management |
| Incident handling | Security, system-operations controls | Security incident procedures |
| Supplier oversight | Security, vendor-risk controls | Business-associate safeguards where applicable |
| Workforce accountability | Security, policy and accountability controls | Workforce sanctions and related administrative safeguards |
Access and logging need configuration-level proof
For logical access, collect the permission definition, authorization record, and review decision. For an agent, that means examining effective filesystem, database, shell, and network permissions rather than stopping at the identity-provider account.
Authentication requires its own analysis. An approved account doesn't establish that the credential used by a tool is appropriately governed. Reviewers should connect the credential reference to its permitted purpose without copying secret material into the evidence package.
For audit controls, distinguish a configured logging destination from usable activity evidence. A reviewer should be able to connect the agent identity, tool, relevant action, and configuration version. If that connection is missing, record a coverage gap.
Integrity and transmission require different tests
Integrity concerns whether the relevant information remains protected against inappropriate alteration. Transmission security concerns protection while information moves between components. Don't combine them into a generic data-protection check.
For a database tool, inspect write permissions separately from connection protections. A secure connection doesn't justify unrestricted writes. Likewise, read-only access doesn't establish that the transmission path is protected.
Shared administration still needs a boundary
Risk assessments, incident procedures, and vendor reviews can support both assessments. Their usefulness depends on whether they include the relevant ePHI systems and agent dependencies.
The healthcare-specific distinction is particularly important for supplier oversight. A vendor review supports risk management, but reviewers must separately address business-associate accountability. The healthcare SOC 2 assessment discussion reinforces why shared evidence shouldn't be mistaken for HIPAA certification.
For each row, record a status such as supported, partially supported, unsupported, or not applicable with rationale. Reserve completion for a tested relationship. A missing approval, absent audit trail, or exposed credential belongs in the findings register, not beneath a completed mapping label.
The AI Agent Gap in Traditional Crosswalks
A crosswalk can clear every named application and still miss the component that mattered: the tool the agent invoked outside the reviewed path. The failure mode is scope.
Neither SOC 2 nor HIPAA, by itself, proves coverage for each agent, Model Context Protocol (MCP) server, plugin, credential, or routed request that can reach ePHI. Reviewers have to tie those elements to the system description and to the minimum-necessary decision for the actual use or disclosure.
| Reviewer habit | Where it breaks | Evidence to request |
|---|---|---|
| Assess the approved application name | A scheduling agent can invoke a separately configured database tool while the application stays inside scope | Tool inventory, agent definition, permission grant |
| Rely on runtime logs | Logs show calls that happened; configuration shows calls that were possible | Versioned settings, capability list, deployment record |
| Treat one annual review as durable | Agents drift when prompts, tools, endpoints, or credentials change | Drift record tied to approval history and remediation |
Translate AI agent security risks into inspectable artifacts rather than generic threat labels: versioned agent definitions, external-interface inventories, permission rationale, approval history, and detected deviations.
As noted earlier, HHS's December 2024 proposed Security Rule would require technology-asset inventories and network maps showing ePHI movement, reviewed at least annually and after material changes. Treat that as a proposal in this analysis.
An unobserved tool call is not proof that the tool was unavailable.
Static review has limits too. A configuration file cannot prove an external service behaved as intended or that production ran the same settings. Pair the reviewed artifact with deployment evidence, then compare the intended boundary with operational observations. If a capability exists outside the approved purpose, record the gap even when logs stay quiet.
What Remains Uniquely HIPAA-Specific
A covered entity approves an AI documentation vendor on the strength of a clean SOC 2 report. Six months later, a compliance review asks which agreements governed the vendor's subprocessors and what notification duty applied after an unauthorized disclosure. Nobody can produce the analysis. The SOC 2 report did its job. It was never asked those questions.
That distinction defines this section's scope. SOC 2 attests that controls operated. HIPAA assigns legal relationships, permitted uses, and response duties that exist whether or not any control framework mentions them. Reviewers need a separate accountability record for each.
Vendor approval is not a business-associate determination
An attestation does not establish a required Business Associate Agreement. Listing a platform in the assurance package also does not bring downstream tools, subprocessors, or separately issued credentials inside the approved arrangement. The determining factors are the provider's role and its actual handling of protected information, which a control report was never designed to assess.
The record reviewers should produce has four parts:
- Relationship analysis: the covered-entity or business-associate determination and the agreements that follow from it.
- Use and disclosure basis: the approved purpose and the Privacy Rule assessment behind it.
- Dependency tracing: downstream components and how their involvement is governed.
- Reassessment ownership: a named party responsible when a vendor, credential, or data route changes.
Incident evidence must support legal decisions
A security team can contain an incident without completing the HIPAA-specific assessment. Containment answers what stopped. The legal question asks what happened, which protected information was involved, and what notification obligations follow. A log showing a successful request is insufficient if reviewers cannot establish which tool configuration authorized it or which recipient received the information.
Emergency-mode operations need the same explicit treatment. Reviewers should examine how the organization governs access and protects ePHI during disrupted operations, rather than assume a general continuity document covers the healthcare context.
Security personnel establish the technical events. Designated compliance personnel resolve the applicable HIPAA obligations using that evidence.
Pre-deployment capability reviews make those determinations easier to reconstruct. They fix what was approved before an incident, while runtime evidence establishes what occurred.
Building a Crosswalk for AI Agent Systems
A crosswalk that names controls but not artifacts fails under review. The durable unit is a deployable configuration version: agent definition, tool set, permission scope, credential reference, approval state, data route, and release identifier captured before deployment.
Treat the mapping as an evidence graph, not a two-column table.
| Crosswalk entry | Evidence to preserve | Review question it answers |
|---|---|---|
| Scope boundary | Named config version, owner, environment, data purpose | Which agent and ePHI purpose are being assessed? |
| Reachable capability | Tool specs, effective permissions, credential references | What can the agent touch when invoked? |
| Control relationship | SOC 2 criterion area, HIPAA safeguard, rationale | Why does this finding satisfy or fail each objective? |
| Decision record | Reviewer, approval, exception, remediation | Who accepted the residual condition? |
| Release linkage | Commit SHA, deployment record, reviewed artifact | Is the approved artifact the one running? |
| Open HIPAA obligation | Owner, required determination, status | What cannot be proven from configuration alone? |
Static configuration evidence closes the part both frameworks leave implicit. Neither SOC 2 nor HIPAA automatically settles whether an agent's tool definition was approved, whether its permission bundle exceeded the approved purpose, or whether a model route changed after review. The preserved artifact gives reviewers the baseline. Deployment records show whether that baseline reached production.
Where checks can be expressed mechanically, encode them as deployment gates. These policy-as-code examples show how rules such as denying broad database access or requiring approval for sensitive tools can be stated. A passed gate proves conformance with that gate only; HIPAA obligations still require the named organizational determinations.
This companion video can support discussion of the workflow.
Keep superseded results after remediation. The earlier finding, corrective change, approval, and later result form the change-control trail.
Set reassessment triggers in writing: a new tool, widened permission, changed credential scope, new destination, altered approval flow, or dependency change reopens the affected rows. The crosswalk is complete when an engineer and a compliance reviewer can start from the same artifact and reach the same coverage decision without inbox archaeology.
Real-World Scenarios for Compliance Teams
The following scenarios are hypothetical assessment examples, not reported case studies. Each illustrates a different decision that a crosswalk should support.
Deploying an MCP server that handles ePHI
A development team proposes an MCP server with database and filesystem tools. Before release, the security engineer collects the server definition, tool specifications, effective permissions, credential references, and proposed data routes.
The reviewer maps excessive permissions to the relevant access-control objectives and records the exact configuration evidence. Compliance personnel separately determine whether the server's ePHI handling fits the approved purpose and applicable organizational boundary.
- Release evidence: Preserve the reviewed artifact, approval, and deployment reference.
- Unresolved condition: Don't mark coverage complete while the tool's reachable data remains unknown.
Onboarding an external tool provider
A platform team wants to replace a tool provider without changing the agent's visible user interface. The compliance impact depends on the changed dependency and information flow, not the interface.
Vendor-risk personnel examine the provider's assurance evidence. HIPAA stakeholders assess the relationship and applicable agreement, while engineers compare the old and proposed destinations, permissions, and credentials.
The useful output is a documented decision about the changed route. A copied vendor approval doesn't demonstrate that reviewers assessed the new provider's actual role.
Investigating a suspected tool-call disclosure
An incident responder identifies a request that may have sent ePHI to an unintended destination. The responder preserves request records and retrieves the configuration version deployed at the relevant time.
The investigation compares approved capability, deployed capability, and observed action. Those are distinct evidence subjects.
- Technical reconstruction: Establish the tool, destination, identity, and relevant configuration change.
- Compliance assessment: Determine the protected information involved and applicable breach-assessment and notification duties.
Across these examples, the crosswalk helps teams locate evidence and identify responsibility. It doesn't replace the engineering investigation or the healthcare-specific decision.
A Practical Recommendation for Dual Compliance
Treat SOC 2 and HIPAA as complementary evidence streams supported by a shared control inventory. Keep their assessment conclusions separate. That structure allows evidence reuse without turning a technical control result into an unsupported legal conclusion.
For AI-agent environments, make the configuration version the link between engineering work and compliance review. A permission finding should lead directly to the relevant artifact, approved change, deployment record, and control rationale.
Prioritize proof over mapped labels
Start with an agent that handles ePHI and test whether a reviewer can reconstruct its approved boundary. If the reviewer must ask engineers to recreate the tool inventory or explain undocumented permissions, the evidence package isn't ready.
Use a focused review agenda:
- Establish ownership: Name the people accountable for configuration, deployment, and HIPAA decisions.
- Resolve scope: Identify the agent's dependencies and relevant data destinations.
- Preserve decisions: Retain approvals, exceptions, remediation records, and historical configurations.
- Test coverage: Verify that claimed controls address the actual component and activity.
Where teams use centralized routing, an MCP gateway can support runtime policy decisions. Its coverage still depends on which requests traverse it. Don't extend that evidence to traffic outside the routed path.
The strongest SOC 2 HIPAA mapping is therefore not the table with the most completed rows. It's the record that lets an independent reviewer explain what was covered, why the evidence applies, and what remains unresolved. Treat static configuration artifacts as compliance evidence from the start, then validate them against deployment and runtime records.
Foo Guard offers pre-deployment static analysis for AI-agent configurations and MCP/tool definitions, with evidence-backed findings, versioned history, and policy checks for GitHub and CI/CD. Visit Foo Guard to evaluate a configuration and use its permission, credential, and approval findings as supporting evidence in your SOC 2 HIPAA mapping, not as a substitute for a HIPAA assessment.
