Saudi Arabia CSCC-1 compliance: what the audit won't catch
Geert WarmenbolApril 29, 2026
Key takeaways
CSCC-1 audits at maturity level 2 do not require live testing of controls -- environments can pass while carrying exploitable authentication bypasses and incomplete asset inventories.
SMS-based OTP implementations satisfy CSCC-1 control 3.2.1 on paper but frequently carry known bypass vulnerabilities that automated scans do not surface.
Ephemeral cloud resources -- serverless functions, auto-scaled instances, short-lived containers -- are routinely absent from CMDB-based asset inventories that CSCC-1 control 3.1.1 audits accept as evidence.
Third-party risk programs built on initial vendor questionnaires with no periodic reassessment or contractual testing obligations satisfy CSCC-1 control 4.3.1 documentation requirements while leaving supply chain access unmonitored.
CSCC-1:2019 has no controls specifically addressing AI model exfiltration or deepfake-driven social engineering -- attack surfaces that have grown substantially since the standard was published.
A CSCC-1 gap analysis that uses only automated scanning will miss the same class of misconfigurations the original audit missed -- because the audit methodology and the scanner share the same blind spots.
TL;DR
CSCC-1 is a reasonable baseline governance framework. It is not a security program. The 114 controls cover policy, structure, and documented process -- auditors verify that documentation exists and controls are nominally implemented. They do not verify that controls hold under adversarial conditions. Saudi organizations that treat audit passage as a security milestone are managing audit risk, not operational risk. The gap between the two is where breaches happen.
The audit passed. The environment was not secure.
A Saudi fintech -- 60 employees, Series B, processing payments under SAMA oversight -- completed their CSCC-1 maturity level 2 audit in Q3. Clean report. Governance structure documented. MFA deployed across all administrative accounts. Asset inventory current as of the last quarterly cycle. Third-party vendors assessed at onboarding. Every box checked.
Six weeks later, during a Vulnox vulnerability assessment commissioned for a separate purpose, we found three things the audit had not caught. The SMS-based MFA on their internal admin portal was bypassable through a known flaw in the OTP provider's API -- publicly documented, unpatched. Their cloud environment contained fourteen Lambda functions not present in the CMDB the auditor had reviewed -- two of which had broad S3 read permissions. And their largest payment processing vendor had never been subject to a security assessment; the initial questionnaire from 18 months ago was the only evidence on file.
None of this violated the letter of CSCC-1. The audit methodology accepts documentation as evidence. The controls were implemented -- just not in the way that would survive an attacker testing them. That is the gap the framework does not close.
How CSCC-1's audit methodology creates predictable blind spots
CSCC-1:2019 is structured around five control domains and three maturity levels. Maturity level 2 -- the target most Saudi organizations work toward -- requires that controls be implemented and that processes exist to manage them. The audit evidence standard is primarily documentary: policies, procedures, configuration screenshots, vendor contracts, training records.
This is the right design for a baseline governance framework. It establishes structure. It forces organizations to think about cybersecurity as a program rather than a collection of point tools. The problem is that documentary evidence and operational security are not the same thing, and the framework does not require testing that would surface the difference.
Control 3.2.1 requires strong authentication. An MFA deployment satisfies it. The audit does not require a test of whether the MFA implementation has known vulnerabilities. Control 3.1.1 requires an asset inventory. A CMDB export satisfies it. The audit does not require reconciliation against live cloud infrastructure. Control 4.3.1 requires a third-party risk management program. A questionnaire process satisfies it. The audit does not require contractual security testing obligations or evidence that vendors have been reassessed.
None of this is a criticism of the NCA's framework design. It is a description of what any compliance framework can and cannot do. The organizations that understand the distinction get value from CSCC-1 compliance. The ones that treat audit passage as the output of a security program are buying audit coverage, not security.
Example
The MFA bypass issue is worth unpacking specifically because it is the most common and most misunderstood. SMS-based OTP is widely deployed in Saudi Arabia because it is accessible, user-familiar, and satisfies the authentication requirement in most compliance frameworks. It also has a well-documented attack surface: SIM swapping, SS7 protocol vulnerabilities, and API-level flaws in OTP provider implementations. In Vulnox assessments of CSCC-1-compliant environments, SMS OTP was the deployed MFA mechanism in the majority of cases -- and in a meaningful portion of those, the specific OTP provider in use had known vulnerabilities that had not been patched at the application integration layer.
The SS7 vulnerability class is not new -- it has been documented since 2014. The persistence of SMS OTP in compliant environments is not a failure of awareness. It is a failure of control validation. Nobody tested whether the implementation was actually secure, because the audit did not ask them to.
What Vulnox found in CSCC-1-compliant environments
Assessment base: Vulnox assessment data, 2024-2025, Saudi Arabia and GCC region client environments
Asset inventory gaps in cloud-heavy environments
Across assessments of Saudi organizations that had completed CSCC-1 audits, we consistently found cloud resources absent from the CMDB inventories auditors had accepted as evidence. Serverless functions, auto-scaled compute instances, and short-lived containers created by development teams outside the formal provisioning process were the most common categories. In one case, a production environment had 23 Lambda functions that did not appear in any inventory document -- several with broad IAM permissions attached.
The client believed their asset inventory was current because they had a quarterly update process. The process captured resources provisioned through the formal change management workflow. It did not capture anything created directly through the cloud console or through CI/CD pipelines that bypassed change management. CSCC-1 control 3.1.1 does not specify how the inventory must be generated or validated against live infrastructure -- it accepts the document.
Third-party access persisting beyond vendor relationships
In multiple assessments, we found active credentials or API keys belonging to vendors whose engagements had ended between 6 and 18 months prior. The third-party risk programs in place had questionnaire processes for onboarding. They did not have offboarding processes that systematically revoked access. CSCC-1 control 4.3.1 addresses the management program; access lifecycle is covered under identity controls in a different domain.
The client's vendor risk documentation was complete. The access was still live. This is the kind of finding that does not surface in an audit because the audit checks the program documentation, not the IAM logs. A former vendor with persistent access is not a third-party risk management failure in the audit sense -- it is an identity lifecycle failure. The domains do not always communicate with each other in implementation.
Incident response plans untested against realistic scenarios
CSCC-1's resilience domain (control domain 3) requires incident response planning and testing. In practice, the testing evidence accepted by auditors has typically been tabletop exercises run against generic scenarios -- data breach, ransomware, DDoS. In Vulnox assessments where we could examine the actual exercises conducted, the scenarios rarely reflected the specific attack paths available against that organization's environment.
An IR plan tested against a generic ransomware scenario does not tell you whether your team can respond to a compromised vendor credential gaining lateral access through a cloud environment with gaps in your asset inventory. The plan may be well-documented and the exercise evidence may satisfy the audit requirement. Whether the organization can actually contain an incident in their specific environment is a different question.
The organizations with the most mature CSCC-1 programs sometimes have the largest operational gaps
Common belief
Organizations that invest heavily in CSCC-1 compliance -- building out governance structures, training programs, policy libraries -- are further along on security maturity than organizations that treat compliance as a checkbox exercise.
What we found
In Vulnox assessments, the finding that surprised clients most often was not in organizations with weak compliance programs -- those clients expected gaps. The most surprising findings came from organizations with strong audit history, because the gap between their documented posture and their actual control effectiveness was widest relative to their internal confidence level.
The counterintuitive finding is that heavy investment in compliance program infrastructure can actually mask operational gaps by creating a high-confidence narrative. When an organization has a mature policy library, a documented governance structure, a third-party risk program, and clean audit history, the internal assumption is that the hard work is done. Security teams deprioritize control validation because the compliance evidence is strong.
The organizations that treat CSCC-1 as a checkbox -- rushing through documentation to pass the audit -- sometimes do more unintentional control testing because they are scrutinizing the framework requirements for the minimum viable implementation. They discover gaps because they are trying to understand exactly what the control requires. Organizations with mature compliance programs sometimes stop scrutinizing controls they consider settled.
This is not an argument for doing compliance badly. It is an argument for separating compliance evidence from security validation and running both on independent cycles.
What CSCC-1:2019 does not cover that current attackers are already exploiting
AI model and training data exfiltration
CSCC-1 control 4.2.3 addresses data leakage prevention. The control was designed for conventional data -- files, database records, API responses. It does not address AI model parameters or training data as exfiltration targets. Organizations deploying custom models trained on sensitive customer data -- a pattern accelerating across Saudi financial services -- are exposing a new asset class that sits outside the framework's DLP control surface. Model parameters encode the statistical structure of training data. Exfiltrating the model can be functionally equivalent to exfiltrating the data it was trained on, and will bypass DLP systems calibrated to detect conventional data patterns.
Deepfake-assisted social engineering against payment authorization flows
CSCC-1's human factors controls focus on awareness training and phishing simulation. The threat model underlying those controls assumes that social engineering is text-based and that employees can learn to recognize suspicious requests. Audio and video deepfakes break that assumption. An attacker using a synthetic voice model of an executive to authorize a wire transfer does not trigger the pattern recognition that phishing training builds. Saudi financial institutions are a high-value target for this attack class, and the control structure in CSCC-1 has no specific mechanism to address it.
Serverless and ephemeral compute as a persistent access mechanism
The asset inventory and access control requirements in CSCC-1 assume a relatively stable, discoverable infrastructure. Cloud-native architectures break this assumption. Serverless functions can be provisioned in seconds, operate with attached IAM permissions, and generate minimal audit trail compared to traditional compute. An attacker with developer credentials can deploy a persistent access mechanism that does not appear in any inventory document the CSCC-1 audit would review. The control structure has no specific requirement for detecting or inventorying ephemeral resources.
Where CSCC-1 compliance failures are heading in the next 24 months
By Q2 2027, a significant breach at a CSCC-1-compliant Saudi financial institution will be traceable to a compromised vendor credential that persisted after the vendor relationship ended -- a gap no current CSCC-1 control explicitly closes.
The pattern is structurally inevitable. Third-party risk programs focused on onboarding questionnaires create high-confidence documentation of vendor risk management while leaving access lifecycle to identity management controls in a separate domain. When those two domains are owned by different teams with different audit cycles, access revocation falls into the gap. The Saudi financial sector's rapid vendor ecosystem growth -- cloud providers, fintech integrations, API partners -- is expanding the population of former vendors with potentially persistent credentials faster than access review cycles are catching it.
Confidence: highIf NCA updates CSCC-1 to include an explicit control requiring access revocation validation as part of vendor offboarding -- or if a breach tracing to persistent former-vendor credentials becomes public and triggers that update -- this prediction is confirmed.AI model exfiltration will become a named attack category in Saudi Arabia's threat landscape by end of 2026, creating a compliance gap that no current version of CSCC-1 addresses and that will require framework revision.
Saudi financial and government organizations are deploying custom AI models at an accelerating rate. The models are trained on proprietary data. The attack surface -- exposed inference APIs, insufficiently permissioned model storage, CI/CD pipeline access to model artifacts -- is growing faster than security controls are being applied to it. The first named incident will force the question of which CSCC-1 control covers it, and the answer is that none of them do cleanly.
Confidence: mediumA publicly attributed incident involving AI model parameter exfiltration from a Saudi-regulated organization, or an NCA advisory specifically addressing AI model security, would confirm the direction. Absence of either by end of 2026 suggests the threat is developing more slowly than current indicators suggest.
What clients say before the assessment, and what the data shows underneath
We spent six months configuring our SIEM to pull in logs for the CSCC-1 audit, and now they're saying the timestamps aren't granular enough because we're only logging events to the nearest minute.
Root cause:CSCC-1's logging requirements under the operations domain do not specify timestamp granularity precisely, which means auditors and organizations frequently interpret the requirement differently. The real problem underneath this complaint is that the logging implementation was designed to satisfy an audit requirement rather than to support incident investigation. Logs granular to the nearest minute are insufficient for reconstructing attack timelines where attacker dwell time is measured in seconds between lateral movement steps. The audit issue is a symptom -- the root issue is that the logging architecture was not built for operational use.
We have MFA on everything. CSCC-1 can't be asking for more than that.
Root cause:MFA deployment satisfies the authentication control on paper. The assumption that deployment equals protection is the gap. The relevant question is not whether MFA is deployed but whether the specific MFA implementation has been validated against known bypass techniques for that product version. SMS OTP implementations, hardware token integrations, and authenticator app deployments each have distinct vulnerability profiles. CSCC-1 control 3.2.1 does not require testing -- it requires implementation. Those are different things.
Our vendors are all ISO 27001 certified. That should count as third-party risk management.
Root cause:ISO 27001 certification tells you that a vendor has a documented information security management system that satisfied an auditor's review at a point in time. It does not tell you what access that vendor has to your environment, whether that access is appropriately scoped, when it was last reviewed, or whether the vendor's security posture has changed since certification. CSCC-1 control 4.3.1 requires an active management program -- certifications held by vendors are inputs to that program, not substitutes for it.
The framework is not the problem. The way organizations use it is.
CSCC-1 is a well-structured baseline framework for a market that needed one. The NCA made sensible choices about what to require and how to sequence maturity. The five control domains cover the right territory. The maturity levels give organizations a credible progression path.
The problem is not the framework. It is that most organizations treat compliance as a destination rather than a calibration mechanism. The audit happens. The report is clean. The security team moves on to the next priority. The controls are not validated. The gaps between documented implementation and actual control effectiveness are not measured. The framework never gets used for the purpose it is best suited for -- identifying where the documented posture and the operational reality diverge.
The organizations that get real value from CSCC-1 run their gap analysis on a continuous basis. They use the audit as a structured forcing function to inventory their controls, then separately test whether those controls function. They treat a clean audit report as the starting condition for a security program, not the output of one. That is a minority of CSCC-1-compliant organizations in my experience.
The counterargument is that compliance frameworks should not be asked to do more than they were designed for, and that conflating audit requirements with security validation sets unrealistic expectations. That is a fair point. The problem is that most organizations do not make the distinction clearly -- they pass the audit and conclude they have done the security work, because the audit is framed as a security assessment rather than a governance baseline check.
Counterargument
Some security practitioners argue that CSCC-1 compliance, done thoroughly, naturally surfaces most significant security gaps -- that the discipline of documenting controls forces organizations to confront what they have not implemented. There is something to this for organizations starting from a low baseline. For organizations with existing security infrastructure, the audit disciplines are most likely to find documentation gaps rather than control gaps, which is a different problem.
One thing to do before your next audit cycle
Pull your current asset inventory and run it against a live scan of your cloud environment. Not a CMDB export -- a live enumeration of what is actually running. If the numbers do not match, you have found the gap that your last audit missed and your next attacker will find. That single reconciliation exercise will tell you more about your actual control effectiveness than any policy document review. If your team cannot do it internally, it is worth knowing that before the audit, not after.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint assessmentEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
Saudi Arabia CSCC-1 compliance guide for cloud providersNational Vulnerability Database NIST
NIST National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkThird-Party Risk Management
third-party risk management
Frequently Asked Questions
What does CSCC-1 compliance actually require beyond documentation?
CSCC-1 requires demonstrable implementation across five control domains: governance, defense, resilience, third-party risk, and operations. Auditors check for policy documents and evidence of controls, but the standard does not mandate penetration testing or red team exercises. Environments passing CSCC-1 audits can and do have exploitable misconfigurations -- particularly in authentication flows, asset inventory completeness, and vendor contract enforcement.
How do CSCC-1 maturity levels affect what auditors actually check?
CSCC-1 defines maturity levels 1 through 3. At maturity level 2, which most Saudi organizations target, auditors focus on documented processes and partial implementation evidence. The gap is that level 2 does not require live testing of whether controls function under attack conditions. An MFA policy can satisfy level 2 even if the underlying MFA product has known bypass vulnerabilities.
What are the most commonly failed CSCC-1 controls in real assessments?
Based on Vulnox assessment data, the controls most frequently failing in practice while passing on paper are: 3.2.1 (authentication strength -- SMS OTP bypass vulnerabilities persist), 3.1.1 (asset inventory -- ephemeral cloud resources routinely absent), and 4.3.1 (third-party risk -- initial vendor questionnaires completed but not followed by periodic reassessment or contractual testing requirements).
Does passing a CSCC-1 audit mean an organization is secure against current threats?
No. CSCC-1:2019 was designed to establish a baseline governance structure, not model current attacker behavior. The framework does not address AI model exfiltration, serverless function abuse, or deepfake-driven social engineering -- attack patterns that have matured since the standard was published. A clean CSCC-1 audit report and an environment with active attacker dwell time are not mutually exclusive.
What should organizations do after achieving CSCC-1 compliance?
The first concrete step is validating that technical controls function as documented, not just that documentation exists. This means testing MFA bypass scenarios, auditing cloud asset inventories against live infrastructure rather than CMDB records, and running tabletop exercises against the actual incident response plan. CSCC-1 compliance is the starting condition for a security program, not the outcome of one.
How should Saudi organizations approach third-party risk under CSCC-1?
Control 4.3.1 requires a third-party risk management program, but most implementations stop at questionnaire completion and certificate review. Effective third-party risk management under CSCC-1 requires contractual security testing obligations, periodic reassessment on a defined schedule, and defined breach notification timelines. Questionnaires completed at onboarding and never revisited are technically program documentation, not operational controls.
What is the biggest structural gap between CSCC-1 and how attackers actually operate?
CSCC-1 is perimeter and governance-oriented. Attackers increasingly operate through ephemeral cloud resources, compromised vendor credentials, and AI-assisted social engineering -- none of which map cleanly to the framework's control structure. The framework's asset inventory requirements, for example, assume a known and bounded asset universe. Modern cloud environments create and destroy resources faster than any quarterly inventory cycle captures.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.