Safeguard 7.6 external vulnerability scans: CIS evidence

What Safeguard 7.6 asks for: monthly automated scans of external assets

Safeguard 7.6 asks for automated vulnerability scans of externally exposed enterprise assets at least monthly. If an assessor or customer is asking for evidence of external scanning, they want to see that every internet-facing system is scanned automatically on that cadence, that the results exist, and that someone acted on them. The organization owns this control. An implementation partner can set up the scanning and evidence trail, but only an independent auditor issues any report on it. External exposure raises the stakes because an attacker on the internet needs no insider access to probe a system that is reachable from outside. A flaw in a public web server, VPN gateway or cloud load balancer can be found and exploited within days of disclosure. That is why Safeguard 7.6 sets a tighter cadence than the quarterly internal scans in Safeguard 7.5. Safeguard 7.6 is also assigned to Implementation Groups 2 and 3 but not IG1, so an IG1 organization is not required to meet it. Confirm your own Implementation Group before you commit scope, and check the assessment specification for the current wording of each measure. The hard part is usually not the scanner. It is knowing what is exposed. Public IP addresses, DNS records, load balancers and short-lived cloud instances change often, and a list built once during a project goes stale quickly. Confirm that your asset inventory from Safeguard 1.1 and software inventory from Safeguard 2.1 capture internet-facing assets, and that the external scan target list is generated from them or reconciled against them. The most common gap is scans that run on schedule but whose reports are never reviewed or routed to remediation. Ask who receives each report, how findings are triaged, and what record shows the review happened.

Which external assets and teams fall under Safeguard 7.6

Safeguard 7.6 only works if the scan list matches what the enterprise actually exposes to the internet. The cards below cover the asset types to include, the owners who must act on findings, and the inventories that let an assessor confirm the scope is complete.

Public IP addresses and DNS names

Start with every public IP range and every DNS name that resolves to it, including old records, subdomains created for test projects and names pointing at decommissioned hosts. Compare DNS zone exports with cloud account address lists, because a forgotten record often marks an unmanaged service. Confirm with the network team who owns each zone, since the scan schedule only holds if someone can approve the target list.

Load balancers and reverse proxies

Load balancers, CDN origins and reverse proxies expose backend services, so scanning only the public hostname can miss the systems behind it. Record which backend pools each listener forwards to, and check whether any origin is reachable directly from the internet. The owner is usually the platform team that manages the listener configuration.

VPN gateways and remote access endpoints

VPN concentrators, remote desktop gateways and zero trust access proxies are common entry points and frequently run older firmware. Include their management interfaces if they are reachable from outside, and confirm the scanner can authenticate or at least identify their version. Security operations or network engineering typically owns these assets.

Cloud-hosted services and externally reachable APIs

Cloud virtual machines, container services, serverless endpoints and public API gateways create exposure that changes with each deployment. Tie each internet-facing resource to an owning application team and an account or subscription, and review security group rules for ports that open to 0.0.0.0/0. Ask engineering leads to confirm which APIs are meant to be public and which were exposed by mistake.

Third-party and hosted assets

Systems run by a SaaS vendor, managed hosting provider or outsourced development firm may still carry your domain name or customer data. Decide whether Safeguard 7.6 covers them as enterprise assets or whether the contract requires the provider to scan and report. Record that decision in the service provider inventory and confirm it with procurement, because an assessor will ask who scans these systems.

Inventories that define the scan list

Safeguard 7.6 depends on the enterprise asset inventory (Safeguard 1.1), the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1). The CIS Controls Assessment Specification lists these as prerequisites because they produce the data the measurement needs. Without them, the external scan list cannot be shown to be complete, and the software inventory helps identify the service versions the scanner reports. Applies to IG2 and IG3, since Safeguard 7.6 is not assigned to IG1.

How the assessment specification measures Safeguard 7.6

