Detection and analysis

The NIST SP 800-61 detection and analysis requirement expects you to reliably detect potential security incidents and run a consistent triage process that assigns severity and drives the right response path ¹. To operationalize it fast, define what “incident” means for your environment, implement detection coverage for priority log sources, and document a repeatable triage workflow with evidence.

Key takeaways:

• You need both signal (detection coverage) and decisioning (triage criteria) to meet the detection and analysis requirement ¹.
• Consistency is the point: same inputs, same severity rules, same escalation outcomes across teams and shifts ¹.
• Audit readiness depends on artifacts: alerts, triage notes, severity rationale, and metrics that show the workflow actually runs ¹.

“Detection and analysis” sounds like a SOC function, but for a Compliance Officer, CCO, or GRC lead it’s a requirement you must be able to explain, test, and evidence. NIST SP 800-61 frames this expectation succinctly: detect potential incidents and triage severity consistently ¹. That single sentence drives a surprising amount of operational design: what telemetry you collect, how alerts become cases, how analysts decide severity, and how you prove decisions were made the same way each time.

Most breakdowns happen in the handoffs. Monitoring exists, but it doesn’t cover the right systems. Alerts fire, but nobody can explain why one was “High” and another was “Low.” Or an incident gets handled in chat with no case record, so later you can’t show that you detected, analyzed, and escalated predictably. This page translates the detection and analysis requirement into implementable steps, required artifacts, and an execution plan you can run with your security and IT teams. The goal is simple: a detection-to-triage pipeline that is repeatable, reviewable, and defensible ¹.

Regulatory text

NIST SP 800-61 excerpt (requirement-level): “Detect potential incidents and triage severity consistently.” ¹

What the operator must do:

1. Detect potential incidents: Establish monitoring and alerting that can surface suspicious activity in the systems and services you rely on ¹.
2. Analyze and triage: Take each potential incident through a defined process to validate, categorize, and assign severity using documented criteria ¹.
3. Do it consistently: Ensure the same triage rules apply across teams, time periods, and event sources, with clear escalation triggers ¹.

This is a control-design requirement (the workflow exists and is documented) and a control-operating requirement (you can show it ran for real alerts) ¹.

Plain-English interpretation (what this really means)

You must be able to answer, with evidence:

• How do you find suspicious activity in your environment?
• How do you decide whether it’s an incident?
• How do you decide severity and urgency?
• How do you ensure two analysts would reach the same severity outcome given the same facts?

Consistency does not require perfect detection. It requires a defined process, coverage aligned to risk, and a triage method that produces repeatable decisions and escalations ¹.

Who it applies to (entity and operational context)

NIST SP 800-61 is widely used as incident handling guidance; in practice you should apply this requirement wherever you have operational responsibility for detecting and responding to security events ¹. Based on the provided applicability notes, it commonly fits:

• Critical Infrastructure Operators: Organizations where outages, safety impact, or systemic disruption risk makes early detection and disciplined triage essential.
• Service Organizations: SaaS, managed services, processors, and any organization that must detect and analyze incidents affecting customer data or service delivery.

Operational contexts where auditors will expect this to be concrete:

• Central SOC or outsourced SOC (MSSP) operations
• Cloud and on-prem hybrid environments
• High-value identity systems (SSO, IAM, privileged access)
• Customer-data platforms and production workloads
• Third-party-managed infrastructure where you still own incident accountability

What you actually need to do (step-by-step)

The fastest way to operationalize the detection and analysis requirement is to treat it like a pipeline: inputs → detection → triage → severity → escalation → records ¹.

Step 1: Define “potential incident” vs. “incident”

Create a short definition set that your analysts can apply:

• Security event: observable occurrence in a system or network.
• Potential incident: an event (or cluster) that warrants triage because it may violate policy or indicate compromise.
• Incident: confirmed adverse event meeting your incident criteria.

Tie these definitions to your incident response plan and ticketing categories so cases do not get lost in generic queues ¹.

Step 2: Establish detection coverage for priority log sources

Document your minimum detection inputs. Keep it practical and defensible:

• Identity/authentication logs (interactive and API where relevant)
• Endpoint security alerts (EDR/AV)
• Network/security controls (firewall, IDS/IPS where deployed)
• Cloud control plane logs (if you run cloud workloads)
• Key application logs for systems that store or process sensitive data

Create a simple “coverage map” that shows source → collection method → monitoring owner → retention location. This is the core evidence that you can “detect” ¹.

Step 3: Implement a documented triage workflow (single front door)

Write the workflow as a checklist that an on-call analyst can follow. Minimum stages:

1. Intake: alert arrives (SIEM, EDR console, email from third party, user report).
2. De-duplication and correlation: determine whether it’s already tracked.
3. Initial validation: confirm signal integrity (false positive checks, scope).
4. Classification: map to incident categories you recognize (e.g., unauthorized access, malware, data exposure).
5. Severity assignment: apply a defined severity rubric (see Step 4).
6. Escalation decision: route to incident commander / IR team / IT ops, based on severity and type.
7. Case creation and documentation: ensure the case record contains required fields (see “Artifacts” below).

Make the workflow the same regardless of who found it: internal tools, a third party, law enforcement outreach, customer report, or internal audit finding ¹.

Step 4: Define severity criteria that produce repeatable outcomes

Create a rubric that forces consistency. A workable approach:

• Impact dimension: business service impact, data impact, safety/regulatory impact.
• Scope dimension: number of systems/identities affected, lateral movement indicators.
• Confidence dimension: quality of evidence, confirmation status, corroborating telemetry.
• Urgency dimension: active exploitation indicators, persistence, privileged access involvement.

Turn that into a severity matrix (Low/Medium/High/Critical) with explicit escalation triggers ¹. The test: if you give two analysts the same facts, they should land on the same severity.

