Network scanning finds vulnerabilities on the systems that handle ePHI — missing patches, weak TLS, exposed services — so you can fix them before an attacker (or an auditor) finds them. It supports the HIPAA Security Rule requirement to run periodic technical evaluations (§164.308(a)(8)) and to identify and address technical vulnerabilities.
Availability. Network scanning is an opt-in module. An org admin turns it
on under Settings → Organization → Features. It's off by default.
A scan is only as good as its target list. Aim for the internet-facing systems that create, receive, store, or transmit ePHI, plus the infrastructure that protects them. Good candidates:
What to leave out — the platform will refuse these automatically, but scope them out to begin with:
Tip: record each in-scope system's address on its ePHI system (Settings → Organization → ePHI Systems, "Scan target" field) or on an asset. The scan page can then pull your whole target list in one click, and your scan scope stays tied to your declared inventory.
On Network Scan → Request Scan:
While a scan is running you can Check now (poll immediately instead of waiting) or Cancel it. The "last checked" time shows it's alive.
Concurrency. Each organization can have a limited number of scans in
flight at once (default 3). If you're at the limit, wait for one to finish or
cancel it.
A completed scan records critical / high / medium counts, stores the full report as evidence on the linked assessment, and drafts findings for each critical and high vulnerability. Drafted findings are suggestions — review each, then remediate, mark it a false positive, or accept the risk. Open scan findings feed your compliance score once you've run at least one scan. Scan results — summary counts, timestamps, and outcomes — also appear in the auditor portal (when the auditor link is granted the Network Scans scope) and in the auditor packet export (network-scans.csv).
After you fix something, Resubmit for retest. This re-scans the same targets as a new attempt in the same chain and shows a diff vs. the previous scan — what's fixed, still open, and newly introduced. Record an outcome on each completed scan (remediated / regressed / accepted). The full chain — initial → retests → final — is preserved as an audit trail of a vulnerability found, fixed, and confirmed.
A vulnerability you've already marked a false positive or accepted risk is not re-drafted on later retests, so retesting doesn't recreate noise you already triaged.
Under Recurring Scans, schedule automatic scans daily, weekly, or monthly. Daily is the tightest cadence. Each run starts at a spread-out time inside the 4-hour window you choose (e.g. 02:00–06:00), interpreted in the timezone you pick for the schedule (defaults to UTC), and collects your current targets fresh at run time. Pause or delete a schedule anytime. A schedule waits rather than exceeding your concurrency limit.
Everything above is available over the REST API for automation and to pull results into your own tooling — see the API help page and openapi.yaml:
GET /api/v1/scans — list scans (or ?id= for one scan + its retest chain).POST /api/v1/scans — request a scan (targets[], or from_systems:true to collect from your inventory). DELETE /api/v1/scans?id= cancels one.GET /api/v1/scan-report?id= — download a completed scan's report file.GET/POST/PATCH/DELETE /api/v1/scan-schedules — manage recurring schedules.These need an API key with the scans:read (read/pull) or scans:write (request/manage) scope, created under Settings → API.