Safeguard 12.4 Network architecture diagrams guide

What Safeguard 12.4 network architecture diagrams require in practice

If an auditor, a customer questionnaire or an IG2 adoption decision asks for current network documentation, the answer you need is that Safeguard 12.4 requires network architecture diagrams or other network system documentation to be established and maintained, reviewed and updated annually or sooner when significant enterprise changes could affect it. It is the documentation counterpart to the secure network architecture designed under Safeguard 12.2, so the diagrams must describe a design that actually exists. In the CIS Controls v8.1 assignment, 12.4 sits in the Documentation asset class and the Govern security function, and it applies from Implementation Group 2 upward, not to IG1. The Assessment Specification lists no prerequisite safeguards for measuring it, so an assessor tests the document directly. If no network architecture documentation exists, the safeguard scores as a failure, regardless of how well the network is designed.

The hard part is rarely drawing the first diagram. Diagrams drift from the live network within weeks of a firewall change, a new VLAN, a cloud subnet or a retired site, and nobody is assigned to notice. Start by naming an owner for the document, usually the network architecture lead or platform engineering manager, and writing the annual review date into the change calendar. Require that any change record touching segmentation, routing, remote access or internet edges references the diagram it modifies, so the significant-change trigger in the Safeguard fires from a real event rather than memory. Confirm with your assessor what counts as significant for your environment, since the Safeguard does not define a threshold.

Store the documents where version history is kept. A wiki such as XWiki records what changed, when and by whom, and can compare or restore earlier versions, which gives an assessor a dated trail showing reviews actually happened. BookStack lets you limit who can edit network pages through role permissions at the shelf, book or page level, so reviewers can be separated from editors. Asset data can support the diagrams: GLPI's Assets module holds network equipment and racks, and Wazuh's Syscollector collects network interfaces and open ports from endpoints, which lets you check that the documented topology still matches what is connected. Treat tooling as evidence support only. The diagrams must still be reviewed by a person who can explain them, and you should confirm with your assessor which artifacts they expect to see.

How an assessor tests network architecture documentation

This table walks through how an assessor approaches Safeguard 12.4 under the CIS Controls Assessment Specification, the evidence to prepare, and the findings that most often cause a failing result. Read it as a pre-assessment checklist: each row names what the assessor looks for and what your team should be able to show before the assessment starts.

Assessment step	What the assessor checks	Evidence to have ready
Existence of documentation	Whether network architecture documentation exists at all. The assessment specification gives a failing score when none is present, so this is the first gate.	Diagrams or other network system documentation covering the enterprise network, in a format the team can produce on request.
Currency against the live network	Whether the documented topology matches the network as it runs today, including segments, zones, firewalls, cloud networks and remote access paths.	A walkthrough of the diagrams against current inventory or discovery output, with discrepancies logged and corrected.
Annual review cycle	Whether the documentation was reviewed and updated at least annually, and sooner after significant enterprise changes such as mergers, new sites or major migrations.	Dated review records, change tickets linked to documentation updates, and a list of significant changes in the period.
Version history	Whether the team can show what changed, when and by whom, so the assessor can trace the current version back to earlier reviews.	Revision history from the documentation platform or source repository, with named reviewers and approval records.
Coverage of segments	Whether diagrams show every network segment in scope, including management networks, guest networks, DMZs and connections to third-party or cloud environments.	A segment register that matches the diagrams, plus a note of any segment deliberately excluded and the reason.
Access to the documentation	Whether the documentation is controlled, so only authorized staff can read or change it, and so the assessor can access it during the assessment.	A list of roles with read and edit rights, and a record of how access is granted and removed.
Common findings	Undated diagrams, missing review records, diagrams that omit segments added after the last review, and documentation that exists only in one person's files.	A pre-assessment self-check against each row above, with gaps assigned to owners and dates before the assessor arrives.

Building and maintaining network diagrams step by step

