Trust is built in, not bolted on.
Approach
Behind every website and every system we build is data that someone has entrusted to us. That is why we build security into a project from the very first line of code, not as a checklist ticked off just before delivery. Strict access control, two-factor authentication, encryption and layered defences are part of the build itself, and we never collect more data than the service needs.
Principles
Secure by default
Nothing is open unless it is opened deliberately. New databases, file storage and web services start locked, and only what genuinely belongs in public is made public. That way nothing becomes accessible by accident.
Least privilege
Each part of a system gets exactly the permissions its work requires and nothing beyond that. Keys with full access exist only on the server and never travel into the user's browser, where no one should ever see them.
Defence in depth
We never rely on any single safeguard. Authentication, authorisation, validated input, encryption and monitoring work together in layers, so that if one layer fails the others take over. To reach the data all the way through, many things would have to go wrong at once.
Data minimisation
Data that is never collected can never leak. That is why we keep only what the service needs, delete it once it has done its job, and never store sensitive identifiers in raw form.
Code security
What security looks like in the code itself
Strict typing and review
All code is written in with the strictest settings, and no change ships without review and automated tests. That way the compiler catches whole classes of bugs, and with them security flaws, long before they reach production.
Security rules in the database
Access control lives not only in the code but in the database itself. With a technique called , every single row carries its own rules about who may read and change it. Even if a bug slipped into the application, access would still be protected at the database level.
Validated input
Everything users submit is validated on the server, not only in the browser, where controls are easy to bypass. Defences against injection, SSRF and other known attack paths are built in, and rate limiting stops open endpoints from being abused.
Secrets outside the code
keys, connection strings and other secrets are stored in the hosting platform's environment variables, never inside the code or its version history. They can be rotated without touching the code, and each key covers only the role it is meant for.
Updates and the supply chain
Every dependency is pinned to an exact version and updated regularly. We follow vulnerability advisories across everything the systems rely on, and when a fix arrives it reaches production in days rather than months.
Encryption everywhere
All traffic travels over an encrypted HTTPS connection, and ensures the browser never settles for anything less. Data is likewise encrypted at rest, and sensitive identifiers such as IP addresses are hashed before they are stored, so they never exist anywhere in readable form.
Two-factor auth
A password is not enough. Two-factor authentication is our default requirement.
Two-factor authentication (2FA, sometimes called ) adds a second step to signing in. The first step is something you know, your password, and the second is something you have, such as your phone. Even if the password leaks in a breach, is caught by a phishing scam or has been reused elsewhere, no one gets in without the second step.
Why do we place so much weight on this? Because the vast majority of account break-ins have nothing to do with a technical vulnerability and instead start with a stolen password. Two-factor authentication stops almost every automated attack of that kind, and it is the cheapest and most effective security improvement most companies can make.
We use the standard. An authenticator app such as 1Password, Google Authenticator or Microsoft Authenticator generates a six-digit code that is valid for half a minute. The code is created inside the device itself, never crosses the network where it could be intercepted, and works even without cell coverage. We recommend an authenticator app over SMS codes, since an SMS can be intercepted by having the phone number transferred. Backup codes are provided at setup so you are not locked out even if the device is lost.
In our own systems this is not optional. The admin consoles of the sites we run require authentication before any sensitive action takes place, and permissions are verified on the server on every single request, not just when you sign in. Client portals use magic links by email instead of passwords, so there is simply no password there that can leak.
When we hand over a system, two-factor authentication comes with it from day one. It is active for every administrator, and setting it up is part of the delivery. We also strongly encourage clients to do the same everywhere else, whether in email, hosting or domain management, because one hijacked inbox can open the door to everything else.
Data
Privacy is part of security
Security and privacy go hand in hand. We collect only the information the service needs, keep it no longer than there is reason to, and delete it automatically when its retention period runs out.
Sensitive identifiers are protected from the very first contact. IP addresses, for example, are never stored in raw form but hashed before they reach the database. Access to personal data is restricted to administrators with two-factor authentication, and all processing complies with data protection law and .
Operations
Security in operations, not just in code
The sites run on , where every request is handled in an isolated environment and a global distribution network absorbs denial-of-service attacks before they reach the systems. The data lives in with automatic backups, so it can be restored if something goes wrong.
The systems are monitored around the clock. If an unexpected error occurs, we are notified at once, with enough context to trace the cause but without any personally identifiable data. New features ship in small steps that are easy to trace and to roll back if needed.
Disclosure
Found a vulnerability?
If you believe you have come across a security vulnerability in our systems or those of our clients, we want to hear about it, ideally before anyone else. Send us a note describing the issue and how to reproduce it. We respond quickly, take every report seriously, and impose no penalties on anyone who lets us know in good faith.
vefapp@datatech.isSee also
Next
Want a system you can trust?
Get in touch →