HITRUST CSF v11.9 Wants to See Your Risk Reasoning

Key Takeaways:

• HITRUST CSF® v11.9.0, released September 24, 2026, ties more security decisions to a documented risk assessment and expects evidence that controls detect and respond to exploitation attempts. 
• New e1 and i1 assessments can’t be created on v11.8.0 after December 31, 2026, and e1 and i1 v11.8.0 assessments can’t be submitted starting March 31, 2027. 
• Policies now need to spell out risk tiers, remediation and patch timeframes, change classifications and log review ownership. Fieldwork will look for that reasoning in change records, logs and incident response tests. 
• Cryptographic asset inventories, TLS 1.3 (or restricted TLS 1.2), passkey enforcement and post-quantum planning move cryptography from a configuration setting to a documented program.  

---

HITRUST released CSF v11.9.0 on September 24, 2026. The headline items, including agentic AI mappings, post-quantum cryptography considerations and refreshed TLS and passkey requirements, are easy to read as technical housekeeping. The larger shift actually sits underneath those headlines. Across vulnerability management, change management, logging, incident response and endpoint protection, v11.9 expects more of your security decisions to trace back to a documented risk assessment, and it expects evidence that your controls detect and respond to attempts to exploit technical vulnerabilities. For teams planning a 2027 HITRUST assessment, that changes what fieldwork will ask to see. 

THE VERSION DECISION COMES BY DECEMBER 31 

HITRUST advisory HAA 2026-006 gives organizations a short window to choose which version to assess against. Through December 31, 2026, new e1 and i1 assessments can be created on either v11.8.0 or v11.9.0. After that date, new e1, i1 and rapid assessments can no longer be created on v11.8.0, and starting March 31, 2027, e1 and i1 assessments on v11.8.0 or earlier can no longer be submitted. Any e1 and i1 assessment unsubmitted by then will need to be upgraded to v11.9.0 or later. r2 assessments can continue to use any version 11.x, since the deadline only applies to e1 and i1. 

Starting on v11.8.0 late in the year can make sense for an organization already deep into preparation. If there is any chance fieldwork or remediation slips into spring, building toward v11.9 from the start avoids reworking evidence midstream. 

“RISK-BASED” NOW NEEDS A PAPER TRAIL 

Many organizations already describe their security practices as risk-based, but under v11.9, written policies and standards need to show the reasoning: 

• Vulnerability management defines risk-based scanning frequencies (at least annually), remediation timeframes tiered by severity and exploitability, how a fix is confirmed, and formal risk acceptance for what can’t be fixed in time. 
• Patch management sets risk-tiered timeframes for vendor security updates, covering automated updates and systems that need manual installation. 
• Change management defines risk classifications, the factors used to assign them, and the testing and approval each classification requires. 
• Endpoint protections beyond traditional antivirus are selected through a documented risk assessment. 

The risk assessment itself carries more weight, too. It should account for changes in how exploitable vulnerabilities are and in threat conditions, and it should be updated when those changes materially affect your risk. HITRUST’s release notes cite updates made in response to AI-enabled vulnerability research, and faster exploit discovery is exactly why exploitability, alongside severity, now drives remediation timelines. 

FIELDWORK WILL TEST WHETHER CONTROLS CATCH EXPLOITATION 

Policies set the expectation, but operating evidence proves it works. During v11.9 fieldwork, expect assessors to ask for: 

• Change records that show the risk classification each change received. 
• Logs that capture events and fault conditions that may indicate exploitation, such as unexpected outbound connections, inter-process injection or suspicious scheduled tasks. 
• Administrator and operator log reviews performed at a frequency set by documented risk, by named reviewers with defined qualifications. 
• An incident response capability that coordinates with vulnerability management, security monitoring and forensics, with lessons-learned activities that flag recurring, high-impact or exploitation-related incidents. 
• Incident response testing at least annually, more often where your risk assessment calls for it, using scenarios drawn from that risk assessment. 

That last item connects everything. A tabletop exercise built around a generic ransomware script won’t demonstrate much if your risk assessment names a different threat as your top concern. 

CRYPTOGRAPHY STARTS WITH AN INVENTORY 

You can’t plan a post-quantum migration for keys you haven’t found. v11.9 asks for an inventory of cryptographic assets, including algorithms, protocols, certificates, keys and cryptographic libraries, and an IT asset inventory that records each asset’s operating system version, build or release, and patch level. 

From there, data in transit should use TLS 1.3, or TLS 1.2 limited to NIST-approved cipher suites. Encryption at rest should identify the algorithm and key strength. Encryption policies, and information-exchange agreements where relevant, should address the lifecycle status of cryptographic algorithms and the need for quantum-resistant mechanisms. 

Authentication policies now extend to passwordless options such as passkeys. Expect to verify a user’s identity before resetting a password or registering a passwordless authenticator, and to show the configuration that enforces passwordless authentication where you use it. 

SMALLER CHANGES WITH REAL OPERATIONAL REACH 

A handful of narrower requirements will touch teams outside security: 

• Secure coding guidelines should address common, complex, and context-dependent weaknesses, including those identified by OWASP, and outsourced development contracts should cover finding and fixing technical vulnerabilities. 
• Application or system owners should approve each system’s sensitivity classification. 
• If nonpublic information can be posted publicly, including to AI services where you can’t control downstream use, designate the individuals authorized to post it. 
• Immutable or offline backups should be protected from modification or deletion for a period your organization defines. 

WHERE TO START BEFORE YOUR NEXT ASSESSMENT 

Most v11.9 gaps begin as a missing definition, so start with policies. Check whether each one states the risk tiers, timeframes and owners that v11.9 expects. Then pull a sample of recent change tickets, a log review record and your last incident response test and see whether each shows the risk reasoning behind it. Where it doesn’t, you have your remediation list, and time to work through it before the version deadline makes the choice for you. 

360 Advanced is a HITRUST Authorized External Assessor. Learn more about our HITRUST CSF assessment and certification services, and see HITRUST’s CSF v11.9.0 release advisory for the full summary of changes. People-First. Technology-Forward. professionals focused on the decisions that matter. Learn more about our SOC 2 examinations. People-First. Technology-Forward.