The Healthcare IT Security Audit Checklist for Imaging and Interface Systems

Most healthcare security audits produce a long document, a spreadsheet of findings, and very little change. The failure is usually not in the testing — it is in scoping that was too broad, evidence that was too weak to defend, and findings that were never converted into owned, dated work.

This is the checklist we work through for imaging and interface environments, along with the parts that make the output usable.

Scope It Before You Start

An audit that covers everything at low depth tells you nothing you can act on. Define, in writing, before starting:

Systems in scope — name them: PACS, VNA, RIS, LIS, interface engine, modality fleet, viewer infrastructure
Network boundaries in scope — which segments, which external connections
Test types permitted — passive review, configuration inspection, authenticated review, active scanning. Active scanning against clinical devices needs explicit sign-off and a clinical window.
What is explicitly out of scope, and why
Escalation path if something urgent is found mid-audit — agree this in advance, because it will be needed on an audit at least once

The active-scanning boundary matters. Some medical devices behave badly under scanning. Agree the approach with biomedical engineering and clinical leadership before touching anything in use.

Domain 1: Network and Exposure

Evidence: external scan output with timestamps; firewall rule export; network diagram matching the rule set; the vendor access register.

Domain 2: DICOM and Imaging Configuration

AE title allow-lists configured on every node
Unused DICOM services disabled per node
TLS enabled on external and cross-segment DICOM paths where supported
Certificate inventory with expiry dates and alerting
Default and vendor-shipped credentials changed on all imaging systems and modalities
C-FIND scope restricted — query interfaces do not return the full patient index to any peer
De-identification process defined and tested for research and teaching exports
Test and training systems contain no production PHI, or are protected to the same standard

Evidence: node configuration exports; a TLS status matrix per connection; certificate register; documented de-identification profile and a sample verified output.

The test-system item produces findings more often than any other in this domain. Copies of production data in test environments, protected far more weakly, are a recurring pattern.

Domain 3: Interfaces and Message Flow

Interface engine management console not reachable from general user networks
Interface credentials unique per connection, not shared across feeds
Message content logging reviewed — full-message logs containing PHI must be protected and retained like clinical records
Log retention aligned to policy, and log storage access-controlled
Test messages use non-clinical patient identifiers
Feeds to external organisations use encrypted transport
Interface configuration under version control with change history
Queue and journal storage covered by backup

Evidence: interface inventory with transport and encryption status per feed; a sample of log storage permissions; version control history.

Full-message logging is the item most often missed. Interface engines routinely log complete HL7 messages for troubleshooting, which means the log directory holds identifiable clinical data — frequently with far weaker access controls than the systems the data came from.

Domain 4: Access Control

Role definitions match actual duties, documented and reviewed
Administrative accounts separate from daily-use accounts
No shared accounts on systems recording clinical access
Vendor accounts time-bounded and reconciled against contracts
Leaver process verified against imaging and interface systems specifically
Multi-factor authentication on remote and administrative access
Break-glass access labelled and reviewed after use
Account review performed at a defined interval, with evidence

Evidence: user list export per system, reconciled against HR leaver data for a sample period; MFA configuration; the most recent completed access review.

The leaver test is the fastest way to find a real finding: take last quarter's leavers and check each clinical system for their account. It takes an afternoon and rarely comes back clean.

Domain 5: Logging and Detection

Audit logging enabled on PACS, VNA, RIS, LIS, and interface engine
Logs forwarded off-host to centralised, access-controlled storage
Retention exceeds realistic time-to-detection
Exception rules in place (same-surname, VIP, out-of-hours, volume anomaly)
Alerts route to a monitored destination with a defined response
Clinical workflow monitoring exists, not just host monitoring
A documented case of log review producing an investigation in the last year

Evidence: log samples showing required fields; retention configuration; alert routing configuration; a redacted example of a completed review.

That final item is the honest test of whether logging is a control or an artefact. If no log has ever prompted an investigation, nobody is reading them.

Domain 6: Resilience

RPO and RTO defined per system and signed off by clinical leadership
Backup schedule verified to deliver the stated RPO
At least one immutable or offline copy, outside the production credential domain
Database and image archive backups verified consistent with each other
Restore tested within the last quarter, with timings recorded
Downtime procedures current, distributed, and known to clinical staff
Incident response plan names imaging and interface systems specifically
System configuration exported and version-controlled

Evidence: signed RPO/RTO document; backup job configuration and recent results; the most recent restore test record including timings.

Domain 7: Vendors and Third Parties

Inventory of every third party with access to clinical systems or data
Data processing agreements in place and current
Sub-processors identified
Patch commitments documented per product
End-of-support dates recorded and in the replacement plan
Breach notification obligations defined with timelines
Access reconciled against active contracts

Scoring Findings by Clinical Impact

Technical severity scores alone mislead in healthcare. A medium-severity vulnerability on the interface engine that carries every order in the hospital outranks a high-severity issue on an isolated reporting server.

Score along two axes and combine:

Likelihood — is it exposed externally, internally reachable, or only exploitable with existing privileged access?

Clinical impact — what happens if it is exploited?

Level	Clinical impact
Critical	Care delivery stops, or PHI is disclosed at scale
High	Major workflow disruption, or targeted PHI disclosure
Medium	Degraded workflow with a workaround available
Low	Limited operational impact

The combined rating drives priority. This framing also makes remediation easier to fund, because it speaks in terms leadership already uses.

From Findings to a Plan

An audit report is not an outcome. Convert every finding into a row with:

The finding, stated as a fact with its evidence
The combined severity
A named owner — a person, not a department
A target date
The accepted-risk decision, if it will not be fixed, with the name of the person accepting it

That last column is the one that changes behaviour. Findings that will not be remediated should be explicitly accepted by someone with the authority to accept them, recorded on the risk register with a review date. Findings that quietly disappear reappear in the next audit, unchanged, and by then nobody remembers why.