Services / Cloud / Security & compliance

Secure by default, and provable when someone asks

Most breaches are not sophisticated. They are a key left in an old repository, an admin account without a second factor, a storage bucket opened for a quick test and never closed again. We shut those doors, keep them shut automatically, and leave you the evidence your customers and auditors will ask for.

Start the conversation →See the technology

Why it matters

The cost is the wait

The picture most people carry of a breach, someone clever defeating a firewall, is not the one that actually happens. What happens is that a credential leaks and somebody logs in. A key sits in an old repository nobody has looked at for years. A contractor's account is never removed. An integration is granted full administrative access because narrowing it looked like an afternoon of work. None of this requires sophistication, and all of it is preventable.

It is worth separating two things that get spoken about as though they were one. Security is engineering, and it is not optional. We build it in whether you ask for it or not. Compliance is a legal and contractual obligation that belongs to you: GDPR, HIPAA, PCI-DSS, SOC 2 and the rest are frameworks your business must satisfy, and no supplier can be compliant on your behalf. What we can do is engineer your systems to the standard those frameworks demand and produce the evidence continuously, so your auditors and advisors have an easy job.

In practice that means starting with identity, because that is where incidents start. Then least privilege, secrets kept properly, encryption everywhere, an audit trail that survives contact with an attacker, and backups they cannot delete. Then we make it stay that way, hardening expressed as code and checked automatically, rather than a one-off tidy-up that quietly decays over the following six months.

What you actually get

Built to be trusted

None of this is exotic. It is the set of controls that would have prevented most of the incidents you have read about.

Identity comes first

Single sign-on against one identity provider, multi-factor authentication with no exceptions for senior people, no shared logins, and joiners and leavers handled automatically. An account that disappears the day someone leaves cannot be used against you six months later.

Least privilege, granted temporarily

Access scoped to the job rather than to the person's seniority, administrative rights requested when needed and expiring afterwards, and a documented break-glass account for genuine emergencies. This is what limits the damage when one credential is stolen, which is the realistic scenario to plan for.

Secrets out of code, and out of chat

Credentials, keys and tokens live in a managed vault with automatic rotation and a record of who accessed what. We also scan your existing repositories and their full history during onboarding, because that is where we most often find live keys everyone assumed were long gone.

Encrypted everywhere, certificates that never surprise you

Data encrypted in storage and in transit as standard, keys managed properly rather than pasted into configuration, and certificates issued and renewed automatically with alerting well ahead of expiry. An expired certificate is still one of the most common self-inflicted outages there is.

Backups an attacker cannot destroy

Ransomware goes for the backups first. Yours are held in a separate account with separate credentials, written so they cannot be altered or deleted for a defined period, and restored on a schedule so you know they work before you need them to.

Evidence, not assurances

Administrative activity logged to storage that cannot be quietly edited, access reviews on a schedule, change records produced by your own pipeline, and a pack you can hand to a customer's security team or an auditor without a fortnight of preparation first.

Where it earns its keep

Same pattern, different desks

The controls overlap heavily between industries. What changes is which framework you are measured against, and who is doing the measuring.

01 · Healthcare & clinics

Patient data on a system built for convenience

The problem: Records are reachable by more staff than strictly need them, access is not logged in a way anybody could reconstruct afterwards, and several small suppliers touch the data with no agreements in place. The practice is not careless, the systems simply grew around the work.
What we build: Patient data is separated and encrypted with access cut to the minimum necessary role by role, every read and write is logged to storage that cannot be edited, retention and deletion are implemented rather than merely described in a policy, and each supplier is brought under a proper data-processing agreement.
What changes: A defensible answer to who accessed what and when, a deletion request that actually executes end to end, and documentation the practice's own data-protection officer can work from.

02 · Payments & fintech

In scope for far more than necessary

The problem: Card details pass through the company's own systems on their way to the payment provider, which drags a great deal of infrastructure into PCI-DSS scope and turns every annual assessment into a project of its own.
What we build: The flow is redesigned so card data travels directly from the customer's browser to the payment provider and never touches your servers. Tokenised references are all you store. What remains is segmented so the assessed boundary is small, clearly defined and documented.
What changes: A much smaller compliance footprint, a lighter assessment each year, and an architecture where a breach of the main application cannot expose card data, because the card data was never there.

03 · B2B software selling into enterprise

The security questionnaire that stalls every deal

The problem: Larger prospects send a two-hundred-question security review before they will sign anything. Each one takes weeks, answers drift between them, and deals sit in limbo while a founder writes prose about controls the product does not actually have yet.
What we build: We implement the controls those questionnaires genuinely test: enforced single sign-on, role-based access, audit logging, encryption, tested backups, change management, vulnerability scanning and a written incident response plan, and wire them so they produce their own evidence continuously rather than on request.
What changes: Questionnaires answered in days from a maintained evidence pack, a credible position when a SOC 2 audit is eventually demanded, and security stops being the reason the quarter's largest deal slips.

The technology

The tools behind it, named

Security tooling is only ever as good as the configuration underneath it, so we favour a small number of well-understood pieces over a sprawl of dashboards nobody reads.

6 layers · 31 technologies

Identity & access

Where almost every incident begins, and therefore where the most valuable hour of work you will ever buy is spent.

Okta
Auth0
Keycloak
Microsoft Entra ID
Google Workspace

Secrets & keys

Credentials belong in a vault with rotation and an access record, never in a configuration file, a repository, or a message thread somebody can scroll back through.

HashiCorp Vault
1Password
Bitwarden
Cloud KMS & HSM

Finding the holes first

Dependencies, containers, infrastructure code and the application itself, scanned continuously inside your pipeline rather than once a year by someone with a clipboard.

Snyk
Trivy
SonarQube
Dependabot
OWASP
GitHub Actions

Defending the edge and the runtime

Filtering traffic before it ever reaches you, and noticing when something already inside starts behaving unlike itself.

Cloudflare
Falco
Cilium
NGINX
Let's Encrypt

The audit trail

Logs that cannot be quietly edited, retained for as long as your obligations require, and searchable at the moment an incident or an auditor demands it.

Elastic
OpenSearch
Grafana
OpenTelemetry
Sentry

Hardened, and kept that way

The secure configuration is code. Drift is detected automatically, because a manual tidy-up decays within months of the person who did it moving on.

Terraform
OpenTofu
Ansible
Kubernetes
Docker
Red Hat Enterprise Linux

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

We usually start with a fixed-scope review, because arguing about priorities gets much easier once there is a findings list on the table.

A read-only review against a real baseline

We assess your accounts, identity, network, data stores and pipelines against published benchmarks, the cloud provider's own best practice and the CIS baselines rather than against anybody's opinion. Nothing changes at this stage.

Findings ranked by what is actually exploitable

A long list of theoretical weaknesses helps nobody. Findings are sorted by how likely they are to be used against you and what it would cost if they were, with the handful that need fixing this week clearly separated from the rest.

Identity first

Single sign-on, multi-factor everywhere, dormant and orphaned accounts removed, over-permissioned roles narrowed, and secrets moved into a vault with anything already leaked rotated. This is where risk reduction per hour of work is highest, by a distance.

Hardening written as code

The secure configuration is expressed in infrastructure code and enforced by policy checks in your pipeline, so a change that would open a bucket or widen a firewall rule is refused before it is applied, rather than discovered in next year's audit.

Independent testing, then a retest

We coordinate professional penetration testing (deliberately not carried out by us, because marking your own homework is not a security control), triage the findings by real exploitability, fix them, and confirm with a retest. You keep the whole package.

The part that never finishes

Scheduled access reviews, continuous scanning, a patching rhythm, incident runbooks and a rehearsed response. We run the rehearsal too, because a plan nobody has practised is a document rather than a capability.

Before you commit

The questions worth asking

Can you make us HIPAA or SOC 2 compliant?

No, and be wary of anyone who says they can. Compliance is awarded by an auditor or assessor against your organisation as a whole, including processes and paperwork that have nothing to do with infrastructure. What we do is engineer your systems to meet the technical controls those frameworks require, and produce the evidence continuously, so the audit becomes an exercise in collecting what already exists. Certification, legal interpretation and sign-off stay with your auditor and your advisors, and that separation is in your interest, not just ours.

How long until we're secure?

Security is not a state you arrive at. The first pass (identity, secrets, obvious exposure) usually takes weeks and removes most of the realistic risk. After that it becomes a rhythm: patching, reviews, scanning, rehearsals. Any supplier who gives you a finished date is describing a snapshot that starts decaying the day after it is taken.

Will this slow our developers down?

Some of it will, honestly. Requiring reviewed changes and blocking a deployment on a critical vulnerability adds friction by design. We automate everything we can, so checks run in seconds instead of requiring a meeting, and we are explicit about the controls that genuinely cost time so you can decide whether the risk justifies them. What we will not do is quietly add friction and call it best practice.

What if we're breached anyway?

It remains possible. No control set reduces the risk to zero, and a supplier promising otherwise is not being straight with you. What good preparation changes is the outcome: you detect it in hours rather than months, the audit trail tells you exactly what was reached, least privilege limits how far it spread, and immutable backups make recovery a procedure rather than a negotiation. Writing and rehearsing that incident plan is part of the work, not an add-on.

Do you run the penetration test yourselves?

No. We coordinate it with independent specialists, help you scope it sensibly, triage the report, fix what matters and arrange the retest. Testing our own work would not be independent, and a customer's security team will notice that immediately.

Our data isn't allowed to leave the country. Is that a problem?

No, but it constrains the design, and it is far cheaper to know on day one than in month six. All three major clouds offer specific regions, and services can be restricted by policy so nothing can be created outside them. The trade-off is that not every managed service exists in every region and some cost more there. We will show you which of your requirements carry a price before you commit to an architecture.

Want to know what an attacker would find?

A read-only review of your cloud setup, benchmarked against published standards, with findings ranked by what's genuinely exploitable. No obligation, and no scare stories.

Start the conversation →

Explore more

The rest of Cloud & Infrastructure

Migration Cost optimisation Reliability ← All of Cloud