The CIS Controls Assessment Specification (CAS) for v8.1 is the document that tells an assessor what to measure to confirm a Safeguard is implemented. For each Safeguard it defines inputs, operations, measures and metrics, but it stops at what to measure and leaves the method to the organization. For Safeguard 7.6, six measures roll up into two metrics: coverage of vulnerability scans and compliance with vulnerability scans. In practical terms, coverage asks whether every externally exposed asset is inside the scan scope, and compliance asks whether those scans run on the required schedule and produce usable results. Before you build any evidence around these measures, confirm the exact measure wording in the specification, because that wording determines what an assessor will test.

Three other Safeguards feed the measurement of 7.6. The specification lists them as prerequisites because they typically produce the data it needs: Safeguard 1.1 (the enterprise asset inventory), Safeguard 2.1 (the software inventory) and Safeguard 4.1 (the secure configuration process). The first decision is which assets count as externally exposed. Build that list from the asset inventory, flagging public IP addresses, internet-facing DNS names, load balancers, VPN concentrators and cloud services with public endpoints, and record an owner for each. Then check that the software inventory explains what runs on those assets, since scan findings are only as useful as the service list behind them. Changes to secure configuration can make a service reachable, so treat such a change as a trigger to review the external scope. Illustrative example: a reverse proxy published to the internet without an inventory entry is the kind of gap a coverage check would expose.

Evidence for 7.6 should show the schedule and its history, not only the scanner's current configuration. For each period, keep the scan target list, the scan task schedule, the completed reports with their dates, and approval records for any asset temporarily removed from scope, each with an owner and an end date. Open-source tools can support this record. Greenbone Community Edition schedules scan tasks and stores results in PostgreSQL, and DefectDojo can hold findings across repeated runs so the history stays reviewable. Confirm with your tool vendor which reports and fields carry scan timestamps and target lists, because assessors will ask for them. Before fieldwork begins, agree with your independent assessor how they will sample assets and periods. Your team prepares these records, but the assessor or certification body draws the conclusion.

How an assessor tests external vulnerability scanning

This table lists the practical steps an assessor takes to test Safeguard 7.6, what each step checks, the evidence requested and the gaps that most often appear. Read it as a sequence: the external asset list must be right before scan schedules and reports can be trusted, and findings must be traced into remediation before the Safeguard is met.

Test step	What the assessor checks	Evidence requested	Common findings
Confirm the external asset list	That the externally exposed assets are identified and match the enterprise asset inventory and software inventory (Safeguards 1.1 and 2.1)	Inventory extract filtered for internet-facing addresses, DNS records, cloud public IP listings, and the reconciliation to scan targets	Public IP ranges or cloud load balancers missing from the inventory, or hosts scanned that no longer exist
Check scan schedule against the monthly minimum	That automated external scans are configured at least monthly and that the schedule covers every external target	Scheduler configuration or task list, scan calendar, and the scan frequency setting for each target group	Schedules set to quarterly, scans running on some targets but not others, or schedules paused without record
Sample scan reports across months	That reports exist for each month in the review period and that scans completed rather than failed or timed out	Scan reports or summaries for a sample of months, with completion status and scan start and end times	Gaps in months, partial scans reported as complete, or reports that do not name the targets scanned
Test coverage for newly exposed assets	That assets published after the last scan are detected and added to the external scan scope within a reasonable window	Change records for new internet-facing services, discovery results, and the date each new asset first appeared in scan scope	New services or test environments exposed to the internet without ever being scanned
Verify automation and authentication	That scans run without manual starts and that authenticated scanning is used where the assessor's scope and the asset type allow it	Scanner configuration showing credentials or scan profiles, job logs showing unattended runs	Scans started by hand when staff remember, or credentials configured for some targets only with no documented reason
Trace findings into remediation	That detected vulnerabilities are recorded, deduplicated, assigned and passed to the remediation process from Safeguard 7.2	Ticket samples linking scan findings to owners, due dates and remediation outcomes, plus rescan results after fixes	Findings kept in scanner reports only, no owner assigned, or closures recorded without a verifying rescan
Review exceptions and false positives	That accepted risks and false positive decisions are documented, approved and reviewed	Exception register with approver, justification and review date for each accepted finding	Blanket suppressions, expired exceptions still active, or no approver named

Implementing Safeguard 7.6 in sequence

