Safeguard 13.6 Network traffic flow logs

What CIS Safeguard 13.6 network traffic flow logs require

Safeguard 13.6 asks the enterprise to collect network traffic flow logs, or the network traffic itself, from its network devices so that the records can be reviewed and alerted on. In CIS Controls v8.1 it sits in the Network asset class under the Detect security function and belongs to Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. An IT or security lead who must show an assessor that traffic is logged at the boundary should expect the assessment to start with one question: which devices sit on the network boundary, and does each one export flow records that someone can read. The Coverage metric in the CIS Controls Assessment Specification scores the share of those boundary assets that are configured to log traffic flow or traffic, so the answer is a count against a defined list, not a general statement about logging.

The risk this Safeguard addresses is a blind spot. Lateral movement between internal hosts, data leaving through unexpected destinations and command-and-control traffic from compromised systems often leave no trace in endpoint or application logs. Flow records from firewalls, routers and virtual network gateways show who talked to whom, on which port and in what volume, which lets analysts spot those patterns and lets alerting rules fire on them. Flow logs are a telemetry source for Control 13, not a detection capability on their own. They show that communication happened; they do not inspect payloads or prove malicious intent. Intrusion detection under Safeguards 13.2 and 13.3 and centralized alerting under 13.1 are what turn that telemetry into findings.

Four problems make this Safeguard hard in practice. The first is an unclear boundary: the team must agree which interfaces, segments and cloud network edges count as the boundary, and the Safeguard depends on the enterprise asset inventory (Safeguard 1.1) and the architecture diagrams (Safeguard 12.4) to define that list. The second is devices that cannot export flows, which may need replacement, a different export method or a documented exception. The third is volume and retention: the team must decide what is sampled, what is kept and for how long, and confirm that storage and the SIEM can handle the load. The fourth, and the most common, is ownership. Someone must be named to review and tune the records, and the review must be evidenced. Confirm these four points with your own environment before you commit to a tooling choice.

Which network boundary assets fall under CIS Safeguard 13.6

Safeguard 13.6 is measured as a coverage share of network boundary assets, so the scope decision determines both the size of the work and the denominator an assessor will check. The cards below cover the boundary devices to include, the implementation group question, and how the prerequisites from Controls 1, 4 and 12 define the list.

Internet edge devices

Internet-facing firewalls, routers, load balancers and reverse proxies are the most common core of the boundary list. Each one that passes traffic between an external network and the enterprise should be treated as in scope for Safeguard 13.6 and must be able to export flow records or network traffic. Confirm the list against the external address ranges your registrar and cloud accounts actually expose, not only against the device names in the network team's spreadsheet. A device missing from the list is a gap the assessor can find by comparing the list to the perimeter.

Data center core and segment gateways

Core switches, distribution layers and the routers or firewalls that gate each network segment sit on the boundary between trust zones inside the enterprise. Where Safeguard 13.4 segments the network, the gateway between segments is usually the point where flow data is most useful for detection. Use the architecture diagrams from Safeguard 12.4 to identify every segment boundary, then decide which devices export flows for each one. Record the decision for each boundary so the coverage figure can be reproduced.

Cloud virtual network boundaries

Virtual private clouds, virtual networks and their gateways, peering links and transit routers form boundaries that do not appear on a physical rack diagram. Include each VPC or virtual network edge that carries traffic into or out of a workload environment, and confirm which provider-native flow logging feature covers it. Flow logs must be enabled per network or subnet in most cloud platforms, so an account-level assumption can leave gaps. Keep the cloud network inventory under Safeguard 1.1 in step with the boundary list.

VPN concentrators and remote access gateways

VPN concentrators, zero trust access proxies and remote desktop gateways are where outside users and devices enter the internal network, so they are high-value boundary assets for Safeguard 13.6. Include every device that terminates remote sessions, even if it is a virtual appliance or a service running on a general server. Check that flow or session records capture the source identity or address, the internal destination and the time, because these fields are what the Coverage metric would look for in the logs. Tie this list to the remote access controls under Safeguard 13.5.

Prerequisites that define the list

The assessment specification treats Safeguards 1.1, 4.2 and 12.4 as prerequisites for measuring 13.6. In practice, the asset inventory from 1.1 supplies the candidate devices, the secure configuration process from 4.2 confirms that each device's logging settings are controlled, and the architecture diagrams from 12.4 show which devices sit on boundaries. A boundary device that is absent from any of the three sources should be investigated before the Coverage figure is calculated. Ask the team to show how the three records were reconciled at the last review.

Third-party and cloud-hosted boundaries

Boundaries run by a managed service provider, colocation operator or cloud provider may generate flow data that the enterprise cannot configure directly. Before counting such a boundary as covered, confirm in writing which flow or traffic records the provider can export, the retention period, how the enterprise receives the data, and who is responsible for enabling and maintaining the feature. If the provider cannot supply the records, the boundary still belongs in the denominator and the gap must be recorded. Contract terms under Control 15 are the natural place to put these commitments.

How an assessor tests CIS Safeguard 13.6 flow log coverage

This table walks through the questions an assessor works through when measuring the Coverage metric for Safeguard 13.6, from the boundary asset list to logs that reach a reviewer. Read each row as a step the organization should be ready to show with its own method, because the Assessment Specification defines what to measure but not how to measure it.

Assessment step	What the assessor checks	What the organization should show
Denominator: boundary asset list	Whether the list of network boundary assets is complete and traceable to the enterprise asset inventory (1.1) and the architecture diagrams (12.4).	A documented boundary definition, the asset list with identifiers, and a reconciliation showing how boundary devices map to inventory and diagram entries.
Prerequisite: configuration process	Whether network infrastructure is configured under a secure configuration process (4.2), so logging settings are not left to individual administrators.	The approved configuration baseline for boundary devices and the change records showing flow logging was enabled under it.
Sampling of devices	Whether the assessor can select a representative set of boundary assets and test each one, including firewalls, routers, cloud gateways and virtual network appliances.	Your sampling method, the sample chosen, and the reason it covers each device type and location. Confirm the approach with your assessor before testing.
Configuration exports	Whether each sampled device is set to send network traffic flow or traffic records, and to which collector or destination.	Dated configuration exports or screenshots for each sampled device, with the logging or flow export settings visible.
Evidence of collection	Whether records from each sampled device arrive at the central log platform (13.1 or a log store) within a period the organization defines.	Log query results or receiver statistics per device for a stated time window, showing records are present and recent.
Evidence of review and alerting	Whether someone reviews flow data or whether alert rules use it, as the safeguard asks for review and alerting.	Alert rule definitions that use flow data, review records or ticket samples, and the named role responsible for review.
Common finding: incomplete boundary list	Devices that handle north-south or partner traffic appear on the diagram or in the cloud console but not on the boundary list.	Periodic reconciliation between cloud account listings, network diagrams and the boundary list, with exceptions recorded and closed.
Common finding: logging without a receiver	A device is configured to export flow data, but the collector is retired, misnamed or unreachable, so nothing is stored.	Receiver health checks and alerts for silent sources, plus evidence that a sampled device's records were received.

How to implement Safeguard 13.6 in sequence

This sequence takes the network boundary assets from the inventory and architecture diagrams to a documented flow log stream that is reviewed, alerted on and measured with the Coverage metric. Each step produces an artifact an assessor can inspect.

