The HITRUST CSF

The HITRUST CSF is a comprehensive control framework that integrates requirements from dozens of authoritative sources — HIPAA, ISO 27001, NIST SP 800-53, NIST CSF, PCI DSS, GDPR, CMMC-aligned NIST 800-171, and numerous state and federal regulations among them. It is currently in the version 11.x series, which restructured the framework around a "threat-adaptive" model: requirements are periodically re-tuned against real-world attack data, and the assessment portfolio (e1, i1, r2) is built as nested layers of the same framework. HITRUST releases updates regularly, so always confirm the current minor version in MyCSF when you scope — organizations should always work with the current version.

Understanding the CSF's internal structure is not academic. It determines what you will actually be asked to prove, how it will be scored, and where you can legitimately reduce scope. This lesson walks the framework top to bottom.

Framework Structure: From Categories to Requirement Statements

The CSF has a layered hierarchy, and the vocabulary matters because MyCSF, assessors, and QA reviewers all use it precisely:

• Control categories — 14 broad areas (numbered 0 through 13), inherited from the framework's ISO 27001 ancestry: from the information security management program and access control through incident management, business continuity, and privacy practices. These are covered one by one in the control categories lesson.
• Control objectives — 49 statements of what each category must achieve.
• Control references (specifications) — 156 named controls beneath the objectives.
• Implementation levels — each control reference has up to three progressively stronger implementation levels; risk factors determine which level applies to you.
• Requirement statements — the atomic unit of assessment: specific, testable statements ("Passwords are required to have a minimum of N characters...", "Audit logs are reviewed at a defined frequency..."). Your assessment is, concretely, a scored list of requirement statements. An e1 contains 44 of them; an i1 roughly 180; an r2 anywhere from about 250 to 400 or more depending on your risk factors.

This is the key mental shift from HIPAA: where the Security Rule says "implement audit controls" and leaves reasonableness to you, the CSF tells you what good looks like at a testable level of detail. Prescriptiveness is the product.

The 19 Assessment Domains

While the framework is organized into 14 control categories, assessments are administered through 19 assessment domains — a practitioner-friendly regrouping of the same requirements that aligns to how security work is actually divided:

1. Information Protection Program
2. Endpoint Protection
3. Portable Media Security
4. Mobile Device Security
5. Wireless Security
6. Configuration Management
7. Vulnerability Management
8. Network Protection
9. Transmission Protection
10. Password Management
11. Access Control
12. Audit Logging and Monitoring
13. Education, Training and Awareness
14. Third-Party Assurance
15. Incident Management
16. Business Continuity and Disaster Recovery
17. Risk Management
18. Physical and Environmental Security
19. Data Protection and Privacy

Scores are calculated and pass/fail thresholds applied per domain, which has a planning consequence: you cannot let one weak area (say, portable media) slide on the theory that strong areas will average it out. Every domain must clear the bar independently.

Risk-Based Scoping and Tailoring

Not every organization implements every requirement. For r2 assessments, MyCSF generates your requirement set from risk factors you declare during scoping:

• Organizational factors — type of organization, number of records held, geographic footprint.
• System factors — internet accessibility, third-party access, mobile device use, public cloud use, and similar architecture questions.
• Regulatory factors — which authoritative sources you need included: HIPAA, PCI DSS, FedRAMP-aligned NIST controls, state privacy laws, GDPR, and so on. Selecting a regulatory factor pulls its mapped requirements into your assessment.

This tailoring is why one company's r2 has 280 requirement statements and another's has 400. It is also your most important cost lever: risk factors should be answered accurately — assessors and HITRUST QA check them — but scope (which systems and business units are in the assessment boundary) is a genuine design decision. A tightly defined platform boundary with clear segmentation is a dramatically smaller project than "the whole company." The e1 and i1, by contrast, are fixed-scope by design: everyone gets the same 44 or ~180 requirements, which is precisely what makes them faster and cheaper.

PRISMA Maturity Scoring

The CSF's scoring model derives from NIST's PRISMA (Program Review for Information Security Management Assistance) methodology. Each requirement statement is evaluated across up to five maturity levels:

At each applicable level, the assessor rates compliance on a five-point scale — non-compliant, somewhat compliant, partially compliant, mostly compliant, fully compliant — which converts to a numeric score. Level scores are weighted (implementation weighs most) and rolled up into requirement, domain, and overall scores.

How much of the ladder applies depends on assessment type: e1 and i1 evaluate only the implemented level — is the control actually operating — while the r2 scores policy, procedure, and implemented for every requirement, with measured and managed contributing extra credit where they exist. This is the real difference in difficulty: an r2 fails not only when a control is absent, but when a control operates perfectly yet no policy mandates it or no procedure documents it. Organizations coming from SOC 2, where a working control is a passing control, consistently underestimate the documentation burden. For certification, each of the 19 domains must reach the passing threshold — a maturity rating of 3 or better, roughly 62 on the 100-point scale — with corrective action plans required for lower-scoring requirements even in passing domains.