This sequence turns network documentation into a maintained, owned and linked record of the enterprise network, so that the diagrams an assessor reviews match the systems that actually run. Each step ends with a named output that can be checked before the next step begins.

Define the documentation scope
Name the networks, sites, cloud accounts, data center zones and network segments that the documentation covers, and list the ones that are excluded with a reason. Involve the network engineering lead and the owners of cloud accounts so that no in-scope environment is missed. The output is a scope statement that lists each network, site, account and segment by name, approved by the person accountable for network security. Confirm that the scope matches the asset inventory described in Control 1 so the two records do not disagree.
Assign an owner and review date
Appoint one named owner for the network documentation and a backup who can act when the owner is unavailable. Record the annual review date and the criteria for an earlier review, such as a merger, a new cloud region or a change to the perimeter. The output is a document control block on the first page of the documentation that shows the owner, the approver, the last review date and the next due date. An assessor will look for this block to confirm accountability.
Export the architecture from a source of truth
Build the diagrams from a system of record rather than from memory. Use the configuration management database or asset module, device inventories, routing and switching configurations, firewall rule exports, cloud network definitions and infrastructure-as-code repositories, depending on what the enterprise holds. Where the source of truth is missing a device or link, record the gap and correct the source. The output is a set of diagrams and a list of data sources with the date each was exported, so a reviewer can trace each line on the diagram back to a record.
Record the documentation in a controlled location
Store the diagrams and supporting network documentation in one controlled repository with access limited to people who need it, since network maps are sensitive reconnaissance material. Keep version history so that every change shows what changed, when and by whom, and so that earlier versions can be restored. The output is a published location, a stated access policy and a visible version history for each diagram. A wiki with version control or a document repository with change tracking can meet this need; confirm the chosen product supports both features before you rely on it.
Link the diagrams to the 12.2 design and policy
Cross-reference each diagram to the secure network architecture design described under Safeguard 12.2, including the segmentation rules, trust zones and least-privilege principles the diagram is meant to show. Add references to the network security policy and the standards that govern each zone. The output is a document index that connects each diagram to its design rationale and policy clause, so a reviewer can follow a control from the written requirement to the drawn topology.
Verify the diagrams against live configuration
Before approval, compare the diagrams with the running environment. Sample a set of devices, subnets and cloud routes and confirm that each appears on the diagram with the correct addressing and connections. Record any mismatch as a finding, correct either the diagram or the configuration, and repeat the check on the corrected items. The output is a signed verification record that lists the sample, the result and the corrections made, which gives the owner evidence that the documentation was checked rather than assumed to be accurate.
Approve and publish the annual review
Route the verified documentation to the approver named in step two and record the approval with a date. Publish the approved version and retire the superseded one in a way that keeps it available for audit history. Schedule the next annual review in the calendar of the owner. The output is an approved, dated version and a review record that an assessor can compare against the review date set earlier in the cycle.
Trigger out-of-cycle updates after significant change
Define the changes that force an update before the annual review, such as a new site, a new cloud account, a change to segmentation, a new remote access path or the retirement of a network zone. Connect these triggers to the change management process so that the network owner is notified when a qualifying change is approved. The output is a written trigger list and a record showing that each significant change produced either an updated diagram or a documented decision that no update was needed.

Evidence that passes a Safeguard 12.4 review

Safeguard 12.4 is judged on whether the documentation exists, is current and is tied to the real network. The cards below cover the artifacts an assessor typically asks for, what each one proves and where it tends to fail. Read them together: a diagram without history, review records or an inventory reconciliation is hard to rely on.

Current diagrams with version and date

The assessor starts with the architecture diagrams or other network system documentation themselves. Each diagram should carry a version number, a date and an owner, and should show the segments, zones, firewalls, routers, wireless networks, remote access paths and connections to cloud or third-party networks. Check that the diagram matches the current design, not a template from the original build. A diagram with no version or date is the most common reason a reviewer cannot tell whether it is current.

