Which CIS Benchmark profile should we choose for our CIS Benchmark Level 1 vs Level 2 vs STIG profiles decision?
Level 1 is the base profile to implement first, and Level 2 is for environments where security is paramount. A contract, customer or regulator that asks you to harden systems against a CIS Benchmark usually does not specify a profile, so the choice is yours to make and document. Level 1 is meant to be implemented fairly quickly with minimal performance impact while reducing attack surface and keeping systems usable. Level 2 adds defense in depth, and CIS warns that it can harm operations if applied without care. The STIG profile replaced the former Level 3 profile. It includes all STIG-specific recommendations plus the overlapping Level 1 and Level 2 recommendations where they apply, so it is the profile to examine when federal or DISA-aligned requirements are in play.
The right profile depends on three things: the role of each system, your risk tolerance for that role, and your capacity to test changes before they reach production. A domain controller, a payment-facing application server and a shared developer workstation do not carry the same operational risk, so one profile across all of them is rarely the right answer. Start by applying Level 1 to the broad estate, then decide per system role whether Level 2 or the STIG profile is justified. CIS advises testing any Benchmark profile in a non-production environment before applying it, so confirm that you have a staging environment that mirrors production closely enough to catch breaking changes. Record every recommendation you skip or modify as a deviation, with the reason, the compensating control, the approver and a review date, in the secure configuration process that Safeguard 4.1 requires.
Your organization owns these configuration decisions and every deviation. An implementation partner can prepare the baseline, build the test environment, apply the chosen profile and assemble the configuration evidence, but the partner does not decide which recommendations you accept. Only an independent assessor issues any report or attestation about your configuration. Before you ask for a quote, confirm with the partner which profiles, system roles and test environments are in scope, and ask how deviations will be documented. The CIS Benchmarks FAQ explains the profile definitions and is the natural next read before you draft your decision record.
How to decide which profile fits a given system
Choosing between Level 1, Level 2 and the STIG profile is a judgment about the system, not a ranking of strictness. The factors below connect the system's role, its tolerance for disruption, any federal or STIG obligations, the exact wording of what you must meet, and whether your team can test and roll back changes before they reach production.
System role and exposure
Start with what the system does and who can reach it. A internet-facing server that handles sensitive data or sits in a segment with many trusted paths usually justifies stricter settings than an internal build agent with no inbound access. CIS describes Level 1 as a base profile that reduces attack surface while keeping systems usable, and Level 2 as defense in depth for environments where security is paramount. Check the asset inventory entry, the network diagram and the data classification for the system before choosing.
Tolerance for downtime or breakage
Level 2 settings can disable functions that applications depend on, and CIS warns that it can harm operations if applied without care. Ask the system owner which services, integrations and scheduled jobs must keep running, and how long an outage or a broken workflow would be tolerated. A system with a narrow maintenance window or a fragile legacy dependency points toward Level 1, with Level 2 reserved for components that can be tested in isolation first.
Federal or STIG-driven requirements
If a contract, federal program or authorization names DISA STIGs, the STIG profile inside the CIS Benchmark is the profile that carries those recommendations. It replaces the former Level 3 profile and includes STIG-specific recommendations along with overlapping Level 1 and Level 2 items where applicable. Confirm in writing which STIG version and which recognized baseline the assessor will accept, because a generic Level 2 result does not automatically satisfy a STIG requirement.
Regulatory and contract wording
Read the clause that drives the hardening requirement and note the exact verb and object. Wording that asks for a recognized hardening baseline, a documented configuration standard or a specific benchmark points to a named profile. Wording that asks only for secure configuration leaves the choice to you, and the decision should then be recorded with its reasoning. Ask your auditor or the customer which profile they expect for each system class before rollout, since CIS states that the Controls do not replace any regulatory or compliance scheme.
Team capacity to test and roll back
CIS advises testing any Benchmark profile in a non-production environment before applying it. Check whether your team has a staging copy of the system, a documented rollback method such as a tested image or configuration snapshot, and people who can review failed checks. Without these, Level 2 adds risk that outweighs its benefit, and a deviation from any recommendation should be recorded with a reason, an owner and a review date in your secure configuration process.
Why Level 2 can break operations if applied without care
CIS warns that Level 2 can harm operations when it is applied without care, and the risk comes from what the stricter settings do rather than from the Benchmark itself. Level 2 is written as defense in depth for environments where security is paramount, so its recommendations tighten behavior that Level 1 leaves alone. In practice, those tighter settings can block legitimate services, break integrations that depend on a protocol or authentication method the Benchmark now restricts, change how logs are generated or forwarded, alter authentication behavior that users rely on, and disrupt the people who work on those systems every day. Each of these effects is hard to predict from the Benchmark text alone, which is why the risk sits in the rollout rather than in the recommendation.
The practical response is to scope Level 2 to a short list of high-value systems, such as a domain controller, a payment-adjacent database server or a privileged management host, and to document for each one which services, integrations, log consumers and administrative paths must keep working. Confirm the owner of each dependency before changing anything, and check whether the Benchmark's recommendations overlap with the STIG profile if your environment already has a hardening requirement. Do not apply Level 2 fleet-wide in one step. Apply it to a non-production copy of the scoped systems first, as CIS advises for any profile, then run the application, integration and logging tests that matter to the business. Only after those tests pass should the change move to production, one system group at a time, with a tested way to roll back.
Record every recommendation that cannot be met or is deliberately relaxed as a documented deviation in the secure configuration process, with the business reason, the compensating control, the approver and a review date. Ask the team delivering the change to state how it will detect breakage after go-live, such as service health checks and log pipeline monitoring, and how long it will keep the previous configuration available for rollback. A Level 2 rollout that cannot show its scope, test results and deviations is hard to defend to an assessor, and it is also the rollout most likely to trigger an outage.
How to test a profile before it reaches production
This sequence turns a CIS Benchmark profile choice into a tested, documented configuration change. Each step produces a record that shows what was applied, what broke, what was accepted as an exception and how the change can be reversed. CIS advises testing any Benchmark profile in a non-production environment before applying it.
Select the profile and Benchmark version
The platform owner and security lead choose the Benchmark, its version and the profile, either Level 1, Level 2 or STIG, for each system group. Level 1 is the base profile meant to be implemented fairly quickly with minimal performance impact. Level 2 adds defense in depth for environments where security is paramount, and CIS warns it can harm operations if applied without care. The STIG profile replaces the former Level 3 profile and includes all STIG-specific recommendations plus overlapping Level 1 and Level 2 recommendations. The output is a short profile decision record per system group, naming the Benchmark version, profile, owner and the reason for the choice.
Build a non-production baseline
The platform team builds a test environment that mirrors production in operating system version, installed applications, service configuration, identity integration and network paths. Where the environment differs, the differences are listed. Data is either synthetic or handled under the same controls as production. The output is a baseline record with system images or build definitions, versions and a list of known differences from production. Without this record, later test results cannot be trusted to predict production behavior.
Apply the profile to the test baseline
The team applies the chosen profile to the test systems using the same automation that production will use, such as configuration management or infrastructure as code kept under version control. Applying by hand makes the result hard to reproduce. The output is a logged change run for each test system that records the profile, the Benchmark version and the run identifier. If a recommendation cannot be applied automatically, it is recorded for the deviation step rather than applied ad hoc.
Run the Benchmark assessment
The team scans the hardened test systems against the same Benchmark profile using a scanner such as CIS-CAT or an open-source checker, depending on the tools the organization has licensed or adopted. The scan result lists each recommendation as passed, failed or not applicable. The output is a saved scan report for each test system, kept with the profile decision record so an assessor can trace the result to the configuration that produced it. Confirm which scanner the Benchmark and its license terms support before relying on the results.
Test application and business functions
Application owners and business users run their normal workflows on the hardened test systems, including logins, batch jobs, backups, monitoring, integrations and any vendor support requirements. Level 2 settings are the most likely to break these functions, so this step matters most for them. The output is a signed functional test result listing each workflow, who tested it and whether it passed. Any failure returns to the deviation step with the specific setting that caused it.
Document each failed or changed setting
For every recommendation that failed, was changed from the Benchmark value or was not applied, the owner records the setting, the reason, the compensating control if one exists, the affected systems and the planned review date. This is the deviation record that the secure configuration process requires the organization to keep current. The output is a deviation register entry for each item, linked to the scan report and the functional test result. Entries without a compensating control or a named owner should not be accepted.
Approve exceptions through the change process
The risk owner, who is usually a senior security or operations leader, reviews the deviation register and approves, rejects or sends back each exception. Approval should be recorded in the organization's change management system so the decision is traceable. The output is a signed exception approval for each accepted deviation, along with the list of rejected items that must be fixed before rollout. Ask your auditor which approval level they expect for exceptions before the first assessment cycle.
Roll out in stages with a rollback plan
The team moves the approved profile into production in stages, starting with a small group of low-impact systems and widening the group only after monitoring shows normal behavior. Each stage has a rollback plan that states how to restore the previous configuration, who decides to roll back and the signals that trigger it. The output is a rollout log for each stage, a tested rollback procedure and a post-rollout scan report showing the production state. Records from every stage are kept with the profile decision record so the change history is complete.
Who owns the profile decision, the testing and the evidence
The organization owns the secure configuration decision. Its leadership chooses which Benchmark profile applies to each asset group, accepts the operational risk that comes with that choice, and approves any deviation from the recommendations. Safeguard 4.1 asks for a written process for configuring enterprise assets securely, and that process needs an owner who signs it off and reviews it at least once a year or after a significant change in the enterprise. An implementation partner can draft that process, but it becomes the organization's process only when the organization adopts it.
- Profile selection: Decide whether Level 1, Level 2 or the STIG profile fits each system based on its function, data sensitivity and tolerance for disruption.
- Risk acceptance: Record who accepts the residual risk of every recommendation left unapplied, and the expiry or review date of that acceptance.
- Deviation records: Keep a register that names each deviation, its justification, its compensating controls and its owner.
- Process approval: Approve the written secure configuration process and confirm the annual review date.
- Business input: Confirm with application owners which services must keep working during rollout, since Level 2 settings can break operations if applied without care.
Check that every profile decision has a named approver with the authority to accept the risk, not only the engineer who ran the scan.
The implementation partner prepares the systems and the evidence. Under a fixed-scope engagement, the partner builds baseline images or configuration code, applies the chosen profile, tests the result in a non-production environment and documents what changed. CIS advises testing any Benchmark profile in a non-production environment before it is applied, so that step belongs in the written scope. The partner does not decide the risk of an unapplied recommendation and does not sign off the configuration on the organization's behalf.
- Baseline preparation: Build the hardened baseline for each platform in scope, and keep its configuration in version-controlled infrastructure as code where the design allows.
- Profile testing: Apply the profile in a staging environment, check application behavior and record every failed or disabled recommendation.
- Deviation documentation: Write up each deviation with the technical reason and the compensating control proposed, then route it to the organization for approval.
- Scan results: Produce benchmark scan reports and show how the results map to the chosen profile and the owned baselines.
- Handover: Deliver runbooks and evidence packs so the organization can repeat the process without the partner.
Check the scope document for who performs the non-production testing, who keeps the scan output, and how long the partner retains the evidence after handover.
The independent assessor examines the evidence and reaches its own conclusions. An auditor, assessor or certification body is the only party that issues a report or certificate. For a CIS Benchmark profile, an assessor typically samples systems, compares the running configuration against the approved profile, and checks that deviations were approved and reviewed. The assessor does not configure systems or write the baseline, because that would remove the independence the report depends on. Where a customer or regulator requires a specific assurance report, the assessor's scope and the report type should be agreed before the evidence is collected.
- Sampling: Select a sample of systems across the environment and compare their configuration to the approved baseline.
- Deviation review: Confirm that each deviation has an approver, a justification and a review date.
- Process review: Check the written secure configuration process against Safeguard 4.1, including its annual review record.
- Change evidence: Review change records and version history to confirm that baselines were tested before rollout.
- Report issuance: Issue the report or certificate in the assessor's own name, based on its own testing.
Before engaging an assessor, confirm which standard or framework the report will address and whether the assessor is accredited for it. Ask how it will treat evidence produced by the implementation partner.
Recording deviations in the secure configuration process
Every departure from a profile recommendation should be recorded as a deviation with its own entry in the secure configuration process, not left as an undocumented setting on one server. A usable record names the setting and the Benchmark recommendation it departs from, the operational reason, the compensating control that reduces the risk the recommendation addresses, the accountable owner, the approver, and a review date. Without those fields, an exception made during a Level 2 rollout tends to become permanent, and an assessor reviewing Safeguard 4.1 will find configuration that no one can explain.
Safeguard 4.1 asks for a written process for configuring enterprise assets securely, reviewed once a year or after significant enterprise changes, so the deviation register should be a controlled part of that process. Link each entry to the profile and version it was assessed against, and reopen every entry when the Benchmark is updated or the system changes. Confirm with your assessor how they expect the register to be stored and who signs off on it, because the CIS Controls do not prescribe a format.
Deviations touching administrative access need more scrutiny. Safeguard 4.6 expects administrative interfaces to be reached over secure protocols such as SSH and HTTPS, and expects insecure protocols such as Telnet and HTTP to be avoided unless they are operationally essential. A deviation that re-enables an insecure protocol, relaxes SSH key or root login settings, or leaves a management port exposed should name the specific operational need, the systems that depend on it, the network restrictions that limit exposure, and a date to remove it. Keeping the configuration in version-controlled infrastructure as code makes each such change traceable to a reviewed commit, which is the evidence most assessors ask to see.
Common questions about choosing a CIS Benchmark profile
Is Level 1 enough for most systems?
For most systems, Level 1 is the sensible starting point. CIS describes Level 1 as a base profile meant to be implemented fairly quickly, with minimal performance impact, that reduces attack surface while keeping systems usable. Whether it is enough depends on what the system does and what it protects. A general-purpose server holding ordinary business data may reasonably stay at Level 1 for its first hardening cycle. A system that handles regulated data, sits on a sensitive network segment or faces higher threat exposure may need Level 2 recommendations or a STIG profile added after testing. Ask your security team to classify each system by impact and document the profile chosen for each class, along with the reasons.
Does any standard require Level 2?
No supplied source names a standard that requires Level 2 specifically, so confirm this against each framework and contract you are subject to. The CIS Controls state that they do not replace regulatory, compliance or authorization schemes, and CIS maps the Controls to many frameworks through its Navigator. Read the requirement text itself, and ask your assessor how they will accept evidence of secure configuration. Many organizations document a Level 1 baseline for general systems, then record justified Level 2 settings for high-sensitivity systems. Whatever you choose, the written secure configuration process under Safeguard 4.1 is where the decision and its reasons should be recorded.
What is the STIG profile for?
The STIG profile is the profile inside a CIS Benchmark that carries the DISA Security Technical Implementation Guide recommendations. CIS says it replaces the former Level 3 profile. It includes all STIG-specific recommendations plus overlapping Level 1 and Level 2 recommendations where applicable, and every recommendation belongs to at least one profile. Organizations that must align with DoD or other federal STIG requirements usually choose this profile. Commercial organizations may use it when they want the stricter DISA-derived settings. Expect more settings to need testing and exception handling, because the profile is broader than Level 1. Check the current STIG requirements that apply to your contract with the authorizing body.
Do the CIS Benchmarks cost anything to use?
The answer depends on the Benchmark and on how you use it, so confirm the current terms on the CIS website before you commit. Some Benchmarks and tools are available free, and some features or content require CIS SecureSuite membership. Your costs usually come from staff time, testing infrastructure, change management and any scanning tool you buy. Ask CIS for written confirmation of the terms that apply to your use case, including whether internal use, reporting and commercial services are covered. Ask your implementation partner to separate licensing fees from labor in any quote.
How long does testing a profile take?
The time depends on the number of systems, how similar they are, and how many applications run on them. Testing time grows with the number of distinct system images and roles, because each image needs its own check for broken services and integrations. Other drivers include how many recommendations you adopt beyond Level 1, how many business applications must be validated after each change, the availability of non-production environments that mirror production, and the number of deviations that need review. Build a test plan that groups systems by image and role, then ask whether testing can run in parallel. CIS advises testing any profile in a non-production environment before applying it.
Can our own team apply and test a profile?
Often yes, if your team has the skills and capacity to change configuration, run regression checks and record decisions. Your team owns the controls, so the core questions stay in-house: which profile applies, which recommendations you accept, and which deviations you approve. Capacity is usually the constraint, not knowledge. An implementation partner can prepare hardening automation, run test cycles, document deviations and prepare evidence, but the organization still makes the risk decisions and an independent assessor still reviews the results. Ask any partner for a fixed scope in writing before work begins, and keep the approval of each deviation within your own process.
How DeployOpen scopes, tests and documents a hardening profile
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, so the choice of CIS Benchmark profile is made against the client's real systems and risk appetite. The work covers scoping the profile, applying it in a non-production environment, testing the effect and documenting every deviation for the secure configuration process.
How we scope
- The written scope names which systems, operating systems and applications the chosen profile covers.
- Scope records whether Level 1, Level 2 or STIG recommendations apply, and which business services each could affect.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before hardening work starts.
How we build
- Profiles are applied first in a non-production environment, following CIS guidance to test every Benchmark profile before rollout.
- Each recommendation is reviewed for operational impact on the platform, its integrations and its administrators.
- Settings that break required functions are tracked as candidate deviations rather than silently excluded or forced through.
How we hand over
- The handover includes the applied profile, the configuration baseline and the scan results from the test environment.
- Each accepted deviation is documented with its reason, owner and approval, ready for the secure configuration process.
- The organization owns its controls and its review cycle, and an independent assessor decides how the evidence is judged.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Profile reviews can be scheduled after significant enterprise changes, which the secure configuration process should trigger.
- Confirm with DeployOpen during scoping which support terms, reporting and retest activities are included in the written scope.
