PSPM Architecture: The Four Prevention Layers
Each rule (from the previous chapter) exists at exactly one prevention layer. Understanding these layers helps explain how PSPM tracks coverage and identifies where overlapping controls create defense in depth.
Each rule exists at exactly one of four prevention layers representing when and where in the deployment lifecycle prevention operates:
Build Layer - Catch problems before launch. IaC scanning and CI/CD pipeline policies stop misconfigurations before deployment. Build-layer prevention is highest value (catches issues earliest) but typically has incomplete coverage (only scans what's in code).
Access Layer - Control who can do what. Organization policies (AWS SCPs, Azure Policy, GCP Organization Policy) block risky actions at the API level. Access-layer prevention is most powerful (can't be bypassed by resource owners) and has broadest coverage.
Config Layer - Secure defaults everywhere. Account and service settings make resources safe by default. Config-layer prevention is invisible to developers (just works automatically) but may have limited scope (only covers defaults, not all configurations).
Runtime Layer - Auto-fix in real time. Continuous monitoring catches drift and remediates automatically. Runtime prevention is the safety net (catches issues that bypass other layers) but has longest exposure window (issues exist briefly before remediation).
PSPM platforms track prevention coverage across all four layers, identifying where multiple rules create overlapping protection and where gaps leave risks unaddressed.