The standards we test against, where the days in an engagement actually go, how a finding gets written, how we rate severity, and what happens to your data when we are finished.
Security firms tend to keep methodology vague, which is convenient, because vagueness makes two very different engagements look identical on a quote. One is eight days of manual testing by someone who has built the kind of system they are attacking. The other is a scanner run, reformatted.
You cannot tell those apart from a proposal, so this page describes ours in enough detail to compare against whoever else is bidding. If a competitor will not put the equivalent in writing, that is worth noticing.
If you cannot tell from the proposal how the days will be spent, you are not buying a test. You are buying a document.
The checklist for web application work: identity, session, authorization, input handling, business logic, and client-side. Used as a floor, not a ceiling.
Object and function level authorization, mass assignment, resource consumption, and inventory problems where an old version of an endpoint is still answering.
Storage, cryptography, authentication, network, platform interaction, and resilience, at the verification level your threat model justifies.
The reference for source code review and for telling a development team what good looks like in terms they can implement against.
Prompt injection, insecure output handling, excessive agency, and data leakage through context. Applied to both agent systems and retrieval pipelines.
The technical guide underpinning network testing: planning, discovery, attack, and reporting, with the documentation discipline that comes with it.
The common language for internal and red team work. Findings map to techniques so your detection team can check coverage against something they already use.
Engagement structure for goal-led red team work: intelligence gathering, threat modelling, exploitation, and post-exploitation boundaries.
Configuration baselines for cloud platforms and operating systems, used as the comparison point for posture review rather than as the whole review.
A standard tells you what was covered, not how hard anyone looked. We cite them because they make scope comparable between vendors, and we go past them because the interesting findings are rarely on a checklist.
Rough shape rather than a rule, and the scope document gives you the real numbers for your engagement. The point is that you can see what you are paying for.
Walking the application as a real user in every role, building the request inventory, and running the automated passes. This is the only day a scanner contributes much.
Session handling, token lifetimes, password and recovery flows, and the horizontal and vertical access control tests that need one account per role to perform at all.
The part a scanner cannot reach: sequence abuse, state manipulation, quantity and price tampering, approval bypass, and whatever your application does that nobody else's does.
Confirming and exploiting what the tooling flagged, plus the parameters it never found because they only appear three steps into a workflow.
Combining the low and medium findings into something that is neither. This day produces the findings clients remember, and it is the first thing cut from a cheap quote.
Reproduction steps verified from scratch against a clean session, evidence assembled, severity argued, and remediation written specifically enough to act on.
CVSS 3.1 is calculated without knowing anything about your business, which is exactly why auditors like it and exactly why it is not sufficient on its own. Every finding carries both the base score and our rating, and where they disagree the finding explains the gap.
A worked example. An insecure direct object reference on an invoice endpoint scores around 6.5, a medium: network vector, low complexity, low privileges required, confidentiality impact only. In an environment where that same endpoint enumerates every customer's billing record, including registration and bank details, we rate it high and show the enumeration in the evidence. Your auditor still gets the 6.5 they expect to see. Your engineering lead gets the number that should decide what gets fixed first.
Requests, responses, screenshots, and the minimum data needed to prove a finding. Where proof would mean copying real personal data, we capture the smallest sample that demonstrates it and say so.
Encrypted at rest, access limited to the named testers on the engagement, and never pasted into a third-party service that we have not named in the scope document.
Destroyed at the end of a retention period you agree before the engagement starts, with written confirmation once it is done. If you want it gone the day the retest closes, say so in the scope.
Nobody outside the engagement team. We will not reuse your findings as a case study, a conference talk, or a sanitised example without asking you first, in writing.
The engagement is not finished when the report arrives. It is finished when the findings are closed or consciously accepted, and there is a document saying which.
A call with the engineers who have to fix it, going through findings in priority order.
Your team can ask about any finding while they work. Clarification is not a change request.
Each finding re-run against the original scope once your fixes are deployed.
What closed, what did not, and what you accepted as business risk, with reasons recorded.
A retest covers the findings in the report against the scope as it was. It is not a second test, and it will not catch a problem introduced by a feature that shipped while you were fixing the first one.
CobaltLoom