AWS Config Conformance Packs: Deploying Pre-Built Compliance Frameworks

AWS Config conformance packs solve a real problem: translating an abstract compliance framework (CIS Level 1, PCI DSS Requirement 10, NIST AC-2) into concrete AWS checks without manually mapping every control to a Config rule. AWS ships conformance pack templates for the major frameworks, and deploying one activates the full set of relevant checks in a single operation — dramatically faster than building a rule list from scratch.

That said, conformance packs are not a compliance checkbox. They cover the AWS resource configuration controls within a framework. They do not cover process controls, personnel controls, physical security, or application-layer requirements. A PCI DSS conformance pack does not make you PCI compliant — it makes your AWS resource configurations compliant with the subset of PCI controls that are automatable through AWS Config.

Available Pre-Built Conformance Packs

AWS maintains a library of sample conformance pack templates in the AWS Config GitHub repository and in the AWS documentation. The most widely used packs include the following.

CIS AWS Foundations Benchmark — available for both Level 1 and Level 2. Level 1 covers foundational controls: CloudTrail configuration, S3 public access, IAM password policy, root account MFA, and security group restrictions. Level 2 adds more granular checks including VPC configuration, KMS usage, and detailed IAM evaluations. This is the most commonly deployed pack and the best starting point for organizations without a specific regulatory framework requirement.

AWS Foundational Security Best Practices (FSBP) — AWS's own security best practice framework, covering 200+ controls across EC2, IAM, S3, RDS, Lambda, and other services. FSBP is also the basis for Security Hub's default security standard. Running the FSBP conformance pack and enabling Security Hub FSBP standard in parallel gives you two evaluation mechanisms against the same control set — useful for cross-validation but produces duplicated findings if you are not careful about routing them to the same dashboard.

PCI DSS — maps PCI DSS requirements to AWS Config rules. Covers requirements 1, 2, 7, 8, 10, and 11 as they apply to AWS resource configurations. Does not cover requirements 9 (physical security), 12 (information security policies), or application-layer requirements. Each rule in the pack is tagged with the specific PCI DSS requirement it maps to, which simplifies audit evidence collection.

NIST 800-53 — the most comprehensive pack, mapping to NIST Special Publication 800-53 revision 5 controls. NIST 800-53 is broad — it covers access control (AC), audit and accountability (AU), system and communications protection (SC), and configuration management (CM) among others. The conformance pack covers the controls in these families that are evaluatable through AWS resource configuration. This pack is required for FedRAMP, and increasingly used by enterprises outside the federal sector as a comprehensive security baseline.

HIPAA Security Rule — maps Health Insurance Portability and Accountability Act Security Rule requirements to Config checks. Covers technical safeguards including access controls, audit controls, transmission security, and integrity controls. Like the PCI pack, it explicitly does not cover administrative or physical safeguards, which require separate compliance evidence.

Operational Best Practices for AWS Well-Architected — covers the security pillar of the AWS Well-Architected Framework. Useful for organizations that are not bound to a specific regulatory framework but want alignment to AWS's recommendations for secure, reliable architectures.

Deploying via Console vs. CloudFormation StackSets

For a single account, deploy conformance packs through the AWS Config console or with the AWS CLI: aws configservice put-conformance-pack --conformance-pack-name CIS-L1 --template-s3-uri s3://your-bucket/cis-level1.yaml. This approach works for evaluation and for single-account environments, but does not scale to multi-account deployments.

For organization-wide deployment, use AWS CloudFormation StackSets deployed from the management account. AWS provides an organization conformance pack type — aws configservice put-organization-conformance-pack — that deploys the pack to all accounts in the organization simultaneously. This is distinct from StackSets but achieves the same result: consistent conformance pack configuration across every account.

When using organization conformance packs, you need delegated administrator permissions set up. The management account must grant Config service permission to deploy conformance packs to member accounts. Accounts that are in the exclusion list (if any are configured) will not receive the pack. Use aws organizations list-accounts to verify all expected accounts are included after deployment.

Customizing Pack Templates

AWS conformance pack templates are CloudFormation YAML files. Download the template, modify it, and deploy your customized version. Common customizations include adjusting rule parameters (changing the maximum access key age from 90 days to 60 days), removing rules that generate known false positives in your environment (a rule that flags intentionally public CDN buckets), and adding custom Config rules alongside the managed rules in the same pack.

Store your customized templates in an S3 bucket in your management account. Version control them in Git. When AWS updates the base template — which happens as frameworks release new versions and as AWS adds new managed rules — merge the upstream changes with your customizations deliberately rather than blindly overwriting your custom version.

Conformance Pack Compliance Score

Each deployed conformance pack produces a compliance score: the percentage of rules in the pack that are in a COMPLIANT state across all evaluated resources. A score of 100% means every rule in the pack passes for every in-scope resource. A score of 72% means 28% of your rule evaluations are returning NON_COMPLIANT findings.

