Healthcare compliance frameworks compared

Which healthcare compliance framework to pursue first

For a provider, health plan or health tech vendor selling to covered entities, HIPAA Security Rule compliance is the legal duty that applies first. Covered entities and business associates must comply with the Security Rule for electronic protected health information, so it is not optional and it is not chosen for its proof. The other frameworks are chosen because a customer, a payer or an assessor asks for evidence. There is no HIPAA certificate: HHS states that no Security Rule standard requires certification and that it does not endorse or recognize private certifications. HITRUST, SOC 2 and ISO 27001 each produce a certificate or report from a third party (an authorized HITRUST External Assessor, a CPA firm, or an accredited certification body), while the NIST CSF is a voluntary structure with no certification at all.

Order the work by buyer type. A provider or health plan buying a vendor usually asks first for HIPAA alignment evidence and a risk analysis, and may then ask for HITRUST or SOC 2 if its own vendor review requires an independent report. A health tech vendor selling to many covered entities usually needs a SOC 2 Type 2 report first, because its customers' questionnaires and due diligence favor it, and it can add a HITRUST certification later if specific customers require it. An ISO 27001 certificate is most useful where customers or procurement teams sit outside the US and expect the international standard. Confirm each buyer's exact requirement in writing before committing budget, since requirements differ by contract.

Doing HIPAA and one assurance report together makes sense when a vendor's contracts name a specific report and the Security Rule program is already documented. The HIPAA work produces the risk analysis, policies and evidence that the assurance examination will test, so the two efforts overlap. Plan for the proposed Security Rule changes as well: the January 2025 proposed rule would require penetration testing at least once every 12 months, and as of October 2026 no final rule has been published. Ask your assessor and your customers which report versions and scopes they will accept before you sign a fixed-scope engagement.

How HIPAA, HITRUST, SOC 2, ISO 27001 and NIST CSF differ

This table compares the five frameworks a healthcare organization is most likely to see by legal status, who issues the proof, what it covers, whether it is voluntary and what the official output is. Read the first two rows before the rest, because HIPAA sets the legal baseline and the other four are evidence of control, not substitutes for it.

Dimension	HIPAA Security Rule	HITRUST CSF	SOC 2	ISO 27001	NIST CSF 2.0
Legal status	Binding federal regulation for covered entities and business associates handling electronic protected health information	Voluntary private framework; no legal force on its own	Voluntary attestation; contracts and customers ask for it	Voluntary standard; contracts and customers ask for it	Voluntary framework; no legal force on its own
Who issues the proof	No certification exists; HHS Office for Civil Rights enforces through complaints, reviews and audits	Authorized HITRUST External Assessor organizations perform assessments; HITRUST performs central quality assurance	A CPA firm issues the SOC 2 report	Accredited certification bodies issue certificates; ISO does not certify organizations	No certification; NIST states it has no plans for a conformity assessment program
Official output	None; no Security Rule standard requires certifying compliance	Certification (e1, i1 or r2)	Attestation report (Type 1 or Type 2)	Certificate	None
Coverage	Electronic protected health information, with 18 standards and 36 implementation specifications in Appendix A to Subpart C	Harmonized control set built on ISO/IEC 27001 and 27002 and mapped to HIPAA and NIST SP 800-53 Rev. 5	Controls for the system description and selected Trust Services Criteria in scope	Information security management system across the organization within the certificate scope	Cybersecurity outcomes across six functions, with informative references to other standards
Required and addressable specifications	14 required and 22 addressable specifications; addressable ones need a documented assessment and a reasonable alternative if not implemented, so the rule cannot be met by ticking a list	Not applicable; requirements are control statements, not a legal test	Not applicable	Not applicable	Not applicable
Cycle	Continuous obligation; the proposed January 2025 rule would add penetration testing at least every 12 months	e1 and i1 valid for one year; r2 valid for two years with an interim assessment in the 90 days before the first anniversary	Type 1 is a point-in-time review; Type 2 covers an observation period	Surveillance and recertification cycle set by the certification body	Self-directed; no assessment cycle set by NIST
Fit	Every covered entity and business associate that handles electronic protected health information must comply	Useful when customers or partners want a single, scored assessment across many sources	Useful for service organizations selling to US enterprises that ask for independent controls evidence	Useful for organizations that want an internationally recognized management system	Useful as a shared vocabulary and planning tool, mapped to other standards

Why HIPAA is the legal baseline and what HHS does with certifications

