Safeguard 1.5 Use a passive asset discovery tool: evidence

What Safeguard 1.5 asks for and why passive discovery is the IG3 step

Safeguard 1.5 requires a passive asset discovery tool that identifies assets connected to the enterprise network, with its results reviewed and used to update the asset inventory at least weekly. It is the only Implementation Group 3 Safeguard in Control 1, and it sits on top of the detailed inventory in Safeguard 1.1 and the active and DHCP-based discovery that IG2 adds. Active scanning sends probes and waits for answers. Passive discovery listens to traffic that is already on the wire, such as ARP, DHCP, DNS and broadcast traffic, and builds a picture of which addresses, hardware identifiers and services are present. The difference matters because a probe only finds what responds to it. A quiet device, a medical or industrial controller that cannot tolerate scanning, or a device on a segment that scanners are not allowed to reach can stay invisible to active tools for months.

The hard part is visibility, not the software. A passive tool only sees the traffic that crosses the points where its sensors are placed, so a sensor on a core switch will miss conversations that stay inside a access switch or a wireless segment. Before you buy or deploy anything, confirm with your network team which segments carry traffic, which ones are switched locally, and where mirrored or span ports can be configured without disrupting production. Ask the tool vendor to document the protocols it parses, the traffic volume it needs, and how it attributes an observed address to an inventory record. Those answers decide whether the weekly review produces a usable list or a pile of unattributed addresses.

Treat the weekly review as a process with an owner, not a dashboard someone glances at. Record which networks each sensor covers, who reviews new and unknown observations, and how each finding is closed by adding the asset to the inventory or routing it to the unauthorized-asset process in Safeguard 1.2. Assessors will look for that trail. Sensor placement and configuration will also need to be documented, because the measurement of this Safeguard depends on how much of the enterprise's networks those tools actually cover. An open-source option such as Suricata can contribute network metadata to this picture, but it is an input to discovery, not a complete discovery tool on its own.

Which networks, devices and teams fall under Safeguard 1.5

Safeguard 1.5 is measured by coverage, so the first job is deciding which networks count as enterprise networks and which sensors or feeds reach them. The cards below cover the decisions that most often change the size of the work and the evidence an assessor will ask for.

Map every network segment to a sensor or feed

Start from the network diagram and list each segment that carries enterprise traffic: user VLANs, server zones, management networks, branch sites and DMZs. For each one, decide whether a passive sensor sees its traffic through a SPAN port, network TAP or flow export, and record the gap where none does. Coverage is measured by the share of networks the tool actually covers, so an unmapped segment is an open finding, not a neutral omission. Confirm the mapping with the team that maintains the diagrams.

Decide how OT and IoT segments are covered

Industrial controllers, building systems, medical devices and cameras often cannot tolerate active probing, so passive observation is usually the safer discovery method for these segments. Confirm with the operations owner which protocols and broadcast traffic are visible, whether a mirror port is available without disrupting production, and who may access sensor output. Record the segments excluded from scanning and the reason, because the assessor will ask why coverage is partial.

Place sensors for cloud and remote endpoints

Passive observation depends on traffic passing a point you can monitor. Cloud workloads may need virtual network taps, flow logs or agent-based inventory, and remote laptops on home networks rarely cross an office sensor at all. Decide which feeds stand in for network observation in each case, and document the ones that do not provide passive coverage. Ask the cloud platform team which flow log sources exist and how long they are retained.

Bring guest and visitor networks into scope

Guest Wi-Fi and visitor VLANs often bridge into or sit beside the enterprise network. Decide whether they are enterprise networks for this Safeguard, and whether devices seen there should be classed as unauthorized under Safeguard 1.2. A common approach is to observe guest segments for presence only, without storing user-identifying detail. Confirm the decision with legal and privacy staff before sensors are placed.

Assign who owns the tool and its output

Three teams commonly run passive discovery: the inventory owner, the network team and the security operations center. Each choice changes who reviews results and who is accountable for the weekly update to the inventory. Decide the owner in writing, name the reviewer who updates the inventory at least weekly, and confirm who can change sensor configuration. Assessors look for a named owner and records of the reviews, not just a running tool.

Confirm prerequisite records exist

