# What should a penetration test report include, and how often should you test?

> A penetration test report should state the scope and rules of engagement, the methodology, an executive summary, and for each finding the affected system, a severity rating, evidence to reproduce it, the impact and specific remediation, followed by a retest. Test at least once a year and after significant changes. PCI DSS, the FTC Safeguards Rule and NYDFS Part 500 each set an annual baseline.

Source: https://www.cyberaccord.com/insights/penetration-test-report-and-frequency · Guide by CyberAccord Security Team, CyberAccord · Published 2026-10-27 · Last reviewed 2026-10-27

A penetration test is only as useful as the report it produces. This guide sets out what the report should contain, and how often the rules that most often apply to our clients expect you to test.

![Cover graphic for the penetration test report guide: a report page with four severity bars of decreasing length, the longest in gold, beside a gold circular arrow standing for the retest.](https://www.cyberaccord.com/assets/insights/penetration-test-report-and-frequency-cover.webp)

Cover image: Cover graphic for the penetration test report guide: a report page with four severity bars of decreasing length, the longest in gold, beside a gold circular arrow standing for the retest.

## Key takeaways

- A usable report has two audiences: an executive summary for leadership and customers, and detailed findings that let engineers understand, reproduce and fix each issue.
- Every finding needs the affected asset, a severity rating with the method behind it, evidence, business impact and specific remediation steps.
- PCI DSS requirements 11.4.2 and 11.4.3 call for internal and external penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change.
- The FTC Safeguards Rule requires annual penetration testing unless you run effective continuous monitoring, and NYDFS Part 500 requires testing from inside and outside your boundaries at least annually.
- A test is not finished until exploitable findings are fixed and retested; PCI DSS 11.4.4 makes the retest a requirement.

A penetration test is an authorized attempt to exploit weaknesses in your systems the way an attacker would. What you keep afterwards is the report. A good one tells leadership how exposed the organization is, tells engineers exactly what to fix, and gives auditors and customers evidence that testing happened. A weak one is a scanner export with a logo on it.

## What should a penetration test report include?

NIST's technical guide to security testing, SP 800-115, describes reporting as a phase that runs alongside the whole test: the rules of engagement are set during planning, logs and interim reports are kept during discovery and attack, and a final report at the end describes the vulnerabilities found, presents a risk rating and gives guidance on mitigation ([NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final), section 5.2.1). Section 8.2 adds that because a report has several audiences, it may need more than one format, and that internal reports should include the test methodology, test results, analysis and a plan of action and milestones.

The OWASP Web Security Testing Guide suggests a report structure in its reporting chapter ([OWASP WSTG v4.2](https://wstg.owasp.org/v4.2/5-Reporting/)). Combined with NIST's guidance, a complete report has these parts:

| Section | What it should contain | Who reads it |
|---|---|---|
| Introduction | Version control, test team, scope, limitations, timeline and disclaimer | Everyone |
| Executive summary | A plain-language view of overall exposure, the most serious issues and strategic recommendations | Leadership, board, customers, auditors |
| Findings summary | A table of every finding with its severity and status | Security and IT leads |
| Finding details | One write-up per issue, detailed enough to understand, reproduce and fix it | Engineers |
| Methodology | The approach followed, the standards used, and how severity was rated | Auditors, assessors |
| Appendices | Cleaned tool output, test checklists and supporting evidence | Engineers, assessors |
| Retest results | The current status of each earlier finding after fixes | Everyone |

OWASP's guidance on the executive summary is to keep it constructive and meaningful, free of jargon and technical detail, with strategic rather than technical remediation advice. That summary is the part your board and your customers will read, so it should be accurate about what was and was not tested.

Scope matters more than it appears to. "No critical findings" means little if the reader cannot see what was in scope, what was excluded, and whether the testers had credentials.

## What does each finding need?

The findings section, in OWASP's words, should give enough information to understand the vulnerability, replicate it and resolve it. In practice, each finding should include:

1. **A clear title and the affected assets.** Hostnames, URLs, API endpoints or accounts, specific enough that the owner knows it is theirs.
2. **A severity rating and the method behind it.** Many testers use the Common Vulnerability Scoring System. FIRST's CVSS v4.0 specification groups metrics into Base, Threat, Environmental and Supplemental, and maps scores to None, Low, Medium, High and Critical ([FIRST](https://www.first.org/cvss/v4-0/specification-document)). The report should say which rating method it used.
3. **A description.** What the weakness is and why it exists.
4. **Evidence and reproduction steps.** Requests, responses, screenshots or commands that let an engineer confirm the issue for themselves. A finding no one can reproduce rarely gets fixed.
5. **Impact.** What an attacker could do with it in your environment: read another customer's records, take over an account, move from a user laptop to a server.
6. **Remediation.** Specific steps, not "apply best practices." NIST notes that recommendations can be technical, such as applying a patch, or about process, such as fixing the patch management routine that let the patch lapse (section 8.1).
7. **References.** Links to the relevant advisory, standard or vendor guidance.

> [!NOTE]
> A CVSS score describes the technical severity of a vulnerability. FIRST's specification states that factors such as regulatory requirements and monetary losses are outside the scope of CVSS. A medium-severity flaw on the system that holds cardholder or client data may deserve faster attention than a high-severity one on an isolated test server. Ask your tester to explain the business impact in each finding, not only the score.

Where several minor issues combine into a serious one, a good report shows the chain as a single attack path.

> **Next step:** Planning your next test around a PCI DSS, FTC or NYDFS deadline? We can help you set the scope and timing. [Explore Penetration Testing](https://www.cyberaccord.com/services/security-testing/penetration-testing) · [Book a free consultation](https://www.cyberaccord.com/contact)

## What should be agreed before testing starts?

The report should refer back to a written agreement made before any testing begins. NIST SP 800-115 provides a rules of engagement template in its Appendix B. It covers the purpose and scope of the test, assumptions and limitations, the risks of testing and how they will be reduced, the people involved and their contacts, the test schedule and hours, where testing is authorized from, how test data will be handled, and what reports will be delivered and how often. It ends with a signature page, where at a minimum the test team leader and senior management sign to confirm they understand the scope and boundaries.

Settle a few practical points at this stage:

- **Testing approach.** Black-box, gray-box with test accounts and some documentation, or white-box with source code and architecture access. Gray-box testing usually gives the most coverage for the time spent.
- **Critical finding notice.** Agree how and when the tester will tell you about a serious issue during the test, rather than waiting for the final report.
- **Off-limits systems and techniques.** Production databases, third-party services you do not own, and anything destructive.
- **Third-party permission.** Cloud providers and hosting companies publish their own rules for testing their platforms. Check them before scope is fixed.

> [!WARNING]
> A penetration test report is a map of how to attack you. NIST SP 800-115 advises that results from any security test identify vulnerabilities an adversary can exploit and should be treated as sensitive (Appendix B, section 5.3). Agree how the report will be stored, shared and eventually destroyed, and send it only to the people who need it.

## How often should you run a penetration test?

The short answer is at least once a year and after significant changes. Several of the rules that apply to our clients put that baseline in writing.

| Rule | Requirement | Frequency |
|---|---|---|
| PCI DSS v4.0.1, Req. 11.4.2 | Internal penetration testing | At least once every 12 months, and after any significant infrastructure or application upgrade or change |
| PCI DSS v4.0.1, Req. 11.4.3 | External penetration testing | At least once every 12 months, and after any significant infrastructure or application upgrade or change |
| PCI DSS v4.0.1, Req. 11.4.5 | Testing of segmentation controls, where segmentation isolates the cardholder data environment | At least once every 12 months, and after any changes to segmentation controls or methods |
| PCI DSS v4.0.1, Req. 11.4.6 | Segmentation testing for service providers only | At least once every six months, and after any changes to segmentation controls or methods |
| FTC Safeguards Rule, 16 CFR 314.4(d)(2)(i) | Penetration testing of information systems | Annually, absent effective continuous monitoring |
| NYDFS, 23 NYCRR 500.5(a)(1) | Penetration testing from inside and outside the information systems' boundaries | At least annually |

**PCI DSS.** Requirement 11.4.1 asks for a documented methodology that uses industry-accepted approaches, covers the entire cardholder data environment perimeter and critical systems, tests from inside and outside the network, validates segmentation and scope-reduction controls, includes both application-layer and network-layer testing, and considers threats and vulnerabilities from the last 12 months. Results and remediation records must be kept for at least 12 months. Testing may be done by a qualified internal resource or a qualified external third party, provided the tester is organizationally independent. Microsoft Learn reproduces the requirement text alongside its own guidance ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/standards/pci-requirement-11)). Version 4.0.1, published in June 2024, was a limited revision that added or deleted no requirements ([PCI SSC](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1)). Our [PCI DSS readiness](https://www.cyberaccord.com/compliance/pci-dss) page covers the rest of the standard.

**FTC Safeguards Rule.** For tax preparers, mortgage brokers, certain auto dealers and other non-bank financial institutions, 314.4(d)(2) requires either continuous monitoring or periodic penetration testing and vulnerability assessments. Absent effective continuous monitoring, you must run annual penetration testing, scoped each year by the risks in your risk assessment, and vulnerability assessments at least every six months ([eCFR](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314/section-314.4)). Firms that hold information on fewer than 5,000 consumers are excused from that schedule but must still regularly test or monitor their key controls under 314.4(d)(1). Our [FTC Safeguards Rule guide](https://www.cyberaccord.com/insights/ftc-safeguards-rule-small-firms) covers the exemption in detail.

**NYDFS Part 500.** Section 500.5(a)(1) requires covered entities to have policies that ensure penetration testing of their information systems from both inside and outside the information systems' boundaries, by a qualified internal or external party, at least annually ([NYDFS](https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf)). Section 500.5(a)(2) separately requires automated scans, plus manual review of systems the scans do not cover, at a frequency set by the risk assessment and promptly after material system changes. Covered entities that qualify for the limited exemption in 500.19(a) are exempt from section 500.5. See our [NYDFS Part 500](https://www.cyberaccord.com/compliance/nydfs-500) page for the rest of the regulation.

Outside these rules, many frameworks and customer contracts ask for regular testing without fixing an interval. NIST SP 800-115 notes that frequency is often driven by compliance requirements, that a test is a snapshot of security at a point in time, and that organizations may choose to test more often (section 6). Systems that hold sensitive data, face the internet or change frequently are the ones that justify it.

## What counts as a significant change?

PCI DSS and NYDFS both tie testing to change as well as to the calendar, but neither gives a closed list in the requirement text. Your assessor's or examiner's view governs. In our experience, the following usually warrant a test, or at least a scoped retest, before or shortly after they go live:

- A new internet-facing application, API or customer portal.
- A major release that changes authentication, authorization or payment flows.
- A move to a new cloud provider, data center or network architecture.
- Changes to firewalls or segmentation that separate sensitive systems from the rest of the network.
- An acquisition or merger that connects another company's network to yours.
- A serious security incident, once the environment has been recovered.

Plan the annual test so it lands after your largest change of the year, not just before it.

## Is a vulnerability scan a substitute?

No. A vulnerability scan compares your systems against known weaknesses automatically. A penetration test has a person try to exploit those weaknesses, combine them and look for flaws no scanner can detect, such as a user reaching another customer's data by changing a request. NIST SP 800-115 describes vulnerability analysis as one part of a penetration test's discovery phase, followed by an attack phase that verifies potential vulnerabilities by attempting to exploit them (section 5.2.1).

The rules treat the two separately. PCI DSS requires quarterly internal and external scans under requirement 11.3 in addition to the annual tests under 11.4. The FTC Safeguards Rule pairs annual penetration testing with vulnerability assessments every six months. NYDFS requires both. Scanning between tests is how you catch new exposures sooner; it does not replace the test.

## What should happen after the report arrives?

NIST SP 800-115 treats remediation as part of the testing process, not something that happens afterwards (section 8.3). It recommends a plan of action and milestones that turns each finding into specific, measurable actions, testing fixes before they reach production, routing changes through your change management process, and then verifying the fixes. It also notes that the test team can verify a fix properly only by repeating the original test.

PCI DSS makes that last step a requirement: under 11.4.4, exploitable vulnerabilities found during testing must be corrected according to your risk ranking, and penetration testing must be repeated to verify the corrections. Even where no rule requires it, a retest is the evidence auditors and customers want to see.

A simple routine works for most organizations:

1. **Debrief.** Walk through the findings with the testers and the people who own the affected systems.
2. **Assign.** Give every finding an owner and a target date based on its severity and business impact.
3. **Fix and verify.** Remediate, then confirm the fix in a test environment.
4. **Retest.** Have the testers repeat the original test on fixed findings and update the report.
5. **Record.** Keep the report, remediation records and retest results together. PCI DSS asks for at least 12 months; other frameworks and customers may expect longer.
6. **Feed it back.** Use recurring findings to fix the process behind them, and to scope the next test.

When a customer asks for evidence in a [security questionnaire](https://www.cyberaccord.com/insights/answering-security-questionnaires), the executive summary and retest results usually answer the question without exposing the technical detail.

## Where to start

Start by listing the rules and contracts that apply to you, because they set your minimum frequency and scope. Note the dates of your last test and your largest planned changes for the year, and schedule the next test after them. Before anyone starts testing, agree written rules of engagement, and ask to see a sample report so you know the findings will be specific enough to act on.

Our [penetration testing](https://www.cyberaccord.com/services/security-testing/penetration-testing) covers web applications, APIs, mobile apps and internal and external networks, with a prioritized report, a debrief with your engineers and a retest of fixed findings. Our [security testing](https://www.cyberaccord.com/services/security-testing) page explains how penetration tests fit with other assessments. If you want help scoping your next test around a specific requirement or customer deadline, [talk to us](https://www.cyberaccord.com/contact).

## Get a penetration test report your team can act on

We scope the test around the systems your auditors and customers care about, write findings your engineers can reproduce and fix, and retest the fixes so the report reflects where you stand.

- Penetration Testing: https://www.cyberaccord.com/services/security-testing/penetration-testing
- Book a free consultation: https://www.cyberaccord.com/contact

## Frequently asked questions

### How often should a small business get a penetration test?

At least once a year and after significant changes, such as a new application, a major release or an infrastructure migration. That matches the annual baseline in PCI DSS, the FTC Safeguards Rule and NYDFS Part 500. Systems that change often or hold sensitive data may justify more frequent testing.

### Is a vulnerability scan the same as a penetration test?

No. A scan compares your systems against known vulnerabilities automatically. A penetration test has a person attempt to exploit weaknesses, chain them together and look for flaws a scanner cannot see. PCI DSS, the FTC Safeguards Rule and NYDFS Part 500 each treat scanning and penetration testing as separate activities.

### Can we share our penetration test report with customers?

Share the executive summary, or a summary letter from the testing firm, rather than the full technical report. NIST SP 800-115 notes that test results identify vulnerabilities an adversary could exploit and should be treated as sensitive. Detailed findings belong with the people fixing them.

## Sources

- [NIST SP 800-115, Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final), National Institute of Standards and Technology (NIST), 2008-09-30
- [Web Security Testing Guide v4.2, 5. Reporting](https://wstg.owasp.org/v4.2/5-Reporting/), OWASP
- [Common Vulnerability Scoring System v4.0: Specification Document](https://www.first.org/cvss/v4-0/specification-document), FIRST, 2024-06-18
- [PCI DSS v4.0.1 (Document Library)](https://www.pcisecuritystandards.org/document_library/), PCI Security Standards Council, 2024-06
- [Just Published: PCI DSS v4.0.1](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1), PCI Security Standards Council, 2024-06
- [Microsoft Entra ID and PCI-DSS Requirement 11](https://learn.microsoft.com/en-us/entra/standards/pci-requirement-11), Microsoft Learn
- [16 CFR 314.4, Elements (Standards for Safeguarding Customer Information)](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314/section-314.4), Electronic Code of Federal Regulations (eCFR), 2026
- [Second Amendment to 23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies](https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf), New York State Department of Financial Services, 2023-11-01

Last reviewed 2026-10-27. General guidance, not legal advice.

## Contact CyberAccord

- Book a free consultation: https://www.cyberaccord.com/contact
- Phone: +1 (832) 429-5665
- Email: info@cyberaccord.com