This sequence turns Safeguard 7.6 into a repeatable monthly process: a current list of externally exposed assets, a written scan scope and schedule, a configured scanner, retained results, handoff to remediation, and metrics that show whether the process works.

Build the external asset inventory
Start from the enterprise asset inventory under Safeguard 1.1 and the software inventory under Safeguard 2.1, and filter for assets reachable from the internet: public IP addresses, DNS names, cloud load balancers, VPN gateways, remote access portals and exposed APIs. The network team owns the list, and the security team reviews it against external DNS records and cloud account listings. The step is complete when every externally reachable asset has an owner, a purpose and a recorded software stack, and the list is dated and stored with the scan records.
Define scope and monthly schedule in writing
Write a short scanning procedure that names the in-scope address ranges and hostnames, the scan frequency (at least monthly under Safeguard 7.6), the scanning account and source addresses, the approval needed before scope changes, and who is notified when a scan fails. The procedure should reference the vulnerability management process in Safeguard 7.1 so the two documents agree. The output is an approved, versioned procedure with a named owner and a schedule that the scanning platform can follow.
Select and configure the external scanner
Choose a scanner that can run unauthenticated scans from outside the network against the in-scope list, and confirm it covers the service types you expose. Greenbone Community Edition (OpenVAS) is one open-source option: its gvmd service stores results in PostgreSQL, manages users and permissions, and schedules scan tasks through the Greenbone Security Assistant interface. Confirm vendor feed update behavior, scanner source IP handling and coverage for your services in your own environment before relying on it. The output is a configured scanner with a scheduled task for each target group and a test scan that reaches a known exposed service.
Run scans and retain results
Run the scheduled scans and keep each report with its date, target list, scanner version and feed version so that results can be reproduced during an assessment. Store raw reports in a location with access control and retention rules that match your data governance policy. Record scans that failed, timed out or were blocked, because those gaps count against the coverage metric. The output is a dated, complete record for every monthly cycle, including documented failures and their follow-up.
Triage findings and deduplicate
Import the results into a findings tracker such as DefectDojo, which accepts reports from more than 500 tool formats and deduplicates findings using per-tool hashcode fields. Confirm each finding against the asset inventory, separate false positives with a recorded reason, and assign severity and an owner. Where a finding is external-facing and the affected software is unclear, check it against the software inventory from Safeguard 2.1. The output is a deduplicated, triaged list in which every open finding has an asset, an owner and a status.
Hand findings to remediation
Pass triaged findings to the remediation process in Safeguard 7.2, which sets the risk-based priority and timeline, and let Safeguard 7.7 govern the fix itself. Externally exposed findings should be ranked above internal ones of similar severity because they are reachable by attackers. Link each ticket back to the scan finding so closure can be verified by a rescan. The output is a set of tracked remediation tickets with priorities, owners and a link to the source finding.
Track coverage and compliance metrics
The Controls Assessment Specification measures Safeguard 7.6 with coverage of vulnerability scans and compliance with vulnerability scans. Calculate coverage as the share of in-scope external assets that were scanned in each cycle, and compliance as the share of scans that ran on the required monthly schedule. Review both figures monthly and record gaps, such as assets added to DNS but missing from scope. The output is a monthly metrics record that an assessor can trace back to the scan reports and the inventory.
Test the process and correct gaps
Test the whole chain at least once: add a test host with a known exposure to the inventory, confirm the scanner detects it, follow the finding through triage and into the remediation queue, and verify closure by rescanning. Record what failed and update the procedure, inventory or scanner configuration. An independent reviewer, such as an internal audit function or an external tester, can check the test record. The output is a test report with corrective actions that feed back into the procedure from the first step.

Evidence that passes a Safeguard 7.6 review

Safeguard 7.6 is tested through what the scanning program produced over time, not through a single scan. The cards below cover the records an assessor is likely to ask for, from the list of exposed assets to the tickets that closed each finding. Confirm the exact set and sampling approach with your auditor before the review begins.

External asset list with dates

A dated inventory of every internet-facing system, including public IP addresses, DNS names, cloud load balancers and exposed APIs. Assessors compare this list against the scan targets to test whether scanning covers what is actually reachable from outside. Record when each asset was first exposed and when it was retired, so the list shows its state at any date in the review period. Your asset inventory from Safeguard 1.1 is the natural source for this list.