The assessment specification lists Safeguards 4.2 and 12.4 as prerequisites for measuring Safeguard 1.5. Safeguard 4.2 covers the network infrastructure secure configuration process, and Safeguard 12.4 covers architecture diagrams. Before scoping coverage, check that current configuration records and diagrams exist for each network, because they are the reference you measure discovery coverage against. Gaps here usually mean the coverage figure cannot be defended.

How an assessor measures passive discovery coverage

This table walks through the steps an assessor takes to test Safeguard 1.5, which measures coverage: the share of enterprise networks watched by properly configured passive discovery tools. Read it as a checklist of what to prepare, the evidence to hold ready, and where assessments commonly stall.

Test step	What the assessor asks for	Evidence requested	Common finding
Confirm network scope	A current list of enterprise networks and segments that should be covered by passive discovery	Architecture diagrams and network segment inventory, drawn from Safeguard 12.4 work	Diagrams are outdated, so segments exist that no one has mapped to a sensor
Check network infrastructure configuration	Evidence that the network infrastructure secure configuration process (Safeguard 4.2) governs the devices that feed discovery	Documented configuration standard, change records and sample device baselines	Standards exist on paper but sensors or SPAN ports are not in the configuration baseline
Verify tool placement and configuration	Which passive tools observe each network, what traffic they see and how they are tuned	Sensor placement map, port mirroring or tap configuration, tool settings export	Sensors cover the core but miss remote sites, cloud subnets or segments reached only through a firewall
Measure coverage	The share of in-scope networks covered by properly configured passive tools	Coverage calculation that compares the segment list with sensor-observed networks	Coverage is asserted as a percentage without a traceable list of the networks behind it
Review scan results weekly	Proof that discovery output is reviewed at least weekly and by whom	Review logs, tickets or meeting records with dates and named reviewers	Reviews happen when someone remembers, leaving gaps of several weeks
Confirm output reaches the inventory	A traceable path from discovered assets into the Safeguard 1.1 inventory	Sample of newly observed devices with matching inventory entries and timestamps	Discovered devices sit in the tool console and are never added or flagged in the inventory
Test unknown device handling	Whether observed unrecognized devices feed the Safeguard 1.2 unauthorized asset process	Tickets or quarantine records for devices first seen passively	Unrecognized devices are logged but no response or removal is recorded

How to implement passive discovery in six steps

This sequence takes a passive discovery tool from architecture review to a weekly, owned inventory feed, with each step leaving a record an assessor can check. It keeps the tool's coverage claims tied to the network segments it can actually see.

Confirm the architecture diagram and segments
Start by collecting the current network architecture diagram and a list of every network segment, VLAN, branch and cloud network that carries enterprise traffic. The network team owns this list, and the security team checks it against the diagram. Safeguard 4.2 (network infrastructure secure configuration) and Safeguard 12.4 (architecture diagrams) are prerequisites for measuring Safeguard 1.5, so confirm both exist before going further. The step is done when every segment is named, each has an owner, and the diagram matches the list.
Choose sensor placement points
For each segment, decide where the tool will see traffic. Common options are SPAN or mirrored switch ports and network taps placed on links that carry the segment's traffic. Placement determines what the tool can observe, so a sensor on a single access switch may miss traffic that never crosses it. Record the chosen point, the device it attaches to and the segments it covers. The step is done when a placement record exists for every segment, with any segment that has no viable point flagged for the gap register.
Deploy and configure the discovery tool
Install the sensors and the collection point, then configure the tool to observe only the approved segments and to write discovered assets to a store the inventory can read. Confirm the tool's configuration against the vendor documentation, since capabilities vary by product. Keep the configuration file or settings export under change control so an assessor can see what was set and when. The step is done when the sensors report traffic from each planned point and the configuration is recorded.
Connect output to the asset inventory
Feed the discovery results into the detailed asset inventory described in Safeguard 1.1. Map the tool's fields (address, hardware identifiers where observed, first and last seen times, and protocols) onto the inventory's required fields, and define how a newly discovered asset is matched to an existing record or opened as an unmanaged item for the process in Safeguard 1.2. The step is done when a test device appears in the inventory with the expected fields and a second record is not created for the same device.
Set a weekly review with a named owner
Assign one named person to review passive discovery results at least weekly, and record that owner in the inventory procedure. The review compares new and changed assets against the inventory and routes unknown assets into the unauthorized asset process. Keep a dated log of each review, including the number of new assets found and the action taken. The step is done when the owner has accepted the role in writing and the first review log entry exists.
Record coverage gaps
Compare the segments in the architecture list against the sensor placements and the segments the tool actually observes. Record each gap, such as a segment with no sensor, a link where traffic is encrypted or filtered before the sensor, or a cloud or remote network outside the tool's reach. Assign each gap an owner and a decision (close, accept with reasoning, or compensate with another discovery method such as DHCP logging or active discovery). Coverage is the measure assessors use for Safeguard 1.5, so this register is the evidence that the share of covered networks is known and not assumed.

