What it means
Every security decision rests on assumptions: an identity provider is trustworthy, a network segment is isolated, backups cannot be altered, users control their devices, a vendor will notify the organization of incidents, or an attacker lacks a particular capability. Unstated assumptions become invisible dependencies.
How it works
Threat modeling and architecture review document assumptions, connect them to evidence and controls, assign owners, and define triggers for revalidation. High-consequence assumptions may need independent verification or a design that remains safe when the assumption fails.
A recovery plan assumes the primary identity system will be available during a ransomware incident. If identity is also compromised, administrators may be unable to access backups. Recording the assumption exposes the need for protected emergency credentials and an independent recovery path.
Practical focus
- Write assumptions in testable language
- Identify what fails if each assumption is wrong
- Assign evidence, owner, review date, and invalidation trigger
- Reduce dependence on assumptions with large consequences
Common mistakes
- Treating architecture diagrams as proof of actual isolation
- Assuming vendor or cloud responsibilities without checking contracts and configuration
- Leaving temporary assumptions in place after a project ends
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: