HITRUST Control Categories

HITRUST organizes the CSF into control categories that map to common security domains. Understanding these categories helps you plan implementation, assign ownership, and map your existing controls to HITRUST requirements before an assessor does it for you.

A quick structural reminder from the CSF lesson: the framework's reference structure is 14 control categories (numbered 0 through 13, a legacy of its ISO 27001 ancestry) containing 49 control objectives and 156 control references, which decompose into the requirement statements you are actually scored on. Assessments regroup those requirements into 19 assessment domains for scoring — but implementation planning is easiest category by category, because each category maps cleanly to an owner: your security lead, your IT admin, your HR manager, your legal counsel.

Here are the categories, what they require, and where teams struggle.

Category 0: Information Security Management Program

The umbrella category: a formally established, documented, approved, and maintained security program. In practice this means a charter or master security policy, defined roles and responsibilities, management sponsorship, and a review cycle. It is small in requirement count and enormous in consequence — for r2 assessments, every other category's policy scores hang off the program's documentation discipline established here.

Categories 4 and 5: Security Policy and Organization of Information Security

These govern the policy framework itself (approved, published, communicated, reviewed on schedule) and how security is organized: management commitment, assigned coordination, authorization processes for new systems, confidentiality agreements, contact with authorities and special-interest groups, independent review, and controls around external parties. For startups, the practical work is naming an accountable security officer, formalizing a policy library with version control and annual review, and resisting the temptation to download a policy pack nobody reads — assessors interview staff, and policies your team cannot describe score poorly at the procedure level.

Category 1: Access Control

Access control is typically the largest category and maps to the domain where the most requirement statements live. Requirements span user registration and deprovisioning, role-based access and least privilege, privileged access management, periodic access reviews, password and authentication parameters (prescriptive ones — length, history, lockout), multi-factor authentication, session management and timeouts, remote access controls, network access segregation, and mobile/teleworking rules. Most organizations have access controls in place but fail on formality: reviews that happen "when we think of it," admin accounts outside the PAM process, contractors missed at offboarding. HITRUST wants the process documented, executed on a calendar, and evidenced with artifacts — review sign-offs, deprovisioning tickets, MFA coverage reports.

Category 2: Human Resources Security

Controls addressing the workforce across the employment lifecycle: screening and background checks before hire, security terms in employment agreements, security awareness training with documented completion, acceptable use policies, a disciplinary (sanction) process, and termination procedures returning assets and revoking access. The evidence burden is administrative rather than technical — training completion records, signed acknowledgments, offboarding checklists — which makes this an easy early win with an HRIS and an LMS, and an embarrassing finding without them.

Category 3: Risk Management

HITRUST requires a formal risk management program: a documented methodology, periodic risk assessments identifying threats and vulnerabilities specific to your environment, a risk treatment plan with owners, and ongoing monitoring. This mirrors the HIPAA Security Rule's risk analysis requirement and can be satisfied by one well-run process feeding both. The common failure: a beautiful one-time risk assessment from a consultant, never updated, with no evidence that identified risks drove actual decisions.

Categories 6 and 13: Compliance and Privacy Practices

Category 6 covers identifying applicable legal and regulatory requirements, protecting records, technical compliance checking (vulnerability scanning and penetration testing live here), and audit considerations. Category 13 contains the privacy program requirements — notice, consent, minimal use, individual rights — drawn from HIPAA's Privacy Rule and other privacy authorities; how much of it applies depends on your regulatory risk factors. Teams with a pure security background consistently under-invest in 13: privacy requirements need a named owner, often legal or compliance rather than engineering.

Category 7: Asset Management

An inventory of information assets with assigned ownership, acceptable use rules, data classification, and handling procedures per classification. Modern reality: your inventory spans cloud resources, SaaS applications, endpoints, and data stores, and it must be current — a stale spreadsheet fails the implemented test. Asset inventory quality quietly determines several other categories, because scoping, patching, logging, and encryption coverage are all measured against it.

Category 8: Physical and Environmental Security

Secure areas, entry controls, protection against environmental threats, equipment siting, supporting utilities, cabling, secure disposal, and clear desk/clear screen policies. Cloud-native companies inherit the heavy requirements from their providers — this is a prime target for HITRUST's inheritance program, importing AWS/Azure/GCP assessed scores — leaving offices, endpoints, and disposal procedures as the residual work.

Category 9: Communications and Operations Management

The largest and most operationally diverse category: documented operating procedures, change management, segregation of duties, capacity management, malware protection, backups, network security controls, media handling, information exchange agreements, e-commerce security, and — critically — audit logging and monitoring: what is logged, how long it is retained, protection of logs, clock synchronization, and evidence that someone actually reviews them. Logging and monitoring is among the most-failed areas in assessments, for the same reason it is in HIPAA enforcement: collecting logs is easy, but demonstrating documented, periodic, acted-upon review is a process discipline. Encryption requirements for data at rest and in transit, and key management, also anchor here and in category 10 — HITRUST specifies standards, not vibes: algorithms, key handling, and coverage must be documentable.

