Why HITRUST assessments fail and what causes it

Why do HITRUST assessments fail, and which domains cause it?

Failed HITRUST results concentrate in a few domains. In 2024, Endpoint Protection was the most common domain causing submitted assessments to fail certification, accounting for 12.2% of failing domains, according to the HITRUST 2025 Trust Report. Audit Logging & Monitoring and Risk Management were each 9.8% of failing domains and tied for second, while Vulnerability Management accounted for 7.3%. If a customer or contract now requires HITRUST, these four domains are where to look first, but they are a starting point, not a guarantee of where your own assessment will struggle.

The causes differ by organization. They depend on the systems in scope, how much of the environment your own controls cover, whether inherited results from a cloud provider or vendor apply, and how mature your evidence is. An endpoint gap, for example, usually means the scope includes laptops, desktops or mobile devices that reach the in-scope environment without consistent configuration, patching and monitoring. Ask your team to confirm which devices and accounts fall inside scope and whether each one can produce current evidence for the control, because that is where a low domain score usually starts.

Your organization owns its controls. An implementation partner can prepare systems, configurations and evidence for the assessment, but only an authorized HITRUST External Assessor performs the validated assessment, and HITRUST's quality assurance decides the result before any report is issued. If the thresholds are not met, the report is a validated-only report with no certification letter. Before you commit to a timeline or a partner, ask the assessor to explain how they will test your weakest domains, and confirm what the HITRUST Assessment Handbook requires for your assessment type.

Which domains fail most often and what each one tests

HITRUST's 2025 Trust Report points to a small set of domains that repeatedly pull assessments below threshold. Each card below describes what the domain covers, why organizations commonly fall short, and the evidence an assessor will look for before scoring it.

Endpoint protection

This domain covers user laptops, desktops and mobile devices that can reach the in-scope environment, including how they are configured, patched, protected against malware and managed when lost or retired. Organizations often fall short because the device inventory is incomplete, with personal or contractor devices outside central management. Check that every device category in scope has a current inventory, enforced configuration baselines and documented exceptions, and that assessors can trace device records to real access logs.

Audit logging and monitoring

This domain tests whether logs are generated, protected, reviewed and acted on for systems that handle in-scope data. Organizations commonly collect logs but never define how often they are reviewed, how each review is recorded or who signs it off, which is the gap that most often becomes a corrective action. Confirm that review frequency, reviewer roles and review records are written down, and that sample reviews exist with dated sign-offs and follow-up tickets.

Risk management

This domain examines how the organization identifies, assesses and treats risk, and whether management formally authorizes new systems before they go live. Organizations often have a risk register but no evidence that leadership reviewed it or approved systems entering production. Check that risk assessments are current, that treatment decisions name an owner, and that authorization records exist for each system in scope, with periodic reviews of those authorizations.

Vulnerability management

This domain covers how vulnerabilities are found, prioritized, remediated and verified across the in-scope estate. It was the lowest-scoring domain for i1 validated assessments in 2024 and a close second for r2, because scan schedules often exist without documented remediation timelines or proof that fixes were retested. Confirm scan coverage against the asset inventory, a defined prioritization method, tracked remediation records and evidence that exceptions were approved by someone with authority to accept the risk.

Access control

This is the lowest-scoring e1 domain in both 2023 and 2024, covering how user identities are created, authenticated, granted least privilege and removed. Organizations commonly fall short on periodic access reviews, leavers who keep active accounts and shared or privileged accounts without clear ownership. Check that provisioning requests are approved, that access reviews are performed on a schedule with recorded decisions, and that deprovisioning timestamps can be matched to HR termination dates.

Which domains score lowest for e1, i1 and r2

The e1 is the smallest validated assessment in the portfolio, with 44 requirement statements in CSF v11.9. HITRUST's 2025 Trust Report names Access Control as the lowest-scoring e1 domain in both 2023 and 2024, which makes it the domain most worth checking first. The e1 scores the Implemented maturity level, and each domain's core statements must average at least 83 for the domain to pass.

