Decision guide · Network and connectivity investment

A firewall refresh is a continuity decision wearing a hardware invoice.

Network spend usually gets triggered by a failure, an end-of-life notice, or a mildly alarming reseller pitch. The stronger question is which connectivity risk matters most to the business, in what order.

Frame the connectivity question

Every network purchase claims to be urgent. Not every one actually is.

Firewalls, Wi-Fi access points, and internet circuits age quietly until something fails - a vendor stops issuing security updates, a floor of new hires overwhelms wireless coverage designed for half the headcount, or a single ISP outage stops the business cold. The purchase that follows is usually reactive, sized to what a vendor is offering rather than to what the business actually depends on.

Network infrastructure investment deserves the same lens the site already applies to security spend: start from business consequence, not from whichever proposal is on the desk this week. A retail floor that can't process payments and a back-office file server that's briefly unreachable are not the same risk, even if both show up as "the network is down."

The decision is sequencing - which connectivity risk gets funded first, on what evidence, and who owns the result once it's in place.

Boundary

This is a leadership sequencing and decision-advisory lens. Network design, cabling, firewall configuration, and hands-on installation remain separately scoped technical and vendor work.

Connectivity categories

Different failure, different urgency.

Category	Consequence if it fails	Typical trigger to fund now	Common blind spot
Perimeter / firewall	An unpatched edge device becomes the way in.	Vendor end-of-life or support expiry notice.	Buying a bigger box without revisiting the rules running on it.
Wi-Fi & wired LAN	Staff or customer-facing devices can't reliably connect.	Headcount or device growth outpaces original design.	Coverage tested once, at move-in, and never since.
Internet & WAN links	The business stops entirely when the link drops.	A single-provider outage causes a real disruption.	Assuming failover exists because two lines appear on an invoice.
Remote & site-to-site connectivity	Remote staff or a second site can't reach core systems.	A new location, acquisition, or remote-work shift.	VPN capacity sized for a much smaller team than it now serves.

Decision lenses

Six questions before the next network purchase.

Business consequenceWhat actually stops working, and what does that cost per hour?
Single points of failureWhere does redundancy exist on paper but not in practice?
Growth headroomWas this sized for the team that exists now, or the one from three years ago?
Vendor support lifecycleWhen does the current hardware stop receiving security updates?
Failover realityHas the backup path actually been tested, or only assumed?
Ongoing ownershipWho monitors and maintains this once it's installed?

Working process

Rank by consequence before comparing quotes.

Map what depends on connectivity
By location and function - payments, production systems, remote access - not just "the network."
Rank by consequence
Order the list by business impact, not by which vendor called first or which box is oldest.
Test failover assumptions
Confirm a backup path actually works before funding a second one on faith.
Assign ongoing ownership
Name who monitors, maintains, and renews - before the purchase, not after installation.

The same evidence-first sequencing already applies to security spend

Hypothetical pattern

Two internet lines, one point of failure

The business believes it has failover because two internet circuits appear on the invoice. Neither anyone has verified is that both lines enter the building through the same conduit, from the same local exchange - so one dig, one outage, takes down both at once. The useful decision isn't a third line; it's testing the assumption before the next storm proves it wrong.

See how this plays out during a new-site setup

Next step

Bring the network purchase that's been deferred one more quarter.

A focused brief can turn a vendor pitch into a consequence-ranked list with an owner for what gets funded.

Build the priority brief

Every network purchase claims to be urgent. Not every one actually is.

Map what depends on connectivity

Rank by consequence

Test failover assumptions

Assign ongoing ownership

Two internet lines, one point of failure

Bring the network purchase that's been deferred one more quarter.

Get IT decisions made, and made to stick.

Related services