Security testing uses the same techniques as an attack. What separates the two is written permission. Before any test starts, two documents set the boundary: the rules of engagement, which describe how the testing will run, and the authorization letter, in which the system owner confirms that the testers may test the listed systems. At Edilec, every engagement starts with both, signed, and we test nothing outside them.
Why both documents are needed
The rules of engagement are an operating agreement between your team and the testers. The authorization letter is a short, formal statement that someone with the authority to grant permission has granted it. Testers carry the letter during the engagement; if a hosting provider, a security operations team or anyone else asks whether the activity is approved, the letter answers the question.
| Document | Main purpose | Who signs |
|---|---|---|
| Rules of engagement | How testing runs: scope, windows, methods, exclusions, contacts, data handling and reporting | The client's technical or security lead and the testing lead |
| Authorization letter | Permission to test the listed systems in the listed period | A person with authority over the systems, such as an owner, director or delegated security officer |
What the rules of engagement contain
- Scope: every target by URL, IP range, account, app build or cloud account, with anything out of scope named explicitly.
- Dates, test windows, freeze periods and how to pause testing.
- Methods allowed and not allowed, for example automated scanning limits, exploitation depth and whether phishing simulation is included.
- Exclusions that always apply at Edilec: no destructive attacks, no ransomware and no safety-critical systems.
- Data handling: what testers may view to prove a finding, how test data is stored encrypted, and when it is deleted under the contract.
- Contacts and escalation: who receives critical findings immediately, and who can stop the test.
- What happens if testers find signs of a real intrusion or a third party's weakness.
- Reporting format, delivery dates and retest terms.
What the authorization letter contains
An authorization letter is short. It should be readable in a minute by someone who has never seen the project.
- The organization granting permission and the signer's name and role.
- The testing company and the named testers, or the team, carrying out the work.
- The systems covered, or a reference to the scope in the rules of engagement.
- The start and end dates.
- A 24-hour contact who can confirm the letter is genuine.
- A statement that the signer has the authority to grant this permission.
When the systems belong to someone else
Many targets run on someone else's infrastructure: cloud providers, managed hosting, SaaS platforms and payment providers. Your authorization covers what you own and control; it cannot authorize testing of the provider itself. Major cloud providers publish their own penetration testing policies that say what customers may test without asking. Anything beyond those policies, or any system run by a partner, needs the partner's own written permission. If that permission is not available, the system stays out of scope.
Staying inside the lines during testing
Writing the boundary down is half the work; respecting it is the other half. During an Edilec engagement, testers check targets against the signed scope before testing them, keep a log of what was tested and when, and stop to ask if something is unclear. If a test could affect live operations, they stop and contact your named contact first.
| Situation during testing | What the rules say happens |
|---|---|
| A critical weakness is found | Your named contact is told immediately, not at the end |
| A system is not in the signed scope | It is not tested; the tester raises it with your technical owner |
| A test starts to affect a live service | Testing stops and the emergency contact is called |
| Signs of a real attacker appear | Testing pauses and your security lead decides the next step |
Before you sign
- Do the targets match what you actually own or are authorized to have tested?
- Is everything you do not want touched listed as an exclusion?
- Are the dates and test windows right, including time zones?
- Can every named contact be reached during the test windows?
- Do you have written permission from any third party whose systems are in scope?
- Do the data-handling and deletion terms match your own policies?
Once both documents are signed, testing can start. The scope behind them is covered in How to scope a penetration test, and the report that comes out at the end in What a useful penetration test report contains. Edilec's own approach is on the Penetration Testing and Red Team Services page.