How passive discovery feeds the Safeguard 1.1 inventory

A passive discovery tool does not add assets to the inventory on its own. It produces inventory candidates: IP addresses, MAC addresses, protocols, observed hostnames and service banners seen on the wire. Each candidate has to be reconciled against the detailed record required by Safeguard 1.1 before it counts as known. Matching logic should run on stable identifiers such as MAC address, hostname and serial or asset tag where they are available, because IP addresses change under DHCP and by subnet. Candidates that match an existing record update that record. Candidates that match nothing move into the Safeguard 1.2 unauthorized-asset process, where someone decides whether the device is approved, must be removed, or must be blocked or quarantined. Confirm with your team who owns that queue and what the weekly review cadence looks like, since Safeguard 1.5 expects the results to be used at least weekly.

Passive tools only see traffic that crosses the points they monitor. A sensor on a core switch span port will miss a quiet device that talks only to a local switch in another building, and it will miss hosts that stay silent for long periods. Coverage therefore depends on sensor placement, mirrored or tapped traffic, and the network segments you have documented. Before you rely on results, compare the segments the sensor sees against your network diagrams and your list of subnets. For a segment without a sensor, a gap should be recorded and assigned an owner, not assumed to be empty. Illustrative example: a sensor on the server VLAN reports nothing from an isolated laboratory subnet, and the team only discovers the gap when a diagram review turns up the subnet.

Passive discovery works best alongside the other Control 1 discovery methods rather than as a replacement for them. Safeguard 1.3 covers active discovery, which probes address ranges on a schedule and finds devices that are quiet on the network. Safeguard 1.4 uses DHCP server or IP address management logs, which record devices that have requested addresses even if they never generate traffic a sensor can see. Each method has blind spots the others can fill. Ask your team to name which method is authoritative for each segment and to check that the three feeds agree on a sample of assets each quarter.

Evidence that shows Safeguard 1.5 is working

Safeguard 1.5 is measured by coverage: how much of the enterprise network is watched by a properly configured passive discovery tool, and whether the results reach the inventory at least weekly. The artifacts below connect those two checks, so each one should be dated and owned by a named person.

Discovery tool configuration baseline

Keep a versioned record of the passive discovery tool's settings, including which interfaces or mirror ports it listens on, which subnets it classifies as in scope, and how it stores and exports its findings. Assessors compare this record with what is running on the sensors. Export the configuration after each change, store it with the change ticket, and confirm the current copy matches the live system before every audit. Fields that drift silently, such as a removed mirror port, are the most common gap.

Network coverage map

Maintain a map that lists every network segment, the sensor or tap that observes it, and the date the coverage was last verified. Coverage is the measure for this Safeguard, so the map is the document an assessor will use to judge the share of networks covered. Reconcile it against the current architecture diagrams and against routing and VLAN records, since a new segment that appears in the network without appearing in the map is a coverage gap. Re-verify coverage after every network change.

Sensor placement records

Record where each sensor sits, which traffic it can see, and why that position was chosen. Placement records should show the switch, span port, tap or cloud flow source feeding each sensor, along with the owner who approved the position. Review them when the topology changes, and test visibility by confirming that known assets on each segment appear in the discovery output. Placement that looks correct on paper but sees no traffic will fail a coverage review.

Weekly review records

Keep a dated log of each weekly review of passive discovery results. Each entry should name the reviewer, the date, the number of newly observed assets, the number of assets that did not match the inventory, and any sensor that reported no data. Assessors check that the reviews happened at least weekly, so gaps in the log are visible. Use a shared ticket queue or a GLPI-style workflow so the record is created during the review, not reconstructed afterward.

Reconciliation tickets into the inventory

