The Compliance Atlas·Volume V
Volume V · HITRUST CSF v11 · Edition 2026.1

The Compliance Atlas

Authoritative refs
HITRUST CSF v11.6 (Aug 2025)
MyCSF · Assurance Program v9.x
Verified May 12, 2026

HITRUST is the only framework in the Atlas owned and certified by a private organization. Its product is certainty: a single assessment that maps to ISO 27001, NIST CSF, HIPAA, PCI DSS, GDPR, and dozens more. Customers in healthcare and adjacent industries treat the HITRUST report as table stakes.

Reading the Atlas

Internal — assessed entity External — AEA + HITRUST Bridge / hand-off

Three assessment levels — e1, i1, r2 — calibrated by risk and scope, with very different effort, depth, and certificate validity. The assessor recommends; HITRUST decides.

I.
Layer 01 — Lifecycle

Three certifications, one platform

HITRUST Assurance Program
MyCSF Engagement Manager

The HITRUST cycle — assessor recommends, HITRUST decides

ASSESSMENT TIMELINE → Scoping MyCSF setup Self-assessment Validated QA + decision Cert maintenance Recert INTERNAL — ASSESSED ENTITY EXTERNAL — AUTHORIZED EXTERNAL ASSESSOR + HITRUST Choose level e1 / i1 / r2 risk-driven Define scope orgs · systems · data drives r2 control count MyCSF subscription platform license required · annual fee Risk factors entered org · system · regulatory tailors r2 control set Self-assessment PRISMA scores entered all 5 maturity levels Evidence upload to MyCSF · per ctrl policy · proc · artifacts Bridge cert interim assurance 90-day if delayed AEA selection approved firm list CCSFP staff Engagement contract SOW with AEA scope · timeline · fees Readiness assessment optional but advised pre-validation Remediation work close gaps pre-validation CAPs filed corrective actions for unmet ctrls Interim assessment r2 only · 1 yr in subset retested Recert prep e1/i1: 1yr · r2: 2yr full re-assessment AEA proposal pre-engagement independence checks MyCSF onboarding assessor seat granted view · validate Validation testing walkthrough + sample scoring methodology PRISMA scoring 5 levels per ctrl assessor adjusts entity scores Findings recorded in MyCSF CAPs proposed by entity AEA recommendation to HITRUST cert / no cert HITRUST QA review independent of AEA decision + report Independence affirm no consulting same ctrl HITRUST policy Sample selection judgment · risk-based larger for r2 Internal QC AEA partner review pre HITRUST submit CAP review by HITRUST closed / open / partial 90-day SLA closure Re-validation if QA disputes AEA → entity Cert score threshold 3+ avg for r2 below = letter only Maintenance audit r2 interim · 1 yr ~30-50% retested HITRUST OWNS THE DECISION AEA recommends · HITRUST QA approves · cert issues centrally tailored controls → assessor scoring CAPs proposed → AEA reviews remediation → CAP closure PRISMA self-scores → validated/adjusted

The three assessment levels — e1, i1, r2

e1 · ESSENTIALS e1 cybersecurity hygiene baseline Controls: ~44 foundational Cycle: 1 year · annual recert Scoring: implemented Y/N Effort: 3–4 months Cost: low (under $50k typical) USE WHEN — Small org, just starting compliance — Customer asks for "any HITRUST" cert — Stepping stone to i1 / r2 later — No regulatory pressure yet i1 · IMPLEMENTED i1 leading practices for moderate risk Controls: ~182 baseline set Cycle: 1 year · annual recert Scoring: implemented Y/N Effort: 6–9 months Cost: moderate ($75–150k typical) USE WHEN — Mid-market org with PHI / sensitive data — Customers want HITRUST not "any" — Avoid r2 effort but show real rigor — Strong fit for SaaS in healthcare r2 · RISK-BASED r2 expanded — tailored — gold standard Controls: 200–400 typical (≥225 min) Cycle: 2 years + interim audit y1 Scoring: PRISMA 5-level maturity Effort: 9–18 months Cost: high ($200k–$1M+) USE WHEN — Large org · regulatory mandate — Healthcare payor / provider / vendor — Large customers expect r2 (HCA, BCBS) — Inheritance & reciprocity matter

What HITRUST is selling

