Check authorization before a penetration test
Confirm who can approve a security test, which systems are covered, and when permission ends. Use a practical authorization checklist.
Before a penetration test, confirm that the approving person has authority over the exact systems and methods in the plan. A public website, an employee's verbal agreement, or a published reporting address is not enough to establish the test boundary. Keep the approval with the engagement record, not only in a chat that the reviewer cannot later access.
This is an operational checklist. It does not determine legal authority or replace an agreement reviewed by the appropriate people. For example, RFC 9116 defines security contact information; publishing that information is not a general invitation to test.
What must the approval identify?
| Check | Evidence to retain |
|---|---|
| Authorizing party | Name, role, organization, and confirmation of authority |
| Systems | Exact applications, environments, hosts, and relevant ownership |
| Methods | Allowed activities and explicitly excluded actions |
| Accounts and data | Approved synthetic accounts and permitted data handling |
| Timing | Start, end, timezone, and any restricted periods |
| Revocation | A contact and a clear instruction for stopping work |
| Reporting | Approved recipients and a secure delivery method |
Do not infer permission for a vendor because the customer uses that vendor. A customer can often authorize tests of their own application logic without authorizing tests of the vendor's shared infrastructure. Resolve that distinction before including the dependency.
How do you handle an ambiguous request?
Write the ambiguity as a concrete question. “Does this cover everything?” is hard to answer. “May the reviewer exercise the staging export worker using the two supplied synthetic tenants?” is easier to approve or decline.
Check that the approved version matches the current plan. An older agreement may name a previous environment, team, or date. Record changes rather than silently treating them as covered. If the owner withdraws permission, stop the affected activity and preserve only the evidence permitted by the agreed handling rules.
A ticket marked approved is useful only if it resolves to the actual approval and its conditions. The reviewer must be able to inspect that record. An invented identifier or a copied summary cannot replace it.
When is the test ready to start?
Use a final readback: the reviewer states the assets, methods, window, exclusions, and stop contact. The owner confirms or corrects the summary. Check that the test accounts belong to the agreed environment and that the stop contact is reachable through the agreed channel.
If a material field is unresolved, prepare the remaining paperwork without running the test. Contact Sourced to discuss the review question and scope. An inquiry starts that discussion; it does not authorize activity against the supplied URL.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.