Confirm the boundary asset list
The network team starts from the Safeguard 1.1 asset inventory and the Safeguard 12.4 architecture diagrams to list every network boundary asset that should produce flow logs or traffic records, such as perimeter firewalls, routers, VPN concentrators and cloud virtual network edges. Each entry is tied to a diagram zone and an owner. The step is done when the list is approved by the asset owner and every boundary device in the diagrams appears on it or has a documented reason for exclusion.
Select the flow source for each device type
For each boundary asset, the engineering team records which telemetry source the device supports, such as NetFlow, IPFIX, sFlow, a firewall traffic log, a cloud flow log service or a Suricata EVE JSON stream on an open-source gateway. The choice is confirmed against the vendor documentation or the platform's own configuration reference, because support varies by model and version. The output is a table mapping each asset to its source and format, reviewed by the security team.
Enable export and point it at a collector
Administrators enable flow or traffic export on each boundary asset and direct it to a collector inside the organization's own infrastructure, such as a flow collector or a syslog receiver. Changes go through the normal change process and the secure configuration baseline from Safeguard 4.2. The step closes when each device shows as sending records to the collector and a test flow appears in storage, with the change ticket linked to the asset entry.
Set retention and time synchronization
The logging team sets how long flow records are kept and confirms that every boundary device and the collector use a common, trusted time source so events can be correlated. Retention is set against the organization's own policy and any contractual or regulatory requirement it must meet, which the organization should confirm with its compliance lead. The output is a retention setting per log store and a time sync check showing the offsets on each source.
Connect the stream to centralized alerting
The security engineering team forwards the flow and traffic stream into the centralized alerting platform from Safeguard 13.1, whether a SIEM or a log analytics tool, and builds parsing rules and at least one correlation rule that uses the data. Where an intrusion detection sensor such as Suricata runs, its EVE output is split into separate files so flow records can be handled on their own. The step is complete when a sample event from each source is searchable and a test alert fires as designed.
Define review and alert ownership
The security operations lead names who reviews the flow data, who receives each alert type, and what happens out of hours. The ownership record includes the escalation path into the incident response process and the review frequency the organization chooses. The output is a written roster or runbook section, approved by the security lead, that a reviewer can follow without asking the author.
Record the Coverage calculation
The assessment owner calculates the Coverage metric from the Safeguard 13.6 assessment specification: the share of network boundary assets properly configured to log network traffic flow or traffic. The numerator and denominator come from the approved asset list in step one, and each asset's status is supported by the export configuration and a test record. The result, its date and the supporting screenshots or configuration exports are stored as evidence. Any gap is logged as a finding with an owner and a closure date.

Evidence that shows CIS Safeguard 13.6 flow logging is working

An assessor testing Safeguard 13.6 looks for proof that every network boundary device exports traffic records, that those records are retained and that someone uses them. The cards below cover the artifacts that connect the boundary inventory, device configuration, sample records, the Coverage metric, alerting and retention, and how to refresh each one between audits.

Boundary asset register

This register lists every network boundary device in scope, traced back to the enterprise asset inventory under Safeguard 1.1 and the architecture diagrams under Safeguard 12.4. It is the denominator source for Coverage, so each row should name the device, its role and its owning team. Check that no boundary device appears in the diagrams but is missing from the register. Refresh the register on every change to firewalls, routers or cloud network edges, and review it at least quarterly with the inventory owner.

Device configuration exports

Export the flow or traffic logging configuration from each boundary device and keep the files with a date and device name. The assessor needs to see that traffic export is enabled and points to the collector, not only that a platform team says it is. Exports from firewalls and intrusion detection engines, such as the EVE JSON output enabled in OPNsense, should show the destination and the record types. Schedule a monthly export, and export again after any firmware upgrade or rule change because upgrades can reset settings.

Sample collected records

Pull a sample of records from each boundary device for a recent window and confirm each one carries a timestamp, source and destination, and the protocol or flow identifiers. Check that the timestamps are synchronized across devices so the records can be correlated during an investigation. Keep the samples as read-only extracts with the query used to retrieve them. Repeat the sampling each quarter, and take a fresh sample after any change to the collector.

Coverage calculation

Coverage is the share of network boundary assets properly configured to log traffic flow or network traffic, so the artifact is a worked calculation with a numerator and denominator that match the register. The numerator counts devices whose export configuration and recent sample both pass. The denominator counts every device in the register. Record any device excluded from scope and the reason, because an assessor will ask. Recalculate the figure whenever the register or the sampling results change, and store each version with its date.

Alert rules and review tickets

Flow logs only satisfy the intent of Safeguard 13.6 when someone reviews them or alerts on them. Keep the detection rules that consume flow data, such as correlation rules in the centralized alerting platform, and a sample of tickets or review notes that show analysts acting on those alerts. Record who reviewed each item and what they decided. Review the rule set on a fixed schedule and attach the change record whenever a rule is added, tuned or retired.

Retention settings

Document how long flow records are kept, where they are stored and who can delete them. Retention should be set in the log platform and in any local buffer on the device, and both settings should appear in the evidence. Confirm that archived records remain searchable for the investigation window your incident response plan requires. Export the retention configuration with each quarterly review, and update the document whenever storage capacity or the retention policy changes.

What meeting CIS Safeguard 13.6 costs in money and effort

This table breaks the cost of meeting Safeguard 13.6 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no price or duration for this Safeguard is published in the supporting facts. The main takeaway is that open-source tooling removes license spend but not the engineering, storage and review effort that the evidence requires.

