Penetration testing: preparing for an assessment and understanding the report

A penetration test evaluates agreed security breach scenarios in a specific system. It helps establish the practical impact of weaknesses within time and coverage limits. Useful results require clear objectives, owner authorisation, impact control and readiness to remediate findings.

Define objectives and written scope

A public site, internal network and multi-role portal present different objectives. Record assets, permitted actions, exclusions, timing and a stop contact. Third-party services are not automatically authorised because the website integrates with them.

Agree sensitive operations and unacceptable impact separately. Testing must not create real payments or mass messages without a specific authorised scenario. Both testers and operational owners need to understand the boundaries.

Prepare access and the initial state

Define available information and required test roles. A portal benefits from accounts with different permissions and safe test data. An unauthenticated external assessment does not validate boundaries between authenticated users.

Record version, backups and recovery owners. The test environment should reflect relevant production properties, with differences documented. A backup does not authorise arbitrary destructive actions; the agreed procedure still applies.

Read the report through evidence and impact

A finding should explain conditions, impact, limitations and remediation principles. For example, a user in one organisation may access another organisation’s document. A useful report shows the broken access boundary and required check rather than merely naming a broad flaw category.

Priorities combine technical severity with business context. Restrict sensitive evidence to relevant recipients. Management needs an understandable risk and decision list; developers need enough detail to reproduce issues in an authorised environment.

Complete remediation and retesting

Assign an owner and completion criterion. Remediation should cover shared functions rather than only the demonstrated route. After changes, retest the finding and legitimate operation so protection does not block an authorised action.

The final status separates fixed, unverified and accepted exceptions. New features and configuration changes need further risk-based assessment. A penetration test provides a scoped conclusion rather than a promise of complete future security.

Sources and further reading

• NIST: planning technical security assessments
• OWASP WSTG: assessment reporting
• OWASP: penetration testing methodologies

• Related subservice: Penetration testing
• Explore this service area