Each asset that discovery reports but the inventory lacks should produce a ticket that links the observed record to the inventory entry it created or corrected. The ticket shows what was found, who confirmed it, and the inventory change made. Keep these tickets linked to the Safeguard 1.1 inventory so the chain from observation to record is traceable. Unexplained observed assets that stay open for long periods are a signal that the process is not being run.

Uncovered segment register

List every segment the discovery tool cannot see, with the reason, a risk owner, a compensating method such as active discovery or DHCP logging, and a dated remediation plan. An honest register is stronger evidence than a claim of full coverage that an assessor can disprove. Review the register at each weekly cycle and close entries only when coverage is verified on the coverage map. Confirm the compensating method is documented in the Safeguard 1.3 and 1.4 records as well.

What meeting Safeguard 1.5 costs in money and effort

This table lists each cost component of running passive discovery for Safeguard 1.5, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for requesting a quote, since no prices are published here. The main takeaway is that licence spend is often the smallest line, while sensor placement and the weekly review carry most of the ongoing effort.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling or licences	Recurring if commercial, one-time setup otherwise	Commercial passive discovery products often price by sensor, network segment or monitored asset count. Self-hosted open-source options such as Suricata and Wazuh carry no licence fee, but the licence terms still apply (GPL-2.0-only for Wazuh, GPL-2.0-only for Suricata).	Confirm the licence terms with counsel before deployment, and ask vendors whether pricing is per sensor or per asset before comparing options.
Sensor hardware or switch port mirroring	One-time, with refresh cycles	Needs a sensor host or appliance on each monitored segment, and a SPAN or mirror port on switches or a tap where mirroring is not available. Encrypted or high-volume segments need more capacity.	Map segments first, then place sensors on the fewest segments that cover all networks. Reuse existing firewall or VM capacity where the platform allows it.
Engineering time for placement and configuration	One-time, with changes as the network grows	Time to identify traffic points, configure mirroring, tune protocol parsing, and exclude noisy or out-of-scope ranges. Safeguard 4.2 and Safeguard 12.4 inputs (secure configuration process and architecture diagrams) reduce this time when they exist.	Finish network architecture diagrams and the network infrastructure configuration process before scoping the work, so placement is not guessed.
Weekly review of discovery results	Recurring, at least weekly	Analyst time to review discovered assets, classify unknowns, and feed new devices into the asset inventory from Safeguard 1.1. The volume of new or unclassified devices drives the time.	Route results into an inventory tool such as GLPI so that known assets are matched automatically, and document the review steps so they can be done by more than one person.
Evidence upkeep	Recurring	Keeping dated scan reports, sensor configuration records, review sign-offs and coverage calculations current for each review cycle. The effort grows with the number of networks and sensors.	Store the evidence in one repository with a fixed naming pattern, and automate exports from the discovery platform where possible.
External review or consultant support	Usually one-time for design, optional recurring for reviews	Fees for an implementation partner to design the placement, configure the tools, and prepare the evidence. Scope depends on the number of networks and the existing documentation. Ask for a fixed-scope written quote.	Define the networks in scope and the deliverables in writing before work starts, and ask the partner to separate design, build and evidence tasks in the quote.
Auditor sampling and testing	Recurring with each assessment cycle	The auditor or assessor selects networks and dates to test coverage and review cadence. More networks and more review gaps increase sampling and follow-up work.	Keep a current list of networks, sensors and coverage gaps, and confirm the sampling approach with the auditor before the test window.

Who owns the discovery tool, who can help, and what the auditor checks

Your organization owns Safeguard 1.5. The control has to be operated by your staff, and no partner or auditor can take over the weekly review or the decisions that follow from it. Your team decides which networks the discovery tool must cover, approves the inventory changes it produces and keeps the records that show the process ran. Owning the control does not require building the tooling in-house, but it does require a named person who can answer for every cycle's results.

Scope decisions: Name the networks, VLANs and cloud segments the passive discovery tool must observe, and record the reason for excluding any segment.
Weekly review: Assign a named owner to review discovery results at least weekly and note what was reviewed, by whom and when.
Inventory reconciliation: Compare newly observed assets against the detailed asset inventory from Safeguard 1.1 and open a ticket for each unknown device.
Sensor health: Confirm the tool still sees traffic from every monitored segment, because a silent sensor can look like an empty network.

Check that the weekly review has a named owner, a dated record for every cycle and a documented path from an unknown asset to a removal or authorization decision.

