Safeguard 13.6: Collect Network Traffic Flow Logs

Safeguard 13.6: collect network traffic flow logs requirement means you must consistently capture and retain network flow telemetry (for example, NetFlow/IPFIX/sFlow or cloud flow logs) across key network boundaries, then make those logs usable for detection and investigation. Operationalize it by defining scope, enabling flow logging at each boundary, centralizing storage, and proving ongoing coverage with repeatable evidence. (CIS Controls v8; CIS Controls Navigator v8)

Key takeaways:

• Flow logs are a minimum viable record of “who talked to whom, when, and how much,” and they must be collected continuously where it matters most. (CIS Controls v8)
• Your audit win condition is provable coverage: documented scope, enabled sources, centralized retention, and recurring verification. (CIS Controls Navigator v8)
• Treat flow logging as a control with owners, monitoring, and exceptions, not as a one-time network engineering task. (CIS Controls v8)

Flow logs are one of the fastest ways to reduce blind spots in detection and response without full packet capture. They do not show payload content, but they do show communication patterns that help you identify lateral movement, unexpected egress, command-and-control beacons, misrouted traffic, and data transfer anomalies. Safeguard 13.6 sits in CIS Controls v8 as a practical requirement: collect network traffic flow logs in a way that supports security operations and investigations. (CIS Controls v8; CIS Controls Navigator v8)

For a Compliance Officer, CCO, or GRC lead, the hard part is rarely the concept. The hard part is turning “collect flow logs” into a control you can test: clear scope, accountable owners, a standard configuration, and evidence that remains valid after network changes, cloud migrations, and tooling swaps. This page focuses on requirement-level implementation guidance you can hand to Network/SecOps and then audit without guesswork. It also tells you what artifacts to retain so an assessor can quickly confirm the control is both designed and operating as intended. (CIS Controls v8)

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 13.6 implementation expectation (Collect Network Traffic Flow Logs).” (CIS Controls v8; CIS Controls Navigator v8)

What the operator must do:
You must enable collection of network traffic flow logs from the environments you run (on-prem network devices and/or cloud networking services), route those logs to a centralized logging platform, and retain them in a way that supports detection and investigation. Your compliance obligation is not satisfied by having the feature available. It is satisfied when flow logging is turned on for the defined scope, logs are actually arriving, and you can prove that the process is maintained over time. (CIS Controls v8)

Plain-English interpretation

“Collect network traffic flow logs” means you capture metadata about network connections so you can answer basic incident questions quickly:

• What systems communicated?
• Over what protocol/port?
• When did it start and stop?
• How much data moved? This requirement is about visibility. If you cannot reconstruct traffic patterns, you will struggle to scope incidents, validate containment, or identify compromised hosts that communicated with suspicious destinations. (CIS Controls v8)

Who it applies to

Safeguard 13.6 applies broadly to enterprises and technology organizations running networks where security monitoring and incident response matter. (CIS Controls v8; CIS Controls Navigator v8)

Operational contexts where assessors will expect flow logging coverage:

• Internet egress points: firewalls, secure web gateways, cloud NAT/egress gateways
• Ingress boundaries: edge firewalls, load balancers, WAF-adjacent network paths
• Segmentation boundaries: data center core/distribution, internal firewalls, VLAN gateways
• Cloud networks: VPC/VNet flow logs, subnet-level and gateway-level flows
• Remote access paths: VPN concentrators, ZTNA gateways (where they emit flow-like telemetry)

If your environment includes third parties operating network infrastructure on your behalf (for example, managed firewall, managed SD-WAN, MSP-run cloud accounts), treat flow logs as a shared responsibility requirement: your program still needs evidence that logs are collected and accessible for investigation. (CIS Controls v8)

What you actually need to do (step-by-step)

1) Define scope in a way you can test

Create a short “Flow Logging Scope” standard that lists:

• Which boundaries must emit flow logs (internet egress, segmentation chokepoints, cloud VPC/VNet, remote access)
• Which device/service types qualify (NetFlow/IPFIX exporters, cloud flow logs, firewall session logs if they meet your flow definition)
• Which networks are in-scope (production, corporate, sensitive environments)

GRC tip: if scope is vague (“all networks”), you will never be able to prove completeness. Write it so a tester can enumerate in-scope boundaries from diagrams and inventories. (CIS Controls v8)

2) Select your flow log sources and formats

Common options:

• Network device flow export: NetFlow/IPFIX/sFlow from routers, switches, firewalls
• Cloud-native flow logs: VPC/VNet flow logs, gateway flow logs, load balancer connection logs
• Firewall/session telemetry: acceptable if it reliably captures source/destination, port, action, timestamps, byte/packet counts

