Our approach
Clear scope. Careful work. Plain answers.
Here's exactly how an engagement works, from first conversation to final walk-through — so you know what to expect at every step.
Stages of an engagement
-
1. An initial conversation
You tell us what you've built, who uses it, what worries you and what you're hoping to achieve. We'll ask about the technology, hosting and how the application was developed — but you don't need to know the answers to everything.
There's no charge and no obligation for this first conversation. Please don't send source code, credentials or confidential data at this stage.
-
2. A written scope
We recommend what's worth examining and why, and write it down: which parts of the application, which environments, what access we'll need, what's excluded, the timeline and the cost.
For anything involving testing, the scope also records your written authorization and any rules — for example, testing only against a staging copy, or only outside business hours.
-
3. Secure access
We agree how access is granted — typically read-only repository access, a staging environment and dedicated test accounts. We avoid production credentials wherever possible, use the minimum access needed, and ask you to revoke it when we're finished.
-
4. The review
We combine reading code and configuration, examining architecture and hosting, and carefully testing how the application behaves — within the agreed scope. Tools support the work; experienced judgement drives it.
If we find something serious during the review, we won't wait for the final report to tell you.
-
5. The report
You receive a documented assessment: an executive summary, the scope, what was and wasn't examined, prioritized findings with evidence, and practical recommendations.
-
6. Walk-through and next steps
We go through the findings together, in plain language, and answer questions. Then you decide what happens next: fix things yourself, hand the report to your developer or AI tools, ask us to help, or schedule a follow-up check.
Principles we work by
- Independent
- Our opinion isn't shaped by who built the application or by follow-on work. Remediation is always scoped separately.
- Evidence-based
- Every finding explains how it was identified, so it can be verified, reproduced and fixed.
- Proportionate
- We prioritize by real business risk. A small internal tool doesn't need the same treatment as a payment platform.
- Plain-spoken
- Clear language for decision-makers, specific detail for developers. No alarmism, no jargon for its own sake.
- Authorized
- We only examine systems you own or have authority over, within a written scope. No exceptions.
- Confidential
- What you share is used only for your engagement. We're happy to sign a reasonable NDA first.
How we prioritize findings
Each finding gets a priority based on likely business impact and how easily the issue could be exploited or triggered — not on how technically interesting it is.
- High
- Could directly expose data, money or control of the system, or seriously disrupt the business. Address before relying on the application further.
- Medium
- A real weakness or limitation that increases risk or cost. Plan to address it soon.
- Low
- A quality, usability or hardening improvement. Address as part of normal maintenance.
Being honest about limits
No review can find every problem. What we can do is examine the most important areas carefully, tell you precisely what we did and didn't look at, and explain our reasoning. That transparency is part of the deliverable — it lets you judge the result properly and decide whether anything else is needed.
Our reviews are professional opinions. They are not certifications, compliance audits, or guarantees that an application is secure.
Start with a conversation
Tell us about your application. We'll recommend a sensible scope — or tell you honestly if you don't need us.