HITRUST CSF Threat and Mitigation Analysis

The Threat Landscape is Evolving, but the Way in Still Looks Familiar

Cyber threats are moving faster. AI is giving attackers new ways to scale their efforts. But beneath all that change, some of the most effective ways into an organization remain surprisingly familiar.

HITRUST’s Q3 2026 threat analysis found that general malware, browser malware, phishing, backdoor malware, and software supply chain attacks were the five most commonly mentioned entry points in the threat research reviewed.

It’s a reminder that preparing for what’s next doesn’t mean leaving established risks behind.

Phishing tells that story particularly well. It remained the leading technique across both traditional MITRE ATT&CK and AI-focused MITRE ATLAS threat activity in Q3. And it frequently appeared alongside another familiar technique: User Execution.

In other words, attackers may have more sophisticated technology at their disposal, but getting someone to click, open, download, or act still works.

What does that mean for security assurance?

As attack methods evolve, organizations need to know whether their security controls are keeping pace with the threats they’re actually facing, not simply whether those controls existed at a point in time.

That’s the idea behind HITRUST’s Cyber Threat Adaptive process. Current threat intelligence is continuously analyzed against the HITRUST CSF to evaluate how assessment requirements align with observed adversary activity.

For Q3 2026, that analysis included:

• 9,859 threat articles
• 42,602,746 MITRE ATT&CK and MITRE ATLAS technique-level indicators
• 75 real-world breaches

The findings help evaluate whether HITRUST requirements continue to provide meaningful coverage against current and emerging threats.

But which techniques showed up most often? Where are organizations most exposed? And how do HITRUST’s e1, i1, r2, and AI Security Certification requirements map back to the threats being observed?

Read the Q3 2026 HITRUST CSF Threat and Mitigation Analysis for the full findings. 

The TPRM Top 10 - Closing Perspective on The TRPM Top 10

The challenges covered across this series of blog are not isolated weaknesses. They are interconnected symptoms of a TPRM operating model struggling to keep pace with complexity of modern vendor ecosystems:

• Insufficient staffing and technology limit capacity.
• Unreliable assurance creates additional review work
  
• Business dependencies pressure organizations to accept risks they do not fully understand or cannot adequately mitigate
  
• Manual processes consume scarce capacity
  
• Incomplete vendor data undermines risk visibility
  
• Limited supply chain visibility obscures material exposures

Emerging Themes from the Top 10

Across the ten issues, four areas consistently appear:

• Focus: Apply accurate risk tiering so the strongest requirements and most experienced judgment are directed toward the vendors that can create the greatest harm.
  
• Trust: Require independently validated assurance that makes scope, control coverage, exceptions, and shared responsibilities clear.
  
• Scale: Automate routine evidence collection, control mapping, and reassessment activity so analysts can spend more time evaluating and reducing material risk.
  
• Transparency: Extend ecosystem visibility beyond individual vendors to downstream providers, shared platforms, and concentration points

The answer is not another questionnaire or spreadsheet. The stronger model is both risk-based and evidence-driven. It directs attention to the vendors and control areas where failure would have the most significant consequences. Instead of requiring organizations to repeatedly collect the same evidence, it relies on reusable assurance that has been independently validated. The model also supports more effective oversight by linking monitoring activities to events which can change a vendor's risk profile over time.

These 10 issues are connected symptoms of an operating model struggling to keep pace with modern third-party ecosystems. They capture the key areas where TPRM leaders report their programs are breaking down, with the objective of equipping organizations to address these challenges in order to make more timely, defensible risk decisions.

Solving these challenges will require more than incremental improvements to existing processes. Organizations need a more scalable, risk-based model built on complete vendor data, standardized and independently validated assurance, greater automation, and deeper supply chain visibility. The objective is to develop sufficient confidence to identify material exposures early, focus expertise where it matters most, and make timely and defensible decisions.

The organizations best positioned for the future will be those that treat TPRM as an enterprise risk capability. By modernizing vendor assurance, TPRM programs can reduce friction while improving visibility and confidence. Ultimately, the goal is a program that can scale alongside the business without sacrificing the rigor needed to protect critical operations and data.

Check Out the Previous Blogs

•  Traditional Third-Party Risk Management Has Reached Its Operating Limit 
• The TPRM Top 10 - Vendor Growth Is Outrunning TPRM Capacity 
•  The TPRM Top 10 - Critical Vendors Become Too Important to Fail 
•  The TPRM Top 10 - Lack of Assurance Comparability 
•  The TPRM Top 10 - Manual Work Is Consuming TPRM Capacity  
•  The TPRM Top 10 - Hidden Vendor Risks 
•  The TPRM Top 10 - Incorrect or Incomplete Risk Tiering Is Directing Attention to the Wrong Places 
•  The TPRM Top 10 - Limited Visibility Into the Deep Supply Chain 
•  The TPRM Top 10 - Concentration Risk Turns Vendor Failures Into Enterprise Events 
•  The TPRM Top 10 - Unreliable Vendor Data Undermines Risk Decisions 
•  The TPRM Top 10 - Vendor Risk Is Changing Faster Than Reassessment Cycles 