Cross-Framework Mapping

One of HITRUST's greatest values is its harmonization. Every requirement statement is mapped to the authoritative sources it satisfies, and MyCSF can report your posture against each mapped framework. Implement the CSF once and you generate defensible answers for:

• HIPAA — the mapping healthcare buyers care about most; see What Is HIPAA for the legal side.
• ISO 27001 and NIST CSF — structural ancestors of the framework, with dense mappings.
• NIST SP 800-53 and 800-171 — selectable as regulatory factors for organizations with federal exposure.
• PCI DSS, GDPR, and state privacy laws — pulled in where your risk factors say they apply.

Two practical notes. First, mapping is evidence, not certification — an r2 with the PCI factor does not make you PCI-validated; it demonstrates coverage. Second, the mappings work in reverse during implementation: if you already hold ISO 27001 or a mature SOC 2, a good assessor or compliance platform can pre-populate substantial portions of your CSF evidence, and HITRUST's inheritance program lets you import assessed scores directly from certified providers — most importantly AWS, Azure, and GCP — for requirements they fulfill on your behalf. Cloud-native companies routinely inherit a meaningful fraction of their physical, environmental, and infrastructure requirements.

Working With the CSF Day to Day

The CSF is licensed and consumed primarily through MyCSF, where you scope assessments, view your generated requirement statements, assign owners, attach evidence, and record scores. A workable operating rhythm:

1. Pull the requirement statements and group them by your 19 domain owners (in a small company, five people wearing nineteen hats).
2. For each requirement, identify the policy, the procedure, and the implementing system — the r2's three mandatory maturity levels — and log the evidence source.
3. Track gaps as a remediation backlog with owners and dates; this becomes your readiness roadmap for the certification process.
4. Watch version releases: when HITRUST ships a new CSF minor version, new assessments use it, and refreshed requirements (especially threat-adaptive i1 changes) may add work to your next cycle.

CSF Readiness Checklist

• Current CSF version confirmed and MyCSF access in place
• Assessment boundary defined: systems, facilities, business units, data flows
• Risk factors answered accurately (organizational, system, regulatory)
• Requirement statements generated and assigned to domain owners
• Policy inventory mapped to requirements — every statement traceable to an approved policy
• Procedures documented for each requirement, not just policies
• Implementation evidence identified per requirement (configs, samples, exports)
• Cloud provider inheritance opportunities registered (AWS/Azure/GCP)
• Existing certifications (SOC 2, ISO 27001) mapped to pre-fill evidence
• Per-domain gap scores estimated against the passing threshold
• Remediation backlog prioritized by domain risk of falling below threshold
• CSF version-update review added to the annual compliance calendar

Frequently Asked Questions

What is the difference between the 14 control categories and the 19 assessment domains?

Same requirements, two organizing schemes. The 14 categories (numbered 0–13) are the framework's reference structure, descending from ISO 27001. The 19 domains are how assessments group requirements for scoring and how practitioners divide the work. You will read the framework in categories and run your assessment in domains.

How many requirements will we actually be assessed on?

Fixed for the lighter assessments — 44 for e1, roughly 180 for i1 — and risk-factor-dependent for r2, commonly between about 250 and 400 or more requirement statements. Your MyCSF scoping answers generate the exact number before you commit, which is worth doing early for budgeting.

Do we need to hit all five maturity levels to certify?

No. e1 and i1 score only implementation. The r2 requires policy, procedure, and implemented for each requirement; measured and managed raise scores but are not prerequisites for certification. That said, the highest-scoring programs use measured/managed credit as buffer against imperfect implementation scores.

Is the CSF free?

Qualified organizations can obtain the framework for internal, non-commercial use at no charge, but running an actual assessment requires a paid MyCSF subscription, and validated assessments add assessor and HITRUST fees. Budget for the platform as a recurring cost.

How often does the CSF change, and does an update break our certification?

HITRUST issues updates on a roughly annual cadence within the v11 series, with i1 requirement selections refreshed against current threat data. Existing certifications remain valid for their term; the new version applies to your next assessment. The planning implication: review release notes when scheduling recertification so new requirements land in your backlog, not in your validation window.

Can we map our existing SOC 2 controls onto the CSF?

Substantially, yes — access control, change management, logging, and vendor management evidence usually transfers. The gaps are predictable: CSF requirements are more prescriptive (specific parameters rather than "commensurate with risk"), and the r2's policy/procedure scoring demands documentation depth SOC 2 never tested. Assume meaningful reuse, not a free pass.

In the next lesson, we will cover HITRUST assessment types.

Most teams manage CSF requirements, evidence, and mappings through a compliance automation platform alongside MyCSF. AuditXYZ helps you compare compliance automation platforms and auditors so you can pick tooling and an assessor with real HITRUST depth.