Consolidated control findings Generating, updating, and archiving control findings Automation and suppression of control findings Compliance details for control findings ProductFields details for control findings Severity levels for control findings

Generating and updating control findings

AWS Security Hub Cloud Security Posture Management (CSPM) generates and updates control findings when it runs checks against security controls. Control findings use the AWS Security Finding Format (ASFF).

Security Hub CSPM normally charges for each security check for a control. However, if multiple controls use the same AWS Config rule, Security Hub CSPM charges only once for each check against the rule. For example, the AWS Config iam-password-policy rule is used by multiple controls in the CIS AWS Foundations Benchmark standard and the AWS Foundational Security Best Practices standard. Each time Security Hub CSPM runs a check against that rule, it generates a separate control finding for each related control, but charges only once for the check.

If the size of a control finding exceeds the maximum of 240 KB, Security Hub CSPM removes the Resource.Details object from the finding. For controls that are backed by AWS Config resources, you can review resource details by using the AWS Config console.

Topics

Consolidated control findings
Generating, updating, and archiving control findings
Automation and suppression of control findings
Compliance details for control findings
ProductFields details for control findings
Severity levels for control findings

Consolidated control findings

If consolidated control findings is enabled for your account, Security Hub CSPM generates a single finding or finding update for each security check of a control, even if a control applies to multiple enabled standards. For a list of controls and the standards that they apply to, see the Control reference for Security Hub CSPM. We recommend enabling consolidated control findings to reduce finding noise.

If you enabled Security Hub CSPM for an AWS account before February 23, 2023, you can enable consolidated control findings by following the instructions later in this section. If you enable Security Hub CSPM on or after February 23, 2023, consolidated control findings is enabled automatically for your account.

If you use the Security Hub CSPM integration with AWS Organizations or invited member accounts through a manual invitation process, consolidated control findings is enabled for member accounts only if it's enabled for the administrator account. If the feature is disabled for the administrator account, it's disabled for member accounts. This behavior applies to new and existing member accounts. In addition, if the administrator uses central configuration to manage Security Hub CSPM for multiple accounts, they cannot use central configuration policies to enable or disable consolidated control findings for the accounts.

If you disable consolidated control findings for your account, Security Hub CSPM generates or updates a separate control finding for each enabled standard that includes a control. For example, if you enable four standards that share a control, you receive four separate findings after a security check for the control. If you enable consolidated control findings, you receive only one finding.

When you enable consolidated control findings, Security Hub CSPM creates new standard-agnostic findings and archives the original standard-based findings. Some control finding fields and values will change, which might impact your existing workflows. For information about these changes, see Consolidated control findings – ASFF changes. Enabling consolidated control findings might also affect findings that integrated third-party products receive from Security Hub CSPM. If you use the Automated Security Response on AWS v2.0.0 solution, note that it supports consolidated control findings.

To enable or disable consolidated control findings, you must be signed in to an administrator account or a standalone account.

Note

After you enable consolidated control findings, it can take up to 24 hours for Security Hub CSPM to generate new consolidated findings and archive the existing standard-based findings. Similarly, after disabling consolidated control findings, it can take up to 24 hours for Security Hub CSPM to generate new standard-based findings and archive the existing consolidated findings. During these times, you might see a mix of standard-agnostic and standard-based findings in your account.

Generating, updating, and archiving control findings

Security Hub CSPM runs security checks on a schedule. The first time Security Hub CSPM runs a security check for a control, it generates a new finding for each AWS resource that the control checks. Each time Security Hub CSPM subsequently runs a security check for the control, it updates existing findings to report the results of the check. This means that you can use the data provided by individual findings to track compliance changes for particular resources against particular controls.

For example, if the compliance status of a resource changes from FAILED to PASSED for a particular control, Security Hub CSPM doesn't generate a new finding. Instead, Security Hub CSPM updates the existing finding for the control and resource. In the finding, Security Hub CSPM changes the value for the compliance status (Compliance.Status) field to PASSED. Security Hub CSPM also updates the values for additional fields to reflect the results of the check—for example, the severity label, workflow status, and timestamps that indicate when Security Hub CSPM most recently ran the check and updated the finding.

