PSPM Architecture: Objectives and Rules

Understanding how PSPM platforms organize prevention helps explain how they discover controls, assess coverage, and generate recommendations. This architectural foundation consists of Objectives, Rules, and Layers.

PSPM platforms organize prevention around two core concepts:

Prevention Objectives

Objectives are prevention goals - what you're trying to accomplish. Examples: "Require encryption for EBS volumes," "Prevent public S3 buckets," "Restrict usage to approved AWS regions."

Objectives are cloud-agnostic and focus on security intent rather than implementation mechanism. The same objective (prevent public data exposure) might be achieved through organization policies, secure defaults, IaC scanning, or runtime remediation - or all four.

Each objective has:

• Category - Logical grouping like Data Governance, Trust & Sharing, Network Perimeter, Audit & Logging, Identity & Access, Core Infrastructure, or Feature Restrictions
• Priority - Relative importance from P1 (essential, foundational) to P5 (optimization and hygiene)
• Resource types - Which cloud services this objective applies to (S3 buckets, EC2 instances, RDS databases, etc.)

Objectives provide the "what" of prevention. They describe security goals independent of implementation approach.

Prevention Rules

Rules are discovered preventive controls that achieve objectives. While objectives describe what you're trying to accomplish, rules define how it's being achieved.

Examples of rules:

• An AWS SCP statement denying ec2:CreateVolume without encryption
• An Azure Policy denying public blob access
• A GCP Organization Policy restricting VM external IP addresses
• A Terraform scanning rule flagging unrestricted security groups
• An AWS Config rule auto-remediating public S3 buckets
• A default encryption setting for EBS volumes

Each rule:

• Maps to one or more objectives it achieves
• Exists at exactly one prevention layer (Build, Access, Config, or Runtime)
• Has a scope showing where it applies (accounts, regions, organizational units)
• Receives a quality assessment based on how effectively it achieves its objectives

Defense in Depth Through Multiple Rules

A single objective might be achieved through rules at multiple layers. "Prevent public S3 buckets" might have:

• Build layer: IaC scanning rule blocking public bucket configurations
• Access layer: SCP denying s3:PutBucketPolicy that allows public access
• Config layer: S3 Public Access Block enabled by default
• Runtime layer: Auto-remediation removing public access within minutes

This overlapping coverage means issues that bypass one layer get caught by others - true defense in depth.

PSPM Recommendations

PSPM platforms generate recommendations - specific actions to improve prevention posture:

Rule deployment recommendations suggest new preventive controls to deploy. "Deploy an SCP to block public S3 buckets in production accounts." "Enable default EBS encryption across all AWS accounts."

Coverage expansion recommendations identify where to extend existing controls. "Apply encryption SCP to development accounts (currently only enforced in production)."

Rule improvement recommendations suggest strengthening existing controls. "Upgrade Azure Policy from audit to deny effect."

Layer expansion recommendations encourage defense in depth. "You have runtime remediation for public buckets. Add access-layer SCP to prevent public buckets at deployment."

Recommendations are prioritized based on impact, effort, finding reduction, and risk severity - transforming prevention from guesswork into data-driven deployment roadmaps.