Ethical Security Testing
Beginner 16 min read Ethical Security Testing

Authorization and Rules of Engagement

Before any packet flies: why written authorization, clear scope, and Rules of Engagement are not paperwork but the ethical and legal foundation of all testing.

rules of engagementscopeauthorizationlegalbug bountyresponsible disclosure
Introduction

What is this?

Rules of Engagement (RoE) is the written, signed agreement defining exactly what may be tested, when, with which techniques, and what is off-limits — the boundary that makes a test legal and ethical.

Motivation

Why do you need it?

  • Testing without authorization is a crime in nearly every jurisdiction — scope is what separates a pentester from an intruder.
  • A signed RoE protects you AND the client: both sides know the blast radius and the stops.
  • Every professional engagement (bug bounty, offensive lab) rests on a scope contract; it is the professional habit.
Think about it

Mental model

Imagine

A demolition permit

Think of

The map of which walls are load-bearing

The permit authorizes the work; the map tells you which bricks you may actually knock out.

Mechanics

How it works

  • The statement of work names targets, IP ranges, domains, time window, and testing methods.
  • RoE adds constraints: no social engineering, no data exfiltration, do-not-test lists, emergency contacts.
  • Special clauses cover data handling: masks, retention, and what to do when you stumble on real PII or a live incident.
  • A breach of scope voids the authorization instantly — stopping and reporting is always the right move.

Anatomy of a scope contract

Targets
Window
Methods
Limits
Sign-off
Real world

In production

  • A retailer's RoE bans any test touching the payment network; the tester discovers a do-not-touch list and honors it.
  • A bug-bounty scope file lists exactly the *.example.com assets in-scope and excludes everything else.
  • A pentest contract includes an emergency-stop contact and a 24h notification rule for discovered live incidents.
Guidelines

Best practices

  • Document scope in writing, dated, with the exact assets and time windows — 'you said it on a call' is not scope.
  • Keep the RoE on hand during the test; reassess whenever a new target appears.
  • Stipulate that accidental damage and surprise discoveries are reportable, not coverable.
  • Do a pre-engagement scoping call: the client's 'of course' often hides the do-not-test list.
Watch out

Common mistakes

  • Starting to test from a sneaky 'security research' reading of a generic statement.
  • Including production systems in scope without naming them explicitly in the RoE.
  • Testing 'just this one more host' because it looks related — scope creep voids the badge.
  • Sharing client findings, screenshots, or data outside the engagement without permission.
When things break

Debugging tips

  • When a target is ambiguous, treat the unclear case as OUT of scope and write a question to the client.
  • Keep a scope-checklist; tick it per asset before touching anything.
  • Store the RoE with your evidence pack so a regulator or court can read the boundary.
Security

Security considerations

  • Ethics and legality converge here: never test hosts you do not own or are not contracted to test.
  • If you discover a live breach mid-test, follow the RoE's emergency pathway and preserve evidence — do not 'help' by changing things.
Interviews

Interview checkpoint

Practice

Hands-on lab

Draft Your Own Rules of Engagement and Stand Up a Lab
40 min · beginner
In progress
Objectives
  • Write a scope document for a lab you will test.
  • Name targets, window, methods, and do-not-test items.
  • Deploy a local target and map it to the scope.

Draft Your Own Rules of Engagement and Stand Up a Lab

40 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The scope agreement's purpose in testing is...

2

You discover a live incident mid-test. Correct move:

Go deeper

Official documentation