When reporting changes to compliance status, Security Hub CSPM might update any of the following fields in a control finding:

Compliance.Status – The new compliance status of the resource for the specified control.
FindingProviderFields.Severity.Label – The new qualitative representation of the severity of the finding, such as LOW, MEDIUM, or HIGH.
FindingProviderFields.Severity.Original – The new quantitative representation of the severity of the finding, such as 0 for a compliant resource.
FirstObservedAt – When the compliance status of the resource most recently changed.
LastObservedAt – When Security Hub CSPM most recently ran the security check for the specified control and resource.
ProcessedAt – When Security Hub CSPM most recently began processing the finding.
ProductFields.PreviousComplianceStatus – The previous compliance status (Compliance.Status) of the resource for the specified control.
UpdatedAt – When Security Hub CSPM most recently updated the finding.
Workflow.Status – The status of the investigation into the finding, based on the new compliance status of the resource for the specified control.

Whether Security Hub CSPM updates a field depends primarily on the results of the latest security check for the applicable control and resource. For example, if the compliance status of a resource changes from PASSED to FAILED for a particular control, Security Hub CSPM changes the workflow status of the finding to NEW. To track updates to individual findings, you can refer to the history of a finding. For details about individual fields in findings, see AWS Security Finding Format (ASFF).

In certain cases, Security Hub CSPM generates new findings for subsequent checks by a control, instead of updating existing findings. This can occur if there's an issue with the AWS Config rule that backs a control. If this happens, Security Hub CSPM archives the existing finding and generates a new finding for each check. In the new findings, the compliance status is NOT_AVAILABLE and the record state is ARCHIVED. After you address the issue with the AWS Config rule, Security Hub CSPM generates new findings and begins updating them to track subsequent changes to the compliance status of individual resources.

In addition to generating and updating control findings, Security Hub CSPM automatically archives control findings that meet certain criteria. Security Hub CSPM archives a finding if the control is disabled, the specified resource is deleted, or the specified resource no longer exists. A resource might not exist anymore because the associated service is no longer used. More specifically, Security Hub CSPM automatically archives a control finding if the finding meets one of the following criterion:

The finding hasn't been updated for 3‐5 days. Note that archival based on this time frame is on a best-effort basis and is not guaranteed.
The associated AWS Config evaluation returned NOT_APPLICABLE for the compliance status of the specified resource.

To determine whether a finding is archived, you can refer to the record state (RecordState) field of the finding. If a finding is archived, the value for this field is ARCHIVED.

Security Hub CSPM stores archived control findings for 30 days. After 30 days, the findings expire and Security Hub CSPM permanently deletes them. To determine whether an archived control finding has expired, Security Hub CSPM bases its calculation on the value for the UpdatedAt field of the finding.

To store archived control findings for more than 30 days, you can export the findings to an S3 bucket. You can do this by using a custom action with an Amazon EventBridge rule. For more information, see Using EventBridge for automated response and remediation.

Note

Prior to July 3, 2025, Security Hub CSPM generated and updated control findings differently when the compliance status of a resource changed for a control. Previously, Security Hub CSPM created a new control finding and archived the existing finding for a resource. Therefore, you might have multiple archived findings for a particular control and resource until those findings expire (after 30 days).

Automation and suppression of control findings

You can use Security Hub CSPM automation rules to update or suppress specific control findings. If you suppress a finding, you can continue to access it. However, suppression indicates your belief that no action is needed to address the finding.

By suppressing findings, you can reduce finding noise. For example, you might suppress control findings that are generated in test accounts. Or, you might suppress findings related to specific resources. To learn more about updating or suppressing findings automatically, see Understanding automation rules in Security Hub CSPM.

Automation rules are appropriate when you want to update or suppress specific control findings. However, if a control isn't relevant to your organization or use case, we recommend disabling the control. If you disable a control, Security Hub CSPM doesn't run security checks for it and you aren't charged for it.

