Menu

Data security

Last updated 3 November 2026

How we protect data in OmniSync Retail, and what we do if something goes wrong. This page is Annex 2 of our data processing agreement.

Signing in

  • Passwords are stored only as bcrypt hashes. Nobody at Versifyd can read them.
  • Password rules: a minimum length and mix of characters, no reuse of the last 10 passwords, and a password expiry after 365 days with a warning 14 days before.
  • Two-step verification with an authenticator app, with 8 single-use backup codes. It is required for our own admin accounts. Account owners can require it for their whole team.
  • The secret keys and backup codes for two-step verification are encrypted in the database.
  • Repeated failed sign-in attempts are slowed down and then blocked for a while, and so are repeated wrong manager PINs at the till.
  • Signed-in sessions end after 8 hours without activity.

Keeping each shop's data separate

  • Every record belongs to one company. Every database query is automatically limited to the signed-in user's company, so one shop cannot see another's data.
  • Within a company, roles decide what each user can see and do. Back office pages a role is not given are blocked.
  • Sensitive till actions, such as voids, refunds and price overrides, can require a manager and are recorded with who did them and when.
  • An activity log records important changes in each account.

In transit and on the server

  • All traffic to the app and this website is encrypted with HTTPS (TLS).
  • Every form is protected against cross-site request forgery.
  • Payment messages from Paddle are checked against a secret signature before we act on them.
  • Card and bank details never reach our servers. Paddle handles them.
  • The app runs on managed hosting in a European data centre, with the hosting provider's physical security, network protection and monitoring.
  • Debug output is switched off in production, and secret keys are kept out of the code.
  • Fonts and scripts are served from our own server. A content security policy stops the browser loading code from anywhere else, apart from Paddle's checkout.

Backups

  • The database and files are backed up automatically by our host.
  • Backups are kept on a rolling cycle and overwritten, at most 30 days later.
  • We test that backups can be restored.

Our own access

  • Only Versifyd staff who need it can reach the servers, database or the admin side of the app, each with their own account.
  • Our hosting, payment, email and code accounts use two-step verification.
  • Everyone with access is bound by confidentiality, and access is removed when someone leaves.
  • We look at a customer's data only to run the service, fix a fault, answer a support request, or meet the law.

Building the software

  • Every release is tested automatically before it goes live, and released with a version number and change log.
  • We keep the framework and libraries up to date and apply security fixes promptly.
  • Inputs are checked on the server, and database access uses parameterised queries.

Data breach procedure

A personal data breach is any security problem that leads to personal data being lost, destroyed, changed, disclosed or accessed without permission, by accident or on purpose. If we suspect one, we follow these steps.

  1. Contain it. As soon as we know, we stop the cause: for example lock affected accounts, reset keys and passwords, block access, or take part of the service offline.
  2. Assess it. We work out what happened, what data and which customers and people are affected, whether the data was protected (for example encrypted or hashed), and how likely and serious the harm could be.
  3. Tell the shops affected. Where the data belongs to a shop's account, we email its owner without undue delay and within 48 hours of becoming aware. We say what we know, what we are doing, and what they should do, and send updates as we learn more.
  4. Tell the authority. Where we are the controller and there is a risk to people, we tell the relevant data protection authority within 72 hours of becoming aware. Where we are the processor, we give the shop what it needs to make its own report in time.
  5. Tell the people affected. Where there is a high risk to them, they are told without undue delay in plain language, with steps they can take to protect themselves. Where we are the controller we do this; where we are the processor we help the shop do it.
  6. Fix and recover. We fix the cause, restore data from backup if needed, and check that the fix works.
  7. Record and learn. We keep a written record of every breach, even small ones that need no report: the facts, effects and action taken. We review what went wrong and change how we work so it doesn't happen again.

Reporting a security problem

If you think you have found a security weakness in OmniSync Retail, or that your account has been misused, email [email protected] straight away with as much detail as you can. Please don't test it further or access other people's data. We will reply within 2 working days and keep you told about the fix.

What you can do

  • Turn on two-step verification, and require it for your team in Settings.
  • Give each member of staff their own account and the smallest role they need.
  • Remove staff accounts as soon as someone leaves.
  • Lock or sign out of tills and back office computers when they are not in use.
  • Don't put card numbers, health details or other sensitive data in notes or free text fields.