Endpoint Inventory and Visibility

The endpoint inventory and visibility requirement means you must maintain an accurate, complete list of every endpoint in scope and be able to show each device’s current security posture, patch status, and configuration compliance on demand. Operationally, that requires a single accountable inventory process, reliable discovery, and continuous reporting tied to remediation. ¹

Key takeaways:

• You need both inventory completeness and posture visibility (patching, protection, config compliance), not a spreadsheet of assets. ¹
• Auditors will test for unknown/unmanaged endpoints, coverage gaps (remote, BYOD, lab/clinical), and stale data. ¹
• Evidence must prove how endpoints are discovered, reconciled, monitored, and remediated, with clear ownership and repeatable reports. ¹

Endpoint inventory and visibility is a control you either operationalize end-to-end or you fail during an assessment. HICP Practice 2.9 expects you to maintain a complete inventory of endpoints and have visibility into each device’s security posture, patch status, and configuration compliance. ¹

For a Compliance Officer, CCO, or GRC lead, the practical challenge is that endpoint truth is usually fragmented: IT asset tools, EDR consoles, MDM, vulnerability scanners, identity directories, and departmental systems all disagree. Attackers and outages thrive in those seams, and audit findings often start with “unknown device on network,” “unsupported OS not tracked,” or “patch status cannot be evidenced.”

This page translates the requirement into an operating model you can stand up quickly: define endpoint scope, establish authoritative sources, implement discovery and reconciliation, and produce posture reporting that is traceable to tickets and exceptions. You will also see what evidence to retain, the exam questions that commonly create findings, and execution phases you can run without waiting for a full tool replacement. ¹

Regulatory text

HICP Practice 2.9: “Maintain a complete inventory of all endpoints with visibility into their security posture, patch status, and configuration compliance.” ¹

Operator interpretation (what the examiner expects):

• Complete inventory means you can account for endpoints that create risk: corporate-managed devices, remote devices that rarely touch the network, clinical endpoints, and endpoints owned by third parties but connected to your environment. ¹
• Visibility means you can produce evidence, not assumptions, for each endpoint’s:
  • Security posture (for example: endpoint protection/EDR installed and reporting, disk encryption status, basic health) ¹
  • Patch status (OS and key software patch level, and whether the device is missing required updates) ¹
  • Configuration compliance (alignment to your baseline, such as secure configuration standards and required settings) ¹

Plain-English requirement

You must know what endpoints you have, who owns them, where they are, and whether they meet your minimum security requirements. If you cannot prove those four points with current data and a repeatable process, you do not have endpoint inventory and visibility in the sense HICP 2.9 intends. ¹

Who it applies to

Entity types

• Healthcare organizations (providers, payers, integrated delivery networks, clinics, labs). ¹
• Health IT vendors (including organizations hosting, managing, or supporting systems that touch healthcare workflows). ¹

Operational context (typical scope decisions you must make)

• Endpoints include laptops, desktops, mobile devices, virtual desktops, and server-like endpoints in clinics where endpoint agents run. Many organizations also include clinical workstations, imaging review stations, and thin clients when they run general-purpose OSs. Document your definition and exclusions. ¹
• Third-party-connected endpoints matter when a third party connects devices to your network, uses remote access tooling, or manages equipment that has endpoint-like characteristics. Treat “owned by someone else” as a risk factor, not a scope carveout. ¹

What you actually need to do (step-by-step)

1) Define endpoint scope and minimum posture requirements

Create a short standard that answers:

• What counts as an endpoint in your program.
• What “minimum posture” means (required endpoint protection, patching expectations, and baseline configuration controls).
• What is out of scope and why (documented). ¹

Deliverable: Endpoint Security Standard (one to two pages) mapped to “security posture, patch status, configuration compliance.” ¹

2) Establish authoritative data sources and ownership

Pick a primary inventory record (your “system of record”) and define which systems feed it, such as:

• Endpoint management (MDM/UEM)
• EDR/endpoint protection console
• Vulnerability scanner
• Directory/IdP device objects
• Network discovery sources (DHCP, NAC, VPN device lists)

Assign:

• Control owner (accountable for compliance).
• System owners (responsible for each feed’s health).
• Service desk (remediation workflow). ¹

Practical tip: If you cannot pick one system of record quickly, use Daydream to document the interim control design, the authoritative sources, and the reconciliation rules so you can evidence governance while tooling matures.

3) Implement discovery and reconcile duplicates

Your inventory must detect endpoints that exist outside procurement and ticket workflows. Build a reconciliation process that:

• Ingests device identifiers (hostname, serial, MAC, device ID) and normalizes them.
• Deduplicates records and resolves conflicts (example: EDR sees a device that MDM does not).
• Flags “unknown/unmanaged” endpoints for triage. ¹

Deliverable: Reconciliation rules (written) plus a recurring exception queue for unmanaged endpoints.

4) Add posture reporting for the three required dimensions

Build dashboards and exportable reports that show, per endpoint:

• Security posture: agent installed, last check-in time, protection enabled status. ¹
• Patch status: OS version/build, missing critical updates, last patch date, and patch tool reporting status. ¹
• Configuration compliance: baseline compliance score or pass/fail against key settings (local admin controls, encryption, firewall, screen lock, secure boot where applicable). ¹

Make posture visibility actionable: each report should link to a remediation workflow (ticketing, endpoint management actions, or exception approval). ¹

5) Operationalize remediation, exceptions, and compensating controls

Define what happens when endpoints fail posture checks:

• Standard remediation path (auto-remediate where possible, otherwise ticket and track).
• Exception process for business-justified deviations (example: clinical device constraint), with risk acceptance and expiry.
• Compensating controls (network segmentation, restricted access, additional monitoring) when configuration compliance cannot be achieved. ¹