HIPAA's Security Rule is the legal floor for any covered entity or business associate handling electronic protected health information, and no private certificate changes that. The rule at 45 CFR Part 164 Subpart C (sections 164.302 to 164.318) sets 18 standards across administrative, physical and technical safeguards, with 36 implementation specifications: 14 required and 22 addressable. Sections 164.314 and 164.316 add organizational and documentation standards. HHS states that no Security Rule standard requires an entity to certify compliance, and that it does not endorse or recognize private certifications. A HITRUST, SOC 2 or ISO 27001 report can support your evidence file, but it does not prove compliance to OCR and does not stop OCR from later finding a violation.

Addressable does not mean optional. For each addressable specification, you must assess whether it is reasonable and appropriate for your environment. If it is not, you must document why and implement an equivalent alternative measure where that is reasonable and appropriate (45 CFR 164.306(d)). In practice, a hospital that decides not to deploy a given encryption or audit control needs a dated decision memo, the risk analysis behind it and the compensating control in place. Ask your assessor or internal compliance lead to show you that trail for each addressable item, because a missing rationale is a finding even when the technical control looks adequate. The NIST SP 800-66 Rev. 2 resource guide gives sample questions for every standard and is useful for building that documentation, though HHS lists it as informational rather than binding.

OCR enforces the rule through complaint investigations, compliance reviews and audits. Its 2024 to 2025 HIPAA audits review 50 covered entities' and business associates' compliance with the provisions most relevant to hacking and ransomware. For penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty ranges from $145 per violation (no knowledge) to $2,190,294 per violation (uncorrected willful neglect), with a calendar-year cap of $2,190,294 (45 CFR 102.3). Confirm the current figures with counsel before you use them in board materials, since the amounts are adjusted periodically. The practical lesson is that the evidence you keep for each addressable decision and each risk analysis is what you will be asked to produce.

How recognized security practices under the 2021 HITECH amendment fit in

The 2021 HITECH amendment does not give covered entities a safe harbor, but it does ask OCR to weigh recognized security practices. The cards below separate what the amendment requires from what you must still map and document yourself.

What the amendment asks OCR to consider

Under the 2021 HITECH amendment, OCR must consider in certain Security Rule enforcement and audit activities whether an entity has shown that recognized security practices were in place for the prior 12 months. This is a factor OCR weighs, not a safe harbor that excuses a violation. Confirm with counsel how your practices would be documented if OCR asks, and keep dated evidence covering the full 12-month look-back.

Recognized practices are not a certificate

HHS does not endorse or recognize private certifications for the Security Rule, and certifications such as HITRUST, SOC 2 or ISO 27001 do not relieve a covered entity of its legal obligations. A HITRUST or SOC 2 report may be useful evidence of control operation, but it does not by itself establish that recognized security practices were in place. Ask your assessor how their report maps to Security Rule standards before relying on it.

Parallel frameworks you must map yourself

The frameworks that may qualify as recognized security practices are not listed here as a fixed set. Your team must decide which candidate frameworks you follow, then map each one to the Security Rule standards in 45 CFR 164.308, 164.310, 164.312, 164.314 and 164.316. Document the mapping, the gaps and the compensating measures, because a mapping that exists only in a vendor's marketing sheet will not carry much weight.

NIST SP 800-66 Rev. 2 as a starting map

NIST SP 800-66 Rev. 2, published in February 2024, is a resource guide for implementing the HIPAA Security Rule. It gives key activities, descriptions and sample questions for every standard. HHS lists it as informational rather than legally binding, so use it to structure your mapping and evidence, not as a checklist that proves compliance on its own.

Evidence for the look-back period

Because OCR looks at the prior 12 months, a control that was adopted last quarter has limited value as evidence. Keep dated records of configuration baselines, access reviews, penetration test results, training completions and risk analysis updates. Ask any external assessor to confirm which evidence falls inside the window and which controls were operating throughout it.

Proposed rule would add annual testing

HHS's January 2025 proposed rule would require penetration testing of relevant electronic information systems by a qualified person at least once every 12 months, or more often if the risk analysis calls for it. The rule is not final. Plan your evidence program so that an annual test can be added without redesigning the program, and check the current status in the Federal Register and the Unified Agenda before setting budgets.

What the proposed Security Rule changes would add

