Why good intentions are insufficient
A test can change system state, increase load or reveal data unrelated to its purpose. Being able to run a command establishes capability. Permission depends on an authorized owner, the asset boundary and the agreed method.
Here, ethical hacking means using evidence to improve security within explicit authorization and constraints. A public website, a shared company name or a previous relationship does not supply missing permission. Real engagements must also confirm applicable local requirements and organizational processes.
Further reading: NIST SP 800-115: Security Testing and Assessment
Turn scope into decisions you can check
Record asset identifiers, allowed and prohibited methods, time windows, test accounts, data handling, contacts and stop conditions. Rules of Engagement (ROE) connect these agreements to operational decisions. Permission to inspect a staging site’s headers can coexist with a prohibition on load testing.
Authorization needs a change process. If staging redirects to a new domain, retain only the necessary non-sensitive observation, stop that action and check with the named contact. An automatic redirect does not place the new asset inside scope.
Further reading: NIST SP 800-115: Security Testing and Assessment
Make the decision reconstructable
Record the purpose, time, asset, method, observation and next action. Retain only what is needed to support the finding. If possible personal data appears, follow stop-and-report rules instead of downloading more to demonstrate impact.
A credible record can say: a redirect was received; the destination was not tested; scope confirmation is pending. That is a clear evidence boundary. Work that was not performed cannot be described as verified safe.
Example: staging redirects to a payment service
A team authorizes HTTP response-header checks on lab.example.test from 14:00 to 15:00 and prohibits payments or high request volumes. At 14:20, the response redirects to pay.example.test.
The observed fact is a redirect from the original site. Ownership, authorization and data handling at the destination remain unknown. Similar names do not resolve those unknowns. Record the source, time and destination, then ask the named contact to confirm scope.
Conclusion: Stop following the redirect. Do not send test requests to the new site until scope is explicitly extended.
Tabletop exercise: write a minimal ROE
Use only the fictional scenario and a text editor. Do not connect to any target; no scanner installation is needed.
- Create three columns: allowed, prohibited and needs confirmation. The only target is lab.example.test, the only action is reading headers, and the window is 14:00–15:00.
- Classify five actions: read headers at 14:10; load-test at 14:30; test again at 15:10; follow a redirect to a new domain; contact the named owner after an anomaly.
- Add stop conditions for suspected sensitive data or service disruption, plus a rule to retain only necessary evidence.
Expected result
Header reading at 14:10 and contacting the owner are allowed. Load testing and testing after the window are prohibited. The new domain requires confirmation before testing.
Check your work
Could another person classify all five actions the same way using your rules? Clarify any target or method they still have to guess.
Finish and clean up
Save the fictional ROE as your learning artifact. No accounts, network connections or system state require cleanup.