What is a detection engineering cycle template?

A detection engineering cycle template is a structured operating record that walks one detection engineering cycle from threat-model input and ATT&CK coverage scoping, through log source coverage check, rule write-and-tune-and-retire decisions, purple-team validation, false-positive backlog burn-down, programme metrics, and framework evidence packaging. It is not a SIEM rule library, a SOAR playbook, an ATT&CK Navigator export, or a Sigma rule pack. It is the named, versioned, role-anchored procedure that converts the question of which adversary techniques the organisation has to detect, into a per-cycle artefact that the detection engineering lead, the SOC manager, the security operations leader, the AppSec lead, the vulnerability management lead, the audit committee, and the regulator all read against. Without a cycle template the detection engineering function devolves into ad hoc rule writing against whichever alert produced the most noise that week, and the firm cannot answer the audit question of how detection coverage moved between cycles for a named ATT&CK technique.

How is the cycle template different from a SIEM rule library or a Sigma rule pack?

A SIEM rule library or a Sigma rule pack is the content artefact: the actual queries, correlations, and detection logic that runs in the SIEM, the SOAR, or the XDR platform. The cycle template is the operating procedure that sits above the rule artefact. It names which ATT&CK techniques the cycle is funded to address, which log sources have to be available for the rule to fire, which validation pattern proves the rule works, which false-positive threshold the rule has to clear before it stays in production, which retirement signal the rule has to be measured against, and which framework evidence the cycle produces for ISO 27001 A.8.16, SOC 2 CC7, PCI DSS Requirement 10, NIST CSF 2.0 DE, NIST SP 800-53 SI and AU, NIS2, and DORA. A Sigma rule pack answers what rules exist; a SIEM rule library answers where those rules run; the cycle template answers how the detection engineering function actually operates against an audit, leadership, and consumer set of expectations.

What sections does a defensible detection engineering cycle template contain?

Twelve sections produce a cycle artefact that survives an audit committee read, a regulator inquiry, a CISO leadership review, and a post-incident lesson capture. Cycle header and version control. Cycle charter, scope, and authority. Threat model input and ATT&CK technique scope. Log source coverage check and ingestion fitness. Rule lifecycle plan with write, tune, retire decisions. Validation pattern with purple-team, BAS, and red-team handoff. False-positive triage backlog and noise budget. Detection content register and platform target stack. Cycle metrics and quarterly governance review. Operating cadence with calendar and event-driven triggers. Cross-team handoff with SOC, AppSec, VM, IR, and threat intelligence. Cycle governance, sign-off, and template revision. The twelve sections cover what the cycle is funded to address, which techniques are in scope, which log sources have to be available, which rules are being written or retired, how the cycle validates the rules, how the false-positive backlog is bounded, how the cycle reads at governance, when the cycle operates, how the cycle hands off to neighbouring functions, and how the template itself stays current.

How does the cycle template handle ATT&CK technique scope and prioritisation?

Section 3 of the template captures the explicit ATT&CK technique set the cycle is funded to address, derived from four input streams. Threat-model input names the techniques that map to the named adversary profiles the firm tracks (one set per actor where the threat library identifies multiple groups). Red-team and purple-team input names the techniques that landed without detection in the most recent operation. Threat intelligence input names the techniques that have surfaced in the recent CTI cycle as in-the-wild against the sector or against deployed components. Coverage gap input names the techniques the ATT&CK coverage matrix shows as uncovered or partially covered against the threat model. Each technique in the in-scope list carries a priority band (must-cover, should-cover, watch), a rationale chain naming the input stream, a target detection outcome (alerted-on, prevented, hunted-with-prompt), and a named owner on the detection engineering side. The cycle does not aim to cover every ATT&CK technique; it aims to cover the prioritised subset the four input streams agree is in scope for the cycle, with the rest tracked in the coverage register for future cycles.

Why does log source coverage matter so much, and how does the template check it?

A detection rule that targets an ATT&CK technique cannot fire unless the log source that carries the technique signal is actually ingested into the platform the rule runs on at the volume and the cadence the rule expects. Section 4 of the template runs an explicit log source coverage check before the cycle commits to writing the rule. Each in-scope technique resolves to one or more required log sources (Windows Event Logs 4688 process creation, Sysmon 1 process creation, EDR process telemetry, EDR network telemetry, cloud control-plane logs, identity provider sign-in logs, container runtime audit logs, network flow logs, application logs, DNS query logs, web proxy logs, ICAP logs, email gateway logs). Each required log source resolves to an ingestion fitness assessment: is the source ingested at all, is it ingested for the asset class the rule targets, is the timestamp parsing correct, is the parsing schema stable across vendor updates, is the retention window long enough to support the rule and the historical hunt. Techniques whose log source coverage fails the fitness check move to a log source onboarding finding rather than the rule write queue, so the cycle does not commit to writing rules that cannot fire.

How does the rule lifecycle plan work in the template?

Section 5 of the template captures the per-rule lifecycle decision for the cycle: write, tune, retire, or carry-forward. Write captures new rule authoring against an in-scope technique where no existing rule covers it. Tune captures changes to an existing rule because of false-positive volume, missed detections during validation, schema changes on the source log, or platform migration. Retire captures the rule removal where the technique is no longer relevant against the current threat model, the underlying control prevents the technique reliably, or the rule has degraded into a noise generator that erodes SOC trust. Carry-forward captures rules that pass the cycle without change. Each rule decision carries a named author, a named reviewer, a platform target (SIEM, SOAR, XDR, host-based detection, network-based detection), a deployment status (drafted, peer-reviewed, deployed in monitoring mode, deployed in alerting mode, retired), a validation reference back to Section 6, a false-positive baseline from Section 7, and a deployment date. The lifecycle decision chain is the record the audit reads to confirm that rules ship through a controlled procedure rather than being added and removed on analyst preference.

How does the cycle template handle validation through purple-team, BAS, and red-team handoff?

Section 6 of the template names the validation pattern for each rule in the cycle. Three primary patterns produce defensible validation evidence. Purple-team validation pairs the offensive operator and the detection engineer on the same engagement record so the technique fires while the rule monitors; the operator logs the technique, the detection engineer logs the rule outcome, and the engagement carries both. Breach-and-attack-simulation (BAS) validation runs an automated technique replay (Atomic Red Team, Caldera, Cymulate, AttackIQ, SafeBreach, Mandiant Security Validation, Picus Security, Scythe) against the deployed rule and captures the result on the engagement record. Red-team after-action validation reads the most recent red-team operation for techniques that landed without detection, opens a missed-technique finding against the engagement, writes the rule against the finding, then schedules the next purple-team operation to replay the technique against the new rule. Each validation pattern produces an explicit pass, partial-pass, or fail disposition that determines whether the rule advances from drafted to monitoring-mode to alerting-mode or returns to the tune queue.

How does the cycle template bound the false-positive backlog and the noise budget?

Section 7 of the template captures the false-positive triage discipline that prevents the detection content from collapsing into alert fatigue. Each in-production rule carries a false-positive baseline from the last cycle (count of analyst-confirmed false positives per week against alert volume), a noise budget (the count of false positives the rule is allowed to produce per week before the cycle commits to tuning), and a noise-budget breach disposition (tune in next cycle, tune this cycle as event-driven trigger, suppress with documented rationale, retire). The false-positive triage backlog is the queue of rules that are operating above the noise budget at the cycle open. Each backlog entry resolves to one of four outcomes during the cycle: tune the rule and revalidate, raise the threshold (with documented rationale and a residual-risk record), suppress the alert path while retaining the rule (with the suppression captured on the exception register), or retire the rule. The backlog is bounded at the cycle close so the next cycle opens against a known noise envelope rather than against an accumulating backlog of unresolved noise complaints from the SOC.

What metrics does the quarterly governance review read against the cycle?

Section 9 of the template captures ten durable indicators the quarterly governance review reads against trend. ATT&CK coverage rate by tactic against the threat model (the percentage of in-scope techniques with at least one rule in alerting mode per tactic). New-rule deployment count per cycle against the deployment commitment (rules drafted, rules deployed in monitoring mode, rules promoted to alerting mode). Rule retirement count per cycle and the retirement reason mix (technique no longer in scope, underlying control reliable, noise generator, platform migration). Validation pass rate by validation pattern (purple-team pass percentage, BAS pass percentage, red-team replay outcome). False-positive backlog count at cycle open and cycle close, with the noise-budget breach count by rule. Mean time from missed-technique finding to rule deployed in alerting mode (the detection backlog burn-down indicator). Mean time from a CTI technical product naming an in-scope technique to a rule update or new rule deployed (the CTI-to-detection responsiveness indicator). Log source onboarding count per cycle (new log sources ingested, parsing schemas updated, retention windows extended). Hunt-prompt deployment count per cycle (analyst-facing hunting prompts shipped, with hunt-outcome rate). Cross-team handoff count per cycle (handoffs into SOC, AppSec, VM, IR, and CTI). The ten metrics together let the audit committee, the board risk committee, and the CISO read whether the detection programme is improving over time rather than producing volume without coverage gain.

How does the cycle template align with NIST CSF, NIST SP 800-53, SOC 2, ISO 27001, PCI DSS, NIS2, and DORA?

