Worried Your Business System Has Been Hacked?

Something about a business system looks wrong. A password reset you did not request arrived, a report shows activity that cannot be right, or a customer says they had a strange message from your account.

The first decision is whether this is happening now or whether it is a prompt to check how exposed the system is. Those two situations need different work. In an active incident, speed and evidence matter. In a preventive review, the useful work is a calm look at how the application is built, who can reach it and what it depends on.

Signs that need investigation

Business.gov.uk's guidance on responding to a cyber attack lists the signals worth taking seriously:

• Devices running slowly, rebooting or behaving strangely.
• Being locked out of an account or system.
• Password reset or sign-in requests you did not trigger.
• Unusual transactions or activity in business accounts.
• Customers or suppliers reporting odd messages from your business.

These signs can have other explanations. Unexpected access, transactions or messages deserve prompt investigation through your existing incident arrangements. Do not wait for a routine software-review booking if you suspect an attack is in progress.

Contact the people who already own the response

Work through the arrangements you already have: an incident plan, the IT provider who supports the systems, the software supplier, your insurer. If you have no plan, the NCSC's advice for sole traders and small organisations covers account recovery, ransomware, infected devices, payment fraud and denial of service in plain terms. The NCSC also publishes a list of assured cyber incident response providers for organisations that need specialist help.

If money has moved, tell your bank using the number on its own website. If you have lost access to an account, start with the provider's recovery process rather than guessing at passwords.

Reporting a cyber incident is a separate question from fixing it. The government's report a cyber incident service points to the right body for your situation, including the NCSC and the police. Whether anything must be reported, and to whom, depends on what happened and whose data is involved, so take that decision with the people handling the incident and, where needed, your professional advisers.

Keep the evidence, and keep credentials out of messages

The instinct to wipe a laptop, rebuild a server or restore last night's backup is understandable. All three can also remove the record of what happened, how it got in and what was taken. Follow the person leading the incident response on containment and account recovery, recording what changes. Avoid ad hoc wiping or restoring that could destroy evidence or return a compromised system to service.

Keep a simple written log: what was seen, when, by whom, what has been changed since and who has been told. Screenshots help. So does a note of which accounts were signed in and which supplier was called.

Locking an intruder out is still the right move, and NCSC's hacked account guidance sets out how: reset the password through the provider, sign out of all devices and apps, and turn on two-step verification. Check email forwarding and filter rules as well, because a hidden rule can keep sending copies out after a password change.

What should never travel in email, chat, a ticket or an AI assistant:

• Passwords, API keys or database connection strings.
• Card details or bank account numbers.
• Customer records, order exports or personal data.

If a supplier needs access, ask for a named account with the narrowest permissions that will do the job, approved by you, and share the credential through a password manager rather than a message. The NCSC's recovery guidance for disruptive attacks is written for the harder cases where systems are unusable, and it runs from the immediate response through recovery to a rebuild planned later.

The other case: checking an application before something happens

If nothing points to an active incident, the useful question is how much the business system exposes you. That is application risk. Start with documentation, configuration and agreed access; agree any intrusive testing and use an isolated environment where appropriate. The NCSC's small organisations guide covers the basics worth having in place either way: backups, account protection, updates and spotting scams.

Most owners know what the system does. Fewer know which accounts can reach the data, what the application connects to, or what a supplier would need if the system had to be rebuilt quickly.

What a review covers

The work below assesses an application and the way it is used. The scope and testing arrangements are agreed first; this is separate from specialist investigation of an active incident.

Area	What we check	What you get
Access	Who can sign in, admin screens, service accounts, supplier logins, leavers, password reset and multi-factor setup	A list of who and what can reach business data, with the gaps ranked
Data flow	Where order, customer, payment and invoice data is stored, copied, exported and deleted	A data map you can hand to a supplier, adviser or insurer
Dependencies	Versions of the application, plugins, libraries and hosting, support status and overdue updates	A short list of what to update, replace or schedule
Integrations	Every system the application talks to, the direction of each link, the credential it uses and what happens when it fails	An integration inventory showing where a problem could spread
Change and recovery	How changes are tested and released, what is backed up, and whether anyone has restored a backup	A recovery plan with named owners and agreed restore evidence

Useful outputs from that work usually include:

• A written summary of the risks found, ranked, with an owner for each.
• A fix plan with scope, sequence and price before any work starts.
• Agreed changes implemented and checked, such as splitting admin access, removing unused accounts, tightening permissions, updating components or rotating an integration credential.
• A record of what was postponed or accepted, and why, so the next review starts from facts.

What we need to start, safely

A first conversation needs a written description of the system. It does not need a password:

• What the system does, who uses it and how it is hosted.
• What looks wrong, with dates and screenshots where you have them.
• Which supplier built or supports it, and what your agreement with them covers.
• Any architecture or integration diagram that already exists.
• Read-only or limited access, arranged by you, once we have agreed what it is for.

Start with the description and redacted evidence. Agree any further access needed to scope the review, and how it will be provided, before sharing it.

Questions for your software supplier

These are the questions that turn a vague worry into a decision. Ask for written answers.

• Which version are we running, and when did it last receive a security update?
• Who holds admin access to the application, the database and the hosting, and how is multi-factor enforced for each?
• What does the application log, for how long, and can we have an export?
• Which third-party services and libraries does it depend on, and who watches for security notices about them?
• How are backups taken and stored, and when was a restore last tested?
• How would we find out if data had been read or copied?
• What is the process for a security fix, including testing and when it goes live?
• What support is agreed out of hours, and what does the contract actually promise?

What we can and cannot do

Revitt can assess an application's access, data flow, dependencies and integrations, and implement the fixes you agree. If your team or another supplier owns the code, we can review it and work alongside them.

The application review described here is scoped software assessment and repair; it does not provide forensic investigation or an NCSC-assured incident response engagement. Any monitoring, support hours and response commitments need their own agreement. A completed review records what was checked and repaired; it does not certify that a system has no vulnerabilities. In an active incident, contact your existing provider and, if you need one, an assured provider from the NCSC list first.

Published proof

Our work for Mitchell's Vintners included an audit of two online shops and the software linking them to the till. A security hole was found and written up with the fix, alongside urgent repairs and updates.

The case describes the actual application work. It is not a claim that a breach occurred or that a security review can certify a system free of vulnerabilities.

Next step

Revitt is based in Sheffield and works with teams across the UK. For a planned application review or agreed software repair, book a free call or contact us. Describe the system and the decision you need help with; we will explain the review scope and what we can investigate. If an attack may be happening now, use your existing incident provider or the NCSC guidance above rather than waiting for this appointment.

For the engineering side, see development. Where the useful work is deciding priorities, supplier oversight and risk across several systems, technical leadership sets that out.