Logical vs physical network diagram: use separate sheets

The short answer: use a physical network diagram to show where equipment is and exactly what connects to what. Use a logical network diagram to show how traffic moves through subnets, zones, and policy boundaries. For anything larger than a small fixed network, keep those as separate sheets and put application or incident-response flows on a third view instead of turning one drawing into an unreadable inventory dump.

Cisco describes physical topology as the actual placement and connections of components—the underlay—and logical topology as the path data follows regardless of those physical connections—the overlay. That distinction is simple; the hard part is deciding what belongs on each drawing. This guide gives you that decision rule, a worked OT example, and a review checklist.

Scope: this is a documentation method, not a security architecture standard. The example below is illustrative, not an as-built system or an approved segmentation design. Last checked against the cited Cisco, CISA, and NIST sources on August 27, 2026.

Physical vs logical network diagram: the decision table

Start with the question the reader must answer. Do not start with a stencil library or a list of every field available in a discovery tool.

The dividing line is intent. Physical documentation should let a technician locate a component and trace a real connection. Logical documentation should let an engineer or responder understand reachability, segmentation, dependencies, and expected communication.

What belongs on the physical drawing

A useful physical drawing identifies both ends of every important connection. For a rack-to-field link, that normally means the two device names, the port at each end, the cable or circuit identifier, the medium, and the physical locations. If redundancy matters to the job, show the separate paths rather than drawing one generic line.

The worked example records FW-01 p7 → SW-OT1 Gi1/0/24, the FO-17 fiber run to field panel FP-02, and the local connection from SW-FIELD to PLC-02. Those labels answer a 2 a.m. troubleshooting question: which end can I inspect or move without guessing?

Avoid filling this view with every IP address, firewall rule, application dependency, firmware version, and support contract. CISA's 2025 OT asset inventory guide calls for an organized, regularly updated inventory and lists high-priority attributes including criticality, IP and MAC addresses, manufacturer, model, physical location, ports and services, and logging. A diagram can point to an asset ID, but a maintained table or system of record is better for attributes that change independently of the cable path.

What belongs on the logical drawing

The logical drawing abstracts away rack coordinates and cable IDs. It groups components by the boundaries that determine communication: subnets, VLANs, routing domains, security zones, cloud networks, tunnels, and third-party access paths. Lines should represent relevant reachability or expected flows, not merely the existence of a cable.

In the example, the logical view shows three zones:

1. An enterprise network containing the administrator's workstation.
2. An OT DMZ containing a jump host and historian.
3. A control zone containing the HMI and PLC.

The arrows make the intended paths reviewable: an approved administrative path reaches the jump host, a managed session crosses into the control zone, process traffic connects the HMI and PLC, and telemetry moves toward the historian. The example deliberately does not specify ports, protocols, authentication, failover, or enforcement products; those facts must come from the real system and its approved rules.

NIST SP 800-61r3 makes network communication and data-flow representations an asset-management outcome in ID.AM-03. It notes that maintaining those representations can improve the detection of malicious flows and suggests automation as one way to help keep them current. That is a stronger requirement than “have a pretty topology picture”: the maintained view must represent authorized communication well enough to compare expected and observed behavior.

When to add a third data-flow view

Add a data-flow view when the logical topology still contains too many possible paths to answer the operational question. A network engineer may need the whole Layer 3 adjacency map; an incident responder may need only the path for identity, DNS, backups, telemetry, or a critical business application.

For each reviewed flow, record:

• source and destination roles, not only device names;
• direction and business or operational purpose;
• protocol and port when the review depends on them;
• the boundary crossed and the control expected there;
• owner, approval reference, and last verification date;
• what should happen when the destination or control is unavailable.

CISA's StopRansomware Guide recommends regularly updated network diagrams that describe systems and data flows, including major networks, addressing schemes, topology, interdependencies, third-party access, and cloud connections. Its advice to store network documentation securely and keep offline backups also matters: a response drawing that is available only from the compromised network is not much of a response asset.

A worked procedure for splitting an overloaded diagram

Suppose your current drawing has rack elevations, switch ports, VLAN colors, IP addresses, firewalls, application arrows, vendor VPNs, and a spreadsheet pasted into the corner. Split it in this order:

1. Write the review question in the title block. “Trace a failed field link” produces a different sheet from “review vendor access to the control zone.”
2. Duplicate the source, then delete by question. On the physical copy, remove subnets and application arrows. On the logical copy, remove rack units and cable paths.
3. Give every retained line a meaning. A physical line is a connection. A logical line is reachability, adjacency, or an expected flow; label which one.
4. Move volatile attributes into an inventory. Keep stable IDs on the drawing so readers can join the views without copying the database into both.
5. Add a focused flow sheet only for consequential paths. Remote access, identity, backups, control traffic, and safety-relevant dependencies are typical candidates.
6. Review the packet with two people. Ask a field technician to trace a cable and a responder to trace an authorized flow. If either must guess, the split is incomplete.

This procedure also exposes contradictions. If the physical sheet shows a direct link that the logical sheet omits, decide whether it is irrelevant to the stated question, undocumented, or an unintended path. Do not quietly “make the pictures agree” without checking the system.

Common failure modes

One drawing tries to serve every audience. The result has dense labels but no clear answer. Create separate views with explicit purposes.

A line changes meaning across the page. Readers cannot tell whether it means cable, Layer 2 adjacency, route, or permitted application flow. Use a legend and label exceptions.

The diagram becomes the inventory. Firmware, owner, serial number, support date, and every address are copied onto shapes and immediately drift. Keep a stable asset key on the drawing and maintain detailed attributes elsewhere.

Discovery output is treated as approved design. Automated discovery can reveal devices and observed connections; it does not establish that a path is authorized, complete, or safe. Reconcile discovered state with configuration, change records, and accountable owners.

Sensitive detail is published too broadly. Exact addressing, remote-access paths, management interfaces, and recovery dependencies can be useful to defenders and attackers. Store the full packet according to its sensitivity and create a deliberately sanitized view for broader audiences.

The drawing has no date or owner. A clean but stale map can be worse than an obviously incomplete one. Put the owner, scope, source systems, last verified date, and change trigger in the title block.

The 15-minute review checklist

Before issuing the drawing packet, verify:

• each sheet states the question it answers;
• physical links name both endpoints and important ports or circuit IDs;
• logical boundaries and subnets match the approved configuration;
• line semantics are explicit and consistent;
• third-party and cloud connections are not silently omitted;
• critical dependencies and expected flows are reviewable;
• detailed asset attributes live in a maintained inventory;
• secrets and unnecessary sensitive details are absent;
• owner, scope, last verified date, and next review trigger are visible;
• an offline or otherwise incident-accessible copy exists where required.

If the split is clear, draft the two views from the same verified inventory. You can use the ChatDiagram network diagram maker to structure the first pass, then have the network owner verify every device, boundary, and flow against the actual environment before issue.