For detection engineering teams
who run the rule lifecycle as a structured engagement record

A detection engineering workspace built around the technique and the rule it covers

Detection engineering teams own the workflow that sits between the threat model, the ATT&CK coverage matrix, the rule register, the false-positive backlog, the SIEM and SOAR target stack, the log source inventory, the alert-to-case tuning record, the purple-team operations log, and the audit-evidence trail into NIST CSF 2.0 DE, NIST SP 800-53 SI and AU, SOC 2 CC7, ISO 27001 A.8.16, and PCI DSS Requirement 10. The work usually carries across a SIEM console, a SOAR console, a coverage spreadsheet, a rule repository on Git, a false-positive ticket queue, a Slack channel with the red team that ages out before the next operation, and a steering committee deck that gets rebuilt from scratch every cycle. The cost is not the licensing. It is the reconciliation hours each cycle and the coverage drift between cycles.

SecPortal gives detection engineering teams one workspace for engagement records per detection workstream, findings management with CVSS 3.1 scoring and MITRE ATT&CK tactic, technique, and sub-technique tags on every finding, retesting workflows that pair the post-deployment replay to the original missed technique, document management for the detection engineering charter and the rule-writing standard and the rule retirement policy, compliance tracking that covers NIST CSF 2.0 DE, NIST SP 800-53 SI and AU families, SOC 2 CC7, ISO 27001 A.8.16, PCI DSS Requirement 10, and the other 21 supported frameworks in parallel, AI-assisted programme reporting, role-based access control with enforced multi-factor authentication, and an append-only activity log on one workspace that the red-team partner, the purple-team partner, the SOC partner, and the audit observer all share with the detection engineering team.

SecPortal is not a SIEM, a SOAR, a UEBA platform, an XDR or EDR platform, a log management system, a detection-as-code rule store, or a Sigma rule library. It does not ingest event telemetry from endpoint, network, identity provider, cloud platform, or application sources, it does not run correlation logic, it does not author detection content on the platform itself, it does not ship a Sigma or Snort rule pack, and it does not connect through API to a SIEM, a SOAR, a UEBA platform, an XDR, or a ticketing tool. Teams running a dedicated SIEM, SOAR, UEBA, XDR, or detection-as-code platform keep that detection platform; SecPortal carries the engagement, the technique finding, the coverage outcome, the rule lifecycle record (referenced by rule identifier and platform target), the retest run, the exception decision, the documentation, and the audit trail next to those platforms rather than inside them.

Capabilities detection engineering teams use cycle to cycle

How detection engineering teams run the discipline inside SecPortal

A detection engineering programme that holds up under audit fieldwork, board questioning, cyber insurance underwriting, and post-incident review operates on a small set of disciplines. The detection engineering charter, the rule-writing standard, the rule retirement policy, the false-positive runbook, the coverage matrix, the rule register, and the audit-evidence trail inherit each one rather than carving out a parallel operating model per artefact.

From technique fired to rule written to replay verified, on one engagement record

The detection programme loop is open the detection workstream engagement, log the techniques that get exercised against the organisation, write the detection content against each missed or partially detected technique, replay after tuning, map the controls, record the exceptions, route the cross-team work, regenerate the leadership view, and read the recurring cadence. SecPortal runs a single workflow that the detection engineering team, the red-team partner, the purple-team partner, the SOC partner, the audit committee, and the steering committee can all work against without re-keying state into another tool.

