When a SAMA-regulated institution evaluates a cloud service provider, the assessment often begins and ends with a certificate. ISO 27001, SOC 2, CSA STAR—these frameworks confirm that a provider maintains certain processes, but they do not confirm the specific configurations your institution will inherit. NCA cloud cybersecurity controls compliance demands more. The National Cybersecurity Authority's Cloud Cybersecurity Controls framework, particularly controls 2-2-1 through 2-2-5, requires you to verify precise identity and access management settings before you migrate a single workload or sign a contract.
This article describes the five configuration categories these controls address, the questions your CSP questionnaire must ask, and the evidence you should receive in writing. It is written for CISOs and cloud governance leads at SAMA-regulated institutions who are responsible for third-party cloud risk and NCA compliance.
Why Certifications Are Not Configurations
A cloud service provider may hold multiple international certifications and still operate configurations that conflict with NCA requirements. A certificate confirms that the provider has documented policies and undergoes periodic audits. It does not confirm that multi-factor authentication is enforced on every privileged account, that session logs are retained for the duration the NCA specifies, or that encryption keys remain under your institution's control.
SAMA-regulated institutions are accountable for the data and systems they place in the cloud. The NCA Cloud Cybersecurity Controls framework assigns specific obligations to the cloud customer, and many of those obligations depend on the provider's baseline configuration. If the provider's default settings do not meet NCA requirements, your institution must either negotiate contractual changes, implement compensating controls, or accept residual risk that may not be acceptable under SAMA's supervisory expectations.
The five controls addressed here—2-2-1 through 2-2-5—cover identity and access management, multi-factor authentication, privileged access management, logging and monitoring, and encryption and key management. Together, they form the technical foundation of your shared-responsibility model. Verifying them in advance is not optional; it is the only way to ensure NCA cloud cybersecurity controls compliance from day one.
Control 2-2-1: Identity and Access Management
The NCA requires that access to cloud resources is granted based on the principle of least privilege, that user identities are uniquely assigned, and that access rights are reviewed regularly. Your CSP questionnaire must verify the following configurations:
- Does the provider enforce unique user accounts for every individual, or are shared accounts permitted by default?
- What is the provider's process for provisioning and deprovisioning user access, and can it integrate with your institution's identity provider via SAML or OpenID Connect?
- Are role-based access controls available, and can you define custom roles that align with your internal segregation-of-duties requirements?
- Does the provider support automated access reviews, and can you export access logs for periodic recertification?
Request written confirmation of these capabilities and ask for sample configuration screenshots or policy excerpts. If the provider's platform does not support automated recertification, you will need to build that process internally, and that effort should be reflected in your migration timeline and budget.
Control 2-2-2: Multi-Factor Authentication
The NCA mandates multi-factor authentication for access to systems that process or store sensitive data. For cloud environments, this extends to administrative consoles, API access, and any interface that can modify configurations or access customer data. Your questionnaire must ask:
- Is MFA enforced by default on all administrative accounts, or is it optional?
- Which MFA methods does the provider support—time-based one-time passwords, hardware tokens, biometrics, push notifications?
- Can MFA be enforced programmatically via policy, so that no administrator can disable it for their own account?
- Does the provider log MFA events, including successful and failed authentication attempts, and are those logs available to you in real time?
If the provider's MFA is optional, you must negotiate a contract amendment that makes it mandatory for all accounts with access to your institution's data. If the provider supports MFA but does not enforce it by policy, you will need to implement a monitoring control that alerts you when MFA is disabled on any account.
Control 2-2-3: Privileged Access Management
Privileged accounts—those with the ability to create, modify or delete resources, change security settings, or access encryption keys—represent the highest risk in any cloud environment. The NCA requires that privileged access is tightly controlled, monitored and audited. Your CSP questionnaire must verify:
- Does the provider offer a separate privileged access management solution, or are privileged accounts managed in the same directory as standard users?
- Can privileged sessions be recorded and retained for audit purposes?
- Does the provider support just-in-time access, where privileged permissions are granted only for a defined period and automatically revoked?
- Are privileged accounts subject to additional authentication requirements, such as approval workflows or time-of-day restrictions?
Ask for evidence that the provider's own administrators are subject to the same controls. If the provider's support staff can access your environment without your knowledge or approval, that access must be logged, time-limited and subject to your institution's incident-response procedures.
Control 2-2-4: Logging and Monitoring
The NCA requires that all access to cloud resources is logged, that logs are protected from tampering, and that they are retained for a period sufficient to support investigations and regulatory inquiries. SAMA expects institutions to retain logs for at least one year, and in some cases longer. Your questionnaire must ask:
- What events does the provider log by default—authentication, authorization, configuration changes, data access, API calls?
- Are logs immutable, or can an administrator with sufficient privileges delete or modify them?
- How long does the provider retain logs, and can you configure a longer retention period if required?
- Can logs be exported in real time to your institution's SIEM or log management platform?
- Does the provider offer alerting based on log events, and can you define custom alert rules?
Request a sample log export and verify that it includes the fields you need for correlation and analysis. If the provider's default retention period is shorter than your regulatory obligation, confirm that extended retention is available and understand the cost.
Control 2-2-5: Encryption and Key Management
The NCA requires that sensitive data is encrypted at rest and in transit, and that encryption keys are managed in a way that prevents unauthorized access. For SAMA-regulated institutions, this often means that keys must remain under the institution's control, not the provider's. Your questionnaire must verify:
- Is encryption enabled by default for all storage services, or must it be configured manually?
- Does the provider support customer-managed keys, and can those keys be stored in a hardware security module that you control?
- Can you rotate keys without downtime, and does the provider log all key usage and administrative actions?
- Is data encrypted in transit between all components of the provider's infrastructure, and which protocols and cipher suites are used?
Ask for written confirmation that the provider cannot access your encryption keys and that any request for key access by the provider's support staff requires your explicit approval. If the provider manages keys on your behalf, understand the process for key recovery in the event of a disaster and confirm that it aligns with your business continuity plan.
Building the Shared-Responsibility Matrix
Once you have verified these five configuration categories, you must document the division of responsibility between your institution and the provider. The NCA expects this to be explicit. For each control, identify which party is responsible for implementation, monitoring and evidence collection.
For example, the provider may be responsible for enabling MFA on the platform, but your institution is responsible for enforcing MFA policy on all user accounts you create. The provider may log API calls, but your institution is responsible for monitoring those logs and responding to anomalies. The provider may offer encryption, but your institution is responsible for managing the keys.
This matrix becomes the foundation of your cloud security policy and the basis for internal audit and NCA supervisory reviews. It must be agreed in writing before migration begins.
When to Conduct This Verification
This verification should occur during the vendor selection phase, before you sign a contract or begin any proof-of-concept work. If you are already using a cloud service provider and have not completed this exercise, it is time to do so now. SAMA's supervisory expectations and the NCA's enforcement activity are both increasing, and retroactive compliance is more costly and disruptive than getting it right from the start.
Signs that this work is overdue include:
- Your institution has migrated workloads to the cloud without a documented shared-responsibility matrix.
- Your internal audit team has raised findings related to cloud access controls or logging.
- You cannot answer basic questions about who has privileged access to your cloud environment or how long logs are retained.
- Your CSP contract includes generic security language but no specific configuration commitments.
A good outcome is a written agreement with your provider that specifies the exact configurations required by NCA controls 2-2-1 through 2-2-5, a shared-responsibility matrix that assigns accountability for each control, and a baseline configuration standard that your institution will enforce on every cloud workload.
How Cloud & Application Security Engagements Address This
Cloud environments assessed against NCA controls provide the verification process described in this article. The engagement produces a cloud security assessment report that documents the provider's configurations against each relevant NCA control, a shared-responsibility matrix that defines accountability, and cloud security policy and baseline configuration standards that your institution can enforce going forward.
Data residency and approvals are addressed before migration, and the shared-responsibility model is defined for each service you intend to use. The engagement typically requires four to eight weeks, depending on the number of providers and services in scope. Major public cloud platforms and local cloud service providers are both covered, assessed against the NCA controls and the provider's own security model.
The deliverables include a remediation roadmap that prioritizes any gaps identified during the assessment and assigns responsibility for closure. This roadmap becomes the basis for your migration plan and your ongoing compliance monitoring.
Closing
NCA cloud cybersecurity controls compliance is not achieved by collecting certificates. It is achieved by verifying specific configurations, documenting shared responsibilities, and holding your provider accountable for the commitments they make. Controls 2-2-1 through 2-2-5 define the identity and access management baseline every SAMA-regulated institution must verify before moving to the cloud.
If your institution is evaluating a cloud service provider, auditing an existing provider relationship, or preparing for an NCA supervisory review, the Cloud & Application Security service provides the assessment, documentation and roadmap you need. The engagement is structured to deliver clarity on shared responsibilities, evidence of NCA compliance, and a practical path forward.
