Assume breach
Definition
Assume breach means designing as if an attacker may already have a foothold, so detection and recovery matter as much as prevention.
Also called: assume-breach
Why it matters for WordPress
Perfect prevention fails eventually: a zero-day plugin hole, a phished editor, a vendor compromise. Teams that only “lock the door” freeze when something slips through. Assume breach means you can still answer what changed, restore cleanly, and hunt persistence.
How it shows up in practice
- A staging restore drill you actually ran last quarter
- An events log that answers “who created that admin?”
- Password and salt rotation as routine after incidents, not panic theater
- A named person (or agency) who owns malware cleanup
What to do
- Practice a restore on staging before you need production heroics.
- Keep event logging and file integrity checks on.
- Write a one-page incident checklist while everyone is calm.
- After any compromise, hunt persistence. Do not only delete the weird file.
Related terms
Nearby ideas in the dictionary
- Defense in depth Defense in depth stacks multiple controls so one missed update or weak password is less likely to end in disaster.
- Event logging Event logging records security-relevant actions so you can see what changed and when.
- Backdoor A backdoor is hidden access an attacker leaves so they can return without the original vulnerability.
- Incident response Incident response is the structured process of detecting, containing, cleaning, and learning from a security incident.
- WordPress salts WordPress salts are secret keys in wp-config.php that help secure cookies, nonces, and related cryptographic operations.