1. 1Open an engagement per detection workstream. Capture the workstream owner, the scope (the ATT&CK matrix section, the threat actor profile, the asset class, the log source set, the SIEM and SOAR target stack), the applicable framework set (MITRE ATT&CK as methodology reference, NIST CSF 2.0 DE function, NIST SP 800-53 SI and AU families, SOC 2 CC7, ISO 27001 A.8.16, PCI DSS Requirement 10), the in-scope offensive partner, the in-scope SOC partner, and the named audit observers on the engagement record. Attach the detection engineering charter, the rule-writing standard, the rule retirement policy, the log source inventory, and the detection RACI as documents.
2. 2Run technique findings against the engagement record. Red-team operators log techniques against the engagement they exercised them on; purple-team operations log techniques and detections in parallel against the same engagement; threat-led penetration test reports and breach-and-attack-simulation exports import in bulk; tabletop technique outcomes log manually. Each finding carries the ATT&CK tactic, the technique identifier, the sub-technique identifier, the CVSS 3.1 vector, severity, evidence, named owner, and the detection outcome.
3. 3Write the detection content against the finding rather than against a separate rule backlog. A missed technique gets a rule, a query, or a correlation logic written by a named detection engineer with the rule identifier, the platform target, the query or rule body summary, the test traffic, and the deployment status logged on the same finding. The aging clock keeps running on the original capture date.
4. 4Replay after tuning. Once the rule is deployed, the offensive partner or the breach-and-attack-simulation tool replays the technique and the detection engineer logs the post-deployment outcome on the same finding. The retest run targets the same engagement, validates the rule, and moves the finding state from in_progress to resolved or verified on the engagement record. The activity log records who verified what against which retest run with timestamp and rationale.
5. 5Map findings, technique coverage, and engagement records against the NIST CSF 2.0 DE function (Detect, with DE.CM continuous monitoring and DE.AE adverse event analysis categories), NIST SP 800-53 SI and AU control families, SOC 2 CC7 Trust Services Criteria, ISO 27001 A.8.16 monitoring activities, PCI DSS Requirement 10, HIPAA Security Rule audit controls, and the other supported frameworks through compliance tracking. The audit-time evidence packs read from the same engagement records the detection team operates on.
6. 6Capture exceptions, compensating controls, and accepted-gap decisions on long-tail techniques where coverage cannot be written, on rules that need to stay suppressed for noise reasons, on missed-by-design techniques outside the threat model, and on log sources the platform cannot ingest yet on the same record as the findings they cover. The exception register reads as a queue of dated decisions with named owners and explicit expiry, so the detection steering committee reads exceptions that are actually due rather than re-debating the same items.
7. 7Route the work through role-based access control and multi-factor authentication. Detection engineers see the engagements for the workstreams they operate, the rule reviewer reads the rule register and the rule retirement queue, the SOC partner reads the alert-to-case threshold tuning record, the red-team partner reads the purple-team operations they share with the detection team, audit observers read the programme posture across the detection estate without seeing the full operational backlog, and the steering committee reads the leadership view that regenerates on demand.
8. 8Regenerate the detection leadership view through AI-assisted reporting. Executive summaries, per-engagement coverage readouts, purple-team operation narratives, rule retirement cycle summaries, false-positive remediation summaries, SIEM migration progress writeups, and detection compliance summaries draft from the live engagement data on demand. The detection team edits drafts rather than writes the deck from a blank page each cycle.
9. 9Read the recurring programme cadence from the append-only activity log. Every finding update, scan run, document upload, retest run, exception decision, comment, credential rotation, and team change is recorded with the actor, the timestamp, and the action. CSV export keeps the programme trail reproducible at regulator review time.

Where the detection engineering view connects to the rest of the workspace

Most detection engineering functions adopt SecPortal in three phases: bring every detection workstream onto an engagement record so the coverage matrix, the rule register, the false-positive backlog, and the findings live on one record; pair the engagement records with the red-team and purple-team partner so the technique log and the detection write-up share the same finding; and route the audit, steering committee, and SOC leadership cadence through compliance tracking, role-based access control, multi-factor authentication, and AI-assisted reporting so the rule reviewer, the SOC partner, and the audit committee all read from the same source the detection team runs on. The relevant capability, workflow, framework, and blog pages explain each phase in detail.