Page history showing changes

A wiki or documentation platform should keep every revision, recording what changed, when and by whom. The assessor compares the history with the period under review to confirm that the documentation was maintained rather than written once. Gaps in the history, bulk edits that overwrite earlier versions, or edits made outside the platform weaken this evidence. Confirm that the platform retains older versions and that the retention setting has not been reduced.

Approval and annual review records

Safeguard 12.4 calls for a review and update at least annually. Keep a dated record of each review showing who reviewed the documentation, what they confirmed and which changes they approved. Sign-off in a ticket, a meeting minute or an approval workflow all work if they are retained. An assessor will look for a review within the last twelve months and will ask whether the reviewer had the authority and knowledge to approve it.

Change records that trigger updates

The safeguard also requires updates sooner when significant enterprise changes could affect the network, such as a new site, a merger, a cloud migration or a firewall replacement. Link each significant network change ticket to a documentation update, and record the date the diagram changed. Assessors often sample recent network changes and check whether the diagrams moved with them. A missing link between change tickets and documentation updates is a common finding.

Reconciliation with the device inventory

Diagrams are only as credible as their match to the live network. Compare the devices and subnets on the diagram with the network equipment, IP ranges and interfaces in your inventory. Discrepancies, such as an unlisted firewall or a subnet that appears in the inventory but not on the diagram, should be recorded with an owner and a closing date. Inventory tools can supply the data for this comparison, and the reconciliation itself becomes evidence. Confirm which inventory source your organization treats as authoritative before you start.

Keeping network documentation current between audits

Architecture diagrams go stale quietly. A firewall is replaced, a new segment is added for a project, or a cloud subnet is peered with a partner, and the diagram still shows last year's design. Safeguard 12.4 asks for diagrams or other network system documentation to be established and maintained, with a review and update at least annually, or sooner when significant enterprise changes could affect it. An assessor will not accept a diagram that was accurate once. The practical question is which process keeps it accurate between reviews, and the answer is almost always the organization's own change management and asset inventory, not the diagram tool.

The most reliable control is to make the diagram part of the change record. Every change ticket that adds, removes or re-routes a network device, segment, gateway or external connection should name the documentation it affects and require the owner to update it before closure. A monthly or quarterly reconciliation then compares the diagram against the device inventory, for example a GLPI Assets export of network equipment or a Wazuh Syscollector view of interfaces and open ports, and logs every mismatch as a finding. Ask your team to confirm which source is authoritative for each device type before the first reconciliation, because two inventories that disagree will produce disputes rather than evidence. Version history in a wiki such as XWiki or BookStack gives the assessor a dated trail of who changed what and when.

The review calendar needs a named owner, a visible due date and an escalation path, because an annual obligation with no reminder is usually the first thing missed. Keep the calendar with the document itself, and record each review as a dated entry that states the reviewer, the scope and any corrections made. Confirm with your assessor how they will sample reviews and whether they expect evidence of event-driven updates as well as the annual cycle. Because the Assessment Specification lists no prerequisite safeguards for 12.4, nothing outside your own processes will enforce this work. Plan for the change and inventory practices to exist first, and budget internal time for the reconciliation, which recurs for as long as the network changes.

Open-source tools that keep network documentation current

Safeguard 12.4 asks for network architecture documentation that is kept current, with a review at least annually or sooner after significant change. The four tools below cover different parts of that job: versioned text, access control over who edits it, an inventory of network equipment, and a record of what each endpoint actually listens on. None of them draws diagrams or replaces a human review.

Version-controlled documentation with XWiki

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one, which gives an assessor a dated trail of each annual review. Check that the wiki holds the design narrative, assumptions and approval records, and that diagram exports are attached or linked with their revision. Confirm the LGPL-2.1-or-later license terms with the project before deployment.