Cost component	One-time or recurring	Who is paid	What drives it up or down
Collector and storage tooling or licenses	Recurring if commercial; one-time setup for open source	Software vendor, or the implementer for open-source deployment	Commercial per-volume licensing rises with traffic; self-hosted collectors such as Suricata EVE output or flow exporters remove license spend but keep hosting cost
Engineering time to enable export on each device type	One-time per device model, with recurring work when firmware changes	Internal engineers or the implementation partner	Number of boundary devices, device vendor support for NetFlow, IPFIX, sFlow or mirrored traffic, and how many firmware versions are in use
Log storage and retention capacity	Recurring	Infrastructure team or cloud provider	Traffic volume, retention period set by policy, and whether logs sit on-premises or in cloud storage billed by volume
Review and alert tuning effort	Recurring	Security operations staff or a managed service provider	Alert volume from flow and IDS data, number of analysts, and how often detection rules are reviewed and tuned
Evidence upkeep	Recurring	Compliance lead and system owners	Number of boundary assets in the Coverage measure, frequency of configuration exports, and how well asset inventory and architecture diagrams (Safeguards 1.1 and 12.4) are kept current
External review or testing	Recurring or periodic	Independent assessor or testing firm	Scope of testing, whether an outside party reviews flow log configuration, and whether the review covers the network boundary only or wider segments
Auditor sampling	Recurring per assessment cycle	Independent auditor or certification body	Number of assets sampled, how many periods of logs the auditor asks to see, and how quickly the organization can produce them
Ask in the written quote	Not applicable	Implementation partner	Itemized device list, traffic estimate, retention period, licensing model, hours per device type, and which evidence artifacts are delivered

Which open-source tools can produce flow and traffic evidence

Safeguard 13.6 is measured by how many network boundary assets log traffic flow or traffic, so the tools you choose must produce records you can keep, review and export. The cards below cover one network telemetry source and two application audit trails that complement it. Network records show what crossed the boundary, while application audit trails show what users and administrators did inside a system.

OPNsense IDS and IPS logging

OPNsense's built-in intrusion detection and prevention system runs Suricata with rulesets such as Emerging Threats and Abuse.ch, and it can send alerts to syslog in EVE JSON format. For Safeguard 13.6, this gives you alert records from boundary traffic that you can forward to a collector. Confirm which interfaces the IPS inspects, whether it runs in detection or blocking mode, and whether the syslog target receives the records you need for review. OPNsense is licensed under BSD-2-Clause, so you can deploy and modify it without copyleft obligations.

Suricata EVE JSON output

Suricata's EVE output writes JSON records for alerts, flows and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, plus file information, dropped packets and engine statistics. Flow and transaction records are the closest match to the traffic flow logs that Safeguard 13.6 describes. Separate files can be written for each record type, which helps log management tools ingest them. Suricata is licensed under GPL-2.0-only, so confirm with your legal team what that license means for any modifications you distribute and how it applies to your deployment.

Nextcloud admin audit logging

Nextcloud's admin_audit app logs additional event information to audit.log in the data directory, or to a path set with logfile_audit. This is an application-level trail of administrative actions, such as configuration changes and access events, which is useful evidence for Safeguard 13.6 review only as a companion source. It does not record network traffic flows. Confirm that the app is enabled, that the log path sits on storage with appropriate permissions, and that the file is forwarded to your central log platform. Nextcloud is licensed under AGPL-3.0-only, so confirm the obligations that apply to your deployment.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. For a Safeguard 13.6 review, this shows who requested secrets and from where, which complements network flow records that show the underlying connections. It does not replace network telemetry, because it only covers API activity. Confirm how audit devices are enabled, what happens if the audit device cannot write, and how long records are retained. OpenBao is licensed under MPL-2.0, a file-level copyleft license, so review its obligations before you modify its source.

Who owns CIS Safeguard 13.6 and who can help

The organization owns Safeguard 13.6 in full. Its security and network teams decide which devices sit on the network boundary, configure those devices to produce flow logs or traffic records, review the output and act on the alerts it produces. The Coverage metric in the CIS Controls Assessment Specification is a share of network boundary assets, so the organization must maintain the authoritative boundary list and be able to explain any asset left out of it.