• The engagement record model that anchors every detection workstream is covered on the engagement management feature page, the per-workstream findings repository with ATT&CK tagging on the findings management feature page, and the rule register, charter, and standard attachment surface on the document management feature page.
• The post-deployment replay loop that pairs to the missed-technique finding on the retesting workflows feature page, the multi-framework control mapping a single engagement record rides on the compliance tracking feature page, and the AI-assisted detection programme reporting surface on the AI reports feature page.
• The append-only programme trail across every detection workstream on the activity log feature page, the role-scoped access for detection engineers, rule reviewers, SOC partners, and audit observers on the team management feature page, and the enforced multi-factor authentication on every workspace account on the multi-factor authentication feature page.
• The MITRE ATT&CK methodology anchor on the MITRE ATT&CK framework page, the NIST CSF 2.0 Detect function evidence anchor on the NIST CSF 2.0 framework page, and the NIST SP 800-53 SI and AU family evidence anchor on the NIST 800-53 framework page.
• The SOC 2 Trust Services Criteria anchor for the CC7 monitoring controls on the SOC 2 framework page, the ISO 27001 framework anchor for Annex A.8.16 monitoring activities on the ISO 27001 framework page, and the PCI DSS framework anchor for Requirement 10 logging and monitoring on the PCI DSS framework page.
• The purple-team operating workflow where offensive and defensive operators share the same finding on the purple teaming use case, the pentest-to-detection-engineering handover workflow on the pentest finding handover to SOC use case, and the threat-led penetration testing workflow on the threat-led penetration testing use case.
• The exception register for accepted-gap decisions and rule suppression decisions on the vulnerability acceptance and exception management use case, the security finding fix verification workflow on the security finding fix verification use case, and the retesting workflow that pairs the post-deployment replay to the original missed-technique finding on the retesting use case.
• The red-teaming workflow on the red teaming use case, the security operations orchestration explainer on the SOAR explainer, and the red team versus penetration test article on the red team versus penetration test article.

Where the detection engineering team role sits next to adjacent personas

Detection engineering teams run the rule-and-content discipline that sits between the offensive operator function (the in-house red team), the defensive responder function (the SOC analyst), the platform-owner function (the security engineering team), the GRC and compliance evidence owner, the cross-source vulnerability management backlog owner, the application security discipline, the executive sponsor (the CISO), and the cross-team programme coordinator (the security program manager). The detection engineering team owns the rule lifecycle rather than any one of those adjacent shapes.

If your function is the in-house red team that exercises techniques against the organisation as a continuous programme, the SecPortal for in-house red teams page covers the offensive operator shape that pairs to the detection engineering discipline on the shared engagement record.

If your function is the SOC analyst function that triages the alerts the detection content generates and operates the incident response on top, the SecPortal for SOC analysts page covers the alert-consumer shape that pairs to the detection engineering content author shape.

If your function is the security engineering platform discipline that owns the SIEM, the SOAR, the log pipeline, and the detection-as-code tooling that the detection engineering team writes against, the SecPortal for security engineering teams page covers the platform-owner shape the detection content runs on.

If your function is the application security discipline that owns the AppSec testing backlog and the application-side findings the detection layer should also catch, the SecPortal for AppSec teams page covers the application security shape that feeds findings into the same workspace the detection team operates on.

If your function is the cross-source vulnerability management backlog owner that consolidates the detection-adjacent findings into the wider security backlog, the SecPortal for vulnerability management teams page covers the unified queue discipline that the detection-adjacent findings land on.

If your function is the GRC and compliance evidence owner that assembles audit packs from detection controls into NIST CSF 2.0 DE, NIST SP 800-53 SI and AU, SOC 2 CC7, ISO 27001 A.8.16, and PCI DSS Requirement 10, the SecPortal for GRC and compliance teams page covers the evidence-side discipline that reads from the same record the detection team operates on.

If your function is the internal security team that runs the consolidated security programme across detection engineering, AppSec, vulnerability management, identity, and incident response, the SecPortal for internal security teams page covers the consolidated workspace view the detection programme rolls into.

If your function is programme-level executive sponsorship and board-level reporting rather than the detection discipline specifically, the SecPortal for CISOs and security leaders page covers the leadership-tier reporting workflow the detection posture rolls up into.

SecPortal is built for detection engineering teams who want one workspace for the log-coverage-write-replay-map-report loop on the detection surface: engagement records per detection workstream, technique findings with MITRE ATT&CK tactic and technique and sub-technique tags, the rule write-up and the post-deployment replay paired to the original missed-technique finding, multi-framework compliance tracking that covers NIST CSF 2.0 DE, NIST SP 800-53 SI and AU, SOC 2 CC7, ISO 27001 A.8.16, and PCI DSS Requirement 10 in parallel, AI-assisted programme reporting, role-based access control with enforced multi-factor authentication, document management for the detection engineering charter, rule-writing standard, and rule retirement policy, and an append-only activity log on top. The rule reviewer reads the rule retirement queue, the SOC partner reads the alert-to-case threshold tuning record, the red-team partner reads the shared engagements, the audit committee reads the programme posture, and the detection team gets back the hours that used to disappear into reconciliation between coverage spreadsheets, rule repositories, false-positive ticket queues, and steering committee decks.