Scan schedule and scanner configuration

The documented schedule showing that external scans run at least monthly, along with the scanner settings that define each job, such as targets, scan profile, plugin feeds and credentials handling. Assessors use this to confirm the cadence was set in advance and was not reconstructed afterward. Keep the configuration under version control so each change has a date and an owner. Confirm with your auditor whether they expect the schedule to appear in your vulnerability management process document from Safeguard 7.1.

Dated scan reports for each month

Raw and summarized reports for every scan run in the review period, each showing its start and end time, the targets it covered and the vulnerabilities it reported. Assessors look for an unbroken monthly series, so a missing month is the most common gap they raise. Store the original report files, not only screenshots or spreadsheets, because they are the record a reviewer can re-examine. Ask your auditor how many months and which samples they will select.

Coverage reconciliation against exposed assets

A reconciliation that matches each exposed asset from the external list to at least one completed scan in the period, and explains every gap. Gaps usually come from assets added after a scan window closed, scan targets that reached a different address, or systems behind a provider that blocked the scanner. Write down the reason for each unmatched asset and the date it was brought into scope. This document supports the coverage metric that CIS measures for Safeguard 7.6.

Findings linked to remediation tickets

Records that tie each external finding to a ticket, its risk rating, the owner, the due date and the closure evidence, such as a retest result or a patch record. Assessors sample findings and trace them forward to see whether the remediation process from Safeguard 7.2 was followed. Accepted risks need a documented approval and a review date. Set your ticketing system to keep closed records so findings from earlier months remain traceable.

Metric reports and change log

Periodic reports that show scan coverage and scan compliance over time, with the underlying counts, plus a change log recording when assets were added or removed from external scanning. The change log is what keeps evidence current between audits: every newly exposed system should generate an entry and a scan target within the same cycle. Keep raw reports and change records for the full retention period your auditor and contracts require. Confirm that retention period in writing before the review period starts.

What meeting Safeguard 7.6 costs in money and effort

This table lists each cost component of running monthly external vulnerability scans, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to build a written quote request, because the largest recurring cost in most programs is people's time rather than scanner licenses.

Cost component	One-time or recurring	What drives it	How to keep it down
Scanner licenses or subscriptions	Recurring	Commercial scanner tiers often price by number of scanned addresses or hosts, and by scan features such as authenticated checks or feed access. Ask the vendor how external IP ranges are counted.	Scope scanning to the internet-facing ranges you can name. Open-source scanners such as Greenbone Community Edition remove license spend but not the labor below.
Engineering time for scope and configuration	One-time, then periodic	Identifying every externally reachable address, hostname, cloud load balancer and API endpoint, then setting scan targets, schedules and credentials. Cloud and DNS sprawl increases the work.	Start from the asset inventory required by Safeguard 1.1 and the software inventory from Safeguard 2.1 so scope is derived from records, not memory.
Asset inventory upkeep	Recurring	Each new public service, DNS record or cloud resource must be added to scope before the next monthly scan, or it goes unmeasured. Shadow internet exposure is the usual gap.	Tie scope updates to change tickets and cloud tagging. Reconcile external scan targets against DNS and cloud account listings each cycle.
Monthly review and triage time	Recurring	Each scan produces findings that need validation, false-positive handling, owner assignment and deduplication. Volume rises with the number of exposed services and the age of the software on them.	Deduplicate across tools and suppress accepted findings with documented reasons. Route findings to owners through the remediation process from Safeguard 7.2.
Platform hosting and operations	Recurring	Self-hosted scanners and aggregation tools need compute, storage, updated feeds, patching and access control. Scanner maintenance is often overlooked in the budget.	Run the scanner in an existing managed environment and document who maintains feed updates and the scanner itself.
External testing or review, if bought	Recurring or per engagement	Some organizations buy an outside review of scan scope, results or exposed services. The fee depends on the provider, scope and whether it is a one-off or retained service. Automated scans alone do not replace a penetration test.	Ask the provider for a written scope, deliverables and what the review covers compared with the scan. Keep the purchase separate from the scanning program.
Auditor sampling effort	Recurring at each assessment	Assessors typically sample scan records across months to confirm monthly cadence, scope coverage and follow-up. Gaps in any month or undocumented scope changes create extra questions and rework.	Keep scan schedules, reports, scope lists and remediation tickets in one place with dates. Confirm with your assessor which samples and periods they will request.

