Security that is built in, not bolted on after the questionnaire.
Most security problems in small software are not exotic. They are an access key committed to a repository two years ago, a database open to the internet because somebody needed to debug something, permissions nobody has reviewed, and no way to tell what changed or when. We build to avoid those, because it is how we run our own platform.
The problems we are normally called in to fix.
Secrets live in the repository
Environment files committed once and never rotated. Every developer who ever cloned it has them, including the ones who left.
A deal stalls on a security questionnaire
The buyer sends a supplier assessment and nobody can answer where the data lives, who can reach it or what happens if a laptop is lost. The work is done, the deal is not.
Permissions nobody has looked at
A cloud account where everything can reach everything, because it was quicker at the time and nobody has audited it since.
No way to prove what happened
Without deployment history, audit trails and logs you cannot answer the only question that matters after an incident, which is what changed.
What security and secure development means here.
Secrets management
Credentials out of the repository and into a managed store, pulled at runtime. Our own manifests hold references and never values, with secret scanning in CI as the backstop.
Cloud and access review
IAM permissions scoped to what each service genuinely needs, short-lived role credentials rather than long-lived keys, and a written account of what is exposed.
Supply chain and deployment integrity
Images pinned by digest rather than by tag, dependency scanning, and a deployment history that says exactly what is running and who put it there.
Data protection review
What personal data you hold, where it lives, how long you keep it and what a subject access request would actually involve. Written plainly, for UK GDPR.
Security questionnaire support
Answering the supplier assessments that hold up deals, and fixing whatever the honest answers reveal.
Penetration testing
Delivered with certified specialists we bring in, because a test is only worth having if the certificate behind it means something to your buyer. We scope it, they test it, we fix what it finds.
The outcome we aim at.
- Credentials that can be rotated without a deployment
- A cloud account somebody has actually reviewed
- Answers ready for the supplier assessment before it arrives
- A deployment history that can be audited after an incident
What actually moves the price.
- Whether this is a review of what exists or a rebuild of how it is deployed
- How much of the estate is in infrastructure as code already
- Whether formal penetration testing and a certificate are required
- Whether you handle special category data, which changes the obligations
We quote a fixed shape of work with a price and a date on it, rather than an hourly rate that grows.
Sectors that need this most.
AI & SaaS
AI products, agents and automation platforms, and the B2B SaaS they are built into.
Health & Healthcare Technology
Patient portals, clinic software and digital health products, built for UK data rules.
Professional Services
Law firms, dental and private clinics, accountants and recruiters. High value clients, so marketing pays for itself quickly.
Straight answers.
Do you do penetration testing yourselves?
We scope it and fix what it finds, and the testing is done by certified specialists we bring in. That is deliberate: many buyers will only accept a test carried out under a recognised certification, so a test from us would be worth less to you than one from them.
Can you help with a supplier security questionnaire?
Yes, and it is a common first piece of work. Usually the questionnaire is not the problem, it is that answering it honestly reveals two or three things worth fixing.
What do you actually run yourselves?
Secrets pulled from AWS SSM at runtime, so the manifests hold references and never values. Secret scanning in CI. Container images pinned by digest rather than tag. Short-lived role credentials through OIDC federation instead of stored access keys. Production that does not deploy itself automatically.
Are you certified?
Not yet, and we will tell you that rather than imply otherwise. If your procurement requires Cyber Essentials or an accredited tester, say so at the start and we will either get there or bring in someone who already is.
We think we have already been breached. Can you help?
Incident response is not what we do, and you want a specialist firm on it within the hour rather than a development team. Call one. We can help afterwards with what needs rebuilding.
Tell us what you need building.
A couple of lines is enough to start. You will get a straight answer on scope, cost and timeline within one working day.