Authentication
Sessions handled properly, passwords stored using a current algorithm, multi-factor available where the data justifies it, and a real password-reset flow rather than an email with a link that never expires.
How it usually goes wrong
Most business software doesn't get breached. It gets neglected.
The picture people have of a security failure is an attacker picking a lock. The common reality is duller: an application built four years ago, running libraries with published vulnerabilities, with an administrator account belonging to someone who left in 2023, and no monitoring to notice any of it.
Nothing dramatic happened. Nobody was negligent. The system simply stopped having anyone responsible for it, and the world kept moving.
That is why security here is inseparable from the ongoing work. A one-off secure build that nobody maintains is secure for about a year.
Throughout
Where the security work actually happens.
The same six stages a project runs through, with what security means at each one. Stage 04 is a dedicated review — but it is checking work that was already done carefully, not doing it for the first time.
Understand
What data the business holds, who legitimately needs it, and what would actually hurt if it leaked.
Design
The permission model designed alongside the workflow, rather than retrofitted once the screens exist.
Build
Authorisation on every route, input handled safely, secrets kept out of the codebase from the first commit.
Secure
Dedicated reviewA deliberate review pass: access, dependencies, data handling, logging, and what happens when something fails.
Launch
Production credentials separated, monitoring live before the users are, backups running and tested.
Improve
Dependencies updated on a schedule and access reviewed as people join and leave.
Practice
What we do on every project.
Specific enough that a technical person on your side can hold us to it, and general enough to apply to every system we build.
Limits
What we don't claim.
Every item here is something a supplier could imply and we will not. If any of them changes — a certification achieved, a standard adopted — it will be stated here with its scope and its date.
No certifications
We hold no ISO 27001, no SOC 2, no Cyber Essentials at the time of writing. If your procurement process requires one, we are not currently the right supplier and we would rather you knew now.
Not a penetration-testing firm
We review our own work carefully, which is not the same as an independent adversarial test. Where the risk justifies one, commission it from a specialist — and we will fix what it finds.
No guarantee of invulnerability
No honest engineer will tell you a system cannot be compromised. What we will tell you is what we do to make it unlikely, and what happens if it occurs anyway.
No uptime figures we have not measured
We will not quote a percentage for a system that does not exist yet. Once yours is running, its actual availability is something you can see.
Compliance advice is not legal advice
We build systems that handle personal data carefully and can support your obligations under UK GDPR. We are not your data-protection adviser and will not pretend to be.
Already have something running?
If nobody has looked at it in two years, that is the thing to fix first.
We take on existing systems. That starts with a review of what is actually there — dependencies, access, data handling, backups, monitoring — and a written account of what we found, what it would cost to put right, and what is not worth keeping.
It is a genuinely useful piece of work on its own. Plenty of businesses have used it to discover their software was in better shape than they feared.