Validating your AWS Security Incident Response configuration

After you complete onboarding, you can validate that enrollment, detection sources, AWS Identity and Access Management (IAM) permissions, containment, and notifications are configured correctly before a real security event occurs. This section provides step-by-step verification procedures using both the AWS Management Console and the AWS CLI.

Before you validate

Prerequisites for validating your Security Incident Response configuration

To complete these validation steps, make sure that you have the following:

Confirm log readiness

AWS Security Incident Response doesn't enable log sources on your behalf. During an investigation, engineers rely on logs that are already present in your environment. Before validating your setup, confirm the following logs are enabled in all covered accounts and AWS Regions. Without these logs, Security Incident Response engineers have limited visibility during investigations. Enable them before proceeding.

Verify GuardDuty is enabled

Use the following command to verify that Amazon GuardDuty is active in your accounts:

aws guardduty list-detectors

A non-empty response confirms GuardDuty is enabled in the current AWS Region. Repeat this step for each active Region, or verify across your organization through the GuardDuty delegated administrator account.

Step 1: Verify enrollment and membership

Using the AWS Security Incident Response console

Using the AWS CLI

Run the following command from your delegated administrator account:

aws security-ir list-memberships

The preceding command returns your membership ID and status.

To get full membership details including your incident response team configuration, run the following command:

aws security-ir get-membership --membership-id membership-id

Use the command output to verify the following information.

Verify the delegated administrator

To confirm that the correct account is registered as the delegated administrator for Security Incident Response, run the following command:

aws organizations list-delegated-administrators \
  --service-principal security-ir.amazonaws.com

Step 2: Verify detection sources and triage

AWS Security Incident Response monitors security findings from GuardDuty and third-party tools through Security Hub CSPM. The service uses a service-linked role to ingest findings through Amazon EventBridge rules deployed to your accounts during onboarding.

Verify the Triage service-linked role

The AWSServiceRoleForSecurityIncidentResponse_Triage service-linked role must exist in your management account and all in-scope member accounts.

To verify, run the folloiwng command in the management and in-scope member accounts:

aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage

A successful response confirms the role exists. If you receive a NoSuchEntity error, do one of the following:

Verify the primary service-linked role

The AWSServiceRoleForSecurityIncidentResponse role should also exist in your delegated administrator account. To verify that the role exists, run the following command:

aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse

Verify proactive response and EventBridge rules

In the AWS Security Incident Response console, confirm that Proactive response shows as enabled. When enabled, the service does the following:

Verify EventBridge rules are deployed in member accounts

To verify that EventBridge rules are deployed in member accounts, complete the following steps.

If the rules are missing, re-run the proactive response setup from the Security Incident Response console or contact AWS Support.

Verify third-party integrations (if applicable)

If you use third-party detection tools (such as CrowdStrike Falcon, Trend Micro Cloud One, or Fortinet Lacework FortiCNAPP), verify that their findings are flowing through Security Hub CSPM:

Step 3: Verify the automated finding pipeline

This step confirms that the EventBridge pipeline is active and findings are reaching automated triage.

About GuardDuty sample findings

GuardDuty's built-in Generate sample findings feature produces findings marked as samples. Automated triage filters sample findings to prevent noise; they don't flow through the full triage pipeline and can't be used to validate your Security Incident Response configuration. Don't use them for this step.

Validate with the GuardDuty test domain

The GuardDuty documentation provides a test domain (guarddutyc2activityb.com) that generates a real finding without requiring real-world security events. Querying this domain from an Amazon EC2 instance in a covered account produces a finding that Security Incident Response ingests and processes.

To generate a test finding:

What to expect:

Step 4: Verify notifications and incident response team

Verify your incident response team

In the Security Incident Response console, review your configured incident response team members. Each member receives immediate email notifications when a case is created.

Or, run the following command to verify using the AWS CLI:

aws security-ir get-membership --membership-id membership-id

Confirm that:

Understanding case watchers

Case watchers are stakeholders who are granted access to view a specific case. Key details:

This per-case scoping is particularly important when granting access to external parties such as managed detection and response (MDR) partners or third-party investigation teams who should only see the specific case they're involved in.

Verify notification delivery with a test case

The most effective way to validate end-to-end notification flow is to create a reactive (self-managed) test case:

What to expect from case notifications

When a case is created (either proactively by the service or reactively by your team), all configured incident response team members receive an email notification containing the case details.

Verify EventBridge integration (if configured)

If you configured EventBridge to route case events to third-party platforms (such as ServiceNow, Jira, Slack, or PagerDuty), verify that your test case triggers the expected notification in those systems.

Step 5: Verify containment readiness (optional)

If you haven't enabled containment

Nothing to validate here. Security Incident Response provides guidance and investigation during security events but doesn't take automated containment actions unless you explicitly authorize it.

If you have enabled containment

Check containment status in the console. Verify whether containment actions are shown as Authorized. Supported containment actions include runbooks for:

Verify the CloudFormation StackSet is deployed. Containment requires IAM roles (AWSSecurityIncidentResponseContainment and AWSSecurityIncidentResponseContainmentExecution) in your covered accounts:

If the StackSet isn't deployed, containment authorization in the console doesn't result in actual containment actions being taken.

Confirm your containment preference. Security Incident Response supports three containment levels:

To submit or update your preference, create an AWS Support case with case type Technical: Security Incident Response Service / Other.

If you want EC2 Triage: Deploy the Containment with EC2 Triage CloudFormation template. This allows Security Incident Response engineers to collect investigative data from Amazon EC2 instances using AWS Systems Manager.

Step 6: Confirm ongoing operation

After completing initial validation, use these indicators to confirm that Security Incident Response is continuously operating as expected.

The absence of cases is normal

Security Incident Response creates a proactive case only when automated triage identifies activity that warrants human investigation. When triage determines a finding is benign, it archives the finding without creating a case or contacting your team. A deployment with no open cases and a consistent flow of archived GuardDuty findings is operating as intended.

If you see no cases and no archived findings after your environment has been active for several days, the pipeline may not be connected; verify Steps 2 and 3.

Archived findings and suppression rules as health signals

As Security Incident Response processes findings over time, it creates two observable artifacts:

Your incident response team is notified when a suppression rule is created. If a rule was created in error, contact AWS Support to request a rollback. Archived findings are retained in GuardDuty for 90 days.

Monthly activity report

Security Incident Response sends a monthly activity report to your incident response team summarizing findings processed, triage outcomes, and any cases that were opened. If your team hasn't received a report after your first full calendar month of operation, verify that incident response team members have communications enabled. For any other issues related to the monthly report, contact your Account Team or open a Support Case with case type: Technical: Security Incident Response Service / Other and include the following information:

What to expect from Security Incident Response engineers

When you create an AWS-supported case or the service proactively creates one, Security Incident Response engineers acknowledge new cases within 15 minutes. This 15-minute acknowledgment SLO applies to all AWS-supported case types; both active security events and investigations. The initial acknowledgment confirms your case is being reviewed; the full assessment timeline may vary based on case severity and complexity.

For proactive cases (auto-created when the triage service identifies a confirmed security issue), the service creates the case after automated triage confirms the issue, and your incident response team is notified when the case is opened.

Validation checklist

Use this checklist to confirm your configuration is complete:

Billing verification

Enterprise Support and Unified Operations customers: Security Incident Response is included at no additional cost as part of your support plan. You don't see Security Incident Response charges in AWS Cost Explorer or the AWS Cost and Usage Report.

All other customers: Pricing is based on the number of security findings ingested. The first 10,000 findings per month are free. For details, see AWS Security Incident Response pricing.

Troubleshooting

Related resources