A GuardDuty gap is specific to an account and a Region, and a quiet findings page does not prove that detection was running. To confirm coverage, check the detector state in each account and each Region you rely on, then check organization policy and each protection plan separately. Do this before drawing any conclusion about past activity.
What a disabled detector actually changes
Amazon GuardDuty can be paused or turned off, and the two actions have different consequences for what you already have. AWS documents suspension as a way to halt monitoring while keeping existing results. Disabling is the stronger action: it removes the data for that Region. The table below uses AWS’s documented wording, and the source for each row is linked in the text beneath it.
As an Amazon Associate I earn from qualifying purchases.
| Question | Suspend | Disable |
|---|---|---|
| Does monitoring continue? | No. AWS states that a suspended GuardDuty “no longer monitors the security of your AWS environment or generates new findings.” | No. Monitoring and new findings stop for the selected Region. |
| Do existing findings remain? | Yes. Existing findings are preserved. | No. Existing findings are lost and cannot be recovered after disablement. |
| Is configuration retained? | Not stated for suspension in the cited passage. Re-enablement is permitted later. | No. Configuration for the Region is lost. |
| Is the action limited to one Region? | Not stated in the cited passage. | Yes. AWS says disabling affects only the selected Region, so it must be repeated in each enabled Region to fully turn the service off. |
Source for the suspend and disable behavior: Suspending or disabling GuardDuty. If you need to keep findings from a Region where the service was disabled, export them before any change, because AWS documents no recovery path once they are deleted.
Why one enabled Region does not cover the account
GuardDuty is enabled per Region. An account can show healthy detection in the Region an engineer normally uses and still have no detector elsewhere. AWS recommends enabling GuardDuty in all supported Regions. Without that, detection of activity involving global services such as IAM is reduced. The Regional list and endpoint details are in the Amazon GuardDuty Regions and endpoints page, and the initial enablement model is described in Getting started with GuardDuty.
#1 Best Overall
Auditing a standalone account
Use this sequence when a single account is in scope. Work Region by Region, and record the state you observe in each one.
- Fix the scope first: the account IDs, the Regions, and the time window under review. Do not infer these from the incident title or from a dashboard summary.
- In the GuardDuty console, switch to each Region in the scope and record whether a detector exists and whether it is enabled, suspended, or absent.
- Check each optional protection plan in the same Region. A detector can be on while a plan is off, and plan availability varies by Region (see the protection plan section below).
- For any Region where the service is off, enable it, then recheck the account-level status. Do not rely on the summary view for this confirmation.
- If the account was disabled rather than suspended, record that the earlier findings and configuration for that Region cannot be recovered, and retrieve any exported records separately.
Auditing an AWS Organizations environment
In an organization, three checks are separate and must all be run: which accounts exist, which accounts are GuardDuty members, and what the organization policy and auto-enable settings allow. Only the delegated administrator can manage member accounts, as described in Continually managing your member accounts within GuardDuty.
Membership gaps
Start by listing every account in AWS Organizations, then compare that list with the GuardDuty member list. Accounts that have never become GuardDuty members do not appear in the output of ListMembers, and their detector status is not visible until they are added. A missing row is therefore not proof of coverage, and it is also not proof of a disabled detector. It means the account must be checked directly or added to the organization’s GuardDuty configuration. The impact review process in Reviewing a policy’s impact before you apply it describes how to enumerate accounts against policy effects.
Auto-enable modes
Auto-enable is set per Region. It controls whether new accounts receive GuardDuty automatically, and whether existing accounts are included.
Rank #3
| Mode | Applies to existing members | Applies to new members | Effect of changing to this mode later |
|---|---|---|---|
| ALL | Yes | Yes | Changing to NONE does not disable the setting for existing accounts. |
| NEW | No | Yes | Changing to NONE does not disable the setting for existing accounts. |
| NONE | No | No. The service is not automatically enabled for new members. | Does not remove settings already applied to existing accounts. |
Propagation of these preferences can take up to 24 hours, according to the organization auto-enable preferences guidance. The mode descriptions are in Auto-enable options. A setting that reads NONE is therefore not evidence that existing accounts are unprotected, and a setting that reads ALL is not evidence that every account has finished enabling. Check the account states themselves.
Organization policies that block re-enablement
If an account’s console or API attempt to turn GuardDuty back on fails, look at the organization policy before assuming an account-permissions problem. An applicable GuardDuty organization policy can disable the service or a specific protection plan. When that policy applies, covered accounts cannot turn the service back on through the console or the API. The policy has to be changed or removed at the organization level, not in the member account.
Verifying protection plans separately
Foundational detection and optional protection plans have separate enablement states. Some protection types are configured on their own, and feature availability differs by Region. Confirm each plan you depend on, in each Region, rather than inferring it from the detector status. The summary dashboard can show current-Region coverage, but AWS describes it as a summary view, so use account-level status for confirmation. In a newly created organization, the statistics shown on the dashboard may take up to 24 hours to populate. See Summary dashboard in Amazon GuardDuty for the dashboard’s scope.
What a quiet findings page does and does not show
An empty findings list cannot establish whether the detector was on or whether the relevant activity would have been detectable. Treat the findings page as one input. The coverage question is answered by the detector state, the membership list, the auto-enable setting, and the plan configuration, each checked in the Region and account concerned. Any conclusion about past activity needs the account’s own logs and records and is outside what GuardDuty’s configuration can show.
Best Value
This article describes how GuardDuty behaves and how to verify its state. It does not establish that any particular account was compromised, that any finding was lost in a specific incident, or how long any exposure lasted. Those questions need evidence from the environment in question.
Summary of the audit order
- Scope the accounts, Regions, and period first.
- Check detector state in each Region, then each protection plan.
- In an organization, reconcile the account list against GuardDuty membership, then check auto-enable settings.
- Check for an organization policy before treating a failed re-enablement as a permissions issue.
- Export findings before any change that could remove them.
AWS’s own documentation covers each of these steps, and the links above are the authoritative references for the current behavior.
Quick Recap
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
