What Auditors Look for in a Penetration Testing Report

As a specialized Canadian CPA and cybersecurity audit firm, MHM acts as an independent compliance auditor and certification body. Through our work with organizations worldwide, we have seen how important a well-documented penetration tests can be to an organization's cybersecurity program. They can also serve as valuable audit evidence when an organization needs to show that security controls have been tested and that identified vulnerabilities are being addressed. But not every penetration testing report provides the same level of evidence.

If you are using a penetration test to support a SOC 2 examination, ISO/IEC 27001 certification audit, privacy assessment, or another compliance requirement, the report needs to do more than list vulnerabilities. It should clearly establish what was tested, how it was tested, what was found, and what happened afterward. A strong report gives your security team enough information to understand and remediate vulnerabilities while giving an independent reviewer enough evidence to understand the test and its results.

1. Make sure the scope matches your audit scope 

The penetration test should cover the systems and environments relevant to the audit scope. A completed penetration test does not necessarily mean the systems in your audit scope were tested. 

Review the scope carefully. It should identify the relevant applications, APIs, networks, cloud environments, IP addresses, domains, or other assets that were included in testing.

Pay particular attention to:

• Production versus staging or development environments
• External versus internal testing
• Web applications and APIs
• Cloud infrastructure
• Authentication and user roles
• Critical systems or components supporting the services being audited
• Systems that were specifically excluded

For example, if your SOC 2 scope includes a production SaaS application and its public API, but the penetration test only covers a staging environment, there may be a disconnect between the test and the system being examined. 

For more on defining testing boundaries, see How to Scope a Technology-based Penetration Test.

2. Make the testing approach clear

The report should clearly describe how the penetration test was performed and whether the approach was appropriate for the systems being tested.

It should describe the testing methodology, testing dates, testing perspective, and level of access provided to the penetration testers.

For example, the report may identify testing as:

• Black-box: Pentesters have limited or no information about the target before testing.
• Grey-box: Pentesters receive some information or credentials.
• White-box: Pentesters receive extensive information about the environment or application.

The report should also explain whether testing included manual testing, automated scanning, or both. Automated tools can identify potential vulnerabilities, but a penetration test should provide more than a list of scanner results. Where appropriate, manual testing and validation can demonstrate whether a vulnerability is exploitable and its potential impact. For example, a report that simply states:

"A penetration test was performed against the organization's web application."

provides limited information.

A stronger report might state:

"External black-box testing was performed against the production web application and public APIs between June 3–7, 2026. Testing included authentication, authorization, input validation, session management, API endpoints, and manual exploitation of identified vulnerabilities."

The second description gives an auditor a clearer understanding of what was tested, when, where, and how. 

The report should also identify the penetration testing provider and, where relevant, the qualifications or experience of the pentesters involved.

3. Look for vulnerabilities supported by technical evidence 

Significant vulnerabilities should be supported by enough technical evidence to understand what was identified, where it occurred, and how the issue was validated.

A penetration testing report should do more than state that a vulnerability exists. Significant vulnerabilities should give your security team enough information to understand the issue, assess its impact, and determine how it should be addressed. 

For example:

Weak:

High: Authentication Vulnerability
The application contains an authentication vulnerability that could allow unauthorized access.

Stronger:

High: Broken Access Control
An authenticated user with standard privileges was able to access another user's account information by modifying the account identifier in an API request. The report identifies the affected endpoint and includes request and response evidence, reproduction steps, business impact, and recommended remediation.

The stronger vulnerability description identifies:

• The type of vulnerability
• The affected system or component
• The conditions required to exploit it
• What an attacker could actually accomplish
• Evidence demonstrating that the issue was validated
• Information that can support remediation

Depending on the vulnerability, supporting evidence may include screenshots, relevant request and response data, reproduction steps, proof-of-concept information, or other technical evidence.

The goal is not to make the report unnecessarily technical, but to make significant vulnerabilities verifiable and actionable. 

4. Pay attention to severity - but don’t stop at the score 

Vulnerabilities should be evaluated based on their potential risk and impact, rather than relying on a severity score alone.

Penetration testing reports commonly assign severity ratings such as Critical, High, Medium, and Low. Some reports also include a CVSS (Common Vulnerability Scoring System) score.

These ratings are useful for prioritizing remediation, but a score on its own does not tell the full story. Your report should provide enough context to explain why a vulnerability received its rating and what the vulnerability could actually allow an attacker to do.

