Framework overlap

Does MDS2 (Medical Device) cover Azure Security Benchmark?

You hold MDS2 (Medical Device) and have been told to do Azure Security Benchmark. Here is how much overlaps, control by control.

39% of Azure Security Benchmark you already have

MDS2 (Medical Device) already covers about 39% of Azure Security Benchmark, leaving 33 of 54 controls as genuinely new work.

Already covered 7 Likely covered 14 New work 33

What is genuinely new work

Nothing in MDS2 (Medical Device) reaches these. This is the list to scope.

AM-2
Use Only Approved Services
AM-3
Ensure Security of Asset Lifecycle Management
ASB-09
Federation and single sign-on
ASB-10
API security and access tokens
ASB-15
Secure data deletion in cloud
ASB-18
Cloud workload protection
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
DP-3
Encrypt Sensitive Data in Transit
DP-4
Encrypt Data at Rest by Default
DS-6
Enforce Security of Workload Throughout DevOps Lifecycle
ES-1
Use Endpoint Detection and Response (EDR)
ES-2
Use Modern Anti-Malware Software
GS-1
Align Organisation Roles, Responsibilities and Accountabilities
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-3
Enable Logging for Investigation
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 21 you already have
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-21
Cloud security monitoring and logging
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-11
Data classification for cloud
ASB-16
Virtual network segmentation
ASB-17
Container and serverless security
ASB-19
Image and template hardening
ASB-20
Cloud configuration management
ASB-22
Incident response in cloud
ASB-23
Cloud vulnerability management
ASB-24
Cloud change management
DS-2
Ensure Inventory of Software Components in Code

How this is calculated

Already covered means a mapping runs from a control in MDS2 (Medical Device) 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