Category 10: Information Systems Acquisition, Development and Maintenance

Security requirements analysis for new systems, correct processing in applications (input validation, output handling), cryptographic controls and key management, security of system files, secure development lifecycle, change control for development, and technical vulnerability management with defined remediation timeframes. For product companies this is the SDLC category: code review, dependency scanning, secrets management, environment separation, and a patching cadence you can evidence with tickets rather than assurances.

Category 11: Incident Management

Requirements cover incident response planning, detection and reporting channels, response procedures with defined roles, communication protocols, evidence collection, post-incident analysis, and learning loops. Your incident response plan must be documented, tested (tabletops count — keep the minutes), and updated based on lessons learned. For healthcare vendors, the plan must integrate breach-specific obligations: the HIPAA breach notification risk assessment and your BAA notification deadlines belong inside the runbook, not in a separate binder.

Category 12: Business Continuity Management

Business impact analysis, continuity strategy and plans, incorporation of information security into continuity planning, and — the part assessors press on — testing. Backups must exist, be protected, and be restorable on evidence; recovery time and recovery point objectives must be defined and exercised. HITRUST requires regular testing of continuity and disaster recovery plans; an untested plan scores as an unimplemented one.

Category Reference Table

Common Implementation Challenges

Across assessments, the same themes recur. Maturity depth for r2: controls must be not just implemented but backed by policy and procedure documentation for every requirement — the single biggest gap for SOC 2 graduates. Evidence of operation over time: access reviews, log reviews, and tests need a dated artifact trail, which argues for automating evidence collection from day one. Prescriptive parameters: where your current standard says "strong passwords" or "timely patching," HITRUST expects specific values you meet or formally exceed. Third-party assurance: vendors handling your sensitive data need documented risk assessment, contractual controls, and monitoring — connect this to your business associate program rather than building twice.

Implementation Prioritization Checklist

• Every category assigned a named owner (people can own several)
• Requirement statements grouped by category/domain with per-domain gap scores
• Policy and procedure inventory mapped requirement-by-requirement (r2 track)
• Access reviews, log reviews, and vulnerability remediation put on calendars with artifact capture
• Asset inventory automated across cloud, SaaS, and endpoints
• Encryption and key management documented against specified standards
• Training, screening, and offboarding evidence flowing from HR systems
• Incident response and DR plans tested within the last 12 months, minutes retained
• Cloud inheritance registered for physical/infrastructure requirements
• Third-party assurance integrated with vendor and BAA management
• Weakest domains prioritized first — certification thresholds apply per domain, so one weak domain blocks everything
• Privacy requirements assigned outside engineering if category 13 is in scope

Frequently Asked Questions

Which categories generate the most findings?

Consistently: access control (missed reviews, incomplete deprovisioning, MFA gaps), audit logging and monitoring (no evidence of review), configuration and vulnerability management (undocumented baselines, blown remediation timelines), and — on r2 specifically — policy/procedure documentation across every category. Plan your remediation budget accordingly.

Do all 14 categories apply to every assessment?

The categories all exist in the framework, but how many requirement statements you face from each depends on assessment type and, for r2, your risk factors. An e1's 44 requirements sample only the essentials across the map; an r2 with privacy and PCI regulatory factors activates far more of categories 6 and 13. MyCSF shows your exact distribution at scoping.

We're fully cloud-native — how much of the physical category can we inherit?

Typically most of it. AWS, Azure, and GCP participate in HITRUST's inheritance program, letting you import their assessed scores for data center physical and environmental requirements they operate. Your residual scope is offices (if any), endpoints, and media disposal. Register inheritance early — it also covers slices of operations and infrastructure categories.

How do these categories relate to the 19 assessment domains?

Same requirements, regrouped. For example, category 9's logging requirements surface in the "Audit Logging and Monitoring" domain, and category 1 spreads across the access control, password management, and wireless domains. Implement by category (ownership is cleaner), track scores by domain (thresholds are enforced there).

Can we reuse ISO 27001 or SOC 2 work?

Substantially. The category structure descends from ISO 27001, so an existing ISMS maps naturally; SOC 2 evidence covers much of access control, change management, and operations. The reliable deltas: HITRUST's prescriptive parameters, the r2 documentation depth, and healthcare-specific privacy requirements. Do a formal mapping before estimating remediation.

How long does remediation across categories take?

For a company with SOC 2-level maturity targeting i1: commonly 3 to 6 months of part-time effort concentrated in logging evidence, formal reviews, and parameter alignment. Targeting r2 from the same starting point: 6 to 12 months, dominated by policy/procedure documentation and letting controls accumulate operating history. Starting from minimal formality, double both.

In the next lesson, we will cover the HITRUST certification process.

Mapping 14 categories of requirements to your stack is exactly what compliance automation platforms are built for. AuditXYZ helps you compare compliance automation platforms and auditors so you can close category gaps with the right tooling and the right assessor.