What the CIS AWS Foundations Benchmark asks for and what it costs to meet
CIS publishes the AWS Foundations Benchmark at version 7.1.0, alongside the Compute Services (2.0.0), Database Services (2.0.0), End User Compute Services (1.2.0) and Storage Services (1.0.0) Benchmarks, as of October 2026. CIS makes these available as PDFs for non-commercial use. The document is free to download, but it is not where the cost sits. The cost comes from configuring your AWS accounts to match each recommendation, collecting evidence that the settings are in place and deciding which Level profile applies to each account. Start by listing the accounts and services in scope, then confirm the current Benchmark version on the CIS AWS Benchmarks page, since older versions are archived and no longer maintained.
Most of the effort is internal and recurs. Someone must decide whether an account runs a Level 1 or Level 2 profile, record any recommendation you deliberately do not implement, and test changes in a non-production account before rollout, because Level 2 settings can disrupt operations if applied without care. Ask any implementation partner for a written scope that names the accounts, the Benchmark versions, the Level profile per account, the Config or log evidence to be produced, and who signs off on deviations. Quotes should separate the one-time build of the baseline from the recurring work of re-checking settings after Benchmark updates and AWS service changes.
Ownership is split clearly. Your organization owns its controls and the decisions about scope and risk acceptance. An implementation partner can prepare the account configuration, the evidence collection and the documentation of how each setting was verified. Only your own assessor or auditor reports on whether the controls operate as designed, and CIS itself does not certify your AWS environment. Confirm early with that assessor which Benchmark version and Level profile they expect to see, so the evidence you collect will be accepted without rework.
Who is paid for what when you implement AWS Benchmarks
This table separates each cost of implementing the CIS AWS Foundations Benchmark and other AWS Benchmarks by who pays for it and whether it is one-time or recurring. Read it as a checklist for asking partners and vendors what each line item includes before you sign a written scope.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Benchmark documents | No fee for the AWS Benchmark PDFs for non-commercial use, per CIS's terms | One-time download, then recurring checks for new versions | Confirm your use case is non-commercial before relying on free PDFs in a commercial program |
| Internal cloud and security staff time | Your own cloud, platform and security teams | One-time for baseline hardening, recurring for review and exceptions | Number of AWS accounts, service scope and how many Level 2 deviations you record |
| Implementation partner fees | Paid to a partner such as DeployOpen on a fixed, written scope; the organization still owns its controls | One-time for initial hardening and baseline evidence, optional recurring retainer | Accounts in scope, Benchmark profile chosen, degree of automation and documentation required |
| AWS-native services | Billed by AWS to your account for any configuration, logging or monitoring services you enable | Recurring usage charges, confirm current pricing with AWS | Number of regions, log volume and retention periods you set |
| Open-source scanners | No license fee for the tool; you pay for the hosting, compute and staff who run it | One-time setup, recurring scans and maintenance | Number of accounts scanned, scan frequency and the team that triages findings |
| CIS-CAT Pro | Requires SecureSuite membership; membership cost is set by CIS and varies with headcount, so ask CIS for current terms | Recurring membership while you use Pro | Headcount tier and whether you need Pro-only reporting; CIS-CAT Lite is free but has narrower scope |
| CIS Hardened Images on AWS Marketplace | Image terms are set by the seller on AWS Marketplace; confirm listing terms before purchase | Usually recurring while instances run, confirm with the listing | Number of instances, image variant and whether you need the STIG-hardened variant |
| Independent assessment fee | Paid to an independent auditor or assessor; only they issue reports or certificates | Periodic, tied to your assessment cycle | Scope of the assessment, number of accounts and how well evidence is already organized |
What makes the AWS Benchmark work larger or smaller
The effort to apply the CIS AWS Foundations Benchmark and other AWS Benchmarks depends less on the Benchmark text than on the environment it lands in. The six drivers below set how many accounts, regions and services get assessed, how deep the profile goes and how much evidence the team must keep, so scope them in writing before any hardening starts.
Number of accounts and organizational units
Every AWS account in scope needs its own configuration checks, evidence collection and deviation records, so account count is usually the largest driver. Group accounts into organizational units by function, such as production, development and shared services, and assess one representative account per group first. Confirm with the team which accounts are in the organization, which are standalone, and which are retired but still open. Ask whether a single control can be applied at the organization level or must be repeated per account.
Number of regions in use
Regional services, logging settings and encryption keys are configured region by region, so each active region adds checks even when the Benchmark text does not change. Inventory which regions hold workloads, backups or logs, and close the regions nobody uses where your policy allows it. Confirm whether global services such as identity and some logging features are scoped in a way that avoids duplicate findings. Record the region list in the scope document so assessors see the same boundary you tested.
Services beyond the Foundations scope
The AWS Foundations Benchmark covers account-level controls, but the service-level Benchmarks for compute, database, storage and end user computing add their own recommendations. A workload that uses containers, managed databases or file storage pulls those Benchmarks into scope. Make a service inventory from billing and configuration data, then decide which service Benchmarks apply to which accounts. Mark services that are out of scope with a stated reason, so later additions are visible.
Level 1 versus Level 2 target
Level 1 is the base profile meant to be implemented fairly quickly with minimal performance impact, while Level 2 adds defense in depth and CIS warns it can harm operations if applied without care. Choosing Level 2 for a whole estate often means more exceptions, more testing and more change tickets. Set the target profile per account group, and use Level 2 first on accounts that carry the most sensitive data. Document why each group sits at its level, since that decision is a point assessors ask about.
Existing landing zone or Control Tower state
A mature landing zone with guardrails, centralized logging and baseline accounts can satisfy many Benchmark recommendations once, while an ad hoc estate often needs each setting fixed by hand. Confirm whether AWS Control Tower is deployed, which guardrails are enabled, and whether they are preventive or detective. Check for settings that conflict with a guardrail or that a team has already overridden. Ask for the current landing zone design before estimating effort, because a partial setup can make the work larger than a clean start.
Change control and evidence maturity
Hardening that is not tracked through change control is hard to prove later, and assessors will ask who approved each setting and when it changed. Check whether infrastructure is defined as code, whether changes go through review, and whether configuration history is retained in a form you can export. Plan for recurring evidence: scan reports, approved exceptions and the deviation register, which need an owner and a review date. Teams with weak change records should budget time to rebuild the trail before the assessment begins.
Level 1 or Level 2 for AWS accounts
Level 1 is the base profile in a CIS Benchmark. CIS describes it as a set of settings that can usually be implemented fairly quickly, with minimal performance impact, while reducing the attack surface and keeping systems usable. For most AWS accounts, Level 1 is the sensible first target because it covers the common account hygiene that assessors look for and that rarely breaks deployed workloads.
- Account-level settings: Controls such as logging, root account protection, and identity baseline settings are usually the first items teams implement.
- Low operational friction: Most Level 1 recommendations do not change how applications run, which makes them easier to schedule in normal change windows.
- Clear evidence: Each recommendation maps to a configuration state that a scanner can read and an assessor can sample.
- Fast coverage: Applying Level 1 across all accounts gives a consistent floor before teams design stricter controls.
- Scope limits: Level 1 does not address every risk in a regulated environment, so it should be treated as a baseline.
Confirm with your own AWS environment which Level 1 recommendations already hold through landing zone guardrails, and document the ones you inherit rather than re-implement them.
Level 2 is intended as defense in depth for environments where security is paramount. It adds stricter settings on top of Level 1. CIS warns that Level 2 can harm operations if it is applied without care, because stricter restrictions can block legitimate traffic, break automation, or interrupt services that depend on default behavior. Teams should treat Level 2 as a deliberate design decision for specific accounts, not as an upgrade applied everywhere.
- Targeted use: Consider Level 2 for accounts that hold the most sensitive data or run the most critical workloads, where the added restriction is justified.
- Dependency mapping: Identify which pipelines, service roles, and third-party integrations rely on the settings that Level 2 tightens.
- Exception handling: Where a Level 2 recommendation cannot be met, record the business reason, the compensating control, and a review date.
- Staged rollout: Apply changes to one account or workload group at a time, with a rollback plan for each change.
- Ownership: Name the team that accepts the operational risk of each Level 2 setting.
Ask your team to list which Level 2 settings would stop a production workload if applied today, because that list determines the work needed before rollout.
Whatever profile an account targets, the change should be proven in a non-production account first. Non-production accounts that mirror the production configuration, including identity setup, networking, and logging, reveal breakage before it reaches customers. This step also produces the evidence that a change was tested, which assessors commonly ask for when they sample configuration changes.
- Representative workloads: Test against the same service types, network paths, and deployment tooling used in production, not only an empty sandbox.
- Scanner comparison: Run the same benchmark assessment before and after the change so the difference is recorded.
- Change records: Keep the test plan, results, and approval in the change management system with the account identifier.
- Automation checks: Confirm that infrastructure-as-code pipelines and deployment roles still work after restrictive settings are applied.
- Production sequencing: Promote changes account by account, starting with the least critical.
Illustrative example: a team tests a stricter logging or access setting in a staging account, finds that a deployment role fails, and corrects the role before production. Ask your team which non-production accounts exist and whether they mirror production closely enough to be trusted.
A benchmark profile is only useful if deviations are visible. Every recommendation that is not implemented, whether at Level 1 or Level 2, should be recorded as an exception with a reason, an owner, and a compensating control. This record is what turns a scan report into a defensible secure configuration process, and it gives auditors something concrete to test.
- Exception register: Store each deviation with the account, the benchmark recommendation identifier, and the scan date.
- Justification: State the operational or technical reason and why the risk is accepted.
- Compensating controls: Describe the alternate control, such as monitoring or additional access restriction, that reduces the risk.
- Review cycle: Set a review date and re-test whenever the benchmark version or the workload changes.
- Approval: Record who accepted the risk, normally someone with authority over the account.
Before an assessment, check that every failed recommendation in the latest scan has either a remediation ticket or an approved exception. Gaps in that register are a common reason assessors raise findings.
Some CIS Benchmarks include a STIG profile, which is aligned with DISA STIG requirements. It is relevant mainly to organizations that must meet federal or defense-specific configuration expectations. The STIG profile replaced the earlier Level 3 concept, and it has its own selection rules and recognition, so it should not be treated as a simple third level.
- Who needs it: Organizations with federal or defense obligations typically evaluate the STIG profile first.
- Different expectations: Recognition by federal buyers and commercial buyers can differ.
- Separate decision: Choose the STIG profile on its own merits rather than as a step beyond Level 2.
- Overlap check: Confirm which recommendations are shared with Level 1 or Level 2 before planning work.
For the selection criteria and how the STIG profile differs from Level 2, read the sibling profile page. Confirm the current applicability with your contracting authority before choosing it.
How an AWS Benchmark implementation moves from scoping to evidence
The sequence turns a general intent to harden AWS accounts into a versioned, Level-specific baseline with measured results, tested changes and a record of every accepted deviation. Each phase hands a defined output to the next so that the final evidence pack can be traced back to a scope decision.
Confirm scope and accounts
The organization decides which AWS accounts, Regions, organizational units and workloads fall under the Benchmark, and names an owner for each account. The implementation partner works from that list and records which accounts are production, non-production, shared-services or security tooling. The output is a written scope statement with an account inventory, approved by the accountable owner. The step is done when every in-scope account has an owner and no account is left unassigned.
Select Benchmark versions and Level
The team selects the AWS Foundations Benchmark version and the service-level Benchmarks that match the services in use, such as compute, database, storage or end user compute. For each Benchmark it chooses the Level 1 or Level 2 profile, or the STIG profile where a regulator requires it, and confirms the version against the current list on CIS's AWS Benchmarks page. The output is a Benchmark register that states each version, profile and the reason for the choice. Confirm the approach with the operating teams before moving on.
Baseline current state with a scanner
The team runs a scanner against each in-scope account to record the current pass and fail results for every recommendation in the chosen profile. Open-source options such as Prowler or ScoutSuite and CIS-CAT scanning can produce these results, and the team confirms which tool supports the selected Benchmark version before relying on it. The output is a baseline report per account, stored with its scan date and tool version. The baseline is the reference point that every later result is compared against.
Remediate in non-production first
Engineers change the failing settings in non-production accounts first, using infrastructure as code where the organization has it, so each change is versioned and repeatable. Each change is linked to the recommendation it addresses and to a named approver. The output is a change record for non-production, plus a re-scan showing which recommendations now pass. Where a recommendation cannot be met, the team records the reason instead of forcing the change.
Test operational impact
Before any production change, application owners and the security team test the modified settings against real workloads, logging pipelines, deployment tooling and break-glass access. This step matters most for Level 2 recommendations, which CIS warns can harm operations if applied without care. The output is a test record for each change that states what was tested, who signed it off and any side effects found. A change with unresolved side effects returns to remediation.
Roll out to production
The approved changes move to production through the organization's normal change process, in the same order and with the same rollback plan used in non-production. Engineers re-run the scanner after each wave so that the production results can be compared with the baseline. The output is a production change log and a post-change scan for each account. The step is complete when the post-change results match the approved change list.
Collect evidence and document deviations
The team gathers the scan reports, change records, test records and approvals into one evidence pack, organized by Benchmark and recommendation, and labels each item with its date and source. Every recommendation that is not implemented is listed as a documented deviation with the reason, the compensating measure and the accountable owner. The output is the evidence pack and a deviation register handed to the organization. An independent auditor or assessor decides whether that evidence meets the organization's requirements, because the implementation partner only prepares it.
When CIS Hardened Images on AWS Marketplace fit the plan
CIS Hardened Images fit a plan when the EC2 fleet is built from standard images and the team wants a starting configuration already aligned to a CIS Benchmark. CIS Hardened Images are virtual machine images pre-hardened to CIS Benchmarks and deployed from cloud marketplaces. CIS names AWS, Azure, Google Cloud Platform and Oracle Cloud as platforms, so on AWS the images are sourced through AWS Marketplace. For a team that launches many instances from a golden image, this can cut the work of building and hardening each base image from scratch. It also gives the secure configuration process (Safeguard 4.1 and the related hardening Safeguards in Control 4) a documented, repeatable starting point. Confirm before purchase which image families, operating systems and Benchmark versions the listing offers, and whether the listing's license terms cover your intended use.
A hardened image does not finish the job. The organization still owns its configuration after launch. Teams should run a Benchmark assessment against running instances, because user data scripts, added packages, security group changes and application installs can move a host away from the image baseline. Record every deviation with its business reason, an owner and a review date, and watch for drift over time. Also confirm that the image version matches the Benchmark version the organization has chosen to assess against. Image build dates and Benchmark releases do not always line up, so a mismatch is a common source of false findings or false assurance. Ask the vendor which Benchmark version each image was hardened to and how updates are published.
The Cloud Companion Guide for CIS Controls v8.1, published on December 9, 2024, explains how to apply CIS Controls v8.1 in any cloud environment from the consumer or customer perspective, covering both IT and OT cloud environments. It is the right reference when deciding which responsibilities stay with the AWS customer, such as account settings, instance configuration and access, and which sit with the image provider. Use it to document that split in the secure configuration process so an assessor can see who owns each control. The guide does not replace the Benchmark itself, and it does not certify any image or configuration.
Common questions about AWS CIS Benchmarks
Are the CIS AWS Benchmarks free to use?
Yes for non-commercial use. CIS states that its AWS Benchmarks are freely available in PDF format for non-commercial use, and older, unsupported versions are archived in CIS WorkBench. Commercial use of CIS content is governed by the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 license, so a company that builds paid services, reports or tooling on the Benchmarks should confirm its terms with CIS before relying on them. Read the current license terms on the CIS Amazon Web Services Benchmarks page before you plan your use.
Does passing a CIS AWS Benchmark certify compliance?
No. A Benchmark assessment shows how an AWS account or service configuration compares with the recommendations in the Benchmark, but it does not certify compliance with any regulation or standard. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. If a contract or regulator asks for evidence, the organization should map its Benchmark results to the framework in question and have an independent auditor or assessor decide what counts. Only an independent auditor or certification body issues reports or certificates.
How long does an AWS Benchmark hardening project take?
It depends on the scope: the number of accounts, the services in use, how much of the environment is managed through infrastructure as code, and how many findings need a documented deviation. A project covering the AWS Foundations Benchmark in a few accounts differs greatly from one covering many accounts plus Compute, Database and Storage Benchmarks. Ask for a written scope that lists accounts, regions, Benchmark versions, the Level profile, the services in scope and the evidence to be delivered. A fixed-scope agreement with agreed timelines is the basis for a reliable schedule, and no fixed duration applies to every environment.
What does an AWS Benchmark project need from our internal team?
The internal team owns the decisions and the accounts. Expect to provide access to the AWS Organizations structure and the accounts in scope, named owners for each workload, a change window for Level 1 and Level 2 settings, and someone who can approve or reject each deviation from a recommendation. Security and cloud engineers should review the Benchmark recommendations that touch logging, network paths, IAM policies and encryption, because these can break applications if applied without testing. Plan for time from the people who run production services, since they know which settings the business depends on.
Can an implementation partner complete AWS Benchmark compliance alone?
No. The organization owns its controls, its risk decisions and its AWS accounts. An implementation partner such as DeployOpen can plan the scope, prepare configuration baselines, apply hardening within the agreed scope, document deviations and assemble evidence. It does not decide which recommendations the business accepts, does not sign off on the organization's risk position and does not issue audit reports or certifications. Independent auditors and certification bodies perform any formal assessment. Ask any partner to state in writing which tasks it performs and which remain with your team.
Which AWS Benchmark version should we use for an audit?
Use the version the auditor or customer names in writing, and confirm that it is the current version on the CIS site when the work starts. CIS lists the AWS Foundations Benchmark at version 7.1.0 as of October 2026, along with the Compute, Database, End User Compute and Storage Benchmarks at their listed versions. Record the version in your scope document and your evidence. If the environment moves to a newer Benchmark version during the engagement, document the change, re-run the assessment and note which findings differ, so the auditor can follow the trail.
What is the difference between Level 1 and Level 2 for AWS?
Level 1 is the base profile, meant to be implemented fairly quickly with minimal performance impact while reducing attack surface and keeping systems usable. Level 2 adds defense in depth for environments where security is paramount, and CIS warns that it can harm operations if applied without care. For most AWS accounts, start with Level 1, test changes in non-production accounts and record every deviation. Apply Level 2 only where the risk justifies it and the workloads have been tested against the stricter settings. Confirm the profile choice with the business owners of each account.
Checks before you hire help on AWS Benchmarks
Before you sign with an implementation partner for an AWS Benchmark program, agree on what is in scope, how results will be shown to an assessor and who keeps the configuration after the work ends. The cards below cover the checks that tend to decide whether the engagement produces evidence you can use or a report nobody can reproduce.
Written scope with accounts and versions
Require the statement of work to list every AWS account, organizational unit and Region in scope, along with the exact Benchmark names and versions, such as AWS Foundations Benchmark version 7.1.0 and any service-level Benchmarks you need. Ask which Level profile applies to each account and which accounts are excluded and why. A scope that says only "our AWS environment" leaves the partner and your assessor measuring different things. The account list and Benchmark versions should be attached to the agreement, not left in a kickoff deck.
Evidence format agreed up front
Decide before work starts what evidence the partner will produce, in what format and where it will be stored. Typical items include scan output from the Benchmark checks, configuration exports, change records for each remediated finding and a signed record of each accepted deviation. Ask who owns the evidence repository and whether your assessor can read it without the partner present. Agreeing this early avoids rebuilding screenshots into a usable record at audit time.
AWS and CIS Benchmark experience
Ask the partner to describe, in their own words, the AWS accounts they have hardened to CIS Benchmarks, which Benchmark versions they worked against and how they handled Level 2 settings that could affect production. Ask who on the team has done this work and what their role was. Do not accept a list of logos or certifications in place of a description of the work. If the partner cannot describe a specific remediation and its operational side effects, treat that as a gap.
Independence from your assessor
Confirm that the partner preparing your AWS environment is not the same firm that will assess it. An implementation partner prepares systems, configurations and evidence, while only an independent auditor or assessor issues a report or certificate. Ask the partner to state in writing whether they have any reporting, attestation or advisory relationship with your assessor, and ask your assessor whether that relationship affects their independence. Keep the two roles separate in the contract.
Configuration as code handover
Require that every change made to the AWS environment is delivered as infrastructure as code or scripted configuration stored in a repository you control, with version history. Ask which tools produced the configuration and confirm you can rebuild the account state without the partner. Changes made only in the console will drift from the documented baseline and are hard to explain to an assessor. Include a handover session and a written runbook as deliverables in the scope.
Documented deviations and owners
Every Benchmark recommendation you do not implement needs a recorded deviation: the control, the account, the reason, the compensating measure and a named owner who reviews it on a set date. Ask the partner to draft the deviation register as part of the work and to flag each Level 2 recommendation that they advise against applying. Your organization owns the accept or reject decision. The partner's job is to make the trade-off visible and recorded.
What usually delays AWS Benchmark projects
The most common delay is applying Level 2 recommendations to production accounts without testing them first. Level 2 is meant for environments where security is paramount, and CIS warns that it can harm operations if applied without care. Teams that push Level 2 settings straight into shared production accounts often break workloads, logging pipelines or deployment roles, then spend weeks rolling back changes and arguing about who approved them. The safer sequence is to reach Level 1 across the estate, test Level 2 controls in a non-production account that mirrors production, and promote them only after the owners of each workload have signed off. Confirm the current Benchmark version and profile list on the CIS AWS Benchmarks page before you plan the work, since the version you test against is the version you must document.
Two other delays are unclear account ownership and benchmark version drift. A recommendation that fails in an account nobody owns can sit open for months, because no one is accountable for fixing it. Before remediation starts, record a named owner, a backup owner and an escalation contact for every account in AWS Organizations, including sandbox and decommissioned accounts. Version drift happens when a new Benchmark version is published, some accounts are scanned against the old version and others against the new one, and the results cannot be compared. Choose one version per reporting cycle, record it with each scan, and plan a deliberate migration when CIS publishes an update rather than letting teams adopt it piecemeal.
The last delay is unmanaged exceptions and evidence gathered by hand at audit time. Some recommendations will not fit a given account, for example where a legacy workload needs a broader policy or a service is intentionally public. Each deviation should go into a written exception register that states the recommendation, the affected account, the business reason, the compensating control, the approver and a review date. Schedule automated re-scans, with results stored centrally with timestamps, so the register and the scan history match when an assessor asks for them. Ask your implementation partner and your auditor to agree the evidence format before the first scan, because reconstructing months of scan results from memory is the step that most often pushes an assessment back.
How DeployOpen scopes and prepares AWS Benchmark evidence
DeployOpen works on the CIS AWS Foundations Benchmark and the service-level AWS Benchmarks inside your own AWS accounts, under a written scope. We prepare the configuration, checks and evidence; your organization owns its controls, and an independent assessor decides what the evidence proves.
How we scope
- We confirm which AWS accounts, regions and services fall in scope before any work starts.
- We agree in writing which Benchmark and version applies, and which Level profile your organization has chosen.
- We record any Recommendations you plan to deviate from, with the reason and who approved it.
How we build
- We configure AWS accounts and services to the agreed Benchmark profile, changing one area at a time.
- We set up automated checks that report each Recommendation's status against the agreed profile.
- We test changes in a non-production account first, so operational impact is found before rollout.
How we hand over
- We document the configuration, the checks used, and the evidence each check produces, mapped to your Safeguards.
- We deliver the fixed-scope documentation and run-books in the agreed format, with open items listed.
- We walk your security and platform teams through the evidence so they can repeat the checks themselves.
How we support
- Ongoing support, Benchmark version upgrades and continuous checks are available as a retainer.
- We review configuration drift and new AWS services against the Benchmark when you ask us to.
- Audit and assessment reports come from your independent assessor, which we support with evidence but do not issue.
