Framework overlap

Does Azure Security Benchmark cover IEEE 1686?

You hold Azure Security Benchmark and have been told to do IEEE 1686. Here is how much overlaps, control by control.

86% of IEEE 1686 you already have

Azure Security Benchmark already covers about 86% of IEEE 1686, leaving 1 of 7 controls as genuinely new work.

Already covered 5 Likely covered 1 New work 1

What is genuinely new work

Nothing in Azure Security Benchmark reaches these. This is the list to scope.

IEEE1686-Section5.4-Communications-PortAccess-EncryptedRemote-Crypto
IEEE 1686 Section 5.4 - Communication Port Access + Encrypted Remote + Cryptography + Ports and Services + IEC 61850 + IEC 60870-5 + DNP3 SAv5
Show the 6 you already have
IEEE1686-IR-Recovery-Reporting-Exercises-Drills-RECOV
IEEE 1686 - Incident Response + Recovery from Failed Update + Reporting to Authorities + Coordination with Sector-Specific Agencies + Exercises and Drills
IEEE1686-Scope-IED-Substation-Automation-2022-IEC-NERC-NIST-Coord
IEEE 1686 - Scope + Intelligent Electronic Devices (IEDs) + Substation Automation + 2022 Edition + Coordination with IEC 62351 + IEC 62443 + NERC CIP + NIST SP 800-82
IEEE1686-Section5.1-AccessControl-Accounts-Roles-Password-Session-Remote
IEEE 1686 Section 5.1 - Electronic Access Account Management + Roles + Password + Failed Login + Session + Remote Access + Personnel
IEEE1686-Section5.2-5.3-AuditLog-Retention-Export-Monitoring
IEEE 1686 Section 5.2 + 5.3 - Audit Trail Records + Retention + Export + Supervisory Monitoring and Control + Network Security Monitoring
IEEE1686-Section5.5-5.6-5.7-5.8-Firmware-ConfigSW-TimeSync-DataAtRest
IEEE 1686 Section 5.5-5.8 - Firmware Quality + Configuration Software Security + Time Synchronisation + Data Protection at Rest + Patch + Malware + Hardening + Vulnerability
IEEE1686-SupplyChain-Documentation-Procurement-ComplianceTable-Physical
IEEE 1686 Section 6 IED Security Documentation + Supply Chain + Procurement Specification + Appendix A Compliance Table + Physical and Tamper

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