The compliance score is a useful high-level metric but requires context. A pack with 50 rules where 10 are failing on a single low-risk resource type looks identical in score to a pack where 10 critical security rules each fail across hundreds of production resources. Use the score for trending — is it improving, stable, or declining? — rather than as an absolute pass/fail threshold.

The AWS Config console provides the compliance score per pack and drill-down into which rules are failing, which resources are non-compliant, and the configuration details that triggered the finding. Export this data using aws configservice get-conformance-pack-compliance-summary and aws configservice describe-conformance-pack-compliance for integration into your compliance reporting workflow.

Mapping Pack Controls to Audit Requirements

Compliance auditors do not think in Config rule names — they think in framework control IDs. Maintain a mapping table that translates Config rule names to the framework control IDs they satisfy. AWS provides this mapping in the conformance pack documentation and in the rule tags embedded in the conformance pack templates.

For PCI DSS, each rule in the pack template includes a Tags attribute with the PCI DSS requirement number. For NIST 800-53, the mapping is to NIST control family and control identifier. When an auditor asks for evidence that NIST AC-2 is implemented, query your Config compliance data filtered to the rules tagged NIST-800-53-AC-2 and export the compliance history for the audit period.

This tagging and mapping approach allows you to produce compliance evidence reports directly from Config data without manual correlation. Combine Config compliance history with CloudTrail data showing when findings were remediated — and by whom — to demonstrate both detection and remediation capability to your auditor.

Limitations of Conformance Packs

Conformance packs have meaningful limits that you must account for in your compliance program. They only evaluate AWS resource configurations — not application behavior, network traffic, user activity, or external dependencies. A conformance pack does not verify that your application validates input correctly, that your database backup procedures are tested, or that your incident response process meets framework requirements.

They also cannot evaluate configurations that AWS Config does not model. Some AWS services have limited Config support; resources in those services cannot be evaluated by Config rules. If your compliance framework has controls that apply to services without Config support, you need custom monitoring — Lambda functions, custom CloudWatch metrics, or manual evidence collection — to cover them.

Finally, conformance packs evaluate individual resource configurations in isolation. They do not evaluate relationships between resources or cumulative risk across your environment. A conformance pack will not tell you that a publicly accessible S3 bucket is particularly dangerous because it is also referenced by an IAM policy attached to an EC2 instance in a production VPC — that cross-resource risk analysis requires a more sophisticated approach.

Related Reading

• AWS Config setup guide — the foundation for deploying conformance packs at scale
• Essential Config rules — individual rules that complement conformance packs
• Multi-account Config aggregator — aggregate conformance pack compliance across your organization
• Compliance monitoring and risk scoring — turn conformance pack scores into operational metrics

FAQ

Do conformance packs deploy Config rules to all accounts automatically?

Organization conformance packs — deployed via put-organization-conformance-pack — automatically apply to all accounts in the organization, including newly created accounts that join after deployment. Standard conformance packs deployed via the console or CLI apply only to the account where you deploy them. For multi-account coverage, use organization conformance packs or supplement with CloudFormation StackSets.

Can I customize AWS-provided conformance pack templates?

Yes — and you should. Download the template from the AWS Config GitHub repository or the console, modify it to suit your environment (adjust rule parameters, remove irrelevant rules, add custom rules), and deploy your version. Store customized templates in S3 and version control them in Git. When AWS updates the base template, merge the changes deliberately.

How do conformance packs differ from Security Hub security standards?

Both evaluate AWS configurations against compliance frameworks, but through different mechanisms. Config conformance packs deploy Config rules that evaluate resource configurations. Security Hub security standards run automated checks and aggregate findings from multiple services. The control sets overlap significantly — CIS Benchmark controls appear in both. The difference is operational: Config conformance packs integrate naturally with Config remediation and the Config compliance dashboard. Security Hub standards integrate with the Security Hub findings workflow and cross-service correlation. Run both for comprehensive coverage.

What does a conformance pack compliance score of 100% mean?

Every Config rule in the pack returns COMPLIANT for every resource evaluated. It does not mean your environment is fully compliant with the underlying framework — only that the automatable AWS resource configuration controls all pass. Controls requiring human evidence, process documentation, or non-AWS system configuration are outside the scope of what any conformance pack can evaluate.

How long does it take for a conformance pack to evaluate all resources after deployment?

Initial evaluation after deployment typically completes within one to three hours for most environments. Large environments with many resources across many resource types may take longer. Subsequent evaluations happen in near-real-time for change-triggered rules (when a monitored resource changes) and on schedule for periodic rules. The Config console shows a "Last evaluated" timestamp for each rule, indicating when the most recent evaluation completed.