We find the weak points before someone else does.
We examine your systems the way a real attacker would, always with written permission and within an agreed scope. The result is a report you can read: what we found, what it would mean for your business, and how to fix it. Then we retest to confirm the fix worked.
What a security test is actually for
An automated scanner tells you what isn't updated. It doesn't tell you what you'd lose. It won't chain three small things into an account takeover, won't notice that a support agent can see every customer's invoices, and can't tell which of its four hundred alerts would genuinely ruin your year. That judgement has to be made by a person, and it's where the whole value of a test sits.
The other half of the value is what comes afterwards. Most security reports are unusable for the people who have to act on them: no steps, no proof, a severity assigned by a tool that has never seen your business. The finding gets logged, postponed, and found a year later by someone less friendly.
So we test like an attacker but write like engineers. Every finding comes with the exact steps, proof that it's real, a severity we can defend, and a fix written for the person who'll be doing it. And we go through it with your team in person.
We don't start without written permission
Offensive work is only legitimate when the rules are agreed in advance and in writing. This isn't bureaucracy. It's the exact thing that separates a security test from a crime, which is why we insist on it even when it slows a client down.
- We test only systems you own or demonstrably control
- Scope, methods, timing and limits are agreed in writing before we begin
- Permission must come from someone entitled to give it, named in the document
- If a third party operates the system, we need their authorisation as well
- A contact stays reachable on both sides throughout, with an agreed stop word
- We avoid destructive techniques. We demonstrate impact, we don't cause it
It depends what you're trying to find out
How much you tell us up front changes what the test can prove. We'll pick together, based on your question, and your budget.
No knowledge
You give us nothing but an address. We start from the same position as an outsider with time and motivation.
When you want to know what a stranger on the internet could manage.
With credentials
You give us ordinary login details and basic documentation. We don't burn time finding a way in and spend it on what can be done once inside.
The best value for money. This is what we recommend to most clients.
With the code
We also get the source and the architecture. We find the most per hour, because we're reading rather than guessing.
When you want maximum certainty before a large client or investor arrives.
Red team
We aim at a specific objective and try to stay unnoticed. That also tests whether anyone spots us at all.
When you already have a security team and want to test them too.
How an engagement runs
Predictable, documented and safe for your live systems. No surprises for you, none for your customers.
Agreement and permission
We agree scope, methods, timing and limits. In writing, with a named contact who is allowed to approve it. If you'd like, we start by signing an NDA.
Reconnaissance
We map what you have exposed to the internet, what it runs on, and what can be learned about you for free. Assumptions get replaced by a list.
Testing
Manual work, supported by tools where tools help. We chain findings the way an attacker would, and stop the moment the impact is proven.
Reporting
A summary for management in ordinary language and a technical section for developers. Critical issues are reported the moment we find them. We don't wait for the end.
Walkthrough
We sit down with your team and go through the findings. They can ask 'how exactly?' and get an answer. A report nobody understands changes nothing.
Retest
Once you've fixed things, we come back and verify. You get an updated report, the one you can show a customer or an auditor.
What you get at the end
The report is our real product. This is what's in it.
- 01
Summary for management
Two pages with no jargon: what the real risk is, what it could cost you, and what to fund first. Written so a director who isn't technical can act on it.
- 02
Findings with proof
Each with exact steps to reproduce it, evidence that it really works, and the systems affected. No 'might be possible' dressed up as a breach.
- 03
A severity we can defend
We derive risk from what an attacker would gain in your business specifically, not from a number copied out of a tool.
- 04
A concrete fix
For every finding, instructions written for the developer who'll implement them. Not a reference to a standard.
- 05
A prioritised plan
Findings ordered by risk against effort, so a small team knows what to do on Monday morning.
- 06
Attestation letter
A summary letter with the scope, dates and outcome. Exactly what corporate customers ask for in security questionnaires.
Common questions
What clients ask before approving a test.
Will you break our live system?
That's exactly what the agreed rules are for. We decide in advance what's off limits, we avoid destructive techniques by default, we test disruptive things on a staging environment or at an agreed time, and a contact with a stop word stays reachable throughout. We demonstrate impact, we don't cause it.
What do you need from us before starting?
Written permission from someone entitled to give it, a list of the systems in scope, a technical contact and, if we're testing with credentials, login details and documentation. If a third party operates the system, we'll need their authorisation too. Without that paperwork we don't start.
How often should we test?
Once a year as a baseline, and after any significant change to the system. A test is a snapshot: a product that changes every month outgrows its report quickly. Several clients combine one thorough annual test with shorter reviews around bigger changes.
What if you find nothing?
That's a perfectly legitimate result and we don't invent findings to justify an invoice. You get a report on what was tested and how, and that is exactly the evidence an auditor or corporate customer is asking for. In practice, though, it's rare for a first test to find nothing.
Is our data safe with you?
We sign an NDA before we discuss anything technical. We take only as much data as is needed to prove a finding, keep materials encrypted, delete them on the agreed schedule, and never keep anything as a showpiece for other clients.
You also build software. Isn't that a conflict?
For work we built ourselves, yes, which is why an independent test of our own code is always an option, and why we raise it rather than marking our own homework. In the other direction it helps: because we build production systems daily, we can tell your developers what to change instead of just quoting a standard at them.
Tell us what you're worried about.
A test before launch, an audit a customer is asking for, or an incident happening right now, describe the situation and we'll reply within one business day, under NDA if you prefer.