What Safeguard 7.3 automated OS patch management asks for
Safeguard 7.3 asks that operating system updates on your enterprise assets are applied through automated patch management at least monthly. In practice, you need a patching tool or service that pushes OS updates on a schedule without someone starting each run by hand, and you need proof that it ran and reached the devices it was meant to reach. The Safeguard sits in the Protect security function and belongs to Implementation Group 1, so CIS treats it as baseline hygiene for every enterprise, not an advanced practice reserved for mature programs.
The risk is simple to state: an operating system with known, published vulnerabilities stays exploitable for as long as it stays unpatched, and attackers routinely target exactly those gaps. Assessors will therefore look for two things at once, that the updates are automated and that they actually land. The hard part is usually not choosing a tool but knowing what to patch. Inventory gaps (Safeguard 1.1 for hardware and Safeguard 2.1 for software) mean devices outside the patch scope go unnoticed. Reboot windows, laptops that are rarely online, servers that cannot restart during business hours, and a mix of Windows, Linux and older builds all push patch cycles past a month for some assets.
Before you commit to a patch design, confirm three things with your team: which asset classes the monthly cadence must cover, which groups need staged or maintenance-window deployments, and which exceptions require documented risk acceptance. Ask your patching vendor or open-source platform owner to show how it reports devices that missed a cycle, since the measures in the assessment specification depend on that data. Start with the CIS Controls Assessment Specification for Safeguard 7.3 to see which prerequisite data you must have before your metrics mean anything.
Which enterprise assets and teams fall under automated OS patch management
Safeguard 7.3 applies to enterprise assets, which is a wider set than servers in a data center. The scope decisions below determine who must be in the patch cycle, who owns the tooling, and which systems need contractual evidence instead of direct patching.
Asset classes in scope
Safeguard 7.3 sits in the Software asset class, but the operating systems it covers run on Devices, cloud instances and virtual machines alike. Start from the asset inventory required by Safeguard 1.1, which is a listed prerequisite for measuring 7.3, and confirm that workstations, servers, cloud instances, virtual machines and network-attached devices each appear in it. A system missing from the inventory will be missing from patch metrics too, and an assessor will check that the denominator is complete.
Operating system families
Each operating system family, such as Windows, Linux distributions, macOS and hypervisor hosts, needs its own update mechanism, cadence and reporting source. Record the family and version for every asset in the software inventory from Safeguard 2.1, which is also a listed prerequisite. Confirm that each family has an automated path that reaches at least monthly updates, and flag any end-of-support version where vendor updates have stopped, because automation cannot fix those assets.
Unmanaged and shadow systems
Systems that no team registered, such as test servers stood up outside change control or laptops enrolled in no management platform, are the most common gap in automated patching. Use passive and active discovery results to find assets that the patch tooling does not report on. Treat every unmanaged system as out of compliance until it is either enrolled in automated patching or formally removed, and ask who receives alerts when a new asset appears without an agent.
Teams that own the tooling
A platform or endpoint team typically owns the patch management server, agents, deployment rings and reporting. This team sets the monthly cycle and must show that the tooling reaches each in-scope asset. Document who approves exceptions, who can pause a deployment and who reviews the coverage report, because an assessor will ask who is accountable for the automation rather than who performed a single update.
Teams that own the workloads
Application owners, database administrators and business units often hold the maintenance windows and the authority to accept downtime. Their agreement is needed before a server reboot or a kernel update can happen. Write the responsibility split into the patch process so that a delayed update has a named owner, a recorded reason and an agreed date rather than an open-ended deferral that weakens update effectiveness.
Third-party managed systems
Systems run by a managed service provider, a cloud provider's managed service or a hosting partner may not be patchable directly by your team. For these, you need contractual evidence that the provider applies OS updates at least monthly, plus periodic reports you can review. Confirm the provider's update cadence, reporting format and notification terms in the contract. Safeguard 15 covers how to assess these providers, and the contract should state what evidence you will receive.
Why the asset and software inventories come first
The CIS Controls Assessment Specification lists Safeguard 1.1 (the enterprise asset inventory), Safeguard 2.1 (the software inventory) and Safeguard 4.1 (the secure configuration process) as prerequisites for measuring Safeguard 7.3. The reason is practical: the measures for automated operating system patching are calculated against a population of assets, and that population has to come from somewhere. The asset inventory defines which devices are in scope, the software inventory records which operating systems and versions each device runs and whether they are still supported, and the secure configuration process defines the baseline a patched system is expected to match. Without these three inputs, the update effectiveness and coverage figures have no denominator the assessor can trust. An incomplete inventory breaks the measurement at its foundation. An assessor testing coverage will select a sample of assets from the inventory and check their patch status, and will also ask whether the inventory is complete. If a server, virtual machine, cloud instance or network appliance is missing from the list, nobody can show that it was patched monthly, so the automation coverage metric cannot be confirmed for it, and the organization-level effectiveness figure is overstated by omission. Assets that are discovered on the network but absent from the inventory are a common finding for this reason. Ask your team to reconcile the asset inventory against cloud account listings, hypervisor records and network discovery output before the first assessment, and record how often that reconciliation runs. The same logic applies to the software inventory. A patch tool can report that a host is fully updated while the operating system on it has reached end of support, or while an application on it sits outside the patch scope. Before you rely on scan or patch dashboards as evidence, confirm with your assessor which asset and software records they will use as the authoritative population, and make sure your patch management tool draws its scope from those same records so the numbers in the dashboard and the inventory agree.
How an assessor tests automated OS patch management
This table maps the four metrics the CIS Controls Assessment Specification combines for Safeguard 7.3, showing how an assessor tests each one, what evidence to prepare and where organizations usually fall short. Read each row as a test an assessor will run against your asset data, not as a checklist to satisfy once.
| Metric | How the assessor tests it | Evidence requested | Common findings |
|---|---|---|---|
| Update effectiveness (per asset) | Samples enterprise assets and checks whether operating system updates were applied within the monthly window and whether the asset reports as current at the time of testing | Per-asset patch status reports from the patch tool, with install dates and the asset identifier matching the asset inventory from Safeguard 1.1 | Systems show as patched but are still running the old kernel or library because the reboot never happened |
| Update effectiveness (organizational) | Calculates the share of in-scope assets that were updated across the period and compares the result against the organization's own documented target | Period reports covering several months, the documented target, and the calculation method used to produce the figure | Totals look healthy because decommissioned or unreachable assets were removed from the denominator without a record |
| Coverage of automation | Determines which assets receive updates through automated patch management and which are handled by hand, then checks that the automated share matches what the organization claims | Patch tool enrollment list reconciled against the software and asset inventories, plus the configuration of each update policy | Unmanaged network segments, lab systems or appliances sit outside the patch tool with no owner and no manual process |
| Scan compliance | Runs or reviews an independent vulnerability scan and compares missing operating system updates found by the scan with the patch records | Scanner output dated within the assessment period, with the scan scope and credentials used, and the matching patch records | Patch records say a system is current while the scanner still reports missing operating system fixes |
| Monthly manual exceptions | Reviews every asset excluded from automation or delayed past the monthly cycle and checks for an approved reason, a compensating control and an end date | Exception register with approvals, risk acceptance records, and evidence that each manual update was carried out | Exceptions accumulate, have no expiry, and were approved by the same person who runs the patching |
| Reboot and restart verification | Confirms that updates requiring a restart were followed by a restart or by a recorded deferral, since an unapplied kernel fix is not effective | Pending-reboot reports, uptime data or agent telemetry, and records of deferred restarts | Patch tool marks updates as installed while the running system still uses the vulnerable component |
Implementing automated OS patching in sequence
This sequence takes Safeguard 7.3 from an informal patching habit to a documented, automated monthly process that the organization can measure. Each step produces an artifact an assessor can inspect, and the order keeps the prerequisite inventories ahead of the automation that depends on them.
Confirm the asset and software inventories
Before any patch job runs, the organization confirms that its enterprise asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) are current. The CIS Controls Assessment Specification treats these as prerequisites for measuring Safeguard 7.3, because the coverage and effectiveness measures need a reliable list of which operating systems exist on which assets. The asset owner signs off on the reconciled list, including cloud instances and ephemeral hosts. This step is done when every in-scope operating system can be traced to a named asset and an owner, and the inventory exports can be used as the denominator for coverage reporting.
Define the monthly cadence and maintenance windows
The team writes down the patching cadence required by Safeguard 7.3, which is at least monthly, and sets maintenance windows per asset class and business unit. Owners of production, hosted and industrial systems agree on windows and on the rules for emergency out-of-cycle updates. Security, operations and the change advisory function approve the document. The output is an approved patch cadence and maintenance window standard that names the accountable owner for each asset group. Confirm with the change board whether your change policy needs separate approval for each monthly cycle.
Select and configure patch tooling per OS family
Choose an automated patch mechanism for each operating system family in use, such as the native update service for each platform, a configuration management tool, or an open-source patch orchestration tool. Configure update sources, approval rules, reboot behavior and credentials in version-controlled configuration. Each OS family needs its own test, since the update mechanisms differ. Ask the vendor or project to confirm which update channels, reboot controls and reporting interfaces each tool supports in your environment before you commit to it. Done means the configuration is documented, reviewed and reproducible on a test host.
Pilot on a small representative group
Run the configured automation against a small group of non-critical assets that cover each OS family, each major application stack and each network segment. The pilot checks whether updates install, whether services restart as expected, and whether the tooling reports status back to the central system. Record failures, rollback steps and any packages that break applications. The pilot is complete when the team has a written list of issues, fixes or accepted risks, and the operations lead signs off on moving to production groups.
Roll out in waves across enterprise assets
Expand the automated patching to the remaining enterprise assets in waves, starting with lower-risk groups and ending with high-impact systems. Each wave follows the approved maintenance windows and has a named owner who can halt the wave if updates cause service impact. Track which assets complete each cycle and which fail. The output of this step is a first complete monthly cycle across the in-scope estate, with the failed and deferred assets listed for follow-up.
Set exception handling for systems that cannot be updated
Some assets cannot take an update within the cycle because of vendor support limits, validated application dependencies or operational constraints. Create a formal exception process that records the asset, the reason, the compensating controls, an accountable approver and a review date. Exceptions should be time-limited and reviewed at the same cadence as the patch process. The output is an exception register that the assessor can read alongside the coverage reports, so every asset that is not automatically updated has a documented, approved reason.
Build reporting for the four metrics
Build dashboards or scheduled reports for the four metric groups in the assessment specification: update effectiveness per asset, update effectiveness across the organization, coverage of automation, and scan compliance. Pull data from the patch tooling and the asset inventory, and reconcile the two each cycle. Confirm with your assessor how each measure is calculated before you publish results. The output is a monthly coverage and compliance report, retained as evidence, with exceptions and trends explained for management.
Evidence that shows OS updates are automated every month
Assessors look for a chain of records that connects a written patch policy to what happened on each enterprise asset. The cards below cover the documents, exports and logs that link the monthly cadence to actual patch state, and the routine that keeps each one current between audits.
Patch policy and cadence record
The written patch policy states that operating system updates are applied through automated patch management at least monthly, names the owner of each asset class, and sets the maximum window for deploying critical updates. Keep a dated approval history with it, so the assessor can see the monthly cadence was in force for the whole period under review. Check that the policy matches what the tool is actually configured to do, because a mismatch is a common finding.
Tool configuration exports
Export the patch management tool's schedules, deployment rings, maintenance windows and update categories as files your team can version. These exports show the automation exists and covers the operating systems in scope, not just that a person intended to run updates. Store each export with a timestamp so changes to schedules can be traced to a change ticket.
Patch compliance reports by asset
A per-asset report lists each enterprise asset, its operating system version, the last successful update cycle and any missing updates. The asset list should match the enterprise asset inventory from Safeguard 1.1, so gaps in coverage are visible. Ask whether the report can be filtered by asset class and exported on a schedule.
Dated deployment logs
Deployment logs record when each update was pushed, to which group, and whether it succeeded, failed or was deferred. Retain them for the audit period and confirm they include timestamps from synchronized clocks, so an assessor can match a log entry to a monthly cycle. Logs that show only the final state, without the attempt history, rarely support the automation claim.
Exception register with approvals
Some assets cannot take an update on the normal cycle, such as a legacy system awaiting a vendor fix or a production host in a freeze. Record each exception with the asset, the reason, a compensating measure, an approver and an expiry date. An exception without an approver or an end date signals that the monthly requirement is not being met.
Reboot and verification records
An update that needs a restart is not complete until the asset has rebooted and the new version is confirmed running. Keep records of reboot completion and post-update version checks, and track assets that stay pending a restart beyond the agreed window. Scan results that re-check patch state after the cycle close the loop and show the update took effect.
What automated OS patch management costs to meet
This table lists the cost components of meeting Safeguard 7.3, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where self-hosted open-source tooling removes license spend but not engineering effort. No dollar figures or durations are given because none are supplied for this Safeguard.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Patch tooling licenses | Software vendor, if a commercial patch manager is chosen | Recurring, usually per asset or per seat | Fleet size and number of OS platforms supported. Self-hosted open-source tooling can remove this line but not the effort below. |
| Platform build and hosting | Internal platform team or implementation partner, plus the cloud or data center provider | One-time build, then recurring hosting | Whether the patch service runs in the client's own cloud account, data center or air-gapped network, and how many update repositories must be mirrored. |
| Engineering to configure and pilot | Internal engineers or an implementation partner under a fixed-scope agreement | One-time, with later changes | OS diversity, the depth of existing asset and software inventory from Safeguards 1.1 and 2.1, and how many pilot rings are used before broad rollout. |
| Maintenance window coordination | Internal change management, service owners and operations staff | Recurring, at each monthly cycle | Number of business-critical systems, availability commitments and how many systems need manual reboot coordination. |
| Exception handling and risk acceptance | Security, system owners and approvers | Recurring | Number of assets that cannot be patched on schedule, such as legacy or vendor-locked systems, and the rigor of the approval process for each exception. |
| Evidence upkeep for the CAS measures | Security operations or compliance staff, with tooling output exported as records | Recurring, monthly | Number of measures the organization tracks across the 4 metrics, how much reporting is automated, and how easily asset identifiers match across tools. |
| External review or testing | Independent assessor or a testing firm, if commissioned | Recurring, per review cycle | Scope of the review, whether patch status is checked against independent scan results, and how many systems are sampled. |
| Auditor sampling time | Independent auditor or certification body, paid by the organization | Recurring, per audit cycle | Number of populations the auditor samples, how complete the patch records are, and how quickly evidence can be produced on request. |
Where organizations fall short on OS patching and how to close each gap
Most failures against Safeguard 7.3 are not failures to install updates. They are gaps in what the patch process can see, what it finishes, and what it can prove. The cards below cover five gaps that tend to surface during assessment, with the closing action and the evidence that shows the gap is closed.
Incomplete inventory leaves assets unpatched
A patch job can only update systems it knows about. Assets missing from the enterprise asset inventory, which Safeguard 1.1 covers and which the assessment specification treats as a prerequisite for measuring Safeguard 7.3, never enter the patch scope. Reconcile the patch tool's managed host list against the asset inventory each cycle, and investigate any asset that appears in one list but not the other. The evidence is the reconciliation report with the unmanaged assets listed and their disposition recorded.
Updates installed but reboots never performed
Many operating system updates only take effect after a restart, so a host can report the patch as installed while still running the vulnerable code. Track pending reboots as a separate state, set a maximum time a host may wait for a restart after an update, and feed reboot status into the compliance dashboard. Check whether the patch tool reports a pending-reboot state, and confirm it before relying on it. The evidence is the per-asset effectiveness record showing the update and the completed restart.
No documented exception process
Some hosts cannot be patched on schedule because of vendor certification limits, legacy application dependencies or change freezes. Without a written exception process, these hosts either silently fall out of the metrics or block the whole cycle. Require each exception to name the asset, the reason, a compensating control, an approver and an expiry date, and report open exceptions with the monthly results. The evidence is the exception register and the approval records behind it.
Cloud images and containers patched differently from hosts
Virtual machines, container base images and managed instances are often updated through separate pipelines, so a host patch report can look complete while images in the registry or autoscaling groups still carry old packages. Treat golden images and base images as assets in scope, rebuild them on the same monthly cadence, and confirm that running instances are replaced from the patched image. Software inventory from Safeguard 2.1 helps identify which images contain which packages. The evidence is the image build history and the deployment records showing the patched image in service.
Evidence assembled by hand at audit time
When patch results live in screenshots, spreadsheets and ticket comments, teams spend the audit period rebuilding history instead of reviewing it. Export patch compliance, coverage and scan results on a fixed schedule, store them with timestamps and the asset inventory version used, and keep the exception register alongside them. Confirm with your assessor which artifacts they expect for each measure before the review period starts. The evidence is a monthly package that can be reproduced from the source systems without manual edits.
Who does what: your team, an implementation partner and the auditor
Your organization owns Safeguard 7.3. The obligation to perform automated operating system updates on enterprise assets at least monthly sits with you, and so do the decisions that make the control work: which asset classes are in scope, how often patches are actually deployed, who approves a deferral, and how exceptions expire. Your team also owns the records that show the control operating over time, because an assessor will test a sample of periods rather than a single snapshot.
- Cadence and scope: Set the monthly patch window, the scope of enterprise assets and the owner of each asset group.
- Exception approvals: Approve, time-limit and review any deferral, with a named risk owner and a documented reason.
- Operating evidence: Keep patch deployment records, compliance reports and ticket trails for each cycle.
- Prerequisite inventories: Maintain the asset inventory (Safeguard 1.1), software inventory (Safeguard 2.1) and secure configuration process (Safeguard 4.1) that the measurement depends on.
- Remediation follow-up: Track failed or missed updates to closure under the remediation process.
Before engaging anyone, confirm internally who signs off the monthly cycle and where the evidence will be stored for the assessment period.
An implementation partner such as DeployOpen can help you build the machinery behind Safeguard 7.3 inside your own infrastructure. The partner designs the patch architecture, configures and hardens the patch tooling, builds the reporting that feeds the CIS Controls Assessment Specification measures, and prepares evidence packs for the assessor. The partner works on your systems and under your authority, and it does not decide what your policy says or whether a control passes.
- Patch architecture: Design the update sources, staging rings, maintenance windows and rollback paths for each platform in scope.
- Tooling configuration: Deploy and harden the open-source patch management and configuration tooling in your accounts, data centers or air-gapped networks.
- Reporting: Build dashboards and exports that calculate update effectiveness, automation coverage and scan compliance from your data.
- Evidence preparation: Assemble evidence packs mapped to the measures so your team and the assessor can trace each claim to a record.
- Documentation and handover: Write runbooks and train your staff so the control keeps running after the engagement ends.
In a fixed-scope engagement, ask the partner to list each deliverable and state in writing that it does not issue assessment results or certificates.
An independent auditor, assessor or certification body tests whether Safeguard 7.3 is implemented and reports the outcome. Only that party can issue a report, attestation or certificate. Independence means the assessor is not the designer, operator or reporter of the controls it tests, so its conclusion carries weight with customers, regulators and contract counterparties. Where the assessor and the implementer are the same firm, the conclusion is open to challenge.
- Testing the control: Sample monthly cycles, inspect patch records, re-perform compliance checks and compare asset lists to inventories.
- Evaluating exceptions: Check that deferrals were approved, time-limited and reviewed.
- Issuing the result: Only the independent party issues the report or certificate and states its scope and period.
- Setting boundaries: A partner that built the reporting cannot also attest to the result, because it would be testing its own work.
- Reliance on partner evidence: Assessors may review the partner's documentation as input, but they form their own conclusion from the evidence.
Before selecting an assessor, confirm its accreditation for the framework you are being assessed against and whether it has any conflict with the partner you hire.
How much effort, time and outside help automated OS patching takes
How much in-house effort does automated OS patching take to set up?
The effort depends mainly on how many enterprise assets are in scope and how far the asset and software inventories already reflect reality. Safeguard 7.3 is measured through data that usually comes from Safeguards 1.1 (enterprise asset inventory), 2.1 (software inventory) and 4.1 (secure configuration process), so an organization with incomplete inventories will spend most of its early effort reconciling them before any patch tooling is useful. Setup work typically covers selecting the patch tool, defining maintenance windows, building a test or staging ring, and wiring patch status into reporting. The Assessment Specification lists 10 measures combined into 4 metrics for this Safeguard, so confirm with your assessor which of those measures your reporting must produce before estimating the work.
What does the client's team need to provide for an OS patching project?
The client team owns the policy, the asset inventory, the patch approval decisions and the exceptions. In practice, the team needs named owners for each operating system family, access to the asset inventory and configuration management data, change approval rules that allow scheduled automated updates, and someone who can decide when a failed update is an acceptable exception and who signs it off. Platform or infrastructure staff also need to confirm which systems cannot restart during business hours, which systems are fragile, and which vendor support matrices apply. Ask the implementation partner to list these inputs in writing so the work is not blocked later by a missing approval or an unknown owner.
Is it worth bringing in an outside partner for automated OS patching?
A partner is worth considering when the internal team lacks the time or experience to build patch automation across mixed estates, or when the organization must show evidence quickly for an assessment. The partner can prepare the tooling, the reporting and the evidence trail, but the organization keeps ownership of its controls and its patch decisions. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports or certifications; an independent auditor or assessor reviews the evidence.
How long does it take to show monthly OS patch coverage?
The time to show monthly coverage is driven by a few factors rather than a fixed period: the state of the asset and software inventories, how many distinct operating system versions are in use, whether patching is already automated on some estates, the number of maintenance windows that must be negotiated, and how many systems need staged or manual handling. Organizations with mature inventories and a single platform usually reach reporting sooner than those with legacy systems. Ask any partner to tie the timeline to named milestones in the written scope, and confirm the first full monthly cycle your assessor will accept as evidence.
Can self-hosted open-source tools produce the evidence for Safeguard 7.3?
Self-hosted open-source tools can produce much of the evidence, provided they record what was updated, when, on which asset, and with what result. The evidence an assessor typically asks for includes patch job logs, compliance reports showing the share of assets updated within the monthly cycle, exception records with approvals, and the inventory data that proves coverage. Which specific tools meet each measure in the Assessment Specification must be confirmed against the tool's documented capabilities and tested in your environment, because no tool guarantees a particular measure. Running the tooling inside your own cloud accounts, data center or air-gapped network keeps the evidence under your control.
What should a written quote for automated OS patching include?
A useful quote states the scope in writing before any work begins. Ask for the list of in-scope asset classes and operating system families, the Safeguards and measures the work targets (including the prerequisites from Safeguards 1.1, 2.1 and 4.1), the tooling to be deployed or customized, the integration points with existing change and inventory systems, the evidence deliverables and their format, the testing and rollback approach, and the handover of documentation. Also ask what is one-time setup and what recurs, such as retained support, upgrades or continuous monitoring, and who pays for licenses on any third-party tooling. Confirm acceptance criteria and how exceptions are handled, since these shape the final effort.
How DeployOpen scopes and prepares evidence for Safeguard 7.3
This sequence turns the Safeguard 7.3 requirement into a written scope, a working patch pipeline and an evidence set that an independent assessor can review. DeployOpen prepares the systems and records, while the organization keeps ownership of its controls.
Confirm the organization owns the control
The organization names an accountable owner for operating system patching and decides which teams run the patch process. DeployOpen confirms this ownership in writing before work starts, because the organization owns its controls and any assessor will ask who is accountable. The step closes when the owner, the approving role and the in-scope teams are recorded in the engagement scope document.
Define the asset scope from the inventory
DeployOpen reviews the enterprise asset inventory, the output of Safeguard 1.1, to establish which operating systems and enterprise assets fall under Safeguard 7.3. It also checks the software inventory from Safeguard 2.1 and the secure configuration process from Safeguard 4.1, since the CIS assessment specification lists these as prerequisites. The step closes with a scoped asset list that shows each device, its operating system and its patch source, reviewed by the client.
Document the patching process and cadence
DeployOpen drafts the written procedure for automated operating system updates, covering the monthly minimum in Safeguard 7.3, update sources, approval steps, maintenance windows and exception handling. The client reviews and approves the document, and it is version controlled with an owner and review date. The step closes when the approved procedure is published to the teams that run patching.
Implement automated patch deployment
DeployOpen configures patch management tooling inside the client's own infrastructure, using the platforms the organization has selected, and sets schedules that meet the at least monthly update requirement. It tests deployment on representative assets before broad rollout and records failed and deferred updates. The step closes when a pilot cycle completes and the results are reviewed with the client.
Build the measurement and reporting outputs
DeployOpen sets up reports that map to the CIS assessment specification measures for Safeguard 7.3, including update effectiveness per asset and across the organization, automation coverage and scan compliance. It confirms which data sources feed each measure and documents how each figure is calculated. The step closes when a sample report is generated from live data and checked against the definitions.
Assemble the evidence set for assessment
DeployOpen collects the artifacts an assessor will ask for, such as the approved procedure, inventory extracts, deployment logs, exception records and metric reports for a defined period. It arranges them by Safeguard so the organization can show operation over time, not a single snapshot. The step closes when the evidence index is reviewed by the client, with gaps listed and owners assigned.
Hand over and agree ongoing support
DeployOpen delivers the documentation, configuration records and handover session to the client's operations team, and confirms what remains the organization's responsibility. The client can then choose to continue patch support under a retainer, which is optional and covers ongoing updates and reporting. The engagement closes with written acceptance of the deliverables. An independent auditor or certification body is responsible for any formal assessment or report.
