Back to Blog
Network Security
8 min read

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

December 31, 2025

Secure configuration baselines

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.

Default-permissive
Operating systems and appliances ship configured for compatibility, not security
Drift is constant
Emergency changes, vendor installs and support sessions all move systems off baseline
Audit evidence
A measured baseline is the cleanest evidence of the HIPAA Security Rule risk management process
45 CFR 164.308(a)(1)

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:

SourceBest forNote
CIS BenchmarksWindows, Linux, cloud, databasesLevel 1 / Level 2 split maps well onto clinical risk tolerance
DISA STIGsHigh-assurance environmentsMore prescriptive, heavier operational burden
Vendor hardening guidesClinical applications and appliancesOften the only option, and required for support
Cloud provider benchmarksAWS, Azure, GCP baselinesPair 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"
Permanent exceptions are how baselines die
An exception with no review date becomes invisible. Within two years nobody remembers why SMBv1 is enabled on that subnet and nobody is willing to turn it off. Give every exception an expiry, even if it is renewed each time.

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.

Configuration lifecycleA hardened image is deployed, drifts through ordinary operational change, and is brought back by detection and remediation rather than by rebuilding.Buildhardened imageDeploymachine enrolledDriftchanges accumulateDetectcompare to baselineRemediateor raise exception
Without the detect step the cycle is open-ended and compliance decays silently.

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".

Baseline compliance by system classIllustrative compliance rates showing where remediation effort should go first.Clinical workstations62%Largest population, most driftServers88%Tighter change controlImaging workstations41%Vendor-constrained, most exceptionsCloud workloads94%Rebuilt from code, drift is short-lived
Illustrative. Reporting by class rather than one global figure is what makes it actionable.

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

Baseline programme sequenceBaseline programme sequence1Choose and documentWeeks 1-3Adopt CIS Level 1 for Windows and Linux. Write down what you are targeting.2Measure before changingWeeks 3-6Scan against the benchmark. Expect an uncomfortable number. Change nothing yet.3Harden the newWeeks 6-10Apply the baseline to the build image so every new machine is compliant.4Remediate by classMonths 3-6Servers first, then workstations. Imaging last, with vendor engagement.5Report drift continuouslyOngoingWeekly compliance by class, with exceptions tracked and expiring.

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.