What a penetration test report must prove before you sign it
A framework assessor, a customer's security team, a launch review or an insurer will ask for a penetration test report, and each will treat it as evidence that someone else can rely on. Before you accept a report, check that it can carry that weight. The report has to show what was in scope, how the testing was done, what was out of reach, and why each finding received its severity. NIST SP 800-115 treats reporting as the final phase of a test, the point where the work is turned into something the organization can act on and an outside reader can verify. A report that lacks any of those elements is a summary of opinions, not proof that a system was tested.
Ask the provider to show, in the report itself, how scope was agreed against the written rules of engagement, and which accounts, roles and environments the testers actually used. The PCI SSC outline expects a statement of methodology and a statement of limitations, so look for named test types, known gaps such as excluded hosts or time-boxed access, and the tools used. Then check severity. The report should explain how each rating was derived, usually from a published score such as CVSS, and show the reasoning for any adjustment made for your environment. Ratings with no traceable basis are difficult for an auditor to accept and hard for your team to prioritize.
Be clear about who decides the outcome. DeployOpen plans, performs and documents security testing and prepares the evidence an assessment needs, but independent auditors and certification bodies issue assessment outcomes, attestations and certifications. Confirm with your assessor, before the test starts, which report format and evidence they expect, and whether they will accept the methodology the provider documents. Then plan the retest into the report's timeline. A report is only the starting point for remediation and validation, and the retesting terms should be agreed in writing alongside the scope.
Which sections a penetration test report should contain
PCI SSC's suggested outline is a useful checklist for judging any penetration test report. Each section answers a different question, and each serves a different reader, from the executive who funds remediation to the engineer who has to reproduce a finding. A report missing one of these sections is harder to rely on, whatever its finding count.
Executive summary
A short narrative for leadership that states the overall risk posture, the most serious findings in business terms and the top remediation priorities. Executives use it to decide funding and escalation, so it should stand on its own without the technical body. Check that it names the systems tested and avoids inflated or vague language about overall security.
Statement of scope
This section lists the targets, IP ranges, applications, accounts and environments that were tested, and it should match the signed rules of engagement. Auditors use it to confirm that the test covered the cardholder data environment or other in-scope systems. Check for explicit exclusions and any changes made during testing.
Statement of methodology
This section explains how the testing was carried out, including the phases, knowledge level (black, grey or white box) and the testing standards or guides referenced. Because NIST does not endorse one methodology over another, the report must state which approach was used. Check that manual testing is described as distinct from automated scanning.
Statement of limitations
This section records what the test could not cover, such as time constraints, unavailable accounts, excluded test types or environments that differed from production. Limitations stop a clean result from being read as proof of security. Check whether each limitation has a stated effect on the conclusions.
Testing narrative and segmentation results
The narrative describes the attack paths the tester followed, what worked, what was blocked and where defenses held. For organizations with network segmentation controls, the segmentation results show whether isolation between zones was verified. Engineers use the narrative to understand chains of weakness, and auditors use segmentation results to confirm scope reduction.
Findings with CVE and CWE references
Each finding should state its severity, how that rating was derived (typically from CVSS, with any environmental adjustments explained), evidence, affected assets and remediation advice. CVE identifiers tie known vulnerabilities to advisories, and CWE identifiers classify the underlying weakness. Check that the severity reasoning is traceable and that remediation is specific enough for an engineer to act on.
Tools used and environment clean-up
This section lists the tools and versions used and confirms that test accounts, payloads, backdoors and temporary data were removed afterward. It gives the client an audit trail and shows that testing did not leave residual exposure. Ask the provider to confirm clean-up in writing and to name any retained artifacts.
How severity ratings should be justified
A useful report shows how each severity or risk rating was derived, not just the label. PCI SSC's penetration testing guidance expects the rating to trace back to an industry score, typically a CVSS base score, and any change made for your environment must be explained step by step. Ask the provider to show the base vector for each finding, the metrics they changed, and the reason for each change, such as a compensating control that blocks the attack path, a data classification that raises impact, or an exposure that exists only on an internal segment. A rating with no visible derivation cannot be checked by your team or your assessor, and it cannot be defended to a customer or regulator.
Expect the rating to differ from a scanner's output, and treat that difference as useful information. A scanner scores a vulnerability in isolation from your architecture. A tester who has confirmed the flaw is exploitable, and who can show what an attacker reached from it, may rank it higher. Equally, a tester may lower a score because a control already limits the impact. Ask the provider to state which findings were confirmed by manual exploitation, which were inferred, and where the scanner and tester ratings disagree, with the reason for each disagreement. Confirm that the report keeps the original scanner score next to the adjusted one, so the adjustment can be reviewed.
Your own risk ranking matters more than the tester's label. PCI DSS requirement 11.4.4 requires exploitable vulnerabilities found in penetration testing to be corrected according to the entity's risk ranking, and then the test repeated to verify the fix. Before the test, agree in writing how your organization will translate ratings into remediation deadlines, and ask the provider to map each finding to that scheme. Confirm with your assessor which ranking method they will accept as evidence. The retest is the check that the chosen ranking was honored, so keep the rating rationale with the remediation record.
What the methodology statement must disclose
The knowledge level describes how much the tester knew before starting. PCI SSC's Penetration Testing Guidance defines black-box testing as no information provided, white-box testing as full details of the network and applications, and grey-box testing as partial details. The guidance says PCI DSS tests are typically white-box or grey-box because those levels give more accurate and comprehensive results, and that a black-box assessment may need more time, money and resources to meet PCI DSS deliverables. A statement that only says "external penetration test" leaves the reader guessing how deep the work went.
- Starting information: The report should name what the tester was given, such as architecture diagrams, source code, or test accounts with specific roles.
- Access during testing: It should say whether authenticated access was used, and for which roles, since many flaws sit behind login.
- Scope of the knowledge gap: A black-box result can be correct for the attacker's view but silent on internal weaknesses that a grey-box test would reach.
- Changes to the starting position: Any information added midway should be recorded, along with when it arrived.
Before accepting the findings, confirm that the stated knowledge level matches what your auditor or customer expects for the requirement being tested.
PCI SSC describes penetration testing as a mainly manual process that exploits vulnerabilities to defeat security features, in contrast to vulnerability scans, which use mostly automated tools to identify and rank issues. OWASP ASVS 5.0.0 states that certifying organizations may choose their testing methods but should disclose them in the report, and that merely running an automated tool without thorough testing is insufficient. The methodology statement must therefore separate tool output from tester judgment, so the reader can see how much of the result came from a person working through business logic, authorization and chained conditions.
- Tools named: The report should list the scanners, proxies and other tools used, with versions where the tester can provide them.
- Manual share: It should describe the areas that received hands-on testing, such as authentication, authorization, and payment or session flows.
- Tool-only areas: Any area covered only by automated checks should be stated plainly.
- Verification of automated results: It should say whether each automated finding was validated manually before it was reported.
If the statement does not separate these, ask the provider which findings were confirmed by hand and which were not.
Reference standards give the test a fixed set of checks, so results can be compared across tests and against an audit requirement. OWASP ASVS, the OWASP Web Security Testing Guide and the OWASP Top 10 are common references for application work. Infrastructure tests often reference NIST SP 800-115, which says NIST does not endorse one methodology over another and leaves organizations to adopt or combine methodologies. The methodology statement should name the standard, the version used and any part of it that was skipped or adapted, because an unnamed or silently modified method cannot be checked against the requirement it is meant to satisfy.
- Named standard and version: The statement should identify the exact framework and version, not just a family name.
- Coverage map: It should show which controls or test cases were covered and which were out of scope.
- Adaptations: Any tailoring, such as a shortened checklist, should be disclosed with the reason.
- Tester qualifications: It should note the certifications or accreditations held by the people who ran the tests, without treating them as proof of experience.
Compare the named standard with the one your assessor or customer requires, and confirm that the version matches.
Why the limitations section protects both sides
The statement of limitations records what the test did not cover, the time window in which testing happened, any access restrictions the tester worked under, and the assumptions both parties accepted. Its job is to stop a clean result from being read as a clean environment. A report that lists no critical findings tells you only what the tester could reach, with the accounts and hours it was given. Before you accept a report, read this section first and compare it line by line with the signed scope and rules of engagement. Confirm that every excluded host, application, segment, cloud account and third party appears in the limitations, and that no excluded item is quietly described as tested in the findings or executive summary.
For an auditor or customer, treat each exclusion as a question rather than a pass. If a payment API, an administrative console or a segment that stores cardholder data is listed as out of scope, the reader needs to know whether another control or test covers it, and whether the segmentation claims depend on that boundary holding. Ask the provider to state whether testing used credentials or was unauthenticated, whether any target was tested only from one network position, and whether testing windows excluded peak business periods. Where the report says a control was not tested because of time or access, record that as an open risk in your own register instead of closing it. Keep the limitations statement with the report so the context travels with any evidence you share.
Both sides benefit when the limitations are specific from the start. Agree the exclusions, time boxes and access model in writing during planning, as the rules of engagement should, so the report only restates decisions already made. Ask the provider to explain any limitation that emerged mid-test, such as a fragile system that was excluded for safety, and to confirm how that item will be covered in the next test or retest. A provider that can name its limits clearly is giving you the information you need to plan the next step, and that is the difference between a report that supports your decisions and one that merely looks reassuring.
How to read a penetration test report from front to back
This reading order lets a CISO, auditor or engineering lead confirm that the test covered what was agreed, understand the risk in plain terms, verify the most serious findings and see whether fixes were checked. Each step produces a decision or a question to take back to the tester.
Confirm scope, dates and tested assets
Start with the statement of scope and the testing dates. Compare the listed IP ranges, domains, applications, accounts and environments against the scope agreed in writing before testing began. Check that the test dates fall within the agreed window and that any system added or removed during testing is explained. If a listed asset is missing or an unlisted one appears, raise it before reading further, because every later conclusion depends on this match. This step is complete when you can state, in one sentence, what was tested and when.
Read the statement of limitations
Next, read the statement of limitations and the stated methodology. Look for the knowledge level used (black, grey or white box), any exclusions, testing windows, rate limits or tools the tester could not run, and any areas where access was denied. Confirm that the methodology is disclosed rather than summarized as an automated scan. A report that does not state its limitations gives you no basis for judging coverage. Note each limitation that could hide a risk from your organization, since you will need to decide whether a separate test is required.
Read the executive summary for the overall picture
The executive summary should state the overall risk posture, the number of findings by severity and the most significant business consequences in non-technical language. Check that it agrees with the detailed findings. If the summary says the environment is well protected but the findings list contains serious items, the report needs clarification. Use this section to brief leadership, but do not treat it as evidence, since it summarizes the detailed sections that follow.
Review the highest-severity findings and their reasoning
Turn to the critical and high findings and read each one in full. For each, check the severity rationale: a CVSS base score or a similar industry score, plus a traceable explanation of any adjustment for your environment. Confirm the affected asset, the weakness category with its CVE or CWE reference where applicable, and whether the tester showed that the weakness could be used to defeat a security control. Good evidence shows what was observed, where, and under what conditions, such as screenshots of the affected function, request and response records with sensitive data redacted, or the configuration value found. It should not contain working exploit code or step-by-step attack commands. Ask the tester for a private walkthrough if you need to confirm reproducibility.
Check the remediation advice against your own environment
For each finding, read the remediation guidance and ask whether it is specific enough for your engineers to act on. Good advice names the configuration, code path, patch or design change, and the control that should stop the weakness from recurring. Compare it with the risk ranking your organization applies, because PCI DSS requires exploitable vulnerabilities to be corrected according to the entity's own risk ranking. Note which findings are assigned to owners and which need a decision on risk acceptance. This step is complete when every high-severity finding has a named owner and a proposed fix or documented exception.
Verify the retest status and open items
Finally, check the retest status for each finding. A retest should confirm whether each fix addresses the original risk, not just whether a change was made. Look for a status such as closed, open, partially resolved or accepted, with the date and method of verification. If remediation is still in progress, confirm the planned retest and who will perform it. PCI SSC's guidance says remediation that runs long after the original test may require a new engagement, so flag any delays to decide whether a new test is needed. Close the review by recording open items, the owner for each and the next verification step.
Which finding types the report should cover and how they are described
This table compares the common weakness categories a penetration test report should cover, what each looks like as a finding, the evidence an assessor expects and why it matters to the business. Use it to check whether a sample report describes each category with enough detail to act on, without exploit steps.
| Finding type | What the report entry shows | Evidence expected | Why it matters to the business |
|---|---|---|---|
| Authentication and session weaknesses | Weak login controls, missing lockout or MFA gaps, session tokens that persist or can be reused | Affected endpoint, the control that was missing or weak, and a note on what the tester observed without harmful use | Compromised accounts can expose customer or staff data and bypass payment and admin controls |
| Access control | Users able to view or change records or functions outside their role | Role or account used, the object or function affected, and the expected versus observed authorization result | Broken access control is a frequent route to unauthorized data access and often maps to regulated data |
| Injection | Untrusted input reaching a database, command or template interpreter without proper handling | Vulnerable parameter, input class tested, sanitized response sample and the CWE reference | Injection flaws can lead to data theft or full system compromise, so severity is usually high |
| Misconfiguration | Default settings, verbose errors, exposed admin interfaces, unnecessary services or permissive cloud policies | Configuration item, the observed value, the baseline it departs from and the vendor or project guidance cited | Misconfigurations are often cheap to fix but widen exposure across many systems at once |
| Vulnerable components | Outdated libraries, frameworks or platform versions with known CVE references | Component name and version, CVE identifiers, and whether the vulnerable code path was reachable | Known flaws are easy for attackers to find, so the report should show whether the component is actually exposed |
| Segmentation gaps | Paths between networks or zones that should be isolated, such as cardholder or production segments | Source and destination zones, tested protocols, and the result of each boundary check | Gaps can extend the scope of a compliance assessment and the reach of any single compromise |
| Insecure data handling | Sensitive data stored, logged, cached or transmitted without adequate protection | Data type, location, encryption or masking status, and the test method used to confirm it | Exposure of personal, financial or health data triggers notification duties and customer harm |
How the retest report documents closed findings
A finding marked as verified fixed means the tester repeated the original test steps against the same target and confirmed that the weakness no longer produces the original result. The report should not stop at saying a patch was applied. PCI SSC's guidance says the retest exists to validate that the new controls mitigate the original risk, so the verification has to tie the fix to the risk it was meant to remove. A useful entry names the original finding reference, the target and the retest date, and describes what was checked and what the tester observed after the change.
- Original reference kept: each closed item carries the identifier used in the first report, so the auditor can match the two documents without rereading the narrative.
- Evidence of the new state: the report records the observed behavior after remediation, such as a rejected request or a corrected configuration value, in a form that can be reproduced.
- Scope of the fix confirmed: the tester notes whether the fix was applied to every affected instance, not only the example used in the first test.
- Method stated: the report identifies whether the retest was manual, automated or both, consistent with the methodology disclosed in the original engagement.
- Date and version tied to the fix: the entry shows which build, configuration or release was tested so the closure can be traced later.
Check that each closed finding names the target version or configuration it was verified against, because a fix on a staging copy does not close a production finding.
A partially mitigated finding is one where the change reduces the risk but does not remove the original attack path or weakness in full. This is common when a fix covers one endpoint, one role or one input but leaves a variant open, or when a compensating control such as a rate limit or a network restriction limits exposure without correcting the underlying defect. The report should say what changed, what still works, and what conditions must hold for the remaining risk to stay low. Partial status should never be used to soften an open result.
- Residual path described: the report states the specific condition under which the original weakness can still be reached.
- Compensating control named: if a control is relied on, the report identifies it and explains why it addresses the original risk.
- Severity revisited: the tester notes whether the residual risk changes the original rating, with the reasoning shown.
- Owner and next step: the report names who must act and what a complete fix would involve.
- Retest condition for closure: the entry states what evidence would move the finding to verified fixed.
Confirm with the tester whether a partial result will be counted as closed in your risk register, because that decision belongs to your organization, not to the report.
An open finding means the original weakness was still reproducible at retest, or the remediation was not in place when the retest ran. Open does not automatically mean the tester failed. It may reflect a deferred fix, a change that did not reach production or a risk acceptance that has not been documented. The report should record the reason in plain terms and keep the original severity so the open item stays visible to the people who decide on it. PCI DSS requirement 11.4.4 requires exploitable vulnerabilities to be corrected according to the entity's risk ranking and the testing to be repeated to verify the correction, so an open item needs a clear path to another retest.
- Reason recorded: the report states whether the cause is an incomplete fix, a failed deployment, an accepted risk or a scope disagreement.
- Original severity kept: the rating from the first report stays on the item unless the tester documents a justified change.
- Reproduction stated: the report explains how the weakness was still observed, without exploit detail beyond what the client needs to validate the fix.
- Accepted risk documented: if the client accepts the risk, the record names the approver and the review date.
- Next retest booked: the report records when the finding will be retested and by whom.
Check whether any open item has been pending long enough that the original test no longer reflects the environment, since long delays can require a new engagement rather than a retest.
A retest validates fixes against the environment that existed when the original test ran. As time passes and the system changes, a retest of old findings becomes less useful as evidence of current security. PCI SSC's guidance says remediation that happens long after the original test may require a new engagement, and PCI DSS also requires internal and external penetration tests at least every 12 months and after significant changes. The retest report should therefore state the original test date, the retest date and the elapsed period, so the reader can judge whether the result still describes the live system.
- Dates recorded: the report lists the original test window, each retest window and the environment version tested.
- Significant change noted: if the system changed materially after the original test, the report flags whether the retest still applies.
- Gap explained: the report notes any period where no testing occurred and why.
- New test trigger identified: the tester states when remediation has moved far enough from the original test that a new engagement is advisable.
- Annual cycle linked: the record shows how the retest fits the 12-month testing requirement under PCI DSS.
Ask your provider in writing what they consider a long delay for your environment, because the standards set the minimum frequency but do not define a single cutoff for every system.
Auditors and customers read a retest report to answer one question: which original risks are now demonstrably controlled, and which are not. A retest report that lists only the outcomes without evidence is hard to rely on, and one that buries open items in a long narrative causes avoidable questions. The report should be built so an assessor can trace each original finding to its outcome, and so a customer security team can confirm that the remediation matches what was promised. DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies make the compliance determination.
- Summary table of outcomes: a single table lists every original finding with its final status, which is the first thing an assessor will check.
- Cross-reference to original report: each entry points back to the first report by finding identifier.
- Clear status vocabulary: the report defines what verified, partial and open mean in that document.
- Limitations restated: the retest states what it did not cover, so closed status is not read as broader than it is.
- Sign-off and author identified: the report names the tester and the reviewer responsible for each outcome.
Before the retest starts, confirm with your assessor or customer which format and status vocabulary they will accept.
What auditors and customers accept as evidence
A penetration test report serves several readers, and each one judges it against a different question. The cards below cover the common uses, what each reviewer tends to look for, and where the decision sits. Acceptance always belongs to the auditor, customer or reviewer, so confirm their criteria before testing starts.
PCI DSS assessor review
A PCI DSS assessor checks whether the report follows the scope, methodology and limitations an assessor expects, and whether segmentation results and retest evidence line up with the requirements being claimed. Look for a clear statement of which systems were in scope, which were excluded and why. Ask the assessor, before testing, whether they want a specific report outline or a particular knowledge level such as grey-box or white-box testing.
Customer security questionnaire
A customer's security team usually wants proof that a test happened, when it happened, who performed it and whether serious findings were fixed. Reviewers tend to accept a summary that names the test window, the testing approach and the status of each high-severity finding. They rarely need the full technical narrative. Confirm whether the customer accepts a redacted version and whether they require the tester's name or accreditation on the cover.
Insurer and due diligence review
Insurers and acquirers look for evidence that testing is recurring, that findings are tracked to closure and that the scope covers the systems that carry the most risk. They often ask for the executive summary, the list of open findings and the date of the last retest. Confirm in advance whether the insurer wants the full report or a summary letter, since sharing the full report may raise confidentiality questions.
Board and executive summary
Board members need to understand the overall exposure, the business systems affected and the decisions they must take, such as funding remediation or accepting residual risk. The executive summary should explain severity in business terms and state how the rankings were derived. Ask the provider to confirm that the summary reflects the technical findings accurately, and that it does not overstate or soften risk.
Internal audit and framework reviewers
Internal audit and certification frameworks such as CIS Controls ask whether testing happened on the required cadence and whether it covered both external and internal exposure. Reviewers look for a stated methodology, which OWASP ASVS asks certifying organizations to disclose, and evidence that automated tooling was supported by manual testing. Confirm the framework's exact control wording with the reviewer, because the acceptance decision belongs to them.
How report depth affects cost and timing
Reporting is not a fixed slice of a penetration test. The effort it takes to write and check the report rises with three things: the number of findings, the depth of evidence each finding needs and the number of audiences the report must serve. A test that produces a handful of well-evidenced findings for a technical team is a different piece of work from one that produces dozens of findings, each with reproduction detail, environment context and severity reasoning, and then needs a separate summary for the board. Before you accept a quote, ask the provider how they expect the finding count to shape the reporting phase, and whether the quote assumes a particular level of evidence. Also check whether the quote assumes a single report or several versions for different readers.
Black-box work can add to this effort. PCI SSC's Penetration Testing Guidance notes that a black-box assessment may require more time, money and resources for the deliverables to meet PCI DSS requirements. The reason is that a tester starting with no information spends time on discovery and mapping before any analysis begins, and the report then has to explain how the coverage was reached. If your goal is a PCI DSS deliverable, ask the provider to state the knowledge level in the scope, to explain how that level affects the time needed to produce the report and to confirm that the deliverable structure matches what your assessor expects. Testing at grey-box or white-box level often produces a clearer report for the same budget, though that trade-off should be your decision, not a default.
Two items are usually priced separately from the main report. The first is retesting, which checks whether fixes actually close the original findings and produces a further report section or document. The second is a custom executive version, which translates technical findings into business risk for a board, regulator or customer. Ask for both to be listed as separate line items in the quote, with the conditions under which each is triggered, so you can see what is one-time and what would be added later. Confirm whether retest scope is capped by finding count, whether it requires a new engagement after a long delay, and whether the provider will issue a retest report that your auditor can read alongside the original.
Questions buyers ask about penetration test reports
Does a vulnerability scanner report count as a penetration test report?
No. A scanner report lists issues found by mostly automated tools, while a penetration test report describes manual testing that tried to exploit weaknesses to see what an attacker could actually reach. PCI SSC's guidance draws this distinction, noting that vulnerability scans run in seconds to minutes per host while penetration tests are a mainly manual process that may last days or weeks depending on scope. A scan output can be an input to a penetration test, but it does not replace the tester's narrative, scope statement, methodology, limitations and validated findings. Ask the provider to show which findings were confirmed by hand and which came straight from a tool.
What must I provide to get a useful penetration test report?
A useful report depends on the information and agreements you put in before testing starts. Under the planning phase described in NIST SP 800-115, rules of engagement, management approval, testing goals and the target list should be written down before any testing occurs. Practical inputs include:
- A signed scope with in-scope hosts, applications, accounts and IP ranges, plus explicit exclusions
- Test accounts and roles for authenticated testing, if the test is grey or white box
- Named contacts for escalation and a testing window
- Architecture diagrams, data flow and segmentation details, where segmentation matters for your compliance scope
Missing inputs usually show up as unclear limitations in the report, so confirm each item with the provider in writing.
Can my own team write the penetration test report?
Your team can write its own internal summary or remediation plan, but the independent tester should author the penetration test report itself. Auditors and customers generally expect the report to state the testing performed, the methodology, the limitations and the evidence for each finding, and those statements must come from the people who ran the tests. If your team edits the report for layout, terminology or confidentiality, agree that edits never change the findings, severity or evidence. Ask the provider to explain its review process and how it records any changes made after delivery.
How long does reporting take compared with testing?
Reporting time depends on the number of findings, how much evidence must be captured, the number of environments covered and whether a segmentation or retest section is required. Testing and reporting are separate line items in most engagements, so the schedule should show both. Ask the provider to state in the written proposal how many working days it expects between the end of testing and the draft report, how many review rounds are included, and when the final version is delivered. Those commitments belong in the statement of work, not in a verbal assurance.
Can I see a sample penetration test report before buying?
Many providers can share a redacted sample, and you should ask for one before you commit. A useful sample shows the executive summary, scope and methodology statements, the limitations section, and several findings with severity reasoning, evidence and remediation advice. Check whether the sample explains how severity was derived, for example from CVSS with any environmental adjustments traced in the text. Ask the provider to confirm its sample is current, that its handling rules are acceptable for your procurement process, and that the sample does not reveal another client's data.
How do I confirm a provider's report meets my auditor's expectations?
Ask your auditor or assessor which report elements they require before the test starts, then compare those elements against the provider's sample and proposal. For PCI DSS work, the PCI SSC outline covers scope, methodology, limitations, findings with CVE and CWE references, tools used and environment clean-up, and requirement 11.4 governs repeat testing. For OWASP ASVS-based assessments, the standard expects the testing methods to be disclosed in the report. Confirm the provider's qualifications with the assessor as well, since no certification alone establishes that a report will be accepted. The assessor's acceptance is the test that matters, and DeployOpen prepares evidence for that review but does not issue audit reports or attestations.
How DeployOpen writes and checks penetration test reports
DeployOpen runs security testing across applications, APIs, cloud, infrastructure, AI systems and self-hosted open-source platforms, and prepares the report as part of the same engagement. Each report is built from a written scope, documented methodology and stated limitations, so that the findings can be read and acted on by engineering teams, auditors and customers.
How we scope
- Engagements are fixed-scope, so the report's scope statement matches the targets and environments agreed in writing before testing starts.
- We record the testing approach, whether black, grey or white box, and the accounts and roles used, so readers can judge the coverage.
- Rules of engagement, testing windows and exclusions are documented up front so the report can state exactly what was in and out of bounds.
How we build
- Testing is carried out with manual work on business logic and authentication flows, with automated tools used to support that work rather than replace it.
- Each finding records the evidence observed, the affected component and the conditions under which the weakness was confirmed.
- Severity is explained with the scoring method used, and any adjustment for the client's environment is traced in writing so it can be checked.
How we hand over
- The report includes an executive summary, scope, methodology, limitations, testing narrative, tools used and findings with remediation advice.
- Findings reference relevant CVE and CWE identifiers where they apply, so engineering and audit teams can trace each issue to a known category.
- The report states the environment clean-up performed after testing, so the client knows which test artifacts remain and which were removed.
How we support
- After remediation, retesting confirms whether fixes address the original risk, and the retest report documents each closed finding.
- Ongoing support, upgrades and continuous testing are available as retainers for clients who need periodic testing after significant change.
- Clients should confirm the report format, retest terms and attestation boundaries with us in writing, since DeployOpen prepares evidence but does not issue audit reports.
