# Getting started
Getting started

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/NSyUlhDc_d0?si=PguieeTI3HrUbTDs/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/NSyUlhDc_d0?si=PguieeTI3HrUbTDs)


**Topics**
+ [

# Onboarding guide
](onboarding-guide.md)
+ [

# RACI matrix
](raci-matrix.md)
+ [

# Select a membership account
](select-a-membership-account.md)
+ [

# Setup membership details
](setup-membership-details.md)
+ [

# Associate accounts with AWS Organizations
](associate-accounts-with-aws-organizations.md)
+ [

# Setup proactive response and alert triaging workflows
](setup-monitoring-and-investigation-workflows.md)

# Onboarding guide
Onboarding guide

 AWS Security Incident Response helps you prepare for, respond to, and recover from security events such as account takeovers, data breaches, and ransomware attacks. The service triages findings from Amazon GuardDuty and AWS Security Hub CSPM, escalates security events, and manages cases that require your attention. You also have access to the AWS Security Incident Response team (SIRT), who investigates impacted resources and provides guidance throughout the incident lifecycle. 

For a full overview of the service, see [What is AWS Security Incident Response?](what-is.md) 

# Prepare for onboarding
Prepare for onboarding

 We recommend using a proof-of-concept (POC) approach when implementing AWS Security Incident Response. Before deployment, complete the following preparation steps with your internal teams and AWS account team. 
+ **Identify key stakeholders**: Map out the incident response decision-makers in your organization. Their involvement in policy updates and process changes is essential for a successful rollout.
+ **Validate finding sources**: Confirm that all security finding sources are properly configured and deployed. GuardDuty and Security Hub CSPM are critical inputs for the service's auto-triage technology.
+ **Determine account scope**: Decide whether AWS Security Incident Response will cover your entire AWS organization or specific organizational units (OUs). Defining this scope early makes implementation and scaling more straightforward.
+ **Establish escalation protocols**: Update your existing escalation procedures to include AWS Security Incident Response. Communicate the updated protocols to all stakeholders and response personnel.
+ **Collect points of contact and critical information**: Collecting customer metadata early ensures a smooth onboarding experience and enables timely outreach from AWS SIRT when needed. See [Appendix A: Points of contact and critical information](appendix.md) for the required information.

# Onboarding prerequisites
Onboarding prerequisites

 The only required prerequisite is enabling [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) with **All Features** enabled. Consolidated billing alone is not sufficient. 

 While not required, we strongly recommend enabling [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) and [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) across all accounts and active AWS Regions to get the most value from AWS Security Incident Response. 
