Clinical work runs on named responsibilities, written protocols and follow-up dates; no ward hands over care on a shrug. Hospital IT deserves the same discipline, and the label it often travels under is SecOps. Because the term was never standardised — the NIST glossary carries no entry for it, and a BMC press release in January 2016 was already lamenting the “SecOps gap” — managers keep asking what it actually commits them to. The answers below follow the reading chosen by the Atlas entry that defines SecOps as a working contract: hardened settings both sides sign, one queue of fixes with owners and due dates attached, exceptions kept on a leash of expiry dates, and numbers the two departments read together. Nothing here concerns a monitoring room’s shift rota or any vendor’s product catalogue.
Why does the SecOps word carry three meanings?
Three uses are documented. Some vendors use the word for security specialists and IT operators working as one function. Microsoft’s Cloud Adoption Framework records that the phrase is “sometimes referred to as a Security Operations Center” — the second sense, the room with the screens. The third belongs to Google, which renamed its Chronicle product to SecOps in April 2024. A procurement officer quoting a product deck and an auditor quoting a framework can therefore talk past each other for an entire meeting. Naming which sense you mean, in writing, costs one line and prevents most of the confusion.
What does the contract version commit us to?
Four things. First, hardening baselines: agreed configuration standards for servers, endpoints and network gear, with departures recorded rather than hidden. Second, a single remediation queue — one register where every finding lands with an owner’s name and a resourced timeframe, with no side lists living in spreadsheets. Third, governed exceptions: accepted deviations carry an expiry and a review date. Fourth, measurements that both departments read from the same source. The practices have lineage even though the label does not: NIST SP 800-70 covers configuration checklists, SP 800-128 deals with configuration management, while SP 800-40 Revision 4 addresses patching.
Is SecOps the same thing as the security operations centre?
No, and the boundary matters for budgeting. Triage, detection engineering and incident response sit with the SOC; the contract described here covers what the operations side owes that room — telemetry, agreed containment authority, a shared change calendar — and what it may expect back. If a proposal promises analysts and playbooks, it is buying SOC capability. If it promises owners, deadlines and baselines, it is buying the contract. Confusing the two is how estates end up paying for round-the-clock monitoring while findings still rot in an unowned spreadsheet.
What sits inside the agreement — and what stays out?
- In: baseline governance with tailoring records, routing findings to named owners, realistic timeframes per owner group, one shared register, change windows for security work, and the joint measurements described below.
- Out: SOC triage and detection engineering, urgency-class schemes, patch rollout mechanics, risk acceptance sign-off, pipeline controls (DevSecOps territory) and baseline application itself (SysOps, EndpointOps, CloudSecOps).
Scope discipline is not bureaucracy. When urgency scoring or patch trucks wander into the agreement, meetings drift toward disputes the contract was never designed to settle, and the disputes that do belong to it — who owns this finding, and by when — go unanswered.
How is a baseline adopted without breaking patient-facing systems?
Slowly, and in a fixed order: select a benchmark — the CIS Benchmarks library runs past a hundred tested standards, offered in two grades: Level 1, and the stricter Level 2 — then tailor it, recording every departure from the standard in the XCCDF tailoring file; test away from production; then run log-only mode — or a pilot ring given its own cooling-off stretch — before enforcement begins, ring by ring. Drift monitoring and a yearly review close the loop afterwards. It is the same logic as introducing a new infusion-pump setting on one unit, watching what happens, then scaling. Microsoft does state that its standard-protection attack-surface-reduction rules usually tolerate Block or Warn straight away, with no test phase — yet most hospital estates will still want the quiet phase for anything touching imaging, pharmacy or medical-device VLANs.
What does the Netlogon episode teach about deadlines?
Microsoft’s handling of CVE-2020-1472 became the reference playbook. The first enforcement step took effect on 11 August 2020, counting vulnerable secure channels instead of cutting them: events 5827 and 5828 recorded denials, the pair 5830 and 5831 recorded channels the allow-list still permitted, and 5829 simply logged what remained. The escape hatch — a group setting that let vulnerable Netlogon secure channel connections continue — stayed open only until 9 February 2021, when enforcement turned irreversible. The success measure was never “the update installed cleanly”; it was an empty allow-list before the vendor’s deadline arrived. An install that completes without errors proves nothing about the estate it was meant to protect.
What does security owe operations in return?
The duties run both ways. CIS Control 8 sets the floor at 8.1 to 8.3 — a logging process that actually exists, audit logs that are managed, storage that holds them — the piece IG1 estates are expected to meet. IG2 raises the bar: 8.4 for clock sync, 8.9 for one central collection point, 8.10 for keeping logs a minimum of 90 days, 8.11 for a weekly review habit. Operations is also entitled to containment authority agreed before an incident rather than during one. And treat the tooling with respect: scanning engines, agents running as root or SYSTEM, plus the tokens that SOAR playbooks hold, all sit at a trust boundary nearer domain admin than ordinary software — whoever edits the routing rules can make a finding vanish without a trace.
Which numbers should the joint review actually read?
NIST rejects estate-wide “percent patched” as not actionable, and a worked September scorecard shows why. Closed on time: 198 of 240 findings, a flattering 82.5 percent overall — yet internet-facing high-severity items reached 95 percent while datacentre high-severity sat at 75 percent, the gap explained by a missing change window that the blended figure hid. Around it sit the other measures worth reading monthly: median and p90 time-to-remediate per cell; unowned findings, 18 of 600 that month; exception health, 6 of 35 past their review date; telemetry coverage, 1,540 of 1,600 assets, the 60 missing traced to an unscanned acquired subsidiary; and a disruption counter for security-caused change — 3 of 120, all three traced to one hardening change rolled out everywhere at once with no pilot ring involved. Never reward closed-ticket counts; that only rewards closing the easy tickets.
Where should a hospital IT team begin?
- Pick one benchmark family and inventory where current settings differ from it.
- Stand up the single register, with owner fields drawn from the CMDB.
- Run the first baseline in log-only mode for a defined cooling-off period.
- Read the six numbers above together in one monthly joint meeting.
Procurement habits help: judge tooling the way any careful buyer judges a purchase, by fit rather than brochure, as laid out in our guide to choosing software that fits your business goals. The review rhythm itself mirrors the follow-up culture that makes telehealth follow-up care work — measurements on a schedule, owned by someone, escalated when they drift. And because the operations side carries most of the delivery load, teams that have invested in DevOps skills built through practical automation tend to find the baseline work far less intimidating than it first appears.