---
title: "SecOps"
slug: secops
category: security
term_status: ambiguous
evidence_status: verified
summary: "SecOps is an ambiguous label. Here it means the working contract between security and IT operations: agreed hardening baselines, one owned remediation queue with deadlines, governed exceptions and joint metrics. Others use it for SOC work or a Google product."
audience: [IT and infrastructure managers, Security managers and CISOs, System administrators, Security engineers, Beginners]
last_verified: 2026-10-17
key_takeaways:
  - "\"SecOps\" has three documented meanings: security and IT operations working to one contract, shorthand for the SOC, and Google's SIEM/SOAR product. This page teaches the first and routes readers to the others."
  - "The conflict is structural, not personal. NIST calls patch management \"a contentious issue for decades\": faster fixes shrink the attacker's window but raise the risk of disruption. Settle that trade-off in advance, per group of assets, not ticket by ticket."
  - "Security chooses and governs the baseline, operations applies it, and a named business owner accepts any residual risk. Every deviation is written down with a reason, a compensating control and a review date; containment the SOC may take at night is agreed in advance."
  - "Run one inventory and one queue keyed on asset ownership (the image owner, where hosts are rebuilt rather than patched). At Equifax the alert went to an out-of-date recipient list, and IT and security kept separate, incomplete inventories."
  - "Hardening changes are production changes. A conformance scan shows what fails, not what enforcement would break: test off production, use a log-only mode where the control has one, otherwise pilot rings with a cooling-off period, then enforce."
  - "Measure on-time remediation by asset importance and urgency, count overdue open items, and pair every speed target with a disruption counter-metric."
  - "Security tooling is operational infrastructure, with owners, health checks and staged updates: a security-agent content update crashed Windows hosts in July 2024."
related: [soc-ops, vulnerabilityops, patchops, itops, detectionops, responseops, devsecops, aiops-for-security]
---

## What SecOps is

### In 30 seconds

**SecOps, as this Atlas uses the word, is the working contract between the security team and IT operations.** It answers four
questions in advance: what "securely configured" means for each kind of asset (hardening baselines); how a security finding becomes
owned, dated work in an operations queue; who may grant an exception, and for how long; and which shared numbers both teams answer to.

It exists because almost every security fix is an operational change; without a contract, each becomes a negotiation.

