CIS AWS Foundations v1.2 2.5: AWS Config should be enabled and use the service-linked role for resource recording

To meet cis aws foundations v1.2 2.5: aws config should be enabled and use the service-linked role for resource recording requirement, you must enable AWS Config in each in-scope AWS environment and ensure the configuration recorder uses AWS Config’s service-linked role rather than a custom IAM role. Operationalize it by standardizing AWS Config deployment, validating the recorder role and recording status, and retaining repeatable evidence (console/API outputs and Security Hub results).

Key takeaways:

• Enable AWS Config and confirm it is actively recording resources, not merely installed.
• Require the AWS Config service-linked role for the configuration recorder to reduce misconfiguration risk.
• Produce audit-ready evidence via AWS Security Hub’s CIS mapping and direct AWS Config/IAM queries.

CIS AWS Foundations v1.2 control 2.5 is about making sure you can reliably answer two audit questions: “Are you continuously recording configuration state?” and “Is the recording function running under the intended AWS-managed service identity?” AWS Config is the foundational telemetry that supports change tracking, detective controls, and post-incident reconstruction. If it’s disabled, partially enabled, or recording under an over-permissioned custom role, you create blind spots and role-governance gaps that show up quickly in cloud security reviews.

AWS Security Hub maps this requirement to a specific control check, which gives you a practical compliance handle: you can measure pass/fail continuously rather than treating this as a one-time setup task ¹. Your job as a Compliance Officer/CCO/GRC lead is to turn the benchmark statement into enforceable configuration standards, clear ownership (cloud platform vs. security), and durable evidence that survives staff changes and account growth.

Primary references for this requirement are the CIS AWS Foundations Benchmark and the AWS Security Hub CIS mapping documentation ².

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 2.5 as mapped in AWS Security Hub.” ²

What the operator must do:

• Enable AWS Config so it is running and recording supported resources in each in-scope AWS environment.
• Use the AWS Config service-linked role for the configuration recorder (not a bespoke IAM role) to align to the benchmark expectation as implemented in AWS Security Hub’s CIS mapping ¹.

Plain-English interpretation (what “good” looks like)

You pass this requirement when:

1. AWS Config is turned on (a configuration recorder exists and is started).
2. Recording is actually happening (you can show resources are being recorded and delivered to the defined destination).
3. The recorder runs under the AWS-managed service-linked role (identity and permissions are controlled through AWS’s service-linked role mechanism, not a custom IAM role you might forget to maintain).

This is not a “set it once” requirement. AWS accounts proliferate, regions expand, and teams sometimes disable Config to reduce noise or cost. Treat it as a baseline guardrail with continuous verification through Security Hub and periodic spot checks through native AWS APIs ¹.

Who it applies to

Entity types: AWS cloud operators and any organization that manages AWS accounts with compliance obligations or internal security baselines aligned to CIS ³.

Operational context where it matters most:

• Regulated production workloads (financial services, healthcare, critical infrastructure).
• Organizations using AWS Organizations with multiple accounts where drift is likely.
• Environments where incident response relies on configuration history (forensics, root cause analysis, change attribution).

Typical owners:

• Cloud Platform / Landing Zone team: deployment standard and rollout.
• Security Engineering: detective control integration (Security Hub) and monitoring.
• GRC/Compliance: control definition, evidence standards, audit response.

What you actually need to do (step-by-step)

Step 1: Define scope and the “must be on” rule

Create a short scope statement in your cloud control standard:

• Which AWS accounts are in scope (production, staging, shared services, security tooling).
• Which regions are in scope (your policy should be explicit; your evidence should match your policy).
• Exceptions process (temporary lab accounts, sandboxes), with time-bound approval.

Tie the implementation to AWS Security Hub’s CIS benchmark mapping so you have a consistent control ID to report against internally ¹.

Step 2: Enable AWS Config using a standardized deployment method

Preferred approaches:

• Infrastructure as Code (CloudFormation/Terraform) as the source of truth.
• An AWS Organizations rollout pattern if your platform team runs a centralized landing zone model.

Operational checklist:

• Create/confirm a configuration recorder.
• Set the recorder to record supported resources (your engineering team will choose “all resources” or a defined scope based on your policy).
• Create/confirm a delivery channel (where Config delivers snapshots and configuration history).
• Start the recorder and validate it stays running.

Step 3: Enforce use of the service-linked role for the recorder

The requirement is explicit: the recorder should use the AWS Config service-linked role ¹. Your implementation standard should include:

• The recorder must reference the service-linked role (AWS-managed) rather than a custom IAM role.
• A change-control rule: “No manual role substitution for AWS Config recorder.”

Practical guardrail:

• Add a detective rule (Security Hub + internal alerting) so any finding against the mapped control is triaged as configuration drift, not “informational.”

Step 4: Validate using two independent methods (auditor-friendly)

Use both:

1. AWS Security Hub result for the mapped CIS control (gives you ongoing compliance posture) ¹.
2. Direct AWS evidence via AWS Config/IAM settings (gives you configuration truth if auditors don’t accept “tool says so”).

This dual-track approach reduces audit friction: Security Hub shows continuous monitoring; API/console captures show the exact configuration at a point in time.

Step 5: Operationalize monitoring and change control

Minimum operating model:

• A control owner who reviews exceptions and approves any planned downtime.
• An alert route for when AWS Config recording stops or the role deviates from service-linked.
• A monthly compliance check report exported from Security Hub for management review (if your org runs quarterly reviews, align to that cadence; keep it consistent and documented).

