Introduction: The HITRUST CSF as an Auditor's Framework
The HITRUST CSF (Common Security Framework) is a certifiable, prescriptive information security and privacy framework maintained by the HITRUST Alliance. Originally conceived to address the fragmented and often conflicting security requirements imposed on the United States healthcare ecosystem, the CSF has evolved into a globally recognised, risk-based framework applicable to any organisation that stores, processes or transmits sensitive information. Its defining characteristic is that it harmonises dozens of authoritative sources - such as HIPAA, ISO/IEC 27001, NIST SP 800-53, PCI DSS, GDPR, the NIST Cybersecurity Framework and many others - into a single, overlapping set of prescriptive controls. For an auditor, HITRUST is unusual because it does not merely ask 'do you have a control?' but instead measures the maturity of that control across multiple dimensions and produces a numeric score that must clear a defined threshold for certification.
This guide is written for compliance leaders, security architects, internal audit teams and CyberSigma consultants preparing an organisation for a HITRUST assessment. It walks through what HITRUST is, who needs it, how the framework is structured, and provides a master, auditor-grade checklist covering every control category. It then addresses scoping, phased implementation, the maturity scoring model, the validated assessment lifecycle, evidence expectations, roles, KPIs and cross-framework mapping. Throughout, the emphasis is practical: what an assessor will actually look for, and the typical evidence that satisfies a requirement statement.
Copyright and licensing note
HITRUST CSF, the HITRUST Approach and MyCSF are the intellectual property of the HITRUST Alliance and are protected by copyright and trademark. The framework text, control requirement statements and scoring rubric are licensed material. This guide is an original, independent summary written for educational purposes and deliberately paraphrases all concepts. It does not reproduce HITRUST copyrighted requirement text. Organisations pursuing certification must obtain a legitimate MyCSF subscription and engage a HITRUST Authorised External Assessor. Always refer to the official HITRUST CSF for the authoritative, current control language.
What is the HITRUST CSF?
The HITRUST CSF is a comprehensive, scalable and prescriptive controls framework that provides organisations with a single lens through which to manage information risk and demonstrate compliance against many underlying regulations and standards simultaneously. Rather than treating security as a binary pass/fail against each individual regulation, HITRUST assigns each organisation a set of control requirements tailored to its risk profile and then evaluates the maturity of how those controls are implemented.
Several attributes distinguish HITRUST from other frameworks:
- Harmonisation and mapping: A single HITRUST control requirement typically maps to numerous authoritative sources, so satisfying it can simultaneously evidence compliance with HIPAA, ISO 27001, NIST, PCI DSS and others.
- Risk-based tailoring: The framework uses organisational, system, regulatory and geographic risk factors to add or remove specific requirements, so no two assessment scopes are identical.
- Maturity model scoring: Controls are scored across multiple maturity levels (Policy, Process/Procedure, Implemented, and for higher assurances Measured and Managed), producing a numeric score rather than a simple yes/no.
- Multiple assessment types: HITRUST offers a tiered portfolio - the Essentials (e1) 1-year assessment, the Implemented (i1) 1-year assessment, and the Risk-based (r2) 2-year assessment - allowing organisations to choose an assurance level proportionate to their risk.
- Certification and inheritance: A successful validated assessment results in a HITRUST certification letter and report; certified service providers can allow customers to 'inherit' scored controls, reducing duplicate effort.
- Threat-adaptive: HITRUST regularly updates the CSF and its e1/i1 control selections to reflect current, prevalent cyber threats derived from breach and MITRE ATT&CK analysis.
The current framework generation (CSF v11 and its successors) reorganised controls to support the tiered e1/i1/r2 model, with the e1 and i1 assessments drawing a curated subset of the full r2 control catalogue. The full CSF is organised into 14 control categories, further divided into control objectives and individual control references, each expressed through requirement statements at defined implementation levels.
Who Must Comply With HITRUST?
HITRUST certification is not mandated by any single law. Instead, it is driven by contractual, market and risk pressures - most powerfully within the healthcare supply chain, where large health plans and providers frequently require their vendors to hold HITRUST certification as a condition of doing business. The following table summarises who typically pursues HITRUST and why.
| Organisation type | Why HITRUST applies |
|---|---|
| Healthcare providers (hospitals, clinics, physician groups) | Protect electronic protected health information (ePHI) and demonstrate HIPAA/HITECH due diligence to regulators and partners |
| Health plans and payers | Manage member data risk and impose HITRUST on their downstream business associates |
| Business associates and healthcare vendors | Contractually required by covered entities to hold HITRUST certification to handle ePHI |
| SaaS and cloud service providers | Provide customers with a recognised, inheritable assurance report covering security and privacy |
| Health information exchanges and clearinghouses | Aggregate large volumes of sensitive health data requiring demonstrable controls |
| Medical device and health-tech manufacturers | Address connected-device and platform security expectations from healthcare buyers |
| Pharmaceutical and life-sciences firms | Protect research, patient and trial data against regulatory and IP risk |
| Financial services and other regulated sectors | Increasingly adopt HITRUST as a broad, harmonised control framework beyond healthcare |
| Any organisation seeking multi-framework assurance | Use a single assessment to evidence HIPAA, ISO 27001, NIST, PCI DSS and GDPR alignment |
Regulatory drivers behind adoption
Even though no statute names HITRUST directly, adopting it materially strengthens an organisation's defensibility under HIPAA/HITECH, GDPR, US state privacy laws and sector regulations. Because the CSF maps its requirements to these authorities, a certification provides tangible evidence of a reasonable and appropriate security programme should a breach investigation or enforcement action occur.
Structure of the HITRUST CSF
The HITRUST CSF is hierarchical. At the top sit 14 control categories (also called domains or control families in common usage). Each category contains one or more control objectives, and each objective is delivered through control references. Every control reference carries requirement statements that are assessed at implementation levels, with a set of risk factors determining exactly which statements apply to a given organisation. The 19 assessment domains used in MyCSF reporting are a reporting-layer grouping of these categories. The table below lists the 14 CSF control categories with an indicative numbering and description.
| Ref | Control category | Focus area |
|---|---|---|
| 00 | Information Security Management Programme | Governance, the overarching security programme and management commitment |
| 01 | Access Control | Identity, authentication, authorisation, privilege and remote access management |
| 02 | Human Resources Security | Personnel screening, terms of employment, awareness and termination |
| 03 | Risk Management | Risk assessment, treatment and ongoing risk programme |
| 04 | Security Policy | Documented information security policy set and review |
| 05 | Organisation of Information Security | Internal governance structure and external party security |
| 06 | Compliance | Legal, regulatory, contractual and audit compliance obligations |
| 07 | Asset Management | Inventory, ownership, acceptable use and information classification |
| 08 | Physical and Environmental Security | Secure areas, equipment protection and environmental controls |
| 09 | Communications and Operations Management | Operational procedures, malware, backup, network, media and monitoring |
| 10 | Information Systems Acquisition, Development and Maintenance | Secure SDLC, cryptography, correct processing and vulnerability management |
| 11 | Information Security Incident Management | Detection, reporting, response and lessons learned |
| 12 | Business Continuity Management | Continuity planning, testing and disaster recovery |
| 13 | Privacy Practices | Notice, choice, collection, use, disclosure and data-subject rights |
For MyCSF reporting, these categories are presented as 19 assessment domains, which regroup the control references into operationally coherent buckets. The 19 domains are the units against which domain-level scores are reported and are listed here.
| # | Assessment domain | Representative scope |
|---|---|---|
| 1 | Information Protection Programme | Governance, policy framework, risk and compliance oversight |
| 2 | Endpoint Protection | Workstation, laptop and endpoint hardening and malware defence |
| 3 | Portable Media Security | Removable media handling, encryption and disposal |
| 4 | Mobile Device Security | Mobile device management, BYOD and mobile access controls |
| 5 | Wireless Security | Wireless network configuration, segregation and monitoring |
| 6 | Configuration Management | Baseline configuration, hardening and change control |
| 7 | Vulnerability Management | Scanning, remediation and technical vulnerability handling |
| 8 | Network Protection | Segmentation, firewalls, boundary defence and network monitoring |
| 9 | Transmission Protection | Encryption in transit and secure communications |
| 10 | Password Management | Authenticator policy, rotation and secure storage |
| 11 | Access Control | Authorisation, least privilege and account provisioning |
| 12 | Audit Logging and Monitoring | Log generation, protection, review and correlation |
| 13 | Education, Training and Awareness | Security awareness programme and role-based training |
| 14 | Third-Party Assurance | Vendor risk management and supplier security |
| 15 | Incident Management | Incident response lifecycle and breach notification |
| 16 | Business Continuity and Disaster Recovery | BCP, DR and resilience testing |
| 17 | Risk Management | Enterprise and system-level risk assessment and treatment |
| 18 | Physical and Environmental Security | Facility, secure area and equipment protection |
| 19 | Data Protection and Privacy | Privacy notice, data-subject rights, collection and retention |
Master Assessment Checklist: Every Control Area
This is the core of the guide. Below, each of the 14 CSF control categories is broken out with the key control objectives and the specific verification points an assessor examines, alongside the typical evidence that satisfies them. Use these tables as a pre-assessment self-audit. Every control area is covered; do not skip any group, because HITRUST scoring aggregates across all applicable requirement statements and a weak category will drag domain and overall scores below the certification threshold.
00 - Information Security Management Programme
| What to verify | Typical evidence |
|---|---|
| A formal, documented information security management programme exists and is endorsed by senior management | Signed ISMP charter, management approval records, programme scope statement |
| Roles, responsibilities and authority for security are defined and assigned | Organisation chart, RACI matrix, CISO/security officer appointment letter |
| The programme is reviewed at planned intervals and after significant change | Management review minutes, review cadence policy, revision history |
| Security objectives are measurable and aligned to business risk | Security objectives register, KPI dashboard, board reporting pack |
01 - Access Control
| What to verify | Typical evidence |
|---|---|
| A documented access control policy governs provisioning, review and revocation | Access control policy, approval workflow, joiner-mover-leaver procedure |
| User registration and de-registration follow an authorised, auditable process | Access request tickets, approval records, termination checklists |
| Least privilege and need-to-know are enforced across systems | Role definitions, entitlement matrix, privileged account inventory |
| Privileged access is restricted, logged and periodically reviewed | PAM tool records, privileged session logs, quarterly access certification |
| Unique user identification and strong authentication are enforced | IAM configuration, MFA enrolment reports, SSO policy |
| User access rights are reviewed at defined intervals | Access recertification reports, sign-off evidence |
| Remote access is secured, restricted and monitored | VPN configuration, remote access policy, session logs |
| Segregation of duties is designed to prevent conflicts | SoD matrix, conflict analysis, compensating control records |
| Inactive sessions time out and unattended equipment is protected | Session-timeout GPO/config, screen-lock policy |
| Application and information access is restricted per classification | Application authorisation config, data access control lists |
02 - Human Resources Security
| What to verify | Typical evidence |
|---|---|
| Background verification is performed for personnel proportionate to role risk | Screening policy, completed background-check records |
| Terms of employment include security and confidentiality obligations | Employment contracts, NDAs, acceptable-use acknowledgements |
| Security responsibilities are defined for all roles | Job descriptions with security duties, role charters |
| Ongoing security awareness and role-based training is delivered | Training records, completion rates, course content |
| A disciplinary process exists for security violations | Disciplinary policy, sanction records |
| Termination and role-change procedures revoke access and recover assets | Exit checklists, asset-return records, access-revocation logs |
03 - Risk Management
| What to verify | Typical evidence |
|---|---|
| A documented risk management methodology is defined and applied | Risk management framework, risk assessment procedure |
| Risk assessments are conducted at planned intervals and on change | Risk assessment reports, assessment schedule |
| Risks are recorded, owned, rated and tracked to treatment | Risk register with owners, likelihood/impact ratings, treatment status |
| Risk treatment plans and residual-risk acceptance are approved | Treatment plans, risk acceptance sign-offs, POA&M |
| Risk results feed into the security programme and control selection | Traceability from risk to controls, management review minutes |
04 - Security Policy
| What to verify | Typical evidence |
|---|---|
| A comprehensive set of information security policies is documented and approved | Policy library, approval records, version control |
| Policies are communicated to and acknowledged by relevant personnel | Distribution records, acknowledgement logs, intranet posting |
| Policies are reviewed at defined intervals and after significant change | Review schedule, revision history, change log |
| Supporting standards and procedures operationalise each policy | Standards documents, procedure library, mapping to policies |
05 - Organisation of Information Security
| What to verify | Typical evidence |
|---|---|
| Internal security governance and coordination structures are defined | Security committee terms of reference, meeting minutes |
| Security responsibilities and contacts with authorities are maintained | Contact register, authority/special-interest-group liaison records |
| Security is addressed in project management | Project security checklists, gate approvals |
| Risks from external parties are identified and addressed before access | Third-party risk assessments, access agreements |
| Confidentiality and security requirements are in agreements with third parties | Signed agreements with security clauses, DPAs, BAAs |
| Teleworking and mobile-working risks are governed | Mobile/teleworking policy, device configuration standards |
06 - Compliance
| What to verify | Typical evidence |
|---|---|
| Applicable legal, regulatory and contractual requirements are identified | Compliance obligations register, regulatory mapping |
| Intellectual property and licensing obligations are met | Software asset register, licence records |
| Records are protected against loss, destruction and falsification | Records retention schedule, records protection controls |
| Privacy and protection of PII/PHI meet legal requirements | Privacy compliance evidence, DPIAs, consent records |
| Cryptographic controls comply with relevant regulations | Encryption standards, key-management records, export-control review |
| Independent reviews and technical compliance checks are performed | Internal audit reports, penetration test reports, vulnerability scans |
| Audit activities are planned to minimise operational disruption | Audit plans, scoping agreements, evidence protection controls |
07 - Asset Management
| What to verify | Typical evidence |
|---|---|
| An accurate inventory of information assets is maintained with ownership | Asset register, CMDB, owner assignments |
| Acceptable-use rules for assets are defined and communicated | Acceptable-use policy, acknowledgement records |
| Information is classified according to sensitivity and criticality | Classification policy, labelled data samples, classification matrix |
| Handling procedures match each classification level | Handling standards, labelling and marking guidance |
| Assets are returned upon termination or contract end | Asset-return records, exit checklists |
08 - Physical and Environmental Security
| What to verify | Typical evidence |
|---|---|
| Secure areas are protected by physical entry controls | Access logs, badge system config, visitor registers |
| Physical security perimeters protect facilities and sensitive areas | Perimeter design, CCTV coverage maps, guard procedures |
| Equipment is sited and protected against environmental threats | Data centre environmental controls, UPS/generator records |
| Supporting utilities (power, cooling) are protected and monitored | UPS test logs, HVAC monitoring, environmental alarms |
| Cabling security protects power and telecommunications lines | Cabling diagrams, protected conduit records |
| Equipment maintenance is controlled and documented | Maintenance logs, service contracts |
| Secure disposal or reuse of equipment sanitises data | Media sanitisation records, certificates of destruction |
| Off-site and removal of assets is authorised and tracked | Asset removal authorisations, transit tracking |
09 - Communications and Operations Management
| What to verify | Typical evidence |
|---|---|
| Operating procedures are documented and available to operators | Runbooks, standard operating procedures |
| Change management controls changes to systems and infrastructure | Change tickets, CAB minutes, change calendar |
| Capacity is planned and monitored to meet demand | Capacity reports, monitoring dashboards |
| Separation of development, test and production environments | Environment architecture, access segregation evidence |
| Malware protection is deployed, updated and monitored | AV/EDR console, definition update logs, alert records |
| Backups are performed, protected and periodically restored/tested | Backup schedules, restore test records, backup encryption |
| Network security controls protect and monitor connectivity | Firewall rulesets, IDS/IPS config, network diagrams |
| Media handling, transport and disposal are controlled | Media handling procedure, secure transport records |
| Information exchange with external parties is protected | Data-exchange agreements, secure transfer configuration |
| Electronic commerce and online transactions are secured | Transaction security controls, TLS configuration |
| Audit logs record user, exception and security events | Logging configuration, log samples, retention settings |
| Logs are protected and reviewed; clocks are synchronised | Log integrity controls, review records, NTP configuration |
| Monitoring detects unauthorised information processing | SIEM alerts, monitoring use cases, review evidence |
10 - Information Systems Acquisition, Development and Maintenance
| What to verify | Typical evidence |
|---|---|
| Security requirements are specified for new and changed systems | Security requirements documents, RFP/RFI security criteria |
| Input, processing and output validation prevent data errors | Application validation design, test cases, error-handling logic |
| Cryptographic controls protect confidentiality and integrity | Encryption standards, algorithm inventory, key-management policy |
| Key management covers generation, storage, rotation and destruction | Key-management procedures, HSM/KMS records |
| System files and source code are protected against unauthorised change | Access controls on source, code-repository permissions |
| A secure development lifecycle governs coding and testing | SDLC policy, secure-coding standards, code-review records |
| Change control in development and outsourced development is managed | Change records, supplier development agreements |
| Technical vulnerabilities are identified and remediated promptly | Vulnerability scan reports, patch records, remediation SLAs |
11 - Information Security Incident Management
| What to verify | Typical evidence |
|---|---|
| A documented incident response plan defines roles and workflow | Incident response plan, playbooks, contact tree |
| Events and weaknesses are reported through defined channels | Reporting procedure, ticketing records, staff guidance |
| Incidents are triaged, classified and prioritised consistently | Severity matrix, triage records, incident log |
| Response, containment, eradication and recovery are executed and recorded | Incident tickets, timeline records, remediation evidence |
| Evidence is collected and preserved for potential legal action | Forensic procedures, chain-of-custody records |
| Breach notification obligations are met within required timelines | Breach notification records, regulator/customer letters |
| Lessons learned feed back into controls and the response process | Post-incident reviews, corrective-action records |
12 - Business Continuity Management
| What to verify | Typical evidence |
|---|---|
| Business continuity is integrated into the management framework | BCM policy, programme governance records |
| A business impact analysis identifies critical processes and RTO/RPO | BIA report, criticality ratings, recovery objectives |
| Continuity and disaster recovery plans are documented and current | BCP/DR plans, dependency mapping, recovery procedures |
| Continuity arrangements are tested and maintained | Test/exercise reports, tabletop records, remediation actions |
| Redundancy and resilience meet recovery objectives | Failover architecture, DR site records, replication config |
13 - Privacy Practices
| What to verify | Typical evidence |
|---|---|
| A privacy notice discloses collection, use and disclosure practices | Published privacy notice, notice review records |
| Choice and consent are obtained where required | Consent records, opt-in/opt-out mechanisms |
| Collection is limited to identified, lawful purposes | Data collection inventory, purpose specification |
| Use, retention and disposal align with stated purposes and law | Retention schedule, disposal records, use limitation controls |
| Disclosure to third parties is controlled and agreed | Data-sharing agreements, disclosure logs, BAAs |
| Data subjects can access, correct and request deletion of their data | Data-subject request procedure, request logs, fulfilment evidence |
| Data quality and integrity of personal information are maintained | Data validation controls, correction procedures |
| Privacy monitoring, complaints and enforcement are handled | Complaint register, privacy incident records, DPO oversight |
Scoping the HITRUST Assessment
Scope is the single most consequential decision in a HITRUST engagement. It determines which control requirements apply, how much evidence is required, and ultimately the cost and defensibility of the certification. HITRUST scoping works differently from most frameworks because the platform (MyCSF) generates the applicable requirement set from a set of factors you declare.
- Assessment type: Choose e1 (essentials, foundational cyber hygiene), i1 (implemented, a moderate threat-adaptive baseline) or r2 (risk-based, the comprehensive, tailored assessment). The type sets the base number of requirement statements.
- Organisational factors: Size, complexity, number of records and geographic footprint influence which requirements are added.
- System/platform factors: Whether the in-scope system uses cloud, mobile, wireless, third-party hosting or transmits over public networks triggers additional requirement statements.
- Regulatory factors: Selecting authoritative sources (for example HIPAA, PCI DSS, GDPR, state privacy laws, NIST) causes the CSF to include mapped requirements so a single assessment evidences multiple regulations.
- Boundary definition: Precisely document the in-scope systems, facilities, data flows, business processes and supporting infrastructure, including which controls are inherited from certified service providers.
Scoping discipline saves certifications
Under-scoping (excluding systems that touch in-scope data) undermines the certification's credibility and can be challenged by HITRUST quality assurance. Over-scoping inflates evidence effort and cost. Define the assessment boundary around the data-holding systems and their direct dependencies, document inherited controls explicitly, and confirm the boundary with your Authorised External Assessor before evidence collection begins.
Implementation Approach: A Phased Programme
A HITRUST programme is best delivered in structured phases. Each phase below lists the key activities and the deliverables that should exist at its close. This staged approach lets an organisation build maturity deliberately and avoids the common failure of collecting evidence before controls are actually operating.
Phase 1 - Readiness and Scoping
- Activities: Identify business drivers and target assessment type; define the assessment boundary and data flows; select authoritative sources and risk factors in MyCSF; establish programme governance and sponsorship.
- Deliverables: Scope statement, data-flow diagrams, factor selections, project charter, RACI and programme plan.
Phase 2 - Gap Assessment
- Activities: Map current controls to the generated requirement set; score each requirement against the maturity model as-is; identify gaps and rank by risk and score impact.
- Deliverables: Gap analysis report, current-state maturity scores, prioritised remediation backlog.
Phase 3 - Remediation and Control Uplift
- Activities: Author or update policies and procedures; implement technical controls; close SoD, logging, encryption and access gaps; establish measurement for higher assurance levels.
- Deliverables: Updated policy library, implemented controls, corrective action plans (CAPs/POA&M), evidence artefacts accumulating in a repository.
Phase 4 - Operating and Evidence Maturity
- Activities: Operate controls for a sufficient period; collect operating evidence over time; run internal control testing; for r2, evidence Measured and Managed maturity through metrics and corrective action.
- Deliverables: Operating evidence set, internal test results, metrics dashboards, self-assessment scores approaching the threshold.
Phase 5 - Validated Assessment
- Activities: Engage a HITRUST Authorised External Assessor; complete the validated assessment in MyCSF; support assessor testing, sampling and interviews; respond to findings.
- Deliverables: Completed validated assessment, assessor testing results, submitted assessment package.
Phase 6 - HITRUST QA, Certification and Sustainment
- Activities: Support HITRUST quality assurance review; remediate any QA-raised issues; obtain certification; establish interim assessment and continuous monitoring for the validity period.
- Deliverables: HITRUST report and certification letter, interim assessment plan, continuous compliance calendar.
Maturity and Scoring Model
HITRUST does not score a control as simply present or absent. For validated r2 assessments, each requirement statement is evaluated across up to five maturity levels, each weighted and combined into a numeric score from 0 to 100 for the requirement. Domain scores and an overall score are then derived. Scores are expressed on the HITRUST 1 to 5 rating scale that corresponds to defined percentage bands. To achieve certification, scores must generally reach the level equating to a satisfactory rating across the applicable domains. The e1 and i1 assessments use a simpler Implemented-focused evaluation, whereas r2 uses the full model.
| Maturity level | What it measures | How it is evidenced |
|---|---|---|
| Policy | Whether an approved policy mandates the control | Approved, current policy documents referencing the requirement |
| Process / Procedure | Whether documented procedures operationalise the policy | Standard operating procedures, runbooks, work instructions |
| Implemented | Whether the control is actually operating in the environment | Configurations, tickets, logs, screenshots, sampled records |
| Measured | Whether the control's effectiveness is measured | Metrics, KPIs, internal testing and audit results |
| Managed | Whether measurement drives corrective action and improvement | Corrective action records, management review, trend analysis |
The rating scale below maps compliance percentages to the HITRUST maturity rating used in reporting. The specific certification threshold is set by HITRUST and applied at the domain and overall level.
| Rating | Compliance band | Interpretation |
|---|---|---|
| 5 - Fully Compliant | Approximately 91-100% | Control fully and consistently in place with evidence |
| 4 - Mostly Compliant | Approximately 76-90% | Control largely in place with minor gaps |
| 3 - Partially Compliant | Approximately 33-75% | Control partially implemented; notable gaps remain |
| 2 - Somewhat Compliant | Approximately 11-32% | Control minimally in place; significant gaps |
| 1 - Non-Compliant | Approximately 0-10% | Control effectively absent |
Assessment and Audit Approach
The validated assessment follows a defined lifecycle governed by HITRUST and executed with an Authorised External Assessor. The ordered steps below describe the end-to-end journey to certification.
- Provision a MyCSF subscription and create the object/assessment, declaring scope and risk factors to generate the tailored requirement set.
- Perform a self (readiness) assessment, scoring each requirement statement against the maturity model to identify gaps.
- Remediate gaps, author corrective action plans for residual weaknesses, and accumulate policy, procedure and operating evidence.
- Engage a HITRUST Authorised External Assessor and agree scope, timeline and sampling approach.
- The assessor performs validation testing: reviewing documentation, inspecting configurations, sampling records and interviewing control owners.
- The assessor scores each requirement, documents findings and any gaps requiring corrective action plans within HITRUST tolerances.
- Submit the completed validated assessment package through MyCSF to HITRUST.
- HITRUST performs an independent quality assurance review of the assessment and evidence, raising checkpoints where clarification is needed.
- Address QA checkpoints; upon successful review HITRUST issues the certification and report (e1/i1 valid one year, r2 valid two years).
- Maintain certification through required interim assessments, continuous monitoring and rapid recertification before expiry.
Evidence Request List
Assessors expect evidence at each maturity level and categorised by control area. Prepare the following, organised so each artefact clearly maps to the requirement it supports.
- Governance and policy: information security policy suite, privacy policy, approval and review records, security programme charter, organisation chart and RACI.
- Risk management: risk methodology, risk assessment reports, risk register, treatment plans, risk acceptance sign-offs and POA&M.
- Access control: access control policy, JML procedures, access request/approval tickets, access recertification reports, PAM records, MFA configuration.
- Human resources: screening records, employment and confidentiality agreements, awareness training completion, disciplinary and termination records.
- Asset and configuration: asset inventory/CMDB, classification matrix, hardening baselines, configuration standards and change records.
- Operations: malware protection console output, backup schedules and restore tests, capacity reports, media handling procedures.
- Network and transmission: network diagrams, firewall rulesets, IDS/IPS and segmentation evidence, TLS/encryption-in-transit configuration.
- Logging and monitoring: logging configuration, SIEM alerts and use cases, log review records, NTP/time synchronisation settings.
- Vulnerability and development: scan reports, patch records, penetration test results, secure SDLC artefacts and code-review evidence.
- Incident and continuity: incident response plan, incident tickets, breach notifications, BIA, BCP/DR plans and test reports.
- Physical and environmental: badge access logs, CCTV/perimeter records, data-centre environmental monitoring, disposal certificates.
- Third-party assurance: vendor risk assessments, signed agreements, BAAs/DPAs, inherited-control (customer responsibility) documentation.
- Privacy: privacy notice, consent records, data-subject request logs, retention schedule and disposal records.
Roles and Responsibilities
| Role | HITRUST responsibilities |
|---|---|
| Executive sponsor / senior management | Approve scope and budget, provide governance and accept residual risk |
| CISO / Information Security Officer | Own the security programme, control implementation and assessment readiness |
| HITRUST programme manager | Coordinate the assessment, manage MyCSF, timeline and evidence collection |
| Control owners / process owners | Operate controls, provide evidence and respond to assessor questions |
| Privacy officer / DPO | Own privacy practices, data-subject rights and privacy evidence |
| IT and security operations | Implement and maintain technical controls, logging and monitoring |
| Internal audit / compliance | Perform internal testing, track corrective actions and validate readiness |
| HITRUST Authorised External Assessor | Perform validated testing, scoring and submission to HITRUST |
| HITRUST Alliance | Maintain the CSF, perform quality assurance and issue certification |
KPIs to Track
- Overall self-assessment maturity score and per-domain scores against the certification threshold
- Number and severity of open gaps and corrective action plans (POA&M items)
- Percentage of requirement statements at each maturity level (Policy, Process, Implemented, Measured, Managed)
- Mean time to remediate identified gaps and vulnerabilities
- Access recertification completion rate and orphaned/privileged account counts
- Security awareness training completion rate and phishing-simulation failure rate
- Backup restore test success rate and DR exercise pass rate
- Vulnerability scan coverage and percentage of critical vulnerabilities remediated within SLA
- Incident detection and response times and number of breaches requiring notification
- Third-party assessment coverage and percentage of vendors with current risk reviews
- Evidence readiness index: percentage of requirements with complete, current evidence
- Days remaining to interim assessment and recertification deadlines
Readiness Checklist
- Assessment type (e1, i1 or r2) selected and MyCSF subscription provisioned
- Scope boundary, data flows and inherited controls documented and validated
- Risk factors and authoritative sources declared to generate the requirement set
- Complete information security and privacy policy suite approved and current
- Risk assessment conducted with a maintained risk register and treatment plans
- Access control, MFA, least privilege and privileged access management operating
- Security awareness and role-based training delivered and recorded
- Asset inventory, classification and configuration baselines in place
- Malware protection, backups with tested restores, and logging/monitoring operating
- Vulnerability management and secure SDLC controls evidenced
- Incident response and business continuity/DR plans documented and tested
- Physical and environmental controls implemented and monitored
- Third-party risk management and agreements (BAAs/DPAs) in place
- Privacy notice, consent and data-subject request processes operating
- Gap remediation complete with corrective action plans for residual items
- Evidence repository assembled and mapped to each requirement statement
- Authorised External Assessor engaged and validation timeline agreed
Common Gaps
- Evidence collected before controls have actually been operating, so operating maturity cannot be demonstrated
- Policies exist but corresponding documented procedures (Process level) are missing, capping scores
- No measurement or corrective-action evidence, blocking the Measured and Managed levels required for higher r2 scores
- Scope drawn too narrowly, excluding systems that touch in-scope data and inviting QA challenge
- Access recertification and privileged-access reviews performed inconsistently or without sign-off
- Logging enabled but logs neither protected nor regularly reviewed, and clocks not synchronised
- Backups taken but restore testing not performed or documented
- Third-party inventory incomplete and inherited-control responsibilities undocumented
- Vulnerability scans run but remediation not tracked to SLA closure
- Privacy requirements treated as an afterthought, with weak consent and data-subject request handling
- Underestimating the effort and duration to reach Measured/Managed maturity for r2 certification
HITRUST Mapped to Other Frameworks
A central value of HITRUST is that its control requirements map to numerous authoritative sources, so a single assessment can evidence alignment with many regulations and standards. The table below shows indicative relationships between HITRUST control areas and other frameworks.
| Framework / standard | Relationship to HITRUST CSF |
|---|---|
| HIPAA / HITECH Security & Privacy Rules | Directly mapped; HITRUST is widely used to demonstrate HIPAA due diligence for ePHI |
| ISO/IEC 27001 / 27002 | Structural and control alignment across access, operations, cryptography and continuity |
| NIST SP 800-53 | Mapped control families feed HITRUST requirements for federal-aligned controls |
| NIST Cybersecurity Framework (CSF) | HITRUST provides a NIST CSF report and maps functions to CSF controls |
| PCI DSS | Payment-card requirements map into HITRUST where cardholder data is in scope |
| GDPR / privacy regulations | Privacy Practices category maps to consent, data-subject rights and lawful processing |
| SOC 2 (Trust Services Criteria) | Overlapping security, availability and confidentiality controls; often pursued together |
| FedRAMP | Cloud-focused control overlap for organisations serving US government |
| COBIT | Governance and management practices align with HITRUST programme controls |
| CIS Critical Security Controls | Technical hardening and hygiene controls map to endpoint, network and configuration domains |
How CyberSigma Helps
Partner with CyberSigma for HITRUST readiness and certification
CyberSigma guides healthcare, SaaS and regulated organisations through the entire HITRUST journey - from selecting the right assessment type (e1, i1 or r2) and defining a defensible scope, to running a rigorous gap assessment against the generated requirement set, remediating policy, process and technical gaps, and building an evidence repository mapped to every requirement statement. Our CERT-In empanelled and QSA-credentialed specialists implement the access, logging, encryption, vulnerability and privacy controls that drive maturity scores upward, prepare your teams for validated testing, and coordinate with your Authorised External Assessor through HITRUST quality assurance to certification. Beyond certification, CyberSigma establishes continuous monitoring, interim assessment readiness and multi-framework harmonisation so a single programme sustains HIPAA, ISO 27001, NIST, PCI DSS and GDPR alignment. Engage CyberSigma to make HITRUST certification faster, defensible and durable.
Free 1-minute check
Try it free →Free Security Assessment
Get a complimentary, no-obligation assessment from CERT-In empanelled senior auditors.
Frequently asked questions
Is HITRUST the same as HIPAA?
No. HIPAA is US law with no certification; HITRUST CSF is a certifiable framework that incorporates HIPAA requirements, so a HITRUST certification is often used to demonstrate HIPAA-aligned security.
Which HITRUST assessment should I choose?
e1 for foundational hygiene, i1 for a strong threat-adaptive baseline, and r2 for comprehensive, risk-based assurance over sensitive/regulated data.
Official documents
CyberSigma resources
Need help with HITRUST?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.