Safeguard 13.3 Network intrusion detection: evidence

What CIS Safeguard 13.3 network intrusion detection asks for at IG2

Safeguard 13.3 asks an enterprise to deploy a network intrusion detection solution where appropriate, using a Network Intrusion Detection System (NIDS) or an equivalent cloud service provider service as the examples. It is an IG2 safeguard, so it applies to Implementation Group 2 and Implementation Group 3 enterprises, not to IG1. It is detect-only: it asks you to see suspicious network activity crossing your boundaries, not to block it. Blocking belongs to Safeguard 13.8 (network intrusion prevention), which sits at IG3. The risk it addresses is familiar to any assessor: an attacker who has got past the perimeter moves laterally between segments and talks to command-and-control infrastructure, and nothing on the network notices.

The difficulty is rarely the tool. The first decision is the boundary inventory: which network boundaries exist (internet edge, data center core, cloud virtual networks, partner links, branch and remote access paths) and which of them a sensor must cover. That list depends on the asset inventory in Safeguard 1.1 and the architecture diagrams in Safeguard 12.4, both of which the CIS Controls Assessment Specification (CAS) names as prerequisites. Sensor placement follows from that list, and it has to account for asymmetric routing and for traffic between segments that never reaches the edge. Encrypted traffic limits what a signature engine can see, so you should confirm, in your own environment, what visibility the sensor keeps for TLS sessions and where decryption is or is not in scope. Alert ownership is the last gap: an alert nobody triages does not satisfy the intent of the safeguard.

The CAS scores Safeguard 13.3 with a Coverage metric, the share of network boundaries covered by network intrusion detection solutions, so your boundary inventory is also your measurement baseline. The CIS Controls Navigator maps this safeguard to NIST SP 800-53 Rev. 5 controls AC-4(4), SI-4, SI-4(4) and SI-4(14), to ISO/IEC 27001:2022 Annex A controls 8.16 and 8.21, to AICPA SOC 2 criteria CC6.6 and CC7.2, and to PCI DSS v4.0 requirements 11.5.1 and 12.10.5. Use those mappings as a starting point for your evidence plan and confirm each one against the current Navigator entry, because an assessor will test against the framework text, not against a summary.

Where CIS 13.3 network intrusion detection applies in your environment

Safeguard 13.3 is measured against the network boundaries you declare, so the scope decisions below set the size of the work before any sensor is chosen. Each card is a decision or a check that changes what the assessor will compare your coverage against.

Map every network boundary

A boundary is any point where traffic enters or leaves a network you control. Start with the internet edge, cloud VPC or VNet edges, data center segments, and partner or vendor connections. The Coverage metric in the assessment specification is the share of these boundaries that have intrusion detection, so a boundary left off the list is either a gap or an undocumented exception. Agree the list with the network team before buying sensors.

Confirm the asset inventory first

The assessment specification lists Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite for measuring 13.3. Without it, you cannot show which network segments hold in-scope assets or prove that a boundary has no hidden subnets. Check that the inventory covers cloud accounts and remote sites, not only the data center, and record which network each asset sits behind.

Reconcile against architecture diagrams

Safeguard 12.4, the architecture diagrams, is the other prerequisite the assessment specification names. Diagrams show where boundaries actually sit. Compare them with the boundary list. Where a diagram shows a path that the list omits, such as a backup replication link or a management network, add it to scope or document why it is excluded. Diagrams that are years old are a common source of mismatched coverage claims.

Define in-scope data and systems

Decide which systems and data classes justify monitoring at each boundary, such as systems that process regulated personal data, payment data or identity services. Monitoring a boundary that carries no sensitive traffic still counts toward coverage, but the sensor placement and alert handling should follow the risk. Write the rationale down so an assessor can see why each boundary was prioritized.

Choose cloud-native or appliance sensing

Safeguard 13.3 accepts a NIDS or an equivalent cloud provider service. Cloud boundaries often suit a cloud-native traffic inspection service, while on-premises boundaries may need an appliance or a self-hosted sensor. A mixed estate needs one consistent alert format and one retention policy, otherwise the coverage evidence will be split across tools that do not report together. Confirm what each option inspects, since some only see flow metadata.

Assign owners for each boundary

