Key takeaway
A penetration test exercises attacker actions within agreed boundaries; it does not guarantee that every system is secure.
Agree permission and scope in writing
Before testing, define assets, domains, IP ranges, applications and APIs, test accounts, time windows and contacts. Production load tests, social engineering, service disruption and third-party infrastructure may require separate written permission. Agree an emergency stop, data retention period and secure findings channel.
Follow the path from reconnaissance to report
A typical workflow starts with passive reconnaissance, then moves to authorized active scanning and service checks. If a weakness is confirmed, demonstrate access impact only as agreed; persistence and data extraction require a separate scope decision. Record evidence, boundaries, limitations and remediation steps. Stop and notify the owner if testing causes critical impact or reveals an out-of-scope asset.
Choose a test type for the question
A black-box test gives the tester no internal information so they investigate the environment without prior internal knowledge. A white-box test allows broader review with documentation, code and accounts; gray-box testing sits between them. External, internal, application and wireless tests have different scopes. MITRE ATT&CK tactics and techniques can shape scenarios, identify needed log sources and check detection gaps; the framework alone does not test a live environment.
Remediate findings and retest controls
For each finding, report the affected asset, reproduction conditions, evidence, business impact, priority and possible fix. Automated scans can produce false positives or miss weaknesses; validate critical findings manually. Assign an owner and date, retest the scenario after remediation and record residual risk decisions. Scanning and penetration testing use different methods; neither replaces continuous inventory and patching.