Role-based editing with BookStack

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. That lets you restrict who may edit the network architecture book while leaving it readable to auditors and operations staff. It does not decide who is accountable for the annual review, so record that owner in the page itself. Confirm the MIT license terms with the project before deployment.

Network equipment records in GLPI Assets

GLPI's Assets module records network equipment and racks, entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. Linking device records to the documented architecture lets you check that every routed device on the diagram exists in the inventory and the reverse. GLPI does not discover topology on its own, so confirm which fields your team maintains and who approves changes. Confirm the GPL-3.0-or-later license terms with the project before deployment.

Observed services with Wazuh Syscollector

Wazuh Syscollector collects network interfaces, open ports, running processes and services from each endpoint and stores them in the Wazuh indexer for inventory views and reports. Comparing these records with the documented addressing and service placement shows where the running environment has drifted from the diagram. Syscollector reports what endpoints expose, not what the design intended, so the comparison and its follow-up remain a human task. Confirm the GPL-2.0-only license terms with the project before deployment.

What network documentation costs to keep current

This table breaks the cost of keeping Safeguard 12.4 diagrams current into components, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to shape a written scope before asking a partner for a quote, since the largest recurring cost is usually the annual review and reconciliation work rather than the software.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up
Documentation platform and drawing tools	Software vendor or internal IT, where licenses apply	Recurring if commercial, one-time setup if self-hosted	Number of users editing diagrams and whether a commercial drawing tool is required
Initial diagram creation	Internal network engineers or a partner under a fixed scope	One-time	Number of sites, network segments, cloud accounts and undocumented legacy links
Inventory tooling setup	Partner or internal platform team to connect discovery and inventory sources	One-time setup, with recurring tuning	Count of discovery sources such as network devices, endpoints and cloud accounts
Reconciliation against live networks	Internal engineers, usually with inventory exports	Recurring, typically at each review and after major changes	Drift between documented and live topology, and the number of unmanaged devices
Annual review cycle	Named document owner and reviewers in network and security teams	Recurring, once per year at minimum	Scope of diagrams, number of reviewers and whether sign-off is formal
Change process integration	Internal change management and network operations	Recurring, with one-time process design	Change frequency and whether diagram updates are a required step in change tickets
Version control and access settings	Internal IT administrators	One-time configuration, with occasional maintenance	Number of roles needed to separate editing, approval and read access
External review or assessor sampling	Independent auditor or assessor, who is paid for the audit itself	Recurring at each assessment cycle	Number of diagrams and documents sampled and how well the change history answers questions

In-house team, implementation partner and auditor for 12.4

The organization owns its network architecture documentation. Its own staff decide what the diagrams must show, who approves them, how often they are reviewed and which changes force an update. Ownership cannot be handed to a vendor, because the diagrams have to describe the enterprise as it is run, and only the people running it know which segments, zones, links and dependencies are real.

Diagram content: network engineers define the zones, segments, firewalls, routed paths, cloud connections and external links that the diagrams and related documentation must show.
Review calendar: a named owner schedules the annual review that Safeguard 12.4 asks for and records each review date and approver.
Change triggers: the team defines which significant enterprise changes, such as a merger, a new cloud region or a new segment, must prompt an update before the annual cycle.
Approval and sign-off: a documented approver accepts each revision, so the record shows who accepted the design and when.
Ongoing accuracy: change tickets from networking and security operations are checked against the documentation so drift is caught between reviews.

Before engaging any partner, confirm that a named person in the organization can explain every diagram and has the authority to approve it.

Where Safeguard 12.4 stops and 12.2 begins

Safeguard 12.4 asks for network architecture diagrams or other network system documentation to be established and maintained, with a review and update at least annually or sooner when significant enterprise changes could affect it. Safeguard 12.2 asks for something different: a secure network architecture that addresses segmentation, least privilege and availability, backed by policy and design. The two are separate pass or fail tests, so an enterprise must satisfy both. A team with a well-designed network but no current diagrams fails 12.4, and a team with polished diagrams that show flat, unsegmented networks fails 12.2.