Document which sources you accept as “flow logs” for 13.6 and why. This becomes your control narrative. (CIS Controls Navigator v8)

3) Turn on flow logging at each boundary (with a standard baseline)

For each boundary, define a baseline configuration that includes:

• Export enabled and pointing to your collector
• Required fields (at minimum: src/dst IP, src/dst port, protocol, timestamps, bytes/packets, allow/deny if available)
• Consistent time sync expectations for devices exporting logs (tie to your time standard)

Operational note: “Enabled” must mean “producing events.” Build acceptance criteria: after enabling, confirm logs appear in the central platform and can be queried. (CIS Controls v8)

4) Centralize collection and normalize

Route flow logs to a centralized logging platform (SIEM, log analytics platform, or a dedicated flow collector that forwards to the SIEM). Your goals:

• Single place to search during an incident
• Normalized fields so detections and investigations work across sources
• Access controls and auditability for who can view or export logs

If different teams own different networks, centralization is also your governance hook: it makes evidence collection repeatable. (CIS Controls v8)

5) Define retention and access as a security requirement (not a storage preference)

CIS 13.6 does not provide a numeric retention period in the provided excerpt, so set a retention standard aligned to your investigation needs and any external obligations you have (contractual, legal, other frameworks). Document:

• Hot vs cold retention approach (searchable vs archived)
• Who can access flow logs, and how access is approved
• How you preserve logs for investigations (legal hold process if applicable)

The audit expectation is that you can retrieve historical flow records when needed, and you can show the retention setting is enforced. (CIS Controls v8)

6) Operationalize as a control with recurring evidence capture

This is the point most programs miss. You need a repeatable operating rhythm:

• A periodic coverage check that compares in-scope boundaries to actual configured exporters
• A data-quality check (missing fields, time skew, dropped exports, collector outages)
• An exception process for boundaries that cannot export flow logs (with compensating controls and a remediation plan)

Map 13.6 to documented control operation and recurring evidence capture. That mapping is explicitly called out as recommended control guidance in the provided data. (CIS Controls v8; CIS Controls Navigator v8)

7) Build “can we investigate?” runbooks

Have SecOps validate a basic investigative workflow:

• Find all outbound connections from a host over a timeframe
• Identify top external destinations by byte count
• Pivot from a suspicious destination to internal sources
• Confirm blocked vs allowed traffic where available

If your team cannot do these pivots quickly, you are collecting logs but not meeting the intent. (CIS Controls v8)

Required evidence and artifacts to retain

Keep evidence that proves design and operation, not just that a tool exists.

Design artifacts (control design):

• Flow Logging Scope standard (in-scope boundaries and environments) (CIS Controls v8)
• Network boundary inventory or diagrams that identify where flow logs must be collected (CIS Controls v8)
• Logging architecture diagram: sources → collectors → SIEM/log store (CIS Controls v8)
• Configuration baselines for each source type (router/firewall/cloud flow logs) (CIS Controls v8)

Operational artifacts (control operation):

• Screenshots/exports showing flow logging enabled for each in-scope boundary (sample per boundary type) (CIS Controls v8)
• Central platform proof of ingestion (index/listener status, sample events, parsing/normalization evidence) (CIS Controls v8)
• Recurring coverage check results (ticket, report, or dashboard export) mapped to 13.6 (CIS Controls Navigator v8)
• Exception register entries (owner, rationale, compensating control, target remediation) (CIS Controls v8)
• Incident/purple-team proof: at least one sanitized investigation example showing flow logs used to answer “who talked to whom” questions (CIS Controls v8)

Common exam/audit questions and hangups

Expect these questions from internal audit, customers, or assessors:

• “Show me your scope.” Which networks and boundaries are included, and why? (CIS Controls v8)
• “Prove it’s on.” Demonstrate configuration at the source, not only SIEM screenshots. (CIS Controls v8)
• “How do you know you didn’t miss a boundary?” Walk through your boundary inventory and how changes get captured. (CIS Controls v8)
• “What happens when the collector is down?” Show alerting and operational response for ingestion failures. (CIS Controls v8)
• “Can you retrieve historical data?” Demonstrate search and retrieval aligned to your retention standard. (CIS Controls v8)

Hangups that delay audits:

• Cloud teams assume the platform team enabled flow logs; nobody can prove which VNets/VPCs are covered.
• NetFlow is enabled on some devices, but collectors are missing, saturated, or misconfigured, so exports drop silently.
• Logs exist but are not queryable due to inconsistent parsing across sources. (CIS Controls v8)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Avoid it by
Treating 13.6 as “turn on VPC/VNet flow logs” only	You miss on-prem boundaries and internal segmentation	Define scope by boundary types across hybrid environments. (CIS Controls v8)
No owner for flow log coverage	Logging breaks after network changes	Assign a control owner and require evidence on a recurring cadence. (CIS Controls Navigator v8)
Collecting flows but not validating fields/time	Detections and investigations don’t work reliably	Implement data-quality checks and time sync validation. (CIS Controls v8)
Central ingestion without access governance	Sensitive telemetry becomes broadly accessible	Put RBAC, approvals, and audit logs around flow log access. (CIS Controls v8)
Exceptions handled informally in chat/email	Auditors treat gaps as control failures	Maintain a formal exception register tied to remediation. (CIS Controls v8)

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this specific safeguard, so you should treat this as a framework conformance and assurance requirement rather than a standalone regulatory mandate. (CIS Controls v8; CIS Controls Navigator v8)

Risk implications are operational and immediate:

• Without flow logs, incident responders struggle to scope affected systems and confirm containment.
• Without provable coverage, you will fail customer due diligence and audits even if you “generally log traffic.”
• Missing implementation evidence is itself a stated risk factor in the provided guidance. (CIS Controls v8; CIS Controls Navigator v8)

Practical 30/60/90-day execution plan

Use this as a control-implementation sprint plan. Adjust to your change windows and architecture complexity.

First 30 days: define, inventory, and prove a thin slice

• Publish your Flow Logging Scope standard and assign a control owner. (CIS Controls v8)
• Inventory in-scope boundaries (internet egress, segmentation points, cloud networks, remote access). (CIS Controls v8)
• Enable flow logging for one representative boundary in each major environment (on-prem, cloud, remote access) and verify ingestion end-to-end. (CIS Controls v8)
• Create an evidence folder structure and start recurring evidence capture for 13.6. (CIS Controls Navigator v8)

Days 31–60: expand coverage and stabilize operations

• Roll out baseline configurations to remaining in-scope boundaries and document exceptions. (CIS Controls v8)
• Normalize fields in the central platform so investigations can pivot consistently. (CIS Controls v8)
• Implement ingestion failure alerting and an on-call/runbook response path. (CIS Controls v8)
• Run a tabletop or a simple hunt using flow logs to prove “can we investigate?” (CIS Controls v8)

Days 61–90: make it durable and audit-ready

• Implement a recurring coverage check that reconciles boundary inventory to configured exporters and cloud flow-log settings. (CIS Controls v8)
• Formalize retention, access controls, and retrieval procedures for investigations. (CIS Controls v8)
• Package audit evidence: scope, diagrams, samples of enabled configs, ingestion proof, coverage reports, exceptions, and a sample investigative workflow. (CIS Controls v8; CIS Controls Navigator v8)

Tooling note: Daydream is typically introduced here as the system of record for control narratives, evidence requests, exception tracking, and recurring evidence capture, so 13.6 stays current as networks change. (CIS Controls v8; CIS Controls Navigator v8)

Frequently Asked Questions

Do firewall logs count as “network traffic flow logs” for Safeguard 13.6?

They can, if they reliably capture flow-like metadata (source, destination, ports, protocol, timestamps, and volume) and you can search it centrally for investigations. Document your definition of “flow logs” and apply it consistently. (CIS Controls v8)

How do I scope 13.6 in a hybrid environment without boiling the ocean?

Start with boundaries that concentrate risk and visibility value: internet egress/ingress, segmentation chokepoints, and cloud VPC/VNet flow logs for production networks. Write scope in terms of boundary types so it remains testable through change. (CIS Controls v8)

What evidence is strongest for an audit?

Auditors want proof at the source and at the destination: screenshots/exports showing flow logging enabled plus SIEM/collector evidence that events are arriving and searchable. Add a recurring coverage report mapped to 13.6 to show ongoing operation. (CIS Controls Navigator v8)

What if a third party manages our network and won’t give us raw flow logs?

Treat it as a shared responsibility gap and document an exception with compensating controls, then negotiate access terms (or an investigation support SLA) in the contract. You still need a way to support investigations and provide assurance evidence. (CIS Controls v8)

Should we collect full packet capture instead of flow logs?

Packet capture is useful in some environments, but 13.6 is explicitly about collecting flow logs. Many teams use flow logs as the baseline visibility layer and reserve packet capture for targeted high-risk segments. (CIS Controls v8)

How do we keep this control from drifting after network changes?

Tie flow logging to your change process: new egress paths, new VNets/VPCs, and new segmentation firewalls must include flow logging enablement as a deployment requirement. Backstop with a recurring coverage reconciliation and evidence capture. (CIS Controls v8)