Why the average matters: A single weak core statement can pull a domain below 83 even when most of its statements are strong, so one unmet access control drags down the whole domain.
What Implemented means: Evidence must show that the control operates in practice, not only that a policy exists. Access reviews, provisioning records and privileged account logs are the kinds of artifacts assessors look for.
Small statement count: With 44 statements, each one carries more weight than in the i1 or r2, so gaps are harder to offset.
Common gap pattern: Organizations often document joiner and leaver processes but cannot show recent review records, which weakens the implementation evidence.
Ask your assessor: Confirm which e1 statements in Access Control map to your identity platform and which evidence windows apply.

Before the fieldwork window opens, check whether your access review cadence and records are current enough to present as operating evidence.

What a validated-only report means for a customer or contract

When an assessment does not meet the certification thresholds, the vendor receives a validated-only report, and that report carries no certification letter. The report states that the thresholds were not met. For a customer or procurement team, this means the vendor cannot present a HITRUST certification, even though a formal assessment was completed by an Authorized HITRUST External Assessor and reviewed by HITRUST. Any contract clause that requires a HITRUST certification is not satisfied by a validated-only report, and a vendor who describes the work as certified is misstating the outcome.

The validated-only report is not empty. It still shows the scored results across the assessment domains, so a reader can see which domains fell below the averages required for certification and how far they fell. Those domain results are the most useful input for a vendor risk review, because they show where the control environment is weakest. A common pattern in failing results is weakness in domains such as Endpoint Protection, Audit Logging & Monitoring, Risk Management and Vulnerability Management. A customer can use that detail to decide whether the gaps are acceptable for the service being bought, whether to request remediation evidence, or whether to add contractual controls for those areas.

Ask the vendor for the full validated-only report itself, not a summary letter or a slide that describes the outcome. Then confirm how your contract defines acceptable evidence: whether it names a HITRUST e1, i1 or r2 certification, accepts a validated assessment without certification, or allows another report such as a SOC 2 examination. Check the report date and scope against the services you are buying, and ask who at the vendor owns the corrective actions. Write these answers into the contract or the due diligence file so the decision does not depend on how a summary is worded.

How to reduce the risk of failing a domain before fieldwork

This sequence helps an organization find the domains that most often fall short, close the evidence gaps behind them and confirm the boundaries of the assessment before the External Assessor begins fieldwork. It reduces surprises but does not guarantee a passing result.

Confirm scope and systems in writing
The assessment owner, usually the GRC or security lead, lists every system, environment, facility and third party that touches the in-scope data, and records which of them are in the assessed boundary. Platform and infrastructure teams confirm the list against asset inventories and network diagrams. The step is done when a signed scope statement exists that names each system and the reason it is in or out. Scope errors discovered late tend to force rework across many domains, so this record comes first.
Run an internal readiness review
An internal reviewer, ideally someone who was not responsible for the controls, walks through each requirement statement in the domains that most often fail. The reviewer checks whether a documented control exists, whether it operates as written and whether the owner can explain it. The output is a readiness register that rates each statement as ready, partially ready or missing evidence, with an owner and a named artifact for every open item. Reviewers should not assume that a control passes because a policy exists.
Close endpoint protection evidence gaps
Endpoint protection was the most common failing domain in the HITRUST 2025 Trust Report, so the endpoint team reconciles the device inventory against the in-scope environment, including laptops, desktops and mobile devices that can reach in-scope systems. They confirm that protection agents, configuration baselines and patch status are reported centrally and can be exported for a sample of devices. The step is complete when every device in the inventory has a traceable record and any unmanaged device has a documented exception or removal ticket.
Close audit logging and risk authorization gaps
Audit logging and monitoring and risk management each accounted for a share of failing domains in 2024, so the logging team defines how often logs are reviewed, who reviews them and how each review is recorded. The risk owner documents how new systems are formally authorized and how those authorizations are reviewed. The output is a review procedure with dated sign-off examples and an authorization record for each in-scope system. Teams should confirm that both sets of records exist for past periods, not only from the start of the readiness work.
Close vulnerability management evidence gaps
Vulnerability management was the lowest scoring domain for i1 validated assessments in 2024 and a close second for r2, so the security operations team gathers scan schedules, scan scope, remediation tickets and exception approvals for the in-scope assets. They check that scan coverage matches the asset inventory from step one. The step is complete when a sample of findings can be traced from detection through remediation or documented risk acceptance, with the timing recorded for each.
Test evidence consistency across samples
Assessors select samples, so the readiness team pulls several samples for each control and checks that the artifacts tell the same story. A logging review record should match the log retention period, and an access list should match the authorization record for the same system. The output is a consistency log that flags contradictions, missing dates, unnamed approvers and screenshots that do not match the stated configuration. Each contradiction is fixed at the source before fieldwork, not explained after the fact.
Confirm in-scope items with the External Assessor
Before fieldwork starts, the organization sends its scope statement, readiness register and open items to the External Assessor and asks them to confirm which items are in scope, which are excluded and which evidence formats they expect. The assessor makes the final determinations, since only an Authorized HITRUST External Assessor organization performs the validated assessment. The step is complete when the assessor's written confirmation is filed with the assessment records, and any scope disagreement is resolved in writing before the fieldwork window opens.

