Illustrative example / Inside an evidence-backed finding
See what an actionable finding looks like.
This fictional example illustrates report structure; it is not a customer result or a live exposure. The scenario concerns a publicly reachable staging administration page. Its purpose is to show how a finding supports a decision without overstating the evidence.
Anatomy of a useful finding
Observed
The staging login page is publicly reachable
Owner context
The interface was intended for internal use
Recommended action
Align the access boundary with intended use
Retest question
Does the agreed public access path remain?
This fictional example documents public reachability without claiming unauthorized access.
01 / Illustrative example
Observation: a staging administration page is public
In this illustrative scenario, a staging administration page is reachable from the public internet. The application owner confirms that the interface was intended for an internal team. The assessor records the approved asset reference, observation time, and a redacted screenshot of the login page. No credentials are attempted, and no application data or administrative session is accessed.
FIELD NOTES
- Observed: the staging login page is publicly reachable.
- Owner context: the interface was intended for internal access.
- Evidence: timestamped observation and a redacted page capture.
02 / Illustrative example
Interpretation: access exposure needs an owner decision
The public interface creates an access boundary question. Reachability alone does not prove an authentication weakness or a path to production. The owner needs to confirm the expected access model, the sensitivity of the staging environment, and whether it shares dependencies with other systems. Priority should reflect those facts and the limits of what the assessment established.
FIELD NOTES
- Confirmed: the observed access path differs from the stated intention.
- Unconfirmed: authentication strength and downstream system access.
- Decision needed: retain public access or restrict the interface.
03 / Illustrative example
Recommended action: align access with intended use
The application owner and infrastructure team review the intended users and choose an appropriate access boundary. They document the change, confirm that authorized users can still work, and record any remaining exposure accepted by the business. The recommendation addresses the observed condition; it does not assume that a particular security product or network design fits every environment.
FIELD NOTES
- Assign a named owner for the access decision and implementation.
- Record the chosen access requirement and affected environment.
- Preserve enough change context to support an independent check.
04 / Illustrative example
Retest: verify the specific condition changed
A scoped retest revisits the original public access path and compares the observed result with the agreed requirement. The record states whether the interface is still reachable and whether any check was blocked or incomplete. Closing this finding means the specific exposure was addressed within the retest scope. It does not certify the application or establish that unrelated weaknesses are absent.
FIELD NOTES
- Repeat the original observation from an agreed external position.
- Record the result, supporting evidence, and remaining limitations.
- Use a clear status such as resolved, partially resolved, or not verified.