Each boundary needs a named owner for sensor health, rule updates and alert triage. Ownership often splits between the network team, the cloud platform team and third parties that manage a provider link or a colocation site. Put these owners in writing against the boundary list. Where a third party runs a sensor, the contract should say what it monitors and how evidence is returned to you.

How assessors test CIS 13.3 network intrusion detection coverage

This table walks through each step an assessor takes to test Safeguard 13.3, from confirming the network boundary list to checking that detections are reviewed. Read it as a set of questions the assessor will ask and the evidence that answers each one, since the Assessment Specification defines what to measure but leaves the method to the assessor and the organization. The main takeaway is that the Coverage figure is only as defensible as its denominator, so the boundary list must be traceable to the asset inventory and architecture diagrams.

Test step	What the assessor requests	Evidence that passes	Common findings
1. Confirm the boundary list	The list of network boundaries, traced to the 1.1 asset inventory and the 12.4 architecture diagrams	A boundary register that maps each internet edge, cloud VPC or subnet, data center zone and partner connection to a diagram and to inventoried assets	Boundaries exist in diagrams but not in the list, or the list omits cloud accounts and remote access paths
2. Calculate the Coverage numerator and denominator	The total count of network boundaries and the count with a network intrusion detection solution	A dated calculation showing covered boundaries divided by total boundaries, with each sensor linked to the boundary it watches	Denominator is undocumented, sensors are counted without a boundary link, or the figure is computed once and never refreshed
3. Sample sensors for traffic	Live or recent evidence that sampled sensors receive mirrored, tapped or cloud-flow traffic	Interface statistics, packet counters or cloud flow log volume for each sampled sensor over a recent period	Sensor is deployed but sees no traffic because of a misconfigured span port, missing cloud flow source or asymmetric routing
4. Sample alert generation	Proof that signatures or rules fire on test or benign trigger traffic and produce alerts	Test alert records, rule versions and timestamps from a controlled test, such as an IDS test signature or a documented test event	Rulesets are enabled but outdated, or no test has ever produced an alert, so detection is unproven
5. Check alerts reach a monitored destination	The path from each sensor to the central log or SIEM and the people or queues that receive alerts	Forwarding configuration, such as syslog or EVE JSON export settings, and a SIEM record showing the sensor alert arrived	Alerts stay on the appliance, forwarding breaks silently, or alerts go to a mailbox nobody reads
6. Check that detections are reviewed	Triage records, ticket samples and the review cadence for network intrusion alerts	Tickets or case records with timestamps, owners and dispositions for a sample of alerts, plus a documented review schedule	Alerts accumulate with no disposition, or reviews happen informally with no record
7. Confirm the method is defensible	The written method for counting boundaries and sampling sensors	A short method note stating the boundary definition, the sampling approach and the source of each count, reviewed by the control owner	Method is verbal only, so the assessor cannot reproduce the Coverage figure

Deploying network intrusion detection in a sequence that produces coverage evidence

This sequence moves Safeguard 13.3 from a stated intent to a documented, inspectable state: named network boundaries, sensors placed where traffic is visible, alerts flowing to the logging platform, and a first coverage calculation the assessor can trace back to source records. Each step closes with a document or export that becomes part of the evidence set.

