How to Explain to Management Why Cabling Is a Security Spend

When a network outage hits, the first questions are usually about applications, servers or the internet connection. Yet the cause may be much closer to the floor: a damaged cable, an overloaded patch panel, an unmanaged switch tucked under a desk or a network design that nobody can confidently describe.

That matters to security as much as availability. Physical infrastructure carries the traffic that firewalls inspect and endpoint detection platforms monitor. If the underlying network is unreliable, poorly documented or impossible to segment properly, security controls have less trustworthy information to work with.

For management, the challenge is to make the case without presenting cabling as a technical tidy-up. The stronger argument is that investment in cabling, switching, documentation and design reduces business risk. It protects the organisation’s ability to operate, contain incidents and understand what is connected to its network.

Start with the business risk, not the cable

“We need to replace the cabling” is not, by itself, a compelling management case. It sounds like maintenance that can be deferred. A better risk explanation connects the state of the physical network to outcomes leaders recognise: disrupted operations, delayed recovery, uncontrolled access, compliance exposure and higher incident costs.

Physical infrastructure is part of cybersecurity, not a separate facilities concern. A network is a chain of dependencies: structured cabling connects devices to switches; switching implements network access and segmentation; routing and firewalls control traffic between environments; monitoring tools rely on that traffic being visible and correctly identified. A weakness at the physical layer can undermine the controls higher up.

This does not mean every old cable is a security incident waiting to happen. It means that unknown, unreliable or poorly managed infrastructure makes risk harder to control. If the business cannot establish which device is connected to which port, what network it belongs to, or whether an unexpected connection is legitimate, its ability to investigate and respond is reduced.

Explain how physical faults become security problems

Outages can hide the real cause

A damaged cable or failing switch often appears first as an ordinary performance issue: an intermittent connection, dropped calls, an unreliable industrial device or a workstation that repeatedly disconnects. These faults can trigger workarounds, including moving equipment to a convenient port or adding a small switch to get more connections. The immediate problem may go away, but the network becomes less predictable.

That unpredictability has a security cost. Troubleshooting becomes slower when diagrams do not match reality, patch panels are unlabelled and the path between a device and its network is unclear. During an incident, responders may waste time working out whether a device is isolated, which systems share its segment, or where to safely disconnect it. At 2am, when a service is down and the usual specialist is unavailable, those minutes matter.

Blind spots weaken detection and investigation

VLAN segmentation

Security tools need reliable network context. Firewalls can enforce rules between networks, and endpoint detection platforms can alert on suspicious activity at supported endpoints. But those controls do not magically fix an unknown topology. If traffic bypasses expected inspection points, an endpoint is attached to the wrong segment, or a switch has no usable management information, investigators may not have a clear account of what communicated with what.

Physical-layer faults can also produce misleading symptoms. Packet loss or flapping links may look like application instability, while a poorly understood switch configuration can make monitoring incomplete. The point for management is not that cabling directly detects threats. It is that sound infrastructure makes security controls more dependable and incident evidence easier to interpret.

Segmentation needs capable switching and correct design

Network segmentation is often discussed as though it were simply a firewall purchase or a configuration change. In practice, segmentation depends on suitable switching, a coherent design and accurate implementation from the access layer upwards. The network needs to put the right devices into the right zones and maintain the intended separation as users, systems and sites change.

That can include separating corporate IT from operational technology, isolating guest access, limiting management interfaces and keeping sensitive systems away from general-purpose devices. The specific design should reflect business processes and operational safety; there is no universal VLAN diagram that solves every organisation’s problem.

Switch capability matters. Depending on the design, the organisation may need managed switches, appropriate security features, reliable configuration backups, central visibility and support for the required VLANs and access controls. Unmanaged switches in production are a particular concern: they can create opaque connections that are difficult to monitor and may defeat the intent of a carefully planned design.

Correct design matters just as much as hardware. Creating separate network segments but allowing unrestricted communication between them is not meaningful containment. Nor is a design robust if nobody knows which ports serve critical equipment, or if a contractor can connect a device to an unreviewed point in a sensitive area.

Companies such as Cisco, Garland and MOXA operate in different parts of the networking market, including enterprise networking and industrial connectivity. Their products may be relevant in different environments, but the management case should not hinge on a brand name. Specify the capabilities, support model, lifecycle and security requirements first; then choose products that fit the organisation’s standards and operational needs.

