Skip to main content
VATRelay

Sandbox HMRC test environment. Nothing you submit here is a real VAT return.

Back to sign in
VATRelay

Security incident and breach notification process

WarningDraft: 7 highlighted items still to be completed by the software provider.
Owner[BREACH CONTACT NAME], [JOB TITLE]
Breach contact telephone[TELEPHONE NUMBER]
Deputy[DEPUTY NAME], [TELEPHONE NUMBER]
Security reporting addresssecurity@vatrelay.co.uk
Applies toVATRelay version 0.2 and later (https://vatrelay.co.uk)
Last reviewed3 November 2026. Review at least every 12 months and after any incident

1. For customers: reporting a problem

If you think someone else has used your VATRelay account, or you see something on your Account activity page that you did not do:

  1. Change your password straight away (sign out, then select I have forgotten my password on the sign-in page).
  2. Tell us at security@vatrelay.co.uk or on [TELEPHONE NUMBER].
  3. If you think a VAT return was submitted without your authority, also check your HMRC online account and tell HMRC.

If you have found a security weakness in VATRelay, please tell us at security@vatrelay.co.uk. We acknowledge reports within [2 working days]. Please do not include taxpayer data in your first message, and give us reasonable time to fix the problem before telling anyone else.

VATRelay and HMRC will never ask for your password or an authenticator code by email or phone.

The rest of this page sets out how we handle security incidents, as HMRC requires.

2. Purpose

This process explains how Fishex Limited detects, contains and reports security incidents affecting VATRelay, and how and when we tell HMRC, the Information Commissioner's Office (ICO) and the people affected. It meets HMRC's Developer Hub terms of use, which require that "any issues concerning the security of personal or customer data must be reported immediately to HMRC by logging a ticket", with full details within 72 hours and a named breach contact with a telephone number. It also meets the UK GDPR requirement to tell the ICO about a personal data breach within 72 hours.

3. What counts as a security incident

Treat any of these as an incident and start this process straight away. If in doubt, treat it as one.

  • HMRC application credentials exposed: the HMRC client secret (HMRC_CLIENT_SECRET) is disclosed, lost or used by anyone other than VATRelay.
  • Encryption key exposed: the TOKEN_ENCRYPTION_KEY, which protects stored HMRC connection keys, is seen or copied by someone not authorised.
  • Unexpected activity: returns, connections or other actions appear in VATRelay's records or in an HMRC online account that the customer did not make.
  • Vulnerability reported: someone reports a security weakness in VATRelay.
  • HMRC raises a concern: HMRC tells us about suspicious activity or fraud prevention data problems linked to VATRelay.
  • Hosting account compromised: someone not authorised gets into the Render, Supabase, Stripe, GitHub or HMRC Developer Hub accounts used to run VATRelay.
  • Server settings exposed: any secret setting held on Render is disclosed, for example DATABASE_URL (which contains the database password), STRIPE_SECRET_KEY or FLASK_SECRET_KEY.
  • Database accessed or copied: the Supabase database or a backup is accessed, copied or changed by someone not authorised. It holds customer email addresses, businesses, VAT returns, HMRC receipts, payment records and encrypted HMRC connection keys.
  • One customer able to see another's data, through a fault or an attack.
  • Customer accounts taken over, for example several accounts showing sign-ins the customers did not make.

4. Immediate actions (first hour)

Do these in order. Speed matters more than completeness.

  1. Record the time you became aware of the incident. The 72-hour deadlines run from this moment. Start an incident log (section 9).
  2. Tell the breach contact (or the deputy) by telephone.
  3. Contain the incident. Do whatever applies:
    • HMRC client secret exposed: on the HMRC Developer Hub, open the application, then Client secrets. Create a new secret, put it in Render's Environment settings, then delete the old secret.
    • Database password exposed: in Supabase, reset the database password, then update DATABASE_URL on Render.
    • Stripe key exposed: in the Stripe dashboard, roll the secret key, then update STRIPE_SECRET_KEY on Render. Check Stripe for payments or refunds nobody made.
    • Encryption key exposed: create a new TOKEN_ENCRYPTION_KEY and put it in place. Stored HMRC connection keys can no longer be read after this, so every business must reconnect to HMRC. Tell the customers affected.
    • Session key exposed: replace FLASK_SECRET_KEY on Render. This signs every customer out.
    • Hosting account compromised: change its password, sign out its other sessions, check its two-step sign-in, and review its recent activity and settings.
    • Customer account taken over: in Supabase, sign the account out and reset its password and authenticator. Disconnect its businesses from HMRC.
    • Website under attack or leaking data: suspend the service on Render until the problem is fixed.
  4. Revoke HMRC access where it may be misused. In VATRelay, open the business, then Manage this business, then Disconnect. This deletes the stored HMRC connection key. The business should also remove VATRelay's authority in its HMRC online account.
  5. Preserve evidence before changing anything else: copy the database (Supabase backups), the activity log (the audit_events table) and the logs from Render, Supabase and Stripe to secure storage. Submissions and the activity log cannot be changed or deleted through VATRelay. Do not try to alter them.

5. Assess (within 24 hours)

Work out and write down:

  • What happened, and when it started and ended, as far as known.
  • Which data is affected, for example:
    • customer email addresses and accounts;
    • business names, VAT numbers and HMRC-registered addresses;
    • VAT return figures, HMRC receipts and payment records;
    • HMRC connection keys;
    • fraud prevention data, such as IP addresses and device identifiers.
  • Which customers and people are affected, and how many.
  • Whether HMRC systems or taxpayers' HMRC accounts could have been reached, for example if HMRC connection keys were valid at the time.
  • Whether any return was, or could have been, submitted without authority. Check the submission records and, with the business, its HMRC online account.
  • Whether money was affected, for example payments taken or refunded without authority.
  • The likely consequences for the people and businesses affected.
  • Whether the incident is over, or still happening.

6. Tell HMRC (immediately; full details within 72 hours)

Report any issue concerning the security of personal or customer data, or of VATRelay's access to HMRC, as soon as you know about it. Do not wait until the assessment is finished.

  1. Log a ticket on the HMRC Developer Hub support page: https://developer.service.hmrc.gov.uk/devhub-support
  2. Include:
    • that this is a security incident report;
    • the software name (VATRelay), the application name and Client ID on the Developer Hub, and whether sandbox or production is affected;
    • the breach contact name and telephone number;
    • when the incident was discovered, and when it is believed to have started;
    • what happened, as far as known, and what has been done to contain it;
    • the VAT registration numbers of the businesses affected, and whether any unauthorised submission is suspected;
    • what you will do next, and when you will send an update.
  3. Send full details within 72 hours of becoming aware, by updating the same ticket, even if some facts are still unknown. Give regular updates until HMRC agrees the incident is closed.
  4. Follow HMRC's instructions, including any request to stop using the production credentials.

7. Tell the ICO and the people affected

  • ICO, within 72 hours: if personal data is involved, report it to the ICO within 72 hours of becoming aware, unless the breach is unlikely to put people's rights and freedoms at risk. Personal data includes email addresses, names, addresses, the VAT numbers of sole traders, user names, and IP addresses.
  • People affected, without undue delay: if the breach is likely to put them at high risk, tell the affected customers directly, by email. Explain:
    • what happened;
    • the likely consequences;
    • what we have done;
    • what they should do, for example change their password, check their HMRC online account, and remove VATRelay's authority if needed.
  • Suppliers: where the incident involves Supabase, Render or Stripe, report it to them as well, following their own security reporting process.

8. After the incident

  • Find the root cause, and fix it in VATRelay or in how it is run.
  • Test the fix before reconnecting businesses or reopening the service.
  • Update this process, and the operating checks below, with anything learned.
  • Tell HMRC what was changed, on the same ticket.

9. Incident log

Keep a record of every incident, including those not reported to HMRC or the ICO:

ItemRecord
Incident reference
Date and time discovered, and by whom
Description
Data, customers and businesses affected
Containment actions and times
HMRC ticket reference and time logged
ICO reference and time reported (or reason not reported)
Customers and others told, and when
Root cause
Lessons learned and changes made
Closed on, and by whom

Keep incident logs for at least 6 years.

10. How VATRelay is protected

These controls reduce the chance and impact of an incident. Keep them in place.

  • Two-step sign-in: a password and a code from an authenticator app. Codes cannot be reused, and you are signed out after a period without activity and always within 12 hours.
  • HMRC connection keys are encrypted when stored. Government Gateway details are never seen or stored.
  • Submitted returns and the activity log are permanent: they cannot be changed or deleted through VATRelay.
  • No filing twice: a period cannot be submitted twice, and a return whose outcome is unknown is never resubmitted automatically.
  • Forms are protected against requests forged by other websites.
  • Pages are protected by a strict content security policy and are never shown inside other websites.
  • Each customer sees only their own data, and the database refuses access through Supabase's public interface.
  • All connections are encrypted (HTTPS), and cookies are only sent over HTTPS.
  • Card payments are handled by Stripe; we never see card numbers. Every payment is checked directly with Stripe before a return is submitted.
  • Secrets are held only in the hosting provider's settings, never in the code, which is public.

Operating checks:

  • Turn on two-step sign-in for every account used to run VATRelay (Render, Supabase, Stripe, GitHub, HMRC Developer Hub).
  • Only give these accounts to the people who need them, and remove access when someone leaves.
  • Review Supabase, Render and Stripe security alerts, and keep VATRelay's software dependencies up to date.