Confirm the network boundary list
Start from the detailed enterprise asset inventory (Safeguard 1.1) and the architecture diagrams (Safeguard 12.4), which the assessment specification lists as prerequisites for measuring 13.3. The network team identifies every point where traffic crosses into or out of a network segment, including internet egress, partner connections, cloud virtual networks, data center interconnects and remote access entry points. The output is a dated boundary register that names each boundary, its owner and the diagram it appears on. The step is complete when someone outside the team can trace every boundary back to a diagram and an inventory entry.
Choose sensing for each boundary
For each boundary in the register, record the sensing approach: an on-premises network intrusion detection system, a virtual sensor inside a cloud network, or a cloud service provider's detection service. The choice depends on where traffic can be observed, whether the boundary is encrypted end to end and what the platform team can operate. Where no sensing is chosen, the record states why and who accepted the gap. The output is a sensing decision table linked to the boundary register, which shows that the 'where appropriate' judgment in 13.3 was made deliberately and by a named owner.
Place sensors and prove traffic visibility
Deploy each sensor so it receives a copy or mirror of the traffic that crosses its boundary, using a span port, tap, virtual mirror or cloud traffic capture feature, depending on the sensing choice. Before any rules are tuned, confirm visibility with test traffic and a short capture on the sensor interface, and check that the sensor sees both directions of the flow. The output is a placement record per sensor with its interface, the traffic source and the result of the visibility test. Without this record, a later coverage figure can look complete while the sensor sees nothing.
Route alerts to the logging platform
Configure each sensor to send its alert records to the centralized alerting platform used for Safeguard 13.1, so detection events are correlated with other security data rather than left on the sensor. Where the sensor writes structured output, such as Suricata's EVE JSON records, decide which record types are forwarded and where they are stored. Send a test alert through each path and confirm it arrives with the sensor identifier and timestamp intact. The output is a log routing configuration export and a test record showing end-to-end delivery.
Set initial rulesets and suppressions
Enable a baseline ruleset appropriate to each sensor and document its source, version and update schedule. Record every suppression or disabled rule with a reason and an approver, so that a reduced alert volume can be explained later. Confirm that the sensor is in detect-only mode as 13.3 requires, since prevention belongs to 13.8 at IG3. The output is a ruleset inventory per sensor, a suppression register and a change record for the initial configuration. Tuning cadence belongs to the later review step and Safeguard 13.11.
Document ownership and review cadence
Name an owner for each sensor, a secondary for coverage gaps and the person who reviews alert volume and suppressions. Write down how often the ruleset is updated, how often the boundary register is checked against new diagrams and inventory changes, and who signs off on a new boundary being added or removed. The output is a short detection operating procedure with a responsibility table and a review schedule. The assessor will look for this document to confirm that coverage is maintained after the first measurement, not only achieved once.
Produce the first coverage calculation
The assessment specification measures 13.3 with a Coverage metric: the share of network boundaries covered by network intrusion detection solutions. Divide the number of boundaries in the register that have a verified, detect-only sensor with routed alerts by the total number of boundaries, then list every uncovered boundary with its documented reason. Keep the inputs, the arithmetic and the date of the calculation in one file. The output is a dated coverage workbook with a per-boundary table that an assessor can re-perform from the register and the placement records.

Evidence that passes a 13.3 coverage review and how to keep it current

A coverage review for Safeguard 13.3 tests whether the network boundaries you claim are actually watched by intrusion detection. The six artifacts below connect: the boundary register defines the denominator, the deployment records and alerts prove the sensors work, and the diagram and tuning log show the picture stays accurate as the network changes.

Boundary register with coverage status

A list of every network boundary in scope, such as internet egress, partner links, cloud VPC edges, data center zones and remote access concentrators, with a column showing whether a network intrusion detection solution covers it. The Coverage metric in the assessment specification is a share, so the register is the denominator and the reviewer will ask how it was built from the asset inventory (Safeguard 1.1). Keep it current by updating it whenever a boundary is added, retired or re-routed, and reconcile it against the architecture diagram at each review.

Sensor deployment records or cloud configurations

Proof that each sensor on the boundary register exists and is running. For an on-premises NIDS, this means the host or appliance record, the interface or SPAN/mirror source, and the rule set version. For a cloud provider service, export the configuration showing the service is enabled in each account and region that hosts a boundary. Check that deployment records match what is actually running, not what was planned. Export configurations on a schedule you can defend, or after every change that touches a boundary.

Sample alert records with timestamps and destinations

Representative alerts from the detection platform that show signatures or anomaly rules firing on real traffic, with timestamps, source and destination addresses, and the place the alert was delivered, such as a SIEM index used for Safeguard 13.1 correlation. A reviewer uses these to confirm that detection reaches a person or system that acts on it. Where a rule set is open source, record which rule source and version produced the alert. Pull a sample from each boundary, not only the busiest one, and store it with the query used to retrieve it.

Traffic visibility test results

Records of tests that send known-benign or simulated malicious traffic across each boundary and confirm the sensor sees it. Examples include a test string passing egress, a scan from a controlled host, or a synthetic alert triggered on a segment. The test shows whether a sensor is blind due to asymmetric routing, encrypted traffic it cannot inspect, or a mirror port that dropped. Document the test steps, the expected and observed results, and the remediation for any gap. Repeat the tests after network changes, since a routing change can silently remove visibility.

Review and tuning log