Open-source tools that produce external scan evidence

Safeguard 7.6 asks for automated scans of externally exposed assets at least monthly, and an assessor will want dated scan records, scope, and proof that findings were tracked. The four tools below cover different parts of that evidence trail, from running scan tasks to deduplicating findings, and none of them is a complete answer on its own.

Greenbone Community Edition for scheduled scans

Greenbone Community Edition (OpenVAS) runs through gvmd, which schedules scan tasks, manages users and permissions, and stores results in PostgreSQL. Reviewers work through the Greenbone Security Assistant web interface. For Safeguard 7.6, the schedule and stored reports can show monthly or more frequent runs against defined external targets. Confirm that your scan targets, credentials and network paths reach internet-facing addresses, and check the license terms, since the AGPL-3.0-or-later license carries obligations if you modify and distribute the software.

Wazuh for endpoint vulnerability detection

Wazuh vulnerability detection correlates the software inventory each agent collects with a vulnerability repository, either online or a locally hosted offline copy. It is built around endpoints, so it fits external assets only where an agent can be installed on a host you control. For Safeguard 7.6, it helps evidence the operating system and application state of exposed servers, but it does not replace network-level scanning of public addresses. Confirm which exposed assets can run an agent, and review the GPL-2.0-only license terms with your counsel before distribution.

Fleet for host software matching

Fleet matches installed software on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its output is a host-level view of vulnerable software, which complements the network view from a scanner. For Safeguard 7.6, it can show that the software on externally exposed hosts was checked against current advisories, provided those hosts are enrolled. Confirm that your exposed systems can be enrolled, and verify that the advisory sources you rely on cover your operating systems and applications. Fleet is released under the MIT license.

DefectDojo for finding tracking

DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and deduplicates them using per-tool hashcode fields. This gives you one record of each external finding, its status and its history across scan runs. For Safeguard 7.6, it is the place to show that scan results were reviewed and carried into remediation, which Safeguard 7.7 then addresses. Confirm that the report formats from your chosen scanners are supported, and check the BSD-3-Clause license terms for your deployment.

Who owns Safeguard 7.6 and what a partner can prepare

Your organization owns Safeguard 7.6. That means accountability for which external assets are in scope, how often scans run beyond the monthly minimum, and what happens to the findings. Scan results are only useful if someone is responsible for triage and for getting exposed weaknesses fixed, and that responsibility cannot be handed to a vendor or consultant. The asset inventory that Safeguards 1.1 and 2.1 call for is also yours to maintain, because the scan scope is only as complete as the list of internet-facing addresses, hostnames and services behind it.

Scope decisions: Decide which public IP ranges, domains, cloud endpoints and remote access services count as externally exposed, and approve changes to that list.
Cadence and exceptions: Set scan frequency at or above the monthly minimum and document any exception with a named approver.
Triage and ownership: Assign each finding to an owner who accepts, mitigates or fixes it under the remediation process from Safeguard 7.2.
Inventory upkeep: Keep the external asset list current when new services are published, retired or moved to a cloud provider.
Evidence retention: Keep scan reports, scope approvals and remediation records so they can be produced when an assessor asks.

Before you engage anyone, confirm internally who signs off the scope and who receives critical findings.

Safeguard 7.6 questions buyers ask before hiring help

How much ongoing effort does a monthly external scan cycle take once it is running?

Once the scanner, scan targets and reporting are in place, the recurring work is mostly review: someone checks each monthly run, triages new findings, confirms that scan targets still match the external asset list, and hands confirmed issues to the remediation process under Safeguard 7.2 and 7.7. The effort grows with the number of internet-facing hosts, services and cloud regions, how often those change, and how many false positives the team must clear. Ask any partner to state which of these items is included in a retainer and which stays with your team, and what happens when a new public endpoint appears between scan cycles.

