Penetration Testing for Audit Readiness: How to Build Evidence That Holds Up to Scrutiny

Consider a hypothetical situation. A company sells a B2B platform with a customer portal and a public API. A large customer is preparing its own supplier audit and asks the company to show how the controls declared in its security questionnaire have been tested: access separation between tenants, sign-in through single sign-on (SSO), and logging of administrative actions. The company has a penetration test report, but it is more than a year old. It describes the portal as it was before the move to SSO, and it does not mention the new billing API at all. Two high-severity findings are marked "fixed" in the tracker, but nobody has retested them.

The question here is not whether another pentest is needed. The question is which set of evidence will let an auditor move from each declared control to a specific test, its result and confirmation of the fix. What follows explains how to plan a penetration test so that its results can serve as that evidence, where the limits of that evidence lie, and which decisions need to be made before the work is ordered.

What a pentest can and cannot give an audit

Evidence, not a conclusion

Penetration testing for audit readiness is authorised security testing that is planned and documented so that its results can be used as evidence. It answers a specific question: how does the organisation know that its technical controls work within the agreed scope on the date of the test.

A pentest does not establish compliance, does not replace certification or attestation, and is not an opinion on the effectiveness of controls. Those conclusions are drawn by the auditor or assessor under the rules of their own scheme, and the provider's report is only one input into that work. Wording such as "following the pentest, the system is compliant" should be read as a red flag in a report, not as a strength.

The second limit matters just as much: a pentest does not guarantee the absence of vulnerabilities. It shows what was tested, with which methods, during which period and with what result. Anything that was not tested remains untested, and an honest report says so directly by listing its exclusions and assumptions.

The dual purpose of technical testing

NIST SP 800-115 is NIST's guide to technical information security testing and assessment, published in 2008. It covers planning and conducting tests, analysing findings and developing mitigation strategies. Its abstract notes that technical tests help both to find vulnerabilities in a system or network and to verify compliance with a policy or other requirements. For an audit, the second part is what matters: a test is useful when its results can be compared with requirements stated in advance, not only with a list of issues found.

A report that lists issues without saying what was tested, against which requirements and what happened after the test gives an auditor little to rely on. A report built around a stated methodology and versioned requirements leaves a trail that can be followed and re-checked later.

From declared controls to an agreed scope

The control, system and test map

Preparation should start not with a list of URLs but with a list of the controls the organisation has already declared to an auditor or customer: in policies, security questionnaires and the system description. For each control, decide which systems it applies to, which test can produce evidence about it, and whether that test belongs in the pentest or in another form of assessment. The scope then follows from what must be demonstrated, rather than from the budget or a familiar template.

The first practical step is to confirm with the auditor which systems and controls the evidence must cover and whether a penetration test specifically is expected. Neither NIST nor OWASP says that a particular auditor requires a pentest or accepts a specific report format, so the requirements of your own audit scheme need to be agreed in advance. The table below shows how typical situations turn into scope decisions and what limits the resulting evidence has.

Validating ownership of discovered attack surface

During reconnaissance a provider often finds subdomains, IP addresses or cloud resources that are not on the agreed list. They must not be actively tested until ownership is confirmed: the asset may belong to a third party or a former supplier, or it may sit with a provider whose terms require notice. The right sequence is to record the discovery, pass it to the asset owner, obtain confirmation and get a written decision on whether to bring it into scope. The discovery of unlisted assets is useful to the audit in its own right, because it shows how well the asset register matches reality.

Assume-breach: where the test starts

An assume-breach scenario begins from an agreed state of compromise, for example an ordinary employee account or access to a single server in an internal segment. It shows what can happen next: how far an attacker can progress, and where segmentation, monitoring and privilege separation take effect. However, such a test does not prove that initial access was possible, and it does not assess the external perimeter. The starting point must be described explicitly in the report, otherwise an auditor may read the results more broadly than they deserve.

The role of standards in an audit evidence package