Step 5: Operationalize with tooling and roles (RACI)

Assign owners for each stage:

• Monitoring owner (SOC/MSSP)
• Triage owner (SOC lead/on-call)
• Incident commander (IR lead)
• Evidence custodian (security operations)
• Compliance/GRC reviewer (post-incident QA)

Ensure the triage workflow lives in the same system where cases are tracked. If you run this through chat and spreadsheets, you will fail the evidence test ¹.

Step 6: Add QA: post-triage review and tuning loop

Set a standing review to sample closed cases:

• Was severity justified by documented criteria?
• Were escalation and notifications consistent with severity?
• Did detection inputs exist for the affected system?
• Were false positives tuned appropriately?

This closes the loop between detection coverage and triage discipline ¹.

Step 7: Make it audit-ready (what “good” looks like)

NIST expects consistent triage; auditors will translate that into:

• Documented process
• Repeatable outputs
• Demonstrable operation over time ¹

Daydream (where it fits naturally): use Daydream to standardize the control narrative, map evidence requests to the detection coverage map and triage workflow, and keep a clean audit packet for each sampled incident record.

Required evidence and artifacts to retain

Keep evidence in a form you can export for an audit sample. Minimum artifact set:

• Detection coverage map (log sources and monitoring ownership)
• Triage SOP/runbook (current version, approval, change history)
• Severity rubric (matrix and definitions)
• Case records for sampled alerts/incidents, including:
  • Intake timestamp and source
  • Classification/category
  • Severity and rationale (which criteria were met)
  • Escalation path taken and timestamps
  • Containment/next-step assignment (even if later determined benign)
• Alert snapshots or immutable references (SIEM event IDs, EDR alert IDs)
• Triage QA records (review notes, tuning actions)
• Training/enablement records for triage staff (who is authorized to assign severity)

Common exam/audit questions and hangups

Expect these questions, and pre-build the answers:

• “Show me how you detect potential incidents in your highest-risk systems.” ¹
• “Walk me through your triage process from alert intake to severity.” ¹
• “How do you ensure consistent severity scoring across analysts and shifts?” ¹
• “Provide examples where severity triggered escalation. Show timestamps.” ¹
• “How do you handle detection from third parties (MSSP, cloud provider, key vendor)?” ¹

Hangups auditors fixate on:

• Missing severity rationale (severity recorded but no justification)
• No proof the workflow runs the same way across sources
• Inability to show coverage for the affected asset because inventory and logging don’t match

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “We have a SIEM” as the whole control story.
   Fix: document detection coverage and show that alerts become triaged cases with severity outcomes ¹.

2. Mistake: Severity = analyst intuition.
   Fix: severity rubric with criteria, and require the case to cite criteria met ¹.

3. Mistake: Multiple intake channels with no single case system.
   Fix: one front door for intake, or a mandatory step to create a case record for every triaged alert ¹.

4. Mistake: No linkage between detection and asset criticality.
   Fix: align coverage map to “crown jewels” and critical services first; document exclusions and compensating monitoring ¹.

5. Mistake: Outsourced SOC with weak oversight.
   Fix: require the third party to follow your triage rubric, deliver case exports, and participate in QA reviews; keep your own evidence copy ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is straightforward: weak detection and inconsistent triage increase dwell time, delay containment, and create gaps in incident reporting decision-making because you can’t show how you reached severity determinations ¹. For regulated environments, inconsistent triage also creates audit findings because the control cannot be tested reliably.

Practical 30/60/90-day execution plan

First 30 days: stabilize definitions and workflow

• Publish event/potential incident/incident definitions aligned to your IR plan ¹.
• Create a single triage SOP with a required case template (mandatory fields for severity rationale) ¹.
• Stand up a detection coverage map for top systems and identity layer; document gaps and owners.

Days 31–60: make severity consistent and testable

• Implement a severity rubric and require rubric citations in every case record ¹.
• Train the SOC/on-call rotation and confirm they can run the workflow without tribal knowledge.
• Run tabletop triage drills using realistic alerts; confirm consistent scoring and escalation.

Days 61–90: operational QA and audit packet

• Start a recurring QA review of closed triage cases; track tuning actions to closure ¹.
• Produce an audit-ready “sample packet” template: alert evidence + triage notes + severity rationale + escalation timestamps.
• If you use a third party SOC, add contract/SOW language for evidence delivery and rubric adherence, and test it with a sample pull.

Frequently Asked Questions

Do I need a SOC to meet the detection and analysis requirement?

No. You need detection coverage and a consistent triage workflow that produces documented severity decisions ¹. A small team can meet this with clear intake, logging, and case management discipline.

What does “consistently” mean in practice for severity triage?

It means you have documented criteria and analysts apply them the same way across cases ¹. Auditors look for severity rationale tied to the rubric, not just a label.

Can my MSSP handle triage, or do I have to do it internally?

An MSSP can perform triage, but you still need governance: your rubric, your workflow expectations, and your retained evidence ¹. Make evidence delivery and QA participation part of the operating model.

What evidence should I produce for a sample of alerts that were false positives?

Keep the alert reference, the triage notes showing validation steps, and the closure reason ¹. False positives still prove the triage process operates.

How do I handle incidents reported by third parties (customers, law enforcement, vendors)?

Treat them as intake sources into the same case workflow, then apply the same validation and severity rubric ¹. Record the source, what was claimed, what you confirmed, and what you escalated.

What’s the fastest way to become audit-ready if we’re starting from scratch?

Start with a triage SOP, a severity rubric, and a case template that forces documentation of severity rationale ¹. Then build a detection coverage map for your highest-risk systems and keep sample packets for recent alerts.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. NIST SP 800-61