A SOC investigation rarely starts with perfect evidence. Sometimes the analyst has a packet capture. Sometimes there are only flow records. Sometimes the most useful record is a DNS, proxy, authentication, or application transaction log.

These data types are not interchangeable. They answer different questions, retain different amounts of detail, and create very different storage and privacy costs.

Cisco’s current 200-201 CCNACBR v1.2 scope treats network security monitoring data as a core analyst skill. Cisco training explicitly includes NetFlow, packet capture, log analysis, and correlating PCAPs with alerts. The useful skill is therefore not simply knowing the names of the data sources; it is choosing the evidence that can actually answer the investigation question.

Full packet capture gives the deepest network-level evidence

A full packet capture records packets observed at the collection point, including protocol headers and—when traffic is not encrypted or otherwise unavailable—the application payload.

That makes packet capture valuable when the question depends on exact protocol behavior:

• Which side initiated the connection?
• What flags or options were present?
• What DNS name was queried?
• What HTTP method, header, or response was visible?
• Did a TCP connection reset, retransmit, or complete normally?
• Does the payload contain a recognizable exploit pattern or transferred object?

Tools such as Wireshark let an analyst move from a broad capture to individual conversations and fields.

The tradeoff is volume. Full packet capture can consume significant storage, and retaining payloads can introduce privacy and sensitive-data concerns. Encryption also limits what the analyst can see above the transport layer even when the packet headers remain available.

Packet capture is strongest when the question depends on packet sequence, protocol fields, retransmissions, flags, malformed content, or application data that is actually visible. It can show the difference between “a connection was attempted” and “the three-way handshake completed but the application immediately reset it.” It can also reveal whether the client or server sent the first error and whether a suspicious payload crossed the wire.

That depth has a cost. Full capture consumes storage quickly, can contain sensitive content, and may be unavailable at the exact point where the traffic flowed. Analysts should therefore record where the sensor sits in relation to NAT, proxies, load balancers, VPN termination, and encrypted sessions. A packet trace from the wrong side of a translation or inspection boundary may show different addresses and different visibility than endpoint telemetry.

NetFlow summarizes conversations instead of storing payloads

NetFlow records metadata about network flows rather than preserving every packet payload.

The exact fields depend on the flow format and exporter, but analysts commonly work with properties such as source and destination IP addresses, ports, protocol, timestamps, packet counts, and byte counts.

That makes flow data excellent for questions such as:

• Which internal host contacted this external address?
• How many systems communicated with the same destination?
• Was the traffic short and periodic or long-lived and high-volume?
• Did one endpoint suddenly start communicating with many peers?
• Is there evidence of unexpected east-west movement?
• How much data was transferred?

NetFlow can show that a connection existed and characterize it without showing the application content that a PCAP might contain.

That lower detail is also its operational advantage. Flow records are far smaller than full packet captures, so organizations can often retain them for longer periods and use them for broad hunting across large networks.

Flow records are particularly useful for scale because they preserve the shape of communication without retaining every byte. Depending on the exporter and format, useful fields can include source and destination addresses, ports, protocol, byte and packet counts, timestamps, interface information, and TCP flag summaries. That is often enough to find a beaconing host, an unexpected high-volume transfer, or a system contacting many destinations even when application payload is encrypted.

The analyst must still understand collection behavior. Sampling can reduce fidelity, short and long flow timeouts can split one conversation into several records, and asymmetric routing can cause different sensors to observe different halves of a session. Flow data is excellent evidence of who communicated with whom, when, and how much; it should not be overstated as proof of the exact application content that moved.

Transaction data explains an application or security event

Transaction data sits at a different layer.

A DNS log can record a client querying a domain and receiving a result. A web proxy can record a URL request and response status. An authentication system can record a sign-in attempt. A firewall can record a session decision. An endpoint or application can record a specific action taken by a user or process.

These records are usually structured around a meaningful event rather than raw packet transport.

Transaction data is powerful because the system that generated the record understands context the network alone may not know. A proxy might know the authenticated username. A DNS resolver knows the queried name. An application knows which API method was called.

The limitation is that a transaction log reflects what that particular system observed and chose to record. It may not preserve enough information to reconstruct the lower-level network behavior.

Transaction records sit closer to the service that interpreted the request. A DNS log can preserve the queried name, record type, response code, and resolver action. A web proxy can preserve the URL category, method, user identity, policy result, and upstream status. An authentication system can preserve the account, source, outcome, and reason code. These records answer questions that a generic five-tuple cannot because the application already parsed the protocol semantics.

