The report is what you keep after a penetration test. A useful one tells leaders what the risk is in plain language, tells engineers exactly what to fix and how to check the fix, and gives you evidence you can show a customer, auditor or regulator. At Edilec, every report contains an executive summary, findings ranked by severity with CVSS, the evidence behind each finding and the steps to fix it, followed by retest results on the terms in your contract and a signed testing certificate.
The executive summary
The summary is written for people who will not read the rest. It should answer four questions in a page: what was tested, what the most serious problems are, what they could lead to in business terms, and what to do first. It should not hide behind jargon or bury a serious issue in a long table.
The findings
Each finding is a self-contained record. An engineer should be able to pick one up, reproduce it in the agreed test environment, fix it and know how to prove the fix worked, without reading the rest of the report.
| Part of a finding | What it tells you |
|---|---|
| Title and affected component | Which system, URL, API or account the issue is in |
| Severity | A CVSS score and rating, adjusted for the impact in your environment and explained in plain words |
| Description | What the weakness is and why it matters to your business |
| Evidence | Requests, responses and screenshots from test accounts that show the issue is real, with sensitive data removed |
| Steps to reproduce | How your team can see the problem for themselves |
| Fix | The change that removes the cause, not only the symptom, plus any short-term mitigation |
| References | Relevant standards such as the OWASP testing guides |
How severity is ranked
The Common Vulnerability Scoring System (CVSS), maintained by FIRST, gives each finding a base score from how it can be exploited and what it affects. A base score alone can mislead, because the same weakness matters more on a payments API than on a brochure page. Good reports adjust for your environment, explain the reasoning in plain language and say which findings could be combined into something worse than any single one.
| Rating | What it usually means in practice |
|---|---|
| Critical | Direct, likely path to serious harm, such as taking over accounts or moving money; fix immediately |
| High | Serious harm is possible with some effort or preconditions; fix before or soon after release |
| Medium | Real weakness with limited impact or harder exploitation; schedule the fix |
| Low | Hardening or hygiene improvement; fix with normal maintenance |
Turning findings into fixes
- Give every finding an owner and a target date, starting with critical and high.
- Fix the cause. If a permission check is missing on one API, check the same pattern everywhere else.
- Add a test that fails while the weakness exists, so it cannot quietly return.
- Record any finding you decide to accept, with the reason and who accepted the risk.
- Tell the testers when fixes are ready, so the retest checks the real fix.
Retesting
A retest confirms which fixes work. At Edilec, retest terms are agreed in each contract. The retest report lists every original finding as resolved or still open, so you can show a clear before-and-after. Where a finding remains open, the report should say what is left and who owns it.
Sharing the report safely
Reports describe how to break your systems, so treat them as sensitive. Share the full report only with the people who fix things, keep the executive summary for wider audiences, and share Edilec's signed testing certificate, which confirms what was tested and when, if a customer, partner or auditor asks for proof. Test data held by Edilec is stored encrypted and deleted at the end of the period agreed in the contract.
For how the work starts, see How to scope a penetration test. Edilec's approach is described on Penetration Testing and Red Team Services.