It is for IT and security managers in small and mid-sized organisations and the engineers between them, and it is the **hub of the
Atlas's security-operations pages** ([routing table](#how-secops-relates-to-other-ops)). **Where to start:** beginners, the
[glossary](#glossary-and-mental-model) and [Lab 1](#hands-on-labs); engineers, the [reference
implementation](#reference-implementation) and [runbook](#worked-runbook-hardening-enforcement-blocks-a-legacy-system); leaders,
the [RACI](#roles-ownership-and-raci), [metrics](#metrics-and-kpis) and [decision framework](#decision-framework).

::: note Term status: ambiguous — read this first
"SecOps" is widely used but has no standard definition; the NIST glossary, for one, has no entry for it[^nist-gl]. Three documented
meanings compete:

1. **Security and IT operations working together.** PagerDuty calls SecOps "a collaborative methodology that integrates security
   and operations teams" and contrasts it with the SOC[^pd]; Elastic describes "a long-term collaboration between the two
   traditionally separate security and operations teams"[^elastic].
2. **The security operations team, or SOC.** Microsoft's Cloud Adoption Framework says the SecOps team "is sometimes referred to as
   a Security Operations Center (SOC)"[^ms-caf]; TechTarget describes a team "often operating from a security operations center, or
   SOC"[^techtarget]. CrowdStrike blends both meanings into one unified team[^crowdstrike].
3. **A product.** Chronicle Security Operations was renamed Google Security Operations ("Google SecOps") in April 2024, a SIEM and
   SOAR platform[^gsecops-rebrand][^gsecops].

This page takes meaning 1 as an **editorial choice**; SOC work is taught on [SOC Ops](../soc-ops/) and no product is endorsed.
In the Atlas's mapping, the closest Microsoft role is **posture management**, which Microsoft also calls vulnerability and attack
surface management: "the operational security team that focuses on security enablement for technical operations teams"[^ms-caf].
:::

### At a glance

| Question | Answer |
|---|---|
| Goal | Security work done through operations on agreed terms |
| In scope | Governing baselines and their exceptions; routing findings to owners; the timeframe each owner group has resourced; the shared register; change windows for security work; telemetry and containment authority owed to the SOC; joint metrics |
| Out of scope | SOC triage, detection engineering, incident response, urgency classes and remediation-SLA policy, risk-acceptance policy, patch rollout |
| Prerequisites | An asset inventory with owners, a ticketing tool, a configuration-assessment source |
| Outputs | Baseline catalogue, exception register, timeframe matrix, routing rules, containment list, joint scorecard |
| Term status | `ambiguous`; this page uses the collaboration meaning |

### The problem it solves

NIST's patch-management guide is blunt: "Enterprise patch management has been a contentious issue for decades, with personnel from the
security and business/mission sides of organizations often having conflicting opinions."[^sp800-40] Fast fixes narrow the attacker's
window but risk disruption; testing first does the opposite. NIST calls the habit of treating patch outages as self-inflicted and
attack outages as someone else's doing "misleading and incomplete": "Disruptions from patching are largely controllable, while
disruptions from incidents are largely uncontrollable."[^sp800-40]

Without a contract, whoever escalates loudest settles the conflict, ticket by ticket. Symptoms: findings in a console operations never
watches; separate asset lists; a baseline rolled back after its first breakage and never re-applied; exceptions by email that never
expire; two sets of numbers, and nobody owning time to remediate.

### What it is not

- **Not the SOC** ([SOC Ops](../soc-ops/)). This page keeps one section on [what operations owes the SOC](#siem-and-soar-at-a-high-level).
- **Not DevSecOps**: pipeline controls are [DevSecOps](../devsecops/); SecOps starts where systems run.
- **Not vulnerability management or patch rollout.** [VulnerabilityOps](../vulnerabilityops/) sets urgency classes, remediation-SLA
  policy and the criteria for vulnerability exceptions; [PatchOps](../patchops/) turns maintenance groups into plans and rollouts;
  [RiskOps](../riskops/) owns risk acceptance. SecOps owns the cross-team agreement they rely on: routing, the timeframe each owner
  group has resourced, the shared register, and baseline exceptions.
- **Not incident response** ([ResponseOps](../responseops/)) or incident command ([IncidentOps](../incidentops/)).
- **Not applying baselines**: SecOps chooses and governs them; [SysOps](../sysops/), [EndpointOps](../endpointops/),
  [KubernetesSecOps](../kubernetessecops/) and [CloudSecOps](../cloudsecops/) apply them.

::: caution Editorial distinction
These boundaries are this Atlas's choice, so that each topic is taught once. No standard draws them; one small team may do it all.
:::

## Where it comes from and where it sits

### Origins and evolution

There is no founding document. Explainers describe SecOps by analogy with DevOps[^crowdstrike], and a January 2016 BMC press
release already described "a significant gap between the security and
IT operations (SecOps) teams"[^bmc2016]. The practices are older: configuration checklists (NIST SP 800-70, Rev. 5 since May
2026[^sp800-70]; CIS Benchmarks[^cis-bench]), configuration management (SP 800-128[^sp800-128]) and patch management[^sp800-40].

### Glossary and mental model

| Term | Meaning on this page |
|---|---|
| Hardening baseline | The configuration an asset class must meet, usually a benchmark tailored locally |
| Level 1 / Level 2 | CIS profiles: Level 1 is "designed to not have an extensive performance impact"; Level 2 adds defence in depth that may disrupt operations if misapplied[^cis-faq] |
| Tailoring | Adapting a benchmark locally, recording each change[^sp800-70]; scanners store it in an XCCDF (Extensible Configuration Checklist Description Format) tailoring file |
| Conformance assessment | A scan (CIS-CAT, OpenSCAP, `usg audit`) reporting which rules pass. It changes nothing, so cannot show what enforcement would break |
| Log-only mode | Offered by *some* controls: would-be blocks are logged, not enforced, as with Defender attack surface reduction (ASR) rules in Audit mode[^ms-asr] or SELinux permissive mode[^rh-selinux] |
| Pilot ring | A small group enforced first, with a cooling-off period before wider rollout[^sp800-70]; the safety net where no log-only mode exists |
| Exception (deviation) | An approved departure from the baseline, with reason, compensating control, risk owner and review date |
| Maintenance group, plan | A group is "a set of assets with similar characteristics that generally have the same software maintenance needs"; its plans set actions and timeframes per scenario (routine, emergency patching, emergency mitigation, unpatchable)[^sp800-40] |
| CMDB, ITSM | Configuration management database (assets, owners) inside the IT service management tool for tickets and changes |
| KEV | CISA's Known Exploited Vulnerabilities catalogue, "the authoritative source of vulnerabilities that have been exploited in the wild"[^kev] |
| SIEM | Security information and event management: gathers security data from many systems and presents it "as actionable information via a single interface"[^nist-siem] |
| SOAR | Security orchestration, automation and response: playbooks that enrich alerts and run response actions |
| EDR, MDR | Endpoint detection and response, an agent on each host; managed detection and response, a market label for a provider that monitors, triages and, within granted authority, contains ([SOC Ops](../soc-ops/)) |

**The mental model: two failure models, one ledger.** *Building Secure and Reliable Systems* says: "When designing
for reliability, you assume that some things will go wrong at some point. When designing for security, you must assume that an
adversary could be trying to make things go wrong at any point."[^bsrs1] Operations guards against the first, security
against the second, and each sees the other's changes as risk. SecOps does not remove that tension; it **prices it in advance**:
maintenance groups say which assets tolerate which disruption, timeframes how fast each finding must be fixed, the register who may say
"not now" and until when, and one queue holds the work both teams read.

### How SecOps relates to other Ops

| If your question is about... | Go to | What SecOps adds |
|---|---|---|
| Alert triage, analyst tiers, MDR | [SOC Ops](../soc-ops/) | Logs, agent health, response authority |
| Writing and testing detections | [DetectionOps](../detectionops/) | The change calendar |
| Threat intelligence and hunting | [ThreatOps](../threatops/) | Routing of findings needing operational fixes |
| Security incidents; incident command | [ResponseOps](../responseops/), [IncidentOps](../incidentops/) | Pre-agreed containment authority ([Annex D](#reference-implementation)) |
| Urgency classes, SLA policy; patch plans and rollout | [VulnerabilityOps](../vulnerabilityops/), [PatchOps](../patchops/) | Routing, resourced timeframes per maintenance group, the shared register |
| Security in CI/CD | [DevSecOps](../devsecops/) | The run-time side of the same findings |
| Change approval, CMDB, service desk | [ITOps](../itops/) | Change routes for security work |
| Security telemetry pipelines and cost | [SecDataOps](../secdataops/) | Which sources operations keeps sending |
| Ransomware readiness: offline, encrypted, tested backups[^cisa-rw] | [BackupOps](../backupops/), [DisasterRecoveryOps](../disasterrecoveryops/); incidents [ResponseOps](../responseops/) | Backup isolation in the baseline; restore tests on the scorecard |
| Privileged administration, break-glass; identities | [AccessOps](../accessops/), [IdentityOps](../identityops/) | Admin access to security tooling in access reviews |
| Protecting business data; AI in security | [DataSecOps](../datasecops/), [AIOps for Security](../aiops-for-security/) | — |
| Audit evidence; risk-acceptance process | [ComplianceOps](../complianceops/), [RiskOps](../riskops/) | The register and change records |

::: figure Where SecOps routes security-operations work
```mermaid
flowchart LR
  S["SecOps: the security and IT operations contract"]
  G1["Detect and respond"]
  G2["Find and fix"]
  G3["Apply baselines"]
  G4["Protect and recover"]
  S --> G1
  S --> G2
  S --> G3
  S --> G4
  G1 --> SOC["SOC Ops: triage"]
  G1 --> DET["DetectionOps: detections"]
  G1 --> RSP["ResponseOps: incidents"]
  G2 --> VUL["VulnerabilityOps: urgency, SLA policy"]
  G2 --> PAT["PatchOps: safe rollout"]
  G2 --> ITO["ITOps: change routes"]
  G3 --> SYS["SysOps: servers"]
  G3 --> EPO["EndpointOps: devices"]
  G3 --> CSO["CloudSecOps: cloud accounts"]
  G4 --> BKP["BackupOps: isolated copies"]
  G4 --> ACC["AccessOps: privileged access"]
  G4 --> DSO["DataSecOps: business data"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class S,G1,G2,G3,G4 core
  class SOC,DET,RSP,VUL,PAT,ITO,SYS,EPO,CSO,BKP,ACC,DSO neutral
```
Text equivalent: twelve of the pages named in the routing table and under "What it is not", in four groups. Detect and
respond: SOC Ops, DetectionOps, ResponseOps. Find and fix: VulnerabilityOps, PatchOps, ITOps. Apply baselines: SysOps,
EndpointOps, CloudSecOps. Protect and recover: BackupOps, AccessOps, DataSecOps.
:::

## Principles and operating model

### Charter and principles

::: decision Atlas proposal: a one-paragraph SecOps charter
*Security and IT operations agree in writing, before they need it, what secure configuration means per asset class, how findings
become owned and dated work, who may accept the risk of not doing it, and which shared measures both are judged on. Security sets
standards and verifies; operations implements and runs; a named business owner accepts residual risk.*
:::

1. **Decide the trade-off before the emergency.** Assessing each new vulnerability from scratch "is simply not feasible", so NIST says
   planning "needs to be done in advance"[^sp800-40]. Agree maintenance groups and timeframes once; apply them per finding.
2. **Separate setting the standard, doing the work and accepting the risk.** In NIST SP 800-128 the system administrator "implements
   agreed-upon secure baseline configurations"; the authorising official decides whether changes remain "an acceptable security
   risk"[^sp800-128]; outside government, the accountable service or business owner (the Atlas's mapping).
3. **One inventory, one queue, one owner per asset.** An unowned finding is not fixed ([Equifax](#use-cases-and-scenarios)).
4. **Every deviation is recorded, narrow and temporary.** NIST SP 800-70 Rev. 5 asks for deviations "with documented justifications,
   risk acceptance, and compensating controls" and prefers exceptions for the users or devices that need them over relaxing a setting
   everywhere[^sp800-70]; CSF 2.0 lists it as outcome ID.RA-07[^csf2].
5. **Hardening is a change.** A conformance scan cannot show what enforcement would break. Test on a non-production system
   first[^cis-faq][^sp800-70]; then use the control's log-only mode if it has one, otherwise NIST's pilot deployment groups "with a
   cooling off period to assess residual impact reports"[^sp800-70], with rollback or a backup ready. Where the vendor made
   enforcement safe, enforce at once ([playbook](#core-practices-and-playbooks)).
6. **Measure jointly, including the cost of security change.** Speed targets without a disruption counter-metric teach operations to
   distrust security changes.
7. **Security tooling is production infrastructure**, with owners, monitoring and change control.
8. **Prefer paved roads to tickets.** For six products and 120 firewalls, *Building Secure and Reliable Systems* suggests security
   operate "an automated configuration system that accepts, validates, approves, and pushes firewall changes proposed by the six
   product teams"[^bsrs20].

**Non-goals:** running the SOC, replacing change enablement, or turning security into a change approval board.

### Fundamentals: building blocks

| Building block | Minimum viable version | Usual owner |
|---|---|---|
| Asset inventory with owner group, maintenance group and exposure flag | CMDB fields, reconciled monthly against scanner discovery | IT operations |
| Baseline catalogue | One page: asset class → benchmark → profile → tailoring file → version | Security |
| Exception register | Mandatory fields and a monthly report ([Lab 1](#hands-on-labs)) | Security keeps it; business owners sign |
| Timeframe matrix | Maximum days per urgency class (set in [VulnerabilityOps](../vulnerabilityops/)) × maintenance group, backed by capacity | Joint |
| Shared queue | Tickets in operations' own tool, routed from the CMDB ([Lab 3](#hands-on-labs)) | IT operations hosts; security feeds |
| Telemetry minimum | The CIS Control 8 basics [below](#siem-and-soar-at-a-high-level) | IT operations |
| Joint scorecard | Seven measures on one page ([metrics](#metrics-and-kpis)) | Joint |

### Roles, ownership and RACI

The Atlas proposes this RACI (R responsible, A accountable, C consulted, I informed). "Security" means whoever does SecOps work.

| Activity | Security | IT ops owner group | Service or business owner | Head of IT ops | CISO |
|---|---|---|---|---|---|
| Select and tailor a baseline | R | C | I | C | A |
| Apply a baseline and fix drift | C | R/A | I | I | I |
| Route findings and set due dates | R | C | I | I | A |
| Rule on a disputed finding | R (decides on evidence) | C (supplies evidence) | I | I | A |
| Fix a finding by its due date | I | R | I | A | I |
| Grant an exception (accept residual risk) | R (records, advises) | C (proposes controls) | **A** | C | C |
| Decide an emergency change outside the window | C | R | C | **A** | C (can escalate) |
| Pre-authorise containment actions ([Annex D](#reference-implementation)) | R | C | C | C | A |
| Keep security tooling healthy | A | R (hosts, certificates) | — | C | I |
| Publish the joint scorecard | R | C | I | C (co-signs) | A |

The requester of an exception never approves it, and the Head of IT ops co-signs the scorecard so neither side can disown it. The
Head of IT ops decides *timing* within the agreed timeframe; leaving exposure open beyond it is risk acceptance, which belongs to the
business owner. Many organisations add **security champions**, as Google describes for product teams[^bsrs20]; in operations, a
senior administrator who reviews security tickets weekly.

### Lifecycle

A baseline's lifecycle mirrors NIST's four phases of security-focused configuration management: plan, identify and implement,
control changes, monitor[^sp800-128].

::: figure Lifecycle of a hardening baseline
```mermaid
flowchart TB
  A["Select benchmark and profile"] --> B["Tailor; record deviations"]
  B --> C["Test outside production"]
  C --> D["Log-only mode, else pilot ring"]
  D --> E{"Denials logged or ring broke?"}
  E -- "No, after cooling-off" --> G["Enforce in further rings"]
  G --> H["Monitor drift with scans"]
  H --> I["Review yearly or on change"]
  E -- "Yes" --> F["Fix, or exception with expiry"]
  F --> D
  I --> B
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,B,C,D,G,H,I core
  class E decision
  class F risk
```
Text equivalent: Select a benchmark and profile, tailor it, record deviations, test outside production. Then run the control's
log-only mode, or else a small pilot ring. If denials appear or the ring breaks, fix the cause or grant a narrow, expiring exception,
and repeat. If nothing breaks after a cooling-off period, enforce in further rings, monitor drift with scans, and review yearly or on
significant change, feeding back into tailoring.
:::

The yearly-or-on-change review follows CIS Safeguard 4.1[^cis-4]. **Day 0** agrees the contract; **Day 1** opens the shared queue and the first conformance scan;
**Day 2** is the routine of drift, findings, reviews and the scorecard.

### Operating model and governance

| Cadence | Forum | Decisions |
|---|---|---|
| Weekly, 30 minutes | Queue review: security lead, one champion per owner group | Re-route unowned items; unblock items due within 14 days |
| Monthly | Remediation review: both heads, scorecard | Capacity, windows, escalations; CIS Safeguard 7.2 asks for "monthly, or more frequent, reviews"[^cis-7] |
| Quarterly | Exception review: security, business owners | Renew, retire, or give long-lived exceptions their own maintenance group[^sp800-40] |
| Yearly or on major change | Baseline review | New baseline version |
| After a security-caused outage or missed emergency | Joint post-incident review | Fix the contract, not only the server |

**Escalation ladder:** owner group → weekly review → the two heads → the business owner, who gets a written choice: fix by a date
at a stated cost, or accept the risk with a compensating control until a date.

## Architecture and workflow

### Reference architecture

::: figure Reference architecture: from finding to verified fix
```mermaid
flowchart TB
  subgraph SIG["Signals"]
    direction LR
    ADV["Advisories and KEV"]
    VS["Vulnerability scans"]
    CA["Conformance scans"]
    SOCF["SOC findings"]
  end
  TR["SecOps triage: owner, group, exposure from CMDB"]
  EXR[("Exception register")]
  Q["Owner queues in ITSM"]
  CH{"Change route"}
  STD["Standard change"]
  NRM["Normal change"]
  EMG["Emergency change"]
  VER["Verify by rescan"]
  SC["Joint scorecard"]
  SIG --> TR
  TR --> Q
  Q -.->|"owner cannot fix by due date"| EXR
  EXR -.->|"expired or rejected"| Q
  Q --> CH
  CH --> STD
  CH --> NRM
  CH --> EMG
  STD --> VER
  NRM --> VER
  EMG --> VER
  VER --> SC
  EXR --> SC
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class TR,Q,VER,SC core
  class CH decision
  class EXR,EMG risk
  class ADV,VS,CA,SOCF,STD,NRM neutral
```
Text equivalent: Advisories and KEV, vulnerability and conformance scans and SOC findings enter SecOps triage, which takes owner,
group and exposure from the CMDB and routes each item to an owner queue. Items not fixable by the due date go to the exception
register; expired or rejected exceptions return. Each fix takes a standard, normal or emergency change, is verified by rescan and
feeds the joint scorecard, which also reports on the register.
:::

| Component | Design notes |
|---|---|
| Signals and triage | Each source needs an owner and a health check; rules route, people handle the unowned remainder |
| Owner queues | Work lives where operations already works; duplicate tickets across tools cause "we never saw it" |
| Change routes | Agree with [ITOps](../itops/) that routine security fixes qualify as standard (pre-approved) changes |
| Verification and register | Close on a rescan, not on "resolved"; keep the register separate so closing a ticket cannot hide a live risk |
| Rebuilt (image-based) assets | Route to the image owner; close on a clean image and no old instances (below) |

**Trust boundaries.** Scanners hold credentials for every host, agents run as root or SYSTEM, and SOAR tokens can disable accounts:
administer them like domain administration (separate admin accounts, MFA, logged changes, a named owner). Whoever can edit routing
rules or the register can make findings disappear.

**Alternatives.** A small organisation can use its ticketing tool, a spreadsheet register and scanner exports. ITSM security modules
automate routing: ServiceNow Vulnerability Response (Yokohama release) by default assigns a vulnerable item to the support group of
its CMDB configuration item, and leaves it unassigned when no rule matches and no default rule exists[^sn-assign].

**Estates that are rebuilt, not patched.** Containers and golden-image hosts are not fixed in place. With containers, NIST notes,
"these updates must be made upstream in the images themselves, which are then redeployed"; for container hosts some organisations
"simply redeploy new OS instances with the necessary updates, rather than updating existing systems", which "often requires more
sophisticated operational practices"[^sp800-190]. Three things change. **Routing:** the CMDB links each instance to its image and
the image to an owner, often a platform or pipeline team; findings go there. **Due date:** it covers the rebuilt image *and* its
redeployment. **Verification:** a clean scan of the new image, and no instance of the old one still running. Baselines, too, are
applied in the image build and assessed on the image. Pipelines and rebuilds are taught on [DevSecOps](../devsecops/) and
[ContainerOps](../containerops/).

### End-to-end workflow

::: figure Happy path and exception path for one finding
```mermaid
sequenceDiagram
  participant SRC as Scanner
  participant SEC as SecOps triage
  participant OPS as Owner team
  participant CHG as Change
  participant BO as Risk owner
  SRC->>SEC: Finding on db-01
  Note over SEC: Owner, group, due date
  SEC->>OPS: Ticket in owner queue
  alt Fix possible by due date
    OPS->>CHG: Standard or normal change
    CHG-->>OPS: Implemented in window
    OPS->>SEC: Resolved
    SEC->>SRC: Rescan
    SRC-->>SEC: Clean, ticket closed
  else Fix not possible in time
    OPS->>SEC: Propose mitigation
    SEC->>BO: Exception request
    BO-->>SEC: Accept until review date
    Note over SEC: Record in register
  end
```
Text equivalent: The scanner reports a finding on db-01. SecOps triage sets owner, group and due date and tickets the owner team. If
the fix is possible in time, the owner team changes it in the window and marks it resolved; SecOps closes the ticket only on a clean
rescan. If not (no patch yet, a vendor certification, a business freeze), the owner team proposes a mitigation, SecOps asks the risk
owner, and an accepted exception is recorded with a review date.
:::

**Emergency path.** For an actively exploited flaw on an exposed asset, the emergency patching or mitigation plan applies: NIST
suggests the routine staged approach on "a highly accelerated schedule", canary assets first where possible[^sp800-40]. If
compromise is plausible, involve [ResponseOps](../responseops/). For US federal civilian agencies, BOD 26-04 sets three days for the most
severe combinations, plus forensic triage where a KEV-listed flaw gives total control on a publicly exposed asset, or on an internal
one when exploitation is automatable (Table 1 rows 1, 3 and 9); other combinations get 14 or 60 days, or wait for a system
upgrade[^bod2604].

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Trigger | Owner | Verification |
|---|---|---|---|
| Adopt or revise a baseline | New asset class or benchmark version; yearly review | Security (R), owner groups (C) | Conformance scans before and after |
| Log-only or pilot, allow-list, enforce | A hardening change that can break clients | Owner group | No denials outside the allow-list after enforcement |
| Emergency change | Emergency urgency ([Annex A](#reference-implementation)) | Head of IT ops (A) | Rescan; compromise check if exposure was long |
| Security tooling health | Daily | Tool owner | Agents reporting, scans completing, certificates valid |
| Security-agent update rings | Any EDR, antivirus or inspection-content update | Tool owner with ops | Crash and performance telemetry per ring |

#### Playbook: log-only, allow-list, enforce

Microsoft's Netlogon fix for CVE-2020-1472 is the best public example of both variants:

- **Initial deployment phase** (updates from 11 August 2020): secure RPC enforced for Windows devices, trust accounts and all domain
  controllers. Other vulnerable connections, mostly from non-Windows devices, were allowed and logged (event 5829) for owners to fix.
- **Allow-list:** devices not fixed in time could join a security group named in the policy "Domain controller: Allow vulnerable
  Netlogon secure channel connections"; "The end goal should be to address and remove all accounts from this group policy."
- **Enforcement phase** (updates from 9 February 2021): afterwards "you will not be able to disable enforcement mode"[^netlogon].

*Success measure:* an empty allow-list before the vendor's date. *Pitfall:* treating the August update as "done" because it
installed cleanly; name who watches the vendor's calendar. The general pattern:

1. **Enforce at once where it is safe.** Microsoft says its standard-protection ASR rules can typically be enabled in
   Block or Warn mode "without testing"[^ms-asr].
2. **Log only, for the rest.** Record what *would* be blocked, long enough to see monthly and quarterly jobs; without a log-only
   mode, a pilot ring with a cooling-off period plays this role.
3. **Find and fix.** Route each non-compliant client to its owner through the shared queue.
4. **Allow-list narrowly.** Put clients that cannot be fixed yet into a named group, each with a register entry and review date.
5. **Enforce in stages**, pilot ring first, watching denial events.
6. **Shrink the allow-list** to zero, or move what remains into its own isolated maintenance group.

### Methods, standards and frameworks

| Source | What it gives SecOps | Binding? |
|---|---|---|
| CIS Benchmarks: consensus guides, more than 100 benchmarks across 25+ product families, free PDFs[^cis-bench][^cis-faq] | Baseline content; Level 1, Level 2 and STIG profiles | Voluntary |
| DISA STIGs: Security Technical Implementation Guides of the US Defense Information Systems Agency; CIS lists STIG benchmarks[^cis-bench] | Stricter baselines | Depends on your contracts |
| Vendor baselines, e.g. Microsoft Security Compliance Toolkit[^ms-sct] | Windows and Office baselines, Group Policy comparison | Voluntary |
| NIST SP 800-70 Rev. 5 (May 2026)[^sp800-70], SP 800-128[^sp800-128], SP 800-40 Rev. 4[^sp800-40] | Tailoring, testing and deviations; configuration-management phases and roles; maintenance groups, plans and metrics | Voluntary outside US federal |
| CIS Controls v8.1 | Safeguards 4.1 (configuration process), 7.1–7.7 (vulnerability management and remediation), 8.x (logging)[^cis-4][^cis-7][^cis-8] | Voluntary |
| NIST CSF 2.0[^csf2] | Outcomes GV.RR-02 (roles), ID.RA-07 (exceptions), PR.PS-01 (configuration), PR.PS-04 (logs) | Voluntary |
| ITIL 4 change enablement ([ITOps](../itops/)) | Standard, normal and emergency change routes | Voluntary |
| CISA BOD 26-04 (June 2026)[^bod2604] | Risk-based remediation timeframes | US federal civilian agencies only |

None is law in itself; obligations come from the contracts, regulators and directives that apply to *your* organisation. This
page is not legal advice.

### Tooling landscape

Categories first; products are examples checked against their documentation in October 2026, not recommendations.

| Category | Job in SecOps | Examples | Selection notes |
|---|---|---|---|
| Configuration assessment | Measure conformance; express tailoring | CIS-CAT Pro Assessor[^cis-faq]; OpenSCAP with ComplianceAsCode content[^oscap][^cac]; Ubuntu Security Guide[^usg-audit]; Wazuh SCA, "mostly based on the CIS benchmarks"[^wazuh-sca] | Check the benchmark *version* implemented: ComplianceAsCode's Ubuntu 24.04 CIS Level 1 profile follows CIS v1.0.0 (2024)[^cac]; CIS lists v2.0.0[^cis-bench] |
| Vulnerability scanning | Find missing patches | See [VulnerabilityOps](../vulnerabilityops/) | Unauthenticated scans "will generally underreport vulnerabilities"[^sp800-40] |
| ITSM with security modules | Route, date and track | ServiceNow Vulnerability Response (Yokohama release)[^sn-assign] | Routing is only as good as the CMDB |
| SIEM and SOAR | Central search, alerting, playbooks | Microsoft Sentinel[^sentinel]; Google SecOps[^gsecops]; Wazuh, "free and open source"[^wazuh] | Often priced by data volume; platforms move (Sentinel leaves the Azure portal after 31 March 2027)[^sentinel] |
| Configuration management | Apply baselines at scale | Group Policy, configuration management tools, MDM | Owned by SysOps and EndpointOps; SecOps supplies content |

**Lock-in.** Tailoring files, routing rules and playbooks outlive tools; version them in portable forms (XCCDF tailoring files) with
the benchmark version they target.

### SIEM and SOAR at a high level

The SOC is taught on [SOC Ops](../soc-ops/); this section covers **what operations owes the SOC**, because detections fail silently
when operations changes things unannounced. CIS Control 8 sets the minimum[^cis-8]. IG1, "essential cyber hygiene"[^cis-ig], needs
a logging process, collected audit logs and enough storage (8.1–8.3); IG2 adds synchronised time (8.4), central collection, typically
in a SIEM (8.9), retention "for a minimum of 90 days" (8.10) and weekly reviews (8.11).

The Atlas adds three duties: onboard new assets to logging and agents as part of the build; share the change calendar so detection
engineers can tell planned from hostile change; and pre-agree which containment actions the SOC or a SOAR playbook may take without
waking the owner ([Annex D](#reference-implementation)). Pipelines and ingest costs belong to [SecDataOps](../secdataops/).

### Automation and AI

NIST's third patch-management principle is "Rely on automation"[^sp800-40]; in SecOps it pays off in routing, due dates, rescans,
review-date reminders and the scorecard. Guardrails: automatic remediation only for changes proven on a pilot ring of the same
maintenance group; close tickets on evidence; and automation that changes production takes the same change route as a person.

Vendors market AI in SIEM and SOAR products; Google advertises Gemini for natural-language search and case summaries[^gsecops].
Modest SecOps uses, each checked by a person: summarising findings for owners, suggesting owners for unrouted items, drafting
exception records. In the Atlas's assessment, independent evidence on accuracy is thin ([AIOps for Security](../aiops-for-security/)).

## SecOps in practice

### Reference implementation

::: example Illustrative scenario: a mid-sized company sets up the contract
About 400 servers, 1,200 laptops, one ITSM tool, a security team of four, fifteen IT operations staff in four owner groups and an
outsourced 24×7 monitoring service. Its first-quarter artefacts follow; values are examples, not a standard's.
:::

**Artefact 1: policy excerpt (the contract in plain words).**

_Example status: illustrative text, not executed._

```text
SecOps operating agreement v1.0
Owners: Head of IT Operations, CISO. Approved by: COO.
1. Every asset in the CMDB has an owner group, a maintenance group and an
   exposure flag. Assets without them are found weekly and fixed within
   10 working days. Image-built assets also name their image owner.
2. Security selects and tailors hardening baselines; owner groups apply them.
   Changes are tested off production, then enforced on a pilot ring with a
   two-week cooling-off period; controls with a log-only mode run in it for
   one full monthly cycle first.
3. Security findings are tickets in the owner group's own queue, with a due
   date from the timeframe matrix (Annex A). Tickets close only on a clean
   rescan, or when security accepts the owner group's evidence that the
   finding is false or not applicable (decided within 5 working days; the
   due date stands). Closure reasons are recorded and sampled quarterly.
4. If a due date cannot be met, the owner group proposes a compensating
   control and the service owner accepts or rejects the residual risk in
   writing (Annex B form). Exceptions expire after at most 6 months and are
   reviewed quarterly.
5. Emergency findings (Annex A) use the emergency change route. The Head of
   IT Operations decides timing within the timeframe; going beyond it is an
   exception under clause 4. The CISO may escalate to the COO.
6. The CISO publishes one scorecard monthly (Annex C), co-signed by the Head
   of IT Operations, including the share of security changes that caused an
   incident.
7. The SOC and the monitoring provider may take the containment actions in
   Annex D at any hour. Any other action needs the service owner or the Head
   of IT Operations.
```

**Artefact 2: timeframe matrix and routing (Annex A).** Maximum calendar days from detection to fix or accepted mitigation. Urgency
classes are designed on [VulnerabilityOps](../vulnerabilityops/); this annex records what each owner group has agreed and resourced.

_Example status: YAML syntax-checked by the Atlas validator; schema is illustrative, not a product's._

```yaml
timeframe_days:          # urgency -> maintenance group -> days
  emergency:             # exploited in the wild, asset reachable by attackers
                         # (from an untrusted network or user population)
    internet-facing: 2
    datacentre: 3
    laptops: 3
    build-agents: 3
  high:
    internet-facing: 7
    datacentre: 14
    laptops: 14
    build-agents: 30
  routine:
    internet-facing: 30
    datacentre: 30
    laptops: 30
    build-agents: 60
routing:
  source_of_owner: cmdb.owner_group
  unowned_queue: secops-triage          # never drop; a person finds the owner
  verification: rescan_required
  reminders_days_before_due: [7, 2]
```

**Artefact 3: an exception record (Annex B).**

_Example status: YAML syntax-checked by the Atlas validator; illustrative._

```yaml
id: EX-014
asset_group: payroll-connector    # narrow scope: one group, not the estate
baseline_rule: tls-legacy-protocols-disabled
reason: Vendor client supports TLS 1.0 only; upgrade scheduled with release 9.2
impact_of_deviation: Downgrade attack possible on one internal connection
compensating_controls:
  - Firewall allows the connector from one source address only
  - Connection logs forwarded to the SIEM; alert on any other source
requested_by: payments-team
risk_acceptor: head-of-payroll          # business owner, not the requester
approved: 2026-10-01
review_by: 2027-03-31
exit_criteria: Vendor release 9.2 deployed and the rule re-enabled
```

**Artefact 4: containment actions agreed in advance (Annex D).** NIST lists among the usual elements of an incident response policy
"which roles have the authority to confiscate, disconnect, or shut down technology assets", and wants a provider's responsibilities,
including its "authority to act on behalf of the organization", clearly defined in the contract[^sp800-61]. SecOps records which
actions operations accepts unasked, how the owner hears and how each is undone; [SOC Ops](../soc-ops/) and [ResponseOps](../responseops/) carry them out.

_Example status: YAML syntax-checked by the Atlas validator; an Atlas proposal with example values, not a product's schema._

```yaml
# Asset tiers (as in SOC Ops): 1 crown jewels and admins, 2 servers, 3 devices
# Review after every use and at least yearly.
preauthorised:
  - action: isolate-device               # EDR network isolation
    who: [soc-analyst, mdr-provider, soar-playbook]
    scope: tier-3 laptops and desktops
    owner_told: service desk calls the user within 1 hour
    undo: release in the EDR console after triage
  - action: disable-account              # and revoke its sessions
    who: [soc-analyst, mdr-provider]
    scope: tier-3 user accounts; never admin, service or break-glass
    owner_told: line manager within 1 hour
    undo: re-enable after password reset and MFA re-registration
  - action: block-at-edge
    who: [soc-analyst]
    scope: external IP addresses and domains, except partner lists
    owner_told: network on-call, next business day
    undo: rule expires after 7 days unless renewed
  - action: isolate-server
    who: [ops-on-call]                   # on the SOC's request, any hour
    scope: tier-2 servers
    owner_told: page the service owner at once
    undo: rollback step in the service runbook
needs_owner_decision:                    # service owner or Head of IT Ops
  - any action on a tier-1 system or an admin account
  - shutting down a service that customers use
  - anything that destroys evidence      # ask ResponseOps first
```

### Hands-on labs

**Labs 1 and 3 were executed** on 2026-10-17 (Ubuntu 20.04, Python 3.8.10); **Lab 2 was not**. All data is synthetic.

#### Lab 1 (beginner): exception register health check

**Objective.** Find exceptions past review and records missing mandatory fields. **Prerequisites.** Python 3.8+. **Cost and risk.**
None.

1. Save the register as `exceptions.csv`:

_Example status: executed on 2026-10-17 as input to the script below._

```text
id,group,rule,reason,control,acceptor,approved,review_by,status
EX-001,payroll,tls-old-off,TLS 1.0 app,one IP,cfo,2026-04-01,2026-07-01,open
EX-002,lab,auditd-lock,kernel class,own VLAN,it-head,2026-08-15,2026-11-15,open
EX-003,scada,auto-updates,vendor cert,,plant-mgr,2026-02-10,2026-08-10,open
EX-004,build,usb-storage-off,,none,,2026-09-01,2026-12-01,open
EX-005,web,ssh-root-off,migration,bastion,cto,2026-01-05,2026-03-05,closed
```

2. Save the script as `exception_report.py`:

_Example status: executed on 2026-10-17 (Python 3.8.10)._

```python
#!/usr/bin/env python3
"""Exception register report: overdue reviews, incomplete records, age."""
import csv
import statistics
import sys
from datetime import date

REQUIRED = ("reason", "control", "acceptor", "review_by")


def parse(day):
    return date.fromisoformat(day) if day else None


def main(path, today):
    with open(path, newline="") as handle:
        rows = [r for r in csv.DictReader(handle) if r["status"] == "open"]
    if not rows:
        print("open exceptions: 0")
        return 0
    overdue, incomplete, ages = [], [], []
    for r in rows:
        ages.append((today - parse(r["approved"])).days)
        missing = [f for f in REQUIRED if not r[f] or r[f].lower() == "none"]
        if missing:
            incomplete.append((r["id"], missing))
        review = parse(r["review_by"])
        if review and review < today:
            overdue.append((r["id"], (today - review).days))
    print(f"open exceptions: {len(rows)}")
    share = 100 * len(overdue) / len(rows)
    print(f"past review date: {len(overdue)} ({share:.0f}%)")
    for ident, days in sorted(overdue, key=lambda x: -x[1]):
        print(f"  {ident}: review overdue by {days} days")
    print(f"incomplete records: {len(incomplete)}")
    for ident, fields in incomplete:
        print(f"  {ident}: missing {', '.join(fields)}")
    print(f"median age of open exceptions: {statistics.median(ages):.0f} days")
    return 1 if overdue or incomplete else 0


if __name__ == "__main__":
    as_of = date.today()
    if len(sys.argv) > 2:
        as_of = date.fromisoformat(sys.argv[2])
    sys.exit(main(sys.argv[1], as_of))
```

3. Run it with a fixed date so the output is reproducible: `python3 exception_report.py exceptions.csv 2026-10-16`.

**Expected output** (exit code 1, because problems were found):

```text
open exceptions: 4
past review date: 2 (50%)
  EX-001: review overdue by 107 days
  EX-003: review overdue by 67 days
incomplete records: 2
  EX-003: missing control
  EX-004: missing reason, control, acceptor
median age of open exceptions: 130 days
```

**Validation.** EX-001's review date, 2026-07-01, is 107 days before 2026-10-16; an empty register prints 0 and exits 0. **Troubleshooting.** `ValueError: Invalid isoformat
string` means a date is not `YYYY-MM-DD`; `KeyError` means a misspelt column header. **Extension.** Schedule it weekly and alert on exit
code 1. **Teardown.** Delete the two files.

#### Lab 2 (intermediate): assess a server against CIS Level 1 and express exceptions as code

**Objective.** Run a conformance assessment (USG calls it an audit; it changes nothing) of an Ubuntu server against CIS Level 1
Server with Canonical's Ubuntu Security Guide (USG), and record an approved exception as a tailoring file instead of an email.
**Prerequisites.** A **disposable** Ubuntu LTS virtual machine that USG supports, an Ubuntu One account, sudo. **Cost and risk.**
USG needs an Ubuntu Pro attachment, which registers the machine to your subscription (default: the Free Personal
Token[^usg-install]; personal use is free "on up to 5 physical machines"[^ubuntu-pro]). A plain `pro attach` also enables ESM
repositories and the Livepatch snap[^usg-install]; `--no-auto-enable` (per the client's help) prevents that. Never run `usg fix` on
a shared or production machine.

_Example status: commands from Canonical's USG documentation (checked 2026-10-16), plus the `--no-auto-enable` flag; not executed._

```bash
# 1. Install the Pro client, attach the machine and enable only USG
sudo apt update
sudo add-apt-repository universe     # step in Canonical's install guide
sudo apt install ubuntu-advantage-tools
sudo pro attach --no-auto-enable     # follow the link; pick your subscription
sudo pro enable usg
sudo apt install usg usg-benchmarks-1

# 2. Conformance assessment (read-only); HTML and XML reports in /var/lib/usg/
sudo usg audit cis_level1_server

# 3. Create a tailoring file, then edit it: set selected="false" on the rule
#    covered by an approved exception; add the exception id in an XML comment
sudo usg generate-tailoring cis_level1_server tailor.xml

# 4. Audit again with the tailoring file
sudo usg audit --tailoring-file tailor.xml
```

Sources: Canonical's documentation[^usg-install][^usg-bench][^usg-audit][^usg-custom]. **Expected output.** The first `usg audit`
prints a compliance summary and writes the reports; in the second, the deselected rule no longer counts as a failure.
**Validation.** The deselected rule matches a register entry; nothing else changed. Canonical notes that "Compliance with a benchmark
isn't an all-or-nothing task"[^usg-custom]; a versioned tailoring file keeps register and scan in agreement. **Troubleshooting.** If
`pro enable usg` fails, check attachment with `pro status`; if a profile name is rejected, check the profiles for your release.
**Teardown.** `sudo pro detach`, then delete the virtual machine.

#### Lab 3 (advanced): route findings and measure the joint timeframes

**Objective.** Route findings to owners with due dates, flag unowned assets, and compute NIST-style on-time remediation by asset
importance and urgency[^sp800-40]. Urgency is an input (see
[VulnerabilityOps](../vulnerabilityops/)). **Prerequisites.** Python 3.8+. **Cost and risk.** None.

1. Create the inputs.

_Example status: executed on 2026-10-17 as input to the script below._

```text
owners.csv
asset,owner_group,maintenance_group,importance
web-01,web-platform,internet-facing,high
web-02,web-platform,internet-facing,high
db-01,data-platform,datacentre,high
app-07,payments-team,datacentre,moderate
lt-0042,endpoint-team,laptops,moderate
build-03,devex-team,build-agents,low

findings.csv
finding,asset,urgency,detected,closed
F-101,web-01,emergency,2026-09-01,2026-09-02
F-102,web-02,emergency,2026-09-01,2026-09-05
F-103,db-01,high,2026-08-20,2026-09-10
F-104,app-07,high,2026-08-20,2026-10-02
F-105,lt-0042,routine,2026-07-10,2026-08-01
F-106,build-03,routine,2026-07-10,
F-107,printer-9,high,2026-09-15,
F-108,db-01,routine,2026-06-01,2026-07-20
```

Save `sla.json` with the `timeframe_days` values from Artefact 2:

_Example status: JSON syntax-checked by the Atlas validator; executed as input._

```json
{
  "emergency": {
    "internet-facing": 2, "datacentre": 3, "laptops": 3, "build-agents": 3
  },
  "high": {
    "internet-facing": 7, "datacentre": 14, "laptops": 14, "build-agents": 30
  },
  "routine": {
    "internet-facing": 30, "datacentre": 30, "laptops": 30, "build-agents": 60
  }
}
```

2. Save the script as `route_and_measure.py`:

_Example status: executed on 2026-10-17 (Python 3.8.10)._

```python
#!/usr/bin/env python3
"""Route findings to owner queues with due dates, then measure the joint SLA."""
import csv
import json
import statistics
import sys
from collections import defaultdict
from datetime import date, timedelta


def load_csv(path):
    with open(path, newline="") as handle:
        return list(csv.DictReader(handle))


def main(findings_path, owners_path, sla_path, today):
    owners = {row["asset"]: row for row in load_csv(owners_path)}
    with open(sla_path) as handle:
        sla = json.load(handle)
    cells = defaultdict(list)  # (importance, urgency) -> [(days_taken, met)]
    print("finding  queue           due         state")
    for f in load_csv(findings_path):
        owner = owners.get(f["asset"])
        if owner is None:
            note = f"triage: find an owner for {f['asset']}"
            print(f"{f['finding']:8} {'UNOWNED':15} {'-':11} {note}")
            continue
        detected = date.fromisoformat(f["detected"])
        days_allowed = sla[f["urgency"]][owner["maintenance_group"]]
        due = detected + timedelta(days=days_allowed)
        closed = date.fromisoformat(f["closed"]) if f["closed"] else None
        state = "closed" if closed else ("OVERDUE" if today > due else "open")
        print(f"{f['finding']:8} {owner['owner_group']:15} {due}  {state}")
        key = (owner["importance"], f["urgency"])
        if closed:
            cells[key].append(((closed - detected).days, closed <= due))
        elif today > due:
            cells[key].append(((today - detected).days, False))
    print("\nimportance/urgency   n  by-deadline  mean-days  median-days")
    for (importance, urgency), items in sorted(cells.items()):
        days = [d for d, _ in items]
        share = 100 * sum(1 for _, ok in items if ok) / len(items)
        mean, median = statistics.mean(days), statistics.median(days)
        print(f"{importance:9}/{urgency:9} {len(items):2}  {share:10.0f}%"
              f"  {mean:9.1f}  {median:11.1f}")


if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2], sys.argv[3], date.fromisoformat(sys.argv[4]))
```

3. Run `python3 route_and_measure.py findings.csv owners.csv sla.json 2026-10-16`.

**Expected output:**

```text
finding  queue           due         state
F-101    web-platform    2026-09-03  closed
F-102    web-platform    2026-09-03  closed
F-103    data-platform   2026-09-03  closed
F-104    payments-team   2026-09-03  closed
F-105    endpoint-team   2026-08-09  closed
F-106    devex-team      2026-09-08  OVERDUE
F-107    UNOWNED         -           triage: find an owner for printer-9
F-108    data-platform   2026-07-01  closed

importance/urgency   n  by-deadline  mean-days  median-days
high     /emergency  2          50%        2.5          2.5
high     /high       1           0%       21.0         21.0
high     /routine    1           0%       49.0         49.0
low      /routine    1           0%       98.0         98.0
moderate /high       1           0%       43.0         43.0
moderate /routine    1         100%       22.0         22.0
```

**Validation.** F-102 (due 3 September) closed on 5 September: 1 of 2 on time in high/emergency. Open, overdue F-106 counts as
missed at its current age of 98 days; dropping it would flatter the backlog. F-107 never reaches a queue, the Equifax failure in
miniature. **Troubleshooting.** `KeyError: 'laptops'` means the matrix lacks a
maintenance group used in `owners.csv`. **Extension.** Add a 90th percentile per cell. **Teardown.** Delete the files.

### Use cases and scenarios

**1. Equifax, 2017: no owner, no detection (documented).** According to GAO, after a March 2017 US-CERT notice about an Apache
Struts flaw, Equifax "circulated the notice among their systems administrators. However, the recipient list for the notice was
out-of-date". A scan a week later "did not detect the vulnerability on the online dispute portal"; a certificate that "had expired
about 10 months before the breach" blinded the traffic-inspection tool; the attack "lasted for about 76 days before it was
discovered"[^gao]. The House majority staff report adds that the IT and security organisations "were siloed", kept separate,
incomplete inventories, and let "over 300 security certificates" expire[^house]. *What a contract changes:* routing by CMDB owner, a weekly unowned-asset list, scanner
coverage checked against the inventory, certificate expiry monitored by operations. *Success measure:* no finding without an
owner for more than a week. *Caveat:* a majority staff report; GAO relies on Equifax officials' account.

**2. A security agent's content update, July 2024 (documented).** A CrowdStrike content update for the Windows sensor, live from
04:09 to 05:27 UTC on 19 July 2024, crashed Windows hosts on sensor 7.11 or later that received it. Customers chose sensor versions
(N, N-1, N-2) through update policies; the Rapid Response Content involved was delivered separately. One remediation: "Provide
customers additional control over the deployment of Rapid Response Content updates"[^cs-hub]. *Success measure:* every update
channel of every security agent has a named owner and rings ([ReleaseOps](../releaseops/)), or a register entry if it cannot be staged.

**3. A small company with outsourced monitoring (illustrative).** Eighty staff, two IT administrators, an MDR provider. SecOps is
one page: the escalation path, who may isolate a laptop at night (Annex D), a monthly patch window with a 72-hour emergency rule, a
spreadsheet register. *Success measure:* provider actions stay within Annex D; its findings reach owner
queues. *Pitfall:* assuming the provider fixes things (see the [FAQ](#faq)).

**4. A plant with operational technology (illustrative).** Control systems are patched only in shutdowns. NIST's example group
"Legacy OT assets" relies on isolation and physical security[^sp800-40]: give OT its own maintenance groups and plans, agreed with
plant engineering. *Success measure:* each unpatched OT asset has a register entry with verified isolation. *Pitfall:* holding
control systems to IT timeframes. For OT security, start with NIST SP 800-82 Rev. 3[^sp800-82] (Rev. 4 in public draft since
September 2026) and [IoTOps](../iotops/).

## Measure, govern, pay

### Metrics and KPIs

NIST warns that "Overly simplistic metrics", such as an estate-wide percentage patched, "are not actionable", and proposes on-time
percentage, mean and median time per cell of asset importance × vulnerability importance[^sp800-40]. The scorecard below (Annex C in
[Artefact 1](#reference-implementation)) does that and adds measures of the contract (formulas are the Atlas's).

| KPI | Formula | Pitfall | Cadence |
|---|---|---|---|
| On-time remediation | Items closed by due date ÷ items due, per importance × urgency cell | Open overdue items must count as missed | Monthly |
| Time to remediate | Median and 90th percentile, detection to verified fix; open overdue items at current age | "MTTR" here means *remediate*, not restore (see [IncidentOps](../incidentops/)) | Monthly |
| Unowned findings | Findings on assets without an owner group ÷ open findings | Zero can mean the scanner misses unowned assets | Weekly |
| Baseline conformance | Passing applicable rules ÷ applicable rules, per group and baseline version | Tailored-away rules are not "passing"; report exceptions separately | Monthly |
| Exception health | Exceptions past review date ÷ open exceptions; median age | A falling count can mean exceptions granted outside the register | Quarterly |
| Telemetry coverage | Inventory assets with healthy agents and required logs in 24 hours ÷ inventory assets | Take the denominator from the inventory, not the tool | Weekly |
| Security-change disruption | Incidents caused by security changes ÷ security changes | Without it, speed targets breed distrust | Monthly |

**Worked calculation (illustrative numbers).** In September 240 findings fell due and 198 closed on time: **82.5%**. The aggregate hides
the problem: internet-facing/high was 38 of 40 (**95%**) but datacentre/high 45 of 60 (**75%**), because the data-platform team had no
change window that month. Unowned findings: 18 of 600 (**3%**). Exceptions past review: 6 of 35 (**17%**). Telemetry coverage: 1,540 of
1,600 (**96.25%**); the missing 60 were a newly acquired subsidiary's servers, which no scanner saw either. Disruption: 3 incidents from
120 security changes (**2.5%**), all from one baseline pushed estate-wide without a pilot ring. The review gives data-platform a standing window and
onboards the subsidiary.

**Targets.** Measure for two or three months, then set targets per cell. Unowned findings, coverage and overdue exceptions lead;
on-time remediation and incidents lag. Never reward counts of closed tickets.

### Quality, security and compliance

- **Privileged tooling:** see [trust boundaries](#reference-architecture); access reviews are [AccessOps](../accessops/).
- **Evidence:** auditors ask for the register, change records and rescans; framework mapping is [ComplianceOps](../complianceops/).
- **Logs carry risk:** "those logs may be a valuable target for an attacker"[^bsrs1]; keep secrets and unnecessary personal data out
  ([PrivacyOps](../privacyops/)).

### Cost and capacity

- **Remediation is planned work:** 300 findings a month at an hour each is close to two full-time administrators. Unreserved, that
  capacity loses to projects every time.
- **SIEM ingestion** is often priced by data volume; Sentinel's analytics tier bills by GB or by daily commitment tiers[^sentinel-billing].
- **Exceptions carry costs** (compensating controls, isolation, extended support); record them so the business owner sees them at
  renewal.

### Assurance of the operating model

Check that the controls work: scanner and agent **coverage** against the inventory, weekly; **tool health**, including certificate
expiry (the Equifax failure); **closure quality**, sampling ten closed tickets a quarter; **register integrity**, checking sampled
compensating controls exist; and a yearly **tabletop** of the emergency path and Annex D.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Findings age untouched | Unwatched queue or no owner | Unowned-findings report | Re-route; name champions | CMDB routing; weekly review |
| A baseline change breaks an application | Enforced estate-wide, no pilot ring or log-only phase | Change calendar; denial logs | Narrow allow-list or roll back (runbook below) | Pilot rings; log-only mode where offered |
| Exceptions grow every quarter | No expiry, no cost shown | Register age distribution | Re-approve with cost and exit criteria | Maximum lifetime |
| Operations ignores security tickets | Noise; no say in timeframes | Share closed as "not applicable" | Tune sources; agree timeframes | Dispute route with evidence ([Artefact 1](#reference-implementation); practice on [VulnerabilityOps](../vulnerabilityops/)); joint scorecard |
| Detections fire on planned work | SOC not told of changes | Alerts versus change calendar | Share the calendar | Change records feed detections |
| Security tool silently stops | Expired certificate or credential | Heartbeat and coverage reports | Restore; backfill scans | Operations-owned health checks |

### Worked runbook: hardening enforcement blocks a legacy system

Use this when a newly enforced hardening change breaks a business system. The example is Netlogon[^netlogon]; the steps fit legacy
TLS, SMB signing or NTLM restrictions too.

::: figure Runbook: a hardening change blocks a system
```mermaid
flowchart TB
  A["System fails after enforcement"] --> B["Declare incident, link the change"]
  B --> C{"Denial events match the system?"}
  C -- "No" --> D["Not this change: normal incident path"]
  C -- "Yes" --> E{"Can enforcement be rolled back?"}
  E -- "Yes, low risk" --> F["Roll back the rule for one stage"]
  E -- "No, or rollback reopens risk" --> G["Add system to the allow-list group"]
  F --> H["Register entry: owner, control, review date"]
  G --> H
  H --> I["Verify service and denial logs"]
  I --> J["Fix or retire the system; shrink allow-list"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A risk
  class B,F,G,H,I,J core
  class C,E decision
  class D risk
```
Text equivalent: Declare an incident and link the change. If denial events do not match the failing system, follow the normal
incident path. If they do, roll back one stage when low-risk, else allow-list the system; then record a register entry, verify, and
fix or retire the system to shrink the allow-list.
:::

1. **Declare and link.** Open an incident ([IncidentOps](../incidentops/)) and link the latest security change. On-call operations
   leads; security joins.
2. **Confirm the cause.** Look for denial events naming the failing system (for Netlogon, Microsoft documents 5827/5828 for denied
   and 5830/5831 for policy-allowed connections[^netlogon]):

_Example status: PowerShell, not executed for this page (no Windows domain available); event IDs from Microsoft's documentation._

```powershell
# On each domain controller, last 24 hours:
# denied (5827, 5828) and policy-allowed (5830, 5831) Netlogon connections
$filter = @{
  LogName   = 'System'
  Id        = 5827, 5828, 5830, 5831
  StartTime = (Get-Date).AddDays(-1)
}
Get-WinEvent -FilterHashtable $filter |
  Select-Object TimeCreated, Id, Message | Format-List
```

3. **Choose the lever.** Roll back only if that does not reopen the risk for the whole estate and the vendor allows it; after
   Netlogon's enforcement phase it was not possible[^netlogon]. Otherwise allow-list the one system:

_Example status: PowerShell, not executed; group name is a placeholder; the cmdlet pattern follows Microsoft's article._

```powershell
# Add only the failing machine account to the allow-list group in the policy
Add-ADGroupMember -Identity 'Netlogon-Allow-Vulnerable-Exception' `
  -Members 'PAYROLL-APP01$'
```

4. **Record** a register entry the same day: system, reason, compensating control (for example, network access to the domain
   controllers only), risk owner, review date. Allowed accounts stay at risk[^netlogon].
5. **Verify.** The service works; denials stop for that system; allowed events appear for it and nothing else.
6. **Close the loop.** Ticket the owner to update or retire the system; ask why the log-only phase or pilot ring missed it
   (usually a monthly or quarterly job).

### Anti-patterns and myths

- **Reports over the wall:** 4,000 findings in a spreadsheet, nothing owned, dated or verified. Route tickets with due dates instead.
- **Patching what will be replaced.** A fix made inside a running container or image-built host vanishes at the next redeploy.
- **"The SOC will catch it."** Detection depends on telemetry that operations keeps healthy.
- **Security tools outside change control** (the July 2024 case).
- **Myth: a "SecOps" platform delivers SecOps.** A SIEM or SOAR supports the SOC; it defines no owners, timeframes or exceptions.

## Deciding and adopting

### When to use and when not to use

**Use a formal contract when** security and IT operations are separate teams; findings miss their dates; outages are blamed on
security changes; auditors ask for a configuration standard and remediation evidence; or a vendor enforcement date looms.

**Keep it light, or do something else first, when:**

- **One small team does both jobs.** A one-page list of baselines, a monthly patch window and a register are enough.
- **There is no usable asset inventory.** Routing and metrics will be fiction; build ownership first with [ITOps](../itops/).
- **The estate is almost all SaaS.** Most of the work is identity and SaaS configuration; see [IdentityOps](../identityops/) and
  [CloudSecOps](../cloudsecops/).
- **The real problem is detection.** If incidents go unnoticed, start with [SOC Ops](../soc-ops/) and [DetectionOps](../detectionops/).

Hidden cost: maintaining routing rules, chasing review dates and publishing the scorecard; the Atlas estimates a part-time role.

### Decision framework

::: figure Choosing a SecOps operating model
```mermaid
flowchart TB
  A{"Separate security and ops teams?"} -- "No" --> B["One team: light checklist and register"]
  A -- "Yes" --> C{"Inventory with owners?"}
  C -- "No" --> D["Build ownership first (ITOps)"]
  C -- "Yes" --> E{"Over about 500 assets or several owner groups?"}
  E -- "No" --> F["Central SecOps lead plus one shared queue"]
  E -- "Yes" --> G{"Ops teams own their platforms end to end?"}
  G -- "Yes" --> H["Embedded champions plus paved roads"]
  G -- "No" --> I["Central posture team plus routing rules"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class A,C,E,G decision
  class B,D neutral
  class F,H,I core
```
Text equivalent: One combined team: a light checklist and register. Separate teams without an owned inventory: build ownership
first (ITOps). Under about 500 assets and few owner groups: a central SecOps lead and one shared queue. Larger estates: embedded
champions and paved roads where operations teams own their platforms end to end, else a central posture team with routing rules.
:::

The 500-asset threshold is the Atlas's rule of thumb, not a standard. Weighted comparison of the models (scores 1–3, higher is better
for the criterion; weights are assumptions to change):

| Criterion (weight) | Central lead + shared queue | Central posture team | Embedded champions + paved roads | Merged team |
|---|---|---|---|---|
| Cost to start (3) | 3 | 2 | 2 | 1 |
| Scales to many owner groups (3) | 1 | 2 | 3 | 2 |
| Independence of security judgement (2) | 3 | 3 | 2 | 1 |
| Speed of routine fixes (2) | 2 | 2 | 3 | 3 |
| **Weighted total** | **22** | **22** | **25** | **17** |

The central models tie; estate size breaks it. The merged team scores low on independence: when one manager owns uptime and
exposure, the business stops seeing the trade-off (a judgement, not a measurement).

### Maturity model

This is **the Atlas's model**; no official SecOps maturity model exists.

| Level | Observable behaviour | Exit criteria |
|---|---|---|
| 0 Ad hoc | Findings by email or spreadsheet; verbal exceptions | A named SecOps lead; owner fields in the inventory |
| 1 Defined | Written agreement, chosen baselines, a register | 90% of findings routed to an owner automatically |
| 2 Managed | Shared queue, timeframes per group, weekly review | Scorecard published three months running |
| 3 Measured | Per-cell metrics and the disruption rate drive decisions | Under 10% of exceptions past review; every enforcement went through a pilot ring or log-only phase |
| 4 Adaptive | Paved roads replace tickets; vendor dates tracked; drills run | Sustained; reviewed yearly |

### Adoption roadmap: 30/60/90 days

| Window | Actions | Owners | Milestone and metric |
|---|---|---|---|
| Days 1–30 | Sign the agreement; add owner and maintenance-group fields to the CMDB; pick baselines; start the register | Both heads; CMDB owner | Quick wins: unowned-asset list; baseline catalogue v1 |
| Days 31–60 | Route scanner findings to owner queues; agree timeframes; first conformance scan, then a pilot ring on one group; weekly reviews | SecOps lead; champions | 80% of new findings auto-routed |
| Days 61–90 | First scorecard and exception review; enforce the first baseline in stages; sign Annex D; tabletop the emergency path | Both heads; business owners | Scorecard v1; one baseline enforced without incident |

## Toolkit

### Checklists

#### Quick start

- [ ] A signed one-page agreement: who sets baselines, applies them, accepts risk and may contain
- [ ] A named baseline, profile and version per asset class
- [ ] Owner, maintenance-group and exposure fields in the CMDB; a weekly unowned-asset report
- [ ] Findings arrive as owner-queue tickets with due dates
- [ ] Register entries have mandatory fields and review dates

#### Before enforcing a hardening change

- [ ] Tested outside production on the same image
- [ ] Log-only mode (if the control has one) or a pilot ring ran through a business cycle, including month-end jobs
- [ ] Every client that would be blocked is fixed, retired or allow-listed with a register entry
- [ ] Change raised; rollback, backup or allow-list lever rehearsed
- [ ] SOC and service desk told the date

#### Routine reviews

- [ ] Unowned findings routed
- [ ] Items due in 14 days have a change booked
- [ ] Overdue items have either a new plan or an exception request
- [ ] Security tooling coverage and heartbeat checked
- [ ] Quarterly: expired exceptions decided; compensating controls spot-checked

### Templates

**One-page agreement:** [Artefact 1](#reference-implementation), plus signatures and annexes.

**Exception request form.**

_Example status: template, not executed._

```text
Exception request                                    Id: EX-____
Asset or group (narrowest scope):
Baseline rule or finding:
Why the fix cannot be done by the due date:
Impact of the deviation (what an attacker could do):
Compensating controls (each verifiable):
Cost of the exception per year (controls, support, isolation):
Requested by (team):               Risk accepted by (business owner):
Review date (max 6 months):        Exit criteria:
Security advice:  [ ] support  [ ] support with conditions  [ ] advise against
```

**Architecture decision record: choosing a baseline.**

_Example status: template, not executed._

```text
ADR-007    Baseline for Ubuntu servers
Status:    accepted, 2026-10-16
Context:   400 servers, mixed workloads; auditors ask for a configuration
           standard.
Options:   (a) CIS Level 1 Server  (b) CIS Level 2 Server
           (c) vendor defaults plus our own list
Decision:  (a), tailored; Level 2 only for the payment zone after a 60-day
           pilot ring.
Because:   Level 1 is designed for limited performance impact;
           Level 2 may affect operations.
Deviations: listed in tailor.xml, each tagged with an exception id.
Review:    yearly, or when CIS publishes a new major version.
```

### Deep comparisons

| | SecOps (this page) | [VulnerabilityOps](../vulnerabilityops/) | [SOC Ops](../soc-ops/) | [ITOps](../itops/) |
|---|---|---|---|---|
| Central question | Who fixes what, by when, and who may say not now? | What must be fixed first? | Is something bad happening now? | Is this change safe to make? |
| Main artefacts | Baselines, register, timeframe matrix, containment list, scorecard | Urgency classes, SLA policy | Alerts, cases, playbooks | Change records, CMDB |
| Fails when | Nobody owns the queue or the exceptions | Arrivals outrun fixes | Telemetry is missing or noisy | Change control blocks urgent fixes |

### FAQ

**Do we need to merge security and operations?** No. Some vendors define SecOps that way[^crowdstrike], but a written contract gets
the outcome without a reorganisation, provided a business owner, not either team alone, accepts risk.

**How strict should our baseline be?** Start with CIS Level 1 or a vendor baseline, tailored and tested, and apply stricter profiles
where the risk justifies the operational cost[^cis-faq].

**Our timeframes are always missed. Shorten them?** Not without capacity. Check the per-cell data: usually one group lacks a change
window or people.

**What if a vendor forces an enforcement date?** Make it an operations-owned milestone, collect the vendor's would-be-denial events
at once, and use the allow-list only as a short bridge[^netlogon].

**Is an MDR provider enough?** It covers monitoring, triage and, within the authority you grant ([Annex D](#reference-implementation)),
containment; remediation, hardening and risk acceptance remain yours.

## Going further

### Advanced topics and emerging direction

- **Risk-based remediation clocks.** BOD 26-04 derives federal timeframes from exposure, KEV status, exploit automation and technical
  impact[^bod2604]; elsewhere it is a model to borrow, not an obligation.
- **Continuous configuration monitoring.** SP 800-70 Rev. 5 wants checklists "incorporated into continuous monitoring"[^sp800-70],
  so drift between scheduled scans is routed like any other finding.
- **Exposure management** is, in the Atlas's assessment, an analyst and vendor category, not a standard. Microsoft says its
  exposure graph aligns with "Gartner's Continuous Threat Exposure Management (CTEM) approach"; its product merges asset discovery
  across endpoints, cloud and the external attack surface, marks critical assets and draws attack paths[^ms-em]. Use such tools to
  reconcile the CMDB and to give [VulnerabilityOps](../vulnerabilityops/) attack-path context; judge them by what reaches owner queues.

### Learning path

| Stage | Do this |
|---|---|
| Prerequisites | [ITOps](../itops/) basics; [VulnerabilityOps](../vulnerabilityops/) basics |
| 1-day primer | CIS Benchmarks FAQ, NIST SP 800-40 Rev. 4 section 3, the RACI; Lab 1 |
| 1-week practice | Lab 2 on a throwaway VM; a tailoring file for two real exceptions; a draft timeframe matrix |
| 30 days | Route one scanner into owner queues; four weekly reviews; a first scorecard |
| Specialisation | [SysOps](../sysops/), [EndpointOps](../endpointops/), [CloudSecOps](../cloudsecops/), [SOC Ops](../soc-ops/) |
| Portfolio | An agreement, a versioned tailoring file and a three-month scorecard for a lab estate |

## Wrap-up

### Executive recap and cheat sheet

| Area | Remember |
|---|---|
| Decide | Who sets baselines (security), applies them (operations), accepts risk (business owner), may contain at night (Annex D) |
| Practise | One queue keyed on owners (image owners for rebuilt assets); log-only or pilot ring, allow-list, then enforce |
| Measure | On-time remediation per cell, unowned findings, exception health, coverage, disruption |
| Watch out | Exceptions forever, big-bang hardening, one estate-wide number |
| Next | Sign the agreement, publish the unowned-asset list, date every exception |

### A judgement call: patch the exploited gateway tonight?

::: decision Illustrative dilemma
**Situation.** Friday 16:00. The only remote-access gateway runs a version the vendor says is exploited in the wild; the fix needs a
reboot. Finance works remotely on month-end close until Sunday. Operations proposes the Sunday 02:00 window; security wants the patch
now.

**Option A: patch now.** Closes the hole within an hour, but may interrupt month-end, and an untested patch may fail.
**Option B: wait for Sunday.** No disruption, but an exploited flaw stays exposed for about 34 hours.

**Assumptions.** Exploitation is automated; the gateway faces the internet; the vendor publishes a mitigation (disable the vulnerable
feature) that needs no reboot; a compromise would expose the whole network.

**Reasoning.** Option B feels responsible because the business cost is visible and the attack is not, yet 34 hours is long against
automated exploitation; Option A treats the patch as risk-free. A third option is better: **apply the mitigation now** on the
emergency route, patch on Sunday, and ask [ResponseOps](../responseops/) for a compromise check. That is NIST's "emergency
mitigation" scenario[^sp800-40], quick only because the plan existed before Friday.

**Uncertainty.** Without a mitigation, the question is whether a short, announced outage costs less than the risk. The Head of IT
ops times it inside the two-day emergency timeframe; waiting longer is risk acceptance for the business owner of remote access.
:::

### Learning objectives and mastery check

You should now be able to **explain** the three meanings of SecOps, **design** a RACI and timeframe matrix, **operate** a register and
the log-or-pilot-then-enforce pattern, and **evaluate** remediation with per-cell metrics.

::: answer 1. A colleague says "SecOps owns our SIEM". Which meaning is that, and where does the Atlas teach it?
The SOC meaning (meaning 2), taught on SOC Ops; this page covers only what operations owes the SOC.
:::

::: answer 2. Who should accept the risk of keeping TLS 1.0 on a payroll connector, and why not security?
The payroll business owner, who bears the consequence. Security advises and records; operations proposes the compensating control.
:::

::: answer 3. 92% of findings were closed on time last quarter. What two questions do you ask?
Which cells (asset importance × urgency) make up the 8%, and were open overdue items counted? NIST notes that estate-wide percentages
are not actionable.
:::

::: answer 4. Name two Equifax failures that a SecOps contract addresses directly.
Notices sent to an out-of-date recipient list instead of routed by asset owner; separate, incomplete inventories in IT and
security.
:::

::: answer 5. A CIS audit of production shows 40 failing rules. Has it shown that enforcing them is safe?
No. A conformance assessment changes nothing, so it cannot show what enforcement would break. Test off production, then use a log-only
mode if the control has one, otherwise a pilot ring with a cooling-off period, rollback ready.
:::

::: answer 6. Web servers are rebuilt weekly from a golden image. A scan flags a vulnerable library on 40 of them. Who gets the ticket, and when does it close?
The image owner, not the operators of the 40 instances. It closes when the rebuilt image scans clean and no instance of the old
image still runs.
:::

### Conclusion

"SecOps" names three things: a way of working, a team and a product. The first meaning addresses a real, well-documented problem:
security and operations guard against different failures, and the fixes for one are changes that risk the other.

The answer is neither a new team nor a new tool but a contract written before the emergency: governed baselines, one queue keyed
on owners, resourced timeframes, signed exceptions that expire, pre-agreed containment and shared numbers. Equifax shows the cost of
its absence; Netlogon shows a staged version working. The test: when the next exploited flaw lands on a Friday afternoon, does
everyone already know who decides?

## Sources and further reading

[^pd]: [What is SecOps?](https://www.pagerduty.com/resources/security/learn/secops/) — PagerDuty, 2024-07-29 (updated 2025-03-27). Checked 2026-10-16.
[^elastic]: [What is SecOps?](https://www.elastic.co/what-is/secops) — Elastic, undated. Checked 2026-10-16.
[^crowdstrike]: [What is SecOps?](https://www.crowdstrike.com/en-us/cybersecurity-101/next-gen-siem/secops/) — Bart Lenaerts-Bergmans, CrowdStrike, 2024-05-23. Checked 2026-10-16.
[^techtarget]: [What is SecOps? Everything you need to know](https://www.techtarget.com/cybersecurity/definition/What-is-SecOps-Everything-you-need-to-know) — Sandra Gittlen, TechTarget, 2020-12-22. Checked 2026-10-16.
[^ms-caf]: [Security teams, roles, and functions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/teams-roles) — Microsoft Cloud Adoption Framework, updated 2025-12-04. Checked 2026-10-16.
[^gsecops]: [Google Security Operations](https://cloud.google.com/security/products/security-operations) — Google Cloud, product page. Checked 2026-10-16.
[^gsecops-rebrand]: [Chronicle Security Operations has been rebranded to Google Security Operations](https://security.googlecloudcommunity.com/google-security-operations-2/chronicle-security-operations-has-been-rebranded-to-google-security-operations-1116) — Google Cloud Community (Google staff post), 2024-04-25. Checked 2026-10-16.
[^bmc2016]: [BMC and Forbes Insights survey press release](https://www.bmc.com/newsroom/releases/bmc-and-forbes-insights-survey-reveals-known-vulnerabilities-are.html) — BMC, 2016-01-12. Checked 2026-10-16.
[^sp800-40]: [SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final) — Souppaya and Scarfone, NIST, April 2022. Checked 2026-10-16.
[^sp800-70]: [SP 800-70 Rev. 5, National Checklist Program for IT Products](https://csrc.nist.gov/pubs/sp/800/70/r5/final) — Quinn and Heiserman, NIST, May 2026. Checked 2026-10-16.
[^sp800-128]: [SP 800-128, Guide for Security-Focused Configuration Management](https://csrc.nist.gov/pubs/sp/800/128/upd1/final) — Johnson et al., NIST, 2011, updated 2019. Checked 2026-10-16.
[^csf2]: [The NIST Cybersecurity Framework 2.0](https://doi.org/10.6028/NIST.CSWP.29) — NIST CSWP 29, 2024-02-26. Checked 2026-10-16.
[^sp800-82]: [SP 800-82 Rev. 3, Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final) — NIST, September 2023. Checked 2026-10-17.
[^nist-gl]: [Glossary search for "SecOps"](https://csrc.nist.gov/glossary?keywords-lg=secops) — NIST CSRC, no results. Checked 2026-10-16.
[^nist-siem]: [SIEM tool](https://csrc.nist.gov/glossary/term/security_information_and_event_management_tool) — NIST CSRC Glossary, from SP 800-128. Checked 2026-10-16.
[^cis-bench]: [CIS Benchmarks List](https://www.cisecurity.org/cis-benchmarks) — CIS, live page. Checked 2026-10-16.
[^cis-faq]: [CIS Benchmarks FAQ](https://www.cisecurity.org/cis-benchmarks/cis-benchmarks-faq) — CIS. Checked 2026-10-16.
[^cis-4]: [Control 4: Secure Configuration](https://cas.docs.cisecurity.org/en/latest/source/Controls4/) — CIS Controls Assessment Specification v8.1. Checked 2026-10-16.
[^cis-7]: [Control 7: Continuous Vulnerability Management](https://cas.docs.cisecurity.org/en/latest/source/Controls7/) — CIS Controls Assessment Specification v8.1. Checked 2026-10-16.
[^cis-8]: [Control 8: Audit Log Management](https://cas.docs.cisecurity.org/en/latest/source/Controls8/) — CIS Controls Assessment Specification v8.1. Checked 2026-10-16.
[^cis-ig]: [CIS Critical Security Controls Implementation Groups](https://www.cisecurity.org/controls/implementation-groups) — CIS. Checked 2026-10-17.
[^kev]: [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) — CISA, live catalogue. Checked 2026-10-17.
[^cisa-rw]: [#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) — CISA, MS-ISAC, NSA and FBI, September 2023. Checked 2026-10-17.
[^bod2604]: [BOD 26-04: Prioritizing Security Updates Based on Risk](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) — CISA, 2026-06-10. Checked 2026-10-16.
[^gao]: [GAO-18-559, Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach](https://www.gao.gov/products/gao-18-559) — U.S. GAO, 2018-08-30. Checked 2026-10-16.
[^house]: [The Equifax Data Breach, majority staff report](https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf) — U.S. House Committee on Oversight and Government Reform, December 2018. Checked 2026-10-16.
[^netlogon]: [Managing Netlogon secure channel changes for CVE-2020-1472](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e) — Microsoft Support, 2020. Checked 2026-10-17.
[^cs-hub]: [Falcon Content Update Remediation and Guidance Hub](https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/) — CrowdStrike, updated 2024-08-06. Checked 2026-10-16.
[^bsrs1]: [Building Secure and Reliable Systems, chapter 1](https://google.github.io/building-secure-and-reliable-systems/raw/ch01.html) — Adkins et al., Google and O'Reilly, 2020. Checked 2026-10-16.
[^bsrs20]: [Building Secure and Reliable Systems, chapter 20](https://google.github.io/building-secure-and-reliable-systems/raw/ch20.html) — Adkins et al., 2020. Checked 2026-10-16.
[^usg-install]: [Install Ubuntu Security Guide](https://documentation.ubuntu.com/security/compliance/usg/install-usg/) — Canonical. Checked 2026-10-16.
[^usg-bench]: [CIS Benchmarks and profiles](https://documentation.ubuntu.com/security/compliance/usg/cis-benchmarks/) — Canonical, updated 2026-01-22. Checked 2026-10-16.
[^usg-audit]: [Auditing an Ubuntu system for CIS Benchmarks compliance](https://documentation.ubuntu.com/security/compliance/usg/cis-audit/) — Canonical. Checked 2026-10-16.
[^usg-custom]: [Customizing CIS Benchmarks profiles](https://documentation.ubuntu.com/security/compliance/usg/cis-customize/) — Canonical, updated 2026-01-22. Checked 2026-10-16.
[^cac]: [ComplianceAsCode Ubuntu 24.04 CIS Level 1 Server profile](https://github.com/ComplianceAsCode/content/blob/master/products/ubuntu2404/profiles/cis_level1_server.profile) — ComplianceAsCode project. Checked 2026-10-16.
[^oscap]: [OpenSCAP User Manual](https://static.open-scap.org/openscap-1.3/oscap_user_manual.html) — OpenSCAP project. Checked 2026-10-16.
[^wazuh]: [Getting started with Wazuh](https://documentation.wazuh.com/current/getting-started/index.html) — Wazuh. Checked 2026-10-16.
[^wazuh-sca]: [Security Configuration Assessment](https://documentation.wazuh.com/current/user-manual/capabilities/sec-config-assessment/index.html) — Wazuh. Checked 2026-10-16.
[^ms-asr]: [Test your ASR rules deployment](https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-deployment-test) — Microsoft Learn, updated 2026-07-02. Checked 2026-10-17.
[^rh-selinux]: [Getting started with SELinux, RHEL 9](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/getting-started-with-selinux_using-selinux) — Red Hat Documentation. Checked 2026-10-17.
[^ms-sct]: [Microsoft Security Compliance Toolkit](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/security-compliance-toolkit-10) — Microsoft Learn, updated 2025-08-18. Checked 2026-10-16.
[^sentinel]: [What is Microsoft Sentinel SIEM?](https://learn.microsoft.com/en-us/azure/sentinel/overview) — Microsoft Learn, updated 2026-01-28. Checked 2026-10-16.
[^sentinel-billing]: [Microsoft Sentinel pricing and billing](https://learn.microsoft.com/en-us/azure/sentinel/billing) — Microsoft Learn, updated 2026-04-01. Checked 2026-10-16.
[^ubuntu-pro]: [Ubuntu Pro](https://ubuntu.com/pro) — Canonical, live product page. Checked 2026-10-17.
[^sp800-61]: [SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management](https://csrc.nist.gov/pubs/sp/800/61/r3/final) — Nelson et al., NIST, April 2025. Checked 2026-10-17.
[^sp800-190]: [SP 800-190, Application Container Security Guide](https://csrc.nist.gov/pubs/sp/800/190/final) — Souppaya, Morello and Scarfone, NIST, September 2017. Checked 2026-10-17.
[^ms-em]: [What is Microsoft Security Exposure Management?](https://learn.microsoft.com/en-us/security-exposure-management/microsoft-security-exposure-management) — Microsoft Learn, updated 2025-07-30. Checked 2026-10-17.
[^sn-assign]: [Vulnerability Response assignment rules overview](https://www.servicenow.com/docs/r/9rlb2awQeTeY3Z9jGMo5DQ/apCbvQ2wyvgK43JZOmKtCA) — ServiceNow Docs, Yokohama release, updated 2026-04-07. Checked 2026-10-17.

**Changelog**

- 2026-10-16 — r0: first version; `ambiguous`, three documented meanings; Labs 1 and 3 executed, Lab 2 and runbook not executed.
- 2026-10-17 — r1 (`reviews/secops-r1-response.md`): conformance scans, log-only modes and pilot rings separated; VulnerabilityOps,
  PatchOps and RiskOps split; Netlogon, BOD 26-04, CrowdStrike and CIS facts corrected; routing widened.
- 2026-10-17 — r2 (`reviews/secops-r2-response.md`): containment authority (Annex D, RACI row); rebuilt, image-based estates; BOD
  26-04 triage rows; exposure management; code rewrapped for the desktop column; Labs 1 and 3 re-run.
- 2026-10-17, post-score polish: dispute route, Annex C, use-case success measures, reading routes, two source caveats,
  Figures 1–2 (`reviews/secops-polish.md`).