The HHS proposed a major revision to the HIPAA Security Rule on January 6, 2025 (90 FR 898, RIN 0945-AA22), and the most concrete change for technical teams is a penetration testing requirement. As proposed at 45 CFR 164.312(h)(2)(iii), relevant electronic information systems would need penetration testing by a qualified person at least once every 12 months, and more often if the risk analysis calls for it. Treat this as a direction of travel, not a settled obligation. Today's Security Rule does not set a fixed testing interval, so a yearly test would be a new recurring cost and a new evidence stream for most covered entities and business associates.

As of October 2026, no final rule has been published. The latest Unified Agenda entry for RIN 0945-AA22 lists the rulemaking under Long-Term Actions, with final action projected for July 2027. That date is a projection and can move. Confirm the status on the Federal Register rule record and the Unified Agenda entry before you set budget or contract terms, and check whether the final text keeps the 12-month interval, the "qualified person" wording and the risk-analysis trigger, since each one changes who performs the test and how often.

Practical planning does not require waiting for the final text. Ask whether your current penetration testing covers the systems that hold electronic protected health information, record who performed each test and what the scope was, and keep the risk analysis that would justify a more frequent cadence. Confirm with your counsel and your assessor which requirements are in force today under the existing rule and the 2021 HITECH recognized security practices provision, and which are only proposed. Scope any testing work so it can be extended or repeated on a yearly cycle, and write the contract so a change in the final rule can be handled as a scope change.

Where the controls overlap and where they do not

Healthcare teams often face HIPAA, HITRUST, SOC 2, ISO 27001 and the NIST CSF at once, and the frameworks share a lot of control language. The overlap is real in the sense of shared mappings, but a mapping only shows where two sets of controls address similar topics, not that one report satisfies the other.

HITRUST harmonizes many sources

HITRUST describes its CSF as harmonizing 60 or more authoritative sources on its product pages and over 70 on its framework page, including ISO/IEC 27001 and 27002, NIST SP 800-53 Rev. 5, HIPAA, PCI and GDPR. For a healthcare team, this makes HITRUST a useful map of where HIPAA duties meet other frameworks. Ask HITRUST or your assessor which mapping version your assessment uses, because the mapped sources change with each CSF release.

CSF core rests on ISO 27001

The HITRUST CSF's core structure is based on ISO/IEC 27001 and 27002, so controls in the two frameworks often share a common structure. Teams that already run an ISMS can reuse policy and risk work as a starting point. The gap is in healthcare specifics, such as the Security Rule's required and addressable implementation specifications, which an ISO 27001 scope does not settle on its own.

NIST CSF maps to 800-53 and ISO

NIST's CSF 2.0 Reference Tool lists informative references to ISO/IEC 27001:2022 and SP 800-53 Rev. 5.2.0, among others. The Center for Internet Security's Controls Navigator also maps NIST CSF 2.0, SOC 2 and ISO/IEC 27001:2022 to its controls. NIST states that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement, so verify each row before you cite it to an auditor.

Mappings are not equivalence

ENISA states that its mapping is not a measure of equivalence and does not assess whether a standard fully covers a regulation's requirements. NIST makes a similar point about its informative references. A row that says two controls relate does not show that a SOC 2 Type 2 report covers a HIPAA addressable specification. Ask each assessor to state which requirements their evidence actually supports.

Reusing SOC 2 evidence

PCI SSC guidance says a QSA cannot rely on SOC 2 or SOC 3 reports for a PCI DSS assessment, but may reuse evidence from those audits after independently reviewing it. That rule is specific to PCI DSS. For a HIPAA risk analysis, a HITRUST assessment or an ISO 27001 audit, check with the relevant assessor whether any SOC 2 evidence is accepted, and under what review, before you plan to reuse it.

Control IDs differ by framework

Even where two frameworks cover the same topic, they number and scope controls differently. HIPAA's Security Rule uses standards and implementation specifications in sections 164.308, 164.310 and 164.312, while HITRUST uses its own control categories and specifications. Build a control register with one row per obligation, and record which framework's control ID each row satisfies, so that evidence is traceable in both directions.

Who assesses each framework and what the result looks like

This table shows who performs the assessment for each healthcare framework, what the result is, and how often it must be repeated. Read it first to see which frameworks produce a certificate, which produce a report and which produce nothing a customer can verify on its own.

