Secure Configuration Baselines for Hospital Systems
A baseline nobody measures against is a document, not a control. Choosing a benchmark, handling the clinical exceptions honestly, and detecting the drift that puts you back where you started.
GuardsArm Team
Security Experts
Most hospitals have a hardening standard. Far fewer can tell you how many machines currently comply with it. That gap is the whole subject: a baseline is only a control if something measures against it and something reports the difference.
Pick a published benchmark, do not invent one
Writing your own standard from scratch means maintaining it forever and defending every clause in an audit. Start from something published and attributable:
| Source | Best for | Note |
|---|---|---|
| CIS Benchmarks | Windows, Linux, cloud, databases | Level 1 / Level 2 split maps well onto clinical risk tolerance |
| DISA STIGs | High-assurance environments | More prescriptive, heavier operational burden |
| Vendor hardening guides | Clinical applications and appliances | Often the only option, and required for support |
| Cloud provider benchmarks | AWS, Azure, GCP baselines | Pair with the provider's own posture tooling |
For most hospital estates, CIS Level 1 is the right starting target. It is designed not to break things. Level 2 is where clinical exceptions start to multiply, so treat it as a goal for servers rather than a day-one requirement for clinical workstations.
The exception process is the real design work
Every hospital will have legitimate deviations: an application that needs SMBv1, a device requiring a local administrator account, an imaging workstation whose vendor forbids a particular patch level. Pretending otherwise produces a baseline everyone quietly ignores.
An exception should carry:
- The specific control being deviated from
- The clinical or vendor justification, named
- A compensating control — tighter segmentation, extra logging, restricted access
- An owner who is accountable, ideally on the clinical side
- A review date, not "permanent"
Golden images, and why they decay
Building a hardened image is the easy half. The hard half is that the image is correct only on the day it is built.
The drift sources that matter in hospitals:
- Vendor support sessions that disable a control to troubleshoot and never re-enable it
- Emergency changes made at 2am with no follow-up ticket
- Local administrator use by biomedical or application teams
- Group Policy conflicts where a newer policy silently overrides a hardening setting
- Machines that have been offline for months and miss policy updates entirely
Measuring compliance
The number that matters is not "we have a baseline" but "what percentage of in-scope systems match it, by system class, this week".
Cloud workloads usually score best for a structural reason worth copying: they are rebuilt from a definition rather than patched in place, so drift is short-lived. Where you can move clinical infrastructure toward rebuild-over- repair, baseline compliance largely takes care of itself.
A pragmatic sequence
Measuring before changing matters. It gives you the number that justifies the work, and it prevents the common failure of hardening aggressively, breaking a clinical system, and losing the mandate entirely.
GuardsArm runs configuration baseline assessments against CIS benchmarks in clinical environments, including the exception framework that keeps them alive. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “Secure Configuration Baselines for Hospital Systems”
Talk to the GuardsArm team about how these services apply to your environment.