Who owns each part of a failed or passed assessment

A HITRUST validated assessment depends on four parties with separate jobs: the organization that runs its controls, the partner that prepares systems and evidence, the External Assessor that tests and scores them, and HITRUST that reviews the submission. Knowing which party owns which result shows where a failing domain was actually decided and who must fix it.

The organization owns the controls

The organization operates its controls every day and owns the evidence they produce. Most domains that fall short, such as endpoint protection and vulnerability management, fail because the control ran inconsistently or left no record, not because a document was missing. Check that each in-scope control has a named owner, a repeatable procedure and evidence that covers the full assessment period.

The implementation partner prepares

An implementation partner such as DeployOpen can configure self-hosted open-source platforms so they produce logs, access records and patch data in the form an assessor will sample, and it can write documentation and run readiness testing. The partner does not score controls, issue reports or certificates. Confirm in writing that the partner's work is limited to preparation and that the organization keeps ownership of its control statements.

The External Assessor tests and scores

Only an Authorized HITRUST External Assessor organization may perform the validated assessment submitted for certification. It runs fieldwork, samples evidence, assigns scores and submits the results, and the fieldwork window for e1, i1 and r2 is at most 90 days. Ask whether the assessor has any role in building the controls it will later test, because that conflict can affect its independence.

HITRUST reviews and issues

HITRUST performs central quality assurance on each submitted assessment before it issues a report. If the thresholds are not met, HITRUST issues a validated-only report that states this and carries no certification letter. Read the report itself, not a summary, to confirm which outcome was issued and which domains drove it.

Common questions about HITRUST assessment failure

Does one failing domain mean the whole HITRUST assessment fails?

For certification, yes. Each domain has its own threshold. The e1 and i1 need the core statements in each domain to average at least 83 at the Implemented maturity level, and the r2 needs each domain to average at least 62 across policy, procedure and implementation maturity. If any domain falls below its threshold, the assessment does not meet the certification thresholds, and HITRUST issues a validated-only report that states the thresholds were not met and contains no certification letter. Passing the other domains does not carry the certificate. Ask your assessor to walk through domain-level scores before fieldwork closes, so you know exactly which domains are close to the line and which are well below it.

Can we fix a failing domain before fieldwork starts?

Yes, and that is the purpose of readiness work, provided the fix produces evidence an assessor can test. Assessors look for controls that operated over the period they examine, so a policy written shortly before fieldwork rarely shows operating history. Prioritize the domains that most often fall below threshold: Endpoint Protection, Audit Logging & Monitoring, Risk Management and Vulnerability Management, along with Access Control for e1 assessments. For each, confirm a named owner, run the control on its defined schedule, and keep the records it generates, such as scan results tracked to closure, reviewed logs, approved access lists and documented management authorizations. Fieldwork is capped at 90 days for e1, i1 and r2 assessments, so unresolved gaps should be closed before that window opens.

