An ethical hacking assessment begins with an agreement about what can be tested, by whom, and under which conditions. Technical skill does not replace that agreement. A tester can perform a technically interesting action that produces no useful evidence or creates an avoidable incident if the target, timing, and limits are unclear. Rules of engagement turn a broad request to check security into a controlled assessment.
This guide uses a fictional training application owned by a small software team. It explains how a beginner can prepare a scope document and practise working within it. The example is an educational planning exercise, not legal advice or permission to assess a third-party system. Obtain explicit written authorization from the responsible owner before conducting a real assessment.
Describe the business objective
Begin with the reason for the assessment. The fictional team wants to know whether students can view another student’s practice submissions or use features reserved for instructors. That objective is more useful than find every vulnerability. It narrows the testing questions and helps the owner decide whether the evidence answers the original concern.
Record the intended audience for the report. Developers need reproducible observations, while the business owner needs an explanation of impact and priorities. The scope should support both without promising complete security. Every assessment is limited by the environment, accounts, time, methods, and information available during the agreed window.
Identify assets precisely
List the permitted application hostname, environment, APIs, and relevant account roles. Distinguish a staging application from production even when they look similar. Record who owns each asset and whether shared infrastructure or external services are involved. A company account on a third-party platform does not automatically grant permission to test the platform itself.
Use explicit exclusions as well as inclusions. The fictional assessment might include the local training portal and its test API while excluding payment services, email providers, and employee devices. If an application links to an unlisted domain, treat that as a boundary to clarify rather than an invitation to expand the assessment.
Define accounts and test data
Create dedicated test accounts representing the relevant roles. For the training application, use two student accounts and one instructor account with synthetic records. Record which account owns each object. This makes permission expectations clear and avoids using private customer information merely to demonstrate a security weakness.
Agree who can create, reset, and remove the accounts. Set a recovery process for lockouts and expired sessions. The team should also decide how test records are identified so they can be removed later. A scope document is incomplete if it allows testing but leaves account cleanup and data restoration undefined.
Set permitted methods and limits
Describe the allowed checks at a level that the owner can understand. Examples include reviewing application behaviour with supplied accounts, checking server-side permission enforcement on synthetic records, and examining configuration exposed by the test environment. Record whether automated tools are allowed and under which rate or concurrency limits.
Also identify methods outside the agreement. Availability testing, social engineering, credential guessing, and destructive changes should not be assumed to be included in a routine application review. If additional techniques become relevant, document a revised agreement before using them. A general statement about security testing is not a substitute for defined boundaries.
Agree on a schedule and communication path
Record dates, time zones, working hours, and maintenance periods. A test that is harmless during a quiet staging window may interfere with a demonstration or a scheduled data import. Give the tester a primary contact and a backup contact who can clarify unexpected conditions or pause the assessment.
Use a communication channel appropriate for sensitive findings. Avoid posting account tokens, private screenshots, or raw request logs into broad group chats. For urgent issues, agree on a short notification containing the affected asset, observed risk, and recommended immediate action, with detailed evidence delivered through the protected channel.
Define stop conditions
Stop conditions should be observable. Examples include unexpected production traffic, access to real personal data, signs of instability, unexplained account changes, or discovery that an asset belongs to another organisation. Define who may resume testing and what evidence is required before continuing. This prevents a tester from improvising under pressure.
A pause is not a failed assessment. It is a controlled response to uncertainty. Record the time, the observation, what was stopped, and the person contacted. That record helps distinguish test activity from unrelated operational events and gives the owner a factual basis for the next decision.
Plan evidence handling
Collect the minimum evidence needed to reproduce a finding. Synthetic object identifiers, response status, timestamps, and a short explanation may be sufficient. Redact tokens, passwords, and unnecessary personal information. A screenshot that proves a point should not expose unrelated records simply because they happened to be on screen.
Define where evidence is stored, who can access it, and when it will be removed. Keep originals protected and create sanitised copies for reports or portfolios. Do not assume that authorization to perform an assessment also permits public disclosure of the application’s details or publication of the final report.
Specify deliverables and acceptance
Useful deliverables include the tested scope, account-role matrix, findings, evidence references, limitations, and recommended fixes. Each finding should identify an expected rule and the observed behaviour. Avoid promising a particular number of vulnerabilities: a careful assessment may find no issue in the permitted paths and should still document what was checked.
Agree whether retesting is included and how it will be scheduled. A repair review should refer to the original finding and the new application version. Define what counts as fixed, partially fixed, or not reproduced. Without these terms, a team may confuse the absence of one symptom with resolution of the underlying problem.
Worked scope example
For the fictional portal, the agreed question is whether two supplied student accounts are isolated from each other. The permitted environment is a local training instance with synthetic submissions. The allowed actions are viewing and attempting routine edits through supplied accounts. Bulk enumeration, deletion, external services, and production access are excluded.
The owner provides a role matrix, an instructor account, a reset procedure, and a contact available during the session. Testing stops if real data or an unexpected external destination appears. The report includes expected and actual access results for selected synthetic records. This narrow exercise is sufficient to practise disciplined assessment without inventing a broad commercial engagement.
Beginner review exercise
Write a one-page rules-of-engagement document for the portal. Give it to a classmate and ask them to identify whether an API on another hostname is included, whether records may be deleted, and who should be contacted after an unexpected response. If they must guess, the document needs clarification.
Then add a change request for a new test scenario. State the reason, additional asset, permitted actions, risk, and revised timing. This demonstrates that scope is controlled throughout the work, not merely signed once and ignored. Keep both versions so the decision history is visible.
Frequently asked questions
Is verbal permission sufficient for a portfolio project?
Use your own isolated lab or a training environment with explicit published rules. For another person’s system, obtain clear written authorization and scope. A portfolio should not depend on an ambiguous conversation about permission.
What if a serious issue appears outside the scope?
Stop the out-of-scope activity, preserve minimal appropriate evidence, and contact the agreed owner. Do not expand testing merely to determine how serious the issue might become.
Should the final report include every request?
No. Include enough evidence to support and reproduce the findings within the permitted environment. Keep unnecessary sensitive data and noisy raw logs out of the main report.
Reference: OWASP Web Security Testing Guide.