For example, two vulnerabilities may both be rated High but present very different levels of risk depending on:

• Whether authentication is required
• What level of access an attacker has
• What data or functionality can be accessed
• Whether the vulnerability can be exploited remotely
• Whether user interaction is required
• Whether compensating controls are in place
• How critical the affected system or service is

Weak:

High - CVSS 8.1

Stronger:

High - CVSS 8.1. An unauthenticated remote attacker can exploit the vulnerability to bypass authorization controls and access customer records belonging to other accounts. No user interaction is required.

Make sure significant vulnerabilities provide enough context to understand how severity was determined and support appropriate remediation. 

A CVSS score can be useful, but context matters more than the number alone.

5. Show what happened after the test 

Review, address, and, where appropriate, retest significant vulnerabilities after the penetration test.

A penetration testing report documents what the testing identified. It does not, by itself, demonstrate that your organization responded to those vulnerabilities. This may include evidence that identified vulnerabilities were:

• Reviewed and triaged
• Assigned to appropriate owners
• Tracked through remediation
• Addressed within an appropriate timeframe
• Retested where appropriate

For example:

Weak:

“The vulnerability has been fixed.”

Stronger:

“The vulnerability was remediated on July 12, 2026. The related development ticket documents the code change, and the penetration testing provider retested the affected endpoint on July 15, 2026 and confirmed that the vulnerability was no longer exploitable.”

The stronger example connects the original vulnerability to the organization's response and provides evidence that the remediation was actually completed and, where appropriate, validated.

Supporting records may include remediation tickets, change records, updated configuration or code evidence, management review, and retesting results.

If you are using a penetration test as audit evidence, keep the report together with the records that demonstrate how your organization responded to significant vulnerabilities.

Retesting can help demonstrate that remediation addressed the underlying issue. Not every vulnerability requires a separate retest, but you should evaluate significant vulnerabilities to determine whether retesting is appropriate.

6. Don’t ignore limitations and the final conclusion 

A useful report should clearly identify what the penetration test did and did not cover.

No penetration test can test every system, scenario, or potential attack. A useful report should clearly identify limitations, exclusions, and other constraints that affected the engagement.

These may include:

• Systems or applications excluded from scope
• Testing windows or time limitations
• Restrictions on exploitation techniques
• Third-party systems that could not be tested
• Cloud provider limitations
• Production safety restrictions
• Authentication or access limitations
• Services that were unavailable during testing

These details define what the penetration test can actually demonstrate. 

For example, if a production application was excluded because testing was performed only against a staging environment, the report should make that distinction clear. Similarly, if certain attack techniques were prohibited because they could disrupt production systems, that limitation should be documented.

The final conclusion should accurately reflect the engagement's scope and results. 

A report should not imply that an organization's entire environment is secure simply because no significant vulnerabilities were identified within the systems and testing methods covered by the engagement.

Instead, the conclusion should make clear what was tested, what was identified, and any material limitations that affected the results.

Before you submit your penetration testing report for an audit 

Before providing a penetration testing report as audit evidence, make sure you can answer yes to the following:

• Does the testing scope match the systems and services included in your audit scope?
• Was the appropriate production environment tested?
• Are the testing dates clearly identified?
• Does the report explain the testing methodology and approach?
• Does it distinguish manual testing from automated scanning?
• Does the report identify the penetration testing providers and pentesters?
• Are significant vulnerabilities supported by meaningful technical evidence?
• Does each significant vulnerability explain its potential impact?
• Are severity ratings supported by appropriate context rather than simply listed?
• Were significant vulnerabilities tracked through remediation?
• Were appropriate vulnerabilities retested after remediation?
• Are important exclusions and testing limitations documented?
• Does the final conclusion accurately reflect the test's scope and results?

If the answer is yes, your penetration testing report is much more likely to provide useful, defensible audit evidence rather than simply documenting that a penetration test occurred.

A penetration test is more than a report 

A well-documented penetration test can provide valuable audit evidence when its scope, testing, reporting, remediation, and retesting align with what the organization needs to demonstrate. 

For organizations managing multiple cybersecurity and compliance requirements, MHM's integrated approach to independent audits and certification can help reduce duplicate testing and evidence requirements.

Learn more about MHM's approach to independent cybersecurity and compliance audits.