How long does HITRUST preparation take, and what drives the timeline?

No duration has been established for this, so confirm the schedule with your authorized assessor before committing budget or dates. The main drivers are your current maturity, the size of the scope (systems, locations, data flows and third parties), whether controls already generate evidence, how much you can inherit from cloud providers or vendors, staff availability, and how many domains need remediation. The assessor's validated fieldwork window is at most 90 days for e1, i1 and r2 assessments, but that window covers only fieldwork. Ask for a written schedule that separates readiness review, remediation, evidence collection, fieldwork and HITRUST quality assurance, and that states which dependencies, such as system changes or third-party responses, could move each milestone.

Can we run HITRUST readiness ourselves or do we need a consultant?

Many organizations run readiness internally, especially where staff already understand the requirement statements and can produce evidence on a steady schedule. A consultant or implementation partner makes sense when internal teams lack time, when the scope is large, or when remediation touches several platforms at once. Ownership stays with your organization in every case: you own the controls, a partner prepares systems and evidence, and only an authorized HITRUST External Assessor performs the validated assessment and only HITRUST issues the report. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue reports or certifications. Engagements are fixed-scope, so request a written scope, deliverables and timeline before work starts, and confirm which items the assessor expects you to produce yourself.

What can we tell customers from a validated-only report?

A validated-only report does not support a claim that you are HITRUST certified. It shows that an assessment was performed and that its results did not meet the certification thresholds, and it includes no certification letter. Describe the outcome accurately if a customer asks, and avoid wording that implies a certificate exists. Before sharing the report itself, confirm with HITRUST and your assessor what the report permits you to disclose and to whom, and check your contracts for any obligations about security assessment results. Customers reading the report will look for the domain-level picture, so be ready to explain which domains fell short and what your corrective plan covers. Plan a new validated assessment only after the affected controls have operated long enough to produce evidence.

Which HITRUST domains should we check first if we have never been assessed?

Start with the domains that caused the most failures in HITRUST's 2025 Trust Report data for 2024. Endpoint Protection was the most common cause of failed domains, at 12.2% of failing domains, and covers laptops, desktops and mobile devices that can reach the in-scope environment. Vulnerability Management was the lowest scoring domain for i1 assessments and a close second for r2, at 7.3% of failing domains. Audit Logging & Monitoring and Risk Management each made up 9.8% of failing domains, tied for second. Access Control was the lowest scoring e1 domain in both 2023 and 2024. For each, ask: do we have a complete inventory of devices and accounts, are findings tracked to closure, are log reviews defined with frequency, documentation and a named reviewer, and are new systems formally authorized by management?

How DeployOpen prepares systems and evidence for HITRUST

DeployOpen works on the domains that most often fall below threshold in HITRUST assessments: endpoint protection, audit logging, risk management and vulnerability management. We prepare the self-hosted open-source platforms and the evidence behind them inside your own infrastructure, while your organization owns its controls and an authorized external assessor performs the validated assessment.

How we scope

Written scope names which assessment type, in-scope systems and domains the engagement covers before work starts.
Scope also records which domains depend on endpoint, logging and vulnerability tooling that DeployOpen will build or configure.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any platform work begins.

How we build

We configure logging and monitoring platforms so audit records exist, are retained and can show who reviewed them and when.
We deploy endpoint and vulnerability management tooling so coverage across in-scope devices and assets can be shown to an assessor.
Security testing of applications, APIs and infrastructure produces findings that feed the remediation evidence assessors ask to see.

How we hand over

Documentation covers configuration, ownership, review cadence and the evidence each control produces, so your team can reproduce it.
Evidence packs are organized by domain so your assessor and internal reviewers can trace each control to its artifacts.
Handover identifies gaps that remain, such as review procedures or authorization workflows that only your organization can approve.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
Retainers can keep logging, endpoint and vulnerability evidence current ahead of an r2 interim assessment or renewal.
Confirm with DeployOpen during scoping which support terms apply and how changes to in-scope systems will be handled.

Why HITRUST assessments fail and the domains that cause it