Boundary list: Maintain the list of network boundary assets that the Coverage figure is calculated against, linked to the asset inventory from Safeguard 1.1.
Device configuration: Enable flow or traffic logging on each boundary device and keep the settings under change control, supported by the secure configuration process in 4.2.
Review and alert ownership: Name who reviews flow data, who receives alerts and what happens when collection stops.
Coverage figure: Calculate and sign off the Coverage value, with the method and the exceptions documented.
Architecture input: Keep the network diagrams from 12.4 current so reviewers can confirm the boundary is complete.

Before engaging anyone, confirm that the internal owner for each of these items is named in writing.

Where organizations fall short on CIS Safeguard 13.6 and how to close each gap

Safeguard 13.6 is usually measured as coverage of network boundary assets that log traffic flow, so most shortfalls come from an incomplete boundary, a broken collection path, or logs that nobody reads. The cards below cover each gap an assessor is likely to find, with the fix and the evidence that closes it.

Boundary list omits cloud and VPN edges

The Coverage metric is calculated against network boundary assets, so an inventory that lists only the on-premises firewall misses the rest of the edge. Cloud virtual networks, VPN concentrators, remote access gateways and internet-facing load balancers often sit outside the list because they are managed by a different team. Start from the architecture diagram required by Safeguard 12.4 and the asset inventory from Safeguard 1.1, then confirm each boundary point has a flow or traffic log source. Evidence: a dated boundary register signed by the network owner, cross-checked against the diagram.

Flow export enabled without a receiver

A firewall or router can show flow export as configured while nothing listens at the destination, or the collector drops records after a certificate or port change. Check each exporter end to end by confirming that recent records arrive at the log platform and that the timestamps are current. OPNsense can forward Suricata alerts and events to syslog in EVE JSON format, so verify that the syslog target is reachable and that the EVE output file is written on the sending host. Evidence: dated screenshots or query results from the receiver showing records from each boundary device.

Logs collected but never reviewed

Collection alone does not satisfy the Detect intent of Safeguard 13.6. Logs that sit in storage with no detection rules, saved searches or review cadence cannot show that the traffic data supports alerting. Link flow and sensor records to correlation rules in the central alerting platform from Safeguard 13.1, and document who reviews the output and how often. Confirm that at least one alert or investigation has used flow data. Evidence: rule definitions, alert tickets that cite flow records, and a named reviewer with a recorded review schedule.

Coverage measured with an undocumented method

An assessor will ask how the coverage figure was produced. A percentage that appears in a dashboard without a written calculation, a defined numerator and denominator, or a stated source of truth cannot be reproduced and tends to fail review. Write a short method that names the boundary list as the denominator, the configured logging state per asset as the numerator, and the date of each measurement. Assign an owner and keep the method under change control. Evidence: the method document, the boundary register it references, and each dated calculation with its raw inputs.

Retention shorter than the assessment sample

Assessors usually select a sample of past periods and ask for the flow records behind them. If retention is shorter than the period under review, the sample cannot be evidenced, even when collection works today. Set the retention period against the assessment window and the incident investigation needs of the organization, then confirm it on each receiver and archive, not only on the primary store. Check that Nextcloud or other application audit logs, where in scope, follow the same retention policy. Evidence: retention settings from each platform, plus a sample query that returns records from the oldest period in the window.

Clock skew breaks correlation

Flow records from a firewall, IDS sensor and application log only correlate if their timestamps share a reliable time source. A sensor that drifts by minutes can place an alert before the connection that caused it, which hides the sequence from investigators and from correlation rules. Synchronize every boundary device, sensor and log receiver to the same trusted time source, and monitor offset as part of the health check. Confirm the time zone and format are consistent across EVE JSON records, syslog and the SIEM. Evidence: time sync configuration from each device and a dated offset report showing the spread across sources.

Questions buyers ask about CIS Safeguard 13.6 cost, effort and help

Can our team implement Safeguard 13.6 without an outside partner?

Yes, an organization can implement Safeguard 13.6 with its own staff, because the CIS Controls are free for any organization to use to improve its own cybersecurity. The work is configuring network devices and firewalls to export flow records or traffic to a collector, then confirming coverage across the network boundary. Teams that already run a SIEM and manage their own network devices often handle it internally. A partner becomes useful when the internal team lacks spare engineering time, when the device inventory is incomplete, or when the collector needs to be built and hardened inside a private environment. Confirm internal skills against the Safeguard's prerequisites before deciding.

How much effort does Safeguard 13.6 take and what drives it?

