Penetration testing investigates whether selected security weaknesses can be demonstrated within an explicitly authorized scope. The engagement needs written rules, system-owner permission, impact limits and an emergency stop contact. Zoha scopes application-focused security work around validated evidence, clear reporting and remediation, with no assumption that a time-bounded test proves permanent security.
Updated
On this page
State what the test should establish
A useful brief identifies the decision the test will inform: releasing a portal, reviewing an important application change or examining a suspected weakness. It names the application, user roles and business functions in scope. This is more specific than asking a supplier to 'test everything'.
Agree whether the work starts with limited external knowledge, authenticated access, relevant design information or code. Different approaches provide different evidence and coverage. A more restricted view is not automatically more realistic or more thorough; choose the access model that answers the business question.
Approve the rules of engagement
| Rule | Decision needed | Reason |
|---|---|---|
| Authority | Named owner and written permission | Public availability does not authorize testing. |
| Boundaries | Domains, environments, accounts and third parties | Connected services may belong to another organization. |
| Impact | Permitted methods and excluded activities | Business availability and information must be protected. |
| Communication | Test window and stop contact | Unexpected effects need an immediate decision route. |
| Evidence | Collection, storage, recipients and removal | Findings can contain sensitive system information. |
| Closure | Cleanup, reporting, fixes and retesting | Test accounts and unresolved issues need an owner. |
Only authorized parties should approve changes to these rules. If an unexpected system or sensitive record appears, the response should follow the agreed escalation route rather than silently expanding the test.
Keep demonstrations proportionate to the purpose
A finding needs enough evidence to establish the observed weakness and its consequence. It does not require collecting unnecessary customer information or causing avoidable disruption. Use suitable test accounts and records where possible and agree the handling of production evidence.
For a hypothetical authorization issue, the report might show that an account could reach a restricted function belonging to another role. The evidence should establish that control failure within the approved test conditions. Detailed technical material belongs in the restricted report for the people authorized to repair it, not in a public marketing example.
Ask for both decision and repair information
- An executive summary tied to the tested business service and important risks.
- The scope, dates, access model, exclusions and practical limitations.
- Validated findings with affected functions, evidence and remediation guidance.
- A distinction between demonstrated issues and observations needing further work.
- A prioritized action list with ownership to be agreed by the customer.
- An agreed method for verifying important repairs.
A severity label should have a rationale. Your application context may change the priority of a technically similar issue, particularly where restricted records or sensitive actions are involved. The report should give your team enough context to make that decision.
Plan the repair and retest before work starts
Testing is most useful when the responsible developers have time and authority to act on the results. Agree whether remediation is included, how changes will be reviewed and which environment will be retested. A retest should record what changed and which original findings were verified.
OWASP ASVS can help define relevant application requirements, but a reference to it is not a claim that every possible weakness has been found. The final record should preserve scope and limitations. Further releases, account changes and supplier changes can alter the security position after the engagement ends.