Enterprise security questionnaires rarely ask whether you ran a scanner. They ask whether critical paths were tested, what broke, how you proved it, and what happened after the fix. A CVSS score without a reproduction path answers a different question than a working exploit inside a written approved scope.
If you lead security at a funded UK SaaS (CISO, Head of Security, or CTO carrying the function), that distinction is what unblocks diligence when engineering has shipped hard since the last annual PDF.
What a scanner finding actually is
A scanner finding is a hypothesis generated from signatures, fingerprinting, configuration checks, and sometimes light probing. Good scanners are useful. They surface missing headers, known CVE matches, weak TLS, open storage buckets, and stale dependencies at scale.
They do not, by themselves, prove that an attacker can cross an authorisation boundary, escalate a role, exfiltrate a tenant's data, or chain a misconfiguration into impact. That gap shows up in three places buyers care about:
- False confidence from volume. Hundreds of medium findings look like coverage. Many are unreachable, duplicate, or already mitigated by an upstream control the scanner cannot see.
- Severity without a path. A CVSS vector describes a theoretical rating. It does not show the request chain, the session state required, or the data you can actually reach.
- No closed loop. Re-scanning after a ticket closes often confirms the signature disappeared. It does not always confirm the exploit path is gone.
OWASP's testing guidance still centres on verifying behaviour against an application under test, not on collecting tool output alone. See the OWASP Web Security Testing Guide and OWASP ASVS for how verification language is written in practice.
What a working exploit means as evidence
A working exploit, in the sense diligence packs need, is a controlled demonstration that a weakness is reachable and produces impact inside agreed limits. It is not a public PoC dump against production. It is a documented path with preconditions, steps, and observed result.
A defensible exploit-backed finding usually includes:
| Element | Why a buyer cares |
|---|---|
| Preconditions | Auth role, feature flag, tenant, or network position required |
| Reproduction steps | Enough for engineering to follow without theatre |
| Observed impact | What was read, changed, or escalated (bounded, non-destructive) |
| Scope boundary | Explicit confirmation the path stayed inside written approved scope |
| Remediation hint | Concrete change, not "harden input validation" |
| Retest status | Open, fixed pending retest, or closed after retest |
That package answers the questionnaire line items that scanners leave fuzzy: "Was authorisation tested?" "Can you show evidence?" "How do you verify fixes?"
Rendering diagram
Scanner coverage vs adversarial proof
| Dimension | Scanner coverage | Exploit-backed adversarial proof |
|---|---|---|
| Primary output | Finding lists, CVSS, ticket queues | Proven paths with impact inside scope |
| Strength | Breadth, speed, regression on known classes | Depth on auth, IDOR, logic, cloud trust edges |
| Weakness | False positives, blind spots on business logic | Narrower surface unless scope and cadence are deliberate |
| Buyer question answered | "Do you scan continuously?" | "Can you show current proof that critical paths hold?" |
| After a fix | Re-scan for signature absence | Retest of the same exploit path |
| Fit | Hygiene and backlog triage | Diligence, renewals, and contested questionnaire answers |
Neither replaces the other. Continuous scanning without adversarial proof is activity. Annual adversarial testing without a retest loop goes stale the week after the next release. The combination that questionnaires reward is current, scoped, exploit-backed evidence with a path to closure.
Written approved scope is the control plane
Scope is not paperwork for the vendor. It is the safety and evidence boundary for you.
Before work starts, lock:
- In scope: named hosts, apps, APIs, cloud accounts, and roles under test
- Out of scope: production destructive actions, third-party SaaS you do not control, social engineering if excluded, physical access if excluded
- Data rules: which tenants or synthetic accounts may be touched
- Windows and rate limits: when testing may run, and what load is allowed
- Communication: how findings are raised mid-engagement
A finding outside that boundary is not evidence you can hand a buyer. A finding inside it, with a working exploit, is.
For funded SaaS, year-one questionnaires usually focus on the external product surface: web app, customer-facing APIs, auth and session handling, and the cloud configuration that holds the user database. Expand scope only when the buyer pack or your threat model demands it.
Surfaces that show up in questionnaire packs
Map evidence to the questions you actually get asked:
Web application. Login, session fixation and logout, privilege boundaries between roles, multi-tenant isolation, admin tooling, file upload and export flows. Scanners catch many injection classes. They routinely miss broken access control that depends on state.
APIs. Object-level authorisation (IDOR), function-level authorisation, mass assignment, pagination leaks, webhook trust. OWASP API Security Top 10 is a better checklist here than a generic web scan profile.
Cloud. Identity policies, public storage, overly broad roles, CI secrets exposure, management-plane paths that lead to the data store. A bucket marked public is a scanner win. A role chain that can read production objects from a developer identity needs adversarial proof.
Internal networks, Active Directory, mobile, and AI systems belong in scope when your product or buyer requires them. Do not invent coverage you have not authorised.
The retest loop is what makes proof continuous
A closed finding without retest is a claim. A retested finding is evidence.
Practical loop for a lean security team:
- Prioritise by exploitability and data impact, not by raw CVSS alone.
- Assign a named owner and a fix window tied to the questionnaire deadline when one exists.
- Keep the original reproduction steps frozen so retest compares like with like.
- Retest the same path after the fix. Prefer a free retest commitment so closure is not a budget fight.
- File the closed artefact (scope excerpt, finding, exploit summary, retest result, date) into the diligence folder.
That is continuous proof in operational terms: repeatable scoped work aligned to product change, not a slogan.
UK context from the Cyber Security Breaches Survey 2025/2026: 43% of UK businesses identified a cyber breach or attack in the previous 12 months. Only 13% reported carrying out penetration testing. 48% use an external cyber security provider (64% of small businesses with 10 to 49 staff; 70% of medium with 50 to 249). Outsourcing testing is normal. Owning the evidence narrative still sits with you.
What to put in the questionnaire evidence pack
When a buyer asks for "latest penetration test" or "vulnerability management evidence," attach a thin, current pack rather than a raw scanner export:
- Written approved scope (or a redacted excerpt)
- Date of the most recent adversarial cycle on the in-scope product surface
- Summary of critical and high findings with exploit-backed proof where issues were found
- Remediation status and retest results for anything that was open at the last cycle
- Explicit note of what was out of scope, so you do not overclaim
If the pack is nine months old and you have shipped major auth or API changes since, say so and schedule a fresh cycle. Stale honesty beats a confident PDF that no longer matches the product.
How BreachLine helps
BreachLine's Nebula is a fully autonomous AI security engineer · built for the AGI era. You hire it. You do not log in to it. Brief by email or Zoom / Google Meet / Microsoft Teams.
Every engagement starts from a written approved scope. Findings are proven with a working exploit inside that scope. After you fix something in scope, retest is free. Always On / Its Own Desk: reports write themselves, Nebula raises the next move, and specialist agents work in parallel across the surfaces you authorise (web, API, cloud, and more when scope says so).
BreachLine holds Cyber Essentials. ISO 27001 and SOC 2 are in progress (not certified). CREST is not held.
Takeaways
- Scanner coverage and exploit-backed proof answer different questionnaire questions. Treat them as complementary.
- A working exploit inside written approved scope is evidence. A CVSS row without a path is a lead.
- Scope is the control plane: if it is not written and approved, it is not defensible.
- For funded UK SaaS, prioritise web, API, and cloud paths that touch auth and the user database.
- Continuous proof is a retest loop aligned to shipping, not a once-a-year attachment.
- Build a thin diligence pack: scope, dates, proven findings, remediations, retest status.
Sources
- OWASP Web Security Testing Guide
- OWASP Application Security Verification Standard (ASVS)
- OWASP API Security Top 10
- Department for Science, Innovation and Technology and Home Office, Cyber Security Breaches Survey 2025/2026, GOV.UK. Figures cited: 43% breach or attack prevalence; 13% penetration testing; 48% / 64% / 70% external provider rates. https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026
