Skip to main content

Findings

The Findings page lists all GuardDuty findings stored in Prism from the last refresh. You can filter by account, title, severity, and archive status, and open any finding to see the full enriched detail and archive or unarchive it.

Accessing Findings​

In the Security Hub sidebar, click GuardDuty > Findings. You can also reach this page pre-filtered by clicking a severity card, threat-type row, or account row on the Threat Dashboard.

info

The findings list shows results from the last refresh, not live AWS data. If the list appears stale, run Refresh findings from the Threat Dashboard.

Findings Table​

The page header reads Findings, with the subtitle GuardDuty findings • N shown (N+ when more findings are available beyond the loaded page). The table itself sits in a Results card carrying the same count.

Each row in the findings table represents one GuardDuty finding:

ColumnDescription
SeveritySeverity chip: CRITICAL, HIGH, MEDIUM, LOW, or INFORMATIONAL
TitleThe GuardDuty finding title
Resource typeThe affected resource type (for example, Instance or S3Bucket). The resource's own ID or ARN is not in this column; it is in the detail drawer
AccountThe AWS account ID where the finding was detected
RegionThe AWS region where the finding was detected
StatusNot archived (active finding) or Archived (suppressed)
Last observedDate and time the finding was last observed by GuardDuty

Rows are sorted by Last observed, newest first. Long titles are truncated with an ellipsis; hover to see the full title in a tooltip.

Click any row to open the Finding Detail drawer.

How the Severity Chip is Derived​

GuardDuty assigns each finding a numeric severity between 0 and 10. Prism maps that number to the severity band shown in the chip, and every severity filter and dashboard card works on the band, not the number:

GuardDuty numeric severityPrism severity band
9.0 and aboveCRITICAL
7.0 to 8.9HIGH
4.0 to 6.9MEDIUM
Above 0, below 4.0LOW
0INFORMATIONAL

The Resource type column shows the type only, exactly as AWS reports it. Prism recognises Instance, S3Bucket, AccessKey, Lambda, RDSDBInstance and EKSCluster and pulls the matching identifier out of each (instance ID, bucket ARN, access key ID, function ARN, DB instance ARN, cluster ARN); any other type AWS sends is still shown here verbatim, with the finding's ARN standing in for the identifier. The identifier itself lives in the drawer's Resource affected section, never in this column.

Filtering​

Use the Filters card above the table to narrow the list. Its subtitle reads "Narrow the list by account, severity or status", and a chip showing N active appears in the card header once any filter is set.

  • Account: a dropdown listing only the accounts currently enrolled in GuardDuty — accounts that have been removed, or are being removed, are left out — shown as Account name (123456789012), or as the bare account ID when Prism has no name for it. It starts empty with the placeholder All accounts; pick one to show only its findings. If the list of enrolled accounts cannot be fetched the dropdown stays empty, but an account filter already in the URL still applies
  • Search title: free-text search against the finding title (a substring match, not a whole-word one)
  • Severity: toggle chips for CRITICAL, HIGH, MEDIUM, LOW, and INFORMATIONAL; multiple selections are combined with OR
  • Status: toggle chips: Not archived (active findings) and Archived (suppressed findings); select one or both. Selecting both is equivalent to selecting neither, and returns active and archived findings together
note

The INFORMATIONAL chip is offered for consistency with the other Security Hub engines, but GuardDuty only produces an INFORMATIONAL finding when the numeric severity is exactly 0, so in practice it rarely matches anything.

When you arrive from the Threat Dashboard, the pre-applied filter appears in the control it belongs to rather than as a separate summary chip:

  • A severity drill-down (from a severity card) shows that severity's chip in the Severity group already selected. Click the chip again to clear it.
  • An account drill-down (from a per-account row) pre-fills the Account dropdown. Clear the dropdown to remove it.
  • A finding-type drill-down (from a top-threat-type row) has no control of its own, so it appears as a removable Type: <finding type> chip above the filter groups. Click the chip's delete icon to remove that filter.

A Clear filters (N) button appears in the page header when any filter is active, where N is the number of active filters. Click it to reset all filters at once.

info

A GuardDuty finding has no Security Hub workflow status — it is either active or archived — so only the Not archived and Archived chips are offered. Under the hood the two chips still send Security Hub's vocabulary: Not archived sends NEW and Archived sends SUPPRESSED, which is why those two words appear in the page URL.

The statuses with no GuardDuty equivalent are NOTIFIED and RESOLVED. A hand-built URL asking for either returns an empty page rather than silently ignoring the filter and handing back every finding.

