Security Hub can now export findings to S3

2026-10-19

On October 9, 2026, AWS announced that Security Hub can export findings directly to Amazon S3 in CSV or JSON format. The export starts from any findings page in the console and lands in a bucket in your account. No extraction pipeline to build and maintain first.

What changed

• Exports are available from every findings page in the Security Hub console: Threats, Exposure, Vulnerabilities, Posture Management, Sensitive Data, and All Findings. You start an export on demand from the page you are viewing and Security Hub delivers the results to an S3 bucket in your account.
• Two formats. CSV for reviewing or sharing findings in a spreadsheet. JSON for findings in Open Cybersecurity Schema Framework (OCSF) format, the same schema the new Security Hub normalizes findings into.
• Available in all AWS Regions where Security Hub is available.

Why it matters

The immediate use case is audit evidence and compliance reporting, and the timing is practical. Security Hub CSPM findings age out: archived control findings are permanently deleted after 30 days, and the new Security Hub keeps history for a bounded window, not forever. Until now, keeping an archive meant wiring EventBridge to a Firehose stream into S3 yourself, with the caveat that EventBridge only forwards events that occur after the rule exists. An on-demand export gives teams the archive path without that pipeline, and the JSON option hands SIEMs and SOAR tools data already in OCSF rather than a custom schema. That S3 landing spot is also how the findings reach a SIEM: most SIEM AWS connectors already ingest from a bucket, typically by polling it or by watching an SQS queue fed by S3 event notifications, so the export can be picked up with no custom Security Hub connector. AWS's own documentation frames the export the same way: share findings with teams that do not use the console, load them into a data warehouse or BI tool, or keep a point-in-time record for audits. Point-in-time is the limit here: this is a batch a SIEM can ingest, not a live findings stream.

Security Hub vs GuardDuty

• GuardDuty is a detector. It continuously monitors for malicious activity and unauthorized behavior, analysing CloudTrail logs, VPC Flow Logs, and DNS query logs, plus sources such as S3 data events and EKS audit logs, using threat intelligence and machine learning anomaly detection. Its output is findings about threats it has spotted.
• Security Hub is the aggregator. It gives one place across accounts that collects, organises, and prioritises findings from multiple services, including GuardDuty, Inspector, Macie, Firewall Manager, and IAM Access Analyzer, plus partner tools. It also runs automated checks against standards such as the AWS Foundational Security Best Practices, the CIS AWS Foundations Benchmark, and PCI DSS.
• The relationship is source to hub: GuardDuty findings flow into Security Hub, where they sit alongside findings from the other services. An export from Security Hub is therefore the aggregated set, not a GuardDuty export. If the question is "is something malicious happening," that starts in GuardDuty. If the question is "what is our overall security posture and what do we fix first," that is Security Hub.

CloudWatch vs CloudTrail

• CloudTrail is the audit record. It records API activity in the account: who made the call, what the call was, when it happened, and where it came from. It delivers those log files to an S3 bucket, and it is the record used for governance, compliance, and operational auditing. Management events are the default; data events, such as S3 object-level activity, are an optional extra.
• CloudWatch is the monitoring system. It collects metrics and logs, including application and system logs, and raises alarms when a metric crosses a threshold or a log pattern matches, with notifications through SNS. It answers performance and health questions, not who did what.
• They connect: CloudTrail can deliver its logs to CloudWatch Logs, where a metric filter can turn a specific API pattern, such as an authorization failure, into a metric and then an alarm. The short version: CloudTrail answers who did what, where, and when. CloudWatch watches what is happening and alerts on it.

The catch

• The export is on demand, not continuous. If you need every finding streamed as it arrives, the EventBridge to Firehose path is still the mechanism.
• The bucket is yours, which means the export inherits your account's obligations: the bucket policy, encryption, retention, and who can read it. Findings in a spreadsheet-friendly CSV travel easily, which is exactly what makes access control on that bucket worth a second look.
• CSV is a flattened view. Anything that needs the full nested OCSF object, enrichment fields and all, wants the JSON export.

Sources

• AWS Security Hub now exports findings to S3 in CSV or JSON format (AWS What's New, October 9, 2026)
• Exporting findings to an S3 bucket (AWS Security Hub User Guide)
• AWS Security Hub now receives Amazon GuardDuty Malware Protection findings (AWS What's New; Security Hub aggregation of GuardDuty and other services)
• AWS CloudTrail adds data event delivery to Amazon CloudWatch Logs (AWS What's New; CloudTrail records API activity and delivers it to CloudWatch Logs)