SI-7(7): Integration of Detection and Response

The si-7(7): integration of detection and response requirement is a bridge control: it connects integrity monitoring (detecting unauthorized changes) to incident response (acting on those detections). Many programs already have “detection” via EDR, SIEM, file integrity monitoring, cloud audit logs, or CI/CD controls. The common gap is operational: alerts exist, but they do not reliably trigger IR intake, or they trigger it inconsistently depending on who is on call.

SI-7(7) is written as an enhancement to system integrity controls, but assessors will test it like an IR operational capability. They will look for defined unauthorized-change scenarios, a clear path from detection to incident handling, and evidence that the process runs in production. If you only show tool configuration (for example, “we collect logs”), you will struggle. If you only show an IR plan (“we investigate”), you will also struggle.

This page gives requirement-level implementation guidance you can put into a control narrative, a runbook, and an evidence plan. It is written for a Compliance Officer, CCO, or GRC lead who needs a practical build-and-prove approach aligned to NIST SP 800-53 Rev. 5. ¹

Regulatory text

Requirement (verbatim excerpt): “Incorporate the detection of the following unauthorized changes into the organizational incident response capability: {{ insert: param, si-07.07_odp }}.” ²

Operator translation (what you must do):

1. Decide what “unauthorized changes” are in your environment (this is the organization-defined parameter). Examples typically include unauthorized changes to system files, security configurations, privileged accounts, audit settings, production images, IaC templates, or critical SaaS settings.
2. Ensure you can detect those changes through technical means (tooling, logs, integrity checks) with enough fidelity to investigate.
3. Integrate detections into incident response so detections are not passive. They must drive consistent IR intake and handling: triage, assignment, investigation, containment, eradication, recovery, and lessons learned as appropriate for severity.

This control is satisfied when unauthorized-change detections are treated as first-class IR signals with documented procedures and repeatable evidence. ¹

Plain-English interpretation of the requirement

SI-7(7) expects you to answer one question with proof: “If we detect an unauthorized change, do we respond like it is an incident?” That means:

• Alerts have owners (SOC, SRE, SecOps, CloudSec, AppSec) and routes (SIEM queue, on-call, ticketing).
• Alerts have decision criteria (false positive handling, severity thresholds, escalation triggers).
• Response is documented and repeatable, not dependent on tribal knowledge.

A practical mental model: unauthorized change detection is your “smoke detector,” and IR is your “fire response.” SI-7(7) requires a working connection between the two.

Who it applies to (entity and operational context)

SI-7(7) is relevant anywhere you use NIST SP 800-53 controls, especially:

• Federal information systems implementing NIST SP 800-53 baselines. ³
• Contractor systems handling federal data where 800-53 controls are flowed down contractually or through an authorization boundary. ³

Operationally, it applies to environments where unauthorized changes create material risk:

• Production infrastructure (on-prem, cloud, hybrid)
• CI/CD and build pipelines that can alter production artifacts
• Identity and access systems (IdP, PAM)
• Security tooling configurations (EDR policies, SIEM rules, logging settings)
• High-impact business applications and SaaS admin planes

If your boundary includes third parties (managed service providers, SaaS platforms, outsourced admins), unauthorized changes can originate there too. Your IR integration must cover those signals and escalation paths.

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

Step 1: Define “unauthorized change” events (your SI-7(7) parameter)

Create a short list of change categories that will be treated as IR-relevant. Keep it tight and defensible. Start with:

• Integrity changes: critical binaries, containers, golden images, signed artifacts
• Security control drift: logging disabled, EDR uninstalled, MFA policy weakened
• Privilege changes: new admin roles, access policy changes, new API keys
• Network exposure changes: firewall/security group opened broadly, new public endpoints
• Application release anomalies: out-of-band production deploys

Deliverable: “Unauthorized Change Event Catalog” with category, examples, data source, and response owner.

Step 2: Map each event to a detection source and a responder

For each event category, fill out a mapping table:

Unauthorized change event	Primary signal source	Alert destination	Response owner	Initial action
Logging disabled	Cloud audit logs / config monitoring	SIEM + ticket	SecOps	Restore logging, preserve evidence
New admin role	IdP audit logs	SIEM + pager	IAM	Validate change request, revoke if unauthorized
Out-of-band deploy	CI/CD logs + production change logs	Ticket	AppSec/SRE	Rollback, check pipeline compromise

This table becomes your assessor-ready narrative: detection is defined, routed, and owned.

Step 3: Connect detections to IR intake (tickets/incidents) with rules

You need a deterministic path from alert to IR workflow:

• Send alerts to a central queue (SIEM/SOAR/case management) or to your service desk with an “IR candidate” classification.
• Define auto-ticket creation rules for high-risk unauthorized changes (for example, security logging disabled).
• Add minimum required fields: timestamp, asset ID, actor identity, change diff, source log reference, and recommended next steps.

Evidence to plan for: screenshots/config exports of routing rules, sample alert payloads, and ticket templates.

Step 4: Create playbooks for each unauthorized-change category

For every event category, write a short playbook:

• Triage: validate alert fidelity; check approved change windows; confirm actor identity
• Scope: identify impacted assets/accounts; check for related alerts
• Containment: disable compromised credentials; isolate host; block suspicious IPs
• Eradication/Recovery: revert unauthorized config; restore from known-good; re-enable controls
• Post-incident: root cause, preventive control improvements, detection tuning

Keep playbooks aligned to your existing IR plan. SI-7(7) does not require reinventing IR; it requires integrating these detections into it. ³