The practical boundary is what the artifact has to prove. For 12.4, the question is whether a current record of the network exists: subnets, zones, firewalls, routed paths, cloud VPCs and the links to on-premises sites, each with an owner and a last-reviewed date. For 12.2, the question is whether the design itself is sound: which zones can reach which, whether administrative paths are isolated and whether the design survives a device or link failure. A diagram can show segmentation without proving it works, so the design decisions and their policy basis belong in 12.2 evidence, while the diagram and its revision history belong in 12.4 evidence. Confirm with your assessor how they expect each artifact to be cross-referenced.

Safeguard 12.3 covers how infrastructure is managed securely, for example through version-controlled infrastructure as code and secure management protocols such as SSH and HTTPS. A common overlap is configuration-as-code repositories that double as diagrams. They can support 12.4 if they are current and reviewed, but they do not replace the readable architecture view that 12.4 expects. Decide early which record is the authoritative diagram, where it lives and who approves changes to it, so that 12.3 change control feeds the 12.4 review cycle rather than running in parallel.

Why network documentation fails review and how to close each gap

Safeguard 12.4 is judged on whether network documentation exists, is current and matches the network that is actually running. Most failed reviews trace back to a small set of gaps that look minor on their own but signal that the documentation is not maintained. Work through each card below and confirm the closing action with the assessor's expectations before the review.

Diagrams with no date or owner

A diagram without a revision date, a version number or a named owner cannot show that it was reviewed in the last year, which is the cycle Safeguard 12.4 expects. Reviewers often ask who approved the current version and when. Close this gap by adding a revision block to every diagram with the version, date, author and approver, and by assigning one accountable role to each network domain.

Documentation stored in one drawing file

When the only copy of the architecture sits in a diagram file on one laptop, the documentation is lost if that person leaves or the machine fails, and no one else can prove what changed. Store source files and exports in a controlled repository or wiki with access control. Check that a second authorized person can open, edit and export every current diagram without help from the original author.

Reviews that change nothing

An annual review that signs off the same diagrams without comparing them to the live network produces no evidence of maintenance. Assessors look for recorded changes between review cycles and for notes showing that the reviewer checked the content. Close this gap by having the reviewer walk the diagram against current configurations, record each correction, and keep the prior version so the difference is visible.

Cloud and remote segments left out

Diagrams that show only the data center miss cloud virtual networks, VPN concentrators, remote access paths and third-party connections. These are the segments most likely to have changed since the last review. Trace one traffic path from a remote user to a cloud workload and confirm every hop appears on the diagram, including the identity and access points that control entry.

No link to change management

If network changes go live without updating the documentation, the review is always behind the network. Tie the documentation to the change process by requiring that every approved change that alters a segment, path or device role also updates the affected diagram before the change is closed. Ask for a sample of recent changes and check whether their documentation was updated.

No reconciliation with inventory

Diagrams can list devices that no longer exist or omit devices that were added through automated provisioning. Compare the documented devices with the asset inventory and the network discovery results, then resolve each difference by updating the diagram or the inventory. Open-source inventory tools such as GLPI and Wazuh can supply the device and interface data for this comparison, but the reconciliation step and its record remain the organization's responsibility.

Network architecture diagram questions buyers ask

Does an IG1 organization have to meet Safeguard 12.4?

No. Safeguard 12.4 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 covers essential cyber hygiene and is the minimum standard for every enterprise, so an IG1 organization can leave 12.4 out of its first scope. Organizations that are still growing their network, or that hold sensitive data and expect to move to IG2 soon, often document their architecture early anyway because it makes the later work cheaper. Confirm your Implementation Group against the CIS Controls Implementation Groups pages before you set scope.

How long does it take to document our network architecture?

