AWS Config and Security Hub Organizational Deployment: Multi-Account Setup, Conformance Packs, and Finding Workflow
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AWS Config and Security Hub provide the configuration compliance and security finding aggregation capabilities that multi-account AWS Organizations environments need — but both services require a specific account structure to provide centralized visibility. Without the delegated administrator configuration and cross-account aggregation, each security finding lives in the account and region where it was generated, requiring manual review across dozens of accounts and 20+ regions to understand the organization's security posture.
The deployment sequence matters: designate the security account as delegated administrator first, then enable service recording, deploy conformance packs, and configure finding aggregation. Enabling in the wrong order requires reworking the account structure, and deploying without aggregation means the centralized view never materializes.
Deployment sequence: account structure before service enablement
AWS Config and Security Hub organizational deployment succeeds or fails at the account structure step: designating the security account as delegated administrator must happen before enabling Config recording or Security Hub standards in any member account. This section walks through the CLI commands for Organizations service access, delegated administrator registration, Config aggregator creation, and conformance pack deployment, explaining why the order matters and what breaks if steps are reversed.
Designate the security account as delegated administrator before enabling any member account recording
The management account must designate the security account as the delegated administrator for both Config and Security Hub before enabling either service in member accounts. If Config recording is enabled in member accounts before aggregation is configured, the compliance data is generated but not collected centrally — it must be re-imported rather than automatically aggregated. Execute from the management account: aws organizations enable-aws-service-access --service-principal config.amazonaws.com to enable Config integration with Organizations, then aws organizations register-delegated-administrator --account-id SECURITY_ACCOUNT_ID --service-principal config.amazonaws.com to designate the security account. Repeat for Security Hub (replace config.amazonaws.com with securityhub.amazonaws.com). After designation, all subsequent Config and Security Hub management operations are performed from the security account, not the management account.
Enable Config recording in all regions including unused regions to close blind spots
Enable Config recording in all AWS regions, not just the regions where your organization runs workloads. Attackers who compromise IAM credentials use unused regions specifically because Config monitoring is not typically enabled there, allowing them to create resources and execute operations without generating Config compliance events. The cost of Config recording in unused regions is minimal (no resources to record means near-zero Config rule evaluation events and minimal S3 storage for empty configuration snapshots). Use the Config organizational deployment to enable recording in all regions simultaneously rather than manually enabling per region — this is the only practical way to ensure coverage across all 30+ AWS regions.
Finding workflow: from aggregated findings to remediation tracking
Aggregating Security Hub findings from hundreds of accounts into a single view creates a new problem: volume. Without an automation rules layer to suppress known false positives before human review, the initial wave of findings after enabling organizational deployment is unworkable. This section covers Security Hub automation rule configuration for systematic suppression, EventBridge-to-ticketing-system integration for HIGH and CRITICAL finding assignment, and the closed-loop workflow where ticket resolution updates Security Hub finding status via the API.
Create automation rules to suppress systematic false positives before reviewing findings
Before reviewing the initial wave of Security Hub findings after enabling organizational deployment, create automation rules to suppress the finding categories that are known false positives in your environment. Common systematic false positives: IAM Access Analyzer external access findings for S3 buckets that are intentionally public (CDN origin buckets, public documentation sites), Config rule findings for single-region CloudTrail when the organization uses a centralized organization-level trail, Inspector findings for CVEs in software versions that are not reachable from the internet due to compensating controls. Configure Security Hub automation rules with conditions matching these patterns and the action Set workflow status to Suppressed. This reduces the initial finding volume to actionable items before the review begins.
Assign finding remediation using AWS Security Hub integrations with ticketing systems
Integrate Security Hub with your ticketing system (Jira, ServiceNow) using the AWS Security Hub integration or EventBridge automation to automatically create tickets for HIGH and CRITICAL findings. Each ticket should include the finding account ID, region, resource ARN, description, and remediation guidance from the Security Hub finding details. Assign tickets to the account team responsible for the affected resource — use the AWS account tag structure (owner, team, environment) to determine routing. Track remediation by updating the Security Hub finding Workflow Status via the API from the ticketing system integration: marking a ticket resolved should automatically set the finding to Resolved in Security Hub. This creates a closed-loop remediation tracking system where Security Hub is the source of truth for finding status.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
AWS Config and Security Hub organizational deployment requires designating the security account as delegated administrator before enabling service recording, deploying conformance packs (CIS, PCI DSS, AWS FSBP) through the Organizations integration for automatic coverage of all member accounts and all regions, configuring Security Hub finding aggregation to provide a single-account view of all findings, and integrating with EventBridge to forward findings to a SIEM for correlation. Create automation rules to suppress systematic false positives before the first finding review, then establish a finding workflow that assigns HIGH and CRITICAL findings to account teams with tracked remediation deadlines. The multi-account deployment provides compliance visibility that individual account-by-account review cannot achieve at the scale of a typical AWS Organizations environment.
Frequently asked questions
How do I deploy AWS Config across all accounts in an AWS Organization?
Deploy AWS Config across all Organization accounts using the Organizations delegated administrator and the Config organization-level recording configuration. First, designate the security account as the Config delegated administrator from the management account using aws organizations register-delegated-administrator --account-id SECURITY_ACCOUNT_ID --service-principal config.amazonaws.com. Then, from the security account, enable Config recording in all accounts and all regions using the AWS CLI or CloudFormation StackSet: aws config put-configuration-recorder in the delegated admin account with the AllSupported and IncludeGlobalResourceTypes flags creates recording configuration that propagates to member accounts. Enable a Config delivery channel pointing to an S3 bucket in the logging account. Create a Config aggregator in the security account to collect compliance findings from all member accounts and all regions: aws configservice put-configuration-aggregator with OrganizationAggregationSource that authorizes all accounts in the organization.
How do I deploy the CIS AWS Foundations Benchmark conformance pack?
Deploy the CIS AWS Foundations Benchmark conformance pack from the Security Hub delegated administrator account using the AWS Config console or CLI. In the Config console, go to Conformance Packs and select Deploy Conformance Pack. Choose AWS sample template and select Operational Best Practices for CIS AWS Foundations Benchmark v1.4 Level 1 (Level 1 provides the broadly applicable controls; Level 2 adds additional controls for higher-security requirements). For organizational deployment, select Deploy to all accounts in my organization which creates the conformance pack in all member accounts simultaneously through the Organizations integration. The conformance pack creates Config rules in each account for each CIS control (enabled CloudTrail, no root account access keys, password policy requirements, VPC flow logs, S3 public access blocks, and others). Compliance results per account are visible in the security account's Config aggregator under Conformance Packs.
How do I configure AWS Security Hub to aggregate findings from all accounts and regions?
Enable Security Hub organizational deployment from the management account by designating the security account as the Security Hub delegated administrator: in Security Hub console under Settings, Accounts, select Designate Delegated Administrator and enter the security account ID. From the security account's Security Hub console, under Settings, Auto-enable for new accounts, set to On and enable the AWS Foundational Security Best Practices (FSBP) standard, CIS standard, and PCI DSS standard automatically for new accounts. Configure finding aggregation to collect findings from all regions: in Settings, Regions, select Link regions and add all AWS regions where your accounts operate. Enable automatic enrollment of new accounts using Organizations integration so new accounts receive Security Hub automatically without manual setup. The security account Security Hub console then shows aggregated findings from all member accounts and all linked regions in a single view.
How do I forward Security Hub findings to a SIEM?
Forward Security Hub findings to a SIEM using Amazon EventBridge. In the security account (which receives aggregated findings), create an EventBridge rule with source aws.securityhub and event pattern detail-type Security Hub Findings - Imported. Configure the rule target based on your SIEM ingestion method: for Splunk, use an EventBridge target of Kinesis Data Firehose that delivers JSON finding objects to S3, then use the Splunk Add-on for AWS to ingest from S3. For Elastic, use the AWS integration module which supports Security Hub native ingestion via SQS. For a generic SIEM, create an EventBridge target of Lambda function that transforms the finding to the SIEM's event format and sends it via API. Filter the EventBridge rule to forward only HIGH and CRITICAL severity findings to reduce SIEM ingestion volume, and forward all findings to S3 for long-term storage and ad-hoc analysis.
How do I manage the Security Hub finding workflow to avoid alert fatigue?
Manage Security Hub finding workflow by configuring the finding status and workflow state for each finding category. When a finding is confirmed as a false positive or accepted risk, set the Workflow Status to Suppressed (which removes it from the active finding count and prevents it from reappearing unless the underlying resource changes). For findings requiring remediation, set the Workflow Status to In Progress with a Note documenting the assigned owner and remediation target date. Configure Security Hub automation rules (in Security Hub, Automation Rules) to automatically suppress known false positive patterns — for example, automatically suppress the Config rule finding for CloudTrail multi-region logging disabled for accounts that use the organization-level CloudTrail instead of account-level trails. Automation rules reduce the manual suppression workload for systematic false positives across hundreds of accounts.
What are the most important Config rules to enable for security monitoring?
The highest-priority AWS Config rules for security monitoring based on their coverage of common misconfigurations: ROOT_ACCOUNT_MFA_ENABLED (root account without MFA is the most critical IAM security gap), S3_BUCKET_LEVEL_PUBLIC_ACCESS_PROHIBITED (S3 public access is a frequent data exposure cause), VPC_DEFAULT_SECURITY_GROUP_CLOSED (default security group allows all traffic, creating a misconfiguration path), IAM_ROOT_ACCESS_KEY_CHECK (root access keys should never exist), CLOUD_TRAIL_ENABLED and MULTI_REGION_CLOUD_TRAIL_ENABLED (CloudTrail must be enabled for all compliance frameworks), EC2_INSTANCE_NO_PUBLIC_IP (internet-exposed EC2 instances should be intentional), RDS_INSTANCE_PUBLIC_ACCESS_CHECK (RDS public accessibility creates database exposure), ENCRYPTED_VOLUMES (EBS volumes containing sensitive data must be encrypted), IAM_PASSWORD_POLICY (weak password policies violate most compliance frameworks), and ACCESS_KEYS_ROTATED (IAM access keys should be rotated every 90 days). Deploy all ten as a minimum baseline using the AWS Foundational Security Best Practices standard in Security Hub, which includes these rules automatically.
How do I create custom Config rules for organization-specific security requirements?
Create custom AWS Config rules using Lambda functions that evaluate specific resource configurations not covered by AWS managed rules. For a custom Config rule: write a Lambda function that receives Config evaluation events with the configuration item for the resource type being checked, evaluates the configuration against your security requirement, and returns COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE. Common organization-specific custom rules include: verifying that specific S3 buckets have specific bucket policy requirements, checking that EC2 instances are tagged with required tags for cost allocation and security classification, verifying that security groups do not have organization-prohibited port ranges open, and checking that IAM roles follow the organization's naming convention and trust policy standards. Deploy custom Config rules using CloudFormation StackSets to ensure they appear in all accounts automatically. Custom rules in conformance packs allow deploying and tracking organization-specific rules with the same compliance pack tooling as AWS managed rules.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.