Checklist · Operations

Penetration test preparation

Getting a test that finds real problems, runs safely, and ends in fixes instead of a report nobody reads.

Owner: Security lead and the system ownerTime: 2 hours of preparation

0 of 17

Scope and rules

The goal is written down: what the business is afraid of, not just "test the app".
In-scope systems, addresses and accounts are listed, and what is out of scope is listed too.
Rules of engagement cover testing hours, forbidden techniques (denial of service, social engineering), and data handling.
A signed authorisation from the system owner exists, and the cloud or hosting provider's testing rules were checked.
Third-party systems the target depends on have their owners' permission, or are excluded.

The test runs against production or a production-like copy; whichever it is, the difference is understood.
Test accounts exist at each role level (user, manager, administrator, another tenant).
A fresh backup exists, and a rollback is available if the test damages data.
The tester has an emergency contact available during the test, and a way to stop immediately.

The SOC or monitoring provider knows the testing window and addresses, or it is deliberately kept blind and a contact can deconflict.
Support and operations know whom to call if an alert looks real.
Testers sign a confidentiality agreement, and reports are exchanged over encrypted channels.

The report format and severity scale are agreed before the start.
Each finding has a reproducible description, evidence and a recommended fix.
A debrief with the tester happens within a week, and critical findings are reported as soon as they are found.
Findings are ticketed with an owner and a fix date, and the retest is scheduled.
Fixes are retested by the tester, and the result is attached to the original finding.

Adjust it to your environment before relying on it. A finished list shows a routine was followed; it does not guarantee nothing was missed.

14 dni za darmo. Bez karty kredytowej. Chmura lub on-premises.