On this page
What a scanner report looks like
Open a typical report from a tool-driven test and read the findings table. It looks like this:
- Content-Security-Policy header missing
- Medium. "Implement a CSP to mitigate XSS." No indication that any XSS exists.
- Strict-Transport-Security header missing
- Medium. "Add the HSTS header." Copied from the tool library.
- Server header discloses version
- Low. "Remove or obfuscate the Server header."
- X-Frame-Options header missing (clickjacking)
- Medium. "Add X-Frame-Options or frame-ancestors."
- Cookie without Secure or SameSite flag
- Low. Generic text about cookies.
Ask yourself three questions about that table. Which of these findings tells you an attacker could read another customer’s data? Which one describes how your own application behaves rather than how its web server is configured? Which one would still be in the report if the tester had never logged in?
The answer to all three is none. Every row would be identical for a thousand different applications, because the tool never understood this one.
Why this happens so often
After more than five years of reading penetration test reports for banks, SaaS companies and enterprises, the pattern is consistent: a report full of missing-header findings is the norm, not the exception. Run a scanner, export the PDF, add a logo. The headers are real issues and worth fixing, but they are hygiene, not security testing.
A missing header does not give anyone access to anything. It makes some other attack easier or slightly worse once that attack exists. When a report lists ten of these and nothing about authorisation, you have learned nothing about the risks that end up in breach notices.
What a report worth paying for looks like
It proves impact
Each finding shows what was reached: another tenant's invoices, an admin endpoint, a password reset taken over. Screenshots, requests and responses are included so your engineers can reproduce it.
It understands your application
The tester used real roles and two tenants, read your API, and tested the business rules: pricing, approvals, limits, workflows. These flaws exist only in your product.
It chains issues together
A low-severity information leak plus a weak reset flow becomes account takeover. Scanners report them separately; experts connect them.
It tells you what to fix first
Severity reflects real business impact, not a generic score. Remediation is specific to your stack, not a link to a standards page.
The findings only an expert makes
These are the issues that actually cause incidents, and none of them come from a scanner:
- Broken access control and IDOR. Changing an ID in a request returns someone else’s records. Our IDOR case study shows how one unchecked parameter exposed 12,000 customer records.
- Business-logic abuse. Applying a discount twice, skipping a payment step, approving your own request.
- API authorisation gaps. The mobile app hides a button, but the endpoint behind it works for anyone.
- Authentication and session weaknesses. Reset flows, token handling, MFA bypass.
- Chained attacks. Several small issues that only matter together.
A checklist before you pay for a report
- Ask for a redacted sample report and read the findings, not the cover page
- Count how many findings are header or configuration items; if it is most of them, walk away
- Confirm testing used authenticated accounts across every role and tenant
- Check that each finding has evidence and reproduction steps
- Confirm a retest is included, and that the final report shows what is now closed
- Ask who actually performed the testing and what they do beyond running tools
You can compare against our own sample VAPT report.
Get the free part free
We do not think you should pay for what a tool can find. Summit’s free scan at scan.sumrite.com checks for the scanner-level issues: CSP, HSTS, Server header, clickjacking protection and cookie flags. Run it, fix what it finds, and bring us the part that needs a person.
That is the whole model: a free tool for scanner-level issues, and paid expert work for everything a scanner cannot see. It also makes for a better report. When the hygiene items are already closed, the report you buy is about real risk.
Will auditors and customers accept it?
Reviewers for SOC 2, ISO 27001 and enterprise security questionnaires want evidence of an independent test with verified findings and a retest. A tool export, however nicely formatted, answers a different question. For the difference between a scan and a test see VAPT vs vulnerability scan.
Want a report you can show with confidence?
Tell us what you need tested and why. We will send a fixed scope, an NDA before any technical detail, and a quote in about 15 minutes. Get a quote or run the free scan first.
Frequently asked questions
What is the difference between a scanner report and a VAPT report?
A scanner report is an automated list of possible issues, usually header and configuration findings, with generic advice. A VAPT report is written by an expert who has confirmed each finding is exploitable, shown the impact with evidence and given fixes specific to your system.
Why do so many penetration test reports contain missing-header findings?
Because they are what automated scanners find first and fastest. Missing CSP, HSTS, Server header disclosure and anti-clickjacking headers are real but low-impact hygiene issues. A report made mostly of them usually means the testing stopped at the scanner.
Can I get the scanner-level findings for free?
Yes. Summit's free scan at scan.sumrite.com finds the scanner-level issues such as CSP, HSTS, Server header and clickjacking. You pay for the expert work that finds what a scanner cannot, such as broken access control and business-logic flaws.
What should a good VAPT report contain?
A scope and methodology section, an executive summary, each finding with severity, evidence and reproduction steps, specific remediation advice, and a retest section showing which findings are now closed.
Will auditors and enterprise customers accept a scanner export?
Many reviewers reject it. SOC 2 and ISO 27001 auditors and procurement teams usually want evidence of an independent penetration test with verified findings and a retest, not an unreviewed tool export.
Faisal Khan is a Director at Summit, where he oversees penetration testing, risk assessment and compliance engagements for SaaS and enterprise clients. Case studies are anonymised and published with client permission.
