What Safeguard 16.7 hardening templates for application infrastructure require
Safeguard 16.7 asks the enterprise to adopt standard, industry-recommended hardening configuration templates for the infrastructure its applications run on, and to make sure in-house software does not undo them. It sits in the Software asset class and the Protect security function, and it is placed in Implementation Group 2, so an IG2 or IG3 enterprise preparing for an audit or customer review should expect it to be assessed. IG1 organizations are not required to meet it. The scope covers underlying servers, databases, web servers, cloud containers, PaaS and SaaS components. For each class, the reader needs a named baseline, such as a recognized CIS Benchmark or a vendor hardening guide, a documented decision on which profile applies, and a record of which components were built or reviewed against it.
The main threat named by the Safeguard is in-house code. An application can weaken a hardened host or service in ordinary ways: it may open a debug port, write secrets or permissive file modes into a configuration file, request elevated privileges at install time, or change a database setting to make a feature work. Those changes often arrive through a deployment pipeline that no one reviewed against the baseline. Checking the templates once at build time is therefore not enough. The reader should confirm that release pipelines test deployed configuration against the baseline and that developers cannot override it without a recorded exception.
Keeping templates current is harder than writing them. Vendors release new versions, benchmarks are revised, and each product line has its own profile, so the list of templates grows with the estate. The Safeguard is measured by the share of application infrastructure components that meet the industry configuration standard, so drift across a large number of hosts and containers counts against the score. Before a quote, ask a provider to state how many component types are in scope, which baselines will be used, how exceptions are approved and recorded, and who maintains the templates after handover. Those answers determine most of the recurring effort.
Which application infrastructure and teams fall under Safeguard 16.7
Safeguard 16.7 reaches further than the application code itself. The effort depends on which servers, databases, containers, PaaS and SaaS settings count as application infrastructure, which teams build software that runs on them, and whether the organization is in an Implementation Group that carries the Safeguard at all. Settle these decisions in writing before estimating work, because each one changes the number of components a compliance assessor will sample.
Core application infrastructure components
Start by listing every server, database, web server and container platform that hosts in-house or acquired applications. Under Safeguard 16.7, these components need standard, industry-recommended hardening configuration templates. Count each distinct template as a separate configuration baseline, since a compliance assessor will test each one against its Compliance metric. Ask the team to produce an inventory that ties each component to the application it supports, so that scope can be proven rather than asserted.
Containers and orchestration platforms
Container images, runtime hosts and orchestration clusters often change faster than servers do. Each image base and node configuration can drift from its template between releases, so the scope should cover both the build pipeline and the running hosts. Confirm which team owns each cluster and whether image hardening is enforced at build time, at deploy time or both. Runtime monitoring tools such as Falco can show whether a running container departs from expected behavior.
In-house teams that ship software
Safeguard 16.7 requires that in-house developed software does not weaken configuration hardening. Every team that deploys its own code, including teams that open firewall ports, change file permissions or install debugging tools for a release, falls within scope. Record which teams have deployment rights and which template exceptions they can request. Each exception that is granted becomes evidence an assessor will ask to see, along with its approval and expiry.
SaaS and PaaS settings the organization configures
Managed platforms still carry configuration the organization owns, such as tenant security options, storage access policies, identity settings and logging toggles. Safeguard 16.7 extends to PaaS and SaaS components, so these settings need a documented template too. Ask the platform owner which settings the vendor defaults and which the organization must change. Settings that the provider does not expose for review create a gap that should be recorded and explained, not ignored.
Prerequisite secure configuration process
Safeguard 16.7 depends on Safeguards 4.1 and 4.2, which cover the secure configuration process for enterprise assets and network infrastructure. An organization that has not yet written that process will spend extra effort building it before it can measure application templates. Confirm whether the secure configuration process already covers application infrastructure. If it does not, the scoping work should include extending it, which adds a documented review and approval step to the project.
Why IG1 organizations do not carry it
CIS places Safeguard 16.7 in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. An IG1 organization that builds little in-house software may not need this Safeguard in its CIS scope at all. Confirm the Implementation Group that applies to the organization before budgeting for template work, and treat any voluntary adoption as a separate decision with its own scope statement.
How an assessor measures the share of hardened application components
This table walks through how an assessor approaches Safeguard 16.7 under the CIS Controls Assessment Specification, from the Compliance metric and its prerequisites to the evidence requested and the findings that most often fail. The assessment specification defines what to measure, not how, so confirm the sampling approach and population definition with your assessor before fieldwork starts. Read each row as a question the assessor will ask and the proof you should have ready.
| Assessment element | What the assessor looks for | Common gap |
|---|---|---|
| Compliance metric | The share of application infrastructure components that meet the industry configuration standards you adopted | No agreed numerator or denominator, so the percentage cannot be reproduced |
| Component population | A complete list of servers, databases, web servers, containers, PaaS and SaaS components in scope | Cloud, container or SaaS components are missing from the population |
| Prerequisite 4.1 | A documented secure configuration process that governs how templates are chosen, applied and reviewed | Templates exist, but no process explains who approves and maintains them |
| Prerequisite 4.2 | A documented secure configuration process for network infrastructure that the application stack depends on | Load balancers, firewalls or service meshes are configured by hand with no written standard |
| Template evidence | Named, version-controlled hardening templates tied to recognized industry configuration standards | Templates are undocumented, copied between teams, or out of date with the vendor baseline |
| Measurement evidence | Scan or compliance results that show each in-scope component checked against its template, with dates | Only a sample was scanned, or results were never retained for the assessment period |
| Developer changes | Evidence that in-house software cannot weaken configuration, such as deployment checks and change records | Application teams change timeouts, debug flags or permissions in production and the change is not caught |
| Exceptions | A recorded, approved exception for each component that deviates, with a reason and review date | Deviations are fixed locally with no record, so the percentage looks higher than the real state |
How to roll out hardening templates across application infrastructure
This sequence turns Safeguard 16.7 from a written intention into a configuration baseline, drift detection, a controlled exception path and a measured compliance share that an assessor can test.
Confirm the secure configuration process exists
Before any template is applied, confirm that the documented secure configuration process required by Safeguards 4.1 and 4.2 is in place and covers application infrastructure, not only end-user devices and network equipment. The owner is usually the platform or infrastructure lead, with the security team reviewing. The output is the approved process document, the named owner for each component type, and a record of when it was last reviewed. An assessor will look for this first because the CIS Controls Assessment Specification lists both Safeguards as prerequisites for measuring 16.7.
Choose standard templates for each component type
Map every application infrastructure component to a recognized, industry-recommended hardening template. Typical component types include operating system images for application servers, database engines, web servers, container base images, Kubernetes clusters, and the configuration options exposed by PaaS and SaaS services. Where the organization runs CIS Benchmarks, record the chosen profile (for example Level 1 or Level 2) for each component. Where the organization picks another recognized template, record the source and version. The output is a template register that lists each component type, its template, its version and its owner, which becomes the reference the compliance metric is calculated against.
Set the templates in build and infrastructure code
Encode the chosen templates in golden images, configuration management, or infrastructure-as-code modules so new components are built to the baseline rather than hardened by hand after deployment. The platform team applies the change through the normal change process and tests it in a non-production environment first. Application teams should consume the approved images and modules, not rebuild them. The output is a versioned repository of images or modules, with a record of which template version each one implements and a change history an assessor can sample.
Run automated drift detection on running components
Build behavior is not enough on its own, because running systems change. Schedule an automated scan of deployed components against the template register, for example using a configuration assessment tool that checks files, services and settings against YAML policies or benchmark content. Open-source options include Wazuh Security Configuration Assessment for monitored endpoints, and Fleet policies (osquery queries) for device-level questions. Confirm the chosen tool can cover each component type, including containers and managed services where agents cannot run. The output is a scan report per component with pass or fail results and remediation guidance, retained as evidence.
Define the exception request and review path
Some in-house applications need a setting that the template forbids. Define how an application team requests an exception, what justification is required, who approves it, and how the exception expires or is reviewed. Software must not be allowed to weaken the hardening configuration, so the process should block application code from changing protected settings at deploy time and route any change through the exception path. Confirm with the security lead which exceptions require risk acceptance. The output is a written exception procedure, an exception log with approver and compensating controls recorded, and evidence that deployments outside the template were caught by the drift check.
Measure the compliance share and report it
Calculate the Compliance metric defined in the CIS Controls Assessment Specification for Safeguard 16.7: the share of application infrastructure components that meet the industry configuration standards in the template register. Count components in scope from the asset inventory, subtract those with approved exceptions only where the policy allows, and record the result over time. Review the figure on a regular cadence with the owners of each component type. The output is a dated metric report that shows the numerator, denominator, exceptions and trend, which is the artifact an assessor will ask to see alongside the template register and drift scans.
Which evidence shows the Compliance metric passes
The assessment specification scores Safeguard 16.7 by the share of application infrastructure components that meet industry configuration standards. The cards below cover the artifacts that let an assessor check that numerator and denominator, and that show in-house software has not loosened the templates. Each one needs a routine refresh so the evidence still matches the estate on the day of the audit.
Documented hardening templates by component
Keep one template per component type, such as operating system images, database servers, web servers, container base images and PaaS or SaaS tenant settings. Each template should name the source standard it follows, such as a CIS Benchmark or a vendor baseline, and record any deviations with a reason. Review each template when the source standard is updated and when a component type is added. Confirm with your assessor which baseline version they expect you to cite.
Configuration as code and version history
Store templates as code in a version-controlled repository so each setting has an author, a reason and a date. The history shows when a hardened value changed and who approved it. Confirm that the main branch is protected and that template changes need review before they reach production. Keep tagged releases so an assessor can compare the template in force on a given date with the one in use today.
Scan results against each template
Run configuration assessment on every in-scope component on a fixed schedule and keep the results. Open-source tools such as Wazuh Security Configuration Assessment use YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies. Fleet policies show which devices pass or fail each policy as osquery queries. Keep the pass and fail history per component so the compliance percentage can be reproduced for any period.
Component inventory as the denominator
The metric divides compliant components by all application infrastructure components, so an incomplete inventory inflates the score. Export the list of servers, databases, web servers, containers, PaaS services and SaaS tenants from your asset management system and reconcile it against cloud accounts and deployment pipelines. Ask an assessor how they will test completeness, for example by sampling a cloud account and checking that every resource appears in the list.
Exception records with approvals
Some components will deviate from the template for valid reasons, such as a legacy database or a vendor-managed service. Each exception should record the setting, the business and technical reason, the compensating control, the named approver and an expiry or review date. Exceptions with no owner or no end date are the usual finding. Review the register at each template release and remove exceptions that no longer apply.
Change records showing in-house releases keep settings
Safeguard 16.7 requires that in-house software does not weaken configuration hardening. Keep deployment records that show each release passed the hardening checks before it reached production, along with any change to a security setting, such as a firewall rule, TLS setting or container privilege flag. Pipeline logs and pull request approvals are the usual evidence. Check that the records cover application teams, not only platform teams.
Which open-source tools can produce hardening evidence
Several open-source tools can generate the configuration evidence an assessor will ask for under Safeguard 16.7, but none of them proves the whole safeguard on its own. Wazuh's Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies. Its policies are shipped mostly based on CIS benchmarks and can be extended with custom policies, so you can check the template you actually adopted for application servers, database hosts and web servers. Each policy checks files, directories, registry keys and running processes and recommends remediation. Export the pass and fail results per host as your compliance record, and confirm that the shipped policies match the benchmark version you selected for each platform.
Fleet (MIT) covers a different slice. Its policies are yes or no questions asked of devices as osquery queries, such as whether a disk is encrypted or a service is running with an approved configuration. The policies page shows which devices on each fleet pass or fail each policy, which gives you a current count of compliant components for the Compliance metric in the assessment specification. Write your own queries for settings the shipped policies do not cover, such as those specific to an in-house application's runtime. Confirm which query packs exist for your operating systems before you treat them as complete coverage.
Falco (Apache-2.0) provides evidence that the hardened state holds after deployment. It parses Linux syscalls at runtime, by default through an eBPF probe, and evaluates them against YAML rules that flag privilege escalation, unauthorized file modification, unexpected network connections and suspicious process execution. Container and Kubernetes metadata is attached to each event, and alerts can go to stdout, files, syslog, HTTP endpoints or programs. This matters most where in-house software is the likely source of drift, because it shows when a release or a process changes a locked configuration. For containers, GitLab Community Edition (MIT) container scanning runs Trivy against images, including base images and OS packages, and produces a JSON report job artifact and a CycloneDX SBOM file. Confirm that each license covers the components and use cases in your own environment, and check Trivy and rule coverage against your platforms before relying on any tool as proof.
What meeting Safeguard 16.7 costs in tooling, engineering and evidence upkeep
This table lists the cost components of running Safeguard 16.7, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No price or duration is given because none is supplied for this Safeguard, so use the drivers to build a written scope and ask each bidder to price every row separately.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Template design and approval | Platform or security engineers, plus the security and change approvers who sign off the baseline | One-time per component type, then recurring on each revision | Number of component types (OS, database, web server, container base, PaaS, SaaS), and how many baselines the organization already has from Safeguard 4.1 and 4.2 |
| Configuration engineering | Infrastructure engineers who build the hardened images, configuration management code and application-specific overrides | Mostly one-time, with recurring effort for new platforms | Number of applications and environments, and whether templates are reused across them or rebuilt per team |
| Drift scanning tooling | Licensed vendor (if purchased) or the internal team operating a self-hosted tool such as Wazuh Security Configuration Assessment or Fleet policies | Recurring license or hosting and maintenance | Number of monitored endpoints and assets, scan frequency, and whether the tool's policies match your chosen templates. Self-hosted open source removes license spend but not operating effort |
| Engineering time to remediate drift | Platform and application teams that fix the configuration or the code that weakened it | Recurring | Change frequency, how often in-house software writes configuration at runtime, and whether deployment pipelines enforce the template before release |
| Exception handling | Security governance staff who review, time-limit and approve deviations, and the owners who accept residual risk | Recurring | Number of applications that cannot meet a template without vendor or code changes, and whether exceptions have documented expiry dates |
| Evidence upkeep | Compliance or security operations staff who retain scan results, baseline versions, approvals and exception records | Recurring | Retention period required by your framework, the number of audit periods covered, and whether evidence is generated automatically or collected by hand |
| External review | Independent reviewers or consultants who test the templates and their enforcement before an assessment | Periodic, optional | Scope size, the number of applications in scope, and whether internal reviewers have prior experience with the benchmark you adopt |
| Assessor sampling | The independent auditor or assessor, who samples components and exceptions during an assessment | Recurring per assessment cycle | Number of components the auditor samples and how quickly the organization can produce scan history and approvals on request |
Who owns the templates, who prepares evidence and who issues the opinion
Your organization owns Safeguard 16.7. It decides which hardening templates are the standard for each application infrastructure component, who may approve a deviation from them, and whether in-house software is allowed to change a hardened setting at all. Those decisions are management decisions, so they stay with named owners in security and platform engineering, even when a partner does the technical build.
- Template ownership: Name an owner for each template family (servers, databases, web servers, containers, PaaS and SaaS settings) and record the benchmark or internal baseline it is based on.
- Exception approval: Decide who signs off a deviation, how long it lasts and how it is reviewed, so that application teams cannot weaken a setting informally.
- Application team rules: Write down what in-house software may and may not change in the infrastructure, such as file permissions, listening ports or runtime flags.
- Metric reporting: Own the compliance measure the assessment specification uses, meaning the share of components that meet the chosen standard, and review it on a set cycle.
Before engaging anyone, confirm which named person signs the template baseline and the exception register. Those records are what an assessor will ask for first.
An implementation partner such as DeployOpen works inside your environment to prepare the systems and evidence that Safeguard 16.7 needs. It builds or adapts the hardening templates, configures drift detection, and produces the reports and records that show how the templates were applied. It does not decide the risk position, approve exceptions or sign off that the control works.
- Template design: Adapt industry-recommended baselines to your platforms and document each deviation so the template can be reproduced.
- Drift tooling setup: Deploy and tune open-source checks such as Wazuh Security Configuration Assessment or Fleet policies, and connect their output to your records.
- Evidence preparation: Assemble configuration exports, scan reports, exception records and change history into a form your team and the assessor can follow.
- Exception process design: Draft the workflow for requesting, approving and expiring deviations, for your owners to adopt.
- Fixed scope: Agree the components, deliverables and timelines in writing before work starts, and state which items remain with your team.
Ask any partner to show in writing which tasks it performs and which it explicitly leaves to you or the assessor.
An independent auditor, assessor or certification body is the only party that reports on whether Safeguard 16.7 is met. It tests the design of your templates and the operation of your drift checks, samples components, and compares the evidence against the measure in the CIS Controls Assessment Specification. Its opinion must not be shaped by the people who built the controls.
- Testing approach: Select components, inspect the approved template and compare live settings to it, and check whether exceptions were approved and time-limited.
- Independence limits: An assessor should not design the templates or the evidence it then tests, and should disclose any advisory work it has done for you.
- Output: Only the assessor issues a report, attestation or certificate. Implementation work produces no opinion of its own.
- Scope of the opinion: Confirm with the assessor which framework the test is run against, since CIS Controls itself does not certify and must be mapped to a chosen framework.
Before you engage an assessor, confirm its accreditation status for the framework you need and request its independence statement in writing.
Where hardening programs fall short of Safeguard 16.7
Safeguard 16.7 asks for standard hardening templates across application infrastructure and for in-house software to leave those templates intact. Most shortfalls are not missing tools but gaps in ownership, mapping, change control and measurement that let the templates drift or go unverified.
Templates that are vendor defaults only
Many teams deploy servers, databases, web servers and container hosts with the factory configuration and call it hardened. A standard template should reflect an industry-recommended configuration, such as a CIS Benchmark profile, and record where the organization deviates from it. Check whether each template names its source, its version and the owner who approved its settings. Vendor defaults are often permissive, so they rarely satisfy the Safeguard on their own.
No mapping of components to templates
A template library means little if nobody can say which template governs which production asset. Build a register that links each application server, database, web server, container image, PaaS service and SaaS tenant to one template and version. Assessors will ask for this mapping first, because the Compliance metric in the assessment specification is a share of components, and a share cannot be calculated without a denominator.
In-house changes that bypass review
Application teams often change timeouts, debug flags, file permissions or TLS settings directly in configuration files or deployment scripts. Safeguard 16.7 says in-house software must not weaken hardening, so those changes need the same review path as code. Enforce this with pipeline checks that reject configuration drift and require a security approver for any change that touches a hardened setting.
Containers and PaaS left out of scanning
Configuration scanners are often pointed only at virtual machines, while container images, Kubernetes manifests and managed PaaS settings are checked, if at all, by hand. Include these in the scope of the hardening program and confirm that each scanner in use supports the platform. Verify that scan results from the pipeline and the running environment cover the same components, so a passing image does not hide a weak runtime setting.
No record of approved exceptions
Some components cannot meet a template because of legacy software, vendor requirements or performance limits. When those deviations are not written down, they become invisible and nobody can tell whether a failing result is accepted risk or an oversight. Keep an exception record for each deviation with the reason, the compensating control, the approver, the review date and the expiry. Assessors commonly sample exceptions to confirm they are current.
Compliance share never measured
Teams sometimes apply templates and never calculate how many components meet them, so the program has no baseline and no trend. Measure the share of application infrastructure components that pass their assigned template, report it on a fixed cadence and track it against the exception register. A simple dashboard fed by policy results is usually enough to show movement over time, and it gives the assessor the metric the specification defines.
What buyers ask about hardening templates, cost and effort
How much effort does Safeguard 16.7 take to implement?
The effort depends mostly on how many application infrastructure components are in scope and how far their current configuration already sits from an industry template. Safeguard 16.7 asks for standard, industry-recommended hardening templates for servers, databases, web servers, containers, PaaS and SaaS components, so the work covers choosing a template per component type, applying it, and keeping it applied. Teams with few components and a documented secure configuration process usually need far less effort than teams with many hand-built servers and no baseline. Ask the implementation partner to size the work from a component inventory, not from a general estimate.
Can our own team implement Safeguard 16.7 without outside help?
Yes, an organization can implement Safeguard 16.7 with its own staff, because CIS Controls content is free for organizations to use to improve their own security. The harder part is usually not applying a template once but keeping the templates current, documenting exceptions, and showing evidence on a regular basis. Outside help is most useful when the team lacks time, has no platform engineering capacity, or needs a second set of hands to build templates for mixed environments. An implementation partner prepares the systems and evidence, but the organization still owns the control and its results.
What do our engineers and application owners need to contribute?
Engineers need to own the templates and the configuration pipeline, while application owners need to confirm that their software runs under the template and that any deviation is justified. Because Safeguard 16.7 says in-house developed software must not weaken hardening, developers must know which settings they cannot change, such as opening unneeded ports, disabling logging, or running as root. Typical contributions include:
- Platform engineers writing and versioning templates in code.
- Application owners testing their software against the template before release.
- Security staff reviewing exceptions and checking scan results.
- Developers receiving clear rules on what their code may and may not change in shared infrastructure.
How long does it take to show a passing Compliance metric?
The time depends on how quickly the organization can bring all in-scope components under a template and produce a measurable pass rate. The CIS Controls Assessment Specification scores Safeguard 16.7 with a Compliance metric: the share of application infrastructure components that meet industry configuration standards. Before that metric means anything, Safeguards 4.1 and 4.2 must be in place as prerequisites, so a documented secure configuration process comes first. Ask for a plan that sequences prerequisites, pilot components, and then the full fleet, and confirm which evidence the assessor will accept for the measured share.
Do IG1 organizations have to comply with Safeguard 16.7?
No, Safeguard 16.7 does not apply to IG1 organizations. CIS Controls v8.1 places it in Implementation Group 2, so it applies to IG2 and IG3 enterprises. IG1 is defined as essential cyber hygiene and a minimum standard for every enterprise, and it does not include this Safeguard. An IG1 organization may still choose to adopt hardening templates because they reduce risk, but it should not describe that choice as meeting Safeguard 16.7 unless its assessor agrees the scope applies. Confirm the applicable Implementation Group with your own risk profile and any contract or regulator that names a target group.
What should we ask an implementation partner for in a fixed-scope quote?
Ask for a written scope that lists the component types, environments and cloud accounts covered, the templates to be built or adopted, and the deliverables. Most engagements are fixed-scope, so the quote should follow from that written scope rather than a generic package. Useful items to request include:
- A component inventory and the template chosen for each type.
- Work on prerequisites (Safeguards 4.1 and 4.2) and how they are documented.
- Testing approach, exception handling, and how compliance scanning is set up.
- Evidence to prepare for the assessor, and who will review it.
- Which activities recur, such as template updates and retainer-based support, and which are one-time.
Which open-source tools can show hardening compliance for application infrastructure?
Wazuh's Security Configuration Assessment can scan monitored endpoints for misconfigurations using YAML policies, most of which are based on CIS benchmarks and can be extended with custom policies. Fleet policies can ask yes or no questions of devices through osquery and show which devices pass or fail each policy. Both tools produce results that support the Compliance metric, but the organization must confirm that its chosen policies match the templates it adopted. Ask your implementation partner to show which tool covers each component type and where the evidence is stored.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the hardening templates, configuration checks and evidence that Safeguard 16.7 asks you to show. DeployOpen does not issue audit reports or certifications; your own assessor or auditor reviews the evidence and forms the conclusion.
How we scope
- Agree in writing which application infrastructure components fall in scope, such as servers, databases, web servers, container platforms, PaaS and SaaS tenants.
- Confirm which Safeguard 4.1 and 4.2 secure configuration processes already exist, since they are prerequisites for measuring Safeguard 16.7.
- Record which in-house applications could touch configuration baselines, and how deployment pipelines apply template changes to them.
How we build
- Select a standard, industry-recommended hardening baseline for each component class and document any deviations with a reason.
- Configure policy-as-code checks such as Wazuh Security Configuration Assessment policies and Fleet osquery policies to report pass or fail per device.
- Test that application deployments cannot override hardened settings, and that Falco rules flag unexpected privilege or file changes at runtime.
How we hand over
- Deliver the hardening templates, their version history and the written exception register so your team can maintain them.
- Provide compliance reports showing the share of components meeting the chosen configuration standard, which maps to the Compliance metric in the assessment specification.
- Document the evidence location, collection frequency and owner for each check so an independent assessor can trace it.
How we support
- Ongoing support, template updates and continuous testing are available as a retainer after the fixed-scope work ends.
- Review template changes when vendors or CIS publish updated baselines, and confirm the impact on your environment before rollout.
- Confirm with your assessor which evidence formats they accept before the review, since requirements vary by framework and organization.