A dated record of who reviewed intrusion detection alerts, which rules were disabled, added or tuned, and why. Reviewers look for evidence that noisy rules were adjusted rather than silenced, and that exceptions have an owner and an expiry. This log also links to Safeguard 13.11, which asks for alert threshold tuning at least monthly at IG3. Record each change with its ticket reference so the trail from a finding to a rule decision can be followed.

Current architecture diagram

A diagram of the network showing each boundary, where each sensor sits, the direction of traffic inspected, and any segments that are out of scope. Safeguard 12.4 is a prerequisite for measuring 13.3, so the reviewer will compare the diagram with the boundary register and the deployment records. Mismatches, such as a new cloud subnet absent from the diagram, are a common reason coverage claims fail. Assign an owner for the diagram and tie updates to change approvals so it reflects the network as it is.

What CIS 13.3 network intrusion detection costs to meet

This table compares the cost components of meeting Safeguard 13.3, grouped by who is paid, whether each cost is one-time or recurring, and what moves it up or down. Read it as a checklist for a quote: each row names a line item to ask about in writing. No public price exists for this work, so the main takeaway is that the largest recurring costs are usually staff time and log storage, not the sensor itself.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Sensor or cloud IDS licensing	Recurring	Commercial engine, rule subscriptions and the number of monitored boundaries. A self-hosted Suricata path removes engine license spend.	Confirm which engine and rulesets are licensed and whether open-source options meet the Coverage requirement.
Sensor hardware or cloud compute	One-time for hardware, recurring for cloud compute	Traffic volume at each boundary, inspection depth and whether sensors run on-premises or in cloud accounts.	Size sensors to measured peak throughput and place them only at boundaries the asset inventory and architecture diagrams identify.
Engineering time for boundary mapping and placement	One-time, with revisits after network changes	Number of network boundaries, the quality of the Safeguard 1.1 inventory and the Safeguard 12.4 architecture diagrams, and how many segments are undocumented.	Start from current diagrams and the asset inventory so mapping is verification rather than discovery.
SIEM or log storage for alert volume	Recurring	Alert and EVE JSON event volume, retention periods and whether protocol transaction records are stored in full.	Split EVE output into separate files, store alerts in full and keep verbose transaction logs for shorter periods.
Ruleset tuning and review time	Recurring	Number of enabled rules, false positive rate and how often rulesets are updated and reviewed against the environment.	Enable only rulesets that match the environment and record each suppression with a reason.
Evidence upkeep	Recurring	Frequency of Coverage measurements, the number of boundaries to document and how many systems feed the evidence pack.	Automate Coverage reports from the asset inventory and keep a single dated record of sensor placement.
External review or testing	Periodic, usually one-time per assessment cycle	Scope of the assessment, whether an independent auditor tests sensor placement and whether a separate detection test is run.	Agree the scope in writing and prepare placement evidence before the assessor arrives. Only the independent auditor issues the assessment result.

What your team keeps, what a partner can take and what the auditor decides

Your organization owns Safeguard 13.3. The assessment specification measures whether network intrusion detection covers your network boundaries, so the people accountable for that coverage must be named inside your organization, even when external staff build the sensors. Decisions about where detection is appropriate, which network boundaries are in scope and what counts as an acceptable gap belong to your security leadership and are recorded as risk decisions.

Boundary decisions: Decide which network boundaries require detection, using your asset inventory and architecture diagrams, and record why any boundary is excluded.
Alert ownership: Assign a team that triages NIDS alerts, sets escalation paths and connects alerts to the incident process in Control 17.
Rule and threshold governance: Approve ruleset sources, change requests and suppression decisions, so tuning is traceable to a person.
Risk acceptance: Document the residual risk for uncovered segments, legacy systems or cloud services where a sensor is not practical, signed by an accountable owner.
Prerequisite upkeep: Keep the asset inventory (Safeguard 1.1) and architecture diagrams (Safeguard 12.4) current, since the assessment treats them as prerequisites.

Confirm that a named owner can explain your coverage figure and the open risk decisions without relying on the partner.

Where 13.3 coverage scores usually fall short and how to close each gap

The Coverage metric for Safeguard 13.3 counts the share of network boundaries watched by intrusion detection, so the score is only as honest as the boundary list and the sensor placement behind it. The gaps below recur in assessments because they come from inventory drift, routing changes and neglected configuration rather than from missing products.

Incomplete boundary list

