Security and trust

Last reviewed by us: 15 September 2026

This page describes the security measures that are actually in place on the OptiTech Automation platform on the date above. It is a description, not a promise about how the service will perform. Where we have not built something, this page says nothing about it rather than implying it exists. If a measure is not named here, please do not assume it is there. There has been no external review. The check behind the date above is our own, of our own systems, and we will say so here on the day that changes.

1. Who holds your data, and where it sits

OptiTech Automation is a UK sole trader. Your data sits in one database in the European Union, in Ireland. Every company that touches it is named on our sub-processors page. Some of it also reaches companies outside the EU, each named on our sub-processors page with the legal cover for it.

OptiTech Automation is the trading name of Cristian Moise-Putanu, a sole trader based in Torquay, Devon, England. There is no company behind it and no other staff. One person is accountable for everything on this page.

Your business data, your workers and your customers all live in one database run by Supabase, physically located in the European Union, in Dublin, Ireland. The website and the app themselves run on Vercel.

Every other company that touches your data is listed on our sub-processors page, with what it does, where it is, and the legal cover for sending data there. That list is kept current and we give thirty days notice before adding or replacing anyone on it.

Sub-processors list / Data Processing Schedule (Schedule 1 of the Terms)

We are registered with the Information Commissioner's Office under registration number C1963975.

2. How your business is kept apart from every other one

The database itself refuses to hand one business's rows to another. It is not the app being careful. It is a rule inside the database, on every table.

Every row of your data carries your business identity. The database has a rule set switched on for every table that checks that identity before it returns anything. If a request is not yours then, for everything except those public lists, the rows are not there to be read, whatever the app asks for.

This was checked table by table across the whole database, and we re-run that check by hand against the live database.

Where many parts of the system write to the same kind of record, the business identity is stamped on by the database itself rather than by each piece of code remembering to do it.

3. Who can see what

You see your business. A worker sees their own work. A customer sees their own booking. A few small lists are public on purpose because a booking page has to show them, and none of those holds personal data.

Each person signs in as themselves and the system works out what they are allowed to reach before any page or any request is answered. An owner reaches their own business. A worker reaches their own jobs and their own pay records. A customer reaches their own bookings.

A small number of lists are readable without signing in, because a public booking page cannot work otherwise: the open founding member places, the times a business has free to book, county availability, the plan options, and published reviews as a visitor sees them.

When someone from OptiTech Automation opens your account for support, an email is sent to the owner's address on file saying that the session has started, who opened it and why.

A support session is read only unless a separate, time limited permission is issued for it, and that permission is checked by the server on every single change, not just at the door.

Our own admin screens and admin requests are gated by a flag that lives inside the signed sign-in token and is set by us. It is not something an account holder can give themselves.

4. Signing in

We never hold your password. Sensitive actions ask you to prove it is you again. Requests are rate limited. The connection is encrypted and cannot fall back to an unencrypted one.

Owner, worker and customer passwords are handled by our authentication provider and are never stored in readable form anywhere in our own tables. Nobody here can look your password up.

Repeated failed sign in attempts on our sign in routes are counted and the account is locked for a while. That slows guessing down. We describe it as what it is, a speed bump, rather than as a wall.

Sensitive owner actions need a fresh step up: you prove it is you again and that permission lasts fifteen minutes. Only one of those can be live at a time, so an older one cannot be kept alive on the side.

If you want it, you can turn on an authenticator app code that is then required before a full copy of your business data can be downloaded. It applies to that one action, and only someone signed in as the owner can switch it on.

Requests that change something are rate limited on the owner, worker, clock in and admin routes. Admin requests also have to come from our own site, which blocks a forged request sent from somewhere else.

Everything travels over an encrypted connection, and browsers are instructed for a year ahead never to try an unencrypted one, for the site and everything under it. The browser is also told which places it is allowed to load code from at all, and anything that breaks that rule on the app is reported back to us.

5. Payments and card details

Card details go straight to Stripe. They are never sent to us, and we have nowhere to put them if they were.

When a card is entered, it is typed into a payment field served by Stripe and goes straight to Stripe. The number never reaches our servers, we never see it, and there is no field anywhere in our database that could hold one. What we keep is a reference from Stripe, not a card.

Stripe handles subscription billing and worker payouts as well. Payments for your jobs land in your own Stripe account, not in ours.

6. Monitoring and alerts

A watch that lives outside the platform checks it every ten minutes and raises an alarm when something changes. We do not publish a monthly percentage for it, and this page makes no promise about one.

The platform is watched from a separate system that runs outside the app, so it can still raise the alarm when the platform itself cannot. Every ten minutes it checks that the app is answering properly.

It checks twice before it decides anything, so a momentary blip is not treated as a failure. When the answer really does change it sends an alert to a phone straight away, and reminds hourly until it is fixed. Every change is written down and kept for a fixed period, so what happened and when can be read back afterwards.

We do not publish a monthly percentage for how the platform performs, here or anywhere, and this page makes no commitment about it either way. Our monitoring record is the basis of anything the Service Level Agreement owes you, and that document, not this page, is where our service commitments live. Service Level Agreement

A security sweep runs once a week and reports to the same phone. Before any code is committed, both of our codebases are scanned for a secret key that should not be there, so a leaked credential is caught at the keyboard rather than in the wild.

Application errors are collected so we can find and fix them, with personal details stripped out of the error reports.

7. What we ask of you

Use a password you use nowhere else. Be careful who you invite. Take leavers off the same day. Tell us fast if something looks wrong.

Use a password for your account that you have not used anywhere else. Most break ins of this kind are not clever. Someone takes a password leaked from an unrelated website and tries it here.

Give a manager their own manager account. Do not hand them the owner login. A manager signed in on your login looks exactly like you to us, and to the system, and nothing we build can tell the two of you apart.

When someone leaves, switch them off in the app that day. Deactivating a worker or a manager takes effect immediately on their next request, so it is worth doing straight away rather than at the end of the week.

If something looks wrong, tell us before you tidy it up. The records that show what happened do not last long, so the first hour matters more than a clean screen.

8. How to report a security concern

Email us. Say what you saw and when you saw it. We will not come after anyone who reports a real problem in good faith.

If you think you have found a security problem, or you think someone has got into an account that is not theirs, email us. For anything involving personal data, use the privacy address.

hello@optitechautomation.co.uk / privacy@optitechautomation.co.uk

Tell us what you saw, roughly when, and what you were doing at the time. You do not need to prove anything or write it up formally. A short message that says something is wrong is more useful to us than a polished one that arrives a week later.

We will not take any action against someone who raises a genuine concern in good faith, even if it turns out there was nothing wrong. We do not run a paid reward scheme for security reports, so please do not test anything live, and never use another person's account to prove a point.

9. What this page is not

It is not an accreditation, it is not a promise about performance, and it is only true on the date at the top.

We hold no independent security accreditation and we do not claim one. Nothing on this page has been audited by an outside body. It is a plain description of what we have built, written by the person who built it.

Nothing here is a promise about how the service will perform, and nothing here forms part of a contract. The Business Owner Terms and Conditions and the Service Level Agreement are the documents that say what we owe you. Business Owner Terms and Conditions

Security measures change. This page is true on the date at the top and we re-read it whenever something on it changes. If you are relying on a specific point here, ask us and we will confirm it in writing rather than leaving you to trust a web page. hello@optitechautomation.co.uk