Incident Response
From first alert to closed case with a full timeline
ManySignal assembles the attack timeline, dispatches approval-gated containment, and generates the post-incident report automatically. Investigators start with context — not a blank canvas and a pile of raw logs.
Incident response, end to end
Case timeline built automatically
When an alert escalates to an incident, ManySignal assembles the full attack timeline automatically — first seen indicator, lateral movement events, privilege escalation, data access anomalies — ordered chronologically from connected telemetry. Investigators start with context, not a blank canvas.
- Events correlated from all connected data sources
- Chronological timeline with entity annotations
- MITRE technique labels on every event in the chain
Case timeline built automatically
Containment with one-click dispatch
Approved response actions dispatch from inside the case. Isolate the endpoint, disable the user account, revoke cloud session tokens, block the network destination. Each action requires approval based on your configured policy before execution, and rolls back automatically if the response workflow specifies it.
- Approval-gated containment per action class
- Rollback plans included in high-risk action workflows
- All actions logged with executor identity and timestamp
Containment with one-click dispatch
Post-incident report in the case
When a case closes, the Report agent generates a structured post-incident document: timeline, root cause, affected assets, containment actions taken, gaps that enabled the attack, and hardening recommendations. Delivered to the case automatically — ready for the incident review meeting.
- Executive summary and technical timeline in one document
- Root cause and contributing factor analysis
- Recommended hardening steps mapped to specific controls
Post-incident report in the case
Sample playbook — Account Compromise
ManySignal playbook YAML. Approval-gated, rollback-aware, with automatic evidence gathering.
# ManySignal Incident Response Playbook
# Type: Account Compromise - High Confidence
# Trigger: Triage verdict >= 85 + identity anomaly score >= 70
name: account_compromise_response
version: "2.4"
trigger:
verdict: true_positive
confidence_min: 85
techniques: ["T1078", "T1556", "T1621"]
steps:
- action: gather_evidence
parallel: true
tasks:
- query: identity.login_history(entity=user, window=30d)
- query: endpoint.process_events(entity=devices, window=24h)
- query: cloud.api_calls(entity=user, window=24h)
- action: require_approval
message: "Account compromise detected. Approve disable action."
approvers: [on_call_analyst, security_lead]
timeout_minutes: 15
on_timeout: escalate_to_ciso
- action: disable_user_account
provider: okta
reversible: true
rollback_trigger: false_positive_confirmed
- action: revoke_sessions
providers: [okta, azure_ad, google_workspace]
- action: notify
channels: [slack_security, jira_ticket, pagerduty]
- action: generate_report
template: account_compromise_postmortem28min
median time to close — account compromise
100%
of cases include automated timeline
0
containment actions without approval record
1-click
rollback for reversible actions
Incident response — common questions
How is this different from running a SOAR playbook on an alert?
SOAR playbooks execute a pre-written sequence of steps. ManySignal's incident response starts with a dynamically assembled case — the attack timeline, affected entities, MITRE technique mapping — and then runs approval-gated response actions against that specific incident context. The response is tailored to what actually happened, not a generic template.
Can we customize the response playbooks?
Yes. Playbooks are written in ManySignal's YAML format and version-controlled within the platform. You can create custom playbooks for specific incident types, require different approval chains per action, and set playbook-specific rollback conditions.
How do we handle incidents that span multiple cloud environments?
ManySignal correlates events across all connected sources — AWS, Azure, GCP, Okta, on-prem AD — into a single case timeline. Response actions dispatch across all relevant environments from the same case. A single compromise incident spanning cloud and on-prem shows up as one case, not one alert per platform.
What integrations are available for case escalation?
Cases integrate with Jira, ServiceNow, PagerDuty, Opsgenie, Slack, and Microsoft Teams. Escalation routing uses your configured on-call schedule. Ticket creation and case status sync are bidirectional — changes in your ticketing system reflect in ManySignal and vice versa.
How long does a typical incident take from detection to close?
In environments where ManySignal has been running for more than 30 days, the median time from first detection to case close for confirmed account compromise incidents is 28 minutes. This includes triage, approval-gated containment, and initial evidence collection. Complex ransomware or nation-state incidents have longer timelines reflecting their scope.
How does ManySignal's post-incident report support regulatory notification requirements?
The post-incident report generated at case close includes the fields required for most regulatory notifications: incident discovery timestamp, attack timeline, categories of data accessed, estimated scope (number of affected users, systems), containment actions and timestamps, and root cause classification. The GDPR Article 33 section pre-populates from this report, and the case evidence package contains the SHA-256 hashed logs required for chain-of-custody. The report exports as a structured PDF formatted for regulator and cyber insurance submissions.
What is the rollback procedure if a containment action causes unintended business disruption?
Every reversible containment action — account disable, endpoint isolation, IP block — has a one-click rollback accessible from the case view. Rollback actions execute via the same API as the original action and are logged with a rationale field. For irreversible actions (credential revocation, token deletion), ManySignal displays an explicit warning before execution and requires a second approver confirmation in high-risk environments. Rollback history is preserved in the case audit trail.
Can multiple analysts collaborate on a single incident case simultaneously?
Yes. The case view is a real-time shared workspace. Multiple analysts can add notes, run additional queries, assign tasks to team members, and approve or deny pending actions simultaneously. All contributions are attributed to the acting analyst with timestamps. Concurrent edits are merged without conflict using an event-sourced case model. The case is the single source of truth for the incident, replacing shared spreadsheets and Slack threads.
How does ManySignal handle incidents that start as low-severity alerts and escalate?
Cases in ManySignal escalate dynamically. A P3 alert that generates new correlated events (lateral movement detected, additional host flagged, privilege escalation following initial access) automatically re-evaluates severity and re-routes to the appropriate on-call team. The escalation history — why the severity changed, what new evidence arrived — is preserved in the case timeline. Analysts joining an escalated case see the full history from initial detection through escalation.
See incident response handle a real scenario
30-minute live demo. We'll walk through a simulated account compromise from detection through containment — showing the timeline assembly, approval workflow, and post-incident report.