Empty States​

The table has two different empty states, and they mean different things:

  • No findings yet, "Findings appear here as soon as your enrolled accounts report them." Shown when no filter is active: either no refresh has run yet, or your enrolled accounts genuinely have no findings.
  • No findings match these filters, "Clear a filter or widen the search to see more findings." Shown when at least one filter is active: findings exist, but the current filter combination excludes all of them.

Neither empty state means "the request failed". If the request for findings fails outright, an error panel with a Retry action appears above the Results card — read that panel first, because the table underneath it still draws one of the two empty states above.

Pagination​

The table loads 50 findings per page. If more findings match the current filters, a Load more button appears below the table. Click it to append the next 50 findings; the button reads Loading… and is disabled while the next page is on its way.

Finding Detail​

Click any row to open the Finding Detail drawer on the right side of the screen. The drawer shows the full enriched payload for that finding, organized in the same section structure as the AWS GuardDuty console.

The drawer header shows:

  • Finding title
  • Severity chip (color-coded by severity band)
  • Status chip: Archived or Not archived
  • A close (×) button

Overview​

FieldDescription
(description)Plain-language description of the threat behavior GuardDuty detected, shown as a paragraph above the labelled fields
Finding IDThe GuardDuty finding ID
Finding typeThe GuardDuty finding type (for example, UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B)
AccountThe AWS account ID
RegionThe AWS region
CountNumber of occurrences aggregated into this finding (only when GuardDuty supplied one)
First observedDate and time the finding was first observed
Last observedDate and time the finding was last observed

Resource affected​

FieldDescription
Resource roleThe role the resource played in the finding (only when GuardDuty supplied one)
Resource typeThe affected resource type, for example Instance or S3Bucket
ResourceThe resource's own identifier: instance ID, bucket ARN, access key ID, function ARN, DB instance ARN, or cluster ARN, falling back to the finding ARN
Access key IDIAM access key ID
Principal IDIAM principal ID
User typeIAM user type
User nameIAM user name

The last four fields appear together, and only when the finding carries IAM access key details, which is typical of AccessKey findings. Any of the four that GuardDuty left blank renders as an empty value rather than being hidden on its own.

Action​

This section appears only when GuardDuty identified a specific action that triggered the finding. It shows Action type (for example, AWS_API_CALL or NETWORK_CONNECTION), API, Service name, and the First seen and Last seen timestamps for the action.

Actor​

This section appears only when GuardDuty recorded a remote IPv4 address for the finding. It shows Caller type (always the literal Remote IP) and IP address.

Location​

This section appears only when location data is available for the remote actor. It shows City, Country, and, when GuardDuty supplied coordinates, Lat and Lon.

Organization​

This section appears only when network organization data is available for the remote actor. It shows ASN, ASN org, ISP, and Org.

Remediation​

Every GuardDuty finding drawer ends with a Remediation section. GuardDuty does not send per-finding remediation text, so Prism shows the same guidance on every finding, "See the GuardDuty finding type documentation for remediation guidance.", followed by a View documentation link to the AWS list of active GuardDuty finding types. Use the Finding type value from the Overview section to find your finding on that page.

Archiving and Unarchiving​

The drawer footer shows a note describing the current archive state, a Close button, and a single action button:

  • If the finding is Not archived: the note reads "Archive this finding to remove it from active threats." Click Archive to archive it.
  • If the finding is Archived: the note reads "This finding is archived. Unarchive to move it back to active threats." Click Unarchive to restore it.

Archiving and unarchiving call the AWS GuardDuty API directly, so the change is visible in the AWS GuardDuty console too. The button reads Saving… while the call is in flight; the drawer then closes and the findings list reloads.

Archiving is also what keeps the Threat Dashboard meaningful: its severity cards, top threat types, and per-account counts all exclude archived findings, and a refresh never re-ingests them.

note

If the archive or unarchive call fails, the drawer stays open and the error is shown in an error panel above the finding body, which stays on screen — so you can read the error and the finding it refers to together, then press the button again. The finding's status in Prism is not changed until the API call succeeds.

If the Finding Itself Cannot Be Loaded​

While the drawer is fetching, its body reads "Loading finding…" and the footer is not rendered at all. If the fetch fails, the drawer shows the error instead of the body, again with no footer — there is nothing to archive until the finding loads. An empty response is reported the same way, as "Could not load this finding.", rather than leaving the drawer spinning forever.

Opening a second finding clears the first one first, so the drawer never shows the previous finding's title, severity chip or body while the new one is loading.