The duration depends on scope: how many sites, segments, cloud accounts and devices the diagrams must cover, how current the existing material is, and how many people must confirm it. A fixed-scope engagement at DeployOpen starts from a written scope, and the partner quote should state the timeline, deliverables and what the client must provide in writing before work begins. Ask for the timeline to be tied to named inputs, such as access windows and review dates, rather than to an open-ended effort.

Can our in-house team maintain network architecture documentation without an outside partner?

Yes, provided the team names a documentation owner, agrees on what the diagrams must show, and has tools that keep the records current. A wiki or document platform with version history, such as XWiki, records what changed, when and by whom, and BookStack lets you limit who can edit each shelf, book or page. An asset inventory such as GLPI, and an endpoint inventory such as the Wazuh Syscollector module, can supply the device and interface data that diagrams and reviews depend on. Many teams do the first version internally and bring in a partner only for the gaps.

What does the work require from our team?

The work needs four inputs. First, read access to network configurations, cloud networking settings, firewall rules and inventory exports, so the documentation reflects what runs rather than what was planned. Second, named owners for each site, segment and platform who can confirm the design and approve changes. Third, change records from the last review period, so the team can see what moved and why. Fourth, a decision on where the documentation lives and who can edit it. Ask the partner to list these inputs in the written scope so that delays are visible early.

What drives the cost of network architecture documentation?

Cost follows the size and state of the network. The main drivers are the number of sites, segments, cloud accounts and environments in scope, the age and accuracy of existing diagrams, the number of systems that must be inventoried, and the number of reviewers needed for sign-off. The one-time cost covers the initial build, the tooling setup and the review cycle; the recurring cost is the annual review and any update triggered by significant enterprise changes. In a quote, ask for the cost split between the initial build, the tooling, and each annual review, and for the assumptions behind the scope.

Can a partner issue a certificate or attestation that our network documentation meets CIS Safeguard 12.4?

No. A partner such as DeployOpen prepares systems, controls and evidence, but only an independent auditor or certification body issues reports or certificates. CIS itself does not certify organizations against the Controls; its accreditation program covers CIS SecureSuite member organizations that provide implementation, auditing or assessment services. Where a customer or regulator asks for proof, the organization should agree with its assessor in advance which documents, reviews and approval records will serve as evidence, and the partner's role is to prepare them.

How do we keep network architecture documentation current after the project ends?

Set a named owner, an annual review date and a rule that any significant enterprise change, such as a new site, cloud account, segment or vendor connection, triggers an update sooner. CIS asks for the documentation to be reviewed and updated annually or sooner when significant changes could affect the safeguard. Keep the diagrams in a version-controlled platform so each review leaves a record, and reconcile them against the asset inventory and endpoint inventory so drift is visible. A retainer with a partner can cover the periodic review and continuous testing if internal capacity is limited.

How DeployOpen scopes and prepares 12.4 evidence

DeployOpen helps teams that own their network documentation prepare the diagrams, supporting records and review routine that Safeguard 12.4 asks for. The organization keeps ownership of its controls, while DeployOpen plans and builds the documentation system inside the client's own environment and hands over the evidence for review.

How we scope

We confirm which networks, sites, cloud accounts and segments the 12.4 documentation must cover.
We agree in writing which diagram types and supporting network system records are in scope.
We define the annual review cycle and the significant-change triggers the enterprise will follow.

How we build

We set up a self-hosted wiki or documentation platform inside the client's infrastructure with version history enabled.
We configure roles and page permissions so only authorized staff can edit architecture documents.
We connect inventory data from GLPI or Wazuh so diagrams can be checked against recorded network assets.

How we hand over

We deliver the documentation structure, role setup and review checklist as written, client-owned artifacts.
We provide a version history and review record that shows who changed each diagram and when.
We document how the client's assessor or auditor can access the evidence, which the independent assessor then tests.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
We can help run the annual review and update diagrams after significant network changes, as the scope defines.
Assessment decisions and any certification or report remain with the client's independent assessor or auditor.