HITRUST does not hand you one fixed list of policies. Which documents you need depends on the assessment you choose (e1, i1 or r2), the scope you define, and the requirement statements that apply to it in the MyCSF platform. Work the list out from those requirements, then organise policies, procedures and evidence by control area.
What HITRUST publishes about its assessments
HITRUST's own pages describe three core cybersecurity assessments built on the HITRUST CSF. The e1 offers foundational assurance with 43 core controls and is valid for one year. The i1 is threat-adaptive with 182 control requirements, valid for one year. The r2 is tailored, risk-based and the most comprehensive, valid for two years. Because all three share the HITRUST framework, work from one can be applied toward a more comprehensive one, and organisations can inherit controls from certified cloud service providers.
Certification involves a HITRUST Authorized External Assessor, so an outside party validates your work. HITRUST's pages do not publish a policy checklist, and we did not find one, so do not trust any list that claims to be the required set. Your assessor and MyCSF requirement statements are authoritative.
How to build your own list
- Choose the assessment type with your assessor based on customer demand and risk.
- Define the scope: systems, facilities, data types and business units.
- Pull the requirement statements that apply to that scope from MyCSF.
- For each requirement, decide what must be documented, implemented and evidenced.
- Group the results into documents.
This method gives you a list tailored to your assessment instead of a generic template.
A typical grouping, to adapt
Think of these as likely documents, not a mandated set. Confirm each against your requirement statements.
Governance. Information security policy and program charter, roles and responsibilities, risk management methodology and register, exceptions process, review calendar.
People. Onboarding and offboarding procedures, background screening where lawful, security awareness training, acceptable use, sanctions and confidentiality agreements.
Access and identity. Access control policy, privileged access procedure, password and authentication standard, remote access rules, periodic access review records.
Asset and data handling. Asset inventory procedure, data classification and handling, retention and disposal, media protection, encryption standard.
Operations. Configuration and hardening standards, change management, vulnerability and patch management, malware protection, logging and monitoring, backup and recovery.
Network and application security. Network security standard, secure development lifecycle, testing procedures.
Incident and continuity. Incident response plan with roles and notifications, business continuity and disaster recovery plans and test records.
Third parties. Vendor risk procedure, contract security terms, vendor inventory and assessment records. If you handle health data, add business associate agreements where HIPAA applies to you.
Physical. Facility access and visitor procedures, or documentation of how a cloud provider covers them.
Policy is not enough
HITRUST certification rests on validated evidence, so keep proof alongside each document: configuration exports, tickets, training rosters, review sign-offs, test reports. Write procedures that say who does what and how often, and make sure the practice matches. Inherited controls need evidence too: keep your provider's certification letters and a record of which requirements you inherit.
Common mistakes
Copying a template without editing it to match your tools. Writing one giant policy that mixes principles and procedures. Leaving owners and dates blank. Defining scope loosely and finding in assessment that systems outside your documents handle regulated data.
What to do
- Talk to your assessor early to confirm assessment type and scope.
- Extract requirement statements and map them to documents.
- Build a document register with owner, version, approval date and next review.
- Draft procedures from real practice.
- Create an evidence folder per control area.
- Gather inheritance records from cloud providers.
- Review the set for gaps before you submit.
Quick check
Is there an official HITRUST policy template?
We did not find one on HITRUST's assessment pages. Ask your assessor and check the MyCSF resources available to your account.
Do e1 and r2 need the same documents?
No. The number and rigour of requirements differ, so the documentation scope differs too.
How Safeguard helps automate this
Once documents exist, the work is keeping proof fresh. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between assessments, saving your team time for other work. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies and other findings; it is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Certification is decided by HITRUST and its assessors; Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo or book a call.
Sources
Last reviewed: 18 October 2026.