HITRUST sells certainty, not controls. The CSF itself borrows almost everything from ISO 27001, NIST 800-53, HIPAA, PCI DSS, and others. What HITRUST adds is (1) tailored control selection based on risk factors, (2) maturity-based scoring (PRISMA), (3) a centralized assessment platform (MyCSF), and (4) a certification body that does QA on the assessor's work. The customer using a HITRUST-certified vendor doesn't need to read 50 SOC 2s to figure out if security is acceptable — they read one HITRUST report.

The MyCSF platform is the audit method. Unlike SOC 2 or ISO 27001 where the auditor controls evidence requests and storage, HITRUST mandates everything happens in MyCSF. The assessed entity uploads evidence; the assessor scores in MyCSF; HITRUST QA reviews in MyCSF; the certificate issues from MyCSF. Reproducible — and somewhat cumbersome — but eliminates the "missing email attachments" problem of traditional audits.

Two-party validation is unique. The Authorized External Assessor performs the work and recommends a result, but HITRUST itself reviews the work and issues the certificate. An AEA cannot simply approve a weak assessment — the QA process catches inflated scoring, missing evidence, or undisclosed findings. Certifications take longer (often 60–90 days from validation completion to certificate issuance) than SOC 2 or ISO 27001.

HITRUST is what happens when you hand a healthcare regulator a SOC 2 and they say "but for everyone, the same way."

Inheritance is the underrated feature. If your cloud provider (AWS, Azure, GCP) has HITRUST-certified controls and you scope MyCSF to inherit them, you don't re-test those controls — they're carried forward. This is why HITRUST is dominant in healthcare SaaS: a startup can stand up a credible r2 assessment in 9 months by inheriting infrastructure controls and only validating the layer they own.

II.
Layer 02 — Control universe

Fourteen categories, nineteen domains

HITRUST CSF v11.x
Categories & Domains

CSF structure — control categories + assessment domains

14 CONTROL CATEGORIES — CONTROL OBJECTIVES 00 Info Sec Mgmt Program governance 01 Access Control Largest category 02 Human Resources Personnel security 03 Risk Mgmt Risk assess & treat 04 Sec Policy Policy framework 05 Org of Sec Internal + external 06 Compliance Legal & regulatory 07 Asset Mgmt Asset inventory 08 Phys & Env Sec Premises & equip 09 Comms & Ops Mgmt Largest beyond 01 10 Sys Acquisition Dev & maintenance 11 Incident Mgmt IR program 12 Business Continuity BC + DR 13 Privacy Privacy practices 19 ASSESSMENT DOMAINS — HOW MyCSF FILES THE EVIDENCE D01 Information Protection Program D02 Endpoint Protection D03 Portable Media Security D04 Mobile Device Security D05 Wireless Security D06 Configuration Management D07 Vulnerability Management D08 Network Protection D09 Transmission Protection D10 Password Management D11 Access Control D12 Audit Logging & Monitoring D13 Education, Training, Awareness D14 Third Party Assurance D15 Incident Management D16 Business Continuity & DR D17 Risk Management D18 Physical & Environmental Sec D19 Data Protection & Privacy CATEGORIES VS DOMAINS 14 control categories are the framework's logical organization (drawn from ISO 27002). 19 assessment domains are how MyCSF groups controls for testing. Mapping is many-to-many: one category contributes controls to multiple domains. When you read a HITRUST report, you read it by domain. When you implement, you implement by category. Most teams build their internal wiki by category and their evidence binders by domain.

Why the architecture looks complicated

HITRUST is a unified framework, not an original one. The 14 control categories closely follow ISO/IEC 27002:2013, with HIPAA-specific additions in category 13 (Privacy). The 19 assessment domains were added to organize evidence collection in MyCSF. This dual structure is what gives HITRUST its breadth — you can map controls to ISO, NIST, HIPAA, and PCI simultaneously — but creates a learning curve when you first encounter both organizations.

Authoritative Sources are the real magic. Every HITRUST control points to its sources: HIPAA §164.312(a)(1), ISO 27001 A.5.15, NIST 800-53 AC-2, PCI DSS Req 7. When you implement a HITRUST control, you can show the evidence to a HIPAA auditor, an ISO assessor, and a PCI QSA — and demonstrate the same control satisfies their requirement. This is the inheritance/reciprocity that makes HITRUST attractive in regulated industries.

HITRUST is not a new framework. It is the rest of the frameworks, certified once.

