SAMPLE CUSTOMER-FACING AUDIT RESULT

From verified risk to an action plan and repeat testing

This fictional example shows exactly what the customer receives: clear business impact, technical confirmation, remediation guidance for the client team and a separate status after repeat testing.

VERIFIED FINDING PASSPORTHIGH
FINDING 01

Insufficient object-level access control

A normal authenticated user can change an identifier and retrieve an object owned by another account. The finding was manually validated in the agreed test context.

Risk levelHIGH
Validation statusVALIDATED
Affected assetAPI / ACCOUNT
Next stepClient fix and repeat testing

HOW TO READ A FINDING

One finding answers four practical questions

These four blocks give the customer one connected answer: what happened, why it is possible, how important it is and what to do next.

01 / CONDITION

Where the problem is

The endpoint accepts an object identifier but the server does not verify ownership for the current user. Route, role, environment and prerequisites are recorded.

02 / SCENARIO

What an attacker can do

An authenticated user changes the identifier and reaches another account object. The scenario is documented step by step without unnecessary harmful actions.

03 / IMPACT

What is affected

Customer-data confidentiality, service trust and personal-data processing are at risk. Affected assets and roles are listed separately.

04 / PRIORITY

Why fix it now

The scenario is available to a normal account, needs no admin rights and may affect many objects sharing the same access logic.

LEADERSHIP

Concise impact on business, data, customers and obligations.

ENGINEERING

Exact conditions, reproduction, root cause and guidance.

RISK OWNER

Priority, action owner and a verifiable status after changes.

GUIDANCE & REPEAT TESTING

From root cause to a verified status

We document root cause and remediation guidance. The client or an agreed contractor implements changes; then we separately repeat the original scenario.

01

Server-side ownership check

Authorization is enforced for every object and never trusts the client identifier. Foreign objects must receive the same safe denial.

02

Central access policy

Role and ownership rules live in a shared layer rather than being copied across endpoints, reducing inconsistent behavior.

03

Negative tests

The client team adds cross-account, cross-role and cross-organization tests, including adjacent API methods.

04

Repeat the original scenario

After changes, we repeat the original request and nearby variants, then record closed, partially closed or still exposed.

WHAT THE CUSTOMER RECEIVES

A result package teams can act on

Not just a finding page, but connected material for decisions, remediation and closure control.

01

Executive summary

Overall risk, critical scenarios, affected processes and priorities.

02

Technical report

Validated findings with conditions, impact, evidence and guidance.

03

Finding register

Status, priority, asset and owner of the next action.

04

Evidence appendix

Safe request, response and context excerpts without unnecessary secrets.

05

Repeat-test result

Closed, partially closed or still exposed.

06

Team walkthrough

Report review, questions and clarification of technical guidance.

Discuss an assessment