The denominator of the Coverage metric is the set of network boundaries, and it is often drawn from the office network alone. Cloud accounts, partner interconnects, VPN pools and remote or branch segments are frequently missing, which inflates the score without any sensor change. Build the list from the architecture diagram that Safeguard 12.4 calls for and the asset inventory from 1.1, then check each cloud account and partner link by name. Close the gap by signing off the boundary list with the network owner each review cycle.

Sensors blind after routing changes

A sensor placed on a span port or tap at deployment may see no traffic once a firewall is replaced, a VLAN is re-homed or a cloud route table changes. The sensor keeps reporting as healthy while it observes nothing, so the boundary still counts as covered. Compare sensor traffic counters with expected flow volumes after every network change, and test each boundary with a benign generated signature. Close the gap by making a test signature part of every change ticket that touches a monitored boundary.

Alerts routed to nowhere

Detection only reduces risk when someone reads the alert. Many deployments send intrusion alerts to a shared mailbox, an unmonitored syslog target or a dashboard nobody opens outside business hours, and the sensor still counts as operating. Confirm which system receives each alert stream, who acknowledges it, and what happens when that path fails. Route alerts into the central alerting platform from Safeguard 13.1 so that they are triaged alongside other security events. Close the gap by naming an owner and a monitored queue for every alert source.

Encrypted traffic blind spots

Most network sensors cannot inspect content inside TLS sessions, so an attack carried over HTTPS to an allowed destination may produce no content-based alert. Placement matters here: sensors at points where traffic is unencrypted, such as before a load balancer terminates TLS, see more. Endpoint telemetry from host-based detection under 13.2 can cover the gap for hosts that the network sensor cannot see into. Document which flows are opaque and which compensating control covers each one. Close the gap by recording every encrypted segment as a known blind spot with a named compensating control.

Rulesets never reviewed

Signature sets from vendors and community feeds change constantly, but many deployments enable a ruleset once and never revisit it. Stale rules miss new techniques, and noisy rules bury real alerts, which pushes staff to disable them. Track the ruleset source, version and last update date, and review enabled categories against your actual protocols and assets. For Suricata-based sensors such as the one in OPNsense, the EVE JSON alert records give the evidence for which rules fire. Close the gap by scheduling a documented ruleset review and recording each update.

Coverage calculated once

The Coverage score is often computed for the first assessment and then copied forward. Each new subnet, cloud account, acquisition or decommissioned segment changes the denominator, and a static figure stops reflecting the environment. An assessor will ask for the calculation date, the boundary list at that date and the sensors that cover it. Recalculate the score whenever the architecture diagram or asset inventory changes, and keep dated copies. Close the gap by tying the Coverage calculation to the change process rather than the audit calendar.

Questions buyers ask about CIS 13.3 cost, effort and outside help

How much effort does CIS Safeguard 13.3 take, and what drives it?

The effort depends mainly on how many network boundaries you have and how well they are documented. No figure for effort is supplied here, so ask any provider for a written estimate built on your environment. The main drivers are the number of internet edges, data center and cloud network boundaries, and branch or partner links that need sensor coverage. The work also depends on the state of your prerequisites. The assessment specification lists asset inventory (1.1) and architecture diagrams (12.4) as prerequisites, so an organization without current diagrams will spend time building them first. Sensor placement, rule tuning, log routing to a SIEM under 13.1, and the ongoing review of alerts are recurring effort that continues after the initial deployment.

Do IG1 organizations have to deploy network intrusion detection?

No. Safeguard 13.3 is assigned to Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 covers essential cyber hygiene and a minimum baseline for every enterprise. An IG1 organization can still choose to deploy network detection voluntarily, and that choice may help with other frameworks or contractual requirements, but the CIS Controls do not require it at that level. Confirm your Implementation Group in the CIS Controls documentation before scoping this safeguard into a project.

Does a cloud provider intrusion detection service satisfy Safeguard 13.3?

It can. Safeguard 13.3 names a Network Intrusion Detection System or an equivalent cloud service provider service as acceptable approaches. What matters for the assessment is whether the service observes traffic crossing your network boundaries and produces alerts you review. Before relying on one, confirm which traffic it sees, which boundaries it covers, whether its alerts reach your central alerting, and how long its logs are retained. A cloud service that only covers one account or region will leave other boundaries outside the measured coverage, so inventory every account and network before concluding the requirement is met.

