Set stop conditions before security testing starts
Define when a reviewer must pause, who receives the alert, and what evidence is safe to retain. Avoid improvised decisions during a test.
A security test needs a stop rule before it needs a clever test case. Decide what happens when the application becomes unstable, private data appears, permission becomes unclear, or the owner withdraws approval. A useful stop rule names both the trigger and the next action.
Keep the rules available to every reviewer and operator. An automated tool should not continue because the person who knows the rules stepped away. This suggested procedure turns the agreed review boundaries into explicit operational decisions.
Which conditions should trigger a pause?
| Trigger | Immediate action | Resume condition |
|---|---|---|
| Unexpected sensitive data | Stop collection and protect minimal evidence | Owner agrees on handling and next step |
| Availability degradation | Stop affected traffic and notify the owner | Health restored and activity reapproved |
| Unknown asset or vendor | Do not follow the new target | Ownership and exact permission confirmed |
| Permission withdrawn | Stop covered work | New authorization, if any |
| Unexpected paid action | Stop the workflow | Owner confirms a safe test destination |
| Missing audit record | Stop actions that require that record | Recording restored and state reconciled |
Agree on concrete health signals with the system owner. Do not invent a universal error-rate threshold for every application. A rare but expensive workflow may need different bounds from a read-only staging endpoint.
What evidence should you keep?
Retain the minimum permitted record that explains why work stopped. This may include the time, test identity label, asset, action, and a redacted error. Do not copy a large response containing private records simply because it may be useful later.
The OWASP logging guidance discusses excluding sensitive values from logs. Apply that discipline to incident notes and screenshots as well as application logs.
Preserve the sequence of events. Do not rerun a dangerous action to obtain a cleaner screenshot. A partial record with an honest limitation is preferable to creating additional harm.
Who decides whether work resumes?
Name a customer contact and a reviewer responsible for the decision. Record what changed, which action is now allowed, and any revised bounds. A successful health check alone does not resolve a permission or data-handling problem.
If the owner cannot be reached, remain paused for the affected work. Continue only independent tasks that remain within the agreed scope and do not worsen the situation.
Discuss a bounded review with Sourced before testing begins. Clear stop conditions protect both the customer and the quality of the evidence.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.