Your monitoring stack flags four thousand events a night and the team closes the twelve that matter before breakfast. Then a vulnerability scan arrives in the same queue as a normal ticket: nine hundred lines, no owner, and a note that says “review”. That spreadsheet is where most operations groups first meet the word SecOps, and the meeting goes badly because nobody in the room agrees on what the word actually names.

Start with the honest answer: the term is not settled. NIST’s glossary has no entry for SecOps — The Ops Atlas checked in October 2026 and came back empty. Writers use it in at least three ways. Some mean the collaboration between security staff and IT operations; PagerDuty and Elastic both use the word that way. Microsoft’s Cloud Adoption Framework treats it as roughly another name for the Security Operations Center. And Google sells a product called SecOps, which is what happened when Chronicle was renamed in April 2024. This primer follows the Atlas, which picks the first meaning on purpose: SecOps is a working contract between security and operations — agreed hardening baselines, one remediation queue that somebody owns, deadlines matched to real resources, exceptions that expire, and numbers both sides read together.

It is not a new invention either. BMC’s January 2016 press release had already named a “SecOps gap” a decade before the word went mainstream. The underlying practices trace to older NIST work: SP 800-70 on configuration checklists, SP 800-128 on configuration management, and SP 800-40 Rev. 4 on patching. What is new is the discipline of writing the arrangement down instead of assuming goodwill will carry it.

What the SecOps contract covers, and what it does not

The Atlas draws the boundary precisely, and it helps to copy that boundary onto your own team chart. Inside scope: who governs the hardening baseline and how exceptions are approved; how a finding gets routed to a named owner; what timeframes each owner group is resourced to meet; where the shared register of commitments lives; how security changes get change windows like any other work; which telemetry and containment duties operations owes the monitoring side; and which metrics both teams answer for.

Outside scope, because other terms own those problems: the detection engineering and incident response that happen inside a SOC; urgency scoring; patch rollout mechanics; formal risk acceptance; controls embedded in delivery pipelines, which belong to DevSecOps; and the fleet-wide application of baselines, which is SysOps or endpoint work. An AIOps team sits close to several of those borders, which is exactly why the clarity pays off — your platform may host the routing rules without owning any of them.

A SecOps mini-glossary for the operations desk

• Baseline — the written configuration standard a system must meet, borrowed from a benchmark rather than invented.
• Tailoring — the recorded decisions that adapt a baseline to your estate, kept in a file so the reasoning survives staff turnover.
• Log-only mode — a control deployed to observe and record instead of block, the standard first step before enforcement.
• Pilot ring — a small group of machines that receives a change first, with a cooling-off period before wider rings follow.
• Drift — the quiet movement of real configurations away from the approved baseline between reviews.
• Remediation queue — the single list of findings with owners and dates; if there are two lists, there are none.
• Exception — a documented, expiring permission to stay unremediated, reviewed on a schedule.
• Telemetry duty — the logging, sync, and retention work operations owes the security side, defined as a deliverable.

How the SecOps lifecycle actually runs

The working cycle mirrors the four phases of SP 800-128. Select a benchmark such as the CIS Benchmarks or a DISA STIG. Tailor it, recording every deviation and why. Test the settings somewhere that is not production. Then ship in log-only mode or to a pilot ring, let it cool off, and enforce ring by ring. After enforcement comes drift monitoring, and the year closes with a review that retires stale rules. Microsoft’s own guidance admits one shortcut: standard-protection attack-surface rules can usually move to Block or Warn “without testing”, which is the exception that proves the rule about piloting everything else.

Operations should read that sequence as familiar. It is a canary release for configuration, and the same instincts that make a deploy safe make a hardening change safe.

The half of the contract operations owes

The contract runs both directions, and CIS Control 8 prices the security side of it. At Implementation Group 1 the duties are basic: a logging process, audit logs actually generated, and somewhere to store them (controls 8.1 through 8.3). IG2 adds more: clocks kept in sync (8.4), logs gathered centrally (8.9), ninety days of retention as a floor (8.10), and a weekly review habit (8.11). Two softer promises sit beside those controls — a shared change calendar so security work lands in quiet hours, and containment authority agreed in advance, so nobody negotiates isolation powers during an incident.

Numbers both teams sign

NIST rejects an estate-wide “percentage patched” as not actionable, and the contract should too. The workable set: on-time percentage calculated per cell of asset importance against urgency, median and ninetieth-percentile time-to-remediate, unowned findings counted weekly, exception health, telemetry coverage, and a counter-metric for disruption caused by security changes. The reference we kept returning to while assembling this glossary is the Ops Atlas page on SecOps, which keeps the whole arrangement on one page.

For the AIOps reader the invitation is narrow and concrete: host the shared register, wire the on-time percentages next to your existing service dashboards, and treat the queue as one more pipeline with an SLO. If alert noise is your team’s current tax, our piece on reducing IT event noise pairs well with a single owned queue, and our guide to adopting AIOps inside an IT team shows how to build the routing such a queue depends on. The habit underneath both is the one described in real-time IT problem solving: see the state, name the owner, act inside a window. SecOps just writes that habit down and gets both teams to sign it.