*CHIME Digital Health Analytics. Third-Party Risk Management Assurance: Strategic Market Validation Survey. Commissioned by HITRUST. Ann Arbor, MI: College of Healthcare Information Management Executives, Digital Health Analytics 2026. In July 2026, HITRUST commissioned CHIME Digital Health Analytics to conduct a blinded market-validation survey of 102 qualified respondents from separate healthcare provider organizations with more than $1 billion in annual revenue. Respondents represented security and GRC leadership, TPRM ownership, procurement and vendor management, legal and contracting, and executive leadership. Every participating organization actively managed at least 200 third-party vendors, and 87% managed more than 500.

Trusting AI Requires More Than Trusting the Vendor

Satya Nadella recently posted about how to run powerful AI inside the enterprise, and one line in it should change how risk teams think. Validation, he wrote, must be independent of the thing being validated. He also said a model provider’s assurances don’t relieve the customer of responsibility. His post is about enterprises containing their own AI, but the principle applies to anyone relying on a third party.

AI is creating a challenge the assurance industry has never had to solve at scale. Traditional software typically behaves within predefined boundaries. Modern AI systems can reason, invoke tools, access enterprise data, and act on behalf of users.

The AI supply chain is rapidly becoming more complex than the software supply chain. As organizations increasingly rely on third-party AI, they are accepting risk from systems they did not build, cannot inspect, and often cannot independently test. That changes the question from "Does this vendor have AI?" to "What evidence exists that this AI operates within verified security boundaries?" The future of AI trust will be determined by how that question gets answered.

If a vendor is the only source of evidence about its own AI controls, you don’t have assurance. You have a claim. The vendor built the system, wrote the policies, and is now describing how well both work. Nadella’s point is that this arrangement shouldn’t be accepted, and he calls for industry standards where existing ones fall short.

What Programs Are Getting Today

In practice it comes down to two things.

The first is a questionnaire. A few AI questions get added to the existing set, the vendor answers them, and the answers go in the file. Nobody can say whether those were the right questions, whether the answers are accurate, or whether two vendors who both said “yes” meant the same thing. This is self-reporting, and no one independent has looked.

The second is a governance assurance, such as ISO 42001. That’s a real step up, and it’s independent. It tells you the vendor has a management system for AI: policies, roles, risk processes, accountability.

But governance and security are different questions. A management system standard tells you the vendor has a process for managing AI risk. It doesn’t tell you whether the model’s access to your data is limited to what it needs, whether prompt injection has been tested, whether actions are logged in a way that survives an investigation, or whether anyone can shut an agent down mid-task. A vendor can have mature AI governance and still have an agent with far too much access.

Where the Risk Actually Lives

Nadella’s post puts the weight on technical controls: separating the model from the harness that orchestrates it, limiting the action space, keeping safeguards outside the model, logging every meaningful action, and being able to contain a model from the start. The relevant questions are security questions:

• What can the AI reach, and who approved it?
• What can it do without a human signing off?
• Are those limits enforced outside the model, or does the system depend on the model behaving?
• Is there a tamper-resistant record of its actions?
• Can an authorized person stop it, and how fast?
• Has anyone tested it against attack, including misuse of connected tools?
• Which model providers and tools sit underneath, and what happens if one is compromised?
• When something fails, what does the customer get told, and when?

Questionnaires can ask about these but can’t verify them. Governance assurances generally don’t test them.

What TPRM Programs Need

Independent assurance over AI security controls, with a few properties:

• Independent. The party testing the controls didn’t build them and has no stake in the result.
• Explicit scope. You can see which AI systems were examined and which weren’t.
• Operating effectiveness. Controls were tested in practice, not just documented.
• Current. Models, prompts, and tool permissions change fast, so stale evidence misleads.
• Comparable. A common set of criteria lets you evaluate many vendors without a custom review for each.

Governance assurance and security assurance answer different questions, and a mature program should want both. The mistake is treating the first as a substitute for the second.

What to do This Quarter

Pull your last few AI-related vendor assessments and sort the evidence into three piles: self-reported answers, governance assurance, and independently tested security controls. Most programs will find the third pile nearly empty. That’s your gap.

Then change what you ask for. Skip the longer questionnaire. Ask which AI systems are in scope, who tested the security controls, against what criteria, and how recently.

The Caveat

Security assurance doesn’t prove a model’s outputs are correct or that it’s aligned with anyone’s intent. It tells you the vendor has limited what the AI can reach and do, can see what it’s doing, and can contain a failure. That shrinks the blast radius without eliminating the risk, and a good program should say so plainly.

But it’s the part buyers can demand today, and the part most programs are missing.