The authorization checklist every engagement starts with
The authorization checklist every engagement starts with
Scope, owner, exclusions, stop conditions, and data-handling rules — signed before any operator touches a system. Here is the full checklist and why each line matters.
What 'authorized' means in practice
Authorization is not a checkbox that moves a project forward — it is the boundary that keeps offensive work legal, safe, and reviewable. In Uganda, the Computer Misuse Act (2011) and NITA-U guidance set the frame, but a sound engagement goes further.
Every BeeraSafe engagement starts with a signed document covering each line below. Nothing starts before it is signed.
The checklist
- Owner: the named individual who authorizes the work and has the authority to do so
- Scope: the specific systems, code, identities, and data in scope
- Exclusions: what is explicitly out of bounds
- Time window: when the activity may run, including a start and end
- Rate and impact limits: how much load is acceptable
- Emergency contact: who to reach, at any hour
- Data-handling rules: what may be collected and where it may live
- Stop conditions: what halts the engagement immediately
Why each line earns its place
The scope prevents a test from drifting into systems the owner did not mean to include. The time window makes logs meaningful — a finding outside the window is a different question. The emergency contact is what keeps a remediation reproducible instead of heroic. The stop condition converts a running test into a reversible action.
If any of these are unknown, the right output is a plan — an engagement proposal — not activity. Authorization first is not paperwork for its own sake; it is the reason we can run tests other teams cannot, and defend every one of them.
Bottom line
A written, scoped, signed authorization is the difference between a penetration test and an intrusion. We do not begin before every line on this checklist is agreed.