CUSTOMER CASES

The work we do, in context.

We handle engagements under confidentiality agreements, so client identities stay private. Here are anonymised accounts of the kind of work we take on — the situations, the findings, and what happened next.

Fintech

Pre-launch API security assessment saved a payment platform from a critical data exposure

INDUSTRY

Fintech

SCOPE

A rapidly scaling fintech company was preparing to launch a new open-banking payment platform. With regulatory scrutiny high and enterprise customers waiting, they needed confidence the API layer was secure before going live. Three-week API security assessment covering REST endpoints, OAuth 2.0 flows, and third-party banking integrations.

DURATION

3 weeks

FINDINGS SUMMARY

A broken object-level authorisation (BOLA) flaw allowed an authenticated user to access transaction data belonging to other customers by manipulating object IDs in API requests. A second issue allowed rate-limit bypass on authentication endpoints, enabling credential stuffing at scale.

OUTCOME

Both vulnerabilities were remediated before launch. The platform passed its subsequent SOC 2 Type I audit, and the enterprise procurement process completed without security objections.

API SecurityBOLAOAuthSOC 2
Healthcare

NIS2 readiness assessment for a regional hospital network

INDUSTRY

Healthcare

SCOPE

A network of three hospitals and twelve clinics faced new obligations under the EU NIS2 Directive. Leadership needed to understand what the directive meant for them specifically, and where they stood. Six-week NIS2 applicability assessment and gap analysis against Article 21 security measures, covering governance, incident reporting, and supply chain risk.

DURATION

6 weeks

FINDINGS SUMMARY

The organisation met many baseline technical controls but had significant gaps in formal incident reporting procedures, supply chain risk oversight, and board-level accountability documentation — all newly required under NIS2.

OUTCOME

A prioritised 6-month remediation roadmap was delivered and approved by the board. Incident reporting procedures were formalised to meet the 72-hour notification requirement, and a third-party risk register was established.

NIS2HealthcareIncident ReportingGovernance
SaaS

SOC 2 readiness and penetration testing for a multi-tenant B2B platform

INDUSTRY

SaaS

SCOPE

A B2B SaaS company expanding into enterprise markets needed a SOC 2 Type II report to satisfy procurement requirements. Several large customers had made it a contractual condition. Combined SOC 2 readiness advisory and full penetration testing engagement over four months — scoping the Trust Services Criteria, building the control environment, and testing the application and infrastructure.

DURATION

4 months

FINDINGS SUMMARY

A tenant isolation weakness in the data access layer meant a bug in the query layer could theoretically expose data across customer tenants. The pen test also identified session management weaknesses in the admin interface.

OUTCOME

The isolation issue was fixed with row-level security policies and tested across tenant boundaries. The company completed its SOC 2 Type II audit with no exceptions, and signed three enterprise contracts that had been contingent on the report.

SOC 2Multi-tenantPenetration TestingTrust Services
Critical Infrastructure

Ransomware tabletop exercise exposed escalation gaps in an energy utility

INDUSTRY

Critical Infrastructure

SCOPE

A Nordic energy utility operating across generation, transmission, and distribution wanted to validate its incident response plan against a ransomware scenario before a real event tested it. Full-day facilitated tabletop exercise with parallel technical and executive tracks, simulating a ransomware outbreak spreading from corporate IT into operational technology (OT) systems.

DURATION

1 day

FINDINGS SUMMARY

The exercise revealed decision-making bottlenecks in the escalation chain — specifically, ambiguity over who had authority to isolate OT systems from the corporate network. Backup restoration procedures had also never been tested at scale, and restoration time estimates were optimistic.

OUTCOME

The escalation chain was clarified and formally documented. Backup restoration was tested in a controlled environment, revealing a 40% gap between estimated and actual recovery time. Quarterly exercises were scheduled, and the incident response playbook was revised.

Tabletop ExerciseRansomwareOT SecurityIncident Response

ABOUT THESE CASES

How these accounts are published.

The questions below explain how customer cases are written and what a prospective buyer can and cannot expect from them.

Are these real engagements?

Yes. Each account describes a real engagement, with the situation, scope, notable findings, and outcome summarised factually. Technical details and client-identifying information are removed or generalised to respect confidentiality agreements.

Why are client names withheld?

Cybersecurity engagements are conducted under non-disclosure agreements, and clients in regulated sectors rarely permit public attribution of security testing. Withholding client names is standard practice in the industry and protects the organisations that engage testing services. What can be shared is the sector, the type of work, and the outcome.

Can I speak to a reference client?

Reference arrangements can be discussed with existing clients on a case-by-case basis once a mutual interest in an engagement is established. We do not maintain a public reference list, and introductions are made only with the client's explicit consent.

Want to understand how we'd approach your specific situation? The best way is a short conversation.

Talk to our team