Daydream fit (earned mention): If you track cloud controls as requirements with defined evidence queries and renewal cycles, Daydream can act as your control system of record so the CIS mapping, owners, and evidence artifacts stay current as accounts grow ⁴.

Required evidence and artifacts to retain

Store evidence in an audit folder (GRC repository, ticketing system, or compliance tool). Keep it consistent across accounts.

Evidence types (recommended):

• Security Hub CIS mapping results showing the status for the AWS Config control mapped to this requirement ¹.
• Screenshots or exports showing:
  • AWS Config recorder exists and is started.
  • Recorder role is the service-linked role.
  • Delivery channel configured (destination details may be redacted for security, but keep enough to prove it exists).
• Change records:
  • IaC pull requests / change tickets enabling Config.
  • Exception approvals (if any) with expiration.
• Ownership documentation:
  • Control narrative: “AWS Config is enabled and records configuration changes; recorder uses AWS service-linked role; monitored via Security Hub.”

Retention guidance (practical):

• Keep the latest evidence plus historical snapshots that show continuous operation over time. Auditors often ask for “proof it was on during the period,” not only “proof it’s on today.”

Common exam/audit questions and hangups

What auditors ask (and how to answer):

• “Show me AWS Config is enabled.”
  Provide Security Hub pass status plus recorder status capture ¹.
• “How do you know it’s recording resources?”
  Provide recorder status and evidence of delivered configuration items/snapshots (export/screenshot plus system logs if available).
• “What IAM role does the recorder use?”
  Show the recorder’s role ARN and the presence of the service-linked role configuration ¹.
• “Who reviews drift and how fast do you respond?”
  Provide the alert workflow, ticket examples, and an owner assignment.

Hangup: “We enabled AWS Config once.”
Auditors will test for drift. Your answer must include continuous monitoring through Security Hub and an operational review cadence ¹.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails the requirement	How to avoid
AWS Config enabled in some accounts but not others	Multi-account drift breaks baseline assurance	Roll out via AWS Organizations/IaC and measure via Security Hub 1
Recorder exists but isn’t started	“Installed” is not “recording”	Add a control check for recorder status and alert on stop events
Custom IAM role used for recorder	Fails “service-linked role” expectation and increases permission drift risk	Mandate service-linked role in standard; block noncompliant changes via change control 1
Evidence is ad hoc screenshots	Weak audit trail over time	Use repeatable exports (Security Hub + API output) and store them in a consistent repository

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for this specific CIS requirement. Treat it as a baseline security control that often becomes relevant during broader regulatory exams, customer security reviews, and incident investigations. The risk is practical: if AWS Config is off or misconfigured, you may be unable to reconstruct who changed what, when, and where across resources, and your detective controls may miss unauthorized or risky changes ³.

Practical 30/60/90-day execution plan

First 30 days: Make it measurable and stop obvious gaps

• Confirm which accounts are in scope and document owners.
• Turn on AWS Security Hub CIS benchmarking (or confirm it is on) and identify current failures for the AWS Config mapped control ¹.
• For each failing environment, capture current-state evidence: recorder status, role, delivery channel.
• Draft the control narrative and evidence checklist (what you will retain every review cycle).

Next 60 days: Standardize and prevent drift

• Roll out AWS Config enablement through a standardized deployment method (IaC / centralized rollout).
• Enforce service-linked role usage as the default and document an exception process.
• Implement alerting/ticketing for failures detected through Security Hub and assign response ownership ¹.
• Run a tabletop “audit drill” where you produce evidence for an arbitrary account on demand.

By 90 days: Make it routine (and auditable)

• Add periodic verification: export Security Hub results into your GRC evidence repository on a defined cadence ¹.
• Review exceptions, close expired ones, and validate no silent account additions bypass the standard.
• Add management reporting: current pass/fail, open remediation items, and evidence completeness.
• If you use Daydream, map this requirement to a control record with owners, evidence tasks, and review workflows so your proof stays current as the environment changes ².

Frequently Asked Questions

Does this requirement mean AWS Config must be enabled everywhere?

It must be enabled everywhere you define as in scope for your CIS AWS Foundations alignment, and your scope must be explicit and defensible. Security Hub’s CIS mapping gives you a consistent way to measure pass/fail across those environments ¹.

What does “use the service-linked role” change in practice?

It means the configuration recorder should run under AWS Config’s AWS-managed service-linked role rather than a custom IAM role. This reduces role-permission drift and aligns to the CIS requirement as mapped in Security Hub ¹.

Is a Security Hub “PASS” result enough evidence for auditors?

Often it helps, but many auditors still want point-in-time configuration proof from AWS Config/IAM settings. Keep both the Security Hub result and direct configuration captures so you can answer quickly ¹.

We use IaC. How do we prove ongoing compliance rather than “we deployed it once”?

Keep the IaC change record plus periodic Security Hub exports that show the control remains passing. That combination demonstrates both design (IaC) and operation (continuous monitoring) ¹.

What’s the fastest way to find out which environments are noncompliant?

Start with AWS Security Hub’s CIS AWS Foundations benchmark view and filter to the control mapped to AWS Config for this requirement ¹.

How should we handle temporary exceptions (like short-lived test environments)?

Require documented approval, an expiration date, and compensating monitoring. Auditors mainly look for disciplined exception handling plus evidence that exceptions do not become permanent blind spots ³.

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content

Footnotes

1. AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark

4. AWS Security Hub CIS AWS Foundations mapping table; CIS AWS Foundations Benchmark