Governance & Compliance

TL;DR

• Compliance requires continuous, dated evidence mapped to a named standard (PCI-DSS, HIPAA, SOC 2) — “we follow best practices” is not auditable evidence.
• AWS Config is the foundation: it retains historical configuration/compliance state, so it can answer “was this compliant for the past 6 months,” not just “is it compliant right now.”
• Audit Manager maps Config (and other) findings against named frameworks and packages them for audit review — it doesn’t add new detection, it organizes existing signal.
• Tag policies report non-compliance; they do not prevent non-compliant resource creation. Preventive enforcement requires SCPs or an equivalent deny control.
• Backup coverage should be enforced centrally via an org-wide AWS Backup policy — per-team diligence predictably leaves gaps, typically discovered during an actual recovery attempt.

Core Concepts

AWS Config — historical compliance evidence

AWS Config does not merely check current state; it maintains a historical configuration and compliance timeline against defined rules. When an auditor asks “prove this bucket has been encrypted for the past 6 months,” a current-state console screenshot does not answer that question — only Config’s retained history does. The distinction between a point-in-time check and continuous historical evidence is the central concept in this domain: current-state tools (a console view, a one-off CLI check) prove nothing about the past, and evidence collected only at audit time cannot retroactively prove continuous compliance.

Audit Manager — evidence aggregation for named frameworks

Audit Manager consumes AWS Config data (and other sources) and maps findings against pre-built or custom compliance frameworks — PCI-DSS, HIPAA, SOC 2, and others — organizing raw compliance signal into an audit-ready evidence package. It adds no new detection capability on its own; its value is turning scattered compliance data into something reviewable efficiently, which matters most when the alternative is manually assembling evidence under deadline pressure before an audit.

Organizations — where guardrails get enforced

Organizations (detailed in the landing zone module) is the enforcement layer at scale: SCPs set the permission ceiling, OUs provide the blast-radius boundary within which those controls apply.

Tag policies — reporting versus enforcement

Tag policies define expected tagging across an Organization, but a tag policy alone only reports non-compliance — it does not prevent a resource from being created without a required tag. Actual preventive enforcement requires an SCP condition (or equivalent control) that denies resource creation missing required tags. An org can have a tag policy defined, assume it is enforcing tagging, and later discover during a cost allocation exercise that a meaningful percentage of resources are still untagged — the policy reported the gap the entire time, but nothing closed the loop with real enforcement.

Backup policies — centralized versus per-team coverage

Backup policies, managed centrally through AWS Backup’s policy-based management in Organizations, address a common failure mode: relying on each team to remember to configure backups for its own resources predictably leaves gaps. Those gaps are typically discovered during an actual recovery attempt — the worst possible time to learn a critical database was never in a backup plan. An org-wide backup policy mandates coverage for specific resource types centrally, removing dependency on every team independently getting this right.

Security standards — mapping to a named framework

Treating security as a compliance practice means selecting the specific named standard the organization is actually accountable to (PCI-DSS for payment data, HIPAA for healthcare, a specific regulatory framework for financial services) and mapping actual controls against it explicitly. Security Hub’s standards support provides continuous scoring against a named framework, which is a materially stronger evidentiary position than an unmapped claim of “we’re secure.”

Common Pitfalls

• Pitfall: Assuming a tag policy enforces tagging. Why: tag policies only report non-compliance; they do not block resource creation. Fix: pair the tag policy with an SCP condition (or equivalent) that denies creation of resources missing required tags.
• Pitfall: Backup coverage relying on individual team diligence. Why: gaps are invisible until an actual recovery attempt fails. Fix: enforce backup coverage centrally via an org-wide AWS Backup policy.
• Pitfall: AWS Config enabled too recently before an audit. Why: Config’s evidentiary value depends on retained history — a short history cannot cover a 6-month compliance window. Fix: enable Config organization-wide well ahead of any anticipated audit window.
• Pitfall: Offering “we follow best practices” as compliance evidence. Why: auditors require controls mapped against a specific named standard, not a general claim. Fix: map controls explicitly to the applicable named framework and produce continuous evidence.
• Pitfall: Assembling audit evidence manually and reactively each cycle. Why: this is slow, error-prone, and creates deadline pressure. Fix: use Audit Manager (or an equivalent practice) to keep evidence continuously assembled.

Interview Questions

• “An auditor wants proof that encryption has been enforced for the last 6 months, not just today. What do you show them, and why doesn’t a current console screenshot suffice?” — tests whether Config’s historical evidence role is genuinely understood.
• “A tag policy exists, but 30% of resources are still missing the required tag. What’s actually broken, and how do you fix it?” — tests whether reporting-only versus preventive enforcement is a real, applied distinction.
• “Design backup governance for an organization where individual teams have been inconsistently configuring their own backups.” — tests whether a centralized, policy-based approach is the instinct over relying on team-level diligence.
• “What does Audit Manager add on top of raw AWS Config compliance data?” — tests understanding of evidence aggregation versus new detection capability.
• “Why is ‘we follow AWS security best practices’ an insufficient answer in a compliance-driven design review?” — tests whether the difference between security posture and auditable compliance is understood.