Are CIS Hardened Images enough to meet CIS Control 4 in the cloud?
CIS Hardened Images support CIS Control 4 but do not replace the secure configuration process that Safeguard 4.1 asks for. They are virtual machine images pre-hardened to CIS Benchmarks and deployed from cloud marketplaces on AWS, Azure, Google Cloud and Oracle Cloud. The image gives a cloud team a known starting configuration. Safeguard 4.1 asks the organization to maintain a written process for configuring enterprise assets securely, reviewed once a year or after significant changes, covering servers, end-user devices and applications. The image is an input to that process, not the process itself. Whether the image is enough depends on three things: the workloads, the Benchmark profile and the evidence the organization can produce. A stateless web tier running a standard operating system may need little beyond the image. A database host, a workload with custom agents, or a server that runs an application with its own configuration may drift from the baseline within weeks of launch. Confirm which Benchmark and profile the image is built to, and whether the CIS STIG Hardened Images variant is the right fit for any regulated or federal workload.
The organization still owns the decisions the image cannot make. Record which Benchmark recommendations were deviated from and why, test changes before rollout, and check running instances against the Benchmark after launch, because the image describes the configuration at build time only. Ask the reseller or marketplace listing which versions are current, how updates are delivered, and whether any Benchmark content is licensed differently from the image itself. Under the CIS Controls Assessment Specification, an assessor looks for the documented process and its outputs, so keep the build records, deviation log, scan reports and review minutes together. An independent assessor or certification body will decide whether that evidence satisfies a given framework.
Where CIS Hardened Images are sold and how each cloud deploys them
CIS names Amazon Web Services as one of the platforms where CIS Hardened Images are deployed from cloud marketplaces. On AWS, the image is launched from the AWS Marketplace listing, which then creates an EC2 instance in the account and region you select. The buyer subscribes to the listing and the instance is billed through the account, so the procurement and billing owner needs to be involved before launch.
- Image currency: Confirm the listing's version date and the CIS Benchmark version it was built against, and whether the publisher issues updated AMIs when a Benchmark is revised.
- Licensing: Read the listing's license and subscription terms, including whether the software charge is separate from the underlying instance charge.
- Region availability: Check which AWS Regions the specific AMI is published in, since a listing may not be available in every Region or GovCloud partition.
- Hardening scope: Ask which Benchmark profile is applied (Level 1, Level 2 or STIG) and whether the instance still needs your own baseline changes.
- Patching ownership: Establish who rebuilds or replaces the image after a vulnerability fix, and how you are notified.
Before relying on an AMI in production, record its listing version, subscription terms and Region list in your secure configuration evidence.
CIS names Azure as a platform for CIS Hardened Images. Azure images are typically sourced through the Azure Marketplace, where a virtual machine offer is deployed into a subscription, resource group and region of your choice. Because Azure separates offers, plans and images, the buyer should confirm which plan within the offer matches the Benchmark profile required by the security team.
- Image currency: Confirm the offer's image version and publication date, and how new versions are published to the marketplace.
- Plan selection: Check which plan maps to which CIS Benchmark profile, and whether a STIG-hardened plan is offered separately from the standard hardened image.
- Licensing: Review the offer's terms and any per-hour software charge alongside the compute charge, and confirm who holds the subscription.
- Region availability: Verify the plan is deployable in the regions and Azure Government or sovereign clouds you use, since offers are not always published everywhere.
- Update path: Ask whether an updated image replaces the existing one, and how running virtual machines are moved to it.
Keep a record of the offer name, plan identifier and version used for each deployed virtual machine so that auditors can trace each server to its hardened source.
CIS names Google Cloud Platform as a platform for CIS Hardened Images. These images are published through Google Cloud Marketplace and launched as Compute Engine virtual machines in a project you choose. The marketplace listing handles subscription and billing, while the image itself is a machine image that the project's own policies still govern.
- Image currency: Confirm the image family, version and build date in the listing, and how the publisher communicates new builds.
- Project policies: Check that organization policies, such as restrictions on allowed images, permit the CIS image family before deployment.
- Licensing: Read the listing's terms and whether the software charge is billed separately from Compute Engine usage.
- Region availability: Confirm the image is available in the zones and regions where your workloads run, including any restricted regions you operate in.
- Benchmark mapping: Ask which CIS Benchmark and profile the image was built to, and how the build was verified.
Write down the image family, project and listing version for each instance so the hardened configuration can be traced during an assessment.
CIS names Oracle Cloud as a platform for CIS Hardened Images. Oracle Cloud Infrastructure images are obtained through the Oracle Cloud Marketplace, and the listing is then used to create compute instances in a compartment within a tenancy. Because compartments and tenancy policies control image use, the buyer should coordinate with the tenancy administrator before purchase.
- Image currency: Confirm the listing version and the Benchmark version it corresponds to, and how newer images are published.
- Tenancy and compartment access: Verify that the image is visible to the compartments where workloads will run, and that policies allow its use.
- Licensing: Review the listing terms and the software charge, and confirm how marketplace billing is attributed within the tenancy.
- Region availability: Check which OCI regions carry the image, including dedicated or government regions if they apply to your deployment.
- Support boundaries: Clarify who supports the operating system, the hardening configuration and the Oracle-provided components.
Record the listing name, tenancy, compartment and image version for each instance, and confirm these details again before each major rebuild.
What CIS STIG Hardened Images add for federal and regulated buyers
CIS also offers STIG Hardened Images, built from CIS STIG Benchmarks that are mapped to DISA STIG standards. For a buyer launching a Linux or Windows server from the AWS, Azure, Google Cloud or Oracle Cloud marketplace, the choice is no longer only between a standard CIS Benchmark image and a bare cloud image. It is also whether the authorizing body expects the STIG-mapped configuration. The two are related but not interchangeable: a CIS Benchmark profile is a consensus configuration recommendation, while a STIG-mapped image is aligned to the DISA STIG requirements that federal and defense assessors usually test against.
Before selecting a variant, confirm with your authorizing official, contracting officer or assessor which configuration baseline the system boundary must show. Ask whether they accept a CIS Benchmark image, a CIS STIG image or a DISA STIG applied by your own team, and whether they require the STIG checklist results as evidence. Ask the cloud marketplace listing and CIS for the exact Benchmark version and profile each image implements, because the image name alone does not tell you which Level or STIG mapping was applied. Also check whether your cloud provider's authorization (for example, under the DoD Cloud Computing SRG or FedRAMP) covers the image you intend to use, since recognition of the configuration does not by itself authorize the system.
Plan for the work that remains after the image is launched. A hardened image sets a starting baseline, but your team still owns drift, exceptions and re-validation. Record any STIG finding that is not applied, the compensating control and the approver in the secure configuration process, and rerun a compliance scan after every image update or major change. Some STIG requirements depend on site-specific settings such as logging destinations, certificate stores or administrator roles, so budget time for that tailoring. Where a regulated buyer needs independent proof, the scan output and deviation records are the evidence an assessor will sample, not the marketplace description.
Which standards recognize CIS Benchmark configuration, and what that recognition covers
CIS states that its Benchmarks are recognized as a secure configuration standard by several government and industry bodies, and that this recognition extends to CIS Hardened Images. Each recognition covers a configuration baseline, and none of them certifies a system, so the assessor for each framework decides how much weight the baseline carries.
DoD Cloud Computing SRG
The Department of Defense Cloud Computing Security Requirements Guide is the baseline that cloud service offerings serving DoD workloads must meet. CIS states that its Benchmarks are recognized under this guide, and that the recognition extends to CIS Hardened Images. A hardened image can support the configuration part of a DoD cloud authorization, but the authorizing body still reviews the full system. Confirm with the assessor which Benchmark version and profile they accept.
PCI DSS configuration requirements
PCI DSS asks organizations to apply secure configuration standards to system components in the cardholder data environment and to keep them current. CIS states that the Benchmarks are recognized for this purpose and that the recognition covers CIS Hardened Images. A hardened image gives the team a documented starting configuration, but the qualified assessor still tests whether the configuration is applied, monitored and scoped correctly on each in-scope server.
FISMA federal system baselines
FISMA sets federal information security obligations that agencies and their contractors implement through NIST control baselines. CIS states that the Benchmarks are recognized under FISMA, extending to CIS Hardened Images. For a federal system, the image is an input to the system security plan and its configuration evidence. The authorizing official decides whether the baseline, any deviations and the scanning results satisfy the controls the system claims.
FFIEC examination expectations
The Federal Financial Institutions Examination Council publishes examination guidance that US banks are assessed against, including expectations for secure configuration of technology. CIS states that the Benchmarks are recognized under FFIEC guidance, extending to CIS Hardened Images. Examiners look at how an institution selects, applies, tests and documents its baseline, so the image alone does not answer an examination request. Confirm with your examiner or compliance team how the baseline is documented.
FedRAMP authorization packages
FedRAMP authorizes cloud services for federal use and relies on documented baseline configurations in the system security plan. CIS states that the Benchmarks are recognized under FedRAMP, extending to CIS Hardened Images. A cloud provider or service owner should record which image, Benchmark version and profile each server uses, and how deviations are approved. The FedRAMP assessor and authorizing official decide whether that record is sufficient for the authorization.
NIST and the National Checklist Program
NIST maintains the National Checklist Program Repository, which lists secure configuration checklists that federal and commercial teams reference. CIS states that the Benchmarks are recognized in this repository and that the recognition extends to CIS Hardened Images. Listing in a repository is a statement about the content of the checklist. It does not show that a particular deployed image has been tested or that it meets a particular control. Confirm which checklist version your assessor expects you to use.
How a CIS Hardened Image fits a secure configuration process for cloud servers
The sequence below turns a CIS Hardened Image into evidence for Safeguard 4.1, so the organization can show which Benchmark profile it chose, why, how it was tested, what deviates from it and whether the running servers still match it.
Select the image and Benchmark profile
The organization owns this decision. The platform or security team picks the cloud marketplace image that matches the operating system and the CIS Benchmark it is built to, then records the Benchmark version and profile (Level 1, Level 2 or a STIG profile where a regulator or federal contract requires it). Confirm the exact image, publisher and Benchmark version in the vendor listing before purchase, since image availability differs across AWS, Azure, Google Cloud and Oracle Cloud. The output is a short configuration decision record that names the image, the Benchmark and the reason for the profile, which the assessor will ask to see.
Test the image against the workload
Deploy the chosen image to a non-production environment that mirrors the production workload, then run the application, agents, backup jobs and monitoring against it. Hardening that breaks a service is the main reason teams later relax settings, so this step checks the operational impact before rollout. The output is a test record listing what was tested, which services passed and which settings caused failures, with the date and the people who signed off.
Document deviations from the Benchmark
Every Benchmark recommendation that the workload cannot accept needs a recorded deviation: the setting, the reason, the compensating control, the approver and a review date. This is the step that makes Safeguard 4.1 defensible, because it shows the process was followed rather than the image being applied and forgotten. The output is a deviation register linked to the configuration decision record. Ask your auditor which format they accept before you start.
Build the server through infrastructure as code
Define the hardened image ID, instance settings, security groups or network rules, and any additional configuration in infrastructure as code such as Terraform or CloudFormation, stored in version control. Changes then go through review and leave a history. Using the same template for every server makes the configuration reproducible and avoids manual drift at launch. The output is the committed template and the pipeline record showing who approved each change and which image version was deployed.
Scan running servers for configuration drift
After deployment, run a scanner against the live servers to compare their settings with the chosen Benchmark profile and the deviation register. Tools such as CIS-CAT or open-source options listed in the related guides can produce these reports, and confirm the scanner supports the Benchmark version you selected. Drift caused by updates, manual changes or agent installs appears here. The output is a scan report per server or image group, plus a ticket for each unexplained difference.
Remediate drift and update the baseline
Fix unexplained differences by correcting the running system or the infrastructure as code, then rescan to confirm the fix. If a difference is legitimate, add it to the deviation register with its approval instead of leaving it undocumented. Patch and image updates should trigger a new test cycle before the new image reaches production. The output is closed remediation tickets, updated templates and a rescan that matches the register.
Review yearly and after significant change
Safeguard 4.1 expects the secure configuration process to be reviewed once a year or after significant enterprise changes, such as a new cloud region, a change in regulated workload or a new Benchmark version. The review re-checks the image choice, the profile, the deviation register and the scan history, then updates the written process. The output is a dated review record with the decisions made, which is the evidence an assessor will request to confirm the process is maintained, not written once.
When an MSP or consultant should use the CIS reseller program
CIS runs a reseller program that lets managed service providers, MSSPs and IT consultants sell CIS Hardened Images to their clients. The cards below help you decide whether a provider-led route fits your organization, and what stays with you whichever route you take.
What the reseller program is
CIS offers a reseller program under which MSPs, MSSPs and IT consultants can sell CIS Hardened Images to their clients. The provider sits between CIS and the client, so the image licensing and the configuration baseline reach the client through the provider's contract. Ask the provider to show you exactly which CIS terms apply to the images they sell you, which marketplace or channel delivers them, and who you contact for support when an image needs updating on AWS, Azure, Google Cloud or Oracle Cloud.
When a provider route fits
A provider-led route tends to suit organizations that run many cloud accounts, lack in-house hardening staff, or want one party to manage image selection, deployment and patching across several clouds. It also suits buyers who prefer a single monthly relationship over managing marketplace subscriptions directly. Weigh that convenience against how much visibility you keep into the image build, the hardening level applied, and the change history for each server.
When buying direct makes more sense
A direct purchase, through a cloud marketplace or from CIS, keeps your contract and your support path with the image publisher. This suits teams with strong cloud engineering skills that want to control image versions and update timing themselves. It also suits organizations that already buy through a marketplace and need the images to appear on existing procurement and billing records. Confirm which route gives you the support terms you need before you choose.
Responsibility stays with the client
Whichever route you use, the organization still owns its controls. A reseller can supply or deploy images, but it does not decide your risk acceptance, approve deviations from the Benchmark, or produce your evidence for an assessor. Keep your own record of which images run where, which Benchmark profile they follow, and who approved any change. Include these duties in the written agreement with the provider so that responsibility for each item is explicit.
Contract terms to check
Before signing with a provider, ask who handles image updates when CIS revises a Benchmark, how quickly failed hardening checks are reported to you, and what happens to your images if the reseller relationship ends. Ask for the scope of support, the process for approving changes in your environment, and how the provider records drift from the hardened baseline. Get these answers in writing, because they decide who acts when a configuration falls out of line.
Evidence the provider must hand over
A provider should give you records that show the hardened baseline is in place and kept there. These include the image name and version deployed to each cloud account, the Benchmark profile applied, scan results from a tool such as CIS-CAT or an open-source scanner, and a log of exceptions with their approvals. Confirm the format and retention period for these records in the agreement, so that your auditor can trace each server back to an approved configuration.
What a hardened image does not cover in a cloud environment
A CIS Hardened Image secures the operating system build it ships with. The cloud account, the applications installed on top, the patches applied after launch and the workloads built from custom copies all remain with the organization, so each of these needs its own check.
Application configuration
The image hardens the operating system and its base services, not the web server, database, container runtime or application stack installed later. A server can pass its OS Benchmark profile and still expose a default admin console or run with weak TLS settings. Check each application against its own CIS Benchmark or vendor hardening guide after deployment, and record the result in your secure configuration process under Safeguard 4.1.
Cloud control-plane settings
Account-level settings such as storage public access, logging, network rules and key policies sit in the cloud control plane, outside any instance image. The CIS AWS Foundations Benchmark and the Benchmarks for Azure, Google Cloud and Oracle Cloud cover these settings. Confirm which Benchmark version your organization assesses against, because a hardened guest OS cannot correct a permissive bucket policy or an open security group.
Patch cadence after launch
A hardened image reflects the patch level at its build date. Instances launched from it and left running will fall behind as new vulnerabilities are published. Ask the image provider how often and through which channel updated images are released, then define your own patch window for running instances, test rollouts, and confirm that vulnerability scanning covers the deployed servers, not only the image catalog.
Identity and logging
Hardening rarely covers who can sign in or whether activity is recorded. Administrator accounts, SSH key distribution, IAM roles attached to instances and audit log forwarding each need configuration after launch. Confirm that privileged access is limited to named accounts, that logs leave the instance for central retention, and that time synchronization is consistent across the fleet, as Safeguards in Controls 5, 6 and 8 require.
Workloads built from custom images
Teams often copy a hardened image, install packages and save the result as a new custom image. Each copy inherits the original hardening but can drift from it through later changes, and the copy is no longer the image the provider maintains. Track the lineage of every custom image, re-run the Benchmark scan on each new build, and retire images that no longer match your approved baseline.
Questions buyers ask about CIS Hardened Images
Does using a CIS Hardened Image alone satisfy Safeguard 4.1?
No. Safeguard 4.1 asks the organization to establish and maintain a secure configuration process, covering the documented process, its annual review and the handling of deviations. A hardened image is one input to that process. It gives you a starting configuration aligned to a CIS Benchmark, but the organization still owns the written process, the decision to adopt the image, the record of any changes made after launch, and the review cycle. Ask any partner or assessor to show you how the image feeds into your documented process before you treat it as the control.
Do we need a STIG-hardened variant or is the standard image enough?
It depends on who recognizes your configuration. CIS also offers CIS STIG Hardened Images, based on CIS STIG Benchmarks that map to DISA STIG standards. Commercial buyers often accept a standard CIS Benchmark image, while federal or defense-related workloads may require STIG-based configuration. Check the contract, system security plan or authorization boundary first, then confirm with the buyer which profile they will accept. Do not assume one variant satisfies both audiences.
How is the cost of CIS Hardened Images structured?
Expect costs in three groups: the image itself, purchased from the cloud marketplace where it is listed, with its own pricing terms; internal effort to select, test and approve the image; and any partner effort to build the deployment pipeline, document deviations and produce evidence. Image pricing is set by the marketplace listing, so read the current listing for your platform rather than relying on a third-party figure. Internal and partner effort are largely one-time, while image licensing and ongoing patching and review recur. Ask any quote to separate these lines.
How long does it take to adopt CIS Hardened Images?
The timeline depends on the number of server types, the depth of testing and how many workloads must move. The main steps are choosing the image variant, validating the Benchmark profile against your applications, building a repeatable deployment template, recording deviations and collecting evidence. Small estates with one or two server roles can move quickly, while complex estates with legacy applications take longer because testing takes most of the time. Request a timeline in writing that lists each phase and its dependencies before work begins.
What does our team need to supply for an adoption project?
Plan for named owners and access. You will typically need cloud account administrators to grant marketplace subscription and deployment rights, application owners who can confirm which settings break their software, a change approver for the secure configuration process, and read access to logs and inventory so that drift can be measured. You also need a decision on which Benchmark profile applies. Ask the implementation partner to list these inputs in the scope document so that dependencies are visible from the start.
Will an assessor accept a CIS Hardened Image as evidence?
An assessor decides, not the image vendor or the partner. CIS states that its Benchmark recognition extends to CIS Hardened Images under several standards, but acceptance depends on the framework, the assessment scope and the assessor's judgment. Ask your assessor early whether they accept the image and the Benchmark profile as configuration evidence, and what they will sample. Keep the image version, the Benchmark version, scan results and deviation records together so the evidence can be traced.
Can a partner configure, document and support the hardened images for us?
Yes, DeployOpen works on self-hosted open-source platforms inside your own cloud accounts, and can plan, implement, harden and document secure configuration for systems you run. It does not issue audit reports or certifications, and it does not resell CIS Hardened Images as a CIS partner. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask any partner to state which parts of the image, the Benchmark profile, the evidence and the assessment they own.
Who owns the controls, who prepares the evidence and who issues the report
The organization owns its controls and its Benchmark decisions. When it deploys CIS Hardened Images on AWS, Azure, Google Cloud or Oracle Cloud, the organization decides which image and which Benchmark profile apply to each workload, records any deviation from a recommendation and accepts the residual risk. A marketplace image is a starting point, not a finished control. Applying it to a database server that needs a service the Benchmark disables is still the organization's decision, and that decision belongs in its secure configuration process under Safeguard 4.1, with a named owner and a review date.
An implementation partner prepares the images, configuration and evidence. A partner such as DeployOpen can select the image variant, build the cloud accounts and launch templates, apply organization-specific tailoring, run a scan against the chosen Benchmark profile, export the results and assemble the records an assessor will ask for. Before engaging one, ask for the written scope to name the exact images, Benchmark versions, regions, accounts and scan tooling, and to state who keeps the hardening baseline current after launch. Partners do not certify the result. Confirm in writing that the partner will not present its own work as an independent assessment.
Only an independent auditor, assessor or certification body issues a report or certificate. Whether a client's review is a SOC 2 examination, an ISO/IEC 27001 certification audit or a customer questionnaire, the report comes from the party that holds that role, not from the partner or from CIS. Note that CIS Controls Accreditation is a CIS program, run with CREST, that applies to CIS SecureSuite member organizations providing CIS Controls implementation, auditing or assessment services. Being a CIS SecureSuite member or holding an accreditation claim is not a substitute for an independent assessment. Ask any provider to show the accreditation status in writing and to name the current scope.

