What Safeguard 2.7 asks for when scripts can run on your endpoints
If your enterprise is in Implementation Group 3, scripts such as .ps1 and .py files can run on your endpoints, and Safeguard 2.7 asks you to control which of them may execute. Only approved scripts may run, all others are blocked, and the control is reassessed at least twice a year. The Safeguard sits in the Software asset class and the Protect security function of CIS Controls v8.1, and it is assigned to Implementation Group 3 only, so it is not part of the IG1 or IG2 baseline. Organizations in IG3 usually already have security specialists and sensitive assets, which is why the Safeguard expects enforcement rather than awareness alone.
The risk is straightforward. Scripting runtimes are built into most operating systems and developer toolchains, so an attacker who gains a foothold can often run code without dropping a compiled binary that antivirus or application controls would notice. A script that was never reviewed, or an approved script that was edited after review, can perform the same actions as an authorized tool. The control is hard for three reasons. Script runtimes are many and spread across endpoints, approved script versions change with every update, and you cannot allow or block scripts you have not inventoried first. That dependency is why Safeguards 2.1 and 4.1 are listed as prerequisites in the assessment specification.
For planning, start with three decisions. Name the runtimes in scope on each device class, decide who approves a script and how approval is tied to a specific version or signature, and decide how blocked execution is reported. Then ask your assessor, or your implementation partner, how the Safeguard will be measured, since the assessment specification scores it as failing when the Safeguard was last assessed more than six months ago. Confirm the exact enforcement and reporting approach in your own environment with your tool vendors, because the Safeguard does not prescribe a technology.
Which scripts, runtimes and teams fall inside the scope of 2.7
Safeguard 2.7 only works if the organization first decides which scripts count, where they run and who writes them. The cards below cover those decisions and the two prerequisites the assessment relies on, the software inventory (2.1) and the secure configuration process (4.1).
Script runtimes to include
Start by listing every interpreter that can execute scripts on in-scope assets. CIS gives PowerShell (.ps1) and Python (.py) as examples, but the list usually also includes shell scripts, JavaScript run by Windows Script Host, VBScript, Ruby, Perl and macro languages embedded in office or automation products. Record each runtime and the file extensions it uses, because a control that covers only .ps1 leaves other interpreters open. Confirm with the platform team which runtimes are installed by default on each operating system image.
Script-capable endpoints and servers
A device is script-capable when it has an interpreter installed or can fetch and run code. That includes laptops, workstations, virtual desktops, servers, containers built from general-purpose images and network appliances with a scripting shell. The assessment measures the share of script-capable authorized software that is properly configured, so an unclear population produces an unclear result. Use the software inventory from 2.1 to identify which hosts carry each runtime, and treat hosts missing from the inventory as unscoped until they are found.
Administrative and automation tooling
Configuration management, endpoint management, backup and patch tools often run scripts with elevated rights. Scripts stored in these systems, including remediation jobs pushed to fleets, belong in scope because they act on production assets. Ask each administrator team to name the tools that push scripts, the accounts that run them and the repositories that hold them. A script that is authorized by a ticket but launched by an automation platform still needs to appear on the allowlist.
Build and CI pipeline authors
Scripts written by developers and used in build, test and deployment pipelines often run with access to signing keys, package registries and production credentials. Decide whether build scripts sit inside the allowlist boundary or are governed under Control 16. Either way, document the decision, name the teams that may author pipeline scripts and confirm that changes pass through the same review path as application code.
Vendor and third-party scripts
Scripts shipped by vendors, installers, and scripts downloaded from community repositories still execute on your assets. Decide whether each one is authorized as a whole package or as individual files, and who signs off on updates. Ask vendors how they sign scripts and whether they publish a signing certificate. Scripts that a vendor updates silently are a common gap, so set a rule that a changed script must be re-authorized before it runs.
Prerequisites: inventory and configuration
The assessment lists the software inventory (2.1) and the secure configuration process (4.1) as prerequisites for measuring 2.7. Without a current inventory, the population of script-capable software is unknown, and without a documented configuration process, there is no agreed baseline against which a script is judged properly configured. Before scoping 2.7, confirm that 2.1 lists runtimes per asset and that 4.1 defines how enforcement settings are set, changed and reviewed.
How an assessor tests Safeguard 2.7 in practice
The assessor starts by fixing the population. Safeguard 2.7 is measured against the software that can run scripts on in-scope enterprise assets, so the first input is the software inventory produced under Safeguard 2.1, which shows which assets and tools exist. The assessment specification also expects the secure configuration process under Safeguard 4.1 to be in place, because the measured configuration depends on it. The assessor then asks which script types are in scope, such as PowerShell (.ps1) and Python (.py) files, and which interpreters and runtimes can execute them.
- Population definition: a list of script-capable authorized software per asset class, with the owner of each entry.
- Prerequisite data: the Safeguard 2.1 inventory and the Safeguard 4.1 configuration process documentation, both current.
- Interpreters: the shells, runtimes and script hosts that can launch scripts on each asset.
- Last assessment date: the date the Safeguard was last reviewed, which drives the six-month rule.
- Scope boundaries: which environments, such as production, build and administrative systems, are included.
Before testing, confirm that the inventory and the interpreter list match what is actually installed, because an incomplete population makes every later percentage unreliable.
The measure is the share of script-capable authorized software that is properly configured. An assessor takes a sample of that population and checks whether each item has a documented signing or version control requirement, whether the enforcement rule is set, and whether the configuration is applied on the endpoint rather than only written in a policy. Timeliness is a separate test: the Safeguard is scored as failing when its last assessment is more than six months old, so the organization must show a dated, repeatable review cycle and not a single past exercise.
- Configuration records: exported policy or rule settings showing which signed publishers, hashes or repository paths are permitted.
- Enforcement proof: logs or reports showing that unlisted scripts were blocked or flagged on sampled endpoints.
- Change history: version control records showing who approved each script and each change to the allowlist.
- Review records: dated assessment reports, with reviewer names and the findings each review raised.
- Endpoint results: compliance query output from a management tool that shows pass or fail per device.
Expect the assessor to pick devices from the inventory at random, so evidence must cover the whole population, not only the systems the team manages most closely.
Findings usually come from gaps between the documented allowlist and the running endpoint. Assessors often find that scripts are approved in a register but never enforced, that interpreters were left out of the population, or that exceptions were granted without an expiry date. Stale reviews are a frequent cause of failure, because the Safeguard is scored as failing once the last assessment is more than six months old, regardless of how well the controls worked earlier.
- Unenforced lists: an approved script register exists, but endpoints still run unsigned or unlisted scripts.
- Missing interpreters: a script host, such as a shell or runtime, is absent from the population and therefore untested.
- Open exceptions: temporary exemptions without an owner, a reason or a removal date.
- Stale reviews: the last documented assessment is older than six months.
- Unsigned changes: script updates pushed without the approval or version record the organization claims to require.
Before an assessment, ask the team to reproduce one sampled endpoint result end to end, from the approved list to the blocked-execution log, and confirm the dates match.
How to implement script allowlisting in six steps
This sequence moves an enterprise from an unknown set of scripts to a documented, signed or version-controlled set of approved scripts that the endpoints enforce and the team reassesses on a recurring basis. Each step produces a record an assessor can check against Safeguard 2.7.
Confirm the software inventory and configuration baseline
Before any script can be approved, the organization needs a current software inventory under Safeguard 2.1 and a documented secure configuration process under Safeguard 4.1, because the CIS Controls Assessment Specification lists both as prerequisites for measuring Safeguard 2.7. The security team and the IT operations owner check that the inventory covers the endpoints in scope and that the baseline describes how those endpoints are built and changed. Done means you can name the endpoints, their operating systems and the baseline each one must match.
List script-capable authorized software
Using the inventory, identify the authorized software that can execute scripts, such as PowerShell, Python runtimes, shells, configuration management agents and scripted administration tools. Record the platform, owner and the script types each product runs, and note which script files are maintained in-house versus supplied by a vendor. Your output is a reviewed list with an owner for every entry, which becomes the scope for the allowlist. Confirm the list with the application owners, since they know which scripts run in production.
Choose a signing or version-control method
Decide how approved scripts will be identified: code signing with certificates the organization controls, a version-controlled repository whose approved revisions are the only source the endpoints accept, or a combination. The CIS Controls Assessment Specification names code signing and version control as the kinds of methods the Safeguard contemplates, so document which one applies to each script type and who may approve a change. Protected branches in a platform such as GitLab Community Edition can restrict which roles push or merge to the approved branch and block direct pushes. Confirm the chosen method works with your endpoint platform before rollout.
Configure enforcement for unsigned or unapproved scripts
Configure endpoints to run only scripts that match the approved signatures or approved revisions, and block everything else, including scripts that are unsigned or present in no approved repository. Pilot the policy on a small device group, review the blocks, and add legitimate scripts to the approved set through the change process rather than by weakening the rule. Your output is an enforcement configuration, a pilot record showing which scripts were blocked and why, and a rollout decision signed off by the owner. Confirm with your endpoint vendor exactly which script types the enforcement mechanism covers.
Verify coverage with endpoint compliance checks
Use an endpoint compliance tool to confirm that each in-scope device runs the approved configuration and that no unapproved script runner is left unrestricted. Fleet policies, which are yes or no questions asked of devices as osquery queries, can show which devices pass or fail a given policy, and Wazuh Security Configuration Assessment can check files, directories, registry keys and running processes against YAML policies. The output is a dated compliance report per device group, which you retain as evidence. Treat any failing device as a remediation item with a named owner.
Schedule reassessment and record exceptions
Set a recurring reassessment of the allowlist and the configuration at least twice a year, which the Safeguard requires, and keep a register of exceptions for scripts that cannot be signed or versioned. Each exception should record the script, the business reason, the compensating control, the approver and an expiry review date. Your outputs are the reassessment calendar, the signed review minutes from each cycle, and the exception register. Ask your assessor early which exception format they expect, because the CIS Controls Assessment Specification treats a Safeguard last assessed more than six months ago as failing.
How code signing and version control make script approval verifiable
Approving a script is only half of Safeguard 2.7. The other half is showing that the script running on an endpoint is the exact version someone approved. Two mechanisms do most of that work. A digital signature ties a script to a named publisher and to a specific byte-for-byte version, so any edit after signing breaks verification. Version control does the other job: it records who proposed each change, who reviewed it and when it was merged. Together they answer two questions an assessor will ask: which script is this, and who said it could run.
Version control only proves approval if the repository enforces it. In GitLab Community Edition, protected branches let you restrict which roles can push or merge to the branch that feeds production, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Confirm in your own environment that the production branch is protected, that the roles allowed to merge are the ones your change process names, and that history cannot be rewritten to hide an earlier approval. Ask the team to show you a recent merged script change and its approval record.
The gap assessors look for is between approving a script once and proving it is the approved version on every endpoint. A signature check, a repository merge and a successful review do not by themselves show that a device still runs the approved copy. Plan for drift, such as a local edit, a stale copy left from an earlier release or a script pulled from an unmanaged location. The enforcement point (the operating system's signing policy, an endpoint control, or a configuration tool) and its reporting must be confirmed for your platforms. Treat the mechanism as a design decision to document, test on sample devices and reassess at least twice a year.
Evidence that shows scripts are allowlisted and kept current
An assessor testing Safeguard 2.7 wants to see one connected chain: which scripts are approved, how the approval is enforced on endpoints, what was blocked, and when the decision was last reviewed. The cards below cover each artifact in that chain and the routine that keeps it current between assessments.
Approved script list tied to inventory
This is the register of every script-capable file the organization has approved to run, with its owner, purpose, hash or signing identity, and the authorized software it belongs to. Because Safeguard 2.7 depends on Safeguards 2.1 and 4.1, each script entry should link back to a software inventory record. Check that every approved script still exists on the endpoints where it is listed, and that no script appears on the list without a matching inventory entry.
Signing and allowlisting policy configuration
Export the enforcement policy itself: which signing certificates or publishers are trusted, which file types such as .ps1 and .py are covered, and which execution paths are monitored. Keep the policy under version control so an assessor can see who changed it and when. Confirm with your enforcement vendor exactly which script interpreters the policy governs, because a policy that covers PowerShell but not a secondary Python runtime leaves a gap.
Enforcement logs of blocked executions
Blocked and audited execution events show that the control actually runs on endpoints, not only on paper. Retain them centrally with timestamp, host, user, script path and the rule that fired. Review blocks for patterns, such as a legitimate tool repeatedly blocked, that point to a missing approval or a real intrusion. Ask your enforcement tooling vendor how long logs are kept by default and whether they can be forwarded to your log platform.
Version-control records of approvals
Each approved script should enter the organization through a reviewed change in version control, with the approver recorded in the merge or review history. Protected branches let you restrict which roles can push or merge and block direct pushes, so changes to the approved set cannot bypass review. Export branch protection settings and the approval history for the repository that holds the approved scripts, and confirm that force pushes stay disabled.
Endpoint configuration compliance reports
Configuration checks show whether the endpoints running approved scripts are configured as the Safeguard 4.1 process requires, which is the second input the assessment specification expects. Use a benchmark scanner or a policy engine to report pass and fail results per device, and keep the reports dated. Wazuh Security Configuration Assessment and Fleet policies both produce per-endpoint results that can be exported for this purpose. Confirm which policies map to the script enforcement setup before relying on them as evidence.
Twice-yearly reassessment records and exceptions
Safeguard 2.7 must be reassessed at least twice a year, and the assessment specification fails the Safeguard when the last assessment is more than six months old. Keep signed reassessment records with the date, the scope, the reviewer, the changes made and any exceptions with their owner and expiry date. Put a calendar reminder at the six-month mark, not the twelve-month mark, so a missed review is visible before it becomes a failing result.
What meeting Safeguard 2.7 costs in money and effort
This table breaks down the money and effort behind Safeguard 2.7 by cost component, showing who is paid, which items are one-time or recurring, and what drives each one up or down. Use it to structure a written scope and to compare quotes line by line. The main takeaway is that the largest recurring cost is usually the upkeep of the approved script list and signing process, not the enforcement tool itself.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Enforcement tooling or licenses | Software vendor or open-source project; tooling may be self-hosted in your own environment | Recurring if commercial licenses apply; often no license fee for open-source components | Number of endpoints, script runtimes in scope, and whether you need central management or only reporting |
| Engineering time to build the approved script list | Internal staff or an implementation partner for fixed-scope work | One-time, with later updates | Number of scripts, languages and runtimes (for example PowerShell and Python), and how many owners must approve each script |
| Code signing and version control pipeline | Internal platform or DevOps team, possibly with a partner | One-time build, then recurring maintenance | Number of signing keys, certificate lifecycle needs, and whether signing runs in CI/CD or by hand |
| Ongoing configuration checks and monitoring | Internal security operations or a managed service provider | Recurring | Endpoint count and how many policies must be evaluated and reviewed on each cycle |
| Twice-yearly reassessment and evidence upkeep | Internal control owner; external reviewer if engaged | Recurring at least twice a year | Frequency of script changes, number of teams, and the quality of records kept per approved script |
| Release frequency overhead | Internal change management and developers | Recurring | How often scripts or automation change, and whether each change needs re-approval and re-signing |
| External review or independent testing | Independent assessor, consultant or testing firm | Periodic, scoped per engagement | Scope of script-capable systems sampled, and whether the review covers the approved list, signing and enforcement together |
| Auditor sampling | Independent auditor or assessor | Periodic, per audit cycle | Number of scripts and endpoints sampled, and how complete your approval and exception records are |
Who owns the control, who prepares evidence and who assesses it
Your organization owns Safeguard 2.7. The approved script list, signing authority, exception approvals and the decision to block a script are management decisions. A partner can build the mechanisms that enforce them, and an assessor can test them, but neither should make these decisions for you. Assign a named owner for the control and make sure that owner can explain each approved script and its purpose.
- Approved script list: Record each script, its business purpose, its owner and the version or hash it is allowed to run at. Remove scripts that no longer have an owner.
- Signing authority: Decide who may sign scripts, where signing keys are stored and how keys are rotated and revoked when staff change roles.
- Exceptions: Approve any script that runs outside the list only with a written reason, a compensating control and an expiry date.
- Reassessment: Schedule the reassessment at least twice a year, and record who reviewed the results and what was changed.
- Prerequisite data: Keep the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1) current, because the assessment specification relies on them.
Check that the control owner can produce the approved list, the latest reassessment record and every open exception within a single working session.
An implementation partner prepares the technical parts of the control inside your environment: the enforcement tooling, the signing and version control path, and the evidence exports your team and assessor will review. DeployOpen works this way under a fixed scope, with deliverables and timelines agreed in writing before work starts. The partner does not approve scripts, decide exceptions or sign off on the control's operating effectiveness.
- Endpoint reporting: Configure policy checks, for example with Wazuh Security Configuration Assessment or Fleet policies, so that script execution and configuration state can be shown per device.
- Signing and version control: Build the signing step and protected branches into the release path, so that direct pushes are blocked and changes to approved scripts are traceable.
- Code scanning: Add Semgrep scans to CI/CD pipelines for the languages in scope. Confirm coverage for PowerShell (.ps1) before relying on it, because the supported language list should be checked against your scripts.
- Evidence packages: Produce the script inventory export, policy results, signing logs, change records and a runbook that your owner reviews before handover.
- Prerequisite work: Confirm that the inventory and secure configuration inputs exist, or include them in the written scope.
Ask the partner for a written list of artifacts, the format of each one and the name of the person on your side who accepts each deliverable.
An independent auditor, assessor or certification body tests whether Safeguard 2.7 operates as described, and it is the only party that issues a report, attestation or certificate. The CIS Controls Assessment Specification gives the measures used for this Safeguard, including the rule that a Safeguard last assessed more than six months ago fails. Assessors compare your evidence against those measures and against their own sampling.
- Testing: Sample approved scripts, check that signatures or hashes match, review blocking events and confirm that unapproved scripts were stopped or documented as exceptions.
- Independence: The assessor should not have designed or built the controls it tests. Confirm conflict rules, and confirm whether a partner's work can be relied on as evidence before the engagement begins.
- Reporting: Only the assessor issues results. Internal summaries and partner documents support the assessment but do not replace it.
- Scope and sample: Agree the scope, the evidence window and the sample method with the assessor in writing before fieldwork starts.
Ask the assessor how it will treat evidence produced by an implementation partner, and what it needs from your team to complete the test.
Where organizations usually fall short on script allowlisting
Most script allowlisting programs fail on records rather than on technology: the script list is not tied to the software inventory, approvals and signing keys are informal, and enforcement stays in audit mode. Each card names one gap, why it matters for Safeguard 2.7, and the closure action an assessor would expect to see.
Script list not tied to inventory
Scripts are approved in a standalone spreadsheet that does not match the software inventory from Safeguard 2.1. A PowerShell module installed by a vendor agent may never appear on the approved list, so it either runs unchecked or gets blocked without anyone knowing why. Close the gap by giving each approved script a record that links to its inventory entry, owner and host group, then check that every script-capable endpoint maps to that list.
Approval by email only
A script is approved in an email thread, but nobody records which version was approved, who reviewed it, or which hash was allowed. When the file changes later, the approval still appears to cover it. Require approval through a tracked change, such as a merge request, where the reviewed version, reviewer and date are stored together so the approved content can be reproduced at audit time.
Informal signing key handling
Scripts are signed with a code signing certificate whose private key sits on a shared administrator workstation or in an unlabeled file. Anyone holding that key can produce a script the enforcement layer will trust. Store signing keys in a controlled key store, restrict signing to named roles, log every signing event, and document how a compromised key is revoked and replaced.
Enforcement left in audit mode
Script control is switched on in audit or report-only mode and never moved to blocking, so unapproved scripts run while logs show violations nobody reviews. This makes the Safeguard look implemented on paper while the Protect function does nothing. Set a dated plan to move each host group from audit to enforcement, and keep the audit logs as evidence of the transition.
No reassessment within six months
The last review of the approved script list is older than six months, so the assessment specification scores Safeguard 2.7 as failing regardless of how well the control works day to day. New scripts also accumulate without review. Put a recurring reassessment on the change calendar, record each completed review with its date and scope, and have a named owner confirm the cycle is on schedule.
Unrecorded exceptions
Teams run an unapproved script for an urgent fix, a vendor tool or a legacy job, and the exception lives only in a ticket or in someone's memory. Assessors look for the reason, the compensating control, the approver and the expiry date. Record each exception in a register with those fields, review it at the same cadence as the allowlist, and retire it when the script is either approved or removed.
Questions buyers ask about Safeguard 2.7 cost, time and scope
How much effort does Safeguard 2.7 script allowlisting take?
The effort depends mostly on how many script-capable systems and script types are in scope, and on whether the software inventory and secure configuration process already exist. Safeguard 2.7 is an IG3 Safeguard, so the work sits on top of Safeguards 2.1 and 4.1, which the CIS Controls Assessment Specification lists as prerequisites because they typically produce the data the measurement needs. Effort typically splits into three parts: defining which scripts are authorized and who approves them, enforcing signing or version control so only approved scripts run, and keeping the list current through reassessment. Ask any provider to break its quote into those three parts, and to state which systems, operating systems and script languages each part covers. A quote that does not name the in-scope systems cannot be compared with another.
How long does it take to reach a first assessable state?
There is no fixed duration, because the timeline depends on the starting point. A team with a current software inventory, documented configuration baselines and a code signing or version control practice has less to build than a team starting from scattered scripts on unmanaged endpoints. The main drivers are the number of script sources (administration scripts, deployment pipelines, application code, and third-party tooling), the number of signing or approval workflows that must be introduced, and how much testing is needed before blocking execution does not disrupt operations. Because the assessment specification scores the Safeguard as failing if it was last assessed more than six months earlier, a first assessment should be planned with the reassessment cycle in mind. Ask for a written milestone plan that shows when the authorized script list, enforcement and first review are complete.
Can our own team implement Safeguard 2.7 without outside help?
Yes, many teams do this in-house, provided they have the skills and capacity to own it. The work needs people who understand endpoint configuration, source control and change approval, and who can write and maintain the rules that decide which scripts run. An internal team should first confirm that its software inventory and secure configuration process are mature enough to support Safeguard 2.7. Outside help is usually considered when the team lacks those skills, when many platforms must be covered at once, or when it wants an independent review before an assessment. Where a partner is used, the organization still owns its controls and approves its own authorized list. An implementation partner such as DeployOpen can prepare systems and evidence, but only an independent assessor or auditor issues reports or certificates.
What does the work need from our staff?
Safeguard 2.7 needs ongoing participation from more than one group, not only the security team. Administrators and developers must agree on which scripts are authorized and how changes are requested and approved. Operations staff must be able to run signed or version-controlled scripts without getting stuck in approval queues. Someone must own the authorized list, review exceptions and record decisions. Typical roles include:
- A named owner for the authorized script list and its approval workflow
- Endpoint or platform engineers who enforce execution rules and check results
- Developers and DevOps staff who keep scripts in version control with protected branches
- Security staff who review failing endpoints and document exceptions
Ask each provider which of these roles it expects you to fill, and which it will take on.
Can an auditor test Safeguard 2.7 before reassessment is due?
Yes. An independent assessor can test the Safeguard at any point, and the most useful test is one run before the reassessment window closes. The CIS Controls Assessment Specification scores Safeguard 2.7 as failing when it was last assessed more than six months ago, so an organization should schedule an internal assessment against the specification and keep its results as dated evidence. That evidence should show the authorized script list, its approval records, the enforcement configuration, and the share of script-capable systems that are properly configured. Tools such as Fleet policies, which ask yes or no questions of devices, can show which endpoints pass or fail a given check. DeployOpen prepares systems and evidence for assessment, but only an independent assessor or auditor issues any report or conclusion.
What recurring work comes after the first implementation?
The recurring work is the reassessment cycle, the upkeep of the authorized list and the handling of exceptions. Because the Safeguard must be reassessed at least twice a year, the organization must schedule those reviews, refresh the list when scripts or teams change, and check that enforcement still covers new systems. Costs recur in staff time and, if an outside partner is used, in a retainer for ongoing support, upgrades or testing. Ask whether a quote covers one assessment cycle or ongoing operation, and what happens when new script languages or platforms are added.
How DeployOpen scopes and prepares evidence for Safeguard 2.7
DeployOpen scopes Safeguard 2.7 in writing before any work starts. The scope names which endpoints, servers and script-capable runtimes fall inside the allowlist, which script types (for example .ps1 and .py files) are governed, who approves additions, and how signing keys and the authorized script register are owned. The organization keeps ownership of its controls and its risk decisions. DeployOpen's role is to prepare the systems and the evidence that show those controls operate, and the scope document is where the organization and DeployOpen agree on that split. Most engagements of this kind are fixed-scope, so deliverables and timelines are settled in that document, and a quote follows from the written scope rather than from a standard price list.
DeployOpen then implements and hardens the open-source tooling inside the client's own cloud accounts, data centers or air-gapped networks. Work usually covers the script register that Safeguard 2.1 and 4.1 produce, endpoint policies that check for approved script hashes or signatures, and version control rules that stop unreviewed changes to approved scripts from reaching production. Each piece is documented with its configuration, owner and review cadence so that the reassessment at least twice a year can be repeated by the client's own staff. Ongoing support, upgrades and continuous testing can be added as a retainer if the client wants help keeping those checks running between assessments.
DeployOpen does not issue audit reports, attestations or certifications. Only an independent assessor or certification body can state whether Safeguard 2.7 is met under the CIS Controls Assessment Specification. Before engaging anyone, confirm with the assessor which evidence they will sample, such as exported allowlist records, policy results showing passing and failing devices, and change approvals for signed scripts. Ask any implementation partner to name those artifacts in the written scope so that the evidence is built for the assessment, not reconstructed afterward.
