Authorization comes before curiosity
Use security-testing skills only on systems you own, purpose-built training platforms, certification exam environments, or systems for which the owner has given explicit permission. Public accessibility is not permission. Finding a service on the internet, knowing its address, or suspecting a weakness does not authorize testing.
When another organization owns the system, authorization should identify who approved the activity, the exact assets, permitted actions, dates, communication channels, data-handling rules, and stop conditions. If any part is unclear, stop and ask the owner.
Use environments designed for learning
The safest starting points are provider-hosted labs, capture-the-flag environments with published rules, local virtual machines intentionally built for training, and isolated networks you control. Follow each platform's terms and remain inside the assigned targets.
Do not reuse training activity against school, employer, customer, home-neighbour, or public infrastructure. A technique demonstrated in a lab remains restricted to the lab unless a separate written authorization explicitly covers another environment.
Define scope so it can be checked
List exact hostnames, addresses, applications, accounts, or lab identifiers that are included.
Record the start, end, maintenance windows, and any periods when activity must pause.
State what categories of testing are permitted and what actions are prohibited.
Define what information may be accessed, stored, copied, reported, and deleted.
Know who can answer a scope question and who must receive an urgent incident report.
Pause for instability, unexpected real data, third-party assets, unclear ownership, or any safety concern.
Protect the lab and the surrounding network
Keep local training systems isolated from personal, school, and work devices. Use provider instructions for network configuration. Take snapshots where appropriate, keep software updated on the host system, and avoid placing real credentials or personal data inside intentionally vulnerable machines.
Do not expose a vulnerable training image directly to the public internet. Shut down or remove temporary lab resources when practice ends. If a lab behaves unexpectedly or appears connected to real third-party infrastructure, stop before investigating further.
Treat data minimization as a technical control
Collect only what is needed to demonstrate the authorized learning objective. Prefer synthetic data. Never publish credentials, access tokens, personal information, private lab content, exam material, or proprietary course content. Store notes securely and delete sensitive artifacts according to the platform or engagement rules.
Screenshots and reports can create risk even when the activity was authorized. Review them for secrets, identifiers, and out-of-scope information before sharing.
Keep an activity record
A professional record should show the scope reference, date, lab or target identifier, purpose, high-level actions, observations, evidence location, and cleanup completed. This makes learning reproducible and helps distinguish authorized practice from unexplained activity.
If you discover an unexpected issue in a real product, do not expand the investigation. Preserve minimal evidence, stop, and follow the vendor's published vulnerability disclosure policy or an appropriate coordinated-disclosure channel.
A five-question pause check
- Do I own this system or have explicit permission from the owner?
- Is this exact asset and action inside the written scope?
- Could the activity affect another person, service, or network?
- Am I handling only the minimum data required?
- Would I be comfortable showing my authorization and notes to the owner?
If any answer is no or uncertain, stop. Professional security work rewards restraint and clear escalation.
Further responsible-practice references
For organizational programs, review the CISA Vulnerability Disclosure Policy Template and NIST SP 800-115. Always follow the specific platform or system owner's current rules.