Framework overlap

Does ASIC Cyber Resilience Good Practices cover Azure Security Benchmark?

You hold ASIC Cyber Resilience Good Practices and have been told to do Azure Security Benchmark. Here is how much overlaps, control by control.

30% of Azure Security Benchmark you already have

ASIC Cyber Resilience Good Practices already covers about 30% of Azure Security Benchmark, leaving 38 of 54 controls as genuinely new work.

Already covered 0 Likely covered 16 New work 38

No control in ASIC Cyber Resilience Good Practices maps directly to one in Azure Security Benchmark. Everything counted as covered is covered because both map to the same third standard, which is what a crosswalk is, but it is an inference rather than a lookup.

What is genuinely new work

Nothing in ASIC Cyber Resilience Good Practices reaches these. This is the list to scope.

AM-3
Ensure Security of Asset Lifecycle Management
ASB-01
Shared responsibility model definition
ASB-02
Cloud security policy and strategy
ASB-04
Regulatory compliance for cloud services
ASB-05
Cloud security roles and responsibilities
ASB-06
Cloud identity management
ASB-09
Federation and single sign-on
ASB-10
API security and access tokens
ASB-11
Data classification for cloud
ASB-15
Secure data deletion in cloud
ASB-17
Container and serverless security
ASB-18
Cloud workload protection
ASB-21
Cloud security monitoring and logging
ASB-24
Cloud change management
ASB-25
Service level agreement management
BR-1
Ensure Regular Automated Backups
BR-2
Protect Backup and Recovery Data
DP-2
Monitor Anomalies and Threats Targeting Sensitive Data
DS-2
Ensure Inventory of Software Components in Code
DS-6
Enforce Security of Workload Throughout DevOps Lifecycle
ES-1
Use Endpoint Detection and Response (EDR)
ES-2
Use Modern Anti-Malware Software
IM-1
Use Centralised Identity and Authentication System
IM-3
Manage Application Identities Securely
IM-4
Authenticate Server and Services
IM-6
Use Strong Authentication Controls
IM-7
Restrict Resource Access Based on Conditions
LT-4
Enable Network Logging for Investigation
LT-5
Centralise Security Log Management and Analysis
NS-1
Establish Network Segmentation Boundaries
NS-2
Secure Cloud Services with Network Controls
NS-3
Deploy Firewall at Edge of Enterprise Network
NS-5
Deploy DDoS Protection
PA-1
Separate and Limit Highly Privileged Users
PA-2
Avoid Standing Access for User Accounts and Permissions
PA-3
Manage Lifecycle of Identities and Entitlements
PV-2
Audit and Enforce Secure Configurations
PV-5
Perform Vulnerability Assessments
Show the 16 you already have
AM-2
Use Only Approved Services
ASB-03
Cloud risk assessment
ASB-07
Multi-factor authentication for cloud
ASB-08
Privileged access in cloud environments
ASB-12
Encryption of cloud-stored data
ASB-13
Data residency and sovereignty
ASB-14
Data backup and recovery in cloud
ASB-16
Virtual network segmentation
ASB-19
Image and template hardening
ASB-20
Cloud configuration management
ASB-22
Incident response in cloud
ASB-23
Cloud vulnerability management
DP-3
Encrypt Sensitive Data in Transit
DP-4
Encrypt Data at Rest by Default
GS-1
Align Organisation Roles, Responsibilities and Accountabilities
LT-3
Enable Logging for Investigation

How this is calculated

Already covered means a mapping runs from a control in ASIC Cyber Resilience Good Practices 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