+ [GuardDuty and AWS Security Incident Response](https://docs.aws.amazon.com/security-ir/latest/userguide/guardduty.html)
+ [GuardDuty best practices](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_best_practices.html)

## Third-party EDR integration
Third-party EDR integration

 Security Hub CSPM can ingest findings from third-party endpoint detection and response (EDR) vendors. When ingested, these findings are auto-triaged by AWS Security Incident Response for proactive case creation. To set up a third-party EDR integration, follow the steps in the [Security Hub CSPM integrations documentation](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html). 

![\[AWS Security Hub CSPM console\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/thirdpartyintegration.png)


**Note**  
 You don't need to enable Security Hub CSPM standards or controls. Only the vendor integrations are required for AWS Security Incident Response to ingest third-party findings. 

 **Pricing**: The first 10,000 Security Hub CSPM findings are free. After that, the cost is \$10.00003 per finding. For more information, see [Security Hub CSPM pricing](https://aws.amazon.com/security-hub/pricing/). 

# Step 1: Enable AWS Security Incident Response
Step 1: Enable AWS Security Incident Response

 The onboarding process takes approximately 10 to 15 minutes per AWS organization. For a walkthrough, see the [Getting Started video](https://docs.aws.amazon.com/security-ir/latest/userguide/getting-started.html) in the service documentation. 

**To enable AWS Security Incident Response**

1. Sign in to the AWS Management Console using your management account.

1. Open the AWS Security Incident Response console and choose **Sign up**.  
![\[AWS Security Incident Response sign-up page with the Sign up button.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/AWS_Security_incident_Response.png)

1. Designate a security tooling account as the delegated administrator.
   + For guidance, see [Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) in *AWS Prescriptive Guidance* and [Delegated administrator](https://docs.aws.amazon.com/security-ir/latest/userguide/delegated-admin.html).  
![\[Set up central membership account page for selecting a delegated administrator account.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Set_Up_Central_Membership_Account.png)

1. Sign in to the delegated administrator account.

1. Enter your membership details and associate the relevant accounts.

1. For **Account scope**, choose to enable AWS Security Incident Response for your entire AWS organization or for specific OUs. You can select coverage at the OU level, but not at the individual account level.

1. For **Proactive Response**, confirm that the setting is enabled. Proactive response is on by default and creates a service-linked role that allows AWS SIRT to ingest GuardDuty findings and open proactive investigation cases when threats are detected. For more information, see [Proactive response](https://docs.aws.amazon.com/security-ir/latest/userguide/proactive-response.html).
**Important**  
 The service-linked role is not automatically deployed to the management account. You must configure it manually for complete coverage. For instructions, see [Setup proactive response and alert triaging workflows](setup-monitoring-and-investigation-workflows.md). 

1. (Optional) Choose to pre-authorize AWS SIRT to perform containment actions on your behalf during active incidents. Supported containment actions include runbooks for compromised S3 buckets, EC2 instances, and IAM principals. If you skip this step, SIRT will provide manual guidance during investigations. For more information, see [Containment actions](https://docs.aws.amazon.com/security-ir/latest/userguide/containment.html).

1. Review the service permissions and onboarding configuration, then choose **Sign up**.  
![\[Review service permissions screen showing the permissions that AWS Security Incident Response requires to monitor findings.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Review_Service_Permissions.png)  
![\[Sign up confirmation screen for enabling proactive response monitoring.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Review_and_Sign_Up.png)

# Step 2: Configure your incident response team
Step 2: Configure your incident response team

 After you complete deployment, configure your incident response team to ensure proper notification and escalation during security events. 

**To configure your incident response team**

1. Open the AWS Security Incident Response console.

1. In the left navigation pane, choose **Incident Response Team**.

1. Add up to 10 team members. For each member, provide their name, title, and email address.  
![\[Incident response team configuration page showing team member details.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Teamates.png)

 Your team can include organization leadership, legal counsel, managed detection and response (MDR) partners, cloud engineers, and other stakeholders who need to be notified during security events. 

# Step 3: Understand case types and management
Step 3: Understand case types and management

 AWS Security Incident Response provides two types of cases to manage security events: proactive cases that are automatically created when threats are detected, and reactive cases that you create when you need assistance from AWS SIRT. You can also grant case visibility to external parties such as partners, legal teams, or subject matter experts. 

**Topics**
+ [

## Proactive cases
](#proactive-cases)
+ [

## Reactive cases
](#reactive-cases)
+ [

## Watchers
](#watchers)

## Proactive cases


 The auto-triage feature continuously reviews high-volume alerts to filter out noise and focus on critical, high-impact threats. When a potential threat is detected, the system escalates the finding to an AWS SIRT responder for investigation. If the finding is confirmed as a genuine threat, a proactive case is created in the case management portal and all configured stakeholders are notified automatically. 

 No manual configuration is required for proactive cases beyond enabling GuardDuty and integrating third-party security solutions with Security Hub CSPM. The service also integrates with an AI investigative agent that correlates data from multiple sources to accelerate investigations. This capability is currently available for reactive, AWS-supported cases. 

## Reactive cases


 AWS Security Incident Response provides a subscription-based case management portal where your organization works directly with AWS SIRT. AWS SIRT assists with security investigations and active incidents with a **15-minute service level objective (SLO)**. There is no limit on the number of reactive cases you can open. 

**To create a case**

1. Open the AWS Security Incident Response console.

1. Choose **Cases**, then choose **Create case**.

1. Choose a case type:
   + **AWS-supported**: Escalated directly to AWS SIRT for investigation and guidance (15-minute SLO).
   + **Self-managed**: Kept internal to your organization for tracking and documentation.

1. Complete all relevant fields. Include as much detail as possible to support an efficient investigation.

 Both case types use the same data fields. You can escalate a self-managed case to AWS SIRT at any time by choosing **Get help from AWS** in the upper-right corner of the case. 

![\[Create case screen showing options for reactive cases.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/reactive-cases.png)


 For detailed instructions, see [Create a case](https://docs.aws.amazon.com/security-ir/latest/userguide/create-case.html). 

## Watchers


 You can grant case visibility to external parties using Watchers or IAM policies. These options let 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. IAM policies provide direct console access with least-privilege permissions. 

**To add a watcher to a case**

1. Open the AWS Security Incident Response console and choose **Cases**.

1. Open the case you want to share.

1. Choose the **Permissions** tab, then choose **Add**.  
![\[Case overview page with Permissions tab.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Overview.png)

1. Copy the pre-populated IAM policy and apply it to the appropriate IAM roles or users.  
![\[Watchers configuration page showing IAM policy.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Watchers.png)

**Note**  
 Each case includes a pre-populated IAM policy scoped to that specific case. This maintains least-privilege access for third-party MDR partners and investigation teams. 

# Step 4: Integrate with your existing tools
Step 4: Integrate with your existing tools

 AWS Security Incident Response integrates with your existing security tools and workflows to streamline incident response operations. You can configure automatic finding ingestion from GuardDuty, set up event-driven workflows with EventBridge, connect to ITSM platforms like Jira and ServiceNow, and collaborate with your SIEM and MDR providers. 

**Topics**
+ [

## GuardDuty findings and suppression rules
](#guard-duty-findings)
+ [

## Amazon EventBridge
](#amazon-eventbridge-integration)
+ [

## Jira, Slack, and ServiceNow integrations
](#jira-slack-servicenow)
+ [

## SIEM and external tooling
](#siem-external-tooling)

## GuardDuty findings and suppression rules


 AWS Security Incident Response automatically ingests, triages, and responds to GuardDuty findings and Security Hub CSPM findings from third-party integrations. The auto-triage technology handles analysis as an added layer of detection and analysis. The service can create auto-archive rules in GuardDuty after escalating on a false-positive finding. Responders will always discuss this with you before implementing the rule. 

**To review GuardDuty suppression rules**

1. Open the GuardDuty console.  
![\[The GuardDuty console.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/guardduty-console.png)

1. Choose **Findings**.

1. In the navigation pane, choose **Suppression rules**. The **Suppression rules** page displays a list of all the suppression rules for your account.

1. To review or change the settings for a rule, choose the rule, and then choose **Update suppression rule** from the **Actions** menu.

**Note**  
 Organizations using SIEM technology will see reduced GuardDuty finding volumes over time, which improves both AWS Security Incident Response efficiency and SIEM performance. 

## Amazon EventBridge


 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) enables event-driven workflows for AWS Security Incident Response. You can configure case activity to trigger downstream AWS services (Amazon Simple Notification Service, AWS Lambda, Amazon Simple Queue Service, AWS Step Functions) or external tools such as Jira, ServiceNow, Slack, and PagerDuty. 

**To configure an EventBridge rule for AWS Security Incident Response**

1. Sign in to the delegated administrator account for AWS Security Incident Response.

1. Open the EventBridge console.

1. In the navigation pane, under **Buses**, choose **Rules**.

1. Choose **Create rule**, complete the rule details, then choose **Next**.

1. Under **AWS service**, select **AWS Security Incident Response** from the dropdown.

1. For **Event type**, select the event or API call you want to match. You can edit the pattern manually to include multiple events.

1. Choose **Next**.  
![\[Event pattern configuration showing AWS Security Incident Response as the selected service.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/event-pattern.png)

1. Select one or more targets for your events, such as Amazon SNS, AWS Lambda, an SSM document, or Step Functions. Configure cross-account targets if needed.  
![\[Event pattern configuration showing targets.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/event-pattern-target.png)

1. Review and create the rule.

 To use pre-built partner integrations, check **Partner Event Sources** in the EventBridge console. Available partners include Atlassian (Jira), Datadog, New Relic, PagerDuty, Symantec, and Zendesk. 

![\[EventBridge partner integrations page showing available third-party partners.\]](http://docs.aws.amazon.com/security-ir/latest/userguide/images/Amazon_EventBridge_Partners.png)


## Jira, Slack, and ServiceNow integrations


 AWS provides fully developed solutions for bi-directional integration with Jira, Slack, and ServiceNow. These integrations keep AWS Security Incident Response cases and your ITSM or ChatOps platforms in sync — updates in one system are automatically reflected in the other. 

 **Benefits of integration** 

 Integrating AWS Security Incident Response with your existing ITSM platform streamlines your security operations by centralizing incident tracking and response workflows. These pre-built solutions eliminate the need for custom development, allowing your security teams to maintain visibility across both AWS native and enterprise-wide incident management systems. By leveraging EventBridge for event-driven automation, updates flow seamlessly between platforms in real-time, helping make sure that security incidents are tracked consistently regardless of where they originate. This unified approach reduces context switching for security analysts, improves response times, and provides comprehensive audit trails across your entire incident response lifecycle. 

 For deployment instructions, see [AWS sample solutions for Jira, Slack, and ServiceNow](https://github.com/aws-samples/). 

## SIEM and external tooling


 AWS Security Incident Response doesn't directly ingest findings from your SIEM. However, when you open an AWS-supported case, AWS SIRT responders analyze and investigate SIEM findings in parallel with your team. SIRT helps identify correlations across hybrid and multi-cloud environments and assists with scoping threat actor activity across providers. 

 AWS SIRT also collaborates directly with your MDR providers and third-party investigation teams. Tabletop exercises are available to help establish effective coordination processes before an incident occurs. 

# Appendix A: Points of contact and critical information


 Complete the following table and provide it to your AWS account team before deployment. This information enables AWS SIRT to reach the right people quickly during a security event. 


**IR and SOC Personnel Contact Information**  

| Entry | IR \$1 SOC Personnel: Role, Name, Email | Primary, Secondary Escalation Contacts | Internal, Known CIDR Ranges | External, Known CIDR Ranges | Additional Cloud Service Providers | Working AWS Regions | DNS Server IPs (if other than Amazon Route 53 Resolver) | VPN \$1 Remote Access Solutions and IPs | Critical Application Names \$1 Account Numbers | Uncommon Ports Commonly Used | EDR \$1 AV \$1 Vulnerability Management Tools Used | IDP \$1 Locations | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| 1 | SOC Commander, John Smith, jsmith@example.com | Primary | 10.0.0.0/16 | 5.5.60.0/20 (Azure) | Azure | us-east-1, us-east-2 | N/A | Direct Connect, Public VIF 116.32.8.7 | Nginx Webserver (Example Critical) \$1 1234567890 | 8080 | CrowdStrike Falcon | Entra, Azure | 

**To submit this inforamtion, complete the following steps:**

1. Complete the preceding metadata table with your environment information.

1. Create an [AWS Support case](https://repost.aws/knowledge-center/get-aws-technical-support) with the following details:
   + **Case type:** Technical
   + **Service:** Security Incident Response
   + **Category:** Other

1. Attach the completed metadata table to the case.

# RACI matrix
RACI Matrix

 The following RACI matrix defines roles and responsibilities across the Security Incident Response implementation process. RACI stands for Responsible (R), Accountable (A), Consulted (C), and Informed (I). 


| Activity | Customer | AWS Account Team | SIR Team | 
| --- | --- | --- | --- | 
| **Pre-Onboarding** | 
| Identify Key Stakeholders | R |  | I | 
| Validate Finding Sources | R | C | I | 
| [3rd Party EDR integration] Security Hub CSPM | R | C | I | 
| GuardDuty Validation/Health Check | C | R | I | 
| Determine Account Scope | R |  |  | 
| Establish Escalation Protocols | R | I | C | 
| Enable AWS Organizations | R | C |  | 
| Associate accounts with AWS Organizations | R | I |  | 
| Select Delegated Administrator / Security Tooling Account | R | I |  | 
| **Onboarding** | 
| Setup membership details | R | I |  | 
| Walkthrough (Setup proactive response and alert triaging workflows; Deploy service-linked role to management account; Authorize containment actions) | R | C | I | 
| **Post-Deployment Configuration** | 
| Review operational integration capabilities | R | C | I | 
| Submit Security Incident Response Reactive Cases | R |  |  | 
| Configure Amazon EventBridge integrations | R | C | C | 
| Connect 3rd party tooling (Jira, ServiceNow, PagerDuty, Teams, etc.) | R | I | C | 
| Service deep dive and demo | A | R | C | 

 **RACI Definitions:** 
+ **Responsible (R)** - The party who performs the work to complete the task
+ **Accountable (A)** - The party ultimately answerable for the correct completion of the task
+ **Consulted (C)** - The party whose opinions are sought and with whom there is two-way communication
+ **Informed (I)** - The party who is kept up-to-date on progress and with whom there is one-way communication

# Select a membership account
Select a membership account

 A membership account is the AWS account used to configure account details, add and remove details for your incident response team, and where all active and historical security events can be created and managed. It's recommended that you align your AWS Security Incident Response membership account to the same account that you have enabled for services such as Amazon GuardDuty and AWS Security Hub CSPM. 

 You have two options for selecting your AWS Security Incident Response membership account using AWS Organizations. You can either create a membership in the Organizations management account or in an Organizations delegated administrator account. 

 **Use the delegated administrator account:** AWS Security Incident Response administrative tasks and case management are located in the delegated administrator account. We recommend using the same delegated administrator you've set for other AWS security and compliance services. Provide the 12-digit delegated administrator account ID and then log in to that account to proceed. 

**Important**  
 When you use a delegated administrator account as part of setup, AWS Security Incident Response can't automatically create the required triage service linked role in your AWS Organizations management account.   
You can use the IAM to create this role in your AWS Organizations management account  
Login to your AWS Organizations management account.
Access the [AWS CloudShell](https://console.aws.amazon.com/cloudshell/home) window or access the account through CLI in your preferred method.
Use the CLI command `aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" --no-cli-pager`
(Optional) To verify the command worked you can execute the command `aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage`

 **Use the currently logged in account**: Selecting this account means the current account will be designated as the central membership account for your AWS Security Incident Response membership. Individuals within your organization will need to access the service through this account to create, access, and manage active and resolved cases. 

 Ensure you have sufficient permissions to administer AWS Security Incident Response. 

 Refer to [ Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) for specific steps to add permissions. 

 Refer to [AWS Security Incident Response managed policies.](https://docs.aws.amazon.com/security-ir/latest/userguide/aws-managed-policies.html) 

 To verify IAM permissions, you can follow these steps: 
+  *Check the IAM Policy:* Review the IAM policy attached to your user, group, or role to ensure it grants the necessary permissions. You can do this by navigating to the [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/), select the `Users` option, choose the specific user, and then on their summary page, go to the `Permissions` tab where you can see a list of all attached policies; you can expand each policy row to view its details. 
+ *Test the Permissions:* Try to perform the action you need to verify the permissions. For example, if you need to access a case, try to `ListCases`. If you don't have the necessary permissions, you'll receive an error message. 
+  *Use the AWS CLI or SDK:* You can use the AWS Command Line Interface or an AWS SDK in your preferred programming language to test the permissions. For example, with the AWS Command Line Interface, you can run the `aws sts get-caller-identity` command to verify your current user permissions. 
+  *Check the AWS CloudTrail logs:*[ Review the CloudTrail logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html) to see if the actions you're trying to perform are being logged. This can help you identify any permission issues. 
+  * Use the IAM policy simulator:*[ The IAM policy simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) is a tool that allows you to test IAM policies and see the effect they have on your permissions. 

**Note**  
 The specific steps might vary depending on the AWS service and the actions you're trying to perform. 

# Setup membership details
Set up membership details
+  Select an AWS Region where your membership and cases will be stored.
**Warning**  
You can't change the default AWS Region after initial membership registration.
+ Select whether you’d like to provide full membership coverage over your entire AWS Organizations or part of your AWS Organizations through organizational units (OUs).
+  You can optionally select a name for this membership. 
+  A primary and secondary contact must be supplied as part of the create membership workflow. These contacts are automatically included as part of your incident response team. At least two contacts must exist for a single membership which also ensures a minimum of two contacts are included in the incident response team. 
+  Define optional tags for your membership. Tags help you to track AWS costs and search for resources. 

# Associate accounts with AWS Organizations
Associate accounts with AWS Organizations

 If you chose to associate your entire AWS Organizations during setup, your membership entitles coverage on all member accounts in the organization. Associated accounts will automatically update as accounts get added or removed from your organization.

 If you chose to associate part of the your AWS Organizations during setup and have restricted your membership to specific organizational units (OUs), your membership entitles coverage over all the accounts under the selected OUs. This includes accounts under sub-OUs of the selected OUs. Associated accounts automatically update as accounts get added or removed from those OUs.

 To learn more about best practices involving organizational units, please see [Organizing Your AWS environment Using multiple accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html).

# Setup proactive response and alert triaging workflows
Set up proactive response and alert triaging workflows

AWS Security Incident Response monitors and investigates threat alerts generated from Amazon GuardDuty and Security Hub CSPM integrations. To use this feature, [Amazon GuardDuty must be enabled](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html). AWS Security Incident Response triages low-priority alerts with service automation so your team can focus on the most critical issues. For additional information on how AWS Security Incident Response works with Amazon GuardDuty and AWS Security Hub CSPM, please review the [ Detect and Analyze](https://docs.aws.amazon.com/security-ir/latest/userguide/detect-and-analyze.html) section of the user guide.

If you experience onboarding issues, then [ create an AWS Support case](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case) for additional assistance. Make sure to include details including the AWS account ID and any errors you may have seen during the setup process. 

**Note**  
 If you have questions about Amazon GuardDuty suppression rules, alert triaging configurations, or proactive response workflows, you can create an AWS supported case with the case type **Investigations and Inquiries** to consult with the AWS Security Incident Response team. For more information, see [Create an AWS supported case](create-an-aws-supported-case.md). 

This feature enables AWS Security Incident Response to monitor and investigate findings across all covered accounts and active supported AWS Regions in your organization. To facilitate this functionality, AWS Security Incident Response automatically creates a service-linked role in all covered member accounts within your AWS Organizations. However, for the management account, you must manually create the service-linked role to enable monitoring.

*The service cannot create the service-linked role in the management account. You must create this role manually in the management account by [ working with AWS CloudFormation stack sets](https://docs.aws.amazon.com/security-ir/latest/userguide/working-with-stacksets.html).*

# Understanding Automatic Archiving with Proactive Response


When you enable proactive response and alert triaging, AWS Security Incident Response automatically monitors and triages security findings from Amazon GuardDuty and Security Hub CSPM. As part of this auto-triage workflow, findings are automatically archived based on the following criteria:

**Automatic archiving behavior:**
+ **Benign findings:** When the auto-triage process determines that a finding is benign (not a true security threat), AWS Security Incident Response automatically archives the finding in Amazon GuardDuty and creates suppression rules to prevent similar findings from generating alerts in the future.
+ **Suppression rules:** The service creates suppression and auto-archive rules in both Amazon GuardDuty and Security Hub CSPM for findings that match your environment's known-good patterns, such as expected IP addresses, IAM entities, and normal operational behaviors.
+ **Reduced alert volume:** Organizations using SIEM technology see significantly reduced Amazon GuardDuty finding volumes over time as the service learns your environment and automatically archives benign findings. This improves efficiency for both the AWS Security Incident Response service and your SIEM.

**Viewing archived findings:**

You can review automatically archived findings and the suppression rules created by AWS Security Incident Response:

1. Navigate to the Amazon GuardDuty console

1. Choose **Findings**

1. Select **Archived** from the findings filter

1. Review the suppression rules by selecting the down arrow next to each rule

**Important considerations:**
+ Archived findings are retained in Amazon GuardDuty for 90 days and can be viewed at any time during that period
+ You can modify or delete suppression rules at any time through the Amazon GuardDuty console
+ The auto-triage process continuously adapts to your environment, improving accuracy over time and reducing false positives

**Containment:** In the event of a security incident, AWS Security Incident Response can execute containment actions to quickly mitigate the impact, such as isolating compromised hosts or rotating credentials. Security Incident Response doesn't enable containment capabilities by default. To execute these containment actions, you must first grant the necessary permissions to the service. This can be done by deploying an [AWS CloudFormation StackSet](https://docs.aws.amazon.com/security-ir/latest/userguide/working-with-stacksets.html), which creates the required roles.