Compliance details for control findings

In findings generated by security checks for controls, the Compliance object and fields in the AWS Security Finding Format (ASFF) provide compliance details for individual resources that a control checked. This includes the following information:

AssociatedStandards – The enabled standards that the control is enabled in.
RelatedRequirements – The related requirements for the control in all enabled standards. These requirements derive from third-party security frameworks for the control, such as the Payment Card Industry Data Security Standard (PCI DSS) or the NIST SP 800-171 Revision 2 standard.
SecurityControlId – The identifier for the control across the standards that Security Hub CSPM supports.
Status – The result of the most recent check that Security Hub CSPM ran for the control. The results of previous checks are retained in the history of the finding.
StatusReasons – An array that lists reasons for the value specified by the Status field. For each reason, this includes a reason code and a description.

The following table lists reason codes and descriptions that a finding might include in the StatusReasons array. The remediation steps vary based on which control generated a finding with a specified reason code. To review the remediation guidance for a control, refer to the Control reference for Security Hub CSPM.

Reason code	Compliance status	Description
`CLOUDTRAIL_METRIC_FILTER_NOT_VALID`	`FAILED`	The multi-Region CloudTrail trail does not have a valid metric filter.
`CLOUDTRAIL_METRIC_FILTERS_NOT_PRESENT`	`FAILED`	Metric filters are not present for the multi-Region CloudTrail trail.
`CLOUDTRAIL_MULTI_REGION_NOT_PRESENT`	`FAILED`	The account does not have a multi-Region CloudTrail trail with the required configuration.
`CLOUDTRAIL_REGION_INVAILD`	`WARNING`	Multi-Region CloudTrail trails are not in the current Region.
`CLOUDWATCH_ALARM_ACTIONS_NOT_VALID`	`FAILED`	No valid alarm actions are present.
`CLOUDWATCH_ALARMS_NOT_PRESENT`	`FAILED`	CloudWatch alarms do not exist in the account.
`CONFIG_ACCESS_DENIED`	`NOT_AVAILABLE` AWS Config status is `ConfigError`	AWS Config access denied. Verify that AWS Config is enabled and has been granted sufficient permissions.
`CONFIG_EVALUATIONS_EMPTY`	`PASSED`	AWS Config evaluated your resources based on the rule. The rule did not apply to the AWS resources in its scope, the specified resources were deleted, or the evaluation results were deleted.
`CONFIG_RECORDER_CUSTOM_ROLE`	`FAILED` (for Config.1)	The AWS Config recorder uses a custom IAM role instead of the AWS Config service-linked role, and the `includeConfigServiceLinkedRoleCheck` custom parameter for Config.1 isn't set to `false`.
`CONFIG_RECORDER_DISABLED`	`FAILED` (for Config.1)	AWS Config isn't enabled with the configuration recorder turned on.
`CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES`	`FAILED` (for Config.1)	AWS Config isn't recording all resource types that correspond to enabled Security Hub CSPM controls. Turn on recording for the following resources: `Resources that aren't being recorded`.
`CONFIG_RETURNS_NOT_APPLICABLE`	`NOT_AVAILABLE`	The compliance status is `NOT_AVAILABLE` because AWS Config returned a status of Not Applicable. AWS Config does not provide the reason for the status. Here are some possible reasons for the Not Applicable status: The resource was removed from the scope of the AWS Config rule. The AWS Config rule was deleted. The resource was deleted. The AWS Config rule logic can produce a Not Applicable status.
`CONFIG_RULE_EVALUATION_ERROR`	`NOT_AVAILABLE` AWS Config status is `ConfigError`	This reason code is used for several different types of evaluation errors. The description provides the specific reason information. The type of error can be one of the following: An inability to perform the evaluation because of a lack of permissions. The description provides the specific permission that is missing. A missing or invalid value for a parameter. The description provides the parameter and the requirements for the parameter value. An error reading from an S3 bucket. The description identifies the bucket and provides the specific error. A missing AWS subscription. A general timeout on the evaluation. A suspended account.
`CONFIG_RULE_NOT_FOUND`	`NOT_AVAILABLE` AWS Config status is `ConfigError`	The AWS Config rule is in the process of being created.
`INTERNAL_SERVICE_ERROR`	`NOT_AVAILABLE`	An unknown error occurred.
`LAMBDA_CUSTOM_RUNTIME_DETAILS_NOT_AVAILABLE`	`FAILED`	Security Hub CSPM is unable to perform a check against a custom Lambda runtime.
`S3_BUCKET_CROSS_ACCOUNT_CROSS_REGION`	`WARNING`	The finding is in a `WARNING` state because the S3 bucket that is associated with this rule is in a different Region or account. This rule does not support cross-Region or cross-account checks. It is recommended that you disable this control in this Region or account. Only run it in the Region or account where the resource is located.
`SNS_SUBSCRIPTION_NOT_PRESENT`	`FAILED`	The CloudWatch Logs metric filters do not have a valid Amazon SNS subscription.
`SNS_TOPIC_CROSS_ACCOUNT`	`WARNING`	The finding is in a `WARNING` state. The SNS topic associated with this rule is owned by a different account. The current account cannot obtain the subscription information. The account that owns the SNS topic must grant to the current account the `sns:ListSubscriptionsByTopic` permission for the SNS topic.
`SNS_TOPIC_CROSS_ACCOUNT_CROSS_REGION`	`WARNING`	The finding is in a `WARNING` state because the SNS topic that is associated with this rule is in a different Region or account. This rule does not support cross-Region or cross-account checks. It is recommended that you disable this control in this Region or account. Only run it in the Region or account where the resource is located.
`SNS_TOPIC_INVALID`	`FAILED`	The SNS topic associated with this rule is invalid.
`THROTTLING_ERROR`	`NOT_AVAILABLE`	The relevant API operation exceeded the allowed rate.

ProductFields details for control findings

In findings generated by security checks for controls, the ProductFields attribute in the AWS Security Finding Format (ASFF) can include the following fields.

ArchivalReasons:0/Description

Describes why Security Hub CSPM archived a finding.

For example, Security Hub CSPM archives existing findings when you disable a control or standard, or you enable or disable consolidated control findings.

ArchivalReasons:0/ReasonCode

Specifies why Security Hub CSPM archived a finding.

For example, Security Hub CSPM archives existing findings when you disable a control or standard, or you enable or disable consolidated control findings.

PreviousComplianceStatus

The previous compliance status (Compliance.Status) of the resource for the specified control, as of the most recent update to the finding. If the compliance status of the resource didn't change during the most recent update, this value is the same as the value for the Compliance.Status field of the finding. For a list of possible values, see Evaluating compliance status and control status.

StandardsGuideArn or StandardsArn

The ARN of the standard associated with the control.

For the CIS AWS Foundations Benchmark standard, the field is StandardsGuideArn. For the PCI DSS and AWS Foundational Security Best Practices standards, the field is StandardsArn.

These fields are removed in favor of Compliance.AssociatedStandards if you enable consolidated control findings.

StandardsGuideSubscriptionArn or StandardsSubscriptionArn

The ARN of the account's subscription to the standard.

For the CIS AWS Foundations Benchmark standard, the field is StandardsGuideSubscriptionArn. For the PCI DSS and AWS Foundational Security Best Practices standards, the field is StandardsSubscriptionArn.

These fields are removed if you enable consolidated control findings.

RuleId or ControlId

The identifier for the control.

For the CIS AWS Foundations Benchmark standard, the field is RuleId. For other standards, the field is ControlId.

These fields are removed in favor of Compliance.SecurityControlId if you enable consolidated control findings.

RecommendationUrl

The URL for remediation information for the control. This field is removed in favor of Remediation.Recommendation.Url if you enable consolidated control findings.

RelatedAWSResources:0/name

The name of the resource associated with the finding.

RelatedAWSResource:0/type

The type of resource associated with the control.

StandardsControlArn

The ARN of the control. This field is removed if you enable consolidated control findings.

aws/securityhub/ProductName

For control findings, the product name is Security Hub.

aws/securityhub/CompanyName

For control findings, the company name is AWS.

aws/securityhub/annotation

A description of the issue uncovered by the control.

aws/securityhub/FindingId

The identifier for the finding.

This field doesn't reference a standard if you enable consolidated control findings.

Severity levels for control findings

The severity assigned to a Security Hub CSPM control indicates the importance of the control. The severity of a control determines the severity label assigned to the control findings.

Severity criteria

The severity of a control is determined based on an assessment of the following criteria:

How difficult is it for a threat actor to take advantage of the configuration weakness associated with the control? The difficulty is determined by the amount of sophistication or complexity that is required to use the weakness to carry out a threat scenario.
How likely is it that the weakness will lead to a compromise of your AWS accounts or resources? A compromise of your AWS accounts or resources means that confidentiality, integrity, or availability of your data or AWS infrastructure is damaged in some way. The likelihood of compromise indicates how likely it is that the threat scenario will result in a disruption or breach of your AWS services or resources.

As an example, consider the following configuration weaknesses:

User access keys are not rotated every 90 days.
IAM root user key exists.

Both weaknesses are equally difficult for an adversary to take advantage of. In both cases, the adversary can use credential theft or some other method to acquire a user key. They can then use it to access your resources in an unauthorized way.

However, the likelihood of a compromise is much higher if the threat actor acquires the root user access key because this gives them greater access. As a result, the root user key weakness has a higher severity.

The severity does not take into account the criticality of the underlying resource. Criticality is the level of importance of the resources that are associated with the finding. For example, a resource that is associated with a mission critical application is more critical than one that is associated with non-production testing. To capture resource criticality information, use the Criticality field of the AWS Security Finding Format (ASFF).

The following table maps the difficulty to exploit and the likelihood of compromise to the security labels.

	Compromise highly likely	Compromise likely	Compromise unlikely	Compromise highly unlikely
Very easy to exploit	Critical	Critical	High	Medium
Somewhat easy to exploit	Critical	High	Medium	Medium
Somewhat difficult to exploit	High	Medium	Medium	Low
Very difficult to exploit	Medium	Medium	Low	Low

Severity definitions

The severity labels are defined as follows.

Critical – The issue should be remediated immediately to avoid it escalating.

For example, an open S3 bucket is considered a critical severity finding. Because so many threat actors scan for open S3 buckets, data in exposed S3 buckets is likely to be discovered and accessed by others.

In general, resources that are publicly accessible are considered critical security issues. You should treat critical findings with the utmost urgency. You also should consider the criticality of the resource.

High – The issue must be addressed as a near-term priority.

For example, if a default VPC security group is open to inbound and outbound traffic, it is considered high severity. It is somewhat easy for a threat actor to compromise a VPC using this method. It is also likely that the threat actor will be able to disrupt or exfiltrate resources once they are in the VPC.

Security Hub CSPM recommends that you treat a high severity finding as a near-term priority. You should take immediate remediation steps. You also should consider the criticality of the resource.

Medium – The issue should be addressed as a mid-term priority.

For example, lack of encryption for data in transit is considered a medium severity finding. It requires a sophisticated man-in-the-middle attack to take advantage of this weakness. In other words, it is somewhat difficult. It is likely that some data will be compromised if the threat scenario is successful.

Security Hub CSPM recommends that you investigate the implicated resource at your earliest convenience. You also should consider the criticality of the resource.

Low – The issue does not require action on its own.

For example, failure to collect forensics information is considered low severity. This control can help to prevent future compromises, but the absence of forensics does not lead directly to a compromise.

You do not need to take immediate action on low severity findings, but they can provide context when you correlate them with other issues.

Informational – No configuration weakness was found.

In other words, the status is PASSED, WARNING, or NOT AVAILABLE.

There is no recommended action. Informational findings help customers to demonstrate that they are in a compliant state.

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Schedule for running security checks

Compliance status and control status