Each reference covers its own part of the problem. Mixing up their roles is a common reason why a report looks solid but does not stand up well to an auditor's questions.

NIST SP 800-115 as the planning frame

The guide provides a structure for the work: planning, conducting tests, analysing findings and mitigation strategies, along with a comparison of technical techniques, their benefits and their limitations. It states plainly that it is not a comprehensive testing programme, so an organisation still needs a programme of its own. Its technique overview predates many current cloud and API architectures. It is therefore sensible to use it as a frame for planning and reporting, and to take specific procedures from maintained OWASP material.

WSTG and ASVS: procedure and yardstick

The OWASP Web Security Testing Guide (WSTG) describes how to carry out web application testing. The OWASP Application Security Verification Standard (ASVS) sets out what is verified: it is a basis for testing the technical security controls of web applications and, at the same time, a list of secure development requirements. One of the stated aims of ASVS is to normalise the range of coverage and rigour of verification available in the market. ASVS requirements are published in machine-readable formats, including CSV and JSON, so they are easy to load into a tracker and to use for recording coverage and findings by identifier. For both documents, the report should name the specific version that was actually used.

OWASP Top 10, CWE Top 25 and KEV: priorities, not procedure

The OWASP Top 10 is an awareness document that reflects a broad consensus about the most critical risks to web applications. It helps explain risk to management, but it is a list of risks, not a test procedure. A claim that a test "covers the OWASP Top 10" is therefore weaker evidence than a test mapped to ASVS requirements and carried out with WSTG.

The MITRE CWE Top 25 identifies each year the most severe and prevalent weaknesses, which are often easy to find and exploit. The related CWE Top 10 KEV Weaknesses list ranks actively exploited weaknesses using CISA's Known Exploited Vulnerabilities catalogue. MITRE itself lists exploitability insight and risk prioritisation among the uses of the Top 25. If a report shows that testing focused on weakness classes seen in active exploitation, an auditor sees scope chosen by risk rather than at random. CISA's Secure by Design alerts on cross-site scripting, OS command injection, directory traversal and buffer overflows point to the same classes.

CSF 2.0: the link to target outcomes

The NIST Cybersecurity Framework 2.0 operates at the level of risk governance. Its profiles, quick-start guides and informative references make it possible to link test results to target outcomes the organisation has already defined. The pentest then stops being an isolated document and becomes evidence against specific objectives. How standards turn into decisions across the whole application review is covered in the article on standards-based application security audits.

How to make findings traceable

What every finding must contain

Traceability means an auditor can move from a declared control to a test, from the test to a finding and from the finding to its closure. To make that possible, every finding should contain:

• a reproducible description with the date, conditions and the role used;
• the affected asset and its version or environment;
• a mapping to a CWE identifier;
• a reference to a versioned ASVS requirement or another requirement that was violated;
• a severity rationale;
• a link to the control declared to the auditor, where such a control exists.

It is also worth recording which WSTG version the test cases came from and which weakness classes were deliberately excluded from scope and why. An exclusion without an explanation looks like a gap; an exclusion with a rationale looks like a deliberate decision. Findings in classes that appear on the CWE Top 10 KEV list are worth flagging for priority remediation.

HTTP configuration or confirmed exploitation

Many web system controls are observable at the HTTP layer. MDN describes HTTP as a stateless protocol: cookies add state to some interactions, and HTTP authentication verifies a client's identity. Session handling and authentication are therefore natural test targets. Among the mechanisms delivered through response headers, MDN names Content Security Policy, CORS, CORP and Permissions Policy, and it points to its HTTP Observatory tool for checking configuration.

Header settings are convenient as evidence: they are easy to observe and cheap to re-check after a fix. But the presence of a header does not prove that a control works. A test should check whether the policy actually constrains behaviour, and the report should separate configuration checks from findings confirmed by exploitation.

Versions in requirement references