Deliverable: Exception register with approvals and expiry dates, plus evidence of compensating controls where used.

6) Prove completeness continuously

This is where many programs fail: they report posture for the devices they know about, but cannot prove they know about all devices. Add “completeness checks” such as:

• Compare network-visible devices to inventory; investigate deltas.
• Compare EDR-visible devices to MDM-visible devices; investigate deltas.
• Track endpoints that have not checked in recently and treat them as unknown risk until confirmed. ¹

Required evidence and artifacts to retain

Keep evidence that a third party can review without needing your internal context.

Governance and scope

• Endpoint definition and scope statement.
• Endpoint Security Standard (minimum posture requirements). ¹

Inventory and discovery

• Current endpoint inventory export with key fields: owner, business unit, device type, OS, unique ID, last seen, management status.
• Data flow diagram or written description of inventory sources and reconciliation.
• Records of unmanaged/unknown endpoint investigations and outcomes. ¹

Visibility and remediation

• Posture reports/dashboards for security posture, patch status, and configuration compliance.
• Sample remediation tickets mapped to failing endpoints, including closure evidence.
• Exception approvals and compensating control documentation. ¹

Change management

• Evidence inventory updates occur during onboarding/offboarding and device lifecycle events (procurement, deployment, reimage, disposal). ¹

Common exam/audit questions and hangups

Auditors typically probe for control effectiveness and completeness, not tool ownership.

• “Show me your endpoint inventory. How do you know it’s complete?” ¹
• “Which endpoints are missing patches, and what is the remediation workflow?” ¹
• “How do you measure configuration compliance, and what is your baseline?” ¹
• “How do you handle endpoints used by a third party, contractors, or outsourced IT?” ¹
• “Prove your EDR/MDM coverage. What devices are not reporting?” ¹

Hangup to expect: teams present a CMDB or procurement list. That rarely satisfies “visibility into security posture, patch status, and configuration compliance.” ¹

Frequent implementation mistakes and how to avoid them

1. Treating inventory as a static spreadsheet

• Fix: require automated feeds and define what “current” means for last-seen and last-check-in. ¹

2. No path for “unknown endpoints”

• Fix: create an intake queue, triage ownership, and documented outcomes (block, enroll, retire, or accept with controls). ¹

3. Reporting posture only for managed devices

• Fix: completeness checks across multiple sources. Your KPI should include “devices discovered but not managed.” ¹

4. Configuration compliance is undefined

• Fix: publish a baseline and limit it to enforceable settings. “We follow best practices” is not testable evidence. ¹

5. Exception sprawl

• Fix: time-bound exceptions with named approvers, documented compensating controls, and a review cadence. Use Daydream to run a lightweight exception workflow with consistent artifacts across teams.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk-wise, gaps in endpoint inventory and visibility typically drive:

• Unpatched or misconfigured endpoints staying in production longer than intended.
• Undetected security tool coverage failures (agents missing, disabled, or not checking in).
• Inability to scope incidents quickly because you cannot identify affected endpoints. ¹

Practical execution plan (30/60/90)

Time-boxing helps, but the goal is capability, not calendar precision. Use these phases and exit criteria.

First 30 days: establish scope, ownership, and a minimum viable inventory

• Publish endpoint scope and minimum posture requirements mapped to the three HICP dimensions. ¹
• Identify authoritative sources and document reconciliation rules.
• Produce a first inventory export and a list of unknown/unmanaged endpoints for triage.
• Stand up baseline reporting for one posture dimension first (often security agent presence), and link it to ticketing.

Exit criteria: you can show an inventory, explain how it is built, and show an exception queue. ¹

Next 60 days: expand feeds and make posture reporting audit-ready

• Add patch status and configuration compliance reporting and define pass/fail logic.
• Implement completeness checks between sources (EDR vs MDM vs network signals).
• Formalize exception approvals and compensating control templates.

Exit criteria: you can produce endpoint-level posture evidence and show remediation records. ¹

Next 90 days: operational hardening and continuous oversight

• Integrate inventory controls into onboarding/offboarding and procurement.
• Tune dashboards and automate escalations for non-reporting devices.
• Run a management review that samples endpoints and validates inventory accuracy end-to-end.

Exit criteria: you can withstand sampling and prove sustained operation, not a one-time cleanup. ¹

Frequently Asked Questions

What counts as an “endpoint” for HICP 2.9?

HICP 2.9 focuses on endpoints you must protect and manage. Define endpoints explicitly (laptops, desktops, mobile devices, and other OS-based devices where you can measure posture) and document exclusions with rationale. ¹

Do we need “real-time” visibility?

HICP’s summary calls for real-time visibility into posture, patching, and configuration compliance. In practice, auditors look for current, continuously updated reporting and a defined standard for when a device becomes “stale” or “not reporting.” ¹

If we have a CMDB, is that sufficient?

A CMDB can help, but HICP 2.9 also requires visibility into security posture, patch status, and configuration compliance. If your CMDB cannot show those fields with evidence-backed sources, you still need posture tooling and reconciliation. ¹

How do we handle endpoints owned by a third party (contractors, partners, managed service providers)?

Treat third-party endpoints as in-scope when they connect to your network, access sensitive systems, or are managed on your behalf. Require enrollment into your management stack or enforce compensating controls plus documented exceptions. ¹

What evidence is strongest for configuration compliance?

A defined baseline plus machine-generated compliance reporting tied to device identity is strongest. Pair the report with remediation tickets and exception records so you can prove governance and follow-through. ¹

We have multiple tools reporting different device counts. What will auditors focus on?

They will focus on whether you can explain the differences and show a reconciliation process that finds unmanaged endpoints and drives closure. Document your authoritative sources and keep an exception queue with outcomes. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices