Open source vulnerability management for healthcare: why hospitals need a different scanning model
Hospitals cannot run vulnerability management the way most enterprises do. Clinical systems and medical devices often carry vendor restrictions on patching and on active scanning, yet they hold electronic protected health information (ePHI) that the HIPAA Security Rule requires you to protect. A workable program therefore has three parts: safe scanning profiles that respect device limits, compensating controls for assets that cannot be patched or scanned, and records that show how risk was assessed and handled. Greenbone handles network and host findings, DefectDojo tracks findings to closure, and Wazuh provides host telemetry that can detect exposure on systems that cannot take an active scan. The first decision is scope: list every system that creates, receives, maintains or transmits ePHI, including systems run by business associates.
The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities, meaning health plans, health care clearinghouses and covered health care providers, and to their business associates, for all ePHI they handle. Its technical safeguards in 45 CFR 164.312 require unique user identification, audit controls that record and examine activity in systems holding ePHI, and person or entity authentication. Vulnerability scanning is not named as a standalone requirement in those safeguards, so you need to document how scanning and remediation support your risk analysis and risk management decisions. There is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance, so the evidence you assemble is what an OCR complaint investigation or audit will examine. HHS proposed a major Security Rule revision on 6 January 2025, and as of October 2026 no final rule has been published, so confirm the current text with counsel before you finalize your procedures.
Outside the United States, NIS2 Annex I lists health as a sector of high criticality, covering healthcare providers and manufacturers of medical devices that are critical during a public health emergency. Hospitals operating in EU member states should confirm whether national transposition applies to them. Confirm too whether your medical device vendors fall under the same obligations, because that changes what you can ask them to support. Begin by asking each device vendor in writing which scan types, credentialed checks and network probes they permit, which patches they will validate, and who to contact when a scanner's traffic causes a problem. Those answers set the boundary of your scanning profiles and define which assets rely on compensating controls.
Which HIPAA and sector requirements shape the scanning program
This table maps the HIPAA technical safeguards, business associate terms, NIS2 and GDPR obligations to what each means for scan scope, credentials and evidence in a hospital scanning program. Read each row as a question to answer with your compliance lead, since HIPAA sets outcomes rather than scanner settings and no certification is issued.
| Requirement | What it means for scanning | Evidence to keep |
|---|---|---|
| 45 CFR 164.312(a) access control and unique user identification | Scanner accounts, clinical network credentials and vendor logins must be individually assigned and logged, so shared scan accounts are a finding to fix first | Scan account register, credential custody records, and scan job logs tied to named operators |
| 45 CFR 164.312(b) audit controls | Scanner activity against systems containing ePHI should itself be logged and reviewed, including who ran which scan and when | Scanner audit logs, retention settings and periodic review notes |
| 45 CFR 164.312(d) person or entity authentication | Authenticated scans need verified credentials to hosts and devices, and failed or unverified logins reduce coverage and must be reported | Authentication success rates per asset group and exceptions list for unauthenticated targets |
| 45 CFR 164.308 risk analysis expectation | Scan results feed the enterprise risk analysis, so asset inventory and scan coverage gaps are inputs to the risk analysis rather than standalone reports | Risk analysis entries that cite scan data, asset inventory version and documented risk decisions |
| 45 CFR 164.314(a)(2)(i) business associate terms | Managed scanning, hosting or vendor support that touches ePHI requires contract terms covering Security Rule compliance, subcontractor flow-down and incident reporting | Executed business associate agreements and subcontractor list for any party that can reach scan data |
| NIS2 Annex I health sector scope | Healthcare providers and manufacturers of medical devices critical during public health emergencies are listed as high criticality, so EU organizations should confirm applicability and reporting duties | Written applicability assessment and mapping of scanning records to national transposition requirements |
| GDPR Articles 32 and 34 as cited in the CNIL Hopital Prive de la Loire decision | The CNIL fined the hospital EUR 500,000 on 3 September 2026 for external access without VPN or MFA and access control that ignored care team need-to-know, so scan and remediation access should be scoped to need-to-know | Access review records for scan consoles, MFA evidence for remote scanner access and breach assessment procedure |
| Regulatory status of HIPAA Security Rule revision | HHS proposed a revision on 6 January 2025 and no final rule had been published as of October 2026, so confirm current requirements with counsel before fixing scan frequencies | Dated record of the rule version applied and periodic regulatory watch notes |
What makes clinical systems and medical devices different to scan
Clinical environments cannot be scanned the way an office network can. A hospital estate holds the electronic health record, PACS and imaging modalities, laboratory and pharmacy information systems, infusion pumps, patient monitors and vendor-managed appliances that run a clinical service on a fixed software build. Many of these systems are classed as medical devices or depend on one, so the manufacturer, not the hospital, controls what can be installed, patched or probed. Before any scanner is pointed at them, the scanning team needs an asset inventory that separates clinical systems from general IT, records the manufacturer and service contract for each device, and flags which assets are life-supporting or care-critical. Scanner placement and scheduling decisions follow from that inventory, not from the network map alone.
Vendor warranties and clinical validation are the main limits on patching and on active probing. Installing a vendor update, or changing the operating system, can invalidate a device's regulatory clearance or its warranty, and any change may need re-validation by clinical engineering before it returns to service. Active scans send crafted traffic and can crash fragile embedded stacks, lock accounts through repeated logins, or stall a device mid-procedure. For that reason, the first question to put to each manufacturer is whether they permit network scanning at all, which protocols and ports may be touched, whether authenticated scans are allowed, and what they will support if a device misbehaves. Get those answers in writing and keep them with the asset record. Do not assume that a scan which is safe on a workstation is safe on an infusion pump.
Scanning profiles for these assets are therefore conceptual choices, not defaults. A passive profile observes traffic and identifies assets and software from what they already send, which carries little risk to a device but finds less. An unauthenticated active profile probes exposed services and can confirm versions from banners, which is more intrusive. An authenticated profile logs in with credentials and reads installed software directly, giving the most accurate results but requiring stored credentials, a vendor agreement and careful account handling. Clinical engineering, the device manufacturer and the information security team should agree on which profile applies to each device class before the first scan runs, and the resulting permissions should be written into the scan policy and the vendor contract so that an auditor can trace each scan back to an approval.
Which open-source platforms fit a hospital vulnerability program
A hospital program usually combines a network scanner, a container and dependency view, a central tracker and host telemetry, each with a different safety profile around clinical systems. The cards below set out what each component does, where it fits and what to check before it touches a device or clinical network.
Greenbone Community Edition for scanning
Greenbone Community Edition runs the OpenVAS scanner (GPL-2.0 openvas-scanner) and the gvmd manager (AGPL-3.0), and the Notus Scanner compares installed software against known vulnerable versions during each scan. The Community Feed excludes vulnerability tests for enterprise products, so confirm which device and clinical software families your feed covers before you rely on it for coverage claims. Schedule scans outside clinical hours, exclude medical device segments by default and validate scan profiles in a test network first.
Trivy for clinical application images
Trivy scans container images, file systems and dependency manifests in build pipelines, which suits the clinical applications, integration engines and internal tools your teams build and deploy. It does not reach embedded firmware on medical devices, and it reports on what it can see in an image, so teams should confirm base image update paths with the application vendor. Scan results should be gated in CI for internally built software only.
Dependency-Track for vendor SBOMs
Dependency-Track ingests software bill of materials files and tracks components against newly published vulnerabilities over time. For hospitals, its main value is holding vendor-supplied SBOMs for clinical software and devices that you cannot scan directly. The limit is data quality: many vendors provide incomplete or outdated SBOMs, so ask vendors for SBOM format, update cadence and their vulnerability response contacts in the procurement contract.
DefectDojo for tracking and SLAs
The open-source edition of DefectDojo (BSD-3-Clause) imports Greenbone, Tenable, Qualys and Nexpose reports, deduplicates findings and tracks remediation across teams. Its open-source edition uses local accounts, while SSO with SAML or OIDC, LDAP and MFA are DefectDojo Pro features. For a hospital with clinical staff access to the tracker, plan how local accounts, password policy and audit logging meet your HIPAA access control and audit requirements before go-live.
Wazuh for host inventory and telemetry
Wazuh (GPL-2.0) provides agent-based host inventory, software visibility and security telemetry for servers, workstations and some clinical endpoints where an agent is supported by the operating system and the vendor permits it. Many medical devices cannot run agents, so Wazuh covers the hosts around them: clinical servers, interface engines and administrative endpoints. Confirm agent support for each operating system before you promise inventory coverage to a clinical department.
Security Onion for network visibility
Security Onion bundles Suricata and Zeek for passive network monitoring, which can show which devices talk to which systems without sending active probes to fragile equipment. It is licensed under the Elastic License 2.0, so review its terms with counsel before hosting it as a shared service. Sensor placement needs clinical network engineering input, and passive monitoring does not replace an accurate asset inventory or a vulnerability scan.
Safe scanning profiles by device and system type
General IT servers such as file, directory, print and internal web servers usually tolerate the deepest scanning in a hospital. They are typically owned by the IT team, run standard operating systems and can be patched on a known schedule, so authenticated checks give the most accurate results. Greenbone Community Edition, with its Notus Scanner comparing installed software against known vulnerable versions, is well suited to this group once credentials are in place.
- Passive discovery first: Map address ranges and open services from network records and switch or firewall data before any active probe runs.
- Credentialed host checks: Use a dedicated, least-privilege scan account per platform so installed software and missing patches are read directly rather than inferred from banners.
- Maintenance window runs: Schedule full port and vulnerability tests outside clinical peak hours, with rate limits set in the scan configuration.
- Exclusions: Exclude any server that hosts a clinical interface engine, a database for a clinical system or a device gateway until its owner has approved the profile.
- Change control: Record each scan configuration version so auditors can see which checks ran on which dates.
Before the first production run, have the server owner and the security team review the Greenbone scan configuration, the target list and the schedule together.
Clinical application servers host the electronic health record, order entry, medication administration and laboratory interfaces. Outages here affect patient care directly, and vendors often restrict what may run on the platform or require a vendor sign-off before changes. Scanning these systems should start with passive and credentialed methods, and active network tests should only run with the application owner present and a rollback plan agreed.
- Vendor support boundaries: Check the application vendor's written position on scanning and credentialed access before any test is scheduled.
- Credentialed checks only where agents are supported: Read installed packages and configuration rather than sending exploit-style probes to the application port.
- Limited network checks: Run a reduced test set against known service ports during a maintenance window, with the application team monitoring.
- Dependency exclusions: Exclude database listeners and interface engines from aggressive tests unless the vendor has confirmed the test set is safe.
- Staging first: Where a test copy of the application exists, validate the scan profile there before it touches production.
Confirm with the application owner and clinical informatics lead that the scan window avoids scheduled downtime and that someone can stop the scan quickly.
Medical and biomedical devices, such as infusion pumps, imaging modalities, patient monitors and laboratory analyzers, often run embedded operating systems that cannot be patched or logged into in the usual way. Many are regulated products whose manufacturers restrict changes, and an unexpected probe can cause a device to fail or reset. For this group, the default position should be no active scanning at all, with risk managed through passive monitoring, inventory and compensating controls.
- Passive discovery only: Identify devices from network flow data, DHCP and switch records, and asset inventories maintained by clinical engineering.
- No credentialed host checks: Most embedded systems do not accept scan credentials, and attempting logins can lock accounts or trigger device faults.
- Exceptions by written approval: Any active check requires sign-off from clinical engineering and the device owner, a documented test set and a manufacturer position where one exists.
- Automatic exclusions: Exclude devices in life-sustaining or time-critical use, devices with known fragility, and anything the manufacturer has not cleared for scanning.
- Segmented networks: Scanning from a segment that can reach these devices should be restricted to the approved target list only.
No active Greenbone run should reach a device until clinical engineering and the device owner have approved the exact profile, targets and schedule in writing.
Vendor-managed appliances include firewalls, imaging archives, remote support gateways and building or nurse call systems that a third party maintains. The hospital often cannot install agents, read configuration files or change the operating system, and the vendor may control when updates are released. The aim here is to know what the appliance is, what version it runs and whether the vendor has published a fix, then to coordinate testing through the vendor contract.
- Inventory and version capture: Record model, firmware and support status from the device label, management interface or vendor portal, then compare against published advisories.
- Vendor-run assessments: Ask the vendor whether it runs its own scans or accepts a scan from the hospital, and under what test set.
- Limited external checks: Where an appliance has an internet-facing management interface, test only the agreed ports during a window the vendor has accepted.
- Exclusions: Exclude appliances whose vendor has not approved scanning in writing, and any unit where a scan could interrupt remote support or emergency access.
- Contract terms: Confirm the vendor's obligations for notifying vulnerabilities and delivering patches, using the same contract channels as other business associates.
Confirm with procurement and the vendor manager that the vendor has accepted the scan profile in writing and knows who to call if the appliance degrades during a run.
Compensating controls for devices that cannot be patched
Medical devices and legacy clinical systems often cannot be patched on the normal schedule, so the scanner finding stays open. The controls below reduce exposure while the vendor works on a fix, and each one should be recorded as a documented risk decision rather than treated as a replacement for vendor-approved patching.
Network segmentation and allow-listing
Place unpatchable devices in dedicated VLANs or zones and permit only the ports and destinations the vendor documents as required for clinical function. Deny everything else at the segment boundary. Check that biomedical engineering and the device vendor agree on the allow-list, since an incorrect rule can interrupt patient care. Confirm that the segment map is current and that Greenbone scan results for these hosts are tagged so reviewers can see the segment they belong to.
Passive monitoring with Suricata or Zeek
Where the hospital has approved sensors, mirror or tap traffic to and from device segments and run Suricata or Zeek to record protocols, unusual connections and known exploit signatures without sending probes to the devices. Passive monitoring fits fragile equipment because it adds no load to the device. Confirm with the vendor and clinical engineering which sensor placements are permitted before deployment, and confirm that the sensor itself is inventoried and patched.
Change-controlled access through jump hosts
Route vendor and clinical engineer access to device segments through a hardened jump host that requires named accounts, approved change tickets and time-limited sessions. Vendors often connect remotely for service, and this is the path the CNIL case in Europe examined, where external access lacked VPN and multi-factor authentication. Confirm that vendor accounts are disabled when a service visit ends and that each session is linked to a ticket.
Logging of administrative access
Record logins, privilege use, configuration changes and file transfers on the jump host and on any management interface the device exposes. Forward these logs to a central store that the security team can search, and set retention with the records retention rules your compliance team has confirmed. HIPAA audit controls require activity in systems with ePHI to be recorded and examined, so confirm who reviews these logs and how often.
Vendor letters tracked as risk acceptances
Ask each device vendor for a written compensating-control letter that names the vulnerability, the controls the vendor supports, and the vendor's remediation plan. Record each open finding in DefectDojo as a risk acceptance with an owner, a justification and a review date. The review date forces periodic reassessment, so an expired acceptance reopens the finding automatically in the workflow your team configures.
Monitoring for exploitation signals
Track known exploited vulnerability listings, vendor security bulletins and threat intelligence relevant to each device family, and check whether any listed issue applies to your deployed models and firmware versions. When a signal matches, move the affected devices into stricter allow-listing or isolation and re-rank the risk acceptance. Confirm with the vendor which advisories cover your exact model and version, because generic advisories often do not.
Rollout: from asset inventory to a scan program clinicians can accept
The sequence moves from a device inventory agreed with clinical engineering to a scheduled scan program with change windows, deduplicated findings in DefectDojo and a risk analysis that reflects what was actually found. Each phase closes with a written output that the hospital can review and sign off.
Build the asset and device inventory with clinical engineering
Clinical engineering, biomedical engineering and IT operations build one inventory that lists clinical devices, medical imaging systems, clinical applications, servers and network segments, with an owner, location, vendor and network zone for each item. The inventory marks which devices run vendor-supported software, which cannot be patched by the hospital and which cannot tolerate active probing. The output is a signed inventory that defines what the scan program is allowed to touch, and it becomes the baseline for every later phase.
Review vendor scanning permissions in writing
For each device vendor and clinical application vendor, the team asks in writing whether active scanning is permitted, which scan types the vendor accepts, whether passive or authenticated checks are allowed and who handles the warranty impact. Some vendors will only accept passive discovery or a vendor-run assessment, and those answers decide the scanner profile for each segment. The output is a vendor permission register that lists every device class, the permitted method and the contact who approved it.
Build the scanner and load feed data
The platform team deploys the Greenbone Community Containers with the Docker Compose file on a host in the management network, sized to at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended by the Greenbone documentation. The data containers load vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories into volumes at startup, and the team confirms that every data container completed before the first scan. The output is a running scanner with loaded feeds, a documented feed update procedure and a test scan against a lab target.
Pilot on non-clinical network segments
The first scans run only on administrative workstations, print servers, test servers and other non-clinical segments, using the scan profiles the team settled on during the vendor review. The team compares results against the inventory, records scan duration and any service disruption and tunes the scan configuration to reduce false positives and avoid heavy checks. The output is a pilot report that shows which profiles were safe, which assets were missing from the inventory and which settings must not be used on clinical networks.
Expand in staged rollouts with change windows
The program moves into clinical segments one zone at a time, starting with systems that have vendor approval and an agreed maintenance window. Clinical operations, the clinical engineering lead and the security team approve each window in writing, and a rollback contact stays on call while the scan runs. Each zone is scanned on a schedule that matches its change control rules, and any device that shows an adverse effect is removed from active scanning and moved to passive monitoring. The output is a zone-by-zone rollout log with approved windows, outcomes and any devices excluded from scanning.
Import findings into DefectDojo and configure deduplication
The team sets up DefectDojo, imports Greenbone reports through the OpenVAS parser in CSV or XML format and maps each scan to a product that matches the inventory zones. Deduplication is checked against the parser's hashcode fields, and the team confirms that repeat findings from successive scans merge instead of duplicating. Remediation owners and the ownership of each device are attached to every product so that tickets can be traced to a responsible team. The output is a populated DefectDojo instance with verified deduplication and a list of findings grouped by owner.
Update the HIPAA risk analysis with scan results
The privacy and security officer and the clinical engineering lead update the enterprise risk analysis required by the HIPAA Security Rule, adding the device classes, the compensating controls for unpatchable systems and the scan limits agreed with vendors. The update records which findings are accepted, which are mitigated by segmentation or monitoring and which require a plan with an owner. The output is a revised risk analysis that links each device class to its scan method, its compensating controls and its remediation status.
Deliver the first management report
The security team produces the first management report from DefectDojo, covering scan coverage against the inventory, open findings by zone and owner, exceptions with their approvals and the status of each vendor permission. The report is reviewed with clinical leadership, IT leadership and the compliance lead, who confirm whether the scope and cadence are acceptable for clinical operations. The output is an approved first report and a recorded decision on the next scan cadence for each zone.
Evidence the HIPAA risk analysis and regulators will ask for
This table maps each evidence item a risk analysis or regulator may request to the component that produces it in a self-hosted vulnerability program. Use it to decide which records to keep, where they live and who owns them. It is preparation material for your own review, not an audit or certification, since HIPAA has no certification and HHS enforces the rule through complaints, compliance reviews and audits.
| Evidence item | Produced by | What to confirm or keep |
|---|---|---|
| Asset inventory of ePHI-adjacent systems and medical devices | Greenbone host discovery and target lists, Wazuh agent inventory where agents can be installed | Reconcile scan targets against the clinical asset register; record devices that cannot be scanned and why |
| Scan configurations and approvals | gvmd scan configs, targets and schedules, exported through the Greenbone Management Protocol | Signed approval from clinical engineering and the system owner for each safe scanning profile |
| Scan logs and schedules | gvmd task run history and PostgreSQL-backed results, plus container logs from the Greenbone Community Containers | Retain run history covering the review period; confirm retention with your records policy |
| Finding records with deduplication and status | DefectDojo findings, deduplication hashcodes and status history after importing Greenbone reports | Show open, accepted and closed states with the date and the person who changed each one |
| Exceptions and compensating-control records with review dates | DefectDojo risk acceptance entries and linked findings, supported by a controlled register maintained by the security team | Each unpatchable device needs a compensating control, an owner and a next review date |
| Vendor correspondence on patching and scan safety | Ticketing or document store linked to DefectDojo findings; business associate contract terms under 45 CFR 164.314 | Written vendor position on scanning, patch timelines and incident reporting for each device class |
| Remediation timelines by severity | DefectDojo finding dates, SLA fields configured by your team, and reports exported for management | Document the timelines your organization sets and show actual closure dates against them |
| Risk analysis updates | Periodic exports of vulnerability trends and open exceptions, reviewed and signed by the risk owner | Record each review date and what changed in threats, assets or controls as required by the risk analysis process |
How to coordinate vendors and business associate terms
Can a hospital scan a medical device vendor's equipment without permission?
No. Scanning a device, or the vendor-managed system behind it, without written permission from the vendor and the device owner can breach the support agreement and can disrupt a clinical system. Ask the vendor to name the approved scanning method, the permitted scan window, the test profiles that are safe for their product, and who may run them. Many vendors will accept passive discovery, banner review or a scan of the hospital-side network segment, while active testing of the device itself may be excluded. Record the answer in the asset inventory so every later scan has a documented basis.
What patch timelines should a medical device vendor commit to in writing?
Ask for a written timeline that states how the vendor learns of a vulnerability, how fast it assesses severity, how fast it issues a fix or compensating guidance, and how the hospital receives both. Vendors often separate fixes that require regulatory review from configuration changes that the hospital can apply, and the contract should say which is which. Ask whether the vendor publishes advisories, how it handles vulnerabilities in third-party components such as operating systems and libraries, and what it does when a fix is not yet available. Confirm the commitments against the vendor's support lifecycle, because an end-of-support date may matter more than any patch promise.
What must a business associate contract say under 164.314(a)(2)(i)?
Under 45 CFR 164.314(a)(2)(i), the business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Read the full section in the eCFR text rather than relying on a summary, then check that the vendor's standard agreement actually contains each element. Scanning and remediation data often contains ePHI or identifies systems that hold it, so the contract should cover where scan results are stored and who can access them.
How should incident reporting timelines appear in a business associate agreement?
The agreement should state a defined window for the business associate to report security incidents to the covered entity, including breaches of unsecured PHI, along with the information the report must contain. The rule requires reporting but the length of the window is a negotiated term, so confirm it with counsel and document the agreed figure. Ask the vendor how it detects incidents in its own environment, who receives the notice, and how it supports the covered entity's risk assessment afterward. Include vulnerability disclosures that involve exploitation of its product, since these can lead to security incidents affecting ePHI.
Do subcontractors and cloud hosting providers need their own business associate terms?
Yes, where they create, receive, maintain or transmit ePHI on the business associate's behalf. The flow-down requirement in 45 CFR 164.314(a)(2)(i) means the same Security Rule obligations must pass to any subcontractor handling ePHI. Ask the vendor to list its subcontractors that touch ePHI, including hosting, support tooling and managed scanning providers, and to confirm that each has a compliant agreement. Also ask where vulnerability data from your environment is processed, since a scanner or ticketing service run by a third party can become a subcontractor in its own right.
What should we do when a vendor refuses to allow scanning?
Treat the refusal as a documented risk, not a silent gap. Ask the vendor for the reason, the alternative evidence it can provide, such as a current software bill of materials, a security questionnaire, a recent third-party assessment report or a vendor-run scan with results shared under contract. Next, isolate the device on a segmented network, restrict its inbound and outbound paths, and add monitoring that watches the segment with passive tools. Record the exception with an owner, a review date and a compensating control list, and escalate it through the risk committee. Do not run scans the contract prohibits, even if the goal is patching.
Who pays for vendor coordination work and what recurs after signing?
Coordination costs fall into three groups: the hospital's legal and procurement time to negotiate scan permissions and business associate terms, the security team's time to collect vendor advisories and track device fixes, and any vendor fees the contract attaches to security support or scanning cooperation. Most of the cost is one-time at contracting, but advisory tracking, annual reviews and renewals recur. Ask any implementation partner for a quote that separates contract review, device inventory with vendor mapping, and ongoing coordination, and confirm which items the partner performs and which remain with the hospital's counsel and clinical engineering teams. Confirm the scope in writing before work starts, since engagements are typically fixed-scope.
Can DeployOpen negotiate business associate agreements for our hospital?
DeployOpen does not provide legal advice or sign agreements on a client's behalf, so the business associate contract should be drafted or reviewed by the hospital's counsel. DeployOpen can prepare the technical inputs that the contract depends on, such as a device and vendor inventory, a list of systems that hold ePHI, scan-permission requirements per vendor and a record of compensating controls. Those records help counsel write precise terms and help the security team check that vendors meet them. Confirm the division of responsibilities in the written scope before the engagement begins.
Questions to ask an implementation partner before a hospital pilot
Start with the question that decides whether the pilot can run at all: what has the partner scanned on clinical networks, and how did they keep those scans from disrupting care? Ask for a concrete account of a past engagement in a live clinical or medical device environment, including which hosts they excluded, how they sequenced discovery and how they handled a device that stopped responding. Ask who on their team would run the pilot and whether that person has worked with biomedical engineering and clinical operations, not only with IT. Ask how they would confirm scan safety in writing before the first run, and who in the hospital signs off on that plan.
Next, ask how scan profiles are written for each device class. A partner should be able to explain how a profile for workstations differs from one for imaging servers, infusion pump gateways or legacy monitoring hosts, and why some devices get passive discovery only. Ask how they set scan intensity, timing and credentials, and whether they can show the Greenbone scan configuration or Notus and OpenVAS settings they would start from, plus how they would record which tests were disabled for a device class and why. Ask also how feed updates reach segmented networks: whether they use a controlled transfer of Greenbone feed data into the enclave, how often they expect to do it, and what evidence they keep that the feed version used for each scan was current.
Finally, ask how findings are tracked and justified. For DefectDojo, ask whether the community edition with local accounts is enough for the pilot, or whether SSO, LDAP and MFA, which the README lists as Pro features, are required by your identity policy, and what the cost and support model is for Pro. Ask how risk acceptances are recorded: who approves them, how long they run, how compensating controls for unpatchable devices are linked to them, and whether the partner will prepare that record for the HIPAA risk analysis. Last, ask how they coordinate with device vendors when a patch or scan rule is not available, and who writes to the vendor and how responses are logged.
How much does a healthcare vulnerability program cost and how long does it take?
What drives the cost of a healthcare vulnerability management program?
The main drivers are the number and type of assets in scope, how they are segmented, how many systems the scanner must integrate with, the staff time needed for triage and remediation coordination, and how much reporting the hospital needs. Medical devices and clinical systems usually need separate scanning profiles and more coordination with vendors, so they add effort even when the scanner itself is free. Ask any provider to price each of these drivers separately in a written quote, so you can see which assumptions change the total.
What is one-time and what recurs in a self-hosted healthcare scanning program?
One-time work usually includes discovery of the asset inventory, designing scan profiles and segmentation rules, building and hardening the scanner and tracking platform, integrating them, and agreeing the process with clinical engineering. Recurring costs include infrastructure to run the scanners, feed and data updates, staff time for triage and remediation follow-up, periodic rescans, report preparation and any support retainer. Ask the provider to split the quote into these two groups so you can budget for the ongoing portion.
Can a hospital run open-source vulnerability scanning in-house?
Many hospitals can run the core scanning themselves, provided they have people who understand both security tooling and clinical device constraints. The Greenbone Community Containers are orchestrated with a Docker Compose file, so a platform team can deploy them on existing infrastructure. The harder parts are safe scan timing, clinical sign-off, device vendor coordination and documenting risk decisions, which often need staff from clinical engineering and biomedical teams. A partner can take on the build and the documentation while your staff keep ownership of the decisions.
How long does it take to produce the first vulnerability report?
The timing depends on the size of the estate, how complete the asset inventory is, how many network segments need separate approvals, and whether scanning profiles for clinical systems are agreed before the first run. Installing the scanner is usually the shortest step. The longer steps are inventory, scope approval and a pilot on low-risk segments. No duration is fixed in this page, so ask each provider for a timeline tied to a written scope and milestones.
What hardware does the scanning platform need?
The Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, according to Greenbone's Community documentation. Greenbone recommends 4 cores, 8 GB of RAM and 60 GB of storage. Those figures cover the scanner only. Trivy, DefectDojo, the database, backups and any sensor hosts add to that, so confirm sizing for the full stack with the provider and your infrastructure team before procurement.
What does the work need from clinical engineering and security staff?
Clinical engineering needs to provide asset details for medical devices, confirm which devices can tolerate active or authenticated scanning, and help schedule windows that avoid clinical use. Security staff need to own scan policy, network placement, triage, risk acceptance and reporting to leadership. Both teams should agree on who approves exceptions for devices that cannot be patched. Ask providers to list these responsibilities in the scope so the hospital can plan staff time before work starts.
What is the cost of getting it wrong under HIPAA?
HIPAA civil money penalties are assessed per violation, and the inflation-adjusted range for penalties assessed on or after 28 January 2026 runs from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294, according to 45 CFR 102.3. The penalty range is one reason to document risk analysis and risk management decisions for unpatchable devices. Penalty exposure is separate from the program cost, so ask any provider to explain how their scope supports your documented risk analysis.
How DeployOpen scopes and supports this program for hospitals
DeployOpen agrees the scope of a hospital vulnerability management program in writing before any work starts. The written scope should name the networks and asset groups in each scan zone, which clinical and biomedical segments are excluded or limited to passive discovery, the scanning profiles allowed in each zone, who approves each scan window, and the remediation and exception workflow that engineering and biomedical teams will follow. Deliverables and timelines follow from that document, so a hospital CISO or IT director can compare proposals on the same basis. Ask any partner to show a written scope for a comparable clinical environment before signing, and to name what is excluded from the first phase.
DeployOpen plans, deploys, customizes, hardens, backs up, upgrades and documents the self-hosted open-source components inside the hospital's own infrastructure, whether that is its data center, private cloud or an isolated network. Scan data, reports and any ePHI-adjacent asset records stay under hospital control, which matters for the HIPAA risk analysis and for vendor access. DeployOpen also prepares the systems, controls and evidence that a hospital's assessors or auditors will examine, such as scan schedules, exception records and remediation timelines. It does not issue audit reports, attestations or certifications, and the hospital should keep that distinction clear in its planning with the auditor, legal counsel and the HHS Office for Civil Rights framework.
DeployOpen runs security testing against the platforms it deploys, including the scanning and tracking stack itself, so that the tools that hold asset and vulnerability data are assessed like any other sensitive system. Ongoing support, upgrades, feed maintenance and continuous testing are available as retainers, which suits hospitals that need a steady cadence of feed updates and periodic reviews after the initial rollout. Before signing, ask which retainer activities are included, how emergency changes during a clinical incident are handled, and what the hospital must provide, such as access windows, biomedical sign-off and named owners for each scan zone.
