Authorization, scope and ethics

The techniques of a penetration tester and an attacker overlap. What differs is written authorization, an agreed scope and a duty to minimize harm.

rules of engagement documentscope and authorization letterbug bounty platformscoordinated disclosure policies (security.txt)engagement trackerdeconfliction contacts

Authorization comes first

Testing a system you do not own, or beyond what its owner allowed, can be illegal in most jurisdictions, regardless of your intent. Laws differ by country and can be strict, so this is not legal advice: confirm with counsel. The professional rule is simple. Never test anything without explicit, written permission from someone with the authority to give it, and never go beyond what that permission covers.

Written authorization from the asset owner (for third-party hosting or cloud, also check the provider's testing policy).
A defined scope: which systems, addresses, applications and accounts are in, and which are explicitly out.
A time window and a way to stop: when testing may happen and who can halt it immediately.
A named contact on the client side who can be reached if something goes wrong.

Rules of engagement

The (RoE) turn permission into practical limits. Agree on them before the first packet.

rules-of-engagement.ymlyaml

engagement: Q4 external web and API assessment
authorized_by: "CISO, Example Corp (signed letter attached)"
window: { start: 2026-11-02T08:00:00Z, end: 2026-11-13T20:00:00Z, hours: "business days only" }
in_scope:
  - https://app.example.com
  - https://api.example.com/v2/*
  - test accounts: [tester-a@example.com, tester-b@example.com]
out_of_scope:
  - production payment processor (third party)
  - denial-of-service testing
  - social engineering of employees
constraints:
  - no data exfiltration beyond proof of access (one record, redacted)
  - rate limit scans to 10 requests per second
  - stop and call the contact if production degradation is observed
emergency_contact: "+55 11 5555-0100 (24h SOC)"
reporting: "critical findings reported within 24 hours; final report in 10 business days"

Ethical principles

Minimize harm: prove the issue with the least access needed. Do not read, copy or keep real customer data you do not need.
Protect what you find: findings and any data touched are confidential, stored encrypted and deleted at the end as agreed.
Be honest in the report: do not exaggerate or hide anything, including your own mistakes (for example, a test that caused an outage).
Stop at the boundary: if a path leads outside scope, ask for permission instead of continuing.
Prefer safe proof: demonstrate impact with a harmless marker or a read of a test record, not with destructive actions.

Bug bounties and disclosure

A bug bounty program publishes a scope and rules and invites researchers to test within them, often with rewards; the program's terms are your authorization, and straying outside them removes it. When you find a vulnerability on a system outside any program, report it responsibly through the owner's disclosure channel (a security.txt file, a security@ address or a policy), give reasonable time to fix, and do not exploit it further or publish details early.

Rules of engagementRoEThe agreed document that turns permission into practical limits: scope, time window, forbidden actions, rate, emergency contacts and how findings are reported.see in glossary →Coordinated disclosureresponsible disclosureReporting a vulnerability privately to its owner and allowing reasonable time to fix before any public detail.see in glossary →

connections on the map

Authorization, scope and ethicsboundsPenetration testing methodology

updated on 14/10/2026 · sources to go deeper · report an error

Unlocks

test what you learned

Loading questions…