Where passive discovery programs usually fall short

Passive discovery is only as good as its vantage points, its coverage record and the follow-up it drives. The gaps below appear again and again in programs that run a tool but cannot show that it sees the whole enterprise or that its output changes the inventory each week.

Sensors only on core switches

Many deployments tap a core switch or a single span port and assume that covers the enterprise. Traffic between devices on the same access switch, wireless segments and branch links may never cross that point. Check each network segment against a documented sensor placement, and ask which segments produce no observed traffic at all. Close the gap by mapping every segment to the sensor that observes it.

No coverage map

Assessors measure Safeguard 1.5 by the share of the enterprise's networks covered by properly configured passive discovery tools, so coverage has to be countable. Without a maintained list of networks, sensors and monitored interfaces, the organization cannot state its coverage or prove that a new subnet is included. The architecture diagrams called for under Safeguard 12.4 are a useful starting point. Close the gap by keeping a versioned coverage map tied to the network diagrams.

Weekly reviews not recorded

Safeguard 1.5 expects discovery results to be reviewed and used to update the inventory at least weekly. A review that happens informally in a meeting leaves no trace an assessor can sample. Teams often run the tool continuously but cannot show who reviewed the output, when, and what changed. Close the gap by logging each weekly review with the reviewer, date, findings and inventory changes.

Passive output never reconciled

Passive discovery finds devices that are talking on the network, and the inventory has to reflect them. When discovered assets are never compared with the inventory from Safeguard 1.1, unknown devices stay unknown and retired devices stay listed. Reconciliation should produce a clear list of new, missing and changed assets that feeds the unauthorized asset process in Safeguard 1.2. Close the gap by reconciling each weekly scan against the inventory and recording the differences.

Encrypted and segmented traffic

Passive tools infer assets from what they observe, so devices that rarely transmit, use encrypted sessions that expose little metadata, or sit behind segmentation boundaries can be missed. Quiet devices such as printers, sensors and standby equipment are common examples. Confirm which protocols the sensors can parse and which segments are isolated from the sensor's view. Close the gap by testing discovery against known quiet devices in each segment.

OT segments left out

Operational technology networks are often excluded from passive monitoring because of availability concerns, vendor restrictions or unclear ownership. Those segments hold controllers and engineering workstations that the inventory should record. Any exclusion should be a documented, approved scope decision rather than an oversight. Confirm with the OT owner whether passive observation is permitted and how it will be performed without disrupting the process. Close the gap by documenting each OT segment as in scope, or as excluded with an approved reason and owner.

Questions buyers ask about Safeguard 1.5

How much effort does passive asset discovery take to run?

The effort is mostly a one-time build followed by a recurring weekly review. The one-time work includes placing sensors or taps where traffic can be observed, tuning the tool so it classifies assets correctly, and connecting its output to the inventory from Safeguard 1.1. The recurring work is reviewing the discovery results at least weekly, deciding which newly seen assets are authorized, and passing unknown ones to the process in Safeguard 1.2. Effort rises with the number of network segments, the volume of traffic and the number of unmanaged or industrial devices that need manual classification. Ask any partner to break the estimate into setup tasks and recurring weekly tasks, and to name who performs each.

How long does setting up passive discovery take?

It depends on the number of network segments and how much access the team can get to them. Each segment needs a visibility point, and firewall change approvals, cabling, and access to switch mirror ports or network taps often set the pace more than the software does. A fixed-scope written plan sets the timeline: it lists the segments in scope, the deployment method for each, the acceptance tests and the handover date, and it is agreed before work starts. Ask for the plan to state which tasks depend on your change control and which are under the implementer's control.

Can our own team run passive asset discovery in-house?

Yes, if the team has network engineers who can place sensors, security engineers who can tune detection and an inventory owner who can review results every week. Many teams find the hard part is not installing a tool but maintaining the process: keeping the sensor placement correct as the network changes, handling devices that do not identify themselves clearly, and proving the weekly cadence with records. Teams that lack capacity often outsource the initial design, deployment and documentation, then keep the recurring review in-house. Confirm with your own staff what share of the network they can cover before you decide.

Does IG3 apply to our organization for Safeguard 1.5?

