Penetration test
A scoped, authorized attempt by hired security testers to break into your system, followed by evidence, fixes, and a retest.
See it
What it is
A penetration test is a time-boxed, authorized attempt to exploit your system. Testers combine tools with human judgment, chain small weaknesses, and deliver evidence, impact, and fixes. Unlike a scanner report, the useful question is not only 'does this look suspicious?' but 'could we actually cross the boundary?'
Reach for one before a high-risk launch, after a major architecture change, or when a customer or compliance program needs independent evidence. A good engagement starts with written scope and rules of engagement, includes test accounts for each role, and ends with a retest of the fixes.
A pentest report is not a certificate. A test covers the hosts, roles, code, and dates in scope, not every future release. Cheap engagements can also be little more than an automated scan with a logo on top. Ask for manual authorization testing, safe proof of impact, reproducible steps, and a retest, and never let testing begin without explicit permission.
Ask AI for it
Create a penetration-test engagement pack for [AUTHORIZED TARGET] using the OWASP Web Security Testing Guide. Write the scope as exact hostnames, APIs, mobile builds, roles, and excluded third parties; define test dates, source IPs, emergency contacts, stop conditions, data-handling rules, and prohibited destructive actions. Require manual tests for authentication, authorization, tenant isolation, business logic, uploads, webhooks, and server-side request forgery, with Burp Suite request and response evidence. Provide a finding template with reproducible steps, impact, CVSS v4.0 vector, fix guidance, and proof from the retest. Do not test any asset until its owner has signed the authorization.