Offline by Design: Cloud Only Where the Business Demands It

Illustration for: Offline by Design, cloud only where the business demands it

Somewhere in the last decade the question flipped. It used to be “why would this need to leave the building?” and it became “why on earth would you run that yourself?” Nobody signed that decision off. It arrived one subscription at a time, and most organisations have never gone back and checked whether the default still serves them.

This post argues for reversing the default, which means self-host first and use SaaS or IaaS only where there is a genuine business must. Not because the cloud is bad, but because “everything in the cloud” was never a risk decision. It was a procurement habit.

The default flipped without a risk assessment

Ask to see the risk assessment that moved your organisation’s data into fifty different vendors’ hands and you will usually find there isn’t one. Individual tools were approved one by one, each decision small and reasonable. A design tool here, a survey platform there, a note-taking app someone’s team adopted on a free tier. The aggregate position, hundreds of suppliers holding fragments of your data under dozens of jurisdictions and subprocessor chains, was never assessed by anyone because it was never proposed by anyone.

That is the quiet problem with cloud by default. Each choice is defensible. The sum is not something anyone chose.

What “offline” actually means

Before the argument, the definition, because the word gets abused. Offline does not mean your organisation has no internet. It means the workload lives entirely within your network and functions there on its own.

• No inbound access from the internet. The application is reachable only from inside your network, or over remote access you control. There is no public login page for anyone to attack.
• No outbound calls to the vendor. No telemetry, no usage analytics, no crash reporting, no background connections you did not configure. If a packet leaves your network, it is because you switched something on.
• No call home for licensing. This is the one to check hardest, because it is where “on-premise” products quietly cheat. Software that must contact a licence server every week to stay running is not offline. It is a remote kill switch you have installed voluntarily, and it fails exactly when the vendor has an outage, gets acquired, or decides your contract renewal needs encouragement. Licensing should work by a token or key you can apply with no connection at all.
• Updates happen on your terms. New versions are something you fetch, verify and apply when you choose, not something pushed into your estate on the vendor’s schedule.

The test is simple. Unplug the WAN and watch what breaks. Genuinely offline software keeps working indefinitely. The strictest form of this is full air-gapped operation, which regulated and classified environments already require, but even where you never intend to air-gap, software built to that standard tells you something important about it. It has no hidden dependencies, because it cannot have any.

What you actually hand over

When a workload moves to someone else’s infrastructure, you exchange a set of problems you can see for a set you cannot.

Custody of the data

Your data now sits under the vendor’s controls, their staff access policies, their subprocessors, and whichever legal jurisdictions apply to all of the above. You can audit a contract. You cannot audit what you cannot see.

Your attack surface becomes their attack surface

Every vendor with your data is a route to you. You inherit their patching discipline, their identity security, and their incident response, without visibility into any of it.

Availability on someone else’s terms

When it goes down, your recovery plan is a status page and a refresh button.

Exit costs

Data formats, integrations and workflows accrete around the service. The longer you stay, the more expensive leaving becomes, and pricing tends to reflect that.

None of this is hypothetical. The MOVEit compromise in 2023 reached more than 2,500 organisations through a single file transfer product, most of whom had never heard of the tool because a supplier of a supplier used it. The Okta support system breach the same year turned one vendor’s helpdesk into an identity risk for thousands of customers. And the CrowdStrike outage of 2024 grounded flights and closed surgeries without a single attacker involved. Third-party concentration is now a headline risk class in its own right.

A simple test, business must or business convenience

The point is not to abandon the cloud. It is to make each workload pass a test before it leaves your network. Four questions do most of the work.

1. Does it serve the public at unpredictable scale? A customer-facing website or product with real elasticity needs is a legitimate cloud workload. That is what IaaS is genuinely for.
2. Is it a capability you realistically cannot run? Global email delivery, DDoS absorption, telephony. If running it yourself would be worse for security than outsourcing it, outsource it. Honesty matters here in both directions.
3. What is in the data? If the answer includes personal data, credentials, or anything that maps your weaknesses, the bar for sending it out should be far higher than for marketing assets.
4. What happens on the worst day? If the vendor is breached or gone tomorrow, is the consequence an inconvenience or an incident with a regulator involved?

Cloud where the answers demand it. Your own infrastructure everywhere else. Most organisations that run this test honestly find the “must” list is far shorter than their current subscription list.

Flowchart of the four-question test routing workloads to IaaS, SaaS or self-hosting

The four-question test, where cloud outcomes need a reason and self-hosting is the default.

The data that should never have left

There is one category where I think the argument is close to absolute, and it is the data that describes where you are weakest. Risk registers, vulnerability scan results, incident reports, audit findings, compliance assessments. This is the reconnaissance package an attacker would assemble if they could, and the industry norm is to upload it, pre-organised, to multi-tenant platforms whose other customers, staff and subprocessors you will never meet.

Security and compliance data is a target map. It should sit inside the network it describes, on infrastructure you control, readable by nobody whose name you do not know. If any workload deserves the self-hosted default, it is this one.

The honest counterarguments

“The cloud is more secure than we are”

For some organisations and some workloads, genuinely true. A five-person firm should not run its own email. But the comparison changes for internal workloads, because a containerised application on your own network, with no inbound exposure and no multi-tenant neighbours, has a smaller attack surface than the same application on the public internet behind a vendor’s login page. Patching discipline is still your job either way. It is just visible when it is yours.

“Self-hosting is more work”

Less than it was. Modern self-hosted software arrives as a container, updates in minutes, and does not need a server room or a resident specialist. The operational gap between “we run it” and “they run it” has narrowed enormously. The custody gap has not narrowed at all.

“Our people need access from anywhere”

Remote access to your own systems is a solved problem, and solving it yourself with modern zero-trust tooling still keeps the data under your custody. Access is an argument about connectivity, not about who should hold the data.

“The business case is risk transfer”

This one is usually implicit, so it is worth saying out loud. Most cloud business cases lean on offsetting risk to the vendor, and the appeal is real, because a contract that transfers operational risk looks like a smaller contingency budget and a lighter regulatory exposure on paper. Some of it genuinely does transfer. The vendor now carries the patching, the hardware failures and a contractual slice of the liability. What never transfers is accountability. Outsourcing the work does not move the controller’s duty to choose its processors carefully and oversee them, and the processor picks up its own direct liability rather than taking yours away. The ICO’s £3.07 million penalty against Advanced Computer Software in 2025 landed on a processor, and it did nothing to relieve the controllers whose patients were affected. Your customers were promised the data was safe with you, and on the worst day the incident carries your name whichever infrastructure it happened on. You have transferred the operations and kept the consequences, and a business case that prices the first while ignoring the second is not a risk decision. It is an accounting trick.

Two column comparison of what a cloud contract transfers to the vendor, patching, hardware failures and uptime, against what stays with you, regulator fines, customer trust and your name on the incident

Operations move. Consequences stay. A business case that only prices the left column has not made a risk decision.

Putting it into practice

Start with an inventory, because you almost certainly do not have one. List every SaaS and cloud service touching company data, what data each holds, and who approved it. Expect surprises, because shadow subscriptions are the new shadow IT. Then classify each service as business must, convenience, or historical accident, using the four questions above. Repatriate the crown jewels first, the systems holding the data that describes your weaknesses, and let the convenience tier follow as contracts come up for renewal.

You will keep more cloud than you cut. That is fine. The goal is not purity. It is that every workload outside your network is there because the business needs it there, and someone can say why. Offline by design is not a rejection of the cloud. It is the recovery of a decision that was taken away from you one subscription at a time.