What does the Coverage metric for 13.3 measure, and how do you calculate it?

The Coverage metric measures the share of network boundaries covered by network intrusion detection solutions. In practice, count every network boundary in your architecture, then count the boundaries where a detection sensor or cloud detection service is active and monitored. Divide the covered count by the total count and express the result as a percentage. The denominator depends on the quality of your asset inventory and architecture diagrams, so gaps in those records will distort the result. Document the list of boundaries, the method used to count them, and the date of the calculation, because an assessor will look for that record as evidence.

Is Safeguard 13.3 the same as network intrusion prevention?

No. Safeguard 13.3 is a detect-only safeguard. It requires that intrusion detection is in place so suspicious traffic is seen and alerted on. Blocking or stopping that traffic is a separate requirement, Safeguard 13.8, which applies at IG3. Some products can operate in either mode, so an organization may run detection now and enable prevention later. Be clear with your assessor about which mode is active, because a detection-only sensor satisfies 13.3 but does not satisfy 13.8.

How do the Navigator mappings to NIST, ISO, SOC 2 and PCI DSS relate to 13.3 evidence?

The CIS Controls Navigator maps Safeguard 13.3 to several external controls: NIST SP 800-53 Rev. 5 controls AC-4(4), SI-4, SI-4(4) and SI-4(14), ISO/IEC 27001:2022 Annex A controls 8.16 and 8.21, SOC 2 criteria CC6.6 and CC7.2, and PCI DSS v4.0 requirements 11.5.1 and 12.10.5. These mappings show where one body of evidence may be reused, such as sensor configuration, alert records and review logs. They do not mean a single record satisfies every framework. Each assessor decides independently whether your evidence meets its own test, so confirm the mapping with the assessor and the Navigator before you rely on it.

What does the work need from our team?

The work needs named owners on your side for several inputs. You will need access to network architecture diagrams and the asset inventory, since 1.1 and 12.4 are prerequisites. You will need change approval for placing sensors, access to firewall or cloud network configuration, and an alerting destination such as your SIEM. Your security team must agree who reviews alerts, how false positives are handled, and how detection gaps are logged. A written scope should list each of these inputs, the systems involved and who signs off on each stage before work begins.

Can we implement Safeguard 13.3 in-house, or do we need an outside partner?

Many organizations can do it in-house if they have network engineers, a monitored alerting platform and time to maintain the sensors. An outside partner is useful when the team lacks capacity, when the environment spans several clouds or sites, or when the organization wants a fixed-scope deployment and documented evidence set. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts. The organization still owns its controls, and only an independent auditor or assessor issues any report or certification. Compare an in-house estimate against a written proposal before deciding.

How DeployOpen scopes, deploys and prepares evidence for CIS 13.3

DeployOpen approaches Safeguard 13.3 as a detect-only network deployment inside the client's own infrastructure, starting from a written scope. We plan, implement and document the network intrusion detection setup and prepare the evidence an assessor would review, while the organization keeps ownership of its controls.

How we scope

Confirm which network boundaries exist and which ones must be covered by intrusion detection for the Coverage measure.
Check the prerequisites for 13.3, including the enterprise asset inventory (1.1) and architecture diagrams (12.4), before any work starts.
Record the agreed scope, deliverables and timeline in writing, since most engagements are fixed-scope.

How we build

Deploy a NIDS or an equivalent cloud provider service at each agreed network boundary, inside the client's cloud accounts, data centers or air-gapped networks.
Configure detection rules, alert destinations and EVE JSON output so alerts can reach the centralized alerting set up under 13.1.
Test that detection fires on known benign test traffic and that coverage matches the documented boundary list.

How we hand over

Document the boundary inventory, sensor configuration, rule sources and alert routing so the organization can explain each measured item.
Provide a coverage record showing which network boundaries are monitored, which the assessment specification's Coverage metric uses.
Hand over runbooks and the evidence set. Only an independent auditor or assessor can issue any report or certificate.

How we support

Support upgrades, rule updates and sensor maintenance under a retainer if the organization wants continuing help after handover.
Review coverage when network boundaries change, such as new cloud accounts or segments, and update the documented record.
Confirm with the client's own assessor which evidence format and retention period they expect before the handover is finalized.