ASVS recommends including the version in requirement identifiers: an unversioned identifier is taken to refer to the latest content, and numbering can change between versions. The same logic applies to WSTG, to the different editions of the OWASP Top 10 and to the annually updated CWE Top 25. A statement such as "tested against ASVS" without a version may become ambiguous by the time an auditor reads the report. Cite the version you actually worked with, not the newest one available on the day the report is read.

Remediation, risk acceptance and retesting

NIST SP 800-115 treats testing as a cycle that does not end with the report: analysing findings and developing mitigation strategies are full stages in their own right. An evidence package is stronger when it shows three things: issues were found; they were assigned owners and either fixed or formally risk-accepted; and the fixes were verified. MITRE notes that insight into common root causes helps eliminate entire classes of defect, and ASVS doubles as a list of secure development requirements. A requirement identifier therefore connects a finding to what developers need to meet, and the same issue is less likely to return before the next audit.

1. FindingReproducible description, affected asset, CWE identifier and a requirement reference that includes the version
2. Owner and decisionAn owner is assigned and either a fix or a formal risk acceptance with a review date is chosen
3. FixThe change is made and linked to the finding number in the tracker and to the system version
4. RetestThe same scenario is repeated on the fixed version and the result is recorded with a date
5. Evidence packageThe finding, the decision and the retest result are brought together into one trail for the auditor

What counts as closure

A "fixed" status in the tracker is a statement by the team, not evidence. Closure is confirmed by retesting the same scenario on the fixed version, with a date and a result. If the retest shows the fix is partial, the finding stays open with an updated description. If the organisation decides not to fix an issue, a risk-acceptance decision is needed with an owner, a rationale and a review date. More on proving that fixes actually work is in the article on penetration test remediation validation, and on running the cycle from finding to confirmation in the piece on vulnerability remediation control.

Timing relative to audit fieldwork

The test should take place early enough to leave time for remediation and a retest before audit fieldwork begins. None of the references reviewed gives a standard lead time. The right window depends on the expected number of findings and on how the change process works, so it is better to rely on your own remediation history than on a generic rule. If time is already short, it is more honest to show the auditor a remediation plan with owners than to close findings without a retest.

The age and limits of historical evidence

What goes stale in an old report

A pentest reflects the state of a system on the date of testing. A report that is a year old still proves something: that testing took place during that period, which issues were found and how they were handled. But it says nothing about components added later, functions that have changed or configuration that has been edited since. In the hypothetical example at the start of this article, the old report is useful as a history of the finding and remediation cycle, but not as evidence that SSO and the new API work as declared.

When using historical results, it is therefore worth stating explicitly the test date, the version or build of the systems, the scope and what has changed since. How much weight to give old evidence is the auditor's decision, but that decision is easier when the limits are stated plainly.

Changes that call for a new test

CISA's Safe Software Deployment guidance stresses robust testing and measurement within the deployment process. Organisations that release often have to explain how assurance is maintained between tests. That does not mean every commit needs a paid pentest. A new manual test is justified by specific security-relevant changes: a new authentication or authorisation scheme, a new external interface or API, a change to the multi-tenancy model, a move to a different environment, or a new integration with access to sensitive data. Other changes are covered by automated checks in the pipeline and by configuration control. How to map changes to test scope is covered in detail in the article on change-triggered penetration testing.

Choosing techniques and the test environment

NIST SP 800-115 distinguishes penetration testing, vulnerability scanning, security assessment and risk assessment, and emphasises the benefits and limitations of each technique. For an audit, this is a reminder that no single technique covers every need, and the choice and its rationale should be recorded in the report. That record in itself shows the testing was deliberately planned.

Scanning, manual pentesting and configuration review

Automated scanning covers many assets and is easy to repeat. Manual penetration testing explores business logic, chained issues and authorisation flaws that a scanner usually does not see. Configuration review provides cheap and repeatable evidence for observable settings. The evidence is stronger when the report says which approach was used for which asset. Coverage of the OWASP Top 10 is easy to explain, while mapping to ASVS is more precise, though it takes more effort.

