Illustrative deliverable · No customer data
See the report structure before you buy the work.
This fictional, sanitised example shows how HAPSA separates evidence, risk rationale, coverage, remediation and retest outcomes.
Important. This is an illustrative, fictional report structure—not a customer report, certification, penetration-test result or proof of a completed engagement. Names, systems and findings below are examples only.
| Section | Illustrative content | Decision supported |
|---|---|---|
| Engagement record | Fictional ExampleCo API assessment; authorised test window; named stakeholders | Was the work properly scoped and authorised? |
| Executive summary | One material access-control theme, two hardening gaps, one accepted limitation | What requires leadership attention? |
| Coverage | Authentication, authorisation, input handling, rate controls, business logic; source review excluded | What confidence can be placed in the result? |
| Finding HAPSA-EX-001 | Broken object-level authorisation in a fictional order endpoint | What happened, why it matters and who owns the fix? |
| Evidence | Sanitised request/response sequence with synthetic identifiers | Can the engineering team reproduce it safely? |
| Risk rationale | Exploit preconditions, data exposure, business impact and compensating controls | Is the priority defensible? |
| Remediation | Server-side subject/object checks, negative tests and monitoring recommendation | What exact change reduces the risk? |
| Retest | Original evidence repeated after fix; unauthorised object access denied | Was the stated risk actually addressed? |
What every real report should make clear
- The report identifies the legal customer, authorised scope, test dates and limitations.
- Evidence uses the least sensitive data possible and is sanitised for distribution.
- Severity is explained using the customer context rather than copied from a scanner.
- Recommendations distinguish immediate containment, durable remediation and detection opportunities.
- A clean result never claims the system is secure; it states what was tested and what was not.
Turn the next security decision into a clear scope.
Tell us what you need to protect, prove or improve. We will define the evidence, boundaries and next action before work begins.