SecOps

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). Where to start: beginners, the glossary and Lab 1; engineers, the reference implementation and runbook; leaders, the RACI, metrics and decision framework.

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.”^[9] 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.”^[9]

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.

• Not the SOC (SOC Ops). This page keeps one section on what operations owes the SOC.
• Not DevSecOps: pipeline controls are DevSecOps; SecOps starts where systems run.
• Not vulnerability management or patch rollout. VulnerabilityOps sets urgency classes, remediation-SLA policy and the criteria for vulnerability exceptions; PatchOps turns maintenance groups into plans and rollouts; 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) or incident command (IncidentOps).
• Not applying baselines: SecOps chooses and governs them; SysOps, EndpointOps, KubernetesSecOps and CloudSecOps apply them.

There is no founding document. Explainers describe SecOps by analogy with DevOps^[6], and a January 2016 BMC press release already described “a significant gap between the security and IT operations (SecOps) teams”^[10]. The practices are older: configuration checklists (NIST SP 800-70, Rev. 5 since May 2026^[11]; CIS Benchmarks^[12]), configuration management (SP 800-128^[13]) and patch management^[9].

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.”^[19] 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.

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

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”^[9]. 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”^[13]; 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).
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^[11]; CSF 2.0 lists it as outcome ID.RA-07^[21].
5. Hardening is a change. A conformance scan cannot show what enforcement would break. Test on a non-production system first^[14][11]; 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”^[11], with rollback or a backup ready. Where the vendor made enforcement safe, enforce at once (playbook).
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”^[22].

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

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

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^[22]; in operations, a senior administrator who reviews security tickets weekly.

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

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

The yearly-or-on-change review follows CIS Safeguard 4.1^[23]. 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.

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.

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

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^[25].

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”^[26]. 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 and ContainerOps.

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

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^[9]. If compromise is plausible, involve 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^[27].

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”^[28].

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”^[15].
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.

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

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

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

The SOC is taught on 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^[30]. IG1, “essential cyber hygiene”^[37], 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). Pipelines and ingest costs belong to SecDataOps.

NIST’s third patch-management principle is “Rely on automation”^[9]; 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^[8]. 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).

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

Example status: illustrative text, not executed.

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

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.

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^[38]. SecOps records which actions operations accepts unasked, how the owner hears and how each is undone; SOC Ops and ResponseOps carry them out.

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

# 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

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.

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.

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

#!/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):

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.

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^[39]; personal use is free “on up to 5 physical machines”^[40]). A plain pro attach also enables ESM repositories and the Livepatch snap^[39]; --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.

# 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^{[39][41][33][42]}. 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”^[42]; 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.

Objective. Route findings to owners with due dates, flag unowned assets, and compute NIST-style on-time remediation by asset importance and urgency^[9]. Urgency is an input (see 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.

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.

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

#!/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:

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.

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”^[43]. 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^[44]. 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”^[45]. Success measure: every update channel of every security agent has a named owner and rings (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).

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^[9]: 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^[46] (Rev. 4 in public draft since September 2026) and IoTOps.

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^[9]. The scorecard below (Annex C in Artefact 1) does that and adds measures of the contract (formulas are the Atlas’s).

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.

• Privileged tooling: see trust boundaries; access reviews are AccessOps.
• Evidence: auditors ask for the register, change records and rescans; framework mapping is ComplianceOps.
• Logs carry risk: “those logs may be a valuable target for an attacker”^[19]; keep secrets and unnecessary personal data out (PrivacyOps).

• 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^[47].
• Exceptions carry costs (compensating controls, isolation, extended support); record them so the business owner sees them at renewal.

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.

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

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

1. Declare and link. Open an incident (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^[28]):

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

# 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^[28]. Otherwise allow-list the one system:

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

# 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^[28].
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).

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

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.
• The estate is almost all SaaS. Most of the work is identity and SaaS configuration; see IdentityOps and CloudSecOps.
• The real problem is detection. If incidents go unnoticed, start with SOC Ops and DetectionOps.

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

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

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):

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

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

• 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

• 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

• 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

One-page agreement: Artefact 1, plus signatures and annexes.

Exception request form.

Example status: template, not executed.

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.

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.

Do we need to merge security and operations? No. Some vendors define SecOps that way^[6], 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^[14].

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^[28].

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

• Risk-based remediation clocks. BOD 26-04 derives federal timeframes from exposure, KEV status, exploit automation and technical impact^[27]; elsewhere it is a model to borrow, not an obligation.
• Continuous configuration monitoring. SP 800-70 Rev. 5 wants checklists “incorporated into continuous monitoring”^[11], 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^[48]. Use such tools to reconcile the CMDB and to give VulnerabilityOps attack-path context; judge them by what reaches owner queues.

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.

“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?

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