NCA CCC — Cloud Cybersecurity Controls — How to Comply for SaaS and IaaS

Overview

The NCA Cloud Cybersecurity Controls (CCC-1:2020) regulate every use of cloud computing in the Kingdom — whether by government, semi-government or critical-private-sector entities, and whether the cloud is operated locally or abroad. CCC is complementary to ECC, not a replacement: anyone subject to ECC who consumes cloud must also comply with CCC, and the cloud service provider (CSP) must hold a Saudi-licensed cloud operator status from the CST.

Who this applies to

• Cloud Service Tenants (CST-T) — every public-sector body, every critical-sector private operator, and any entity that hosts Saudi data in the cloud.
• Cloud Service Providers (CST-P) — hyperscalers and local providers offering services into KSA.
• Exempt: purely personal/consumer use, and SaaS that holds no organisational data.

Key control domains

CCC organises 37 controls into four domains, each split by tenant (T) and provider (P) responsibility:

1. Cybersecurity Governance (1-x): cloud strategy, contracts, exit, risk.
2. Cybersecurity Defense (2-x): identity federation, data classification, encryption, segregation, vulnerability management.
3. Cybersecurity Resilience (3-x): backups outside the cloud, business continuity, contingency.
4. Third-Party Cybersecurity (4-x): sub-processors, provider assurance.

Step 1: Decide the deployment model

CCC distinguishes four cloud usage classifications by data classification:

| Data class | Public cloud allowed | Private cloud allowed | Hybrid allowed | |---|---|---|---| | Top Secret | No | Yes (in-Kingdom only) | No | | Secret | No | Yes (in-Kingdom only) | Restricted | | Restricted | Conditional, in-Kingdom only | Yes | Yes | | Public | Yes | Yes | Yes |

Step 2: Tenant-side controls

Identity federation (CCC 2-2-T-1): SSO from your local IdP (Azure AD / Okta / Keycloak) using SAML 2.0 or OIDC. Disable any local cloud-console accounts except a break-glass kept in a sealed vault.

Encryption (CCC 2-4-T-1): data-at-rest using customer-managed keys (CMKs); the CSP must never have unilateral access to plaintext.

# AWS KMS sample: customer-managed key with deny statement preventing CSP root access
KeyPolicy:
  Version: '2012-10-17'
  Statement:
    - Sid: AllowTenantAdmin
      Effect: Allow
      Principal: { AWS: 'arn:aws:iam::123456789012:role/SkyTenantAdmin' }
      Action: 'kms:*'
      Resource: '*'
    - Sid: DenyDataAccessFromOutsideKSA
      Effect: Deny
      Principal: '*'
      Action: ['kms:Decrypt', 'kms:GenerateDataKey']
      Resource: '*'
      Condition:
        StringNotEquals: { 'aws:RequestedRegion': 'me-central-1' }

Data residency (CCC 2-3-T-1): enforce region pinning in IaC and as a service control policy. Block account-wide use of non-KSA regions.

Step 3: Provider-side requirements

The CSP must demonstrate:

• CST cloud-operator licence (Class A/B/C as applicable).
• Local technical support in Arabic during business hours.
• Sub-processor list disclosed and updated within 30 days of any change.
• Right-to-audit clauses including the NCA itself.
• Annual SOC 2 Type II + an ISO 27017 / ISO 27018 certificate.

Step 4: Contractual / exit (CCC 1-3-T-1)

The cloud contract must include:

• Data deletion certificate within 30 days of contract termination.
• Exit clause: tenant can extract all data in non-proprietary formats within 90 days.
• Sub-processor change notification: 60 days minimum.
• Incident notification: within 6 hours of detection.

Step 5: Logging and SIEM (CCC 2-9-T-1)

Ship every CloudTrail / Activity Log / Audit Log to a SIEM inside KSA. Retention minimum 12 months hot + 24 months cold.

aws cloudtrail create-trail \
  --name skyline-ksa-audit \
  --s3-bucket-name skyline-cloudtrail-ksa \
  --is-multi-region-trail \
  --include-global-service-events \
  --kms-key-id alias/skyline-cmk
aws cloudtrail put-event-selectors --trail-name skyline-ksa-audit \
  --event-selectors 'ReadWriteType=All,IncludeManagementEvents=true,DataResources=[{Type=AWS::S3::Object,Values=[arn:aws:s3:::]}]'

Common gotchas

• Tenant assumes CSP encrypts by default — CCC requires CMK with tenant-only access, not provider-managed keys.
• Default IAM role allows cross-region read of secrets — block via SCP.
• Storage bucket in a non-KSA region for "backup convenience" — automatic finding.
• Forgetting that even logs may carry Restricted data — encrypt and pin the SIEM in-Kingdom.

Verification — audit-ready evidence

• Cloud Use Justification document approved by the CISO.
• Data Classification Matrix mapping every bucket / dataset / DB.
• IaC repository showing region-pinning and SCP.
• Encryption inventory: KMS key, rotation cadence, owner.
• Annual cloud-provider assurance report.
• Disaster recovery test executed in the last 6 months, with evidence.

Conclusion

CCC is the legal bridge between Saudi data sovereignty and the elasticity of cloud. Treat the control matrix as your operating contract; let your CSP show how they meet provider-side controls, and you show how you meet tenant-side controls.

Related guides

• NCA ECC v2 — Full Compliance Guide
• SAMA Cloud Computing Rulebook
• PDPL Cross-Border Data Transfer Rules