How we work
Why does it matter which standard we work to?
Because in security, “we looked at it, it's fine” is worth nothing. Without a framework behind it you cannot tell what was checked and what was not — and six months later, after an incident, you cannot reconstruct it either.
A standard gives you three things:
- Completeness. What comes up does not depend on the tester's day. The list is fixed.
- Repeatability. The same assessment six months later gives a comparable result, so you can see whether anything improved.
- A shared language. When your insurer, your partner or an enterprise vendor questionnaire asks, the answer is referenceable.
Which frameworks do we measure against?
| Area | Framework | What it gives |
|---|---|---|
| Web application | OWASP ASVS (Application Security Verification Standard) | Verification levels from authentication to logging |
| Web attack classes | OWASP Top 10 | Coverage of the ten most common flaw classes |
| APIs | OWASP API Security Top 10 | Authorisation and data exposure flaws on the API side |
| Server, operating system | CIS Benchmarks | A hardening baseline with an itemised checklist |
| The testing process | NIST SP 800-115 | Planning, discovery, attack, reporting |
| Severity rating | CVSS v3.1 | A numeric, comparable risk score |
| Vulnerability identity | CVE / CWE | An international identifier for every finding that has one |
| Incident handling | NIST SP 800-61 | Preparation, detection, containment, recovery |
These are public documents. Anyone can look them up, and anyone can check whether our report really covers what we say it covers.
The process, step by step
1. Discovery and scope
We put in writing what is in scope: domains, IP ranges, applications, the time window, and what is explicitly excluded. This is not paperwork — it protects you as much as it protects us.
2. Passive assessment
First, what is visible from the outside: DNS records, certificates, open ports, running versions, security headers, e-mail authentication, data exposed in public sources. This phase puts no load on the system, and it typically surfaces half of the findings already.
3. Active testing
Targeted testing within scope: authentication and session handling, authorisation, input points, file handling, API endpoints, business logic. Anything that may create load runs in an agreed window.
4. Proof
We reproduce every finding before we write it down. What cannot be demonstrated does not go into the report as a finding — at most as a note. This matters because a large share of automated scanner output is false positives, and paying to fix those is money thrown away.
5. Report
What you get:
- Executive summary — where you stand, what the biggest risk is, how much work the clean-up is. One page, no jargon.
- Findings by severity — each with what we found, how to reproduce it, what the consequence is, how to fix it, and a CVSS score.
- A fix order — today's job, this week's, this quarter's, marked by effort.
- Measurement data — what we looked at, when, with which tool. Without it the report cannot be verified.
6. Retest
After the fixes we measure again and confirm in writing that the flaw is actually gone. At many providers this is a separate line item — for us it is part of the audit.
What we do not do
- We do not send raw scanner output as a report. A 400-page machine list is not work, it is the avoidance of work.
- We do not test without permission. Not third-party systems, and nothing outside the agreed scope.
- We do not hold findings back for commercial reasons. What we find, we write down — even if you have someone else fix it.
- We do not promise 100% security. Anyone who does either does not understand it, or is not telling the truth.
What happens to the vulnerabilities we find?
The report is sent encrypted and shared only with the people you name. Findings are not passed to third parties, not referenced publicly, and on request every working copy is deleted once the fixes are confirmed. If we find a vulnerability that is not in your system but in a component you use, we report it to the vendor under responsible disclosure — without naming you.
Frequently asked questions
Do we need a contract before testing?
Yes, and it is in your interest. Testing without permission is a criminal offence in most countries; a written agreement fixing the scope and the time window protects both parties. The free initial assessment is separate: we run it from the outside, without load, on data that is public anyway.
How deep is a free assessment?
An external, passive picture: reachable services, versions, certificates, security headers, e-mail authentication, known risks. It is enough to show whether something is obviously wrong — it does not replace a full assessment, and we do not claim it does.
Who sees the report?
By default only you and the contact you name. If the report goes to a partner or an insurer, tell us in advance and we will format it accordingly.
What if it turns out during testing that you have already been breached?
Then testing stops and we switch to incident handling under NIST SP 800-61: containment, evidence preservation, then recovery. The first hour matters most — there is a separate write-up on that in the knowledge base.
What is the difference between what you do and what my scanner gives me?
An automated scanner looks for known patterns and cannot judge business logic. A scanner will never tell you that customer B can read customer A's invoice by editing an ID — that requires understanding what the application does. We use scanners too, but as a starting point, not as a result.