Safeguard 1.5 is assigned only to Implementation Group 3, so it applies in the CIS Controls framework when your organization falls into IG3. CIS defines IG3 as enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. Organizations below IG3 can still use passive discovery as good practice, but it is not the Safeguard they are measured against. Choose your Implementation Group by reviewing CIS's own IG definitions against your size, data sensitivity and threat exposure, and confirm the result with your customer, regulator or assessor if a contract refers to a specific group.

How does an auditor test passive discovery coverage?

The CIS Controls Assessment Specification measures Safeguard 1.5 by coverage: the share of the enterprise's networks covered by properly configured passive discovery tools. An assessor will typically ask for the network diagram and segment list, which come from Safeguards 4.2 and 12.4 as prerequisites, then check that each segment has a sensor or equivalent visibility point, that the tool configuration is documented, and that discovery results were reviewed and used to update the inventory at least weekly. Expect requests for dated review records and examples of newly seen assets that were investigated. Only an independent assessor or auditor reaches a conclusion; the implementation partner prepares the evidence.

What should we ask a partner for in a quote?

Ask for a written, fixed-scope proposal that lists the network segments in scope, the visibility method for each segment, the tool configuration to be delivered and the evidence it will produce. The quote should separate one-time work (design, deployment, tuning, documentation and handover) from recurring work (weekly review support, tool maintenance and updates), and state which tasks you must perform, such as approving change windows or providing switch access. Ask who performs each task, what acceptance tests prove coverage, what the timeline depends on, and how changes to the segment list after signing are priced. DeployOpen does not publish a price list; a quote follows from the written scope.

Open-source tools that support the Safeguard 1.5 evidence

None of the open-source tools below is a complete passive discovery tool by itself. Each can supply part of the evidence Safeguard 1.5 expects: GLPI can hold the inventory records that passive results update, Wazuh Syscollector can record what is installed and running on endpoints it manages, and OPNsense with Suricata can show which hosts are talking on the network. The assessor will still need to see a tool whose job is passive observation of the enterprise networks, with its configuration and its weekly output traceable into the inventory. Treat the stack as a set of feeds, not as the discovery control itself.

GLPI's Assets module is the natural home for the inventory records, since it manages computers, network equipment, printers and other items and can receive data from the GLPI Agent. Wazuh Syscollector adds host-level observations such as hardware, operating system, network interfaces and open ports for endpoints where the Wazuh agent is installed, which helps with Devices that a passive sensor on the network may see only indirectly. OPNsense Suricata alerts and Suricata EVE JSON output give network-side observations and log records that a passive review can cite. Confirm in your own environment which Suricata rulesets, EVE output types and log forwarding settings your sensors produce, and whether the GLPI Agent and Wazuh deployment cover every network segment in scope.

Licensing matters for the evidence file and for any redistribution. GLPI is licensed under GPL-3.0-or-later, Wazuh under GPL-2.0-only, and Suricata under GPL-2.0-only. OPNsense is licensed under BSD-2-Clause. Before you rely on any of these in a commitment to an assessor or a customer, check the license texts that ship with the version you deploy and confirm support terms with the vendor or community. Ask your implementation partner to document which component produced each piece of evidence, the configuration used, and the date each feed was last reviewed, so the auditor can trace a passive result from observation to inventory update.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and prepares the passive discovery setup and evidence that Safeguard 1.5 asks for. The organization owns its controls and its inventory, and an independent assessor reviews the evidence and draws its own conclusions.

How we scope

Confirm which networks, VLANs and segments the passive sensors must observe to cover the enterprise.
Record the Safeguard 1.4 DHCP and Safeguard 12.4 diagram inputs the measurement depends on, and where they live.
Agree in writing how often discovery results are reviewed and the weekly inventory update is recorded.

How we build

Deploy a passive discovery sensor on mirror or tap points so observed traffic feeds the inventory platform.
Configure GLPI or Wazuh inventory feeds and Suricata EVE JSON output so new assets appear without manual entry.
Test coverage per segment by comparing sensor-observed hosts against a known device list before handover.

How we hand over

Provide configuration records, network coverage maps and the sensor placement rationale for the assessor.
Deliver a weekly review procedure with a sample of dated discovery exports showing the inventory was updated.
Document unresolved gaps, such as segments without sensor visibility, so the organization can decide how to close them.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of the discovery setup are available as a retainer.
Ask any provider to confirm in writing which parts of the evidence they prepare and which the independent assessor must review.