Does Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 cover 3GPP 5G Security Architecture (TS 33.501)?

37% of 3GPP 5G Security Architecture (TS 33.501) you already have

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 already covers about 37% of 3GPP 5G Security Architecture (TS 33.501), leaving 27 of 43 controls as genuinely new work.

Already covered 0 Likely covered 16 New work 27

No control in Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 maps directly to one in 3GPP 5G Security Architecture (TS 33.501). 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 Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 reaches these. This is the list to scope.

33.501-10

Security for Interworking with EPS

33.501-11

Security Aspects of IMS

33.501-13.1

Service-Based Architecture Security (TLS)

33.501-13.2

Network Function Service Authorization (OAuth 2.0)

33.501-15

Steering of Roaming Security

33.501-16

Security for User Plane Integrity Protection

33.501-17

Privacy and Pseudonymization

33.501-4.2

Security Domains and Trust Model

33.501-5.1

Subscription Permanent Identifier Protection

33.501-6.2

Key Hierarchy

33.501-6.4

NAS Security

33.501-6.5

AS Security (RRC and User Plane)

33.501-6.7

Security Mode Command Procedures

33.501-9

Security for Non-3GPP Access

33.501-Annex-D

Cryptographic Algorithms

33.501-OAM

Management Plane Security

TS33.501-4.1

5G Security Architecture Overview

TS33.501-4.2

Security Feature Groups

TS33.501-4.3

Security Domains and Stratum

TS33.501-4.4

Network Functions in the Security Architecture

TS33.501-6.2

Key Hierarchy and Derivation

TS33.501-6.4

NAS Security

TS33.501-6.5

AS Security and PDCP Protection

TS33.501-6.7

Security Key Hierarchy

TS33.501-6.8

Security in Handover

TS33.501-7.1

Untrusted Non-3GPP Access Security

TS33.501-7.3

Wireline Access Security

Show the 16 you already have

33.501-13.4

SEPP and Inter-PLMN Security (N32)

33.501-14

Network Slicing Security

33.501-6.1

Primary Authentication (5G AKA / EAP-AKA')

33.501-8

Security Aspects of UDM/UDR

TS33.501-13.1

NF Registration and Discovery Security

TS33.501-13.2

NF Service Authorization

TS33.501-13.3

N32 Interconnect Security

TS33.501-13.4

OAuth 2.0 Authorization Framework

TS33.501-14.1

Security for Network Slicing

TS33.501-14.2

Security for Edge Computing

TS33.501-14.3

Security for URLLC Services

TS33.501-14.4

Security for IAB

TS33.501-6.1

Authentication Framework

TS33.501-6.3

EAP-AKA' Authentication

TS33.501-6.6

AS Security

TS33.501-7.2

Security Visibility and Configurability

How this is calculated

Already covered means a mapping runs from a control in Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 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