Network Documentation for SOC 2 and ISO 27001

An auditor rarely asks whether your network diagram looks polished. They ask whether the systems in scope are known, whether the controls around them are defined, and whether you can show that those controls operated during the period under review. If the inventory lives in one spreadsheet, the VLAN list in a ticket queue, and the latest topology diagram in someone’s personal drive, answering a simple evidence request becomes a reconstruction project.

Network documentation does not make an organization compliant by itself. It gives your security program a reliable description of the environment that its controls are meant to protect. For SOC 2 and ISO/IEC 27001 audits, that means documenting the assets, boundaries, connections, access paths, changes, and review history that let an auditor trace an assertion or a risk treatment back to evidence.

Start With Scope, Not the Diagram

SOC 2 examines controls relevant to one or more Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. ISO/IEC 27001:2022 defines requirements for an information security management system, including risk management and continual improvement. The standards overlap in their interest in controlled, reviewable operations, but neither one gives you a universal list of network files to produce.

Start by writing down the system boundary. List the products, environments, sites, cloud accounts, data stores, support systems, and third parties that are in scope. Then identify the network paths that connect those components. The boundary is more useful than a beautiful topology map because it tells you which records need to be complete and which can be treated as supporting context.

The AICPA SOC 2 guidance describes SOC 2 as an examination of a service organization’s system and controls. ISO describes ISO/IEC 27001:2022 as the requirements standard for an information security management system. Use your engagement scope, control matrix, Statement of Applicability, and auditor requests as the authority for what evidence is required.

Build an Authoritative Asset Inventory

Your inventory should answer five questions for every in scope network asset: what is it, where is it, who owns it, what does it connect to, and how do you know the record is current? Include firewalls, routers, switches, wireless controllers, access points, VPN endpoints, load balancers, cloud networking resources, servers, appliances, and material third party connections. Add serial numbers or provider identifiers where they help distinguish one asset from another.

An audit ready record also needs context. Capture the business or technical role, environment, site, data sensitivity, support owner, lifecycle status, and last review date. Link the device to its interfaces, IP addresses, VLANs, racks, circuits, and upstream or downstream dependencies. This makes the inventory useful during an audit and during an incident, because the same relationships explain both control scope and operational impact.

Discovery tools can help you find what is live, but discovery is not the same as accountability. Reconcile scan results, cloud consoles, DHCP leases, procurement records, and rack walks against the authoritative inventory. Every unmatched device needs a decision: add it, investigate it, isolate it, or retire it. Record that decision and its owner so the exception does not disappear after the meeting.

Document Segmentation and Data Paths

Auditors need to understand how sensitive systems are separated and how traffic reaches them. Document the zones, VLANs, subnets, security groups, firewall boundaries, remote access paths, and trusted connections that matter to your scope. A logical diagram should make the permitted paths visible, while a physical or cloud view should show the infrastructure that carries them.

Keep a short explanation next to every important boundary. State what the segment protects, which identities or systems may cross it, what control enforces the boundary, and when the design was last reviewed. If a rule is intentionally broader than the normal pattern, link the exception to its approval, expiration date, compensating control, or risk acceptance.

The network record should agree with the implementation. Compare diagrams and IPAM data with firewall exports, switch configurations, cloud route tables, and identity access records. A diagram that says production is isolated while a forgotten management route bypasses the boundary is not a documentation problem alone. It is a control discrepancy that needs an owner and a remediation record.

Preserve Change and Review History

Static documentation shows the intended state. Compliance evidence also needs to show how the state changed and who approved it. Keep change requests, implementation notes, peer reviews, validation results, rollback plans, and closure evidence connected to the asset or network object they affected.

The useful question is not whether a diagram was edited. It is whether you can explain the transition from the old state to the new one. For a firewall change, that could mean the request, risk review, approval, rule owner, test result, and post change verification. For a new subnet, it could include the address plan, VLAN purpose, route change, DNS or DHCP updates, and the review that confirmed the segment belongs in scope.

Do not backfill a perfect history after the fact. If your records are incomplete, label the gap, document the recovery plan, and start producing reliable evidence now. Auditors generally learn more from an honest exception with an owner and due date than from an unexplained sequence of edits that looks complete but cannot be tied to an actual change process.

Show Access and Operational Ownership

Network documentation should make privileged access reviewable. Record which roles can administer firewalls, switches, wireless infrastructure, cloud networks, VPNs, DNS, DHCP, and the documentation system itself. The record does not need to contain secrets. It needs to identify the access path, owning team, approval authority, review cadence, and evidence that access was removed or changed when responsibilities changed.

Ownership matters just as much for ordinary records. Give each site, segment, device class, and critical connection a responsible team or person. A named owner can confirm whether a record is accurate, explain an exception, and close a finding. A shared inbox or an old job title usually cannot.

Treat third party links as part of the network story. Internet circuits, managed firewalls, colocation cross connects, cloud transit, remote support paths, and vendor tunnels can affect the boundary even when another party operates the equipment. Keep the provider, service identifier, purpose, endpoints, contract or SLA reference, and review owner linked to the connection.

Assemble the Evidence Pack

For each control or audit request, collect the smallest set of records that proves the point. A practical network evidence pack often contains the following:

• The approved system boundary and a current logical network diagram.
• An asset inventory with owners, locations, lifecycle state, and review dates.
• IP address, subnet, VLAN, DNS, and DHCP records for in scope environments.
• Segmentation diagrams and representative firewall or routing evidence.
• Access reviews for privileged network and cloud administration.
• Change records showing approval, implementation, validation, and closure.
• Monitoring, incident, recovery, and exception records connected to the affected systems.
• A review log that shows who checked the documentation and what was corrected.

Evidence should be attributable and time bounded. Record the source, collection date, period covered, reviewer, and relevant change or ticket identifier. Preserve the original export when practical, then keep your working summary linked to it. Screenshots can support an explanation, but they are hard to search, easy to age, and weak when they are not accompanied by source and date.

Keep Documentation Ready Between Audits

Audit readiness is a maintenance process, not a week spent polishing diagrams before the auditor arrives. Put documentation updates inside normal change work. Make an inventory update, relationship check, and owner confirmation part of the definition of done for network changes. Route exceptions to a queue with a due date, severity, and accountable owner.

A practical cadence can be simple. Check new and retired assets as changes occur. Review network changes monthly. Review privileged access, segmentation exceptions, and critical connections quarterly. Reconcile the full inventory at least annually and before a major audit or certification activity. Adjust the cadence to your risk, change volume, and auditor’s expectations rather than treating these intervals as a universal compliance requirement.

Track drift as a measurable condition. Useful indicators include the percentage of in scope assets with owners, the age of the oldest unreviewed diagram, the number of undocumented IP assignments, the number of open segmentation exceptions, and the share of changes that link to evidence. These metrics tell you whether the program is getting healthier, not just whether a document exists.

For teams that already maintain infrastructure records, Obelinf’s device inventory, network topology, and network audit use case can provide a connected place to maintain the records behind this process. The important outcome is not the tool name. It is that your inventory, relationships, changes, and review history stay close enough together to be checked before an audit request becomes urgent.

The Practical Takeaway

Good network documentation gives your compliance program a defensible account of what exists, what is connected, what can change, and who reviews it. Start with scope, establish an authoritative inventory, document segmentation and data paths, preserve change history, and attach each record to a person, source, and date.

Then test the trail. Pick one in scope system and follow it from the boundary statement to the asset record, topology, access path, change history, and review evidence. If the chain breaks, you have found the work that will make the next SOC 2 or ISO/IEC 27001 audit less dependent on memory and last minute reconstruction.