SOC 2 vs HIPAA: which to pursue first when you handle ePHI
If you are a health tech vendor or business associate and your customers keep sending security questionnaires, fund the HIPAA Security Rule work first. HIPAA is a legal duty enforced by HHS, and no certificate discharges it. SOC 2 is a voluntary CPA attestation that buyers ask for. In practice, that means completing the risk analysis required by 45 CFR 164.308(a)(1)(ii)(A), implementing the administrative, physical and technical safeguards, and documenting how you meet your direct obligations as a business associate under 45 CFR 164.302. Those duties exist whether or not any customer ever asks for a report, and a regulator will ask for them directly.
A SOC 2 report can support parts of this work, but it cannot show HIPAA compliance. Its trust services criteria, such as the common criteria covering logical access and change management, overlap with some safeguards, yet the report does not test the required risk analysis, the addressable-specification decisions you must document under 45 CFR 164.306(d), or the business associate agreement terms your customers have signed. Before scoping any audit, ask the auditor in writing which HIPAA obligations the report will and will not address, and confirm whether a SOC 2+ report covering additional HIPAA criteria is available. The AICPA's October 2022 guide includes an illustrative SOC 2+ report, but whether a given firm will issue one for HIPAA is a question to put to that firm.
Add SOC 2 when a customer contract or procurement team requires an independent report, and plan to run both once that happens. Most of the evidence for the two overlaps, so the sequencing decision is about timing and scope rather than duplicate work. Confirm with each customer whether a Type 1 (controls as of a date) or Type 2 (controls over a period) report satisfies their request, and whether they accept a SOC 2 without HIPAA-specific criteria. Keep the HIPAA risk analysis and safeguard documentation as the master record, because no report replaces them.
How SOC 2 and HIPAA differ on scope, proof and enforcement
This table compares who each framework applies to, where its obligation comes from, what proof it produces and who enforces it. Read it as two separate questions: HIPAA is a legal duty for covered entities and business associates, while SOC 2 is an attestation a customer may request. The main takeaway is that a SOC 2 report can support parts of a HIPAA program but cannot establish HIPAA compliance on its own.
| Dimension | SOC 2 | HIPAA Security Rule |
|---|---|---|
| Who it applies to | Any service organization that chooses to undergo an examination, usually because customers ask for one | Covered entities and business associates that create, receive, maintain or transmit electronic protected health information |
| Source of the obligation | Voluntary. Set by customer contracts and buyer security reviews, examined under AT-C section 205 | Law. 45 CFR Part 164 Subpart C, with business associates directly liable to OCR for Security Rule failures |
| Proof it produces | A CPA attestation report: Type 1 (design as of a date) or Type 2 (design and operating effectiveness over a period) | No certificate. HHS states no Security Rule standard requires certifying compliance, and private certifications are not recognized |
| Governing criteria | AICPA 2017 Trust Services Criteria with points of focus, plus the 2018 description criteria for the system description | Standards and implementation specifications in 164.308, 164.310, 164.312, 164.314 and 164.316, with required and addressable specifications |
| Enforcement | Buyer requests and contract terms. No regulator enforces SOC 2 itself | HHS Office for Civil Rights through complaints, compliance reviews and audits, with civil money penalties |
| Penalty range | Not applicable. Consequences are commercial, such as lost deals or contract terms | Inflation-adjusted range from $145 per violation (no knowledge) to $2,190,294 per violation, with an annual cap of $2,190,294 for penalties assessed on or after January 28, 2026 (45 CFR 102.3) |
| Status of the proposed 2025 revision | Not applicable | Proposed on January 6, 2025 (90 FR 898) and not finalized as of October 2026. Confirm the current status with the Unified Agenda before planning around it |
| Required risk analysis | Not a separate SOC 2 requirement. Risk assessment is covered within the trust services criteria | Required implementation specification: an accurate and thorough assessment of risks to ePHI (45 CFR 164.308(a)(1)(ii)(A)), which no SOC 2 report replaces |
What a SOC 2 report can and cannot show about HIPAA
A SOC 2 report cannot establish HIPAA compliance, and it cannot stand in for the risk analysis that the Security Rule requires. A SOC 2 is an examination of controls against the AICPA's 2017 Trust Services Criteria, and a Type 1 report covers the system description and whether control design is suitable as of a date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. Neither report tests your organization against the 45 CFR Part 164 Subpart C standards or implementation specifications, and neither says whether an addressable specification was properly assessed and documented under 45 CFR 164.306(d). Ask your auditor which criteria were in scope and whether the report covers any HIPAA-specific subject matter, because the common criteria alone do not map one to one onto the Security Rule.
A SOC 2+ report can widen the picture. The AICPA's October 2022 SOC 2 guide includes an illustrative report in which the examination also addresses criteria or subject matter beyond the trust services criteria, so a provider could ask for HIPAA safeguards to be tested as additional criteria. That is a scoping decision for the engagement letter and the system description, not a default. Even then, the report is a CPA opinion delivered to customers. It does not bind HHS to any finding, and HHS FAQ 2003 states that a third-party certification does not prevent HHS from later finding a security violation. OCR's enforcement, including its 2024 to 2025 audit program, runs separately from any attestation you hold.
Plan for the gap now. HHS proposed an annual compliance audit in its January 2025 Security Rule revision (proposed 45 CFR 164.308(a)(14)), but that rule had not been finalized as of October 2026, and the proposal does not say whether the covered entity or an outside party would perform the audit. Do not budget for a HIPAA audit that does not yet exist. Instead, keep a current, documented risk analysis under 45 CFR 164.308(a)(1)(ii)(A) and map your SOC 2 evidence to it so that the report supports, rather than replaces, that work.
Where SOC 2 and HIPAA controls overlap in practice
SOC 2 and HIPAA both ask whether access, logging, change, response, vendors and monitoring are controlled, but they test different things against different criteria. Treat every overlap below as a starting hypothesis to confirm against your own Security Rule mapping, not as proof that one report satisfies the other.
Access control
A SOC 2 tests logical access under the common criteria for logical and physical access, while HIPAA requires access controls and unique user identification under the Security Rule's technical safeguards. Both expect least-privilege provisioning and timely removal, yet HIPAA also asks for documented role-based access tied to ePHI. Confirm that your SOC 2 access population includes every system holding ePHI, and check the mapping in NIST SP 800-66 Rev. 2 before assuming coverage.
Audit logging and review
SOC 2 looks for monitoring of system activity and evidence that anomalies are reviewed, while HIPAA requires audit controls that record and examine activity in systems containing ePHI. A SOC 2 sample may not show the retention period, log review frequency or coverage of ePHI databases that HIPAA assessors ask about. Confirm log scope against your own risk analysis, not against the sampled controls in the report.
Change management
Both frameworks expect changes to production systems to be authorized, tested and recorded. SOC 2 evaluates this through change management criteria in the common criteria, and HIPAA addresses it through security management and configuration process requirements in the Security Rule. The overlap breaks down when ePHI-specific configuration baselines or patch timing rules are not part of the SOC 2 system description. Check whether your change process covers those items explicitly.
Incident response
SOC 2 tests whether incidents are identified, responded to and remediated under the system operations criteria. HIPAA adds security incident procedures, documented response and mitigation, and breach notification duties that a SOC 2 does not test. Business associates must also meet notice duties to covered entities under their contracts. Confirm that your incident runbook names ePHI breach decisions and contract notice timelines, which a SOC 2 report will not verify.
Vendor and subcontractor oversight
SOC 2 covers vendor risk management in the risk mitigation criteria, and buyers often accept a subservice organization carve-out or inclusive report. HIPAA requires business associate agreements and that subcontractors handling ePHI meet the same Security Rule obligations. A carved-out subservice organization still needs its own assurance under HIPAA, so confirm which vendors touch ePHI and how each one's assurance is collected.
Encryption and system monitoring
SOC 2 tests encryption and monitoring only where your chosen criteria and system description include them, while HIPAA treats encryption as an addressable safeguard that must be assessed and either implemented or justified with an equivalent measure. Ask whether your SOC 2 description states the encryption standards and key management for ePHI stores and transmissions. Confirm the HIPAA addressable decision in your own documentation, since no report records that reasoning.
Business associate duties no SOC 2 report replaces
A business associate working through these duties builds the HIPAA Security Rule record that a SOC 2 report does not contain, and each step ends with a document a reviewer or OCR investigator can check. The sequence starts with scope and ends with the liability you accept by handling ePHI.
Confirm your status and the ePHI in scope
Establish whether your organization acts as a business associate for each customer, and list the systems, data flows and subcontractors that create, receive, maintain or transmit electronic protected health information for that customer. Legal or privacy counsel usually owns the status question, while engineering and operations supply the system inventory. The step is complete when the team can name each covered entity relationship and the systems that touch its ePHI. This inventory is the boundary for every later step, and a SOC 2 system description can help only if its boundary matches the ePHI boundary.
Comply with the Security Rule standards
Business associates must comply with the Security Rule's standards and implementation specifications under 45 CFR 164.302, which spans administrative, physical and technical safeguards plus organizational and documentation requirements. Security or compliance leads assign an owner to each standard and map existing controls to it, using the official Appendix A matrix as the checklist. The output is a gap list showing which standards have an owner, a control and evidence, and which do not. Confirm each item against the regulation text itself, because a SOC 2 criterion can cover some safeguards while leaving others untouched.
Perform and document the risk analysis
Run the risk analysis required by 45 CFR 164.308(a)(1)(ii)(A), which calls for an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI in scope. The analysis can be done internally or by an external firm, but the business associate remains responsible for its accuracy. The output is a dated, written analysis that lists threats, vulnerabilities, likelihood, impact and the chosen responses. A SOC 2 report does not substitute for this document, because the report tests selected controls against chosen criteria rather than assessing the ePHI risk picture.
Decide on each addressable specification
For each addressable implementation specification, assess whether it is reasonable and appropriate for your environment, as 45 CFR 164.306(d) requires. If it is not reasonable and appropriate, document why and implement an equivalent alternative measure where that is reasonable and appropriate. Compliance and engineering leads record the decision, the reasoning and the alternative in the same file as the risk analysis. The output is a decision log with one entry per addressable specification. Auditors and OCR reviewers look for this reasoning, and a clean SOC 2 opinion on a related control does not show that the decision was made or documented.
Maintain required safeguards and documentation
Operate each required implementation specification and keep the policies, procedures and records that the documentation standard in 45 CFR 164.316 requires. Security and operations teams own the day-to-day controls, while the compliance owner reviews the records on a schedule the organization sets. The output is a current policy set, a record of security activity and evidence that controls ran as written. Ask the organization to confirm the retention and review cadence it adopts, since the federal text does not fix a single interval for every record in this step. A SOC 2 Type 2 can test some of these operations, but it does not establish that every required specification exists in your documentation.
Extend the same duties to subcontractors
Where you rely on subcontractors that create, receive, maintain or transmit ePHI for you, the Security Rule expects you to bring them under the same safeguards through written agreements. Vendor management owns the subcontractor inventory and contract review, and legal reviews the agreement language. The output is a signed agreement for each subcontractor with ePHI access and a record of how its safeguards were checked. Confirm the agreement terms with counsel, because the required clauses and the depth of your review are set by the regulation and your own contracts, not by a SOC 2 report from your own auditor.
Accept direct liability to OCR
Business associates are directly liable to the HHS Office for Civil Rights for Security Rule failures, so an OCR investigation or audit can name your organization regardless of what your customers' contracts say. Executive leadership and legal own this exposure, and the security program must be able to show the records from earlier steps on request. The output is a leadership-approved summary of the program, the open risks and the remediation owners. The HHS direct liability fact sheet and the OCR audit program describe the scope of this exposure. Confirm the penalty amounts with the current federal figures before you brief the board.
Who assesses each framework, what is issued and how often
This table compares who checks HIPAA and SOC 2, what each produces and how often the check happens. Read it to see that HIPAA has no certificate and no fixed external audit cycle, while SOC 2 gives you a CPA report whose scope depends on the engagement period you buy.
| Question | HIPAA Security Rule | SOC 2 |
|---|---|---|
| Who assesses compliance | No certifying body. The covered entity or business associate evaluates itself, internally or with an external firm it hires. | A licensed CPA firm acting as service auditor under AICPA attestation standards. |
| Is a certificate issued | No. HHS does not endorse or recognize private certifications, and they do not prevent a later violation finding. | No certificate. The output is an attestation report with management's assertion and the auditor's opinion. |
| Report types available | None defined by HHS. Documentation of the risk analysis and safeguards is the evidence regulators request. | Type 1 (design as of a date) or Type 2 (operating effectiveness over a period), plus SOC 3 as a general-use alternative. |
| Who can read the output | Regulators request your documentation directly during investigations or audits. | SOC 2 use is generally restricted to specified parties; SOC 3 is general use and freely distributable. |
| Who enforces or requests it | HHS OCR, through complaint investigations, compliance reviews and audits. Its 2024 to 2025 audit program reviews 50 covered entities and business associates. | Customers and their procurement or risk teams request it contractually. No regulator requires it. |
| How often it recurs | Set by law and OCR action, not by a fixed cycle. The proposed annual compliance audit in 90 FR 898 is not final. | Set by the engagement period you buy, typically an annual Type 2 if customers expect current evidence. Confirm cadence with your auditor. |
SOC 2 Type 1, Type 2 and SOC 2+ for a HIPAA-regulated vendor
A Type 1 report covers the system description and the suitability of control design as of a specific date. The CPA examines whether the controls you describe are designed to meet the selected trust services criteria at that point, but does not test whether they operated over time. For a HIPAA-regulated vendor, it can show that a security program exists on paper and that management has described it in a way a service auditor accepts.
- Point-in-time scope: The opinion applies to one date, so it says nothing about access reviews, incident handling or patching during the months before or after.
- Design, not operation: A control can be well designed and still fail in practice. Type 1 does not show that workforce access was removed on termination.
- Early stage use: Buyers sometimes accept Type 1 while a Type 2 observation period is still running, especially for a first-year vendor.
- Security Rule gaps: It does not address the risk analysis under 45 CFR 164.308(a)(1)(ii)(A), business associate agreements or breach handling.
- Quote details to request: Ask the auditor which trust services categories were in scope and which criteria were excluded.
Before accepting a Type 1 as evidence, confirm the examination date, the scope of systems described and whether the report is a general use SOC 3 or a restricted SOC 2.
A Type 2 report adds an opinion on operating effectiveness over a stated period, so the auditor samples evidence that controls ran as described. Healthcare buyers usually request it because it shows sustained operation of access, change and monitoring controls. It is still an attestation against the AICPA trust services criteria, not an assessment against the HIPAA Security Rule standards.
- Observation window: Ask for the period covered, since a short window gives less evidence of repeated operation.
- Exceptions: Read the testing results and any deviations, which often matter more than the opinion itself.
- Access and logging: Check whether the tested access reviews and log controls cover systems that store ePHI, not only corporate systems.
- Subservice organizations: Confirm how cloud hosts and other subservice providers are handled, carved out or included.
- Security Rule gaps: Type 2 does not replace the annual evaluation the Security Rule expects, the documented risk analysis or direct liability obligations as a business associate.
Request the full report under the customer's NDA, the management assertion and the list of exceptions before relying on it for a healthcare procurement.
A SOC 2+ examination reports on the trust services criteria and also addresses additional criteria or subject matter. The AICPA's October 2022 SOC 2 guide includes an illustrative SOC 2+ report for this purpose. For a HIPAA-regulated vendor, the extra subject matter could be a set of healthcare-specific requirements that the vendor and the customer have agreed in writing. Whether any SOC 2+ content maps to HIPAA depends entirely on what the engagement defines, so the reader must read the criteria, not the label.
- Defined extra criteria: Confirm the added criteria are written in the engagement letter and the report, with their source named.
- Mapping to the Security Rule: A SOC 2+ report does not become a HIPAA finding because it mentions healthcare. Ask whether any HIPAA standard was tested or only referenced.
- Auditor experience: Ask whether the CPA firm has performed SOC 2+ examinations before and how it sets the criteria.
- Cost driver: Each added criterion usually adds testing work, so the quote should list it separately.
- Limits: A SOC 2+ still leaves open the risk analysis, workforce training records and business associate agreements unless they are expressly included.
Ask for the criteria document before signing the engagement, and confirm which parts of the report the customer's compliance team will accept.
A SOC 3 report covers the same trust services categories as SOC 2 in less detail, with no description of tests or results. SOC 3 reports are general use reports that can be freely distributed, such as posting on a trust page or sending to prospects. Use of a SOC 2 report is generally restricted to the service organization, its existing customers and their auditors, so a healthcare buyer usually receives the full SOC 2 under NDA.
- Public summary: A SOC 3 is suitable for early sales conversations before a buyer asks for the restricted report.
- Less detail: It does not show the testing performed, the exceptions or the system description in depth.
- Security Rule gaps: It offers no evidence on ePHI safeguards, the risk analysis or business associate duties.
- Distribution rules: Confirm with the CPA whether the SOC 3 report and the SOC 2 report are issued together for your engagement.
- Procurement use: Healthcare security reviews typically ask for the restricted SOC 2 rather than the SOC 3.
Before publishing a SOC 3, confirm with your auditor that its scope matches the SOC 2 and that no statement in your marketing overstates what it shows about HIPAA.
What drives the cost of SOC 2 and HIPAA work
Start by separating the cost components, because the two programs are paid for differently. For SOC 2, the most visible fee is the CPA firm's examination, which is a recurring engagement. Alongside it sits the internal cost of building and operating the controls the report tests, such as access reviews, change management and monitoring, which the company pays for in staff time and tooling. For HIPAA, there is no examination fee at all. The costs are the risk analysis required under 45 CFR 164.308(a)(1)(ii)(A), the remediation of what that analysis finds, the documentation the Security Rule expects, and any outside help you buy to do the work.
The only published cost figures in the research come from the Justice Department's regulatory analysis for its October 2024 proposed rule on US sensitive personal data (89 FR 86116). That analysis cited estimates drawn from vendor publications of $5,000 to $25,000 for a SOC 2 Type 1 audit and $30,000 to $100,000 for a Type 2 audit. Treat these as an outside reference point from a different context, not as a quote for your engagement. Ask each CPA firm for a fixed-scope proposal that lists the trust services categories, the number of systems in the boundary and the observation period, since those inputs set the price.
HIPAA costs have no published price, and they are driven by the scope of systems that hold ePHI and by what the risk analysis finds. A narrow environment with few integrations and mature logging will cost far less to document and fix than a platform with many data flows, legacy components or open risk items. Before you request outside help, ask each provider to state in writing what they will deliver for the risk analysis, how remediation is priced separately from assessment, and whether they will update the analysis when the proposed Security Rule changes take effect. The status of that proposed rule should be confirmed with the Unified Agenda entry for RIN 0945-AA22.
Which to fund first and how to sequence both
The sequence puts the HIPAA duties that no report replaces first, then builds one control set that a SOC 2 auditor can test later. Each step ends with a written output you can show customers and counsel.
Map where ePHI lives and flows
Engineering and the privacy or compliance lead list every system, database, backup, log store, support tool and subprocessor that creates, receives, maintains or transmits electronic protected health information. Include environments outside production, such as analytics copies and test data drawn from live records. The output is a data flow inventory with an owner for each system. You know this step is done when a reviewer can trace one patient record from intake to deletion and every hop appears on the inventory. Confirm the scope with your customers, since the covered entity and business associate roles set which duties apply to you.
Complete the documented risk analysis
The security officer leads an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI in that inventory, as 45 CFR 164.308(a)(1)(ii)(A) requires. The team may run it internally or with an external firm, and NIST SP 800-66 Rev. 2 offers sample questions for each standard. The output is a dated risk register with likelihood, impact, the owner of each risk and a treatment decision. You know this step is done when every system on the inventory has at least one assessed risk and leadership has signed the register. A SOC 2 report does not replace this document.
Run a Security Rule gap assessment
Walk the 18 standards in Appendix A to Subpart C, covering administrative, physical and technical safeguards, plus the organizational and documentation standards in sections 164.314 and 164.316. For each implementation specification, record whether it is required or addressable. For each addressable one, document either the implementation or the reasons it is not reasonable and appropriate, along with any equivalent alternative measure, as 45 CFR 164.306(d) requires. The output is a gap list with remediation owners and a policy set that matches what the systems actually do. You know this step is done when no standard is left without a documented status.
Select Trust Services Criteria and map controls once
Choose the trust services categories that match your customer commitments. Security is always in scope through the common criteria CC1 to CC9, and availability, confidentiality, processing integrity or privacy are added only when they are promised in contracts. Build a single control matrix that links each Security Rule safeguard to the relevant common criteria and to any added category, so one control serves both obligations. The output is one control register with a column for each framework, reviewed by counsel for legal sufficiency. You know this step is done when every control has an owner, a test procedure and a link to evidence.
Close gaps and collect operating evidence
Engineering and operations implement the remediation items from the gap list and start producing recurring evidence, such as access reviews, change tickets, backup restore tests, vulnerability scan results and training records. Business associate agreements with subcontractors and vendors are reviewed in the same pass, because business associates must comply with the Security Rule and are directly liable to OCR for Security Rule failures. The output is a dated evidence library tied to the control register. You know this step is done when a sample of controls can be re-performed from stored evidence without asking the owner to reconstruct it.
Decide when a SOC 2 is required
Ask the customers and prospects who request assurance which report they accept, which Trust Services Criteria they expect and whether they want a Type 1 or Type 2. Check whether a SOC 2+ examination is needed for criteria or subject matter beyond the trust services criteria. The output is a written list of customer requirements that justifies the audit spend. You know this step is done when every requirement is traced to a named contract or security questionnaire. Confirm the choice with your sales and legal teams before engaging an auditor.
Engage a CPA for the SOC 2 examination
Select a CPA firm to perform the SOC 2 examination under AT-C section 205. Management prepares the system description against the 2018 description criteria and provides the written representations the auditor requires. Because the control register already maps both obligations, the team can reuse evidence rather than rebuild it for each request. The output is the SOC 2 report, which the CPA issues and which customers may use under the restricted-use rules. You know this step is done when the report is issued and its scope matches the register. The HIPAA duties remain your own responsibility throughout, since the report does not certify HIPAA compliance.
Maintain the program and watch for rule changes
Assign an owner to review the risk analysis and gap list on a recurring cycle, update the control register when systems change, and track the HHS proposed Security Rule revision of January 2025, which has not been finalized. The output is an annual review record and a change log that show the program is kept current. You know this step is done when the risk register, control register and SOC 2 system description still describe the same environment. Confirm any future audit or assessment requirements with counsel as they are finalized.
Questions buyers ask before hiring outside help
Does a SOC 2 report satisfy HIPAA?
No. A SOC 2 report is a CPA attestation on controls against the trust services criteria, while HIPAA is a legal duty under the Security Rule (45 CFR Part 164 Subpart C) enforced by HHS OCR. A SOC 2 can give a customer useful evidence about some safeguards, but it does not test your Security Rule standards as written, does not cover your risk analysis, and does not discharge your duties as a covered entity or business associate. Ask the auditor which Security Rule standards, if any, the report addresses, and treat the answer as a scope statement, not a compliance statement.
Does HIPAA have a certificate I can buy?
No. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that a third-party certification does not stop HHS from later finding a violation (HHS FAQ 2003). Any vendor selling a "HIPAA certified" badge is offering a private claim, not a federal credential. Ask what the badge is based on, who issued it, and whether it would survive an OCR investigation of your organization.
What does the work need from our internal staff?
Plan for named owners in security, engineering, operations, HR and legal, because an outside firm cannot make your policies, access decisions or system changes on its own. Staff typically supply system inventories, network and data flow diagrams, vendor contracts, access listings, incident records and evidence of training and sign-off. Ask the provider to list every artifact it needs, who in your organization supplies it, and by when, and confirm in the written scope who approves each policy.
Can our team run the HIPAA risk analysis alone?
A small team can often do it with outside support, but the work depends on how well it knows its ePHI flows and threats. The Security Rule requires an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI (45 CFR 164.308(a)(1)(ii)(A)). NIST SP 800-66 Rev. 2 (February 2024) gives key activities, descriptions and sample questions for every standard, and HHS lists it as informational rather than legally binding. Drivers of effort include the number of systems and data stores, third-party integrations, hosting model and how many prior assessments exist. Ask whether the team will document the method, the threat sources considered and how each risk was rated and treated.
How long does a SOC 2 Type 2 observation window run?
A Type 2 report covers operating effectiveness over a period, while a Type 1 covers the system description and control design as of a single date (AICPA guidance). The period itself is set by you and your auditor and is not fixed by the framework, so confirm the window and its start date before signing. Plan for the auditor to test controls across that window, which means controls must already be operating when observation starts. Ask the provider how it will prepare evidence for the full period rather than only at the end.
What drives the cost of SOC 2 and HIPAA work?
Cost splits into the auditor's fee, which is paid for the attestation, and the implementation work, which is paid to whoever designs and builds controls, along with internal staff time. The Justice Department's regulatory analysis for its October 2024 proposed rule (89 FR 86116) cited vendor-sourced estimates of $5,000 to $25,000 for a SOC 2 Type 1 and $30,000 to $100,000 for a Type 2, so treat those as a rough external reference rather than a quote. Recurring costs include annual audits, control operation and remediation. Drivers include the number of trust services categories in scope, system complexity, the state of existing controls and how much evidence is already collected. Ask for line items separating audit, remediation, HIPAA risk analysis and ongoing support.
What should we ask for in a written scope?
A written scope should name the systems, locations, data types, third parties and time period covered, and it should state what is excluded. For a HIPAA engagement, ask for the Security Rule standards addressed, the risk analysis method, the policy and documentation set, and who approves each deliverable. For a SOC 2 engagement, ask which trust services criteria are in scope, whether the report is Type 1 or Type 2, and which auditor performs the attestation. Also require a deliverables list, acceptance criteria, a responsibility matrix, change-control rules and a statement of what the provider does not certify. DeployOpen plans and prepares controls and evidence for compliance assessments, but independent auditors issue the reports, so your scope should separate those roles.
How DeployOpen prepares evidence for both
DeployOpen plans, implements, documents and prepares evidence for HIPAA Security Rule readiness and for SOC 2 examinations, inside your own cloud accounts, data centers or air-gapped networks. The work product is controls, configuration and evidence, not a report: DeployOpen does not issue audit reports, attestations or certifications. A CPA firm performs the SOC 2 examination and HHS, not a vendor, decides what a HIPAA review means for you. Ask any implementation partner, DeployOpen included, to put that boundary in the statement of work so nobody later reads readiness work as an attestation.
Because much of the evidence overlaps, the practical approach is one control inventory mapped to both bodies of work. For example, an access review for a hosted EHR integration can serve as evidence for the Security Rule's access control standard and for the logical access criteria in a SOC 2, provided the review is dated, owned and retained the same way for both. DeployOpen's scope would typically cover the risk analysis support, the policy and procedure set, the logging and backup configuration and the evidence collection runbook, while your auditor and your compliance lead decide how each item is presented. Confirm the mapping with your CPA firm before the period starts.
Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. Ask for a written list of which systems, environments and HIPAA standards are covered, who on your side owns each evidence item, and which deliverables are documentation versus configuration changes. Ongoing evidence collection, control testing and upgrades can be added as a retainer. Request a quote built from that written scope, since DeployOpen does not publish a price list.
How DeployOpen scopes and supports SOC 2 and HIPAA readiness
DeployOpen handles SOC 2 and HIPAA as separate workstreams, because a SOC 2 report does not establish HIPAA compliance. We plan, implement and document the controls that each one needs, inside your own infrastructure, and hand over the evidence your team and your independent assessors will review.
How we scope
- Written scope names the systems holding ePHI and the systems in SOC 2 scope, so both are mapped separately.
- Scope states whether SOC 2 covers only the common criteria or adds availability, confidentiality, processing integrity or privacy.
- Scope lists the risk analysis, business associate duties and policy work that a SOC 2 report does not replace.
How we build
- We implement and harden controls on your self-hosted platforms in your cloud accounts, data centers or air-gapped networks.
- We configure access control, logging, backup and change management evidence so it can be pulled for both assessments.
- We test the controls against the agreed criteria and record gaps, owners and remediation steps before handover.
How we hand over
- You receive control documentation, system descriptions and evidence packs organized by control and by Security Rule standard.
- Deliverables are documented as agreed in the written scope, so you can show what was built and what remains your responsibility.
- We prepare evidence for your auditors and assessors but do not issue audit reports, attestations or certifications.
How we support
- Engagements are fixed-scope, and the scope and timeline are agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer to keep controls current between assessments.
- Confirm with your CPA firm and privacy counsel which SOC 2 criteria and HIPAA duties apply to your services before scoping begins.