Step 5: Test the end-to-end workflow and retain proof

Run controlled tests that simulate at least one unauthorized change per category (where feasible):

• Disable a non-production logging setting and confirm: alert → ticket → triage notes → remediation.
• Create a temporary admin role in a sandbox and confirm: detection triggers, approval validation, rollback.

Retain evidence that shows the full chain, not just the test plan.

Step 6: Operationalize ownership, cadence, and evidence

Assign a control owner and set recurring checkpoints:

• Rule review and tuning (false positives, missed detections)
• Playbook review (org changes, tool changes)
• Evidence capture (monthly samples or per-incident retention)

Daydream fit (earned, not forced): Teams struggle most with evidence continuity. Daydream can map SI-7(7) to a control owner, document the implementation procedure, and schedule recurring evidence requests so you always have recent alert-to-incident samples ready for assessment.

Required evidence and artifacts to retain

Keep artifacts that prove design and operating effectiveness:

Design evidence

• Unauthorized Change Event Catalog (the organization-defined parameter content)
• Detection-to-IR mapping table (signal source → routing → owner → action)
• IR procedures/playbooks that explicitly reference unauthorized-change detections
• Tool configurations for alert routing (SIEM/SOAR rules, ticketing integrations)

Operating evidence

• Sample incidents/tickets created from unauthorized-change alerts (sanitized)
• Alert payloads and correlated logs showing: who/what/when/where
• Analyst notes showing triage decisions and closure rationale
• Change approval cross-check evidence (link to CAB record or change ticket, when authorized)
• Tabletop/test records demonstrating the workflow works

A common assessor expectation: you can produce “one or more” recent examples quickly, with timestamps and traceability from alert to closure.

Common exam/audit questions and hangups

• “Show me where unauthorized change detections enter your incident response process.”
• “What changes are in scope for SI-7(7), and who approved that scope?”
• “How do you distinguish authorized vs unauthorized changes during maintenance windows?”
• “Do you open incidents automatically, or do analysts manually convert alerts? Show the criteria.”
• “Provide a recent example where an unauthorized change alert led to containment or rollback.”
• “What happens if the change occurs in a third-party-managed system?”

Hangup to anticipate: teams present change management controls as a substitute. Change management helps determine authorization, but SI-7(7) requires detection integrated with IR.

Frequent implementation mistakes and how to avoid them

1. Mistake: “We log it” equals “we integrated it.”
   Fix: prove routing into IR intake and show response actions in tickets.

2. Mistake: Undefined “unauthorized changes.”
   Fix: publish an explicit event catalog with an owner and review cadence.

3. Mistake: Alerts go to email or a chat room with no case tracking.
   Fix: enforce ticket or case creation for defined categories.

4. Mistake: No link to authorization checks (CAB/change tickets).
   Fix: add a triage step requiring validation against approved changes and recording the reference.

5. Mistake: Over-scoping with hundreds of noisy detections.
   Fix: start with the highest-risk integrity and security control drift events, then expand after tuning.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions.

Risk-wise, SI-7(7) exists because unauthorized changes often indicate compromise, insider activity, or control failure. If detections do not drive response, you can end up with silent security control disablement, undetected persistence, or untracked production tampering. That turns a technical alerting gap into a governance problem: you had a signal and did not act.

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Name the SI-7(7) control owner and responders for each system tier.
• Draft the Unauthorized Change Event Catalog for critical systems.
• Build the mapping table (event → detection source → routing → owner).
• Confirm alert routing creates a trackable case (ticket/case management) for the top event categories.

Days 31–60 (Prove the workflow)

• Write playbooks for each event category and align them to your IR plan.
• Run controlled tests in non-production (or safe production scenarios) and capture end-to-end evidence.
• Add triage requirements: authorization validation, evidence preservation, escalation triggers.

Days 61–90 (Harden and make it auditable)

• Tune detections based on test outcomes and early production feedback.
• Establish recurring evidence capture: sample alerts, cases, and closure notes.
• Add third-party escalation paths where managed services or SaaS admins can introduce unauthorized changes.
• Store everything in a single control record (Daydream or your GRC) with assigned owners and an evidence checklist.

Frequently Asked Questions

What counts as an “unauthorized change” for SI-7(7)?

It’s organization-defined, so you must explicitly list the change types in scope and treat detections of those changes as IR inputs. Pick changes that meaningfully affect integrity, security configuration, or privileged access, then document the list and owners.

Do we need a SIEM/SOAR to meet SI-7(7)?

No. You need a reliable path from detection to incident handling with trackable records. A SIEM/SOAR helps, but a service desk ticketing workflow can satisfy the integration if it’s consistent and evidenced.

Can we satisfy SI-7(7) with change management approvals alone?

No. Change management helps determine whether a change is authorized, but SI-7(7) requires detection of unauthorized changes and incorporation of those detections into incident response activities. ²

How do we handle authorized maintenance windows without drowning in alerts?

Add triage steps that validate the alert against approved change records and document the reference. For recurring maintenance, tune rules to reduce noise, but keep detection for high-risk drift such as logging disabled.

What evidence is most persuasive to an assessor?

A recent sample showing alert details, automatic or manual case creation, analyst triage notes, authorization validation, remediation actions, and closure rationale. Configuration screenshots alone rarely show operational integration.

Does SI-7(7) apply to third-party-managed systems (MSPs/SaaS)?

Yes if those systems are in your authorization boundary or handle covered data. Define which third-party change events matter, ensure you receive the right logs/alerts, and document escalation and response ownership.

Footnotes

1. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5