This page sets out what we actually do on every engagement: how changes are reviewed, how authorisation is resolved, how secrets and dependencies are handled, and how backups are proven. It claims no certification, because we hold none.
It is the single failure we find most often in systems we are asked to review. A control is removed from the interface for users who should not have it, and the underlying request is left unprotected — so anyone who can construct that request can perform the action.
Every operation is authorised on the server, in the same order, with no exceptions for internal tools or administrative screens.
Only when all four pass does the operation run — and it is recorded when it does. Removing a control from the interface remains worth doing, but it is a usability decision. It is never the thing standing between an actor and your data.
Fig. 01 — Server-side authorisation path
The interface layer sits outside the authorisation path entirely: it hides controls for clarity and is not a security boundary. The request itself passes through authentication, a role check, a record-relationship check and schema validation, and a failure at any of the four refuses it.
Open any of them for what it means in practice. Each is written so you could ask us to demonstrate it — which is the only useful test of a claim on a page like this.
Security work is distributed across the project, not appended to the end of it.
Threats are considered when the data model is designed, not after the interface is built. Each significant feature is examined for what an authenticated but unauthorised actor could do with it, what happens when an input is hostile rather than merely wrong, and what is written to logs. A written review checklist is worked through before anything reaches production, and its findings are fixed or explicitly accepted with a reason.
Every change is read by a second engineer before it can merge.
Work lands in short-lived branches behind pull requests. Automated checks — types, linting, tests and accessibility — run first, so review time is spent on the parts a machine cannot judge: whether the authorisation is in the right place, whether the failure modes were considered, and whether the next person will understand it. Nothing reaches production by another route, including work done under time pressure.
Authorisation is resolved on the server, in the same order, every time.
Authenticate the actor, check that their role holds the permission, check their relationship to the specific record, validate the input against a schema, then perform the operation and record it. Client scoping is a database predicate, never a filter applied after data has been fetched. Roles carry the narrowest set of permissions that lets someone do their job, and privileged actions are written to an append-only audit log with sensitive values redacted.
Credentials live in a managed secret store, and environments are genuinely separate.
Secrets are never committed to a repository, never placed in a configuration file that travels with the code, and never included in a browser bundle. Development, staging and production are separate environments with separate credentials, so a compromised development key cannot reach live data. Staging is populated with anonymised or synthetic data wherever the real thing is not required, and access to production credentials is limited to the people who need it and revoked when they no longer do.
Third-party code is watched, updated on a cadence, and kept deliberately small.
Automated advisories run against the dependency tree, and updates are applied as routine scheduled work rather than as an emergency after a disclosure. We prefer fewer dependencies with clearer provenance to a large tree of transitive packages nobody has read. Lockfiles are committed so a build is reproducible, and a dependency that is unmaintained is treated as a defect to be planned out, not a fact of life.
A backup that has never been restored is a belief, not a backup.
Backups are automated, encrypted and retained on a schedule agreed with you. More importantly, restores are actually performed on a schedule into a scratch environment, timed, and carried out by following a written runbook that somebody other than its author can execute. The result of each test — including how long it took — is recorded, because the number you need in an incident is the one you measured, not the one you assumed.
Alerts route to a person, and the dashboards are handed over.
Availability, error rates, performance budgets and backup success are monitored, with alerts routed to somebody who can act rather than into a channel nobody reads. Logs are structured and retained long enough to investigate an incident, and never contain secrets or full personal records. Dashboards and alert rules are part of the handover, so you can see the system yourself rather than asking us what it is doing.
Collect less, keep it for less time, and be able to explain both.
Personal data is minimised at the point of collection, has a defined retention period, and is deletable on request without a manual database intervention. Transport is encrypted, storage is encrypted at rest where the platform supports it, and passwords are stored using a memory-hard hash — never encrypted, never recoverable. Where a project involves a processor relationship, the responsibilities are written down rather than assumed.
Automated where it pays for itself, manual where judgement is required.
Unit tests cover logic, integration tests cover the boundaries where systems disagree, and end-to-end tests cover the handful of journeys that must never break. Authorisation is tested as behaviour — a request from the wrong actor is expected to be refused — rather than assumed from the fact that the control is hidden. Accessibility and cross-device checks run as part of the definition of done, not as a phase that gets compressed when a date moves.
Everything above describes work we do. This section describes what we are not telling you, and why — because the absence of a claim is easier to verify than its presence.
No certifications are held or displayed
A system is only as protected as the accounts and processes around it. These sit with you, and we will say so during discovery rather than after an incident.
Every practice on this page is one you can ask about specifically — how authorisation is tested, when the last restore was timed, what the patching cadence would be for your system. Specific questions get specific answers.
We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.