Security that holds up when tested.

Illustrative diagram: a request from the internet with a valid session crosses the edge and reaches another customer’s records through an API that does not check object ownership. An object-level authorization control is then added, and the same request is refused there with a 403 response.

  1. 01 Attack

    A valid session reaches another customer’s records.

  2. 02 Defend

    An object-level authorization check is added.

  3. 03 Secure

    The same request now stops at the control.

Find the weaknesses attackers can actually reach.

We test applications, APIs and cloud environments to show what an attacker could access, why it matters, and what your team can do about it.

Scope and written authorisation agreed before testing begins.

Most of the attack surface sits behind the controls meant to protect it.

A firewall or WAF inspects traffic on its way in. It cannot tell whether the application behind it checks that the account you asked for is an account you own.

Authentication flows, object-level authorization, business logic, third-party integrations, cloud identity and the application code itself each introduce weaknesses that a perimeter control is not positioned to see. Those are the weaknesses worth finding, because they are the ones an attacker can still reach.

Our work is deciding which of them are genuinely reachable, what they lead to when chained, and what it takes to close them.

Engagements organised the way you buy security.

Five service areas, each scoped as a defined engagement. Pick what you need, and we’ll scope the work around it.

01

Offensive Security

Controlled testing that shows where an attacker could gain access and what they could reach.

For teams launching, changing, or exposing new applications, APIs, or infrastructure.

  • Web application penetration testing
  • API security testing
  • Infrastructure penetration testing
  • Cloud penetration testing

OutputPrioritised findings, attack paths, technical evidence, and remediation guidance.

02

Defensive Security

Engineering and advisory support that builds the detection, logging and response capability your team runs.

For organisations improving how they detect, respond to, and recover from security events.

  • Security monitoring architecture
  • Detection engineering
  • Incident readiness
  • Infrastructure hardening
  • Vulnerability management

OutputPractical detection logic, monitoring improvements, hardened infrastructure, and incident readiness.

03

Security Engineering

Application and cloud security built into the way engineering teams design and ship software.

For technology teams expanding their attack surface or shipping software that needs to hold up under scrutiny.

  • Secure software development
  • DevSecOps
  • Security architecture
  • Cloud security engineering

OutputSecure design guidance, engineering-ready fixes, and a stronger security architecture.

04

Governance, Risk & Compliance

Turn security requirements into practical, measurable controls leadership and auditors can rely on.

For organisations building security governance or preparing for regulatory and compliance requirements.

  • Security assessments
  • Risk management
  • Governance, risk & compliance
  • ISO 27001 readiness
  • Security policies & controls

OutputA gap assessment, risk register, control mapping, policies, and a remediation roadmap.

05

Security Awareness

Build a security-conscious workforce that can recognise, resist, and report common threats.

For organisations strengthening the human layer of their security programme.

  • Security awareness training

OutputA more security-aware workforce, tested response habits, and a training programme you can sustain.

Not sure?

Describe the system, not the service.

Tell us what you are building, changing, or worried about

What our output actually looks like.

Three illustrative examples of how we work — documenting a finding, tracing the attack path, and putting it into a clear report. No client work is shown.

Exhibit AFindingExample

Surface
Web application API
Severity
High
Class
Broken object level authorization
Endpoint
/api/accounts/{id}/

IDOR / Broken Object Level Authorization

Attack scenario. An authenticated user changes the numeric account identifier in an API request and retrieves another user's account data without authorisation.

RequestGET /api/accounts/4821/profileResponseHTTP/1.1 200 OK{ "account_id": 4821, "owner": "other-user" }↑ identifier changed by the caller — the server returns the record anyway

Business impact. Any authenticated user could enumerate and access other customers' account data — a reportable data exposure.

Remediation. Enforce server-side object-level authorization for every requested resource.

Exhibit BAttack pathExample

  1. 01External user
  2. 02Public application
  3. 03Authentication weakness
  4. 04API access
  5. 05Privilege escalation
  6. 06Sensitive resource

Weaknesses become meaningful when they combine. We report the sequence, not just the individual issue.

Exhibit CAssessment report Example

Findings04
High01
RetestOpen
ScopeExternal web application
Top findingBroken Object Level Authorization
Affected asset/api/accounts/{id}/
RemediationServer-side object authorization
01Executive summary
02Technical findings
03Attack-path analysis
04Remediation guidance
05Retest / validation

Leadership gets a prioritised view of risk; engineering gets the path to the fix.

Also available on request

Client engagements are confidential, so these are technical demonstrations of how we work rather than case studies.

Request a walkthrough
  • Sample Penetration TestA structured example of how a web application engagement is scoped, tested, and reported.
  • Sample Vulnerability ReportA finding written the way your engineers would actually receive it — evidence, impact, and fix.
  • Attack-Path AnalysisA demonstration of how isolated weaknesses are chained into a realistic attack sequence.
  • Security Architecture AssessmentAn example of how we assess trust boundaries, identity, and data flow in a system design.
  • Secure Coding ExampleA before/after example of a vulnerable code pattern and its secure implementation.
  • Detection Engineering ExampleAn example detection rule mapped to a specific attack technique and its intended trigger.

A clear process, from first conversation to retest.

Nothing is tested until the scope and rules of engagement are agreed in writing, and the work stays inside them. Select a step to see what happens in it and what it produces.

  1. We learn your environment, objectives and constraints, and propose a scope that fits them.

    Consultation & scoping

    • Understand the systems, users and data involved
    • Agree objectives and the questions the work should answer
    • Identify constraints: environments, timing, sensitivities

    OutputA proposed scope and approach

  2. Scope, rules of engagement and testing windows are agreed in writing before any testing starts.

    Written authorisation

    • Confirm the systems in scope and those explicitly out of it
    • Agree rules of engagement and testing windows
    • Name points of contact on both sides

    OutputWritten authorisation and agreed rules of engagement

  3. We test the agreed attack surface with a structured methodology and record evidence as we go.

    Assessment & evidence

    • Test only the agreed attack surface
    • Work through authentication, authorisation, business logic and input handling
    • Record reproducible evidence for every candidate finding

    OutputEvidence for each candidate finding

  4. Each finding is confirmed, then ranked by how exploitable it is and what it would affect.

    Validation & prioritisation

    • Confirm each finding is real and reachable
    • Determine practical exploitability and what it would expose
    • Rank by risk, not by the order findings were found

    OutputA validated, prioritised list of findings

  5. You receive an executive summary, technical findings and remediation guidance your engineers can act on.

    Reporting & remediation

    • Executive summary for leadership
    • Technical findings with evidence and severity
    • Remediation guidance written for the engineers who will fix it

    OutputThe assessment report

  6. Where the engagement includes it, we verify that identified issues have been addressed.

    Retest & closure

    • Re-test previously identified findings
    • Confirm which are resolved and which remain open
    • Retesting verifies fixes; it is not a new assessment

    OutputUpdated finding status

Technical writing from the work.

All research

Ready to see what holds up?

No surprises between scoping and the final report. Describe the system, the requirement, or the uncertainty you want examined — we'll review the context and come back with the scope we think fits.

  1. 01

    You describe the system, the requirement, or the uncertainty.

  2. 02

    We review the context and come back with the scope we think fits.

  3. 03

    If that turns out to be nothing at all, we tell you that instead.