Can we run external vulnerability scanning in-house with open-source tools?

Yes, in many environments. Greenbone Community Edition (OpenVAS) schedules and runs network vulnerability scans, stores results in PostgreSQL and is reviewed through the Greenbone Security Assistant web interface. DefectDojo can import scanner output from many tool formats and deduplicate findings so triage does not repeat each month. Confirm before you commit that the scanner's feed, scan policies and reporting meet your requirement, because open-source tools produce evidence but do not decide scope. Your team still needs staff who can authorize scan targets, tune scans to avoid disrupting production services and own the results.

How long does it take to implement monthly external scanning?

The duration depends on the written scope and your environment, so no fixed timeline applies to every organization. The main drivers are how well your external asset list is already known (Safeguards 1.1 and 2.1 supply much of this data), how many public address ranges, domains and cloud accounts must be covered, whether scan authorizations and change windows need approval, and how much of the reporting pipeline must be built. Ask for a timeline in the written scope that separates discovery of exposed assets, scanner deployment, a first validated monthly run and handover of the recurring process.

What do we need from our own team to support external scans?

Your team needs to supply authority and context. Someone must approve the public ranges and domains to be scanned, confirm which assets belong to the organization (including third-party hosted services), share change schedules, and define who receives findings and who owns remediation. Engineers need access to the systems that will host the scanner and reporting tools, plus a named owner for each exposed service. Without these inputs, scans either miss assets or flag systems that nobody can fix, so ask any partner to list these responsibilities in the scope before work begins.

Do monthly external scans replace penetration testing under CIS Control 18?

No. An automated external scan under Safeguard 7.6 detects known vulnerabilities and misconfigurations on exposed assets at a set cadence. Control 18 asks for testing that finds and exploits weaknesses in people, processes and technology, which requires a human tester to chain issues, test logic and assess what an attacker could reach. Scans can feed penetration test planning, and penetration test findings can feed the same vulnerability workflow, but each serves a different purpose and needs its own evidence. Treat the two as complementary measures in your assessment plan.

Can a partner issue a CIS Controls certification for our external scanning?

No. The CIS Controls do not provide a certification that a partner or your organization can issue. CIS Controls Accreditation applies to CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services, and it is a status for those providers, not a certificate for your environment. DeployOpen prepares systems, scan configurations and evidence for your Safeguard 7.6 measures. Only an independent assessor you engage can produce an assessment report, and you should confirm the assessor's accreditation status with CIS before you rely on it.

How DeployOpen scopes and prepares external scanning evidence

DeployOpen plans, implements and documents self-hosted open-source scanning inside your own infrastructure so that automated external scans of Safeguard 7.6 assets run on a defined cadence with reviewable records. The organization owns the control and its risk decisions, and an independent auditor or certification body issues any report or certificate.

How we scope

Engagements are fixed-scope, with the external asset list, scan cadence and deliverables agreed in writing before work starts.
The written scope names which internet-facing hosts, domains and IP ranges fall under the monthly or more frequent scanning requirement.
We confirm that asset inventory (Safeguard 1.1), software inventory (Safeguard 2.1) and secure configuration (Safeguard 4.1) data exist before measurement begins.

How we build

We deploy a self-hosted scanner, such as Greenbone Community Edition, inside your cloud account, data center or air-gapped network.
Scan tasks are scheduled at the cadence your written scope sets, with credentials and permissions managed by your team.
Results flow into DefectDojo, where findings are deduplicated and tracked so each scan cycle leaves a comparable record.

How we hand over

You receive documentation of the scan scope, schedule, tool configuration and the process for reviewing and triaging results.
Evidence packages include scan schedules, completed scan reports and coverage records that map to the CAS coverage and compliance measures.
Handover includes a walkthrough so your security team can run, review and extend the scanning process without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover scanner updates, scope changes when new external assets appear, and periodic review of scan coverage.
Before any assessment, confirm with your auditor which evidence formats and sampling periods they expect for Safeguard 7.6.