What Safeguard 7.5 asks for and why organizations struggle with it
If you are an IG2 or IG3 organization preparing for an assessment or a customer questionnaire, Safeguard 7.5 requires automated vulnerability scans of your internal enterprise assets at least quarterly, and those scans must run both authenticated and unauthenticated. The Safeguard sits in the Software asset class and the Identify security function in CIS Controls v8.1, and it applies to Implementation Groups 2 and 3 only, not IG1. CIS publishes the Controls and the assessment specification but does not issue certifications or attestations, so the proof you present will come from your own records, and any formal report will come from an independent assessor you engage. The risk addressed is simple to state: a flaw you do not know about on an internal laptop, server, hypervisor or network device is a flaw an attacker who lands inside your network can use to move laterally. Unauthenticated scans reveal what a host exposes to the network, such as open services and banners. Authenticated scans log in to the asset and read the installed packages, patch levels and configuration, which is where most missing updates actually show up. Authenticated scanning is the harder half because it needs credentials for every asset class in scope, including Linux hosts, Windows endpoints, network appliances and databases, and each credential must be stored, rotated and scoped with the same discipline as any privileged account. Before you commit to a scanner, confirm three things with your own environment. First, check that your enterprise asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) are current, because the assessment specification treats them as prerequisites for measuring 7.5. Second, check whether your secure configuration process (Safeguard 4.1) defines the baseline the scans compare against. Third, decide which asset groups will get authenticated access and who approves that access. Those answers determine the scope, the credential model and the evidence you will need in the assessment.
Which internal assets and teams fall inside the 7.5 scope
Safeguard 7.5 is measured against the internal enterprise assets you declare in scope, so the scope decisions below set the size of the scanning program. Each card covers one decision that an assessor will ask you to justify and that the scan configuration must reflect.
Asset classes that count as internal
Safeguard 7.5 applies to internal enterprise assets, and CIS assigns each Safeguard an asset class. Start from the Devices, Software and Network classes, which hold the endpoints, servers, applications and network equipment a scanner can reach, then decide whether Data and Users assets need separate treatment. Check that your asset inventory from Safeguard 1.1 and software inventory from Safeguard 2.1 match this boundary, because the measurement relies on that data.
Cloud workloads inside the boundary
Virtual machines, containers and managed instances that sit in your cloud accounts are internal enterprise assets when your organization operates them. Confirm that scanner network paths, cloud security groups and account permissions allow internal scans of these workloads, and record which accounts are in scope. Assets that a provider operates and you cannot scan usually need to be documented as an exception with a compensating review.
Segmented networks and scanner placement
Scans cannot see hosts behind firewall rules that block the scanner. Place scanners in each segment that holds in-scope assets, or document which segments are reached through an approved path. For example, a scanner in a general office zone may reach no hosts in a restricted production zone, which leaves those assets with coverage gaps that the coverage metric will show.
Credentialed accounts for authenticated scans
Authenticated scans need a dedicated scanning account on each in-scope system, with read access sufficient to query installed packages and configuration. Define who approves that account, where its credentials are stored, how often they rotate and how the account is removed when a host is retired. Unmanaged scanning accounts become their own privileged access risk, so bring them under your account management process.
Teams that own scan configuration
Assign one owner for scan policies, targets, schedules and credentials, usually the vulnerability management or security operations team, and name separate approvers for changes to the target list. Platform or infrastructure teams typically supply target data and approve credentialed access. Write these responsibilities into the vulnerability management process from Safeguard 7.1 so that an assessor can trace each scan setting to an accountable role.
Exceptions and their approval
Some assets cannot be scanned safely, such as fragile industrial controllers or systems with vendor restrictions. Record each exception with the reason, the compensating measure, the approver and a review date. Ask whether your exception rules will be accepted by your assessor, and confirm with them how excluded assets affect the coverage and compliance metrics before the scope is final.
How an assessor tests the scan coverage and compliance metrics
An assessor testing Safeguard 7.5 starts with the denominator, not with the scan reports. The CIS Controls Assessment Specification defines 11 measures for this Safeguard, combined into 4 metrics: coverage of vulnerability scans, coverage of authenticated scans, compliance with vulnerability scans and compliance with authenticated scans. Coverage metrics compare scanned assets against the population that should be scanned, and compliance metrics check whether scans ran at the required cadence and in the required mode. Before any percentage means anything, the organization has to show what that population is.
That population comes from the prerequisites. The specification lists Safeguards 1.1 (the enterprise asset inventory), 2.1 (the software inventory) and 4.1 (the secure configuration process) because they typically produce the data the measurements need. The asset inventory defines which internal devices count as in scope, and the software inventory defines which operating systems and applications each device is expected to report. An assessor will ask whether the scanner's target list was built from the asset inventory, and whether any device on the inventory is missing from the scan schedule. A scan that covers 100 percent of a stale list proves little, so confirm that the inventory is current and reconciled before you present coverage figures.
The specification says what to measure, not how, so the method is your decision. CIS states that it defines inputs, operations and measures but leaves the technique to the organization. Decide how you will extract the scanner's asset list, how you will match it to the inventory, and how you will prove that authenticated credentials succeeded on each host, since a credentialed scan that silently fails falls into the unauthenticated group. Record those decisions in the vulnerability management process from Safeguard 7.1 so the assessor can repeat your calculation. Ask any tool vendor or implementation partner to show the raw data behind each metric, not only the dashboard.
What an assessor requests and where scans commonly fail
This table sets out, for each area an assessor is likely to examine under Safeguard 7.5, what testing looks like, which records to produce and the findings that most often appear. Read it as a pre-assessment checklist: each row is a place where a scan program can look complete on paper but fail when the evidence is pulled.
| Area | Test approach and evidence requested | Common findings |
|---|---|---|
| Scan schedule records | Confirm internal scans are configured to run at least quarterly. Request scan task definitions, schedule history and run logs for the assessment period. | No evidence of a quarterly cadence, or schedules that were changed or paused without a record. |
| Asset list reconciliation | Compare the list of assets scanned with the enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1. Request target lists and the reconciliation output. | Scans run only on a subset of assets, with newly provisioned or cloud assets missing from target lists. |
| Authenticated scan credential records | Confirm credentials exist for each scanned asset class, are scoped to least privilege and that authenticated scans complete. Request credential inventory (without secrets) and authenticated scan reports. | Authenticated scans silently failing after password rotation or lockout, so reports show only unauthenticated results. |
| Scan result retention | Request raw scan reports and summary metrics for each run, retained for the period the assessor samples. Confirm results can be tied to a specific scan task and date. | Reports overwritten by later scans, or results exported as screenshots that cannot be traced to a run. |
| Exceptions and excluded assets | Request the list of excluded assets, the reason for each exclusion and the approver. Confirm exclusions are reviewed on a defined cycle. | Exclusions added informally, with no owner, reason or expiry date. |
| Coverage and compliance metrics | Request the calculated coverage and compliance figures for both authenticated and unauthenticated scans, with the method used to calculate them. | Metrics that cannot be reproduced from the underlying scan data, or that count assets which were never scanned as covered. |
How to implement quarterly internal scanning with authenticated coverage
This sequence moves from known assets and software to scheduled internal scans, with authenticated and unauthenticated coverage tracked against the inventory. The output is a scan program the organization can show an assessor, with exceptions documented and owned.
Confirm the asset and software inventories
The organization's IT operations team confirms that the enterprise asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) are current before any scanner is pointed at the network. The Assessment Specification treats these two inventories as prerequisites for measuring Safeguard 7.5 because they supply the scan targets and the software context that findings depend on. Done means each internal asset has an owner, an address and a record of installed software, and the team can name the gaps. Those gaps become the first entries in the exception log.
Confirm secure configuration baselines
The platform engineering team confirms that the secure configuration process (Safeguard 4.1) is documented and applied to the asset classes in scope, so scan results can be read against a known baseline. Without that baseline, a scanner reports deviations that nobody can judge. Done means each asset class has a named configuration standard, and the team knows which standard applies to each inventory record.
Define scan scope and cadence
The security team writes the scan scope as a list of network ranges, asset classes and business units, and sets the internal scan cadence at least quarterly, as Safeguard 7.5 requires. The document should state which assets are excluded, who approved each exclusion and when it expires. Done means a signed scope statement exists, the cadence is recorded in the vulnerability management process from Safeguard 7.1, and the assessor can trace each range back to the inventory.
Create least-privilege scanning credentials
The security engineering team creates dedicated scanning accounts on Windows, Linux and network platforms, granting only the read access needed to query installed packages, patch levels and registry or configuration data. Credentials are stored in a secrets manager, rotated under the account management process, and logged. Done means each credential has a documented owner and scope, and a test scan on a sample of hosts confirms the account returns package-level data rather than failing silently. Authenticated coverage depends on this step, so the team should verify it before scheduling.
Schedule authenticated and unauthenticated scans
The scan engineer configures separate scan tasks for each target group: authenticated scans using the credentials from the previous step, and unauthenticated scans that reveal what an attacker on the internal network could see without a login. Both task types are scheduled no less often than quarterly, and the schedule is recorded in the scanner. Done means each task has a named owner, a target list and a last-run date, and the first run completes with results stored in the scanner's database.
Reconcile scan targets against the inventory
After each run, the team compares the hosts the scanner actually reached with the asset inventory from the first step. Hosts that appear in the inventory but were not scanned, or were scanned without authentication, are listed with a reason. This reconciliation produces the metrics the Assessment Specification uses for scan coverage and authenticated scan coverage, so the figures should come from the same source records as the inventory. Done means a reconciliation report exists for each run and every gap has an owner.
Set up review and exception process
The vulnerability management owner reviews each scan report, routes findings to the remediation process under Safeguard 7.2, and records any exception with a reason, an approver and an end date. Exceptions for assets that cannot be scanned, such as fragile devices, are reviewed on the same cycle as the scan program. Done means the exception register is current, the assessor can see who approved each exception, and the compliance measures for scan coverage and compliance are reported to the security committee.
Evidence that passes 7.5 and how to keep it current
An assessor testing Safeguard 7.5 looks for a repeatable record: a scan schedule, reports that show how each host was authenticated, a target list tied to the asset inventory, and calculated coverage and compliance figures. The cards below cover each artifact and the routine that keeps it accurate between assessments.
Scan schedule and task history
Keep the approved schedule for internal scans, along with the task run history that shows each scan actually executed at least quarterly. Export the schedule with its approval date and any changes. An assessor will compare planned cadence with executed runs, so gaps should be explained in writing before the review, not discovered during it. Confirm who can edit schedules and whether edits are logged.
Scan reports with authentication status
Each report should state, per host, whether the scan ran authenticated or unauthenticated and why. Credentialed results show installed software and missing patches, while unauthenticated results show only what is exposed on the network. Store both report types, because Safeguard 7.5 measures authenticated and unauthenticated scans separately. Label the authentication column clearly so an assessor does not have to infer it.
Target lists reconciled to the inventory
The scan target list should match the enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1. Keep a dated reconciliation showing which inventoried assets were scanned, which were out of scope with a reason, and which scanned hosts were missing from the inventory. Unreconciled targets are the most common reason coverage figures fail to hold up under review.
Coverage and compliance calculations
Safeguard 7.5 is measured through coverage and compliance metrics, including separate figures for authenticated scans. Keep the formula, the input export and the result for each reporting period, so the numbers can be recalculated from source data. Ask your team to confirm the definitions used in the CIS assessment specification, since a percentage with an undocumented denominator will be questioned.
Failed credential logs
Authenticated scans fail when credentials are wrong, expired or blocked, and those failures silently lower the authenticated coverage figure. Keep a log of failed logons per target, the date each was detected and the date it was fixed. Review the log at each scan cycle. A rising count of failures on the same hosts usually signals an account management problem, not a scanner problem.
Exception approvals and retention
Any host excluded from scanning, or scanned only without credentials, needs a signed exception with a named owner, a justification and an expiry date. Store exceptions with the scan records they affect. Set a retention period for reports, exports and exception records that matches the assessment cycle your organization is held to, and confirm it with the auditor before setting it. Dated exports taken at each cycle keep evidence current between audits.
Self-hosted scanning patterns for internal assets
Network-based scanning is the traditional pattern for internal assets. A scanner placed on a management segment sends probes to hosts in the address ranges it is given, and it reports what the network reveals without needing credentials. Unauthenticated scans show exposed services and version banners, which is useful for finding what an attacker on the segment could reach. Authenticated scans log in with approved credentials, so they can read installed packages, patch levels and registry or configuration values that a network probe cannot see. Safeguard 7.5 expects both, so most programs run the two modes against the same asset list and track each separately.
- Scanner placement: A self-hosted scanner such as Greenbone Community Edition (OpenVAS) runs in the enterprise network, with gvmd storing results in PostgreSQL and scan tasks scheduled from the Greenbone Security Assistant interface.
- Credential scope: Create dedicated, least-privilege scan accounts for each operating system family, store them in a vault, and record which hosts each account can reach.
- Target lists: Derive target lists from the asset inventory (Safeguard 1.1) so that coverage can be calculated against a known population.
- Scan records: Export task definitions, schedules, credential assignments and result timestamps as evidence of cadence and authenticated status.
- Findings flow: Send results to a findings platform such as DefectDojo for deduplication and tracking into remediation under Safeguard 7.7.
Before relying on this pattern, confirm with your assessor which network segments count as internal enterprise assets and how they will be sampled.
Internal workloads in cloud accounts are often reachable only through private addressing, which means the scanner must run inside the same virtual network or be routed to it. The authenticated and unauthenticated split still applies, but the evidence comes from more sources: cloud inventory, virtual machine images and the scan records themselves. Ephemeral instances are a particular risk for coverage metrics, because a host that exists for a few hours may fall outside a scan window and then disappear from the record. Program owners should decide early how short-lived instances will be captured.
- Scanner in the network: Deploy the scanner as a self-hosted instance in a management subnet within the cloud account, with routes to private workloads and no public exposure of its interface.
- Inventory feed: Reconcile the cloud resource inventory with scan target lists on each run, so that newly launched or retired instances change the coverage denominator.
- Image-based hosts: Where workloads are built from golden images, scan the image or its running instances and record the image version alongside the findings.
- Credential handling: Use cloud-native secrets management for scan credentials and restrict instance roles to the minimum needed for scanning.
- Change records: Keep logs of scanner-to-target connectivity changes, since a broken route can silently remove hosts from the authenticated count.
Ask the team to show how a host launched and terminated between two scan cycles would appear in the coverage metric.
Agent-based detection reverses the flow. Instead of a scanner reaching into each endpoint, a lightweight agent on the host collects its software inventory and reports it to a central manager. Wazuh vulnerability detection works this way: the agent's software inventory is correlated with the Wazuh CTI vulnerability repository, or a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications. Fleet takes a similar approach for enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Because the host reports its own inventory, these tools do not depend on network reachability, but they do depend on agent health.
- Agent coverage: Compare enrolled agents with the endpoint inventory to find hosts that never checked in or that have stopped reporting.
- Offline feeds: Where hosts or managers have restricted outbound access, host a local copy of the vulnerability content and record its update date.
- Inventory-based findings: Agent detection reports software versions rather than probing services, so pair it with network or authenticated scans when the assessor asks for scanner-style evidence.
- Evidence exports: Retain manager reports, agent status records and the feed version used for each evaluation.
- Deduplication: When agent results and network scan results both exist, import them into DefectDojo so one vulnerability does not appear as two open items.
Confirm whether the assessor accepts agent-based detection as meeting the scan requirement or expects it alongside a scanner.
Open-source tools that produce scan and vulnerability evidence
This table compares four open-source tools that can produce parts of the evidence for Safeguard 7.5: a network vulnerability scanner, an endpoint software inventory correlator, a host software matcher and a findings management platform. Read each row against the measures in the assessment specification, and remember that no single tool covers every metric on its own.
| Tool | What it produces for Safeguard 7.5 | License and caveat |
|---|---|---|
| Greenbone Community Edition (OpenVAS) | Network vulnerability scan results from scheduled scan tasks, stored in PostgreSQL and reviewed in the Greenbone Security Assistant. Useful for unauthenticated network scan records and scan schedules. | AGPL-3.0-or-later. Confirm in your version whether authenticated (credentialed) scans are configured and recorded, since the coverage of authenticated scans is a separate metric. |
| Wazuh vulnerability detection | Per-endpoint software inventory matched against vulnerability data, showing which operating system and installed applications are affected on each monitored host. Supports evidence of agent coverage. | GPL-2.0-only. Decide whether to use the Wazuh CTI feed or a locally hosted offline copy, and document which source produced each finding and its update date. |
| Fleet vulnerability detection | Matches installed software on enrolled hosts against sources such as the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Produces host-level vulnerable software reports. | MIT. Confirm which data sources are active in your deployment and how often they refresh, since the evidence date depends on them. |
| DefectDojo | Central record of findings from scanner reports, imported and reimported through the UI or API from more than 500 report formats, with deduplication by per-tool hashcode fields. Supports scan compliance tracking and audit trails. | BSD-3-Clause. Confirm that the import parser for each scanner you use is available in the open source edition and retains the scan dates you need. |
| Authenticated scan evidence | Credentialed scan records show scan depth on hosts, which the assessment specification treats separately from unauthenticated coverage. | Confirm with each tool's documentation that credentialed scanning is supported on your operating systems and that credentials and scan settings are logged. |
| Coverage and compliance evidence | No single tool proves coverage against the asset inventory. Export asset lists from the inventory process (Safeguard 1.1) and compare them with scanned host lists. | Your own reconciliation process produces this evidence. Document the query, the date and the reviewer. |
What meeting 7.5 costs in money and effort
Most of the money for Safeguard 7.5 goes to people and infrastructure, not to scanner licenses. The named open-source tools carry no license fee, but the organization still pays for the hosts that run the scanner, the database behind it, storage for scan results, the staff who schedule and review scans, and any support contract it chooses to buy. A scanner such as Greenbone Community Edition (OpenVAS) stores results in PostgreSQL and runs through the gvmd service, so a production deployment needs a managed, backed-up home inside the enterprise network. Ask your team to price those hosts and the time to patch them, because those costs recur every year whether or not a scan finds anything.
The largest one-time cost is engineering time. Authenticated scans, which Safeguard 7.5 requires alongside unauthenticated scans, need scan credentials for each operating system and platform class, and those credentials must be created, stored in a secrets manager, rotated and scoped with least privilege. Someone must also reconcile scan targets against the asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1, which the assessment specification lists as prerequisites. Expect this work to be heaviest in the first cycle, when unmanaged or poorly named hosts surface. Where Wazuh or Fleet already reports installed software, some of that reconciliation is shared with other controls, which lowers the marginal cost.
Recurring effort comes from evidence upkeep and review. Each scan cycle produces results that an assessor may sample, so the organization must keep scan configurations, schedules, credential records, coverage reports and triage decisions for the period under review. Findings then need deduplication and tracking, for example in DefectDojo, which deduplicates findings using per-tool hashcode fields, so that the same weakness is not counted and worked twice. External review adds cost when an independent assessor or a tester checks the coverage numbers. Auditor sampling cost rises with the number of scan cycles, the number of asset classes in scope and how poorly the evidence is organized. Your quote should list each component separately, state what is one-time and what recurs, and say which items are your staff's time and which are outside help. DeployOpen does not publish prices; a quote follows from the written scope.
Who owns the scanning program and who prepares the evidence
The organization owns Safeguard 7.5. That means it decides the scan cadence, the scope of internal assets, who approves exceptions and who acts on the findings. CIS states that the Controls are for the organization to use to improve its own security, and the assessment specification measures whether the organization's scanning program is implemented, not whether a vendor installed a tool.
- Scope decisions: Confirm which internal segments, server populations and endpoints fall under the quarterly minimum, using the outputs of Safeguards 1.1 and 2.1.
- Credential ownership: Hold the scanning accounts and their approval records, and decide who may change them.
- Exception approval: Document who accepts risk for assets that cannot be scanned, and for how long.
- Remediation accountability: Assign owners to findings, tied to the process in Safeguards 7.2 and 7.7.
- Metric review: Read the coverage and compliance figures each cycle and decide what they mean for the program.
Before engaging anyone, confirm that a named internal owner can sign off on scope and exceptions.
An implementation partner such as DeployOpen can plan, build and document the scanning environment inside your own infrastructure, then prepare the evidence an assessor will ask for. Typical work includes deploying scanners, designing authenticated scan credentials, configuring schedules, and writing reconciliation scripts that compare scanned assets with the inventory. The partner prepares systems and evidence. It does not issue audit reports or attestations.
- Deployment and configuration: Install and harden open-source scanners such as Greenbone Community Edition in your environment, with scheduled tasks and stored results.
- Credential design: Create least-privilege, documented scan accounts for authenticated scans and a process for rotating them.
- Reconciliation scripts: Compare inventory exports with scanner target lists so coverage gaps are visible.
- Evidence packaging: Organize schedules, scan reports, exception records and metric calculations so an assessor can trace each measure.
- Documentation and handover: Deliver runbooks so your staff can operate the program after the engagement.
Ask for a written scope that names each deliverable and states who keeps the credentials after handover.
An independent auditor, assessor or certification body tests whether Safeguard 7.5 is implemented and issues any report or certificate. Independence means the party testing the control did not design or operate it in a way that would bias its conclusions. For that reason, the firm that built your scanner configuration or wrote your reconciliation scripts should not also be the party that certifies the outcome, unless the relevant scheme allows it.
- Testing the design: The assessor reviews whether the scan policy, scope and cadence are documented and approved.
- Sampling operation: The assessor selects scan cycles and asset samples, then checks scan records, credentials and results against the inventory.
- Reviewing exceptions: The assessor checks that exceptions were approved by the owner and tracked to closure.
- Confirming metrics: The assessor recalculates coverage and compliance figures from source data rather than accepting a summary.
- Reporting: Only the assessor issues the report or certificate, under the rules of the scheme in use.
Confirm with the assessor, before work starts, which parts of the preparation they will accept as evidence and which they must test independently.
Gaps that cause 7.5 findings and how to close them
Most Safeguard 7.5 findings do not come from missing scanners. They come from scans that run but do not reach every asset, do not authenticate, or leave no record that an assessor can test. The six gaps below are the ones that most often turn a working scan program into an assessment exception.
Authenticated scans failing silently
An unauthenticated scan reports only what a network probe can see, so local patches and installed packages often go unchecked. When credentials expire or lack rights, many scanners still complete the job and report it as successful. Check the authentication result for every asset in each scan report, and alert on any host that returns to unauthenticated status. Both the authenticated and unauthenticated coverage measures in the assessment specification depend on this distinction.
Inventory gaps hiding assets
A scanner can only test the hosts it knows about. Assets that never appeared in the enterprise asset inventory under Safeguard 1.1, or software absent from the software inventory under Safeguard 2.1, fall outside the scan target list and drop out of coverage. Reconcile the scanner's host list against the asset inventory each time a scan cycle closes, and treat any unmatched host as a finding until it is classified or removed.
Scans not running quarterly
Safeguard 7.5 sets a quarterly floor for internal scans, but schedules often drift when a scan task is paused, a scanner is upgraded, or an owner leaves. A gap of one quarter can show up as a compliance failure even when the team believed scanning was continuous. Confirm the schedule in the scanner itself, not in a runbook, and review run history against the calendar each quarter. Ask your team whether any scan window was skipped and why.
No documented exception record
Some assets cannot be scanned safely, such as fragile industrial controllers or systems under a vendor restriction. When these are left out without a record, the gap looks identical to neglect. Keep a dated exception register that names the asset, the reason it cannot be scanned, the compensating activity, the approver and a review date. An assessor will ask for this record before accepting an unscanned asset as out of scope.
Scan results not retained
Assessors test Safeguard 7.5 by reviewing evidence from past scan cycles, not only the current dashboard. If the scanner purges reports or the database is rebuilt without a backup, the proof for earlier quarters is lost. Set a retention period that covers the assessment window, export reports in a stable format, and back up the scanner's PostgreSQL data along with its configuration. Confirm retention settings in the platform documentation before relying on them.
No metric calculation
The assessment specification combines its measures into four metrics: coverage of vulnerability scans, coverage of authenticated scans, compliance with vulnerability scans and compliance with authenticated scans. Organizations that scan regularly but never compute these figures cannot show their performance against the Safeguard. Define the numerator and denominator for each metric from your asset and scan records, calculate them every cycle, and keep the calculations alongside the raw scan exports.
Questions buyers ask about Safeguard 7.5
Does Safeguard 7.5 apply to IG1 organizations?
No. Safeguard 7.5 is assigned to Implementation Groups 2 and 3 in CIS Controls v8.1, not to IG1. IG1 is the essential cyber hygiene baseline, so an IG1 organization is not expected to meet 7.5 to claim that baseline. IG2 and IG3 organizations with more complex environments or sensitive data are expected to meet it. Confirm your Implementation Group against the CIS Controls Navigator before you scope the work, because the assignment determines which measures your assessor will test.
How long does it take to set up internal vulnerability scanning?
No fixed duration applies, because the time depends on the environment. The main drivers are how complete your asset inventory and software inventory already are, how many network segments need scanner access, whether authenticated credentials can be issued to asset owners, and how many scan results must be triaged. The assessment specification lists Safeguards 1.1, 2.1 and 4.1 as prerequisites because they produce the data scan measurement depends on, so weak inventories and undocumented configurations usually lengthen setup. Ask any provider for a written, fixed-scope plan that lists each phase and its deliverables before work begins.
Are open-source vulnerability scanners acceptable evidence for Safeguard 7.5?
Safeguard 7.5 does not name a product, so a tool is acceptable when its output can show what the assessment measures: that scans run at least quarterly, that they cover internal enterprise assets, and that authenticated and unauthenticated scans both occur. Greenbone Community Edition (OpenVAS) schedules scan tasks and stores results in PostgreSQL, and Wazuh correlates agent software inventories with a vulnerability repository. Whether an assessor accepts a given tool depends on how the evidence is produced and retained, so confirm the approach with your assessor before relying on it.
Can our own team run internal vulnerability scans without a partner?
Yes, if your team has the skills and capacity to run the scanner, manage credentials, triage findings and keep records. The organization owns the control, so an internal team can implement it. Most teams find the recurring work is the hardest part: scans must run on schedule, results must be reviewed and tracked to remediation under Safeguards 7.2 and 7.7, and coverage metrics must be kept current. A partner can be engaged for a fixed-scope build of the tooling and evidence, followed by a handover, or for ongoing support under a retainer.
What does the work require from our own team?
The work requires named owners across several functions. Infrastructure or platform engineers install and maintain the scanner and its network access. Security staff define scan policies, review results and track remediation. Asset owners or system administrators provide the credentials used for authenticated scans and approve scan windows. Someone must also keep the asset and software inventories accurate, because scan coverage metrics depend on them. Document who does each task, how often, and where the records are kept, since an assessor will ask for that proof.
What can an implementation partner not do for Safeguard 7.5?
A partner cannot issue the assessment result. Implementation partners plan, configure and document the scanning capability and prepare the evidence, but only an independent assessor or certification body can issue a report or certificate that a Safeguard is met. Your organization remains responsible for its controls, for running scans on schedule and for acting on findings. Ask any partner to state in writing which deliverables are implementation and evidence preparation, and which decisions remain with your organization or your independent assessor.
How do we know what the engagement will cost?
Cost depends on the written scope, and no published price list exists. Costs fall into one-time items such as design, deployment, integration and documentation, and recurring items such as scanner operation, scan review, credential management and retained support. The main drivers are the number of asset classes and network segments, the number of authenticated scan targets, existing inventory quality and the level of ongoing support you need. Ask for a quote that separates one-time and recurring costs, lists each deliverable, and states what the customer must provide.
How DeployOpen scopes and prepares 7.5 evidence
DeployOpen plans, implements and documents self-hosted open-source scanning for Safeguard 7.5 inside your own cloud accounts, data centers or air-gapped networks. The work starts with a written scope that names the internal network ranges, asset classes and segments to be scanned, the scanner placement for each segment, the credentialed scan accounts, and the exact evidence the assessor will receive. Scope, deliverables and timelines are agreed in writing before any build work begins, and a quote follows from that scope. The organization keeps ownership of the scanning policy, the scan cadence and the decision about which findings are accepted as risk. Before scanners are configured, the team checks the prerequisites the assessment specification relies on. The asset inventory from Safeguard 1.1, the software inventory from Safeguard 2.1 and the secure configuration process from Safeguard 4.1 should already exist, or be scoped as part of the engagement, because the measures for 7.5 draw on that data. Confirm with your own staff which systems are authoritative for each inventory and whether scan targets can be reconciled against them, since a scanner that misses assets will show low coverage regardless of how well it runs.
DeployOpen prepares the evidence package that an independent assessor or auditor will review: scan schedules, scanner configuration exports, credentialed and uncredentialed scan records, coverage reports against the asset inventory, and the remediation tickets linked to findings. The package is built to support the coverage and compliance metrics in the assessment specification, but the assessor decides whether the evidence is sufficient. DeployOpen does not issue audit reports, attestations or certifications. Once the scanners are in production, scan coverage tends to drift as new assets appear and credentials expire. Ongoing scanning support, tuning and evidence upkeep can be arranged as a retainer, and that retainer is priced separately from the fixed-scope build. Ask any implementation partner to state in writing who owns scanner credentials, where scan data is stored, and how the evidence will be handed to your assessor.
