The National Cybersecurity Authority has released version 2.0 of its Cloud Cybersecurity Controls Framework in early 2025, introducing three material changes that will affect how Saudi organizations procure and operate cloud services. This NCA cloud cybersecurity controls framework update establishes stricter requirements for cryptographic-key management, data-residency verification and shared-responsibility documentation that apply to organizations using or evaluating software-as-a-service, infrastructure-as-a-service and platform-as-a-service providers.
CISOs, IT procurement managers and legal counsel should understand these changes now. Existing contracts may require amendment, procurement requests for proposal will need updated security schedules, and the National Cybersecurity Authority has informally signaled a six-month transition timeline for organizations to bring cloud arrangements into compliance with the revised framework.
What the NCA Cloud Cybersecurity Controls Framework Governs
The NCA Cloud Cybersecurity Controls Framework establishes baseline security requirements for organizations in the Kingdom that use cloud computing services. It applies to government entities, critical infrastructure operators and private-sector organizations that process data subject to Saudi regulatory oversight. The framework addresses control domains including access management, encryption, logging, incident response, business continuity and data sovereignty.
Version 1.0 of the framework, in effect since 2022, provided general guidance on these domains but left significant implementation discretion to organizations and their cloud service providers. Version 2.0 tightens this discretion in three specific areas where the National Cybersecurity Authority has observed inconsistent practice or insufficient assurance.
Change One: Mandatory Customer-Managed Encryption Keys for Certain Data Classifications
The most technically significant change in version 2.0 concerns cryptographic-key management for data stored in cloud environments. The revised framework now mandates that organizations processing data classified as "Confidential" or higher under the NCA Data Classification scheme must use customer-managed encryption keys rather than provider-managed keys.
What This Means in Practice
Under the previous framework, organizations could accept a cloud provider's default encryption approach, which typically involves the provider generating, storing and managing the encryption keys that protect customer data at rest. While the data remains encrypted, the cloud provider retains technical access to the keys and therefore the ability to decrypt the data.
Version 2.0 requires that for Confidential data and above, the customer organization must generate and manage its own encryption keys using a key management service or hardware security module that the cloud provider cannot access. The cloud service may perform encryption and decryption operations using these keys, but the keys themselves remain under the customer's exclusive control. If the customer revokes access to the keys, the cloud provider cannot decrypt the data.
Which Services Are Affected
This requirement affects any cloud service that stores data classified as Confidential or higher. Common examples include:
- SaaS applications that store employee personal data, customer records or financial information
- Cloud-based databases containing intellectual property or trade secrets
- Document management systems holding contracts or strategic plans
- Backup and disaster-recovery services that replicate on-premises data to the cloud
Organizations must review their data-classification inventories and map each dataset to the cloud services that process it. Any service handling Confidential or higher data must support customer-managed encryption keys, often referred to as "bring your own key" or BYOK capability.
Procurement and Contract Implications
Many SaaS providers, particularly those offering standardized products to a global market, do not support customer-managed keys in their base service tier. BYOK capability often appears only in enterprise editions or requires additional licensing fees. Organizations evaluating new cloud services must now confirm BYOK support as a mandatory requirement in their requests for proposal, not an optional preference.
For existing contracts, organizations face three options: confirm the service already supports BYOK and implement it, negotiate an upgrade to a service tier that includes BYOK, or migrate the data to an alternative service that meets the requirement. The six-month transition timeline means these decisions must be made by mid-2025 for most organizations.
Change Two: Documentary Evidence of In-Kingdom Data Residency
The second material change addresses how organizations demonstrate compliance with data-residency requirements. Saudi regulations, including the Personal Data Protection Law and sector-specific rules from SAMA and other regulators, require certain categories of data to be stored and processed within the Kingdom's geographic boundaries.
The Previous Standard
Under version 1.0 of the framework, organizations typically satisfied residency requirements through contractual attestation: the cloud provider would state in the service agreement that data would be stored in data centers located in Saudi Arabia, and the customer would rely on this contractual commitment. Some organizations also reviewed the provider's compliance certifications or audit reports.
The New Requirement
Version 2.0 requires documentary evidence of in-Kingdom residency that goes beyond contractual language. The framework now specifies that organizations must obtain and retain:
- Technical documentation identifying the specific data-center facilities where data is stored, including physical addresses within the Kingdom
- Configuration evidence showing that data replication, backup and disaster-recovery processes do not transfer data outside Saudi Arabia
- Logs or reports demonstrating that data has not been accessed from or transferred to systems outside the Kingdom during a specified period
The National Cybersecurity Authority has clarified informally that contractual attestation remains necessary but is no longer sufficient on its own. Organizations must be able to produce technical evidence during an audit or inspection.
Practical Challenges
This requirement creates challenges for both cloud customers and providers. Many global SaaS platforms operate multi-tenant architectures where customer data may be logically separated but stored on shared infrastructure that spans multiple geographic regions. Even when a provider offers a "Saudi Arabia region," the control plane, management interfaces or metadata may reside elsewhere.
Organizations must now ask cloud providers for detailed architecture diagrams, data-flow maps and configuration screenshots that demonstrate physical and logical residency. Providers that cannot or will not furnish this documentation may not be viable for workloads subject to residency requirements.
Legal and procurement teams should update their cloud service agreements to include obligations for the provider to supply this evidence on demand and to notify the customer immediately if any change to the service architecture affects data residency.
Change Three: Shared-Responsibility Matrix Template for Every Cloud Service
The third significant change introduces a standardized template for documenting the division of security responsibilities between the cloud customer and the cloud provider.
The Shared-Responsibility Model
Cloud security operates on a shared-responsibility model: the provider secures the underlying infrastructure, while the customer secures the data, applications and access controls they deploy on that infrastructure. The precise boundary between provider and customer responsibilities varies by service model. In infrastructure-as-a-service, the customer manages more; in software-as-a-service, the provider manages more.
The New Template Requirement
Version 2.0 of the NCA Cloud Cybersecurity Controls Framework includes a shared-responsibility matrix template that maps each control domain in the framework to either the provider, the customer or both parties. Organizations must complete this template for every cloud service they use and obtain the provider's formal acknowledgment of the documented responsibilities.
The template covers domains including:
- Physical security of data centers
- Network security and segmentation
- Operating system and hypervisor patching
- Application security and vulnerability management
- Access control and identity management
- Encryption of data at rest and in transit
- Logging, monitoring and incident detection
- Backup and disaster recovery
- Compliance reporting and audit support
Why This Matters
Many security incidents in cloud environments result from misunderstandings about responsibility. A customer assumes the provider is monitoring for intrusions; the provider assumes the customer is configuring security groups correctly. The shared-responsibility matrix eliminates this ambiguity by creating a written, agreed record of who does what.
For procurement, the matrix serves as a due-diligence tool. When evaluating a new cloud service, the customer completes the template based on the provider's documentation, then asks the provider to review and countersign it. Any control domain where the provider cannot or will not accept documented responsibility becomes a risk that the customer must either accept or mitigate through compensating controls.
For existing services, organizations should complete the matrix retrospectively and seek the provider's acknowledgment. If the provider's actual responsibilities differ from what the customer assumed, the organization must either renegotiate the service terms or implement additional controls to close the gap.
The Six-Month Transition Timeline
The National Cybersecurity Authority has not published a formal compliance deadline for version 2.0 of the framework in the official release. However, informal guidance from the NCA to regulated entities indicates an expectation that organizations will achieve compliance within six months of the framework's publication in early 2025, placing the effective deadline in mid-2025 for most organizations.
This timeline is tight for organizations with large cloud portfolios. A typical financial institution or healthcare provider may use dozens of SaaS applications, multiple IaaS platforms and several PaaS services. Each requires individual assessment against the three new requirements.
Recommended Immediate Actions
CISOs and IT procurement managers should take the following steps now:
- Inventory all cloud services currently in use across the organization, including shadow IT and departmental subscriptions that may not have gone through formal procurement.
- Classify the data processed by each service according to the NCA Data Classification scheme to identify which services must support customer-managed encryption keys.
- Request BYOK capability documentation from providers of services that handle Confidential or higher data, and determine whether current service tiers include this capability.
- Request data-residency evidence from all providers, including architecture diagrams, data-flow maps and configuration documentation that demonstrates in-Kingdom storage and processing.
- Complete the shared-responsibility matrix template for each service and submit it to the provider for acknowledgment.
- Identify gaps where providers cannot meet the new requirements, and develop a remediation plan that may include service upgrades, contract amendments or migration to alternative providers.
- Update procurement templates to incorporate the three new requirements into standard requests for proposal and contract security schedules for all future cloud acquisitions.
When Organizations Need Additional Cybersecurity Capacity
Completing this assessment and remediation work within six months requires significant cybersecurity and compliance expertise. Many organizations discover they lack sufficient internal capacity to inventory services, assess technical controls, negotiate with vendors and implement changes across a large cloud portfolio simultaneously while maintaining day-to-day security operations.
Three signs indicate that an organization may benefit from additional cybersecurity talent:
The internal team is already at capacity. If your security staff are fully occupied with incident response, vulnerability management and routine compliance activities, adding a major framework-transition project will either delay the NCA work or cause other critical tasks to slip.
The organization lacks specific cloud-security expertise. Understanding customer-managed encryption key architectures, evaluating data-residency evidence and mapping shared responsibilities require specialized knowledge of cloud service models and security controls that not all generalist security professionals possess.
Procurement and legal teams need security guidance. Amending contracts, negotiating service upgrades and updating RFP templates require close collaboration between security, procurement and legal functions. Security professionals who can translate technical requirements into contract language and work effectively with commercial teams are valuable during this transition.
A good outcome from additional cybersecurity capacity looks like this: the organization completes its cloud-service inventory, assesses each service against the three new NCA requirements, identifies gaps, develops a prioritized remediation plan, implements necessary changes and updates procurement processes — all within the six-month timeline and without disrupting ongoing security operations.
How Cybersecurity Talent Services Support Framework Transitions
Organizations that need additional capacity during this transition can find, assess and place cybersecurity people for permanent hires, or bring in specialists on an outsourced basis to work on their team. This approach provides the specific expertise required for the NCA Cloud Cybersecurity Controls Framework transition without the lead time of a traditional recruitment process.
Cybersecurity talent services support organizations working with frameworks including SAMA CSF, NCA ECC, PDPL, ISO 27001, PCI DSS and SAMA CRFR, among others. Specialists placed through these services can conduct cloud-service inventories, assess technical controls, complete shared-responsibility matrices, negotiate with cloud providers and update procurement templates — the precise tasks required for NCA CCCC v2.0 compliance.
For organizations that need broader support beyond the immediate framework transition, GRC advisory services provide ongoing governance, risk and compliance expertise on call for your team, while vCISO services offer strategic cybersecurity leadership on demand aligned to your business objectives.
The six-month timeline for NCA Cloud Cybersecurity Controls Framework version 2.0 compliance is approaching quickly. Organizations that assess their current state, identify gaps and secure the necessary expertise now will meet the deadline without disruption. Those that delay will face compressed timelines, limited vendor negotiating leverage and potential compliance findings.