Framework	Who assesses	What the result is	Cycle and validity
HIPAA Security Rule	HHS Office for Civil Rights enforces through complaints, compliance reviews and audits; no certifying body exists	No certificate. HHS states no Security Rule standard requires certification and does not recognize private certifications	Continuous legal obligation; OCR 2024 to 2025 audits review 50 covered entities and business associates
HITRUST e1 and i1	Authorized HITRUST External Assessor organizations, with HITRUST central quality assurance before reports issue	HITRUST validated assessment certification	Valid one year; fieldwork window of at most 90 days
HITRUST r2	Authorized HITRUST External Assessor organizations, with HITRUST central quality assurance	HITRUST validated assessment certification at the r2 level	Valid two years; interim assessment due in the 90 days before the first anniversary; fieldwork window of at most 90 days
SOC 2 Type 1	Licensed CPA firm acting as service auditor under AICPA attestation standards	Report on the system description and suitability of control design as of a specific date	Point-in-time; no operating effectiveness opinion
SOC 2 Type 2	Licensed CPA firm acting as service auditor under AICPA attestation standards	Report adding an opinion on operating effectiveness over an observation period	Covers a period of operation; restricted-use report generally shared under NDA
ISO/IEC 27001	Accredited certification bodies operating to ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024; ISO itself does not certify organizations	Certificate of conformity to the ISMS standard, issued by the certification body	Certificate cycle set by the certification body; confirm surveillance and recertification terms with the body
NIST CSF 2.0	Self-assessment by the organization, or third-party assessment chosen by the organization; NIST offers no conformity assessment program	No certificate. Output is the organization's own profile and evidence of outcomes	No fixed cycle; set by the organization or by contracts that reference it

How HITRUST e1, i1 and r2 fit a healthcare program

The e1, i1 and r2 form a traversable portfolio: every e1 requirement is contained in the i1, and every i1 requirement is contained in the r2 baseline. In CSF v11.9, the e1 carries 44 requirement statements and the i1 carries 182. The full CSF is organized into 14 control categories, 49 control objectives and 156 control specifications, and v11.9.0 is the current version available in MyCSF from September 24, 2026. For a healthcare program, this means the scope you assess at the lower levels is a subset you can carry forward rather than rebuild, provided your control owners keep evidence current as you step up. Confirm with your assessor which version and baseline your contracts reference, since a certification dated against an earlier version will not automatically map to the current one.

A customer asking for a HITRUST report usually wants an independent, scored view of controls across the environment that handles their data, not a self-declared questionnaire. The e1 and i1 are typically sufficient when the customer's risk is moderate, the data flow is limited, or the purpose is to show a defined set of baseline practices for a vendor review. The r2 is the better fit when a payer, large health system or regulator-facing partner expects broader coverage and a longer validity window. Certifications from the e1 and i1 are valid for one year and the r2 for two years, with an interim assessment due in the 90 days before the first anniversary, so the recurring effort differs by level. Ask your external assessor which level matches the contract language before you start fieldwork.

A HITRUST certification does not replace the HIPAA Security Rule duty. HHS states that no Security Rule standard requires certification, that it does not endorse or recognize private certifications, and that a certification does not prevent HHS from later finding a violation. Your covered entity or business associate obligations under 45 CFR Part 164 Subpart C continue regardless of the level you hold. Keep your risk analysis, documented decisions on addressable specifications and evidence of ongoing review in your own records, and treat the HITRUST report as one input to a demonstrable HIPAA program. The HHS FAQ on certifications is the right reference to share with customers who assume a certificate settles the question.

In what order to pursue healthcare frameworks

This sequence starts with the legal baseline every covered entity or business associate must meet, then adds the assurance report or certificate customers ask for, then international and mapping layers. Each step produces evidence that the next one reuses, so the work is not repeated for each framework.

