What is AWS Security Incident Response?

AWS Security Incident Response is a managed security service that monitors your AWS environment for threats, triages security findings on your behalf, and engages you only when action is required. When a genuine security incident occurs, the Security Incident Response Engineering team investigates, helps contain the threat, and provides guidance toward recovery.

AWS Security Incident Response covers the full incident lifecycle: detection, triage, investigation, containment, and recovery guidance. The service aligns with the NIST 800-61 Computer Security Incident Handling Guide, providing a consistent approach to security event management grounded in industry best practices. It works alongside other AWS Detection and Response services and integrates with your existing tools through Amazon EventBridge.

How it works

AWS Security Incident Response doesn't generate security findings. It ingests findings from detection sources you already have (Amazon GuardDuty, third-party tools integrated through AWS Security Hub CSPM) and triages them on your behalf.

The service ingests all findings from configured sources but doesn't triage them all equally. An automated system evaluates whether each finding represents a genuine security threat and contains sufficient context for investigation. Findings that pass this evaluation proceed through a multi-stage triage process that combines automation, threat intelligence, and human expertise.

AWS Security Incident Response only triages threat detection findings. Security posture or compliance findings (such as misconfiguration alerts or benchmark violations) aren't triaged because they describe a state about your environment rather than an active threat requiring investigation.

Triage and deduplication

Triage and deduplication are at the core of the service. AWS Security Incident Response analyzes findings, correlates related signals, and eliminates duplicates so your team doesn't have to.

The service escalates to you only when your involvement is required. Across all customers, less than 1% of ingested findings result in a customer-facing escalation. When the service escalates, it means the finding requires your attention. There's no option to mute or suppress these notifications because each one represents a validated concern that requires action.

The triage process is dynamic. A finding evaluated as expected behavior today can be re-evaluated differently tomorrow if context changes. This is fundamentally different from a static suppression rule. AWS Security Incident Response prefers triage over suppression because it preserves the ability to detect evolving threats.

Log access

Security Incident Response accesses control plane logging only during an active investigation for the purpose of that investigation. Log data isn't provided to customers. Only summaries and conclusions are shared through case notes.

Suppression rules

In rare cases, when both you and the Security Incident Response Engineering team agree that a specific type of alert no longer needs monitoring, a suppression rule is deployed. Suppressed alerts aren't ingested or monitored in the future. You can see suppression rules in the GuardDuty or Security Hub CSPM console, and Security Incident Response notifies your Incident Response team when rules are created or modified. Changes are rolled back upon request.

Suppression rules are used sparingly because suppressed findings are permanently excluded from monitoring, whereas triaged findings remain under dynamic evaluation. Security Incident Response engineers always discuss this with you before implementing a rule.

Automated and human investigation

When automated triage can't determine that activity is expected, the AWS Security Incident Response Engineering team is engaged. This is a global, always-available team of security professionals with expertise in AWS and security incident response.

During an investigation, engineers analyze service metadata and threat intelligence, review insights from past findings in your environment, and apply incident response expertise. As part of a security investigation, Security Incident Response can also collect investigative data from within Amazon Elastic Compute Cloud instances using EC2 Triage (when enabled), without requiring direct access to the instance.

Continuous improvement

AWS Security Incident Response incorporates feedback and lessons learned from prior engagements to enhance detection capabilities, investigative processes, and triage accuracy. As the team investigates incidents across all customers, it develops responder-generated intelligence: indicators of compromise (IoCs), tactics, techniques, and procedures (TTPs), and associated patterns observed during investigations. This intelligence feeds back into the triage process, improving the ability to detect and respond to evolving threats over time.

The effectiveness of the service improves with your collaboration. By actively engaging and providing timely responses during investigations, you help the team understand your environment and expected behaviors, reduce false positive detections, and ensure rapid response to genuine incidents.

Proactive and reactive cases

AWS Security Incident Response provides two types of cases:

Proactive cases: Created automatically when the triage process identifies a genuine threat that requires your involvement. These cases carry a "[Proactive case]" prefix in their title. No manual configuration is required beyond enabling detection sources. When a proactive case is created, all configured stakeholders are notified automatically.

Reactive cases: Cases you create when you need assistance. There are two subtypes:

24/7 availability: Engineers respond to both proactive and reactive cases. AWS-supported reactive cases carry a 15-minute initial response SLO.

Both case types use the same data fields and case management portal.

Containment

When pre-authorized, Security Incident Response engineers execute containment actions on your behalf during active incidents. Supported containment actions include runbooks for compromised Amazon S3 buckets, Amazon EC2 instances, and IAM principals.

If you haven't pre-authorized containment, engineers provide manual guidance during investigations. For more information, see Containment actions.

Watchers and case sharing

You can grant case visibility to external parties using watchers or IAM policies. This lets you include partners, risk and compliance teams, legal counsel, or subject matter experts in your investigations.

Watchers receive notifications for all updates to a specific case. Each case includes a pre-populated IAM policy scoped to that case, maintaining least-privilege access for third-party participants.

Communication and case management

All cases are managed through your Membership account, which centralizes communication for all organizational accounts in one place. Communication during an investigation may include acknowledgment of a security event, establishing a call bridge, analysis of artifacts, requests for confirmation of expected activity, and sharing of investigation results. Video calls are available during active security events.

Only you can close a case. AWS Security Incident Response can set a case to "Ready to Close" status, but final closure is always your action.

Monitored accounts

Only accounts enrolled in your membership are monitored and investigated. You choose coverage at the AWS organization or OU level during enablement. Accounts outside your configured scope aren't monitored. For more information, see Step 1: Enable AWS Security Incident Response.

Integrations

AWS Security Incident Response integrates with your existing workflows through Amazon EventBridge. Every case lifecycle event is published to EventBridge, allowing you to build automations that connect to any tool or process you use.

Documented integration patterns are available for:

You can also build custom integrations for any other tool using the EventBridge events. For more information, see EventBridge integration.

APIs and self-service

AWS Security Incident Response provides APIs that allow you to integrate the service into your own workflows, retrieve case information programmatically, and build customized security solutions on top of the service. For more information, see the AWS Security Incident Response API Reference.

Monthly reports

AWS Security Incident Response delivers monthly reports summarizing activity across your accounts. These reports provide visibility into findings ingested, triage outcomes, and cases created. For more information, see Monthly reports.

Preparedness

During onboarding, you configure your Incident Response team with designated individuals or groups who receive notifications when cases are created. Permission policies define what access team members have within a case. Setting this up in advance ensures rapid response when an incident occurs.

Service boundaries

AWS Security Incident Response isn't a detection service — it doesn't generate findings or replace GuardDuty, Security Hub CSPM, or third-party detection tools. It ingests and triages what those services produce. It isn't an alert aggregator — unlike services that pass all alerts through to you, it absorbs the vast majority of findings and only escalates the ones that require your action. It doesn't triage security posture findings — compliance and configuration findings are informational by nature and don't require threat investigation.

The following activities are also not covered:

Your responsibilities

Getting assistance

If you have a request outside the scope of AWS Security Incident Response, see the following resources.

Supported Regions

AWS Security Incident Response supports the following language and region configurations: