Secure / Cyber Security
Security for systems that move money.
Escrow flows, payment integrations, multi-tenant isolation and identity — tested by people who have had to build them, for teams that cannot treat a breach as a learning experience.
Start a projectNobody has actually attacked it
The application has never been tested by someone trying to get in, so the first real attempt will also be the first test.
One tenant can reach another
Isolation enforced in application code rather than at the data layer, so a single missed condition exposes one customer’s orders, balances or payouts to another.
A customer sent the questionnaire
An enterprise deal now depends on answers about your posture that nobody in the building can give.
What we do
- 01Threat modellingBefore you build: who would attack this, how, and what it would cost you. Written down, so the next engineer inherits the reasoning.
- 02Secure architecture reviewBefore you ship: trust boundaries, secrets handling, tenancy isolation and blast radius, reviewed while they are still cheap to change.
- 03Penetration testingApplication, API and infrastructure testing, reported so a developer can act on it rather than forward it.
- 04Payment and escrow flow reviewCapabilityThe paths where money is held, released, refunded or disputed — including what happens when a transfer half-fails.
- 05Multi-tenant isolation testingCapabilityDeliberate attempts to read another tenant’s data, at the API and the database.
- 06Cloud and identity hardeningWhile it runs: least privilege in practice rather than in policy.
- 07Dependency and supply chain reviewWhat you actually ship, including what your dependencies ship.
- 08Incident responseWhen something happens: containment, evidence preservation, and an honest account of what occurred and what changed because of it.
How we work
- 01
Scope
1 week
What is in scope, what is off limits, and the rules of engagement in writing.
- 02
Test
1–3 weeks
Hands-on testing against the agreed surface.
- 03
Report
1 week
Findings ranked by exploitability, each with a reproduction and a fix.
- 04
Retest
On fix
We verify the fix rather than taking your word for it.
Multi-tenant marketplace review
- The challenge
- A marketplace where a tenant-isolation failure would expose one seller’s orders and payouts to another.
- The approach
- Threat model first, then targeted testing of the isolation boundary, authorisation paths and the admin surface — the places where a leak would be worst.
- The result
- Isolation enforced at the data layer rather than in application code, so a missed condition cannot become an incident.
Questions we get asked
Do you issue certifications?
No. We are not an accredited certification body and will not imply otherwise. We do the technical work that makes those audits pass, and we will sit in the conversations with your assessor.
Which frameworks do you work against?
Most often PCI DSS, SOC 2 and GDPR, and Kenya’s Data Protection Act 2019 for clients operating there. We map findings to whichever applies rather than producing a generic report.
Will testing take our site down?
Not without agreement. Destructive testing is scoped explicitly and usually run against staging.
What do we actually receive?
A written report with each finding ranked by exploitability, a reproduction, an explanation of the impact, and a suggested fix — plus a walkthrough with your engineers. Not a scanner export with our logo on it.
Can you help with a security questionnaire?
Yes — and if the honest answer to a question is "not yet", we will help you say that and show the plan. Enterprise buyers are used to gaps; they are less forgiving of being misled.
Do you offer ongoing testing?
Yes. One test is a snapshot; a retainer against a changing codebase is usually the more useful arrangement.
What if we are mid-incident?
Say so in the first line and we will treat it as urgent. Containment and evidence preservation come before any conversation about a longer engagement.