Closing AWS accounts that have Security Incident Response (SIR) enabled: what to do first

Question: I'm closing several AWS accounts that have AWS Security Incident Response (SIR) enabled. Do I need to take any SIR-specific actions first - such as removing the accounts from scope or deleting service-linked roles or will account closure handle everything cleanly?

Short answer

Account closure will not cleanly clean up SIR by itself. Closing accounts won't be blocked by SIR, but a few SIR-specific actions should happen first. How much work is involved depends on one key question: are these plain member accounts, or is one of them the SIR delegated administrator?

• If they are all member accounts, cleanup is light: remove them from scope, delete the service-linked roles, and export any data you need.
• If one is the delegated administrator, closing it will cancel the SIR subscription and disable SIR for the entire organization. That account must be deregistered and replaced first — an inherently disruptive change that requires careful coordination.

At a glance

Concern	Handled by account closure?	Action needed first?
Removing account from SIR scope	Partially (OU-driven)	Recommended — adjust OU structure
Service-linked roles (SLRs)	No — not auto-deleted	Manual deletion recommended
Membership / subscription	Only if it's the delegated admin	Depends on account role
Case history / data	No — lost on cancellation	Export anything needed
Billing	Yes — stops accruing on closure	None

1. Removing accounts from SIR scope

SIR coverage is scoped at the organization or Organizational Unit (OU) level through a delegated administrator account - it is not toggled individually per account.

Key implication: You can select coverage at the OU level, but not at the individual account level. All accounts within selected OUs - including accounts under child OUs - are covered by the membership. To take an account out of scope, you move it to an OU that isn't covered, disassociate the covering OU from the membership, or remove the account from the organization.

Recommendation: Before closing, move the accounts into an OU that is not in SIR scope (or remove them from the organization). This cleanly stops the SIR association without affecting the rest of the org's coverage.

Note: When updating membership association, changes can be applied for up to 5 OUs at a time. If you need to modify more, complete changes in batches of 5.

2. Service-linked roles are not cleaned up automatically

This is the most commonly missed point. SIR uses two service-linked roles (SLRs):

• AWSServiceRoleForSecurityIncidentResponse — used at the subscription/membership level to identify subscribed accounts, create cases, and tag resources.
• AWSServiceRoleForSecurityIncidentResponse_Triage — used for continuous monitoring and triage. When you onboard through the console, SIR automatically creates this role in the AWS Organizations management account and in all in-scope accounts. (When onboarding via the API/CLI, you create it manually.)

Removing an account from SIR scope or cancelling the membership does not delete these roles — they remain in the account until you delete them manually.

If the accounts are being closed and discarded entirely, the lingering SLRs are largely moot (the account goes away). But the cleanest practice is to delete them explicitly before closing:

aws iam delete-service-linked-role --role-name AWSServiceRoleForSecurityIncidentResponse
aws iam delete-service-linked-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage

Important: Service-linked roles must be deleted using delete-service-linked-role (not delete-role). This initiates an asynchronous deletion process that checks for dependent resources. The standard delete-role command fails on SLRs with an UnmodifiableEntity error. If the deletion fails due to active resources, resolve those dependencies first or wait for SIR to release its sessions.

This matters most if you might ever re-subscribe to SIR in a reopened account — leftover SLRs are easy to recreate (re-onboarding recreates them), but cleaning them up first keeps the offboarding tidy and auditable.

3. Subscription and billing impact

As of the current pricing model, SIR pricing is based on security-findings ingestion from Amazon GuardDuty and supported third-party detection tools through AWS Security Hub — not a per-account membership seat fee.

The first 10,000 findings per month are free. Beyond that, findings are billed per finding with tiered discounts:

Tier	Monthly finding ingestion	Price
Free Tier	First 10K	Free
Tier 1	Next 100K	$0.000676 per finding
Tier 2	Next 500K	$0.000538 per finding
Tier 3	Above 610K	$0.000430 per finding

There is no per-account membership charge, so closing member accounts does not reduce a "seat count" — it only reduces findings volume if those accounts were generating findings.

Enterprise Support and Unified Operations customers: If your organization has an Enterprise Support or Unified Operations plan, SIR is included at no additional cost - you will not be billed for findings ingested, even above the free tier. In this case, closing member accounts has zero direct SIR billing impact.

4. Member account vs. delegated administrator - the critical distinction

This is the question to confirm before doing anything else:

