Penetration Test Reports: What to Redact Before You Share One
A pentest report maps how to break in. See what each reader needs, what to strip, and how to mask credentials, IP addresses, personal data and screenshots.
A penetration test report is a map of how to get into your systems. Share the full report with as few people as possible. Give everyone else a shorter version with the sensitive parts masked, and check the pictures as well as the text.
Why Is a Penetration Test Report So Sensitive?
The report exists to help you fix problems, so it describes them in detail. In France, ANSSI's rules for qualified audit providers set what the report must say about each vulnerability. It must give the attack scenarios, the conditions for exploitation and the result of any attempt. In Germany, the BSI says the report may hold highly sensitive content. It should reach only the tester, the tester's quality assurance and a selected group at the client.
What Is Inside a Report, and Why Is Each Part Sensitive?
Reports differ, but the outline in the PCI Security Standards Council's guidance is a good guide. As of October 2026, the versions read are NIST (2008), PCI SSC (2017), ANSSI (2024) and BSI (a 2016 guide and a 2003 study).
| Part | What it can hold | Why it is sensitive |
|---|---|---|
| Executive summary | Overall result, top risks | Least sensitive, but it still shows how weak you were |
| Scope and annexes | Targets, IP addresses, domain names, URLs, dates | A ready-made target list. ANSSI's rules make the audit plan and the scoping note annexes |
| Findings | Affected systems, attack steps, severity, result | They show an attacker where to go and how, while open |
| Evidence | Screenshots, tool output, file or database dumps | Often hold passwords, hashes, tokens and real people's data |
| People | Testers' names and contacts, names and roles of the client staff they dealt with | Personal data. ANSSI's rules require both in qualified reports |
Who Needs What: Customers, Insurers, Auditors and Developers?
Most readers do not need the full report. NIST SP 800-115 (US) says a report may have several audiences, so several formats may be needed. The BSI adds that managers need no technical detail, while technicians need exact descriptions. Ask what the reader must decide, then give the smallest document that allows it.
| Recipient | What to give | What to strip |
|---|---|---|
| Customer with a security questionnaire | Summary, test date, general scope, fix status | Hostnames, IP addresses, open findings, evidence, tester names |
| Insurer or broker | Summary, test date, number of findings by severity | Attack steps, evidence, internal names |
| Auditor or assessor | Scope, method, findings that matter for their standard | Credentials, hashes, personal data in the evidence |
| Provider fixing one issue | Only the findings for the systems they run, with steps to reproduce | Other systems, secrets, other teams' names |
| Developers in your company | Technical findings with redacted screenshots | Real passwords and real customer data |
What About Personal Data the Testers Captured?
Testers can capture real people's data on the way. NIST SP 800-115 warns that captured data may include personal employee data. Under the GDPR (EU), any information about an identifiable person is personal data, and Article 5 limits it to what is necessary. A staff name counts.
The BSI study says passwords and private emails that the tester captured should stay out of the final report. After the test they go to one agreed person, such as the data protection officer. PCI guidance recommends keeping card data to a minimum, for example not dumping a whole database.
Look for these in every copy:
- Screenshots of internal apps showing customer or staff records
- Names and emails harvested in a phishing exercise
- Password lists, hashes and recovered passwords
- Private emails or messages opened as proof of access
Replace a real record with a count. “We could read about 4,000 customer records” proves the point without showing one.
Which Secrets and Network Identifiers Must Go?
Remove anything an attacker could use as it stands. OWASP's guide says possibly sensitive data in a finding should be masked, such as passwords, personal information or card details. If the testers found a working password or key, change it now. A masked copy does not repair a secret that everyone saw in the first version.
- Passwords, password hashes and recovered passwords
- API keys, cloud tokens, session cookies, JWTs and SSH private keys
- IP addresses, hostnames, server names and internal domain names
- Full URLs, including parameters that reveal an internal path
Why Do Screenshots and Scanned Annexes Need Extra Care?
Evidence is often an image. PCI guidance lists screenshots, raw tool output and recordings as typical evidence. A text search in the PDF cannot find the words inside a terminal screenshot. The same goes for a scanned annex, such as a signed authorisation letter.
ONYRI Sanitize runs in your browser and never uploads files. On every plan it finds IPv4 addresses, web links, emails and passwords after a label such as “password:” (not plain lowercase words). Check IPv6 addresses by eye. Pro adds API keys, cloud tokens, JWTs and SSH private keys. OCR reads scanned pages, not screenshots inside a page with text. Bare hostnames, server names and vulnerability details are not detected: use “Search the document” for text and “Draw an area” for screenshots.
Can a Tester Reuse a Report in a Portfolio or a Talk?
Check your contract first, and ask the client in writing before you reuse anything. The BSI's practical guide says the contract should forbid telling third parties about the weaknesses found, the structure of the organisation and its systems. It adds that published findings must be anonymised, so nobody can trace them back to the tested organisation.
- Remove the client name, logo, domains, IP ranges and staff names.
- Remove sector clues: a rare product, a city, a date, an unusual technology mix.
- Cover every screenshot with solid boxes, or redraw it with made-up data.
- Strip comments and document properties. Then ask a colleague to guess the client. If they can, cut more.
Before you send any copy, name the reader, pick the smallest document that serves them, and look at every picture, one by one. This is general information, not legal advice. For contract or GDPR questions, ask your lawyer or data protection officer.
Frequently asked questions
Can I send the full penetration test report to a customer?
Usually not. Most customers need the summary, the scope and the test date. If one insists, send the full report only to named people under a confidentiality agreement, and mask credentials and personal data first.
Should the tester delete their copy after the test?
Agree this in the contract before the test. PCI guidance recommends writing down retention and destruction rules for evidence before testing starts. In France, ANSSI's rules require qualified providers to return, delete or destroy project material at the end, except what the client lets them keep.
Does a pentest report count as personal data?
Not as a whole, but it often contains some. Staff names, harvested email addresses and customer records in screenshots all count under the GDPR (EU). Data minimisation then applies, so cut what the reader does not need.
Is a black bar over an IP address enough in a PDF?
Not always. If the PDF still holds the text under the bar, anyone can copy it out. Turn the pages into images first, then try to select and search the words in the result.
Sources & references
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (2008)NIST
- Web Security Testing Guide, Reporting StructureOWASP
- Information Supplement: Penetration Testing Guidance, version 1.1 (September 2017)PCI Security Standards Council
- Prestataires d'audit de la sécurité des systèmes d'information (PASSI), référentiel d'exigences, version 2.2 (1 August 2024)ANSSI
- Ein Praxis-Leitfaden für IS-Penetrationstests, version 1.2 (November 2016)BSI
- Studie Durchführungskonzept für Penetrationstests (in German, November 2003, marked as still current, status 2020)BSI
- GDPR, Article 4: Definitionsgdpr-info.eu
- GDPR, Article 5: Principles relating to processing of personal datagdpr-info.eu