Most websites that stay online long enough will be breached at some point, and the number worth arguing about is how much of the business goes down with it. That number is fixed long before any intruder shows up. It gets fixed on the day someone decides whether the database sits next to the web server, whether one password opens everything, and whether the backups live on the same account as the system they’re supposed to rescue. Security budgets still pour most of their money into the front door. How many rooms a single stolen key opens behind it tends to be left to default settings, which in practice means nobody decided at all.

The bill for that indifference keeps growing. IBM’s latest research puts the global average cost of a data breach at $4.99 million, up 12 percent on the year before and the highest figure the study has recorded. An average hides a lot, and few small shops will face a bill that size, but the direction of travel is hard to wave away.

Blast radius is a term borrowed from explosives work, and it suits the subject better than most security vocabulary does. Nobody planning a demolition pretends the charge won’t go off. They spend their effort on where the debris lands.

Flat Networks and the Case for Compartments

Start with the flat network, because it arguably does more harm than any single exploit. When the web server, the admin panel, the mail relay and the customer database can all talk to each other freely, a flaw in one forgotten plugin becomes a flaw in everything. The US government’s own zero trust architecture guidance, published back in 2020, is built on refusing to trust any machine simply because of where it sits on the network. Six years later, plenty of small and midsize sites still hand out that trust wholesale. Splitting the public site, the stored data and the admin tools into separate compartments that have to ask permission to reach each other is dull work. It is also, on the evidence of most incident write-ups, one of the decisions that separates a defaced homepage from a full customer data dump.

In practice, draw every system on one page and write down which ones genuinely need to talk. Anything not on that list gets blocked by default. Teams doing this for the first time often find a connection nobody can explain, and that connection is the one worth closing first.

Whose Hardware the Site Runs On

The second choice concerns whose computer the site actually runs on. Shared hosting and crowded virtual servers put your workload on the same physical machine as strangers, kept apart by a software layer that is usually solid and occasionally is not. Researchers at Graz University of Technology and elsewhere published details of processor flaws that let one program read another’s memory in early 2018, and warned that depending on a cloud provider’s setup, data might be stolen from other customers. Patches followed. For a hobby blog, sharing a machine with strangers remains a perfectly reasonable trade. For a store holding card details or a clinic portal holding patient records, “usually” is an odd word to build a business on.

Single-tenant hardware takes the neighbors out of the equation. Atlantic.Net, for one, sells its dedicated server hosting in USA as standalone machines that aren’t tied into any shared cloud platform, spread across five American data centers and handed over with full administrative control. None of that makes a server invulnerable. What it provides is a boundary you can draw on a whiteboard, where the damage stops at the edge of a box you control instead of somewhere inside a shared layer you’ll never get to inspect.

Dedicated hardware only pays off if the compartments from the previous section survive the move. Putting the web application, the database and the admin tools on one powerful machine recreates a flat network inside a single box. Where the budget allows, give the database its own server, reachable only from the application tier, and treat the administrator password for each machine as a separate secret held by as few people as possible.

One Password, 165 Organizations

Credentials come third, and they probably deserve more anger than they get. The 2024 campaign against Snowflake customers remains one of the clearest pictures of how far a single password can travel. Mandiant’s write-up of the Snowflake intrusions traced the damage to accounts without multi-factor authentication, to passwords left unchanged for as long as four years, and to the absence of any rule limiting logins to trusted locations. Mandiant and Snowflake ended up notifying roughly 165 organizations that their data was potentially exposed. Mandiant found no sign that Snowflake’s own environment had been breached; in several cases the stolen logins had been lifted from contractors’ laptops that were also used for games and pirated downloads.

The practical lesson runs narrower than a slogan about turning on extra login checks. Give each service its own credential, scoped to the one job it does, and rotate it on a schedule no human has to remember. A web app that only reads product listings has no business holding a password that can wipe the orders table. Contractors deserve the same discipline. Issue them accounts that expire when the engagement ends, and don’t let an agency reuse one login across several clients, however much easier that makes the handover.

Keeping Data Off the Open Internet

Fourth, and closely related, there are very few good reasons for a database to answer the public internet. It sounds too obvious to write down, which may be exactly why it gets skipped in the rush before a launch. Placing stored data on a private network segment, the same thinking that separates a virtual private cloud from an ordinary VPN, means an attacker who takes over the web server still has to find a second way in. Each extra step is another chance to be noticed. The same rule covers caches, search indexes and the reporting dashboards that analytics tools create on their own. Anything holding a copy of customer data counts as the database here, whatever the vendor happens to call it.

Card payment rules attach money to the same idea. The PCI Security Standards Council’s scoping and segmentation guidance for modern networks, published in 2024, walks through how zero trust designs and multi-cloud setups move the boundaries an assessor examines, and how to keep an accurate inventory when servers appear and vanish by the hour. The fewer machines that can touch card data, the smaller both the audit and the eventual breach tend to be.

When the Gateway Becomes the Door