Risk factors drive r2 control count. When you set up a r2 assessment in MyCSF, you answer questions about your organization (size, regulatory environment), your systems (cloud / on-prem, public / private), and your data (PHI / PCI / PII). MyCSF generates your tailored control set. Two healthcare SaaS companies of the same size can end up with different r2 control counts depending on their answers. This is why "HITRUST has 2,000 controls" is misleading — almost no one tests 2,000.

III.
Layer 03 — PRISMA scoring

Five maturity levels — every control, every dimension

PRISMA scoring methodology
HITRUST Assurance Program

PRISMA — five maturity dimensions assessed per control

PRISMA — POLICY · PROCEDURE · IMPLEMENTED · MEASURED · MANAGED LEVEL 1 Policy documented intent Does a policy exist that addresses this control? Approved by mgmt? Scope defined? Review cadence stated? EVIDENCE — Policy document — Approval record — Review log Most teams have policies. Few have all 5 levels. LEVEL 2 Procedure documented how-to Does a procedure or runbook tell people HOW to do it? Step-by-step? RACI clear? Maintained & current? EVIDENCE — Procedure / SOP — Runbook — RACI matrix LEVEL 3 Implemented actually doing it Is the procedure being followed in practice? Across all in-scope systems? By all personnel? Consistently? EVIDENCE — Tickets, logs — Configuration screens — Sample artifacts Most r2 cert thresholds cluster around level 3. LEVEL 4 Measured tracked & reported Are metrics collected to verify it's working? Reported to mgmt? Trends analyzed? Targets defined? EVIDENCE — KRI dashboard — Metric reports — Trend analysis LEVEL 5 Managed continually improved Are deficiencies driving control changes? Is the control optimized? Improvements measured? Mgmt acting on data? EVIDENCE — Improvement plans — PDCA cycle records — ROI reports Rare. Mature programs only. Lifts the cert score. SCORING Each level rated 1–5. Average across all 5 maturity dimensions per control gives the control's score. Average ≥3.0 across in-scope controls is the typical threshold for HITRUST r2 certification.

What PRISMA actually measures

PRISMA decouples "we have it" from "we measure it." SOC 2 and ISO 27001 ask whether a control operates. PRISMA asks whether it operates and whether you know how well it operates and whether you're improving it. A SOC 2 control is binary (pass/fail). A PRISMA-scored control has texture — you can be at L3 (implemented) without being at L4 (measured). Most controls in most programs sit at L2.5–L3.5.

The maturity dimensions are not equally weighted. Policy (L1) and Procedure (L2) are foundational — without them, the assessor cannot evaluate L3+. Implementation (L3) is the bar most controls need to clear for r2 cert. Measured (L4) and Managed (L5) lift the average above the threshold. Programs targeting only L3 across the board often miss the cert because their L1/L2 documentation is weak.

PRISMA rewards programs that measure their controls, not just operate them. This is HITRUST's quiet bias toward continuous improvement.

The CAP mechanism handles partial failures. When a control scores below threshold, you don't fail the assessment — you file a Corrective Action Plan in MyCSF describing how you'll close the gap and by when. HITRUST QA reviews the CAP. If reasonable, the cert issues with the CAP attached. If unreasonable, the cert is held. Most r2 assessments include several CAPs; pristine assessments are rare.

Inheritance is the lever that moves PRISMA. If your cloud provider operates a control and is itself HITRUST-certified, you can mark the control as "inherited" in MyCSF. The provider's PRISMA score flows through. This is why a startup running on AWS can get to L3 averages on infrastructure controls in months, not years.

IV.
Layer 04 — Cross-framework

HITRUST is the crosswalk made into a product