Complete the documented Security Rule risk analysis
Covered entities and business associates must comply with the Security Rule for electronic protected health information, so this comes first for every healthcare reader. Your security or compliance lead, with the privacy office and system owners, inventories where ePHI is created, received, maintained or transmitted, identifies threats and vulnerabilities, and rates the risk. The output is a written risk analysis and a risk management plan that name owners and dates. You know the step is done when a reviewer outside the project can trace each risk to a decision and a control.
Decide each addressable specification in writing
Each Security Rule implementation specification is either required or addressable. For an addressable one, the entity must assess whether it is reasonable and appropriate, and if it is not, document why and implement an equivalent alternative measure where that is reasonable. Legal, compliance and the technical owners make these decisions together, and the outcome is a decision record per specification with a rationale. NIST SP 800-66 Rev. 2, which HHS lists as informational rather than binding, gives sample questions you can use to test each decision. The step closes when every addressable item has a documented yes, no or alternative, signed off by an accountable executive.
Map controls to the Security Rule and the framework you will test
Build one control register that maps each safeguard to the Security Rule standards and to the criteria you expect an assessor to test. For SOC 2, that means the common criteria and any optional categories in scope. For HITRUST, that means the e1, i1 or r2 requirement statements. Security and GRC staff own the register, and control owners attest to how each control works. The output is a traceable register where one control can point to several criteria. You know the step is done when a sample of controls can be walked from policy to configuration to evidence without gaps.
Obtain the assurance report customers request
Most US healthcare buyers ask for a SOC 2 report first, and the usual path is a SOC 2 Type 1 report on control design as of a date, followed by a Type 2 report that adds an opinion on operating effectiveness over a period. A CPA firm performs the examination under the AICPA attestation standards, and management provides written representations. For a smaller scope, an e1 or i1 HITRUST assessment may fit better, and an r2 suits a broader scope, but only Authorized HITRUST External Assessor organizations can perform the validated assessment. Your project team prepares the system description and evidence, and the output is a signed report or certification letter. Confirm the report type, scope and validity period with the auditor before you start.
Add ISO 27001 only when international customers require it
ISO does not certify organizations; accredited certification bodies do. Pursue ISO/IEC 27001 when international customers or tenders ask for it, not as a default. The certification body operates to ISO/IEC 17021-1:2015 plus ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. Your team reuses the control register and adds an information security management system around it, including scope, risk treatment and internal audit. The output is a certificate from an accredited body. Confirm with that body how it will handle a shared control set and any overlap with your existing SOC 2 evidence.
Use the NIST CSF as the mapping layer
Once the control register exists, map it to the NIST Cybersecurity Framework 2.0 so that leadership, board reporting and partners can read your program in one structure. NIST does not offer certifications or endorsements for CSF implementations, so the output is an internal or third-party-supported mapping, not proof of compliance. Use the CSF 2.0 Reference Tool and its informative references as a starting point, and remember that NIST does not check the correctness of non-NIST mappings. The step closes when each CSF function points to named controls and evidence owners. Treat it as a communication and gap tool, not a substitute for the Security Rule analysis.
Reuse evidence across reports with independent testing
A single control set can feed several reports, but each assessor tests against its own criteria and sampling method, so evidence must be re-examined for each one. Compliance leads keep one evidence library with control IDs, owners, collection dates and test results, then give each assessor the subset its criteria require. Expect the SOC 2 auditor, the HITRUST assessor and any ISO certification body to ask their own questions. Confirm early which evidence each party will accept, and document the mapping in writing. The output is a repeatable evidence cycle that keeps the next report faster without treating one report as proof for another.

Which path fits hospitals, health plans and health tech vendors

Hospitals and other covered health care providers must comply with the HIPAA Security Rule for electronic protected health information. That duty is set by law, and no certificate discharges it. HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications, so a HITRUST or SOC 2 report is evidence you can show a partner, not a legal safe harbor. The HHS Office for Civil Rights enforces the rule through complaint investigations, compliance reviews and audits, and its 2024 to 2025 audit program reviews covered entities against provisions most relevant to hacking and ransomware. Use the list below to plan your evidence.

Legal duty stays with you: Map each Security Rule standard in 45 CFR Part 164 Subpart C to a named owner and a documented control.
Addressable specifications need records: Where you decide an addressable specification is not reasonable and appropriate, document why and the equivalent measure you chose.
Recognized security practices: Ask counsel whether your documented practices in the prior 12 months would be considered by OCR under the 2021 HITECH amendment.
Partner requests: If referring hospitals or payers ask for HITRUST, confirm which assessment level and scope they require before buying one.
Proposed annual testing: The January 2025 proposed rule would require penetration testing at least every 12 months, so plan testing capacity now even though the rule is not final.

Confirm with counsel which obligations apply to your entity type and state, and confirm with each buyer which report they will accept and for which scope.

What buyers ask before they hire outside help

Does HIPAA have a certificate I can earn?

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private organizations' certifications. A private certificate also does not stop HHS from later finding a violation, so a buyer should treat any HIPAA certificate as a marketing or assurance artifact, not a legal safe harbor. Ask a vendor which report or certificate they hold, who issued it, and what it actually covers. The legal obligation is to comply with the Security Rule itself, and HHS's own guidance on that is the place to start.