Effort depends mostly on how many network boundary devices must export flow data, how many different vendors and firmware versions are involved, and how much of the asset inventory and architecture documentation already exists. The Assessment Specification scores this Safeguard with a Coverage measure, so every in-scope boundary device needs to be counted and configured. Drivers that raise effort include:

Devices that cannot export flow data natively and need a sensor or mirror port
Missing or outdated network diagrams and asset records
Retention, storage and query requirements for the collector
Multiple sites, cloud networks or hybrid links that each need their own export path

Ask any provider to break the effort down by device group and by collector work.

How long does a flow logging project usually take?

Duration depends on device count and scope, so no general timeline applies. A small, single-site network with supported devices and a ready collector can be configured quickly, while a multi-site estate with legacy hardware needs inventory reconciliation, change windows and testing before coverage can be counted. Schedule risk usually comes from change approvals, device maintenance windows and waiting on the asset inventory (Safeguard 1.1) and architecture diagrams (Safeguard 12.4), which the Assessment Specification lists as prerequisites. Ask a provider to tie the timeline to a device list and to named milestones in a written, fixed-scope plan.

What does our internal team need to contribute?

The work needs three roles from the organization. Asset owners confirm which network boundary devices exist, who runs them and which change windows apply. Network engineers enable flow export, set destinations and check that the right traffic is captured without degrading device performance. A reviewer, typically someone from security operations, confirms that the collected data reaches the SIEM or log platform and that alerts on it are reviewed. The organization should also name an owner for the Safeguard, since the controls remain its responsibility even when an outside party performs configuration work.

Can a partner make us compliant with Safeguard 13.6 or issue a result?

No. A partner can prepare the systems, configuration records and evidence, but only an independent assessor or certification body issues a report or certificate. The organization owns its controls and decides how it will show that Safeguard 13.6 is met. Some frameworks that map to this Safeguard, such as ISO/IEC 27001:2022 and AICPA SOC 2, are verified by independent auditors who test evidence over a period or at a point in time. Any provider who promises a compliance outcome or a certificate should be treated with caution. Ask the assessor which evidence format they expect before configuration begins.

What should a fixed-scope written quote for flow logging include?

A useful quote lists the scope in writing before work starts. It should name the in-scope network boundary devices and sites, the collector platform and where it runs, the retention and storage assumptions, and the testing steps used to confirm flow records arrive. It should separate one-time work, such as configuration and documentation, from recurring work, such as collector upkeep, patching and periodic coverage checks. Ask for exclusions in plain language, the client responsibilities such as change windows and access, the acceptance criteria for each deliverable, and the handover format for evidence. Confirm what happens if the device count changes during the engagement.

Does the CIS Controls license limit how we can use Safeguard 13.6?

The CIS Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, and CIS states that organizations may use the Controls for free to improve their own cybersecurity. Commercial use, meaning reselling the Controls or building paid services on the content itself, requires CIS's prior approval. Internal implementation of Safeguard 13.6 falls within the free use CIS describes. Before publishing evidence templates or client-facing materials that reproduce CIS text, check the licensing terms and seek approval where needed, and confirm the position with CIS or qualified counsel.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so flow log collection for Safeguard 13.6 is scoped against your real network boundary assets. We prepare the configuration, telemetry pipeline and evidence, while your organization owns the control and an independent assessor issues any report.

How we scope

Engagements are fixed-scope, with the network boundary assets, devices and telemetry sources agreed in writing before work starts.
We confirm which boundary assets must log flow or traffic data, using your asset inventory and architecture diagrams as inputs.
The written scope names the collection points, retention expectations and alerting outputs covered for Safeguard 13.6.

How we build

We configure flow or traffic logging on in-scope network devices and send records to a central collector you operate.
Where a platform such as OPNsense is in use, we check that its Suricata EVE JSON output is split and forwarded to your log tools.
We test that logs arrive, carry consistent timestamps and that alerts fire for sample traffic in a non-production window.

How we hand over

You receive configuration records, a coverage list of logging boundary assets and a description of the collection pipeline.
Evidence packs map each in-scope device to its logging setting, so the coverage measure in the assessment specification can be reproduced.
Runbooks explain how to review flow records, tune alerts and respond when a boundary device stops sending logs.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, covering new network devices and logging changes.
We can re-run coverage checks after network changes so the evidence stays current between assessments.
Questions about how an independent assessor will test Safeguard 13.6 should be confirmed with that assessor before the scope is signed.