The tradeoff is that transaction data reflects the perspective and schema of the product that generated it. A proxy log may describe the client-to-proxy request rather than the proxy-to-server connection. A DNS security product may log the policy decision even when a separate resolver ultimately answered the query. Before correlating records, identify what each timestamp, source address, user field, and action actually represents.

The right evidence depends on the question

Suppose an alert says a workstation contacted a suspicious IP address.

NetFlow can quickly answer whether the connection happened, when it happened, how long it lasted, and how much traffic moved. That may be enough to scope the event across thousands of endpoints.

A PCAP from the relevant time can answer what happened at the protocol level. If the traffic is visible, it may reveal commands, headers, protocol anomalies, or transferred data.

Transaction logs may explain why the connection happened. A DNS log can show the domain resolved before the connection. A proxy log might show the URL. An endpoint record may identify the process that initiated it.

No single source is automatically “better.” The highest-value source is the one that answers the unresolved question.

A quick decision matrix helps:

Investigation question	Best starting evidence	Why
Did these two hosts communicate?	NetFlow/IPFIX	Efficient conversation-level visibility
Why did a TCP session fail?	Packet capture	Shows flags, sequence behavior, retransmissions, and resets
Which hostname or URL triggered a policy?	Transaction data	Preserves application-aware fields and policy action
What left the network over an encrypted session?	Flow + endpoint/proxy data	Network metadata alone cannot reveal encrypted payload
Is one alert part of a wider campaign?	SIEM correlation across all three	Links network, application, identity, and endpoint evidence

The matrix is a starting point, not a rule that only one source should be collected. Good investigations often begin with the cheapest broad evidence and escalate to deeper evidence only where the hypothesis requires it.

Encryption changes the value of packet content, not the value of network metadata

Modern traffic is frequently encrypted. That reduces application visibility in a normal packet capture because the payload may be ciphertext.

It does not make network evidence useless.

The analyst can still use connection endpoints, timing, ports, packet sizes, handshake behavior, flow duration, and other metadata. Flow records remain useful for communication patterns. DNS and endpoint transactions may provide additional context that is not encrypted in the same way or is logged before encryption occurs.

This is one reason SOC investigations depend on correlation rather than one “perfect” sensor.

Retention changes which evidence is available after the alert

A detection may fire today for activity that began weeks ago.

Organizations often cannot retain full packet captures for the same period that they retain smaller flow or transaction records. That means an analyst may use long-retention NetFlow to identify the first suspicious communication, then use endpoint or authentication logs to reconstruct what happened around it.

Retention strategy should therefore reflect investigation value, not just data size.

A SOC that keeps rich packet data for a very short period but no long-term connection metadata may be unable to answer basic historical scoping questions. A SOC that keeps only flow metadata may struggle when a case requires protocol-field or payload evidence.

Correlation turns separate records into a timeline

The strongest investigation often combines the three.

A practical sequence might look like this:

1. An alert identifies a suspicious destination.
2. NetFlow reveals which hosts contacted it and when.
3. DNS transaction data shows which domain names preceded those connections.
4. Endpoint or authentication logs identify the user and process involved.
5. A PCAP confirms the network protocol behavior for a key time window.
6. The combined evidence is normalized into the SIEM or case-management timeline.

Cisco’s current cybersecurity training explicitly emphasizes correlating event logs, packet captures, and alerts because one source rarely provides the complete story.

Time normalization is part of that correlation. Sensors can use different time zones, experience clock drift, or record the beginning versus the end of a session. NAT can replace the address seen by an external sensor, while a proxy can create a second connection that no longer uses the original client’s IP. If two records appear unrelated, check translation tables, proxy identifiers, hostnames, user identities, and clock offsets before concluding they describe different activity.

This is where a SIEM becomes useful: not because central storage magically makes every event meaningful, but because it provides a place to normalize time, identity, host, and network fields and test whether records from different sources describe the same sequence of activity.

A practical selection model

Use full packet capture when you need packet-level truth.

Use NetFlow when you need broad communication visibility and historical scoping.

Use transaction data when you need system or application context.

Then correlate them when the investigation crosses those boundaries.

A defensible evidence strategy ends with the same question it began with: what must be proven next? Choose the source that can answer that question, state what the source cannot prove, and escalate to deeper evidence only when the investigation requires it.