Connect the investment to recognised security practice

Australian organisations often look to the Australian Cyber Security Centre (ACSC) for practical security guidance. ACSC guidance addresses broader cyber security practices, such as managing systems, controlling access, reducing exposure and preparing to detect and respond to incidents. Those practices assume that an organisation can identify and manage the technology on its network.

That is where solid network foundations come in. A current asset view, documented connectivity, controlled switching and deliberate segmentation help make security practices workable. They do not guarantee compliance or prevent every incident, and cabling alone should not be presented as an ACSC requirement. The honest argument is that reliable, understood infrastructure supports the implementation and operation of security controls described in recognised guidance.

For management, this distinction is useful. It avoids overstating a standard or claiming that a specific cabling project is mandated when it may not be. Instead, show how the proposed work closes a documented gap in the organisation’s ability to manage access, maintain availability, monitor the environment or respond to an event.

Make the financial case in terms leaders can assess

A credible security budget proposal compares the cost of planned infrastructure investment with the cost and likelihood of avoidable business disruption. The numbers will vary, but the method can be straightforward.

Describe the exposure. Document the affected sites, ageing or unsupported equipment, unidentified connections, recurring faults and missing network records. Separate verified facts from assumptions.
Explain the business consequence. Identify which services, teams, customers or production processes depend on the affected network. Estimate the impact of an outage or delayed incident response using the business’s own measures.
Show how the investment changes the risk. For example, replacing unsupported access switches may enable controlled segmentation and central monitoring; relabelling and documenting connections may reduce isolation and recovery time.
Compare practical options. Present a phased approach where possible, including the cost and residual risk of doing nothing. A focused upgrade to high-impact areas may be more realistic than replacing everything at once.
Define how success will be measured. Agree on outcomes such as fewer repeat link faults, a verified network diagram, reduced unsupported equipment, documented critical ports or successful testing of isolation procedures.

Management concern Infrastructure response Example measure Service interruption Replace failing links and equipment; document critical paths Repeat faults, recovery time, availability of priority services Uncontrolled access Remove unauthorised switches and establish managed access Unknown devices or connections found during reviews Limited incident containment Design and test network segmentation Time to identify and isolate an affected segment Unclear operational ownership Maintain labels, diagrams and configuration records Percentage of critical links and ports verified

Show what a responsible project includes

“Cabling project” can be an overly narrow label for the work required. A well-scoped infrastructure investment may cover structured cabling, patch panels, rack organisation, managed switching, configuration standards, network diagrams, testing and the removal of unauthorised equipment. It should also establish who owns ongoing changes and how new connections are approved.

Labelling is not glamorous, but it is operationally valuable. A label maker in the laptop bag is not a security strategy on its own; consistent port labels, updated records and a change process are. Mystery cables should be treated as a reason to investigate, not as an invitation to unplug things and hope for the best.

Build security and resilience checks into the work. Confirm that switch management is restricted, default credentials are changed, firmware and support status are reviewed, configurations are backed up, and the proposed segmentation is tested. Plan for maintenance windows, rollback and verification, especially where operational technology or essential services are involved.

Give management a clear decision

A useful proposal ends with a decision management can make: approve a defined scope and budget, assign an accountable owner, and agree on risk acceptance for anything deferred. Avoid promising that the work will “make the network secure”. Security is an ongoing practice involving people, process and technology. The more defensible claim is that this investment will improve visibility, reduce specific failure modes and make other security controls more effective.

Keep the risk explanation practical. Show a map of the current and proposed design, identify the most consequential unknowns, and describe what a failure or incident would look like in each case. Where possible, use evidence from fault tickets, asset records, site surveys and configuration reviews rather than relying on general statements about age or best practice.

Infrastructure is a security control you can see

Cabling is easy to overlook because it sits behind walls, beneath floors and inside racks. But it is the physical path for the systems the business depends on. When that path is unreliable or poorly understood, outages take longer to resolve, segmentation becomes harder to trust, and security teams have less context when something goes wrong.

The management case is therefore not “buy new cables because old cables are untidy”. It is: invest in dependable, documented and appropriately segmented infrastructure so the organisation can operate reliably, enforce security controls and respond with confidence. That is a security budget conversation—and a practical infrastructure investment in the business’s ability to manage risk.