How long does a HITRUST or SOC 2 cycle run?

It depends on the report and on how often you renew it. A HITRUST e1 or i1 certification is valid for one year, and an r2 certification is valid for two years, with an interim assessment due in the 90 days before the first anniversary. The assessor's validated fieldwork window is at most 90 days for e1, i1 and r2. A SOC 2 Type 1 report covers the design of controls as of a date, while a Type 2 report covers operating effectiveness over a period, so the observation window is set by the scope and the engagement letter. Ask for the planned period, the fieldwork dates and the renewal calendar in writing before work starts.

What drives the cost of a healthcare compliance assessment?

Cost is driven by scope and by how much work sits between your current state and the evidence an assessor needs. The main drivers are the number of systems and data flows in scope, the number of control specifications or criteria being tested, the assessor's fieldwork, and the remediation your team needs before fieldwork starts. Assessor fees are typically one-time per assessment cycle, while readiness support, tooling and internal staff time recur every year. A quote should break out assessor fees, readiness support, remediation work and any renewal or interim assessment. We do not publish prices, and DeployOpen quotes follow from a written scope.

What does the work need from our internal staff?

Internal staff own the facts that an outside party cannot know on its own. Plan for a current asset inventory covering systems that store, process or transmit electronic protected health information, written policies that match how the environment actually runs, and named evidence owners for each control area such as access reviews, backups, change management and incident response. Engineers will also need time for configuration reviews and for remediation. Ask any provider to list the internal roles, the hours they expect from each, and the evidence they will request in the first two weeks.

Can our team prepare for HITRUST or SOC 2 without outside help?

Yes, a team can do readiness work internally, including gap analysis, policy drafting, control mapping and evidence collection. What an internal team cannot do is issue the report that a customer or regulator relies on. HITRUST validated assessments must be performed by Authorized HITRUST External Assessor organizations, and HITRUST performs central quality assurance before issuing reports. A SOC 2 report is issued by an independent CPA firm. Outside help is most useful for independent readiness testing, scoping decisions and evidence review before the assessor arrives. Confirm the assessor's authorization or licensing directly with the certifying body before you sign.

What would the proposed HIPAA penetration testing rule change?

The January 2025 proposed rule would require penetration testing of relevant electronic information systems by a qualified person at least once every 12 months, or more often if the risk analysis calls for it. The proposal is in the Federal Register and has not been finalized. As of October 2026, no final rule has been published, and the Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. Until then, the Security Rule as codified governs. Teams should budget for annual penetration testing as a likely requirement, confirm the final text before committing scope, and check whether the tester's qualifications and report format meet what the final rule requires.

Does the 2021 HITECH recognized security practices amendment change what we need to do?

It does not create a certificate, but it can affect how OCR treats your security program. Under the 2021 HITECH amendment, OCR must consider, in certain Security Rule enforcement and audit activities, whether an entity has shown that recognized security practices were in place for the prior 12 months. Documenting practices over that period, with dated evidence, is therefore more useful than a single assessment snapshot. Ask counsel to confirm how the amendment applies to your entity type and which practices you have adopted, and keep the supporting records current.

How DeployOpen prepares healthcare teams for both frameworks

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence for compliance assessments. We do not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.

How we scope

Engagements are fixed-scope, with systems, controls, deliverables and timelines agreed in writing before work starts.
The written scope names which HIPAA Security Rule safeguards, SOC 2 criteria or HITRUST items the work covers.
Scope also records which environments, hosting accounts and data flows contain electronic protected health information.

How we build

Controls are configured in the client's own cloud accounts, data centers or air-gapped networks, not in a DeployOpen-hosted environment.
Security testing of applications, APIs and infrastructure can be scheduled to cover the penetration testing expectations the client needs to evidence.
Each control is mapped to the framework requirement it supports so the same evidence can serve more than one assessment.

How we hand over

Deliverables include configuration documentation, runbooks, control evidence and records of decisions on addressable safeguards.
Handover records state which items remain the client's responsibility, such as policy approval and workforce training.
Evidence is organized for the assessor the client selects, who decides what sufficiency means for its own report or certification.

How we support

Ongoing support, upgrades, backups and continuous testing are available as retainers, separate from the fixed-scope build.
Retainer scope should be confirmed in writing, including how platform upgrades affect previously assessed controls.
Ask for a quote that separates one-time implementation work from recurring retainer work so the ongoing cost is visible.