Framework overlap

Does OCC Heightened Standards (12 CFR Part 30, Appendix D) cover AWS Well-Architected Security Pillar?

You hold OCC Heightened Standards (12 CFR Part 30, Appendix D) and have been told to do AWS Well-Architected Security Pillar. Here is how much overlaps, control by control.

21% of AWS Well-Architected Security Pillar you already have

OCC Heightened Standards (12 CFR Part 30, Appendix D) already covers about 21% of AWS Well-Architected Security Pillar, leaving 70 of 89 controls as genuinely new work.

Already covered 1 Likely covered 18 New work 70

What is genuinely new work

Nothing in OCC Heightened Standards (12 CFR Part 30, Appendix D) reaches these. This is the list to scope.

AWS-WA-09
Federation and single sign-on
AWS-WA-10
API security and access tokens
AWS-WA-13
Data residency and sovereignty
AWS-WA-17
Container and serverless security
AWS-WA-18
Cloud workload protection
AWS-WA-25
Service level agreement management
SEC01-BP01
Separate workloads using accounts
SEC01-BP02
Secure account root user and properties
SEC01-BP03
Identify and validate control objectives
SEC01-BP04
Stay up to date with security threats and recommendations
SEC01-BP06
Automate testing and validation of security controls
SEC01-BP07
Identify threats and prioritize mitigations using a threat model
SEC02-BP01
Use strong sign-in mechanisms
SEC02-BP02
Use temporary credentials
SEC02-BP03
Store and use secrets securely
SEC02-BP04
Rely on a centralized identity provider
SEC02-BP05
Audit and rotate credentials periodically
SEC02-BP06
Employ user groups and attributes
SEC03-BP01
Define access requirements
SEC03-BP02
Grant least privilege access
SEC03-BP03
Establish emergency access process
SEC03-BP04
Reduce permissions continuously
SEC03-BP05
Define permission guardrails for your organization
SEC03-BP06
Manage access based on lifecycle
SEC03-BP07
Analyze public and cross-account access
SEC03-BP08
Share resources securely within your organization
SEC03-BP09
Share resources securely with a third party
SEC04-BP01
Configure service and application logging
SEC04-BP02
Capture logs, findings, and metrics in standardized locations
SEC04-BP03
Correlate and enrich security alerts
SEC04-BP04
Initiate remediation for non-compliant resources
SEC04-BP05
Implement actionable security events
SEC05-BP01
Create network layers
SEC05-BP02
Control traffic at all layers
SEC05-BP03
Implement inspection-based protection
SEC05-BP04
Automate network protection
SEC06-BP01
Perform vulnerability management
SEC06-BP02
Reduce attack surface
SEC06-BP03
Implement managed services
SEC06-BP04
Automate compute protection
SEC06-BP05
Enable people to perform actions at a distance
SEC06-BP06
Validate software integrity
SEC07-BP01
Identify the data within your workload
SEC07-BP02
Define data protection controls
SEC07-BP03
Automate identification and classification
SEC07-BP04
Define data lifecycle management
SEC08-BP01
Implement secure key management
SEC08-BP02
Enforce encryption at rest
SEC08-BP03
Automate data at rest protection
SEC08-BP04
Enforce access control
SEC09-BP01
Implement secure key and certificate management
SEC09-BP02
Enforce encryption in transit
SEC09-BP03
Automate detection of unintended data access
SEC09-BP04
Authenticate network communications
SEC10-BP01
Identify key personnel and external resources
SEC10-BP02
Develop incident management plans
SEC10-BP03
Prepare forensic capabilities
SEC10-BP04
Automate containment capability
SEC10-BP05
Identify forensic and incident response tools
SEC10-BP06
Pre-deploy tools
SEC10-BP07
Run simulations
SEC10-BP08
Establish a framework for learning from incidents
SEC11-BP01
Train for application security
SEC11-BP02
Automate testing throughout the development and release lifecycle
SEC11-BP03
Perform regular penetration testing
SEC11-BP04
Conduct code reviews
SEC11-BP05
Centralize services for packages and dependencies
SEC11-BP06
Deploy software programmatically
SEC11-BP07
Regularly assess security properties of the pipelines
SEC11-BP08
Build a program that embeds security ownership in workload teams
Show the 19 you already have
AWS-WA-01
Shared responsibility model definition
AWS-WA-02
Cloud security policy and strategy
AWS-WA-03
Cloud risk assessment
AWS-WA-04
Regulatory compliance for cloud services
AWS-WA-05
Cloud security roles and responsibilities
AWS-WA-06
Cloud identity management
AWS-WA-07
Multi-factor authentication for cloud
AWS-WA-08
Privileged access in cloud environments
AWS-WA-11
Data classification for cloud
AWS-WA-12
Encryption of cloud-stored data
AWS-WA-14
Data backup and recovery in cloud
AWS-WA-15
Secure data deletion in cloud
AWS-WA-16
Virtual network segmentation
AWS-WA-19
Image and template hardening
AWS-WA-20
Cloud configuration management
AWS-WA-21
Cloud security monitoring and logging
AWS-WA-22
Incident response in cloud
AWS-WA-23
Cloud vulnerability management
AWS-WA-24
Cloud change management

How this is calculated

Already covered means a mapping runs from a control in OCC Heightened Standards (12 CFR Part 30, Appendix D) to that control. Likely covered means no direct mapping exists but both frameworks map to the same control in a third standard. New work means neither. We keep those separate rather than adding them into one friendlier number, because blending them would present a two-hop inference as a verified fact.

Coverage is not symmetric. Run it the other way and you will get a different number; both are correct.

From 332,959 cross-framework control mappings across 723 frameworks, 531 of them verified against their source documents. It does not tell you that you are compliant: a mapped control means the two standards ask for the same thing, not that you have done it.

Try another pair ยท Today's edition