The cycle template produces the per-decision evidence the framework controls expect. NIST CSF 2.0 DE function (DE.CM continuous monitoring and DE.AE adverse event analysis) reads the cycle as the operating instance of detection content lifecycle, with the ten metrics in Section 9 supplying the trend evidence. NIST SP 800-53 SI-4 (information system monitoring), AU-2 (audit events), AU-6 (audit record review), and SI-2 (flaw remediation, where the detection content cycle pairs with the VM cycle) read the rule lifecycle, the validation evidence, and the false-positive triage discipline. SOC 2 CC7.2 (the entity monitors system components and the operation of those components for anomalies) and CC7.3 (the entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives) read the cycle charter, the validation pattern, the false-positive triage, and the cross-team handoff. ISO 27001 Annex A 8.16 (monitoring activities), A 8.15 (logging), and A 5.30 (ICT readiness for business continuity, where detection feeds incident response) read the cycle as the operating procedure for the monitoring control with the document custody, the validation evidence, and the activity log trail in support. PCI DSS Requirement 10 (log and monitor all access to system components and cardholder data) and Requirement 12.10 (incident response plan addresses external alerts and contains procedures to respond to alerts from security monitoring) read the cycle as the operating evidence for monitoring-control effectiveness. NIS2 Article 21(2) (technical, operational, and organisational measures including detection) and DORA Article 6 (ICT risk management framework) and Article 9 (protection and prevention, where detection feeds the ICT incident management chain in Article 17) read the cycle as the procedural anchor for ICT-incident-aware detection operations. MITRE ATT&CK provides the structured technique vocabulary the cycle scope reads against; the SANS Detection Engineering Maturity Model and the Palantir Alerting and Detection Strategy framework provide the tradecraft anchors the rule lifecycle and the validation patterns read against.

How does the cycle template handle cross-team handoff with SOC, AppSec, VM, IR, and threat intelligence?

Section 11 of the template captures the handoff chain that prevents the detection engineering function from operating as an island. Five named neighbour functions consume the cycle outputs. SOC operations consume the alerting-mode rules that produce live alerts and the hunt prompts the analyst rota runs against; the handoff record captures the rule identifier, the alert-to-case threshold, the runbook reference for triage, and the noise-budget commitment. AppSec consumes the technique findings that map to application-layer vulnerabilities (deserialisation, SSRF, IDOR, server-side template injection, XXE) and contribute to the AppSec finding queue. Vulnerability management consumes the technique findings that map to exploitable CVEs in the deployed estate (the technique cannot land if the underlying vulnerability is closed) and the technical-product class from the CTI runbook. Incident response consumes the alerting-mode rules that produce IR-eligible alerts and the detection content version active at the time of any incident, so the post-incident review can reproduce what detection was deployed when the incident occurred. Threat intelligence consumes the missed-technique findings the cycle produces and the validation outcomes that confirm or refute the CTI prioritisation. Each handoff produces a structured handoff record with a named originator, a named receiver, the artefact reference, the date, and a feedback channel that closes the loop into the next cycle.

Free Tool

Detection Engineering Cycle Template
twelve sections that turn ad hoc detection rule writing into a defensible operating cycle

A free, copy-ready detection engineering cycle template. Twelve structured sections covering cycle header and version control, cycle charter and scope and authority, threat model input and ATT&CK technique scope across four input streams, log source coverage check and ingestion fitness assessment, rule lifecycle plan with write and tune and retire and carry-forward decisions, validation pattern with purple-team and BAS and red-team after-action handoff, false-positive triage backlog and noise budget, detection content register and platform target stack, ten cycle metrics for the quarterly governance review, operating cadence with calendar and event-driven triggers, cross-team handoff with SOC and AppSec and VM and IR and CTI, and cycle governance with sign-off and template revision. Aligned with NIST CSF 2.0 DE.CM and DE.AE, NIST SP 800-53 SI-4 and AU-2 and AU-6 and SI-2, SOC 2 CC7.2 and CC7.3, ISO 27001 Annex A 8.16 and A 8.15 and A 5.30, PCI DSS Requirement 10 and 12.10, NIS2 Article 21(2), DORA Article 6 and 9 and 17. Built for detection engineering leads, SOC managers, security operations leaders, security engineering teams, AppSec leads, vulnerability management leads, incident response leads, threat intelligence programme leads, GRC and compliance teams, CISOs, security architects, audit committees, and board risk committees that need a defensible alternative to ad hoc rule writing against whichever alert produced the most noise that week.

Get Started Free

No credit card required. Free plan available forever.

Twelve sections that turn detection engineering into a defensible operating cycle

Detection engineering is the security function that decides which adversary techniques the organisation has to detect, writes the rules that detect them, validates the rules against known-bad behaviour, and retires the rules that no longer serve the threat model or the noise envelope. The cycle template is the named, versioned, role-anchored operating procedure that codifies how the function runs one cycle on a workspace record the SOC, the AppSec team, the vulnerability management team, the incident response team, the threat intelligence programme, the CISO, the audit committee, and the regulator all read against. It is not a SIEM rule library, a SOAR playbook, an ATT&CK Navigator export, or a Sigma rule pack. Run alongside a threat intelligence program runbook that supplies the technical and operational product classes the cycle consumes and a purple-teaming workflow that produces validation evidence on the same engagement record, the detection engineering cycle becomes the operating record the audit and the regulator read against.

The twelve sections below cover the durable shape of one cycle artefact against NIST CSF 2.0 DE.CM and DE.AE, NIST SP 800-53 SI-4 and AU-2 and AU-6 and SI-2, SOC 2 CC7.2 and CC7.3, ISO 27001 Annex A 8.16 and A 8.15 and A 5.30, PCI DSS Requirement 10 and 12.10, NIS2 Article 21(2), and DORA Article 6 and 9 and 17. The package is not a substitute for a SIEM, a SOAR platform, an XDR, an EDR, or the engineering teams that own the detection and prevention stack. Pair it with the security control validation runbook template that proves the deployed prevention controls still behave as designed against named scenarios, the security program charter template that names the upstream chartered authority the cycle operates under, the incident response runbook template that consumes the alerting-mode rules at incident time, the vulnerability remediation runbook template that the VM handoff in Section 11 feeds into, the security KPI dashboard template for the leadership-facing layer that reads the ten metrics in Section 9, and the quarterly review template that reads the cycle trend into management review. Copy the section that fits your stage and paste the rest as you go.

Copy the full cycle template (all twelve sections) as one block.

1. Cycle header and version control

Open the cycle artefact with the programme name, the cycle identifier, the cycle window, the cycle owner, and the framework expectations it evidences. A reviewer should be able to read in the first lines which cycle this is, who owns the detection engineering programme, what window the cycle covers, and which framework controls the cycle is being run against. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the cycle header is what makes the detection content evidence traceable across audit cycles rather than a loose folder of analyst notes.

Cycle identifier (cross-referenced from the detection engineering charter and the governance forum minute book): {{CYCLE_IDENTIFIER}}

Cycle title: {{CYCLE_TITLE}}
Cycle window start date: {{CYCLE_WINDOW_START}}
Cycle window end date: {{CYCLE_WINDOW_END}}
Cycle cadence band (one of: monthly tactical cycle, quarterly programme cycle, post-incident lesson cycle, event-driven CTI-triggered cycle, post-purple-team operation cycle, log source onboarding cycle):
- {{CYCLE_CADENCE_BAND}}

Programme name: {{PROGRAMME_NAME}}
Programme tier (one of: dedicated detection engineering programme with named engineer pool, distributed detection engineering function with named lead and matrixed engineers, founding-stage detection engineering programme with single lead):
- {{PROGRAMME_TIER}}

Cycle owner (the role accountable for the cycle artefact and the cycle outcomes):
- Role: {{CYCLE_OWNER_ROLE}}
- Named person at time of publication: {{CYCLE_OWNER_NAME}}
- Reporting line: {{CYCLE_OWNER_REPORTING_LINE}}

Cycle author (the role responsible for filling in the cycle artefact):
- Role: {{CYCLE_AUTHOR_ROLE}}
- Named person at time of publication: {{CYCLE_AUTHOR_NAME}}
- Signature: {{CYCLE_AUTHOR_SIGNATURE}}
- Signature date: {{CYCLE_AUTHOR_SIGNATURE_DATE}}

Sponsor (the executive who chartered the detection engineering programme and reads its outputs at the strategic cadence):
- Role: {{PROGRAMME_SPONSOR_ROLE}}
- Named person at time of publication: {{PROGRAMME_SPONSOR_NAME}}
- Sign-off date: {{PROGRAMME_SPONSOR_SIGNOFF_DATE}}

Engineer pool (the named roles authorised to write, tune, and retire rules under this cycle):
- Senior detection engineer (analytic tradecraft authority, final reviewer for rules in alerting mode): {{SENIOR_DETECTION_ENGINEER_ROLE}}
- Detection engineer (rule authorship in monitoring mode, contributing author for alerting-mode rules): {{DETECTION_ENGINEER_ROLE}}
- Rotated reviewer (independent review for rules promoted to alerting mode; rotated through the SOC manager rota and the AppSec engineering lead rota):
  - {{ROTATED_REVIEWER_ROLE}}

Framework expectations evidenced by this cycle (NIST CSF 2.0 DE.CM continuous monitoring; DE.AE adverse event analysis; NIST SP 800-53 SI-4 information system monitoring, AU-2 audit events, AU-6 audit record review, SI-2 flaw remediation; SOC 2 CC7.2 anomaly monitoring, CC7.3 security event evaluation; ISO 27001 Annex A 8.16 monitoring activities, A 8.15 logging, A 5.30 ICT readiness for business continuity; PCI DSS Requirement 10 logging and monitoring, Requirement 12.10 incident response; NIS2 Article 21(2) technical operational measures; DORA Article 6 ICT risk management, Article 9 protection and prevention, Article 17 ICT incident management; sector overlays; internal policy):
- {{FRAMEWORK_EXPECTATIONS_LIST}}

Cross-references:
- Parent detection engineering charter: {{DETECTION_ENGINEERING_CHARTER_REFERENCE}}
- Parent security programme charter: {{SECURITY_PROGRAMME_CHARTER_REFERENCE}}
- Parent rule-writing standard: {{RULE_WRITING_STANDARD_REFERENCE}}
- Parent rule retirement policy: {{RULE_RETIREMENT_POLICY_REFERENCE}}
- Linked CTI programme reference (where the CTI cycle feeds the detection engineering cycle): {{CTI_PROGRAMME_REFERENCE}}
- Linked vulnerability management policy reference: {{VULNERABILITY_MANAGEMENT_POLICY_REFERENCE}}
- Linked incident response plan reference: {{INCIDENT_RESPONSE_PLAN_REFERENCE}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}

