What the domain asks for and why it fails
Endpoint Protection is one of the 19 assessment domains HITRUST uses to group its requirement statements and score e1, i1 and r2 reports. The domain covers the devices that can reach the in-scope environment, including laptops, desktops, servers and mobile devices. Its purpose is to keep malware and unmanaged or misconfigured devices from reaching in-scope data. An assessor will look at whether each such device is known, protected and configured to a defined standard throughout the assessed period.
Why this domain fails. The HITRUST 2025 Trust Report says Endpoint Protection was the most common domain causing submitted assessments to fail certification in 2024, accounting for 12.2% of failing domains. The report does not diagnose causes, so a useful starting point is scope. A single device that is missing from the inventory, runs without endpoint detection or has drifted from its baseline can weaken the evidence for the whole domain. Before fieldwork, compare the device inventory with every system that touches in-scope data, including contractor and personally owned devices.
Owning a control and preparing its evidence are different jobs. The organization owns its endpoint controls, their daily operation and the decisions behind them, including what counts as in scope. An implementation partner can prepare endpoint tooling, configuration baselines and evidence exports. Only an Authorized HITRUST External Assessor performs the validated assessment that can be submitted for certification, and HITRUST performs central quality assurance before it issues the report. Ask any partner to state in writing which of these tasks it will perform and which it will not.
The HITRUST requirement statements for this domain are proprietary, so this page describes the domain only and does not restate them. Obtain the statements from HITRUST or your assessor before drafting any control narrative. Check inheritance early as well. In HITRUST's example of inheritance from Oracle Cloud Infrastructure, Endpoint Protection is only slightly inheritable: the customer still secures endpoints with EDR, patching and MDM and configures its own compute workloads.
Which devices and teams are in scope
Endpoint scope follows every device that can reach the in-scope environment, including devices the organization does not own. The decisions below change the control work, the evidence it produces and who must be involved.
User laptops and desktops
Every laptop and desktop that can sign in to, sync with or reach a system in the assessed scope belongs in this domain, wherever it is used. Check the device inventory against identity and network records, because a device missing from the inventory usually has no EDR, patching or configuration baseline applied. Confirm the device types your scope statement covers before testing begins.
Mobile devices that reach the environment
Phones and tablets count here when they can read email, open sessions or hold data from the in-scope environment. Endpoint protection covers their malware defenses, OS currency and management enrollment, while the detailed mobile requirements sit in 04 Mobile Device Security. Ask which apps and access paths reach in-scope systems so the device list matches what actually connects.
Servers and workloads the organization runs
Virtual machines, container hosts and bare-metal servers that the organization builds and operates are in scope, along with the agents, patching and configuration on each one. These are often the most consequential endpoints because they hold data and run services directly. Check that every production and supporting workload has a named owner, agent or monitoring coverage and a documented baseline.
BYOD versus managed devices
Whether personal devices may reach the environment changes the work more than most other scoping decisions. Managed devices let the organization enforce disk encryption, patch levels and removal of access through its own management tooling. Personal devices need a documented boundary, such as access only through managed browsers or virtual desktops, and evidence that the boundary is enforced.
Contractor and third-party devices
Contractor laptops that sign in to the environment are in scope even though the organization does not own them. Decide whether contractors use organization-issued devices, a managed virtual desktop or their own machines under agreed posture checks. Confirm the contract requires those checks, and review their evidence alongside the controls in 14 Third-party Assurance.
Cloud inheritance has limits
In HITRUST's OCI inheritance example, endpoint protection is only slightly inheritable. The cloud provider secures its facilities and infrastructure, but the customer still runs EDR, patching and MDM on its endpoints and configures its own compute workloads. Confirm the provider's responsibility documentation and map each endpoint control to the party that operates it.
How an assessor tests endpoint protection
This table lists each step an assessor takes for the 02 Endpoint Protection domain, what they examine, and the usual reason a step produces a finding, so readers can prepare evidence before fieldwork.
| Test step | What the assessor examines | Common finding |
|---|---|---|
| Population and inventory | Builds the device population from directories, MDM and EDR consoles, then compares the list against the in-scope environment | Laptops, workstations or servers that reach in-scope systems but are missing from the inventory |
| Sampling | Selects devices from the population across user groups, server roles and operating systems, and checks each sampled device individually | Sampled devices with no agent or with an agent that has never reported |
| EDR review | Confirms the agent is installed, running, current in version and reporting to a managed console with malware detection enabled | Stale agents, disabled services or consoles that show last-seen dates weeks old |
| Patching review | Checks patch status and the timing of updates against the organization's own documented patching rules | Devices past the documented patch window with no tracked exception |
| MDM and configuration review | Inspects MDM enrollment, disk encryption, screen lock and host firewall settings against the approved baseline | Baseline settings that differ between device groups or that the MDM policy never enforces |
| Configuration baseline inspection | Compares sampled device configurations with the baseline the organization approved, often using scan output from a compliance tool | Unapproved changes on sampled devices that no change record explains |
| Exception review | Reads each exception for an approver, a business reason, a compensating control and an expiry date | Undocumented exceptions, expired exceptions still in use or exceptions without compensating controls |
| Remediation follow-through | Traces findings from earlier scans or tests to tickets, owners, fix dates and a re-test showing the issue closed | Findings closed without re-testing or tickets that were never linked to the affected devices |
Implementing the domain in order
The sequence below moves 02 Endpoint Protection from an unknown device population to evidence an assessor can test, with each step handing over a defined output.
Build the in-scope device inventory
Your team lists every laptop, workstation, server, phone and tablet that can reach the in-scope environment, including personal devices used for access. The output is a named inventory with owner, device type and assessed status, reviewed against directory and network records. The step is done when someone outside the project can reconcile the inventory against access logs and find no unexplained devices.
Define the endpoint baseline
Your security owner writes a baseline covering malware protection, secure configuration, patching, disk encryption and MDM enrollment, with a stated requirement for each device class. The output is an approved baseline document that names the owner of each control and the platforms it applies to. Confirm the exact settings and thresholds with your own policy owner and the platform vendors, since they vary by operating system.
Deploy and verify agents
Your platform team installs the chosen endpoint agents and MDM enrollment through your standard software distribution, then verifies each device reports in. Open-source agents such as osquery can be deployed and managed inside your own infrastructure. The output is a verification record showing which devices report, which fail to report and why, with failures routed to the inventory owner.
Set up continuous posture checks
Your team converts each baseline requirement into a scheduled check that runs across the fleet, such as a yes or no policy query or a configuration assessment against a benchmark. The output is a dashboard showing passing and failing devices per requirement, with history retained for assessment. The step is done when a deliberately misconfigured test device is flagged within the scheduled check interval.
Define the exception and remediation process
Your risk owner writes the steps for handling failing devices, the criteria for a documented exception, who may approve it, and when an exception expires. The output is a written procedure, an exception register and a remediation tracker linked to the posture dashboard. The step is done when each failing device in the test population has either a remediation ticket or an approved, dated exception.
Run a pre-assessment test
Your team or an independent reviewer samples devices from the inventory and tests each baseline requirement against the evidence the process produces. The output is a gap list ranked by severity, with an owner and a remediation date for each item. Only an authorized external assessor can perform the validated assessment, so this test prepares your evidence but does not replace that review.
Evidence that passes and how to keep it current
Each artifact needs a date and a way to regenerate it from the same source, so an assessor can reproduce the result. Refresh the full set on a fixed cycle between assessments and keep prior versions for the assessment period.
Device inventory export
A device inventory export lists every laptop, workstation, server and mobile device that can reach the in-scope environment, with owner, operating system and last check-in time. Assessors compare it with directory and network records to test completeness. Confirm that the export comes from the management platform on a known date and that any device missing from it is investigated.
Endpoint protection policy and baseline
The policy states which endpoint controls apply and who owns them, while the baseline sets the configuration each device must meet, such as detection agents installed, disk encryption enabled and host firewalls on. Assessors check that the baseline matches what is deployed and that it was approved and reviewed on a set cycle. Keep version history so the copy you show is the one in force during the period tested.
Agent coverage reports
Agent coverage reports show how many inventoried devices report in with endpoint detection, antivirus or other protection agents, and which do not. Generate them from the same date as the inventory export, because a coverage figure built on a different device population invites questions. Scheduled osquery or Fleet queries can show which hosts respond, but confirm that the query set matches your baseline.
Patch and configuration compliance reports
These reports show, device by device, whether operating system patches and baseline settings are applied. Assessors look at the failing population, the age of open items and whether approved exceptions cover the gaps. Wazuh Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Confirm which policy set you run and retain the results from each scan.
MDM enrollment records
MDM enrollment records prove that laptops and mobile devices used to access in-scope data are enrolled, managed and subject to required settings. Export enrollment status with dates and compare it with the inventory to find unmanaged devices. Personal and contractor devices often fall outside this set, so document how they are handled or excluded and who approved that position.
Exception register and remediation tickets
The exception register records each device or control deviation, its business reason, compensating measures, expiry date and approver. Remediation tickets show how findings from coverage and compliance reports were closed, with timestamps. Assessors sample both, and an exception without an approval or a finding without a closed ticket is easy to find in sampling. Review exceptions on the same cycle as the baseline.
What meeting the domain costs
This table separates the cost components of the 02 Endpoint Protection domain, shows who is paid for each, whether it is one-time or recurring, and what drives it up, so you can ask vendors and assessors for written quotes that match.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Endpoint security tooling or licenses | Commercial EDR, MDM or anti-malware vendor | Recurring, usually per device or per user | Device count, device types (laptops, servers, mobile), and whether vendor tiers include the logging or reporting you need |
| Open-source tooling in place of licenses | No license fee; staff or implementation partner time to deploy and run it | Removes most recurring license spend; staff time remains | Fleet size, number of sites, and how much custom policy and telemetry storage you operate yourselves |
| Engineering time to deploy and baseline devices | Internal platform or endpoint team, or an implementation partner under a fixed-scope agreement | One-time for the initial rollout, then periodic for new device types | Number of sites and device types, existing configuration drift, and how many exceptions must be documented before rollout |
| Exception handling and documented risk acceptance | Internal security and risk owners | Recurring, tied to review cycles | Number of exceptions, such as legacy systems or unmanaged devices, and how often each must be re-justified |
| Ongoing evidence upkeep | Internal compliance or security operations staff, or a retained partner for continuous testing | Recurring for the life of the certification | Frequency of policy and configuration reports, how many devices must be sampled, and how evidence is stored and retrieved |
| External pre-assessment testing | An independent tester or assessor firm chosen by you | One-time per readiness cycle, repeated if gaps are found | Scope size, number of device types tested, and how many remediation rounds you need before the formal assessment |
| Assessor fieldwork | An Authorized HITRUST External Assessor organization | One-time per assessment cycle; fieldwork runs within a window of at most 90 days | Assessment type (e1, i1 or r2), number of sites and devices sampled, and the quality of evidence on the first pass |
| Quote requirements | Vendors, implementation partners and assessors | Ask for each line separately | Request written quotes that state device counts, site counts, license tier, exception assumptions and the evidence each deliverable produces |
Who does what for this domain
Your organization owns the endpoint control decisions and the record behind them. An assessor tests those decisions first, so they need to be documented and signed off by people accountable for them.
- Device policy: approve the standard that governs laptops, workstations and servers able to reach the in-scope environment.
- Inventory: keep the authoritative list of in-scope devices and name an owner for each one.
- Exceptions and risk acceptance: decide which deviations are allowed, record the reason and formally accept the residual risk.
- Daily operation: run patching, triage endpoint detection alerts and track remediation to closure.
An implementation partner builds the technical controls and assembles the evidence so your team can show they work. The partner prepares systems and records, but it does not make the control decisions.
- Agents and baselines: deploy endpoint agents and secure configuration baselines in your environment.
- Dashboards: build fleet views that show which devices pass or fail each policy, using tools such as osquery or Fleet once their fit with your stack is confirmed.
- Evidence packs: organize configuration exports, scan results and exception records against the requirement statements in this domain.
- Pre-assessment testing: run internal tests to find gaps before the external assessor begins fieldwork.
- Limits: the partner does not set policy, approve exceptions or accept risk on your behalf.
Independent assessment sits apart from the implementation work. Only an Authorized HITRUST External Assessor may perform a validated assessment submitted for certification.
- Validated assessment: the assessor tests this domain and reports results under HITRUST scoring.
- Quality assurance: HITRUST performs central quality assurance before it issues the report.
- Independence line: the implementation partner cannot issue the result, draft the conclusions or influence the scoring.
- Selection check: confirm the assessor appears on HITRUST's external assessor directory before you sign a contract.
- Outsourcing pattern: organizations usually outsource the implementation and pre-assessment work, while the validated assessment itself stays with the assessor.
Where organizations fall short
Five gaps recur in endpoint assessments. Each card names the gap and the action that closes it.
Unmanaged personal devices
Personal laptops and phones reach the in-scope environment through email, VPN or browser sessions without enrollment in device management, so no one can show their disk encryption, OS version or EDR status. HITRUST reported Endpoint Protection as the domain most often behind failed submissions in 2024. Compare every access path with the device inventory, and block access from devices that fail enrollment or posture checks.
Agents installed but silent
An EDR or management agent present on the image but absent from the console provides neither protection nor evidence. The assessor will expect proof that coverage is current across the fleet, supported by a recent check-in record. Reconcile the console host count against the asset inventory every month, and treat any host that has not reported in a set period as uncovered until a query confirms otherwise.
Patch status measured on a sample
Reporting patch levels for a handful of machines lets a failing population hide in the rest of the fleet. Assessors look for a measure that covers every in-scope host, with the query, scope and run date recorded. Schedule a fleet-wide query for installed patch levels, such as an osqueryd schedule across all enrolled hosts, and reconcile its host count before reporting a percentage.
Exceptions without expiry
A deviation approved once and never revisited becomes a permanent gap. Each exception should name the control, the affected devices, the compensating measure, the approver and a review date. Fleet policies show which devices pass or fail each yes or no check, so every failing device should map to a dated exception or an open remediation ticket. Expired exceptions go back to the owner for renewal or closure.
Evidence that cannot be reproduced
A screenshot captures one moment in a console, with no query, host scope or timestamp, so an assessor cannot rerun it or confirm the population behind it. Replace screenshots with exported results that record the query, host count and run time, and keep the query in version control. Velociraptor hunts keep the collection and a notebook per hunt, which gives a repeatable record of how each result was produced.
Frequently asked questions
How much effort does HITRUST endpoint protection take?
The effort depends mostly on how many devices can reach the in-scope environment and how closely your current endpoint controls already match what the domain tests. Costs come from three areas: staff time to build a complete device inventory, deploying and tuning agents such as EDR and patching tools, and collecting evidence that each control operated across the assessment period. Ask any provider to price these as separate items in the written scope, and ask which parts recur each year, such as policy reviews, fleet reporting and evidence refresh.
Can our own team complete the endpoint protection domain in-house?
Yes, if your team already runs endpoint management and can show evidence for each requirement statement in the domain. The common gap is consistency: controls that work on most laptops but are missing on a few servers, contractor devices or unmanaged phones. Endpoint protection was the most common domain causing submitted assessments to fail certification in 2024, accounting for 12.2% of failing domains, according to the HITRUST 2025 Trust Report. Only an authorized HITRUST External Assessor performs the validated assessment, and an implementation partner can prepare systems and evidence but cannot issue the report.
How long should endpoint preparation take before a HITRUST assessment?
Plan for preparation to finish before fieldwork begins, because the length depends on your device inventory and the gaps you already have. The validated assessment fieldwork window is at most 90 days for e1, i1 and r2, according to the HITRUST Assessment Handbook v1.1, so the assessor's testing period is capped while your preparation is not. Preparation includes confirming which devices are in scope, closing deployment gaps and collecting dated evidence for the review period. Ask your assessor which evidence dates they will sample, and ask for a dated preparation plan before you commit.
Do inherited cloud controls reduce endpoint protection work for our workloads?
Only slightly. HITRUST's inheritance example for Oracle Cloud Infrastructure treats endpoint protection as only slightly inheritable, because the customer still secures endpoints with EDR, patching and MDM and configures its own compute workloads. A cloud provider can cover hosted platform layers, but laptops, administrator workstations and the operating systems you run remain your responsibility. Confirm the inheritance split in writing with your assessor before you rely on it in your planning.
How does endpoint protection differ from mobile device security and configuration management?
Endpoint protection covers laptops, workstations, servers and other devices that reach the in-scope environment, with malware defenses and secure configuration at its core. Mobile Device Security (04) covers phones and tablets, including encryption, device management and conditional access. Configuration Management (06) covers secure baselines, change control and configuration of systems and services in scope. The three domains overlap on device management, so assign each requirement statement one owner and one evidence set to avoid duplicate work.
How DeployOpen prepares endpoint evidence
DeployOpen plans, builds and documents self-hosted open-source endpoint tooling inside your own infrastructure, so your team owns the controls and receives the evidence. An Authorized HITRUST External Assessor performs the validated assessment and issues any report.
How we scope
- The written scope lists which Endpoint Protection requirement statements and device types are in the assessed environment.
- Laptops, workstations, servers and mobile devices that reach the in-scope environment are inventoried before any tooling is chosen.
- Engagements are fixed-scope, with deliverables agreed in writing before work starts, and ongoing support available as a retainer.
How we build
- Fleet policies, osquery queries and Wazuh configuration checks are set up to test each in-scope requirement statement.
- Velociraptor artifacts and hunts are configured to collect forensic evidence from endpoints, including devices that reconnect after being offline.
- Configuration hardening follows the agreed baseline, and each change is recorded so an assessor can trace it.
How we hand over
- Evidence is indexed to each Endpoint Protection requirement statement, with open gaps listed for the client to close first.
- Runbooks document how each tool is operated, who reviews its output and how often.
- The client keeps ownership of the controls and submits evidence; an Authorized HITRUST External Assessor reports on it.
How we support
- Retainers cover upgrades to the scanning and monitoring platforms and their configuration as tool versions change.
- Ongoing endpoint policy reviews keep Fleet and Wazuh checks aligned with the requirement statements in scope.
- Continuous security testing of the endpoint tooling is available, and retesting follows any remediation the assessment identifies.
