Most businesses use dozens of digital tools, and almost all of them get described the same way: "the systems". That flattens an important difference. Some of those tools are conveniences. If they vanish for a day, people grumble and find another way. Others are infrastructure. If they vanish, the business cannot take orders, pay people, ship goods or answer customers.
The distinction matters because infrastructure deserves a different standard of care: named ownership, monitoring, tested recovery, controlled change and a budget that does not depend on goodwill. Treating everything as infrastructure is unaffordable. Treating nothing as infrastructure is how a spreadsheet nobody has opened for a year ends up quietly holding the business together. This article offers a practical test for deciding which is which.
The core test: what stops, and how fast?
Ignore the product category. A system is infrastructure when the business's essential activities depend on it, whatever kind of software it is. The question to ask of each system is simple: if this were unavailable for a day, what would stop, and how quickly would the damage show?
Five tests sharpen the answer.
- Dependency. Do important outcomes, such as invoicing, delivery, payroll or compliance, rely on it directly?
- Breadth. Do several teams or other systems rely on it, or only one person?
- Substitutability. Could the work continue by hand or with another tool within hours, or would it take weeks to rebuild?
- Failure cost. Would an outage or corrupted data cost money, breach a legal duty or damage customer trust?
- Time sensitivity. Is the damage immediate, or does it build slowly?
A system that scores strongly on two or three of these is infrastructure in practice, even if nobody has ever called it that.
Why category is a poor guide
When owners are asked to list their infrastructure, they tend to name servers, networks, Wi-Fi and the email system. Those are real, but the list is usually incomplete in a specific way: it names technology and omits dependencies.
The national guidance on critical infrastructure published by the US Cybersecurity and Infrastructure Security Agency frames resilience in terms of knowing your infrastructure and its dependencies, understanding which risks matter most, planning, and tracking progress. The scale is very different from a small business, but the starting point is identical: you cannot protect what you have not identified as important. The same logic appears in NIST's Cybersecurity Framework, whose first practical step is to understand the assets and processes the organisation relies on.
Apply that to your business and the list changes. The shared mailbox that receives every purchase order is infrastructure. So is the payment gateway on the website, the integration that moves accepted orders into the accounting package, the domain name that email and the website both depend on, and the spreadsheet that calculates commission. None of them looks like infrastructure. All of them behave like it.
A classification you can use
A three-tier classification is enough for most firms. Put each system in one tier and write the reason beside it.
| Tier | Description | Examples | Standard of care |
|---|---|---|---|
| Foundation | Everything else rests on it. Outage stops the business within hours. | Identity and logins, email and domain, internet connectivity and power backup, core accounting and payroll, main operational platform | Named owner and deputy, monitoring, tested backups and recovery, change control, annual review |
| Operational | Supports a core process. Outage slows the business or forces manual work within days. | CRM, scheduling, e-commerce store, integrations between core systems, reporting layer | Named owner, documented configuration, basic monitoring, backups |
| Convenience | Useful, replaceable, limited blast radius. | Team chat add-ons, design tools, one-person trackers | Light ownership, reviewed at renewal |
The tiers are not permanent. A convenience tool becomes operational when three teams begin depending on it. The guide on when a spreadsheet is a useful tool and when it becomes infrastructure shows how that drift happens with the most common example.
The hidden infrastructure most firms miss
Integrations and automations
The connection between two systems is often more critical than either system alone. When it stops, both sides keep running and report no fault, while data quietly stops moving. These connectors rarely appear on any asset list, yet they decide whether the operation works.
Identity and access
The login system, whether Microsoft 365, Google Workspace or another directory, determines who can reach everything else. Lose control of the administrator account and every other system is at risk. It belongs in the foundation tier.
Domain names and certificates
A lapsed domain registration or expired certificate can take down both the website and the email system in one stroke. These are often registered under a former employee's or web designer's name and renewed by a card that expires without notice.
Power and connectivity
For South African firms, load-shedding turned electricity and connectivity from background assumptions into explicit dependencies. A system that is excellent but unreachable during a power outage is, from the business's point of view, down. Inverters, UPS capacity, fibre and a failover link are part of the infrastructure picture, not an afterthought.
Data that exists in only one place
A price list, customer master or configuration file that exists only on one laptop is infrastructure with no redundancy. The business may not notice until the laptop is stolen or fails.
What to do once you have the list
The classification is a means to an end. Once the foundation and operational tiers are identified, take five actions.
- Assign an owner and a deputy to each foundation and operational item.
- Confirm recovery. For each foundation item, check how it is backed up, who can restore it, and how long it would take. NIST's contingency planning guide for information systems exists because planning for recovery before an incident is far cheaper than improvising during one.
- Add monitoring where failure is silent, particularly for integrations and scheduled jobs.
- Put change control around them. A change to a foundation system should be described, tested and reversible.
- Budget for them as infrastructure. This means recurring maintenance, licences and renewal, not only a one-off purchase. The economics are laid out in why recurring systems maintenance is cheaper than emergency repair.
The NCSC's toolkit for boards makes the governance point that senior leaders should be able to say what the organisation depends on and how well it is protected. If you cannot name your foundation tier, that gap is the first finding.
An illustrative example
The following is a hypothetical case. A Bloemfontein distribution company lists its infrastructure as the office server, the router and the accounting package. A short review using the five tests adds the following: the shared orders mailbox, the integration that creates delivery notes from orders, a pricing spreadsheet held on the sales manager's laptop, and the web domain, which is registered in the name of a freelance designer who left two years earlier.
Each is rated by what would stop. The domain, the mailbox and the integration go into the foundation and operational tiers with owners, backups and renewal reminders. The pricing data moves from the laptop into a shared, backed-up location. The review took an afternoon and produced more risk reduction than any hardware purchase would have.
Keep the list honest
An infrastructure list drifts as quickly as any inventory. Review it every six months and whenever the business adds a major system, changes supplier, opens a branch or loses a key person. The method in how to identify the systems your business actually depends on gives a repeatable way to refresh it, and the wider picture is in what digital infrastructure means for a modern business.
Sources and further reading
- Cybersecurity Framework (last verified 10 October 2026)
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems - CSRC (last verified 10 October 2026)
- Cyber Security Toolkit for Boards (last verified 10 October 2026)
Related Mellorca reading
- How to Build a Business Application Inventory That Is Actually Useful
- How to decide what should be the system of record
- How to decide which system owns which data