Revision history (each entry: cycle version, effective date, trigger, author, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, author {{PRIOR_AUTHOR_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, author {{PRIOR_AUTHOR_2}}, signed {{PRIOR_SIGNATORY_2}}

2. Cycle charter, scope, and authority

Name what the cycle is funded to address, which estates the cycle covers, and which authority the cycle operates under. A detection engineering cycle without an explicit charter drifts into rule writing against whichever alert produced the most noise that week. The charter block converts the unstated assumptions about scope, audience, and authority into a named contract between the cycle and the rest of the security organisation that the audit, the regulator, and the board read against.

Cycle mandate (one paragraph describing what this cycle is funded to address):
{{CYCLE_MANDATE}}

Cycle scope (which estates, business units, geographies, and technology footprints the cycle covers):
- In-scope estates: {{IN_SCOPE_ESTATES}}
- In-scope business units: {{IN_SCOPE_BUSINESS_UNITS}}
- In-scope geographies: {{IN_SCOPE_GEOGRAPHIES}}
- In-scope platform stack (SIEM, SOAR, EDR, XDR, host-based detection, network-based detection, cloud-native detection): {{IN_SCOPE_PLATFORM_STACK}}
- Out-of-scope estates and the rationale (prevents scope drift into adjacent programme space): {{OUT_OF_SCOPE_ESTATES}}

Cycle authority (what the cycle is empowered to do without external sign-off):
- Rule authorship in monitoring mode: granted
- Rule promotion to alerting mode within the published noise budget: granted
- Rule retirement within the published retirement policy: granted
- Hunting prompt deployment to the SOC analyst rota: granted
- Log source onboarding request to the platform team: granted
- Direct finding raising on findings-management for missed-technique records: granted
- Sign-off authority for rules promoted to alerting mode against critical assets: requires senior detection engineer plus rotated reviewer sign-off
- Sign-off authority for cycle artefact at close: requires programme owner sign-off
- Sign-off authority for cycle pack to audit committee: requires sponsor or CISO sign-off

Cycle dependencies (the upstream and downstream programmes the cycle is contractually paired with):
- Upstream from CTI programme: cycle reads the technical and operational product classes from the CTI runbook in this window
- Upstream from purple-team programme: cycle reads the most recent purple-team operation outcomes
- Upstream from red-team programme: cycle reads the most recent red-team after-action items
- Upstream from threat modelling activity: cycle reads the active adversary profile list
- Downstream to SOC operations: cycle ships alerting-mode rules to the analyst rota
- Downstream to incident response: cycle ships the detection content active at the time of any incident
- Downstream to vulnerability management: cycle ships missed-technique findings that map to deployed-estate CVEs
- Downstream to AppSec: cycle ships missed-technique findings that map to application-layer weaknesses
- Downstream to GRC and audit: cycle ships framework evidence packs

Consumer set (the named functions the cycle outputs serve, with sign-off chains for each consumer-class output):
- SOC operations consumer: SOC manager plus on-call rota lead
- Incident response consumer: IR lead plus rotated IR commander
- Vulnerability management consumer: VM lead plus AppSec lead
- Threat intelligence consumer: CTI programme lead
- Audit and GRC consumer: GRC lead plus audit-committee secretary
- Leadership consumer: security operations leader plus CISO

3. Threat model input and ATT&CK technique scope

Name the explicit ATT&CK technique set the cycle is funded to address and the input streams that produced the scope. A cycle that aims to cover every ATT&CK technique covers none defensibly; a cycle that prioritises a named subset against the threat model produces decision-grade evidence. Use four input streams (threat model, red-and-purple-team, threat intelligence, coverage gap analysis) and resolve each technique to a priority band, a rationale chain, a target detection outcome, and a named owner.

Threat model input (the adversary profiles the firm tracks at the start of the cycle):

For each in-scope adversary profile, capture:
- Adversary profile identifier (the name the threat library uses): {{ADVERSARY_PROFILE_IDENTIFIER}}
- ATT&CK groups mapped to this profile: {{ATTACK_GROUPS_MAPPED}}
- Targeting evidence against the firm or the sector: {{TARGETING_EVIDENCE}}
- Confidence level (high, moderate, low) per ICD 203 conventions: {{ADVERSARY_PROFILE_CONFIDENCE}}
- TTPs the profile is known to operate: {{KNOWN_TTPS}}

Red-team and purple-team input (techniques that landed without detection in the most recent operation):

For each red-team and purple-team operation in the cycle window, capture:
- Operation identifier: {{OPERATION_IDENTIFIER}}
- Operation date: {{OPERATION_DATE}}
- Techniques exercised: {{TECHNIQUES_EXERCISED}}
- Techniques that landed without detection: {{MISSED_TECHNIQUES}}
- Techniques detected and the rule that detected them: {{DETECTED_TECHNIQUES_RULE_MAP}}
- Engagement record reference on findings-management: {{ENGAGEMENT_RECORD_REFERENCE}}

Threat intelligence input (techniques surfaced in the recent CTI cycle as in-the-wild against the sector or deployed components):

For each CTI-driven technique entry, capture:
- CTI product reference: {{CTI_PRODUCT_REFERENCE}}
- CTI publication date: {{CTI_PUBLICATION_DATE}}
- Techniques named: {{CTI_NAMED_TECHNIQUES}}
- Affected components and the deployment status: {{CTI_AFFECTED_COMPONENTS}}
- Priority signal carried with the CTI product (must-cover, should-cover, watch): {{CTI_PRIORITY_SIGNAL}}

Coverage gap input (techniques the ATT&CK coverage matrix shows as uncovered or partially covered):

For each coverage gap entry, capture:
- Tactic: {{COVERAGE_TACTIC}}
- Technique identifier: {{COVERAGE_TECHNIQUE_IDENTIFIER}}
- Sub-technique identifier where applicable: {{COVERAGE_SUBTECHNIQUE_IDENTIFIER}}
- Current coverage state (uncovered, partially covered, deprecated rule, suppressed rule): {{COVERAGE_STATE}}
- Cycles open without coverage: {{COVERAGE_CYCLES_OPEN}}

In-scope technique register (the prioritised subset the cycle commits to address):

For each in-scope technique, capture:
- Tactic: {{IN_SCOPE_TACTIC}}
- Technique identifier: {{IN_SCOPE_TECHNIQUE_IDENTIFIER}}
- Sub-technique identifier where applicable: {{IN_SCOPE_SUBTECHNIQUE_IDENTIFIER}}
- Priority band (must-cover, should-cover, watch): {{TECHNIQUE_PRIORITY_BAND}}
- Rationale chain naming input streams (threat model, red and purple team, CTI, coverage gap): {{RATIONALE_CHAIN}}
- Target detection outcome (alerted-on, prevented, hunted-with-prompt, monitored-only): {{TARGET_DETECTION_OUTCOME}}
- Named owner on the detection engineering side: {{TECHNIQUE_OWNER}}
- Estimated cycle effort (engineer hours): {{ESTIMATED_CYCLE_EFFORT}}
- Acceptance criteria reference into Section 6 (validation): {{ACCEPTANCE_CRITERIA_REFERENCE}}

Out-of-scope technique register (techniques the four input streams considered but the cycle deliberately defers):

For each out-of-scope technique, capture:
- Tactic, technique, sub-technique: {{OUT_OF_SCOPE_TECHNIQUE_REFERENCE}}
- Deferral rationale (capacity, dependency on log source onboarding, dependency on platform migration, accepted risk per exception register): {{DEFERRAL_RATIONALE}}
- Re-consideration trigger: {{RECONSIDERATION_TRIGGER}}
- Carrier reference to the exception register: {{EXCEPTION_REGISTER_REFERENCE}}

4. Log source coverage check and ingestion fitness

A detection rule that targets an ATT&CK technique cannot fire unless the log source that carries the technique signal is actually ingested into the platform the rule runs on at the volume and the cadence the rule expects. Resolve every in-scope technique to one or more required log sources, then assess each source against an ingestion fitness check before the cycle commits to writing the rule.

Required log source map (for each in-scope technique from Section 3):

For each technique-to-log-source mapping, capture:
- Technique identifier: {{TECHNIQUE_IDENTIFIER}}
- Required log source identifier (Windows Event Log channel, Sysmon event ID, EDR telemetry stream, cloud control-plane log stream, identity provider sign-in log, container runtime audit log, network flow log, application log, DNS query log, web proxy log, ICAP log, email gateway log, AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs, Kubernetes audit log, Linux auditd, macOS unified log, web application firewall log, secrets management audit log): {{REQUIRED_LOG_SOURCE}}
- Asset class the source has to cover (Windows endpoint, Linux server, macOS endpoint, Kubernetes node, container runtime, cloud account, identity provider tenant, edge appliance, application tier, database tier): {{ASSET_CLASS}}

Ingestion fitness assessment (for each required log source):

For each log source, capture:
- Currently ingested into the platform stack (yes, partial, no): {{INGESTION_STATUS}}
- Asset coverage percentage against the asset class: {{ASSET_COVERAGE_PERCENTAGE}}
- Timestamp parsing correct against the platform schema: {{TIMESTAMP_PARSING_STATUS}}
- Parsing schema stable across vendor updates in the cycle window: {{PARSING_SCHEMA_STABILITY}}
- Volume against the platform license budget (within budget, near budget, over budget): {{VOLUME_BUDGET_STATUS}}
- Retention window long enough to support the rule plus the historical hunt (90 days, 180 days, 365 days, longer): {{RETENTION_WINDOW}}
- Parser owner (the team accountable for the parsing schema): {{PARSER_OWNER}}
- Ingestion owner (the team accountable for the source being available): {{INGESTION_OWNER}}

Log source fitness disposition (for each required log source):
- Fit for the cycle: rule write proceeds to Section 5
- Partially fit: rule write proceeds against the covered subset and the coverage gap moves to a log source onboarding finding
- Unfit: rule write defers; technique moves to a log source onboarding finding and out-of-scope register in Section 3

Log source onboarding findings raised in this cycle (each entry feeds findings-management with a named owner and a target close date):

For each onboarding finding, capture:
- Onboarding finding identifier on findings-management: {{ONBOARDING_FINDING_IDENTIFIER}}
- Required log source: {{ONBOARDING_REQUIRED_LOG_SOURCE}}
- Asset class to cover: {{ONBOARDING_ASSET_CLASS}}
- Blocked technique register references: {{ONBOARDING_BLOCKED_TECHNIQUES}}
- Named owner on the platform side: {{ONBOARDING_OWNER}}
- Target close date: {{ONBOARDING_TARGET_CLOSE_DATE}}
- Dependency notes (vendor procurement, parser development, retention window adjustment, asset agent rollout): {{ONBOARDING_DEPENDENCY_NOTES}}

5. Rule lifecycle plan with write, tune, retire, carry-forward decisions

Capture the per-rule lifecycle decision for the cycle. Write captures new rule authoring against an in-scope technique. Tune captures changes to an existing rule. Retire captures rule removal where the technique is out of scope, the underlying control prevents the technique reliably, or the rule has degraded into a noise generator. Carry-forward captures rules that pass without change. Each rule decision carries the chain that the audit reads.

Write decisions (new rule authorship against an in-scope technique with no existing coverage):

For each write decision, capture:
- Rule identifier (workspace-internal): {{RULE_IDENTIFIER}}
- Target technique identifier from Section 3: {{TARGET_TECHNIQUE_IDENTIFIER}}
- Target detection outcome (alerted-on, prevented, hunted-with-prompt, monitored-only): {{TARGET_DETECTION_OUTCOME}}
- Platform target (SIEM identifier, SOAR identifier, XDR identifier, host-based detection identifier, network-based detection identifier, cloud-native detection identifier): {{PLATFORM_TARGET}}
- Required log source list from Section 4: {{REQUIRED_LOG_SOURCES}}
- Rule body summary (query language, correlation logic, threshold, lookback window): {{RULE_BODY_SUMMARY}}
- Author: {{RULE_AUTHOR}}
- Peer reviewer: {{RULE_PEER_REVIEWER}}
- Deployment status (drafted, peer-reviewed, deployed in monitoring mode, promoted to alerting mode): {{DEPLOYMENT_STATUS}}
- Initial noise budget per Section 7: {{INITIAL_NOISE_BUDGET}}
- Validation reference into Section 6: {{VALIDATION_REFERENCE}}
- Deployment date: {{DEPLOYMENT_DATE}}
- Cross-team handoff references into Section 11: {{WRITE_HANDOFF_REFERENCES}}

Tune decisions (changes to an existing rule):

For each tune decision, capture:
- Existing rule identifier: {{TUNE_RULE_IDENTIFIER}}
- Tune trigger (false-positive volume over budget per Section 7, missed detection during validation per Section 6, log source schema change per Section 4, platform migration, CTI update naming the same technique with new behaviour): {{TUNE_TRIGGER}}
- Rule body change summary: {{TUNE_RULE_BODY_CHANGE_SUMMARY}}
- Author: {{TUNE_AUTHOR}}
- Peer reviewer: {{TUNE_PEER_REVIEWER}}
- Pre-tune noise baseline: {{PRE_TUNE_NOISE_BASELINE}}
- Post-tune noise target: {{POST_TUNE_NOISE_TARGET}}
- Validation reference into Section 6: {{TUNE_VALIDATION_REFERENCE}}
- Deployment date: {{TUNE_DEPLOYMENT_DATE}}

Retire decisions (rule removal):

For each retire decision, capture:
- Retiring rule identifier: {{RETIRE_RULE_IDENTIFIER}}
- Retire trigger (technique out of scope per Section 3, underlying control prevents technique reliably, rule degraded into noise generator beyond noise budget per Section 7, platform migration, rule superseded by new rule): {{RETIRE_TRIGGER}}
- Compensating control reference where the technique remains in scope (control identifier, control owner, validation evidence): {{COMPENSATING_CONTROL_REFERENCE}}
- Author of retirement: {{RETIRE_AUTHOR}}
- Approver of retirement: {{RETIRE_APPROVER}}
- Retirement date: {{RETIREMENT_DATE}}
- Retention of rule artefact for audit reproducibility: {{RETIRED_RULE_ARTEFACT_RETENTION}}

Carry-forward decisions (rules that pass the cycle without change):

For each carry-forward decision, capture:
- Carry-forward rule identifier: {{CARRY_RULE_IDENTIFIER}}
- Validation result this cycle: {{CARRY_VALIDATION_RESULT}}
- Noise baseline this cycle: {{CARRY_NOISE_BASELINE}}
- Owner this cycle: {{CARRY_OWNER}}

Rule cycle summary table (counts at cycle close):
- Rules written in monitoring mode: {{COUNT_WRITTEN_MONITORING}}
- Rules promoted from monitoring to alerting: {{COUNT_PROMOTED_ALERTING}}
- Rules tuned in this cycle: {{COUNT_TUNED}}
- Rules retired in this cycle: {{COUNT_RETIRED}}
- Rules carried forward without change: {{COUNT_CARRIED_FORWARD}}
- Rules deferred to next cycle (with rationale): {{COUNT_DEFERRED}}

6. Validation pattern with purple-team, BAS, and red-team handoff

Name the validation pattern for each rule decision in the cycle. Three primary patterns produce defensible validation evidence: purple-team validation, breach-and-attack-simulation (BAS) validation, and red-team after-action validation. Each pattern produces an explicit pass, partial-pass, or fail disposition that determines whether the rule advances from drafted to monitoring-mode to alerting-mode or returns to the tune queue.

Purple-team validation (offensive operator plus detection engineer paired on the same engagement record):

For each purple-team validation, capture:
- Validation identifier: {{PURPLE_VALIDATION_IDENTIFIER}}
- Engagement record reference on findings-management: {{PURPLE_ENGAGEMENT_REFERENCE}}
- Rule under validation: {{PURPLE_RULE_UNDER_VALIDATION}}
- Technique exercised: {{PURPLE_TECHNIQUE_EXERCISED}}
- Sub-technique exercised: {{PURPLE_SUBTECHNIQUE_EXERCISED}}
- Offensive operator: {{PURPLE_OFFENSIVE_OPERATOR}}
- Detection engineer: {{PURPLE_DETECTION_ENGINEER}}
- Execution date: {{PURPLE_EXECUTION_DATE}}
- Operator-side technique outcome (fired, partial, blocked): {{PURPLE_OPERATOR_OUTCOME}}
- Detection-side rule outcome (alerted, monitored-only, missed, false-positive): {{PURPLE_DETECTION_OUTCOME}}
- Disposition (pass, partial-pass, fail): {{PURPLE_DISPOSITION}}
- Evidence reference (log query, dashboard reference, screenshot reference on document-management): {{PURPLE_EVIDENCE_REFERENCE}}
- Next action (promote to alerting, return to tune, mark as monitor-only, hold for next cycle): {{PURPLE_NEXT_ACTION}}

Breach-and-attack-simulation (BAS) validation (automated technique replay against the deployed rule):

For each BAS validation, capture:
- Validation identifier: {{BAS_VALIDATION_IDENTIFIER}}
- BAS tool (Atomic Red Team, Caldera, Cymulate, AttackIQ, SafeBreach, Mandiant Security Validation, Picus Security, Scythe, Prelude Operator, or other): {{BAS_TOOL}}
- BAS scenario identifier: {{BAS_SCENARIO_IDENTIFIER}}
- Rule under validation: {{BAS_RULE_UNDER_VALIDATION}}
- Technique exercised: {{BAS_TECHNIQUE_EXERCISED}}
- Sub-technique exercised: {{BAS_SUBTECHNIQUE_EXERCISED}}
- Execution date: {{BAS_EXECUTION_DATE}}
- Test traffic shape (volume, cadence, source asset): {{BAS_TEST_TRAFFIC_SHAPE}}
- Detection outcome (alerted, monitored-only, missed, false-positive): {{BAS_DETECTION_OUTCOME}}
- Disposition (pass, partial-pass, fail): {{BAS_DISPOSITION}}
- Evidence reference: {{BAS_EVIDENCE_REFERENCE}}
- Next action: {{BAS_NEXT_ACTION}}

Red-team after-action validation (read the most recent red-team operation for techniques that landed without detection, open a missed-technique finding, write the rule against the finding, schedule the replay):

For each red-team after-action validation, capture:
- Validation identifier: {{RT_VALIDATION_IDENTIFIER}}
- Source red-team operation reference: {{RT_SOURCE_OPERATION_REFERENCE}}
- Missed technique finding on findings-management: {{RT_MISSED_TECHNIQUE_FINDING}}
- Rule written or tuned against the finding: {{RT_RULE_AGAINST_FINDING}}
- Replay date scheduled or executed: {{RT_REPLAY_DATE}}
- Replay outcome on the finding: {{RT_REPLAY_OUTCOME}}
- Disposition (pass, partial-pass, fail, replay-pending): {{RT_DISPOSITION}}
- Finding state update on findings-management (in_progress to resolved to verified): {{RT_FINDING_STATE_UPDATE}}
- Aging clock origin (the original capture date the finding was opened on): {{RT_AGING_CLOCK_ORIGIN}}

Validation summary table (counts at cycle close):
- Total validations executed: {{COUNT_VALIDATIONS_TOTAL}}
- Validations by pattern (purple-team, BAS, red-team after-action): {{COUNT_VALIDATIONS_BY_PATTERN}}
- Pass rate by pattern: {{PASS_RATE_BY_PATTERN}}
- Partial-pass rate by pattern: {{PARTIAL_PASS_RATE_BY_PATTERN}}
- Fail rate by pattern: {{FAIL_RATE_BY_PATTERN}}
- Rules promoted from monitoring to alerting after passing validation: {{COUNT_PROMOTED_AFTER_VALIDATION}}
- Rules returned to tune queue after failing validation: {{COUNT_RETURNED_TO_TUNE}}

7. False-positive triage backlog and noise budget

The cycle bounds the false-positive backlog before the rules collapse into alert fatigue and erode SOC trust. Each in-production rule carries a false-positive baseline, a noise budget, and a noise-budget breach disposition. The triage backlog is the queue of rules operating above the noise budget at cycle open; each backlog entry resolves to one of four outcomes during the cycle.

Cycle noise envelope (the programme-level noise expectation against which per-rule budgets are read):
- Total alerting-mode rule count at cycle open: {{ALERTING_RULE_COUNT_OPEN}}
- Total analyst-confirmed false-positive count per week at cycle open: {{TOTAL_FALSE_POSITIVE_COUNT_OPEN}}
- Target total false-positive count per week at cycle close: {{TARGET_FALSE_POSITIVE_COUNT_CLOSE}}
- SOC capacity model (analyst hours per week available for false-positive triage): {{SOC_FALSE_POSITIVE_CAPACITY}}

Per-rule false-positive baseline (for each alerting-mode rule):

For each rule, capture:
- Rule identifier: {{FP_RULE_IDENTIFIER}}
- False-positive baseline count per week from the prior cycle: {{FP_BASELINE_COUNT}}
- Noise budget per week for this cycle (the count of false positives the rule is allowed to produce per week before the cycle commits to tuning): {{FP_NOISE_BUDGET}}
- Noise-budget breach disposition (tune in next cycle, tune this cycle as event-driven trigger, suppress with documented rationale, retire): {{FP_BREACH_DISPOSITION}}
- Alert-to-case threshold this cycle: {{FP_ALERT_TO_CASE_THRESHOLD}}
- Alert-to-case threshold owner: {{FP_THRESHOLD_OWNER}}

False-positive triage backlog (the queue of rules operating above the noise budget at cycle open):

For each backlog entry, capture:
- Rule identifier: {{BACKLOG_RULE_IDENTIFIER}}
- Backlog-entry origin (cycle-open scan, SOC analyst report, post-incident review, CTI update naming false-positive pattern): {{BACKLOG_ENTRY_ORIGIN}}
- Days in backlog: {{BACKLOG_DAYS_IN_BACKLOG}}
- Resolution outcome (tune-and-revalidate per Section 5 and 6, raise-threshold with rationale, suppress-with-exception-register, retire per Section 5): {{BACKLOG_RESOLUTION_OUTCOME}}
- Resolution date: {{BACKLOG_RESOLUTION_DATE}}
- Residual-risk record reference where applicable: {{BACKLOG_RESIDUAL_RISK_REFERENCE}}
- Exception register reference where applicable: {{BACKLOG_EXCEPTION_REGISTER_REFERENCE}}

Suppression discipline (where a rule remains in the catalogue but the alert path is suppressed):

For each suppression decision, capture:
- Suppressed rule identifier: {{SUPPRESSED_RULE_IDENTIFIER}}
- Suppression rationale: {{SUPPRESSION_RATIONALE}}
- Compensating control reference (the control that catches what the suppressed rule would have caught): {{SUPPRESSION_COMPENSATING_CONTROL}}
- Suppression expiry: {{SUPPRESSION_EXPIRY}}
- Suppression review cadence: {{SUPPRESSION_REVIEW_CADENCE}}
- Sign-off chain (cycle owner plus senior detection engineer plus rotated reviewer): {{SUPPRESSION_SIGNOFF_CHAIN}}
- Exception register reference: {{SUPPRESSION_EXCEPTION_REGISTER_REFERENCE}}

Cycle close noise envelope:
- Total alerting-mode rule count at cycle close: {{ALERTING_RULE_COUNT_CLOSE}}
- Total analyst-confirmed false-positive count per week at cycle close: {{TOTAL_FALSE_POSITIVE_COUNT_CLOSE}}
- Backlog count at cycle close: {{BACKLOG_COUNT_CLOSE}}
- Suppressed-rule count at cycle close: {{SUPPRESSED_RULE_COUNT_CLOSE}}

8. Detection content register and platform target stack

Hold the canonical detection content register and the platform target stack the cycle operates against. The register is the workspace-side view of the rule catalogue that the SIEM, the SOAR, the XDR, or the EDR platform carries operationally. The register reads as the audit-grade index of detection content alongside the operational platform stack rather than as a parallel artefact the team maintains by hand.

Detection content register (the canonical workspace-side index of all detection content active in the cycle):

For each register entry, capture:
- Rule identifier (workspace-internal): {{REGISTER_RULE_IDENTIFIER}}
- Rule title: {{REGISTER_RULE_TITLE}}
- Target tactic and technique identifier: {{REGISTER_TARGET_TACTIC_TECHNIQUE}}
- Platform target identifier: {{REGISTER_PLATFORM_TARGET}}
- Deployment status (monitoring mode, alerting mode, suppressed, retired): {{REGISTER_DEPLOYMENT_STATUS}}
- Author: {{REGISTER_AUTHOR}}
- Last reviewer: {{REGISTER_LAST_REVIEWER}}
- Last review date: {{REGISTER_LAST_REVIEW_DATE}}
- Next scheduled review date: {{REGISTER_NEXT_REVIEW_DATE}}
- Validation pattern (purple-team, BAS, red-team after-action, hybrid): {{REGISTER_VALIDATION_PATTERN}}
- Most recent validation outcome: {{REGISTER_RECENT_VALIDATION_OUTCOME}}
- Most recent noise baseline per week: {{REGISTER_RECENT_NOISE_BASELINE}}
- Compliance mapping (framework controls the rule contributes evidence for): {{REGISTER_COMPLIANCE_MAPPING}}

Platform target stack (the operational platforms the rule catalogue runs against):

For each platform, capture:
- Platform identifier: {{PLATFORM_IDENTIFIER}}
- Platform class (SIEM, SOAR, XDR, EDR, host-based detection, network-based detection, cloud-native detection, secrets-detection, application detection): {{PLATFORM_CLASS}}
- Platform vendor (where externally hosted): {{PLATFORM_VENDOR}}
- In-platform rule count by deployment status: {{IN_PLATFORM_RULE_COUNT_BY_STATUS}}
- Parser owner (the team accountable for the parsing schemas this platform consumes): {{PLATFORM_PARSER_OWNER}}
- Platform owner (the team accountable for the platform operating): {{PLATFORM_OWNER}}
- Platform health (operational, partial-degradation, major-incident, migration-in-flight): {{PLATFORM_HEALTH}}
- Migration cycle window where applicable: {{PLATFORM_MIGRATION_WINDOW}}
- License budget posture (within budget, near budget, over budget): {{PLATFORM_LICENSE_BUDGET}}

Reconciliation discipline (the procedure that keeps the workspace register and the in-platform rule catalogue in sync):
- Reconciliation cadence: {{RECONCILIATION_CADENCE}}
- Reconciliation owner: {{RECONCILIATION_OWNER}}
- Reconciliation drift threshold (the count of register-platform mismatches that triggers an out-of-band reconciliation pass): {{RECONCILIATION_DRIFT_THRESHOLD}}
- Most recent reconciliation outcome at cycle close: {{RECONCILIATION_RECENT_OUTCOME}}

Hunting prompt register (analyst-facing hunting prompts the cycle ships to the SOC rota):

For each hunting prompt, capture:
- Hunting prompt identifier: {{HUNT_PROMPT_IDENTIFIER}}
- Target tactic and technique: {{HUNT_PROMPT_TARGET}}
- Prompt instruction summary: {{HUNT_PROMPT_INSTRUCTION_SUMMARY}}
- Recommended log source query: {{HUNT_PROMPT_QUERY}}
- Author: {{HUNT_PROMPT_AUTHOR}}
- Recommended cadence (daily, weekly, on-demand event-driven): {{HUNT_PROMPT_CADENCE}}
- Recent hunt outcome reference on findings-management: {{HUNT_PROMPT_RECENT_OUTCOME}}

9. Cycle metrics and quarterly governance review

Read the cycle against ten durable indicators so the audit committee, the board risk committee, and the CISO can answer whether the programme is improving over time rather than producing volume without coverage gain. The same ten indicators read across cycles to produce trend lines the governance forum can act on.

Cycle metrics (collected at cycle close and posted to the engagement record):

Metric 1: ATT&CK coverage rate by tactic against the threat model.
- Per tactic (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact), capture the percentage of in-scope techniques per Section 3 with at least one rule in alerting mode per Section 5.
- {{COVERAGE_RATE_BY_TACTIC}}

Metric 2: New-rule deployment count per cycle against the deployment commitment.
- Rules drafted: {{METRIC_RULES_DRAFTED}}
- Rules deployed in monitoring mode: {{METRIC_RULES_MONITORING_MODE}}
- Rules promoted to alerting mode: {{METRIC_RULES_ALERTING_MODE}}
- Deployment commitment at cycle open: {{METRIC_DEPLOYMENT_COMMITMENT}}
- Adherence rate to the commitment: {{METRIC_DEPLOYMENT_ADHERENCE_RATE}}

Metric 3: Rule retirement count per cycle and the retirement reason mix.
- Rules retired: {{METRIC_RULES_RETIRED}}
- Retirement reason mix (technique no longer in scope, underlying control reliable, noise generator, platform migration, superseded by new rule): {{METRIC_RETIREMENT_REASON_MIX}}

Metric 4: Validation pass rate by validation pattern.
- Purple-team validation pass percentage: {{METRIC_PURPLE_PASS_RATE}}
- BAS validation pass percentage: {{METRIC_BAS_PASS_RATE}}
- Red-team after-action replay outcome: {{METRIC_RT_REPLAY_OUTCOME}}

Metric 5: False-positive backlog count at cycle open and cycle close, with the noise-budget breach count by rule.
- Backlog count at cycle open: {{METRIC_BACKLOG_OPEN}}
- Backlog count at cycle close: {{METRIC_BACKLOG_CLOSE}}
- Noise-budget breach count by rule: {{METRIC_BREACH_COUNT_BY_RULE}}

Metric 6: Mean time from missed-technique finding to rule deployed in alerting mode (the detection backlog burn-down indicator).
- Median days: {{METRIC_MED_TIME_TO_RULE}}
- P90 days: {{METRIC_P90_TIME_TO_RULE}}
- Population this cycle: {{METRIC_POPULATION_TIME_TO_RULE}}

Metric 7: Mean time from a CTI technical product naming an in-scope technique to a rule update or new rule deployed (the CTI-to-detection responsiveness indicator).
- Median days: {{METRIC_CTI_RESPONSE_MED}}
- P90 days: {{METRIC_CTI_RESPONSE_P90}}
- Population this cycle: {{METRIC_CTI_RESPONSE_POPULATION}}

Metric 8: Log source onboarding count per cycle (new log sources ingested, parsing schemas updated, retention windows extended).
- New log sources ingested: {{METRIC_LOG_SOURCES_ONBOARDED}}
- Parsing schemas updated: {{METRIC_PARSING_SCHEMAS_UPDATED}}
- Retention windows extended: {{METRIC_RETENTION_WINDOWS_EXTENDED}}

Metric 9: Hunt-prompt deployment count per cycle (analyst-facing hunting prompts shipped, with hunt-outcome rate).
- Hunt prompts shipped: {{METRIC_HUNT_PROMPTS_SHIPPED}}
- Hunt-outcome rate (the percentage of hunt prompts that produced a positive outcome on findings-management): {{METRIC_HUNT_OUTCOME_RATE}}

Metric 10: Cross-team handoff count per cycle.
- Handoffs into SOC: {{METRIC_HANDOFF_SOC}}
- Handoffs into AppSec: {{METRIC_HANDOFF_APPSEC}}
- Handoffs into VM: {{METRIC_HANDOFF_VM}}
- Handoffs into IR: {{METRIC_HANDOFF_IR}}
- Handoffs into CTI: {{METRIC_HANDOFF_CTI}}

Quarterly governance review pack (assembled from the ten metrics across the cycles in the quarter):
- Trend on each of the ten metrics against the prior quarter and the annual baseline.
- Notable lessons learned that landed in cycle template revisions, log source onboarding decisions, platform stack adjustments, or wider programme adjustments.
- Framework alignment evidence for NIST CSF 2.0 DE.CM and DE.AE, NIST SP 800-53 SI-4 and AU-2 and AU-6 and SI-2, SOC 2 CC7.2 and CC7.3, ISO 27001 A.8.16 and A.8.15 and A.5.30, PCI DSS Requirement 10 and 12.10, NIS2 Article 21, DORA Article 6 and 9 and 17.
- Audit committee read-back of the quarter against the chartered mandate.

10. Operating cadence with calendar and event-driven triggers

Run the cycle on a dual cadence: calendar cadence per cycle class plus event-driven cadence for named triggers regardless of calendar position. Calendar cadence anchors the steady-state detection work; event-driven cadence forces out-of-band cycles when a high-priority signal lands between scheduled cycles.

Calendar cadence:

Monthly tactical cycle:
- Week 1: cycle artefact opened, in-scope technique register confirmed per Section 3, log source coverage check run per Section 4.
- Week 2: rule write, tune, retire decisions captured per Section 5.
- Week 3: validation pattern executed per Section 6 (purple-team, BAS, red-team after-action).
- Week 4: false-positive triage backlog resolved per Section 7, register reconciled per Section 8, cycle metrics posted per Section 9, cycle artefact signed off per Section 12.
- Time budget per cycle: 40 to 80 engineer-hours depending on programme tier.

Quarterly programme cycle:
- Read three monthly cycles against the ten metrics in Section 9.
- Run the quarterly governance review forum.
- Refresh the threat model input register per Section 3 if material adversary-profile shifts have occurred.
- Capture programme-level template revision triggers per Section 12.
- Time budget per cycle: 24 to 48 engineer-hours plus governance forum participation.

Annual cycle:
- Annual programme review pack assembled from four quarterly cycles.
- Sponsor and audit committee read of the annual pack.
- Annual cycle template revision pass.
- Sponsor sign-off renewal.
- Time budget per cycle: 40 to 80 engineer-hours plus governance forum participation.

Event-driven triggers (force out-of-band cycles regardless of calendar):

Trigger A - CTI technical product naming an in-scope technique with in-the-wild exploitation:
- Response time budget: 5 business days from CTI publication to rule update or new rule deployed in monitoring mode
- Output: tune or write decision per Section 5; validation per Section 6; handoff into SOC per Section 11.

Trigger B - Confirmed in-scope incident with detection gap identified at the time of the incident:
- Response time budget: continuous detection-engineering support during the incident; post-incident cycle within 15 business days of incident closure
- Output: missed-technique finding per Section 3; rule write per Section 5; validation per Section 6; post-incident lesson capture per Section 12.

Trigger C - Red-team or purple-team operation completed with techniques landing without detection:
- Response time budget: 10 business days from operation close to missed-technique findings opened and write decisions posted
- Output: missed-technique findings per Section 3; rule write per Section 5; replay scheduled per Section 6.

Trigger D - SOC sustained false-positive complaint exceeding the noise budget per Section 7 for two or more cycles:
- Response time budget: 5 business days
- Output: tune or retire decision per Section 5; noise envelope re-baseline per Section 7.

Trigger E - Log source schema change breaking deployed rules:
- Response time budget: 3 business days
- Output: parser schema update per Section 4; rule tune per Section 5; validation per Section 6.

Trigger F - Platform migration window opened (SIEM, SOAR, XDR, EDR migration):
- Response time budget: cycle planning begins at migration window open; per-rule migration decisions captured per Section 5
- Output: platform-migration retire decisions, carry-forward decisions, write decisions per Section 5; reconciliation per Section 8.

Trigger G - CISA KEV addition affecting deployed components where the exploitation chain crosses an in-scope technique:
- Response time budget: 3 business days from KEV addition to in-estate impact assessment and detection content posture review
- Output: tune or write decision per Section 5; CTI-to-detection responsiveness recorded in Metric 7 per Section 9.

Trigger H - Regulator advisory or sector CERT alert affecting in-scope estate:
- Response time budget: 5 business days
- Output: tune or write decision per Section 5; framework evidence update per Section 9.

Capacity-vs-cadence safeguards:
- Event-driven trigger volume is monitored at the quarterly cycle; sustained overrun triggers a capacity request or a trigger-threshold review.
- Calendar cadence has priority over event-driven backlog only when the event-driven response budget has been honoured; otherwise the calendar cycle is rescheduled with a documented note rather than skipped.

11. Cross-team handoff with SOC, AppSec, VM, IR, and threat intelligence

The cycle does not operate as an island. Five named neighbour functions consume the cycle outputs; each handoff produces a structured record with a named originator, a named receiver, the artefact reference, the date, and a feedback channel that closes the loop into the next cycle.

SOC operations handoff:

For each SOC handoff, capture:
- Artefact reference (rule identifier in alerting mode, hunting prompt identifier): {{SOC_HANDOFF_ARTEFACT}}
- Originator (detection engineer): {{SOC_HANDOFF_ORIGINATOR}}
- Receiver (SOC manager, on-call rota lead): {{SOC_HANDOFF_RECEIVER}}
- Handoff date: {{SOC_HANDOFF_DATE}}
- Alert-to-case threshold for the rule: {{SOC_ALERT_TO_CASE_THRESHOLD}}
- Triage runbook reference: {{SOC_TRIAGE_RUNBOOK_REFERENCE}}
- Noise-budget commitment per Section 7: {{SOC_NOISE_BUDGET_COMMITMENT}}
- Feedback channel: {{SOC_FEEDBACK_CHANNEL}}

AppSec handoff:

For each AppSec handoff, capture:
- Artefact reference (missed-technique finding that maps to an application-layer weakness): {{APPSEC_HANDOFF_ARTEFACT}}
- Originator (detection engineer): {{APPSEC_HANDOFF_ORIGINATOR}}
- Receiver (AppSec lead): {{APPSEC_HANDOFF_RECEIVER}}
- Handoff date: {{APPSEC_HANDOFF_DATE}}
- Weakness mapped (deserialisation, SSRF, IDOR, server-side template injection, XXE, authentication bypass, broken access control, other): {{APPSEC_WEAKNESS_MAPPED}}
- Code reference where the application is in scope on connected repositories: {{APPSEC_CODE_REFERENCE}}
- Feedback channel: {{APPSEC_FEEDBACK_CHANNEL}}

Vulnerability management handoff:

For each VM handoff, capture:
- Artefact reference (missed-technique finding that maps to an exploitable CVE in the deployed estate): {{VM_HANDOFF_ARTEFACT}}
- Originator (detection engineer): {{VM_HANDOFF_ORIGINATOR}}
- Receiver (VM lead): {{VM_HANDOFF_RECEIVER}}
- Handoff date: {{VM_HANDOFF_DATE}}
- CVE list: {{VM_CVE_LIST}}
- Deployed-asset list: {{VM_DEPLOYED_ASSET_LIST}}
- Feedback channel: {{VM_FEEDBACK_CHANNEL}}

Incident response handoff:

For each IR handoff, capture:
- Artefact reference (rule in alerting mode at the time of incident; detection content snapshot for post-incident review): {{IR_HANDOFF_ARTEFACT}}
- Originator (detection engineer): {{IR_HANDOFF_ORIGINATOR}}
- Receiver (IR lead, rotated IR commander): {{IR_HANDOFF_RECEIVER}}
- Handoff date: {{IR_HANDOFF_DATE}}
- Detection content version active at the time of incident: {{IR_DETECTION_CONTENT_VERSION}}
- Incident reference on findings-management: {{IR_INCIDENT_REFERENCE}}
- Feedback channel: {{IR_FEEDBACK_CHANNEL}}

Threat intelligence handoff:

For each CTI handoff, capture:
- Artefact reference (missed-technique findings the cycle produced, validation outcomes confirming or refuting the CTI prioritisation): {{CTI_HANDOFF_ARTEFACT}}
- Originator (detection engineer): {{CTI_HANDOFF_ORIGINATOR}}
- Receiver (CTI programme lead): {{CTI_HANDOFF_RECEIVER}}
- Handoff date: {{CTI_HANDOFF_DATE}}
- CTI product references the handoff responds to: {{CTI_PRODUCT_REFERENCES}}
- PIR fitness signal (the missed techniques confirm or refute the priority of the PIR that surfaced them): {{CTI_PIR_FITNESS_SIGNAL}}
- Feedback channel: {{CTI_FEEDBACK_CHANNEL}}

Handoff summary table (counts at cycle close):
- Total handoffs: {{COUNT_HANDOFFS_TOTAL}}
- Handoffs by receiver class (SOC, AppSec, VM, IR, CTI): {{COUNT_HANDOFFS_BY_RECEIVER}}
- Feedback received this cycle: {{COUNT_FEEDBACK_RECEIVED}}
- Feedback-driven cycle adjustments captured for next cycle per Section 12: {{COUNT_FEEDBACK_DRIVEN_ADJUSTMENTS}}

12. Cycle governance, sign-off, and template revision

Keep the cycle artefact and the template itself in sync with the programme by running explicit governance and explicit revision triggers. Cycles that close without sign-off read as analyst notes rather than as operating evidence; templates that never revise drift from the programme as the threat picture, the consumer set, the platform stack, and the regulatory expectation move underneath. The governance block names the forum, the cadence, and the revision triggers.

Cycle close sign-off chain (in order):
- Cycle author signs the completed artefact: {{CYCLE_AUTHOR_SIGNOFF}}
- Senior detection engineer reviews for technical fidelity: {{SENIOR_ENGINEER_SIGNOFF}}
- Rotated reviewer reviews for cross-team-handoff fidelity: {{ROTATED_REVIEWER_SIGNOFF}}
- Programme owner signs for operational fidelity: {{PROGRAMME_OWNER_SIGNOFF}}
- Sponsor signs for governance fidelity (quarterly or annual cycles): {{SPONSOR_SIGNOFF}}
- Activity-log entry captures the close event with the named actor and timestamp: {{ACTIVITY_LOG_REFERENCE}}

Programme governance forum:

Cadence: quarterly (paired with the quarterly programme cycle) and annually (paired with the annual cycle).

Membership:
- Programme sponsor
- CISO
- Security operations leader
- Cycle owner (detection engineering lead)
- Senior detection engineer
- Named consumer representatives (SOC manager, AppSec lead, VM lead, IR lead, CTI programme lead, GRC lead)
- Rotated audit observer (where the firm has an internal audit function)

Standing agenda:
- Read the cycle artefacts in the quarter against the ten metrics in Section 9.
- Read the cross-team handoff summary against the prior quarter.
- Read the CTI-to-detection responsiveness against the CTI programme cadence.
- Read the false-positive trend against the SOC capacity model.
- Read the log source onboarding cycle and the platform stack health.
- Decide on threat model input refresh, log source onboarding priorities, platform stack adjustments, template revision triggers, programme capacity requests.
- Capture sponsor sign-off on the new quarter operating plan.

Template revision triggers (each triggers a template revision pass; the pass produces a versioned new template):
- Scheduled annual revision pass
- Threat model refresh that materially shifts the adversary-profile set or the targeted technique mix
- Platform stack change (SIEM, SOAR, XDR, EDR migration; new platform onboarding; platform retirement)
- Consumer feedback pattern indicating recurring cycle-output fitness issues
- Event-driven trigger volume sustained increase or decrease materially shifting the response-budget assumption
- Regulator change altering programme expectations
- Audit observation against the programme
- Incident post-mortem item naming the cycle template as a contributor
- Sponsor or CISO direction request

Template revision discipline:
- The cycle owner drafts the revision against the named trigger.
- The senior detection engineer reviews the revision for technical fidelity.
- The programme owner reviews the revision for operational fidelity.
- The sponsor or CISO signs the revision for governance fidelity.
- The new template version is published with the effective date; the prior version is retained on document management per the audit evidence retention classification.
- The activity log captures the revision event with the named actor, the timestamp, and the revision trigger.
- The next scheduled cycle runs against the new template.

Programme acknowledgement:
- The cycle artefact is the live operating record of the chartered detection engineering programme.
- The charter defines what the cycle is funded to address, the threat model input plus ATT&CK technique scope codifies what the cycle aims to detect, the log source coverage check codifies whether the cycle has the signal to fire on, the rule lifecycle plan codifies what gets written, tuned, and retired, the validation pattern codifies how the cycle proves the rules work, the false-positive triage codifies how the cycle bounds the noise envelope, the detection content register codifies the canonical workspace-side view, the cycle metrics codify how the cycle reads at governance, the operating cadence codifies when the cycle runs, the cross-team handoff codifies how the cycle pairs with the rest of the security organisation, and the governance discipline codifies how the cycle artefact and the template itself stay current.
- The twelve sections are kept in sync on one workspace so the audit read of detection engineering performance, the consumer read of cycle relevance, the sponsor read of cycle value, and the operational read of cycle workload are the same record rather than twelve independently edited summaries that diverge between reporting cycles.

Eight failure modes the cycle template has to design against

The detection engineering cycle fails the audit read and the consumer read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the detection content evidence chain defensible.

No ATT&CK scope at all

The cycle opens against the inbox refresh rate and rules get written against whichever alert produced the most noise that week. Coverage drift accumulates because no one is reading the catalogue against the threat model. The fix is Section 3 instantiated against the four input streams (threat model, red-and-purple-team, threat intelligence, coverage gap) with priority-banded techniques and named owners, so the cycle aims at a defensible scope rather than at the inbox.

Rules written against techniques whose log source is not ingested

A detection engineer writes a rule for credential dumping behaviours that needs Sysmon event ID 10 process access; the platform ingests Windows Event Log channels but not Sysmon at all. The rule deploys, never fires, and the catalogue accumulates dead rules that look like coverage on the matrix but produce nothing operationally. The fix is Section 4 with explicit log source coverage check and ingestion fitness assessment before the rule write commits.

No validation pattern

Rules deploy on the author signing off without any structural proof that the rule actually fires for the technique it targets. SOC reads alerts whose origin is opaque; the audit committee asks how the firm knows the detection catalogue actually detects and the answer collapses to engineer confidence. The fix is Section 6 with the three validation patterns (purple-team, BAS, red-team after-action), each producing pass, partial-pass, or fail dispositions that determine whether the rule advances.

False-positive backlog that grows without ever shrinking

New rules ship without a noise budget; existing rules accumulate false-positive volume; the SOC learns to ignore CTI-supplied indicators and the analyst rota stops triaging the rule altogether. The fix is Section 7 with per-rule noise budgets, an explicit backlog at cycle open, four resolution outcomes (tune, raise threshold, suppress, retire), and a bounded backlog at cycle close.

Rules retired without compensating control evidence

A rule that has degraded into noise gets retired without naming what now catches what the rule used to catch. The technique remains in scope; the underlying control may or may not prevent it; the cycle records a tidier register but the actual detection posture has degraded silently. The fix is Section 5 with a retire decision chain that captures the retire trigger, the compensating control reference where the technique stays in scope, the approver, and the retention of the rule artefact for audit reproducibility.

Detection content register that drifts from the operational platform stack

The workspace register names twelve rules in alerting mode while the SIEM actually carries fourteen alerting-mode rules. The two extra rules ship outside the cycle and exist only in the platform; the audit cannot reproduce the rule lifecycle for them and the SOC operates against a catalogue that is not chartered. The fix is Section 8 with explicit reconciliation cadence, named reconciliation owner, drift threshold, and reconciliation-pass evidence at cycle close.

Cross-team handoff that broadcasts but never listens

Rules ship to the SOC, missed-technique findings ship to AppSec and VM, and the cycle never reads consumer feedback back into the next cycle. The detection content drifts away from consumer relevance over four to eight cycles; the rule catalogue grows monotonically without trimming what no longer serves anyone. The fix is Section 11 with structured handoff records (named originator, receiver, artefact reference, feedback channel) and Section 12 with consumer feedback as a documented template revision trigger.

Cycle that never closes

Sections of the cycle artefact get filled in across an indefinite window; the cycle owner never signs off; the next cycle starts before the prior cycle has produced its metrics or its lessons. The trend lines in Section 9 cannot read because there is no canonical cycle window. The audit reads the programme as a continuous editing surface rather than as a series of bounded operating cycles. The fix is Section 12 with an explicit close sign-off chain, an activity-log entry on close, and a calendar cadence in Section 10 that bounds the window.

Ten questions the quarterly governance review has to answer

Operational review keeps the cycle template current at the cycle level. Governance review answers whether the programme is delivering durable detection coverage gain or accumulating rule volume without coverage gain. Run these ten questions at every quarterly review and capture the answers in the governance record on the workspace.

1.What is the ATT&CK coverage rate by tactic against the threat model at cycle close, and how does it compare to the prior cycle.
2.Which in-scope techniques from Section 3 did not advance to alerting mode this cycle, and what is the cycle owner plan (next cycle, log source onboarding finding, exception register entry).
3.How many rules were written, tuned, retired, and carried forward this cycle, and how does the rule mix compare to the prior cycle.
4.What is the validation pass rate by pattern (purple-team, BAS, red-team after-action), and which pattern has the lowest pass rate this cycle.
5.What is the false-positive backlog count at cycle open and close, and which rules sustained noise-budget breaches across cycles.
6.What is the mean and the P90 time from missed-technique finding to rule deployed in alerting mode this cycle, and how does it compare to the prior cycle.
7.What is the CTI-to-detection responsiveness this cycle (mean and P90 time from CTI technical product to rule update or new rule), and where did event-driven triggers exceed the response budget.
8.How many log sources were onboarded this cycle, and which onboarding findings remain open against next-cycle in-scope techniques.
9.How many handoffs into SOC, AppSec, VM, IR, and CTI did the cycle produce, and what feedback came back from each receiver class.
10.Which template revision triggers fired this cycle, and what is the cycle owner plan for the template revision pass.

How the template pairs with SecPortal

The template above is copy-ready as a standalone artefact. If your team already runs engagement records, document custody, and finding tracking on a workspace, the detection engineering cycle becomes a byproduct of the work rather than a separate evidence project. SecPortal pairs every cycle to a versioned engagement record through engagement management, so the cycle identifier, the threat model input, the in-scope technique register, the log source coverage record, the rule lifecycle plan, the validation evidence, the false-positive backlog, the cycle metrics, the cross-team handoff record, and the framework anchor live alongside the rest of the security record rather than scattered across a wiki, a coverage spreadsheet, a SIEM console, and a Slack channel with the red team that ages out before the next cycle.

The findings management feature carries each missed-technique record with a CVSS-aligned severity, an ATT&CK tactic and technique tag, a named owner, a target close date, and an evidence-of-closure requirement, so the rule write decision in Section 5 advances on the same record the offensive operator opened the technique on. Retesting workflows pair the post-deployment replay (purple-team operation, BAS run, red-team replay) to the original missed-technique finding, so the aging clock keeps running on the original capture date and rule effectiveness sits on one record across the lifecycle. Document management holds the cycle template itself, the detection engineering charter, the rule-writing standard, the rule retirement policy, the validation playbook, and every prior cycle pack retained per the audit evidence retention policy. Access to each document is gated by role-based access control through team management and protected by multi-factor authentication. The activity log captures the timestamped chain of state changes by user with 30, 90, or 365-day retention windows depending on the plan, so the cycle open, the validation execution, the rule deployment, the sign-off chain, and the cycle close are all observable rather than asserted.

The finding overrides feature captures the suppression decisions and the accepted-coverage gaps with the linked finding, the severity, the compensating control reference, the residual likelihood, the residual impact, the business rationale, the expiry, and the review cadence as a structured exception attached to the finding. The exception register reads as a queue of dated decisions with named owners and explicit expiry, so the cycle governance forum reads exceptions that are actually due rather than re-debating the same items. Bulk finding import supports CSV-based ingestion of missed-technique findings from third-party BAS exports, ATT&CK coverage spreadsheets, and red-team after-action lists so the input streams in Section 3 land on the workspace at the cadence the source publishes. Notifications and alerts dispatches the cycle-cadence reminders, the validation milestones, the noise-budget breach pages to the cycle owner, and the cross-team handoff notifications. Compliance tracking maps the cycle records to NIST CSF 2.0 DE.CM and DE.AE, NIST SP 800-53 SI-4 and AU-2 and AU-6 and SI-2, SOC 2 CC7.2 and CC7.3, ISO 27001 Annex A 8.16 and A 8.15 and A 5.30, PCI DSS Requirement 10 and 12.10, NIS2 Article 21, and DORA Article 6 and 9 and 17 with CSV export, so when an auditor asks how the firm operates a chartered detection engineering function, the cycle artefact, the rule register, the validation evidence, the governance forum minute book, the cycle metrics, and the corrective action chain are one query against the same data. The AI report generation workflow drafts the cycle summary, the rule lifecycle pack, the validation evidence brief, and the quarterly governance review pack from the same engagement data so the audit committee read of detection performance, the sponsor read of programme value, the consumer read of cycle relevance, and the operational read of cycle workload are the same record rather than four independently edited summaries.

SecPortal is not a SIEM, is not a SOAR, is not an XDR platform, is not an EDR, does not deploy detection rules into Splunk, Microsoft Sentinel, IBM QRadar, Google Chronicle, Sumo Logic, Elastic Security, CrowdStrike Falcon, SentinelOne, Carbon Black, Microsoft Defender for Endpoint, Wazuh, Securonix, Exabeam, LogRhythm, Devo, Datadog Cloud SIEM, or Panther, does not run BAS playbooks against Atomic Red Team, Caldera, Cymulate, AttackIQ, SafeBreach, Mandiant Security Validation, Picus Security, Scythe, or Prelude Operator, does not ship native ATT&CK Navigator export, does not federate to Sigma rule repositories, does not parse SIEM telemetry, and does not produce live ATT&CK heatmaps. The engineers run the cycle and the rules in their platforms; the template codifies the procedure; SecPortal carries the durable workspace record the cycle produces and the audit reads after. For the audience reading the cycle into the leadership view, see SecPortal for detection engineering teams, SecPortal for SOC analysts, and SecPortal for security operations leaders. For the upstream CTI runbook the cycle consumes, see the threat intelligence program runbook template. For the operational workflow that ships the validation cycle, see the purple-teaming use case and the breach and attack simulation explainer. For the wider validation-cycle economics frame, see detection validation cycle economics. For the wider detection-and-response platform context, see the extended detection and response explainer and the managed detection and response explainer. For the SOAR side that the alerting-mode rules in Section 5 feed into, see the security orchestration, automation, and response explainer. For the methodology framework that the in-scope technique register reads against, see MITRE ATT&CK. For the compliance anchors the cycle records feed, see the framework pages for ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, NIS2, and DORA. When you are ready to anchor the cycle artefact on the live workspace, start a free SecPortal workspace and open the first detection engineering engagement against this template.

Loading tool...

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Verify fixes and track reopens on the same finding record

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Finding overrides that survive every scan cycle

Bulk finding import bring your scanner data with you

Purple team operations

Threat intelligence driven vulnerability prioritisation

Continuous Threat Exposure Management

Security leadership reporting

Incident response

Security testing program management

Zero-day and emergency vulnerability response

Security finding ownership and routing

Run the detection engineering cycle on the live workspace, not on a side spreadsheet

SecPortal pairs every cycle to a versioned engagement record so the in-scope technique register, the log source coverage record, the rule lifecycle plan, the validation evidence, the false-positive backlog, the cycle metrics, the cross-team handoff record, and the framework anchor all live on one workspace with named-actor activity log. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Detection Engineering Cycle Templatetwelve sections that turn ad hoc detection rule writing into a defensible operating cycle

Twelve sections that turn detection engineering into a defensible operating cycle

1. Cycle header and version control

2. Cycle charter, scope, and authority

3. Threat model input and ATT&CK technique scope

4. Log source coverage check and ingestion fitness

5. Rule lifecycle plan with write, tune, retire, carry-forward decisions

6. Validation pattern with purple-team, BAS, and red-team handoff

7. False-positive triage backlog and noise budget

8. Detection content register and platform target stack

9. Cycle metrics and quarterly governance review

10. Operating cadence with calendar and event-driven triggers

11. Cross-team handoff with SOC, AppSec, VM, IR, and threat intelligence

12. Cycle governance, sign-off, and template revision

Eight failure modes the cycle template has to design against

No ATT&CK scope at all

Rules written against techniques whose log source is not ingested

No validation pattern

False-positive backlog that grows without ever shrinking

Rules retired without compensating control evidence

Detection content register that drifts from the operational platform stack

Cross-team handoff that broadcasts but never listens

Cycle that never closes

Ten questions the quarterly governance review has to answer

How the template pairs with SecPortal

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Verify fixes and track reopens on the same finding record

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Finding overrides that survive every scan cycle

Bulk finding import bring your scanner data with you

Purple team operations

Threat intelligence driven vulnerability prioritisation

Continuous Threat Exposure Management

Security leadership reporting

Incident response

Security testing program management

Zero-day and emergency vulnerability response

Security finding ownership and routing

Run the detection engineering cycle on the live workspace, not on a side spreadsheet

Twelve sections that turn detection engineering into a defensible operating cycle

1. Cycle header and version control

2. Cycle charter, scope, and authority

3. Threat model input and ATT&CK technique scope

4. Log source coverage check and ingestion fitness

5. Rule lifecycle plan with write, tune, retire, carry-forward decisions

6. Validation pattern with purple-team, BAS, and red-team handoff

7. False-positive triage backlog and noise budget

8. Detection content register and platform target stack

9. Cycle metrics and quarterly governance review

10. Operating cadence with calendar and event-driven triggers

11. Cross-team handoff with SOC, AppSec, VM, IR, and threat intelligence

12. Cycle governance, sign-off, and template revision

Eight failure modes the cycle template has to design against

No ATT&CK scope at all

Rules written against techniques whose log source is not ingested

No validation pattern

False-positive backlog that grows without ever shrinking

Rules retired without compensating control evidence

Detection content register that drifts from the operational platform stack

Cross-team handoff that broadcasts but never listens

Cycle that never closes

Ten questions the quarterly governance review has to answer

How the template pairs with SecPortal

Detection Engineering Cycle Template
twelve sections that turn ad hoc detection rule writing into a defensible operating cycle