Production or staging

Testing production is more realistic but carries more operational risk. Staging is safer, but the organisation then needs to show that it matches production in code version, configuration and integrations. If testing was done in staging, this should be written into the scope statement, and known differences from production should be listed.

Keeping the work itself under control

Authorisation and rules of engagement

Any testing must be explicitly authorised in writing by those who have authority over the systems in scope. That includes hosting and SaaS providers whose terms require notice or approval. The rules of engagement record dates, targets, exclusions and contacts. This article explains how to organise authorised work and does not grant or imply authorisation for any testing.

Stop conditions and data handling

Excluded techniques (for example, anything that could degrade availability), rules for handling sensitive data encountered, an escalation channel for critical findings discovered mid-test and clear stop conditions are all agreed in advance. These arrangements are audit evidence too: they show that testing was controlled and that the risk to live systems was managed.

Buyer decisions before ordering a test

When you buy a pentest for an audit, you are buying evidence quality, not tester hours. Since ASVS was created partly to normalise the range of coverage and rigour of verification, offerings in the market are bound to differ. Structure your request for proposals so that responses can be compared against the same requirements.

Questions for the provider

• Which methodologies and versions will you follow, and how will test cases be recorded?
• Will findings be mapped to CWE identifiers and to versioned ASVS requirements?
• Can you show a redacted sample report with methodology, scope and retest sections?
• Is a retest included, and how is closure of findings evidenced?
• How are authorisation, rules of engagement and stop conditions documented?
• How is sensitive data encountered during testing handled?
• Who will perform the testing, and what relevant experience can you evidence?

How to compare answers from several providers against the same criteria is covered in the evidence-led framework for choosing a provider.

Red flags in a report

Some signs reduce a report's value for an audit, even though on their own they do not prove the testing was poor: a reference only to the "OWASP Top 10" with no version and no requirement mapping; no retest; a scope given as a single list of URLs with no roles or accounts; a vague methodology section; promises of "compliance" or "no vulnerabilities"; and an assume-breach scenario with no described starting point. Do not accept a provider's claims about certifications, customers or results without verification: ask for evidence and check it independently.

Five questions before committing budget

• What must be demonstrated? Confirm with the auditor which systems and controls the evidence must cover and whether a pentest or another form of assessment is expected.
• What is in scope? List the applications, APIs, environments and user roles, and set priorities with the CWE Top 25 and the KEV list in mind.
• Which yardstick? Versioned ASVS requirements for verification, WSTG for the procedure and NIST SP 800-115 for the planning and reporting structure.
• Which mix of techniques? Choose scanning, manual testing or configuration review for each asset and record the reasons.
• How will closure be shown? Assign owners, set up risk acceptance and schedule a retest before audit fieldwork.

If the first question cannot be answered, pause procurement: a test ordered before it is clear which evidence is needed risks failing to answer the auditor's question. It helps to gather the list of systems, roles, constraints and expected evidence in advance, for example in the pentest scope preparation form, which can be the starting point for discussing the work with Pentest.red.

A repeatable process instead of a one-off report

The value of a pentest for an audit lies in a documented, repeatable process rather than a one-off report. Planning with NIST SP 800-115, a procedure based on WSTG, verification against versioned ASVS requirements, priorities informed by the CWE Top 25 and the KEV list, an explicit scope and its limits, traceable findings, retesting and an honest statement of how old the evidence is: together these form a trail an auditor can follow.

An organisation preparing for its first audit can start with a tightly scoped test of its highest-risk systems, with ASVS mapping and a retest. A more mature organisation can build testing into a CSF 2.0 profile, link it to security-relevant changes and track how weakness classes shift from one test to the next. In both cases the pentest remains a source of evidence for the audit, and conclusions about compliance are drawn by whoever conducts the audit.