• Closing plain member accounts: SIR coverage for those accounts simply ends; the rest of the org is unaffected. The cleanest path is to move them out of the covered OU first, then close.
• Closing the delegated administrator account: This is far more impactful. Per the AWS documentation:

"Removing a delegated Security Incident Response administrator account from a live subscription cancels the subscription immediately, removes all the member accounts associated with this delegated Security Incident Response administrator account. AWS Security Incident Response will no longer be enabled for all the member accounts."

If one of the accounts you're closing is the SIR delegated admin, you must handle this carefully before closure - or you'll inadvertently disable SIR org-wide.

Heads-up: deregistering the delegated admin is disruptive

Because removing the delegated administrator from a live subscription cancels it immediately and disables SIR for every member account, this is inherently a service-disrupting change. There is no documented zero-downtime "swap" procedure for migrating the delegated admin to another account, so plan for either a coverage gap or AWS Support engagement.

Options if you need to close the delegated admin account:

If you want to keep SIR active for the organization:

• Engage AWS Support to coordinate a delegated admin migration. There is no self-service "swap" documented in the current user guide.
• The general flow would be: cancel membership → wait for end of billing cycle → re-enable with a new delegated admin. This means a period without active SIR coverage.

If you're okay with temporarily losing SIR coverage:

1. Cancel the membership from the delegated admin account (membership remains active until end of the current billing cycle / end of month).
2. After cancellation completes at month-end, deregister the delegated admin:

aws organizations deregister-delegated-administrator \
  --account-id <DELEGATED_ADMIN_ACCOUNT_ID> \
  --service-principal security-ir.amazonaws.com

3. Designate a new delegated administrator and re-enable SIR.

If you're decommissioning SIR entirely: Cancel the membership, wait for end of billing cycle, then proceed with account closure.

5. Data retention and cancellation timing

Voluntary membership cancellation (end-of-month). Per the pricing page:

"You can cancel your service membership at any time. If you do, your membership will remain active until the end of the current billing cycle, which coincides with the end of the month. Once your membership is fully cancelled at month's end, all active investigations, cases, and other resources will be closed."

Delegated admin removal (immediate). If the delegated administrator is removed from a live subscription, cancellation is immediate — not end-of-month. All member account associations are removed instantly.

Recommendations:

• Export any needed SIR case data and finding history before cancellation — once the membership ends (whether at month-end or immediately via DA removal), historical case data is lost.
• SIR integrates with Amazon GuardDuty and AWS Security Hub for findings; closing an account ends those integrations for that account.
• A closed AWS account enters a 90-day post-closure (suspended) state and can be reopened via AWS Support during that window; after that, closure is permanent. Deleting the SLRs and removing the account from scope before closure gives you a clean, predictable offboarding rather than relying on closure to do it.

Recommended offboarding sequence

For each account being closed (assuming they are member accounts):

1. Confirm the role — verify none of the accounts is the SIR delegated administrator. If one is, see Section 4 above for the careful handling required — engage AWS Support for DA migration guidance.
2. Export any needed SIR case data and finding history - cancellation/closure makes this data unrecoverable.
3. Remove from SIR scope — move the account to an OU not covered by SIR (or remove it from the organization). Changes are applied in batches of up to 5 OUs.
4. Delete service-linked roles — using the correct command:

aws iam delete-service-linked-role --role-name AWSServiceRoleForSecurityIncidentResponse
aws iam delete-service-linked-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage

5. Close the account through AWS Organizations or the account console.
6. Note the 90-day reopen window before closure becomes permanent.

Bottom line

Account closure will not cleanly handle SIR by itself. SLRs aren't deleted when you cancel SIR or remove an account from scope, and scope is OU-driven rather than per-account. As long as none of the accounts is the delegated admin, the cleanup is light: move out of scope, delete SLRs (using delete-service-linked-role), and export data. If one is the delegated admin, that is a disruptive change requiring careful coordination — there is no seamless "hot swap" documented, so plan for either a coverage gap or AWS Support engagement.

AWS Security Incident Response is a relatively new service, and some details (especially exact SLR behavior on account closure and delegated admin migration) continue to evolve. Confirm the current procedures in the SIR User Guide before executing.

References

• Using service-linked roles for AWS Security Incident Response
• Considerations and recommendations for using SIR with AWS Organizations
• Managing membership with organizational units (OUs)
• Enable Security Incident Response using the API/CLI
• AWS Security Incident Response and AWS Organizations (integration)
• Closing an AWS account
• AWS Security Incident Response pricing
• AWS Security Incident Response FAQs