6. Data Protection (18%)

Data is ultimately what attackers are after — credentials, customer PII, financial records, intellectual property. Every other security domain exists to protect data: IAM controls who can access it, infrastructure controls where it can flow, detection watches for unauthorized access, and incident response contains breaches when they occur. Without data protection, all those layers are just decorating an open vault. Think of data protection as the last line of defense: if every other control fails and an attacker reaches your data, encryption ensures they get ciphertext instead of plaintext, integrity mechanisms ensure they can't silently modify it, and lifecycle controls ensure sensitive data isn't lingering in forgotten buckets. What makes data protection on AWS uniquely complex? Data exists in two states (in transit and at rest), each requiring different encryption mechanisms. Additionally, key management creates its own security challenge — the encryption is only as strong as the protection of the keys.

The First Principle is that data protection must cover both states (in transit and at rest), be enforced by default through automation (not manual configuration), and maintain the confidentiality, integrity, and availability of data even if all other security layers are compromised.

Scenario: A compliance audit discovers that an S3 bucket containing customer PII was encrypted with SSE-S3 (AWS-managed keys) instead of customer-managed KMS keys. The organization can't demonstrate who accessed the encryption keys or when. How does this gap affect audit compliance?

Reflection Question: Why does the choice of encryption key management (SSE-S3 vs. SSE-KMS vs. SSE-C) matter beyond just "the data is encrypted"?