If the till is down, the shop is shut.
Retail has the shortest distance between a technical fault and lost revenue of any sector we work in. Connectivity, point of sale and card handling are the three things worth engineering properly; everything else can wait.
Every other sector loses productivity when IT fails. Retail loses the transaction outright.
That changes what is worth paying for. Redundant connectivity, which looks like an indulgence in an office, pays for itself in a single Saturday afternoon in a shop. Meanwhile the things retail is often sold — elaborate endpoint suites for a fleet of fixed tills — matter far less than a second internet path and a network design that keeps card traffic away from everything else.
Five failures that close a till.
Ordered by revenue impact per hour, which in retail is the only ordering that matters.
| Failure | Why it happens here | What we do about it |
|---|---|---|
| 01Internet drops on a Saturday | Why it happens hereA single connection, no failover, and a provider whose support queue does not work weekends | What we do about itSecond path with automatic failover — the highest-return spend in retail IT |
| 02Point of sale will not authorise | Why it happens herePayment terminal path depends on a route or certificate nobody owns | What we do about itDocumented, monitored payment path with a known escalation contact before it fails |
| 03Everything on one flat network | Why it happens hereThe guest Wi-Fi, the tills and the back-office PC all share a subnet, which drags card handling into scope | What we do about itSegmentation — card, staff and guest separated, keeping PCI scope small and the assessment short |
| 04Inventory drifts from reality | Why it happens hereSync between store and back office fails silently and nobody notices for a fortnight | What we do about itMonitored integrations with alerting on failure, not on schedule |
| 05Seasonal staff keep their access | Why it happens hereDecember hires still have logins in March | What we do about itIdentity-driven onboarding and offboarding, with dated accounts for temporary staff |
Notice how little of this is about endpoints. Retail IT is mostly network engineering with a payment obligation attached.
Keep the scope small.
PCI DSS obligations scale with how much of your estate touches card data. The cheapest compliance strategy is architectural: make sure most of your network never touches it at all.
The security stack
Segment first
Card traffic on its own segment, guest Wi-Fi nowhere near it, back office separate again. Done at the network layer this is a one-time design decision that reduces every future assessment.
Prefer point-to-point encryption
Where your provider supports it, terminals that encrypt at the reader keep card data out of your systems entirely — which is the strongest position available to a small retailer.
Guest Wi-Fi as a genuine guest network
Isolated, rate-limited, with its own credentials and no route to anything of yours. It is a customer amenity, not an extension of your office.
Know your provider’s boundary
Every payment provider draws the responsibility line somewhere. Knowing exactly where yours sits determines what you actually have to do, and most retailers have never been told.
When support actually needs to exist.
Retail hours are not office hours, and an agreement built for an office fails a shop at exactly the wrong moment.
Cash up and float
Tills wake, terminals reconnect, yesterday reconciles. A fault here delays opening.
Continuous
Every minute of downtime is a measurable loss. Nothing is deferred to a maintenance window.
Evenings and weekends
Precisely when a standard business-hours agreement stops covering you.
Reconciliation
End of day, banking, inventory sync. Failures found here become tomorrow’s accounting problem.
Maintenance
Updates, patching and backup — the only window that exists in retail.
Coverage aligned to trading hours rather than office hours, and a maintenance window that is genuinely overnight. If a provider proposes Monday-to-Friday nine-to-five for a shop that trades Saturdays, they have not understood the business they are quoting for.
For a store, in this order.
Multi-site retail changes the shape but not the order — the difference is that everything above needs a consistent standard per location rather than whatever each store grew into. Further reading for retail: what a managed firewall actually is, and IoT security when every device is on the network. The layers behind this list are the managed firewall, DNS filtering and EDR. If the storefront needs building too, that is web and software.
The ones operators actually ask.
If yours isn’t here, ask it directly — you’ll get an answer from an engineer, not a form letter.
We support the environment it runs on — network, connectivity, workstations and the payment path — and we deal with your POS vendor on your behalf. We are not a reseller for any POS platform, which means we are on your side of that support call.
Yes, and for retail you should. Standing after-hours coverage is priced separately because it is a real cost, but a shop trading Saturdays with weekday-only support has a gap at its busiest hours.
If you accept cards, yes, in some form. How much applies depends on your setup — a segmented network with point-to-point encrypted terminals carries far lighter obligations than a flat network with card data passing through your systems.
Connectivity is the constraint, and it can run six to eight weeks depending on the address. Tell us early and it is straightforward; tell us two weeks out and the opening slips.
Only if it is genuinely isolated. Done properly it is a cheap amenity; done as an extra password on your business network it is a way to put customers inside your perimeter.
Next
The till stays open.
Twenty minutes. Tell us how many locations you run and what happens today when the internet drops — that answer usually decides the whole plan.