17% of ISO 27701:2019 you already have
Azure Security Benchmark already covers about 17% of ISO 27701:2019, leaving
108 of 130 controls as genuinely new work.
Already covered 0
Likely covered 22
New work 108
No control in Azure Security Benchmark
maps directly to one in ISO 27701:2019. 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 Azure Security Benchmark reaches these. This is the list to scope.
4.1Structure of this document
4.2Application of ISO/IEC 27001:2013 requirements
4.3Application of ISO/IEC 27002:2013 guidelines
5.2Context of the organization
5.2.2Understanding the needs and expectations of interested parties
5.2.3Determining the scope of the information security management system
5.3.1Leadership and commitment
5.3.3Organizational roles, responsibilities and authorities
5.5.5Documented information
5.7Performance evaluation
5.7.1Monitoring, measurement, analysis and evaluation
5.8.1Nonconformity and corrective action
5.8.2Continual improvement
6.10.2Information transfer
6.11.1Security requirements of information systems
6.11.2Security in development and support processes
6.12Supplier relationships
6.12.1Information security in supplier 0d0997ee1127/iso-iec-27701-2019 relationships
6.12.2Supplier service delivery management
6.13.1Management of information security incidents and improvements
6.14Information security aspects of business continuity management
6.15.1Compliance with legal and contractual requirements
6.2.1Management direction for information security
6.3Organization of information security
6.3.1Internal organization
6.3.2Mobile devices and teleworking
6.4Human resource security
6.4.3Termination and change of employment
6.5.1Responsibility for assets
6.6.1Business requirements of access control
6.6.3User responsibilities
6.6.4System and application access control
6.7.1Cryptographic controls
6.8Physical and environmental security
6.9.1Operational procedures and responsibilities
6.9.2Protection from malware
6.9.5Control of operational software
6.9.7Information systems audit considerations
7.2Conditions for collection and processing
7.2.1Identify and document purpose
7.2.2Identify lawful basis
7.2.3Determine when and how consent is to be obtained
7.2.4Obtain and record consent
7.2.5Privacy impact assessment
7.2.6Contracts with PII processors
7.2.7Joint PII controller
7.2.8Records related to processing PII
7.3Obligations to PII principals
7.3.1Determining and fulfilling obligations to PII principals
7.3.10Automated decision making
7.3.2Determining information for PII principals
7.3.3Providing information to PII principals
7.3.4Providing mechanism to modify or withdraw consent
7.3.5Providing mechanism to object to PII processing
7.3.6Access, correction and/or erasure
7.3.7PII controllers' obligations to inform third parties
7.3.8Providing copy of PII processed
7.4.3Accuracy and quality
7.4.4PII minimization objectives
7.4.5PII de-identification and deletion at the end of processing
7.4.9PII transmission controls
7.5PII sharing, transfer, and disclosure
7.5.1Identify basis for PII transfer between jurisdictions
7.5.2Countries and international organizations to which PII can be transferred
7.5.3Records of transfer of PII
7.5.4Records of PII disclosure to third parties
8.2Conditions for collection and processing
8.2.2Organization’s purposes
8.2.4Infringing instruction
8.2.6Records related to processing PII
8.3.1Obligations to PII principals
8.4.2Return, transfer or disposal of PII
8.4.3PII transmission controls
8.5PII sharing, transfer, and disclosure
8.5.1Basis for PII transfer between jurisdictions
8.5.2Countries and international organizations to which PII can be transferred
8.5.3Records of PII disclosure to third parties
8.5.4Notification of PII disclosure requests
8.5.5Legally binding PII disclosures
8.5.6Disclosure of subcontractors used to process PII
8.5.7Engagement of a subcontractor to process PII
8.5.8Change of subcontractor to process PII
Show the 22 you already have
5.2.1Understanding the organization and its context
5.2.4Information security management system
5.4.1Actions to address risks and opportunities
5.6.1Operational planning and control
5.6.2Information security risk assessment
5.6.3Information security risk treatment
6.10Communications security
6.10.1Network security management
6.13Information security incident management
6.14.1Information security continuity
6.15.2Information security reviews
6.2Information security policies
6.5.2Information classification
6.6.2User access management
6.9.4Logging and monitoring
6.9.6Technical vulnerability management
7.4Privacy by design and privacy by default
8.4Privacy by design and privacy by default
How this is calculated
Already covered means a mapping runs from a control in Azure Security Benchmark 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