SACS-002 Compliance Guide: Implementing Controls Effectively
Sienna VanceApril 29, 2026
Key takeaways
Nearly 45% of systems passing standard SACS-002 compliance scans still carry exploitable vulnerabilities, per Vulnox assessment data across fintech environments.
SACS-002 5.2.4 (Access Control) is routinely interpreted by auditors to cover machine-to-machine interfaces including HL7 and internal APIs, not just user-facing logins with MFA.
TLS 1.0 and 1.1 still enabled is the most common misconfiguration found across Vulnox SACS-002 assessments, producing audit failures that no automated scanner flagged during internal reviews.
Organizations transacting with the Saudi government must be SACS-002 compliant; ISO 27001 certification does not satisfy this requirement.
SACS-002 7.2.1 (Change Management) is almost universally applied to production deployments but not to Infrastructure as Code templates, leaving an exploitable gap that auditors are beginning to examine.
The largest hidden cost when migrating from NIST CSF to SACS-002 is not control implementation but evidence translation: repackaging existing controls into artifacts that satisfy SACS-002 auditor expectations.
TL;DR
SACS-002 compliance programs fail at the edges, not the center. Most organizations implement the headline controls and miss the interpretation layer: where auditors apply a control beyond its literal text, where machine interfaces are excluded from MFA scope, where IaC pipelines sit outside change management. This guide covers the specific gaps that produce audit findings and the ones that produce breaches without producing findings.
The audit that almost passed
A healthcare organization in Riyadh spent eight months preparing for a SACS-002 audit. They implemented MFA on every patient-facing portal. They documented their password policies with care. They invested in an IDS and ran internal scans that came back clean. Their compliance team was confident going in. The auditor found one finding: the HL7 interfaces connecting their internal clinical systems had no MFA. Those interfaces were explicitly in scope under SACS-002 5.2.4, even though they are machine-to-machine, not human-to-system. The non-compliance triggered a remediation cycle, delayed a government contract, and cost more to fix under deadline pressure than it would have cost to address during the preparation phase.
The gap was not a missing control. It was a missing interpretation. The organization read SACS-002 5.2.4 as applying to user authentication. The auditor read it as applying to all access control points, including system interfaces. That difference in interpretation is not unusual. It is the norm.
What SACS-002 auditors actually measure
SACS-002 shares structural DNA with ISO 27001 but diverges in how individual controls are interpreted and enforced. The divergence is not always documented. It reflects Saudi-specific regulatory context and, in some cases, local threat intelligence that shapes auditor expectations.
Take SACS-002 5.2.4 on multi-factor authentication. ISO 27001 auditors in most jurisdictions will accept SMS-based MFA as satisfying an MFA requirement. SACS-002 auditors frequently will not. This is not a formal written exception in the standard. It is an auditor interpretation informed by documented cases of SMS interception by local threat actors. Organizations preparing for a SACS-002 audit using ISO 27001 experience as their benchmark will not know this until they are in the room.
Logging requirements follow the same pattern. The control text requires logging. The audit expectation covers retention period, log format, alerting configuration on privileged account activity, and coverage of non-production environments in certain scopes. Having a SIEM deployed satisfies none of those expectations on its own. In Vulnox assessments, the phrase we hear most often before an engagement is: we already pay for CrowdStrike, is that not enough for logging? The answer is that the tool is not the control. The configuration, coverage, and retention policy are the control. CrowdStrike with default settings and 30-day retention fails a SACS-002 logging audit in most interpretations.
Example
A fintech organization running 12 microservices had logging enabled on all of them. What they did not have was centralized log aggregation with retention beyond 60 days, alerting on after-hours privileged access, or coverage of their database layer. Each of those gaps is a SACS-002 finding. None of them appeared on their internal compliance checklist because the checklist said logging: yes.
The practical implication for compliance teams: audit preparation requires not just control implementation but auditor expectation mapping. Read published findings from similar organizations. Talk to practitioners who have sat through SACS-002 audits, not just consultants who have helped prepare for them. The interpretation layer is where most failures happen.
What the assessments found
Assessment base: Vulnox SACS-002 gap assessments, primarily fintech, healthcare, and SaaS organizations operating in Saudi Arabia, 2023-2025.
TLS 1.0 and 1.1 enabled on internal services
Across Vulnox SACS-002 assessments, weak TLS configuration is the single most common finding. TLS 1.0 and 1.1 are disabled on public-facing endpoints in most organizations. They remain enabled on internal services, inter-service communication, and legacy admin interfaces because no internal scan flagged them as in-scope. SACS-002 auditors check internal services. Most automated compliance tools do not.
Organizations that run internal scans on external-facing surfaces and declare compliance are not assessing the environment the auditor will assess. The gap is structural, not accidental.
MFA absent from machine-to-machine interfaces
In assessments of healthcare and financial services organizations, MFA on HL7 interfaces, internal APIs, and service account authentication is absent in the majority of environments reviewed. The organizations had MFA deployed and documented. The documentation scoped MFA to user-facing applications. Auditors did not accept that scope limitation.
The SACS-002 5.2.4 interpretation question is not settled. Smart practitioners disagree on whether machine-to-machine interfaces fall under the control. But in practice, auditors are applying it broadly. Assuming the narrow interpretation is a risk position, not a compliance position.
IaC templates outside change management scope
SACS-002 7.2.1 requires formal change management processes. In every environment assessed that used Terraform or CloudFormation, change management controls were applied to production deployments. The IaC templates that generated those deployments were stored in version control with no security scanning, no approval gates on merge, and no review process equivalent to the one applied to runtime changes. In one case, a template had been deploying a web application with a default credential pair enabled for 14 months.
An attacker with write access to a CI/CD pipeline can deploy a compliant-looking system with a backdoor baked in at the infrastructure layer. The deployed system passes runtime scans. The audit passes. The vulnerability is invisible to both.
Phishing simulation gap in training programs
SACS-002 8.1.2 covers security awareness training. Organizations implementing this control typically document annual training completion rates. In assessments where phishing simulations were run as part of the engagement, click-through rates on externally crafted phishing emails exceeded 20% in organizations that had completed their annual training cycle within the prior six months.
Training completion is not training effectiveness. SACS-002 8.1.2 does not explicitly require simulation testing. Auditors do not currently penalize organizations that document completion without testing outcome. That interpretation may change as phishing-originated breaches accumulate in the regional incident record.
The control that passes audits and fails under attack
Common belief
Organizations that have deployed an EDR solution and a SIEM believe these tools satisfy the monitoring and logging requirements of SACS-002. The audit evidence is the tool license and the dashboard screenshot.
What we found
In assessments where we reviewed SIEM coverage against SACS-002 logging requirements, the average coverage gap was not in tool capability but in scope configuration. The tool could ingest the missing sources. No one had configured it to.
The tools are not the controls. An EDR deployed with default telemetry settings does not cover database access events, network flow data, or administrative actions on cloud infrastructure. A SIEM that aggregates endpoint logs but not authentication logs from identity providers, cloud consoles, and internal APIs provides coverage that looks complete on a dashboard and is not complete in an investigation.
The Vulnox assessment pattern: organizations that lead with their tooling investment in the intake conversation are more likely to have coverage gaps than organizations that lead with their logging policy. The tool conversation ends at deployment. The policy conversation requires someone to have thought about what they need to see.
When to pursue SACS-002 versus ISO 27001
SACS-002
Required for Saudi government contracts. Applies Saudi-specific interpretations of MFA, data residency, and incident reporting timelines. Maps to NCA ECC, which allows dual-framework compliance with reduced duplication. Auditor expectations on logging and access control scope go beyond the literal control text in ways that ISO 27001 experience does not prepare organizations for.
If your revenue depends on Saudi government contracts or your primary customer base requires SACS-002 from vendors, this is not optional. Budget for the interpretation gap, not just the control gap.
ISO 27001
Internationally recognized. Flexible control interpretation. Sufficient for many international enterprise customers. Does not satisfy SACS-002 obligations for Saudi government work. SMS-based MFA may pass. Data residency requirements are less prescriptive.
If your operations are primarily outside Saudi Arabia and you have no government contract obligations in the Kingdom, ISO 27001 may provide broader customer coverage at lower interpretive complexity. If you hold ISO 27001 and are expanding into Saudi government work, budget for a gap assessment against SACS-002 specifically. Do not assume overlap.
NIST CSF + SACS-002 migration
The hidden cost of migration is documentation translation, not control implementation. NIST CSF uses a different evidence vocabulary. Controls that are demonstrably implemented may not satisfy SACS-002 auditor evidence expectations without rework. Staff retraining is required not because the security practices change but because the documentation format and audit language change.
Organizations migrating from NIST CSF consistently underestimate the documentation phase by two to three months. Build that time into the project plan before committing to an audit date.
Where SACS-002 programs develop blind spots
Infrastructure as Code pipelines
SACS-002 7.2.1 change management controls are applied to production systems in virtually every compliant organization. They are almost never applied to the IaC templates that define those production systems. The pipeline that builds the infrastructure sits outside the compliance perimeter. Developers do not receive security training equivalent to what operations teams receive. Security scanning tools are not integrated into CI/CD pipelines. The result is a class of vulnerability that is deployed into compliant infrastructure and invisible to auditors reviewing runtime controls.
Legacy admin interfaces with deprecated TLS
Public-facing services are hardened. Internal admin panels, database management interfaces, and legacy monitoring tools are not. TLS 1.0 and 1.1 persist on these surfaces because no one has scoped them into the hardening program. An auditor reviewing internal service communication will find them. An attacker conducting internal reconnaissance after an initial foothold will find them first.
Third-party vendor access
SACS-002 requires controls over third-party access to systems. Most organizations implement these controls at the contract level: vendor agreements include security clauses. The technical implementation, specifically whether vendor access is time-limited, logged, and reviewed, is frequently missing. The contract says the right things. The access logs show persistent vendor sessions that were never terminated after project completion.
Cloud console authentication
MFA on cloud consoles is not universally enforced in environments that have MFA documented as a deployed control. The MFA policy covers the primary application stack. AWS console access, Azure portal access, and GCP console access are authenticated separately and are frequently excluded from the MFA enforcement scope by accident rather than by design.
Where SACS-002 enforcement is heading
Within 24 months, SACS-002 auditors will formalize IaC and CI/CD pipeline coverage as an explicit audit scope item rather than an edge-case interpretation of SACS-002 7.2.1.
Supply chain attacks via compromised build pipelines are generating documented incidents in the region. Regulators and auditors follow incident patterns. The IaC gap is structurally well-understood and increasingly discussed in practitioner communities. Formalization lags incident frequency by roughly 18 to 24 months.
Confidence: highPublished NCA or SAMA guidance explicitly scoping IaC and CI/CD pipelines into SACS-002 7.2.1 change management requirements, or three or more documented SACS-002 audit findings against IaC pipelines appearing in practitioner forums by Q4 2026.A mid-sized Saudi fintech will experience a material breach originating from a compromised IaC template within the next 18 months, and the post-incident review will show that the organization was SACS-002 compliant at the time of breach.
The structural conditions are present: widespread IaC use, no formal audit coverage of build pipelines, developer teams without security tooling equivalent to what operations teams have. The fintech sector in Saudi Arabia is growing faster than security maturity in this specific area. This is not a prediction about intent; it is a prediction about probability given observed conditions.
Confidence: mediumNo material fintech breach attributable to IaC compromise reported in Saudi Arabia by end of 2026, or SACS-002 IaC controls formalized before the breach window closes.
Compliance and security are not the same goal
SACS-002 is a better-than-average compliance framework. The MFA and logging requirements, interpreted broadly as auditors apply them, push organizations toward genuinely stronger security postures. The IaC and supply chain blind spots are real, but they are not unique to this framework. Every framework written before 2020 has them.
The problem is not the framework. The problem is treating audit preparation as the objective. Organizations that invest in SACS-002 compliance because they want to pass an audit will pass the audit and remain vulnerable in the places auditors do not currently look. Organizations that invest in SACS-002 compliance because they want to understand their actual risk posture will pass the audit and also close the gaps auditors miss.
The observable difference between these two orientations is whether the organization conducts any security testing that is not required by the audit process. Penetration testing beyond what SACS-002 mandates, red team exercises, phishing simulations with outcome measurement: these are how organizations find out what compliance does not cover.
Counterargument
The counterargument is that compliance-driven investment is better than no investment, and that organizations with limited budgets should focus resources where they are auditable. That argument holds for small organizations with genuinely constrained resources. It does not hold for organizations that have the budget for discretionary security spending and choose to allocate it entirely toward audit-facing controls.
One thing to do before your next SACS-002 audit
Pull your current MFA scope documentation and check whether it explicitly addresses machine-to-machine interfaces: internal APIs, HL7 connections if you are in healthcare, service account authentication, cloud console access. If the documentation is silent on those surfaces, you have a finding waiting in an audit that has not happened yet. Fixing the documentation is an afternoon. Fixing it under audit deadline pressure, with a government contract on the line, is a different problem entirely.
If you want a structured view of where your environment stands against SACS-002 before an auditor tells you, a gap assessment gives you that view without the consequences. The gaps we find most often are not the ones organizations expect.
Further Reading
Gap Analysis
SACS-002 gap analysisNIST
NIST cybersecurity frameworkNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkUnderstanding Compliance Gap Analysis
compliance gap analysis guideCISA Vulnerability Management
government vulnerability management guidance
Frequently Asked Questions
how to achieve SACS-002 compliance step by step?
Start with a scoped gap assessment against each SACS-002 control domain. Map your existing evidence artifacts to what auditors actually request, not just what the control text says. Prioritize findings by audit risk first, then remediation effort. In Vulnox assessments, the most common blocker at audit time is not missing controls but missing evidence: logs that exist but are not retained in the required format, or MFA that is deployed on user interfaces but not on machine-to-machine interfaces like HL7 or internal APIs.
what are the SACS-002 control domains?
SACS-002 control domains cover information security governance, asset management, human resources security, physical and environmental controls, communications and operations management, access control (including MFA requirements under 5.2.4), system acquisition and development, incident management, and business continuity. The access control and logging domains generate the most audit findings in practice because organizations configure tools for runtime environments and neglect machine-to-machine interfaces and IaC pipelines.
what is the difference between SACS-002 and ISO 27001?
ISO 27001 is an internationally recognized framework with flexible control interpretation. SACS-002 is tailored to Saudi Arabian regulatory requirements and reflects local enforcement expectations. A SACS-002 auditor may reject SMS-based MFA under control 5.2.4 where an ISO 27001 auditor would accept it, due to local threat intelligence around SMS interception. Data residency requirements also differ: SACS-002 may impose stricter geographic constraints on where data is processed and stored. ISO 27001 certification does not satisfy SACS-002 obligations for organizations transacting with the Saudi government.
what does a SACS-002 auditor actually check versus what the control text says?
Auditors routinely go beyond the literal control text. SACS-002 5.2.4 on access control is frequently interpreted to cover internal system interfaces, not just user-facing applications. Organizations that implement MFA on web portals but leave HL7 interfaces, internal APIs, or service accounts unprotected receive non-compliance findings. Logging requirements are similarly interpreted broadly: having a SIEM is not sufficient if log retention, alerting thresholds, or coverage of privileged accounts does not meet auditor expectations.
how much does SACS-002 compliance cost?
Costs vary significantly by organization size, existing control maturity, and scope. The largest hidden cost is documentation: translating existing controls into evidence artifacts that satisfy SACS-002 auditor expectations, particularly when migrating from a framework like NIST CSF that uses different terminology and evidence formats. Organizations migrating from NIST CSF consistently underestimate this translation effort. Budget for at least one full gap assessment cycle, remediation of findings, and an evidence preparation phase before the formal audit.
does SACS-002 compliance require companies transacting with Saudi government?
Yes. Organizations transacting with the Saudi government must demonstrate SACS-002 compliance. This is a contractual and regulatory requirement, not a voluntary certification. Organizations that hold ISO 27001 certification should not assume this satisfies SACS-002 obligations: the frameworks overlap but are not equivalent, and SACS-002 auditors apply Saudi-specific interpretations that ISO 27001 does not address.
what SACS-002 controls do organizations most commonly fail?
Based on Vulnox assessment data, the most common failures are: weak TLS configuration (TLS 1.0 and 1.1 still enabled), MFA gaps on non-user-facing interfaces, insufficient log retention and alerting coverage, and IaC templates that deploy systems with insecure default configurations. The IaC gap is structurally invisible to most compliance programs because change management controls (SACS-002 7.2.1) are applied to production deployments but not to the build pipelines that produce them.
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.