The fifth choice is where the argument turns on itself a little. Admin panels and remote login tools belong behind a gateway rather than facing the open internet, and that advice still holds. The gateways, though, have become targets in their own right, and the wider data complicates the case made about passwords a section ago. Verizon’s 2026 Data Breach Investigations Report found that 31 percent of breaches now begin with an exploited software vulnerability, putting software flaws ahead of stolen passwords as the most common way in.

Cisco’s firewalls show what that looks like at the edge. In September 2025, CISA issued an emergency directive on compromised Cisco firewall devices after attackers used previously unknown flaws to run their own code on them, then altered the devices’ low-level memory so the foothold survived reboots and software upgrades. Equipment bought to shrink exposure became one of the widest doors in the building.

So the gateway stays, but it needs its own patch routine and its own monitoring, and everyone responsible for it should assume that one day it may be the piece that falls. The same directive told agencies to disconnect models the vendor had stopped supporting and to install later updates within 48 hours of release. Both standards travel well beyond government. A device nobody is shipping fixes for has no business being the only thing between the internet and your admin tools, and a patch window measured in weeks is a generous gift to whoever finds the next flaw.

Watching What Leaves

Sixth, decide what your servers are allowed to send out. Most intrusions need to phone home at some point, if only to carry stolen records away. A compromised server allowed to open a connection to any address on earth will happily stream a customer table to a rented machine overseas at two in the morning, and in many small setups nobody is watching the outbound side closely enough to notice. A web server that can reach its payment processor and its update source, and nothing else, makes a poor base for an attacker. Name lookups deserve particular suspicion, since malware has long used DNS as a hidden channel for moving stolen data past filters that only watch the obvious routes.

The fix for that last problem is unglamorous. Force every server to resolve names through a resolver you run or choose, and block direct outbound DNS to anywhere else. MITRE’s catalogue of attacker behavior notes that intruders use DNS to blend into traffic nobody thinks to question, and that such traffic is sometimes allowed before any authentication has happened. Routing lookups through a controlled resolver, one of the mitigations it lists, won’t catch everything. It does turn a blind spot into a record someone can read.

Backups an Intruder Can’t Reach

Seventh on the list, and the most often botched, are backups. A backup that opens with the same administrator login as the live site offers little protection against an intruder holding that login. Verizon’s report found ransomware in 48 percent of breaches, and Britain’s National Cyber Security Centre has described incidents in which ransomware encrypted the connected drives and cloud storage holding the backups along with the original data. Copies kept under a separate account, with at least one disconnected at any given moment and ideally locked against changes for a fixed period, turn a negotiation into a restore.

Then test the restore, on a calendar, with someone timing it. A backup that has never been restored is an assumption, and the first real test of it tends to arrive on the worst day of the year. The NCSC makes the same point more politely, asking organizations to check regularly that their copies actually work.

Records Kept Somewhere Else

Eighth, send logs somewhere the attacker can’t reach. Records sitting on the compromised server are often among the first things a careful intruder tidies up. Shipped continuously to a separate system, they make the difference between telling customers exactly which records left the building and admitting that nothing can be ruled out, a sentence regulators and customers both tend to hear as the worst case.

How long those logs are kept matters as much as where. Joint logging guidance from Australia’s cyber security centre and its international partners warns that default retention periods are often too short, that discovering an incident can take up to 18 months, and that some malware sits on a network for 70 to 200 days before causing visible harm. Logs that roll over after a week may have erased the start of the story by the time anyone goes looking. The same guidance recommends keeping log storage on a separate or segmented network, which brings the argument back to the compartments it started with.

The Data Nobody Needed

The ninth choice undercuts the eighth, and it should. Every log, every archived order and every abandoned test copy of the customer table is something that can leak later. Data that was never kept has a blast radius of zero. Regulators have been saying so for years. Britain’s data minimisation principle expects organizations to hold no more personal data than their purpose requires, to review what they hold periodically, and to delete what they no longer need.

Privacy services have built entire sales pitches around a no-logs policy for a similar reason, since records that don’t exist can’t be handed over or stolen. A retail site can’t go that far and shouldn’t pretend otherwise. It can still ask, table by table, why five-year-old details of long-gone customers sit in the same database as this morning’s orders, and put a deletion date on anything that has no good answer.

Who Gets to Say No

Which leaves the uncomfortable part. Every one of these choices adds friction, whether a second login or a deploy that eats an extra afternoon, and friction is the first thing stripped out when a launch date slips or a new developer can’t get their work done. The compartments get a temporary exception. The exception outlives the person who granted it. The breaches that travel furthest tend to run through a door someone opened for convenience and meant to close later.

So pick one choice from this list before the next release rather than attempting all nine at once. For most sites the cheapest starting point is a credential audit. List every account, key and token that can reach customer data, and give each one a named owner and an expiry date. Then write down, somewhere the people who approve budgets will read it, who has the authority to delay a launch while one of those exceptions is still open. Most teams already know which exception that would be. The harder question is whether the person holding that authority would actually win the argument.