Decide what still works when you switch it all off.

What keeps running was built to run alone

On Monday morning, October 12, 2026, Ahold Delhaize — the parent of Albert Heijn, Etos, Gall & Gall, and Delhaize — told the market it was "experiencing a security issue within its network" and was "taking some systems offline to help protect them." The same statement said the stores were open and serving customers.

That second sentence is the useful part. RetailDetail and Cybernews report that since Sunday the Albert Heijn, Etos, and Gall & Gall websites and apps have been down, online grocery deliveries are suspended, personalized discounts and loyalty savings aren't working, and customer service is hard to reach. Physical stores and checkouts remain open. Cybernews notes electronic shelf labels may still show last week's promotional prices, so the ticket at the till can differ from what the shelf shows. The company has not said whether customer or employee data was taken, and it has not named a cause.

This note is not a postmortem of that incident, and it is not about ransomware or attackers. It is about the client decision the news makes visible: when you choose to switch your own systems off on purpose to contain a security problem, what keeps running is whatever was designed to run alone. If you own a retail, ecommerce, or service business, that list should exist before anyone has to pull the plug.

Name the pieces that must keep working

Tonight, before the next outage, write a short list. Not a binder. Five lines is enough to start. For each line, ask: if the rest of IT is unplugged, does a customer still need this today?

For most shops and brands the must-keep list looks like this:

• Taking payment in the store. Card, cash, or both. If the till depends on a central system that you just took offline, you need another way to charge and to record the sale.
• Prices people can trust. A printed or local price list, or a clear rule for what to do when the shelf label and the till disagree.
• Orders you already promised. Pickup windows, deliveries already booked, gift cards already sold. New online orders can pause; promises already made usually cannot.
• Loyalty balances and gift cards. Even if the app is dark, staff need a way to honor what a customer already earned or paid for — or a clear temporary policy and a way to make it right later.
• A way for customers to reach a human. A phone line, a store counter, a mailbox that still works when the chat widget and the CRM do not.

Cross out anything that is nice-to-have under pressure. Marketing emails, personalized offers, and the recommendation engine can wait. The point of the list is ruthlessness in daylight, so nobody invents priorities at 2 a.m.

Write the fallback sitting next to each line

A must-keep piece without a fallback is just a wish. Next to each line, write what it falls back to when the network is gone — and where that fallback lives.

Payment. A handheld reader that talks to the acquirer on its own cellular connection, a spare terminal that does not need your store Wi-Fi, or a paper imprinter and a later reconciliation process you have actually practiced. Write who holds the spare device and where the spare paper rolls are.

Prices. A printed book or a local copy on a phone that does not need your app servers. Decide in advance which price wins when the shelf and the till disagree, and tell floor staff in one sentence.

Promised orders. A printed pick list or a local export taken on a schedule you trust. For delivery, a phone tree to the courier with addresses you can still open. If your fulfillment operations lean on one central queue, ask whether a store can finish today's promised pickups from a local list when that queue is offline.

Loyalty and gift cards. Either a read-only local balance sheet for the day, or a temporary rule ("we will honor it when systems return; take the customer's contact and a photo of the card") with a named person who owns the follow-up.

Customer contact. A phone number that rings a person, not a ticket system. A store window note. An email address that still delivers to inboxes you can open on a laptop that is not joined to the network you just shut down.

If two pieces share one dependency — for example, payment and loyalty both need the same central API — mark that. Shared dependencies are where "we thought it would keep working" turns into a surprise.

Who pulls the plug, and what the website says

Containment only works if someone is allowed to start it. Write three names (or roles) on the same page as the list:

• Who may decide to take systems offline. Not "IT in general." One role on call, with a backup.
• Who they call before they do it. Ops lead, store director, whoever owns customer promises for the day.
• Who tells customers. Comms or the person who updates the public notice — and they need a draft already written.

The website and app will be the first place angry or confused customers look. If those systems are among the ones you unplug, a blank error page is the message. Host a short, prewritten notice somewhere that does not share fate with the thing you are containing: a separate static page, a status host, even a simple page on another account. It should say, in plain language: we are dealing with a security issue; stores are open / online orders are paused; here is how to reach us; we will update this page when we know more. No speculation. No timeline you cannot keep.

That notice is as much an engineering problem as a comms one: it has to be deployable when the main stack is dark. Test that once. Publish the draft to the fallback host on a quiet Tuesday and make sure the DNS or the link from your domain still works when the main app is stopped on purpose.

This is different from a partial failure decision tree, where one side of a write succeeds and the other fails. Here you are choosing a full unplug. It is closer in spirit to naming what you will shed before a spike — except the shed is defensive, and the clock starts when someone says the word containment.

Run the drill once while the lights are on

A list nobody has practiced is a speech. Pick one quiet hour and simulate "network offline for this store / this brand."

Rules for the hour:

1. Turn off (or unplug from) the systems you would take down in a real containment — or at least stop staff from using them.
2. Serve real customers, or run a full mock with today's order printouts, with only the fallbacks.
3. Time how long it takes to take a payment, look up a price, finish a promised pickup, and answer a phone call.
4. Write down every moment someone says "I need to check the system."

Those pauses are the gaps in the list. Fix the two cheapest ones that week: a spare reader in the safe, a printed price book at the desk, a laminated card with the phone number and the temporary loyalty rule. Then schedule the next drill in ninety days so the list does not rot when staff change.

You do not need to invent how long Ahold Delhaize's disruption will last. You need your own number for how long you can keep the must-keep list working without the network.

Keep the page where people can find it

Put the must-keep list, the fallbacks, the three names, and the customer-notice draft on one page. Store a printed copy where the night manager can reach it without unlocking a laptop on the network you just killed. Keep a digital copy somewhere that does not share credentials with production.

When the next security issue shows up — yours or someone else's in the news — you should be able to open that page in under a minute and know what still works. If you want help turning the list into something your store systems and order tools can actually support offline, our fulfillment and operations work is built around that kind of continuity, and you can tell us what you run.

Related work: Paddle8.