Authoritative Sources mapping
HITRUST CSF v11.x
HITRUST domain SOX SOC 2 (TSC) ISO 27001:2022 NIST CSF 2.0 PCI DSS v4.0.1 HIPAA Shared evidence
D01 Info Protection Program ELC · governance CC1.1 · CC5.3 Cl. 5 · A.5.1 GV.PO · GV.RR Req 12 §164.308(a)(2) Info sec policy, governance charter, RACI
D02 Endpoint Protection ITGC — Operations CC6.8 A.8.1 · A.8.7 PR.PS-05 Req 5 §164.308(a)(5)(ii)(B) EDR/AV deployment, scan logs, MDM config
D03 Portable Media ITGC — Operations CC6.5 A.7.10 · A.8.10 PR.DS-02 Req 9.4 §164.310(d) Removable media policy, encryption verification
D04 Mobile Device Security ITGC — Operations CC6.7 A.7.9 · A.8.1 PR.PS-05 Req 12.3.10 §164.310(d)(2) MDM enrollment, device inventory, remote-wipe records
D06 Configuration Mgmt ITGC — Change CC6.6 · CC8.1 A.8.9 · A.8.32 PR.PS-01 · PR.PS-06 Req 2 · Req 6.5 §164.308(a)(8) CIS benchmarks, change tickets, drift detection
D07 Vulnerability Mgmt ITGC — Operations CC7.1 A.8.8 ID.RA-01 Req 6.3 · Req 11.3 §164.308(a)(1)(ii)(B) Scan reports, patch SLAs, exception register
D08 Network Protection ITGC — Operations CC6.6 A.8.20 · A.8.22 PR.IR-01 Req 1 §164.312(e)(1) Firewall config, network diagram, segmentation tests
D09 Transmission Protection ITGC — Operations CC6.7 A.8.24 PR.DS-02 Req 4 §164.312(e)(2)(ii) TLS scan, cert inventory, VPN config
D10 Password Mgmt ITGC — Access CC6.1 A.5.17 PR.AA-01 Req 8.3 §164.308(a)(5)(ii)(D) Password policy, MFA enforcement, SSO config
D11 Access Control ITGC — Access CC6.1 – CC6.3 A.5.15 · A.5.18 · A.8.2 PR.AA-05 Req 7 · Req 8 §164.308(a)(3) · §164.308(a)(4) JML tickets, UAR exports, IAM config
D12 Audit Logging & Monitoring ITGC — Operations CC7.1 · CC7.2 A.8.15 · A.8.16 DE.CM-01 Req 10 §164.312(b) SIEM rules, log retention, alert tuning evidence
D13 Education & Awareness ELC · COSO Comp.4 CC1.4 A.6.3 PR.AT-01 Req 12.6 §164.308(a)(5) Completion reports, phishing tests, attestations
D14 Third Party Assurance ITGC + BPC · TPRM CC9.2 A.5.19 – A.5.23 GV.SC Req 12.8 · Req 12.9 §164.308(b) · BAAs Vendor inventory, due diligence pkg, contracts, SOC 2s
D15 Incident Mgmt BPC CC7.3 – CC7.5 A.5.24 – A.5.27 RS.MA Req 12.10 §164.308(a)(6) Incident tickets, IR plan, tabletop reports
D16 BCM & DR BPC · resilience A1.2 · A1.3 A.5.29 · A.5.30 RC.RP Req 12.10 §164.308(a)(7) BIA, BCP/DR plans, last-test report, RTO/RPO docs
D17 Risk Management ELC · risk memo CC3.1 – CC3.4 Cl. 6.1 GV.RM · ID.RA Req 12.3 §164.308(a)(1)(ii)(A) Risk register, RCSA, treatment plan
D18 Physical & Env Sec ITGC — Operations CC6.4 A.7.1 – A.7.14 PR.AA-06 Req 9 §164.310 Badge logs, CCTV retention, visitor log
D19 Data Protection & Privacy ITGC + BPC C1.1 · P1 – P8 A.5.34 · A.8.10 PR.DS-01 Req 3 §164.514 · Privacy Rule Data inventory, classification policy, DSAR log

Why HITRUST customers pay the premium

The crosswalk above is, in essence, what HITRUST sells. A startup pursuing SOC 2 + ISO 27001 + HIPAA separately runs three audits, three sets of evidence, three opinions. The same startup pursuing HITRUST r2 with appropriate Authoritative Sources runs one assessment that yields a single report referencing all three sources. The healthcare buyer knows what they're getting; the startup knows what they paid for.

The trap is that HITRUST is not free — the MyCSF subscription, the AEA fees, the HITRUST QA charges, and the time-to-cert (60–90 days post-validation) all add real cost. Compared to SOC 2 alone, a HITRUST r2 typically costs 2–3× more for an early-stage startup. The math becomes favorable only when you would otherwise pursue 3+ frameworks separately.

HITRUST is the right answer when you would otherwise be building three audit programs in parallel.

The shared-evidence model is HITRUST's native operating mode. Every artifact uploaded to MyCSF is automatically scored against multiple Authoritative Sources. JML tickets satisfy HIPAA §164.308(a)(4), ISO A.5.18, NIST PR.AA-05, PCI Req 7, and HITRUST 01.b simultaneously — all visible in MyCSF, all surface in the HITRUST report's Authoritative Sources mapping. This is GRC engineering by default rather than by deliberate effort.