Many failures look alike
Login errors, slow pages, declined payments and unavailable services can result from faults, updates, demand, supplier problems or malicious activity.
Public systems and disruption
Has this service been hacked, or is it simply down?
A failed app, website or payment service shows that something is unavailable. It does not reveal whether the cause is maintenance, a software fault, capacity, supplier failure, a cyberattack or another incident.
Page S-008Guidance pageReviewed 29 August 2026
Key Guidance
Treat the service as unavailable until a source you can trust confirms the cause. Check the organisation's known status page, app or official channels directly. Do not use alternative links, support numbers, refunds or payment routes supplied by unsolicited messages during the disruption.
Start with Key Guidance for the short answer. Then read the sections that match what happened and what you need to do.
Understand the issue
Why this matters to you
The public normally sees the symptom before the cause. Responsible checking preserves that distinction while facts are still developing.
A cyberattack does not prove a breach
An attack may disrupt a service without stealing personal information. A data breach may also happen without a visible outage.
Early statements are limited
An organisation may confirm disruption before it can confirm the affected systems, duration, cause or customer impact.
Disruption creates convincing workarounds
Scammers can offer new login pages, priority access, refunds or replacement payment instructions while normal routes are unavailable.
Consequences and movement
What may happen next
Build the answer from dated, attributable evidence. Update the conclusion when the organisation or a competent authority confirms more.
Only availability is confirmed
Describe the service as down or disrupted. Do not infer hacking, ransomware or data theft from the symptom.
A cyber incident is confirmed
Follow the official operational advice while keeping the separate question of personal-data exposure open.
A breach notification follows
Move to data-breach action based on the information involved rather than the earlier outage alone.
An unofficial workaround appears
Do not sign in, pay or disclose information through it. Verify the alternative through a route you already trusted before the outage.
Practical response
What you should do
Your task is not to diagnose the system. It is to maintain a safe route, preserve evidence and respond only to confirmed personal effects.
- Check a known official sourceUse a saved app, typed address, known status page or official account rather than a link in a post, message or search advert.
- Note time and scopeRecord when the failure began, which functions are affected and what the organisation has actually confirmed.
- Avoid repeated sensitive attemptsDo not repeatedly enter passwords, card details or verification codes into pages that are failing or reached through an uncertain route.
- Reject unverified alternativesDo not reroute payments, bookings, account access or support contact only because someone says the normal system is unavailable.
- Act on direct evidenceProtect an account, payment or identity only when you see suspicious activity, receive a credible notification or the organisation advises a relevant measure.
- Preserve suspicious contactKeep messages and links that exploit the outage, then report them through the platform, phishing or fraud route that applies.
Look more closely
A service problem does not authenticate an alternative contact route
Outages and cyber incidents make people search for updates, support and workarounds. Use the organisation’s confirmed website, app or status page so the disruption does not push you towards an unconfirmed solution.
The service failure creates attention and uncertainty.
Loss of access, payment or time creates urgency.
A support, refund or provider identity appears.
A new link, number, account or workaround is supplied.
Known official channels confirm both status and safe alternatives.
Selected history
Historical cases and lasting lessons
Global IT outage
The UK cyber authority stated that a widely disruptive global outage followed a security-software update and was not assessed as malicious cyber activity.
Lasting lesson: Scale and disruption do not prove an attack. Cause requires evidence.
Outage-themed phishing
Official incident guidance warned that criminals could exploit public attention with related phishing and false recovery activity.
Lasting lesson: A genuine outage can support a false support or payment route even when the cause is not criminal.
Transferable understanding
Patterns over time
The symptom arrives before the explanation
Users experience failure at once while diagnosis and incident communication take time.
Rumour compresses separate questions
Outage, attack, ransomware and data breach are often treated as synonyms although each requires separate evidence.
Alternative routes carry extra risk
The moment normal controls disappear is precisely when a replacement destination needs stronger verification.
Cause can change as evidence improves
Updating an early description is normal when investigators distinguish a fault, supplier incident or malicious act.
Plain-language answers
Common questions
Does an error message mean my account was hacked?
No. Check the account through a known route and look for unfamiliar activity. A service error alone does not confirm account access.
Should I change my password during every outage?
No. Change it when sign-in details may be involved, you see suspicious access or the provider advises it. Repeated resets through uncertain pages can create more risk.
Can an outage and breach happen together?
Yes, but neither proves the other. Follow confirmed information about service availability and exposed data as separate tracks.
Can I trust a status update shared by someone else?
Use it as a lead, then reach the organisation's status or official channel yourself before following any workaround.
Confirm the status before accepting the cause
Use a known official channel, keep outage and breach questions separate and reject unsolicited workarounds until independently verified.
Scamology Insights
Recognise when disruption makes deviation feel necessary
These learning resources can help you see how a real service failure can make a false identity or unsafe alternative easier to accept. Links are intentionally withheld in this production version.
Continue understanding
Explore related guidance
Evidence and currency