Saudi AI Cybersecurity Consultation Has Closed: What Organizations Should Do Now
Last updated: 2026-08-14
That deadline matters—but it does not mean the consultation draft automatically became final or mandatory on the following day.
As of 14 August 2026, no approved final version, consultation-results report, implementation timetable or formal compliance mechanism has been identified in the NCA’s official publications. Organizations should therefore avoid presenting the consultation text as an enacted set of binding controls.
They should not, however, ignore it.
The draft offers a useful view of the cybersecurity practices the NCA considers relevant to artificial intelligence. Many of those practices—AI inventories, defined ownership, secure development, restricted agent permissions, third-party assessment, event logging, rollback and human override—are sensible controls regardless of how the final document is classified.
The practical response is to begin with reversible, risk-based improvements while monitoring the NCA for the final text.
Current status as of 14 August 2026
Question
Verified position
Practical meaning
Has the consultation closed?
Yes. The stated deadline was 5 August 2026.
The announced period for public feedback has ended.
Have consultation results been published?
Not identified in official publications.
It is not yet possible to determine which comments the NCA accepted.
Has a final version been approved?
Not identified as of 14 August 2026.
Continue describing AICG-1:2026 as a consultation draft.
Are the 42 draft guidelines mandatory?
The consultation text presents them as recommended cybersecurity guidance.
Do not claim that the draft independently creates binding obligations for every entity.
Are private organizations within the intended audience?
Yes. The stated audience broadly covers entities in the Kingdom using or planning to use AI.
Private entities can use the draft as a readiness baseline without assuming universal legal applicability.
Is there an implementation deadline?
No universal deadline identified in the draft.
Prioritize improvements according to system risk and existing obligations.
Is there a prescribed audit or evidence-submission process?
None identified in the consultation text.
Retain evidence for internal assurance and future mapping, but do not imply that submission is already required.
What the consultation covered
The consultation concerned the proposed AI Cybersecurity Guidelines, AICG-1:2026.
The draft contains:
Four main cybersecurity domains
Fifteen subdomains
Forty-two individual guidelines
Coverage of the AI-system lifecycle
Express consideration of generative AI and agentic AI
The four main domains are:
Cybersecurity governance
Cybersecurity defense
Cybersecurity resilience
Third-party cybersecurity
Under those domains, the draft addresses areas including cybersecurity risk management, project management, human resources, awareness, asset management, identity and access management, network security, information protection, backup and recovery, vulnerability management, penetration testing, monitoring, web-application security, business continuity and supplier risk.
The draft recommends that entities in Saudi Arabia which use, or plan to use, AI systems follow the guidelines and apply minimum cybersecurity good practices. This intended audience is broad enough to include private organizations.
However, broad intended use is not the same as legally binding applicability. The consultation text presents the document as guidance and does not, by itself, establish a new mandatory compliance perimeter for every private business using AI.
What the consultation’s closure means
Closure means the stated period for submitting feedback has ended.
The NCA can now review the submissions, revise the document, approve a final version, conduct further consultation or take another step within its regulatory process.
Closure does not, by itself:
Approve the consultation draft
Confirm that every proposed guideline will be retained
Convert recommendations into mandatory controls
Establish an implementation deadline
Introduce a certification or attestation requirement
Require organizations to submit evidence immediately
Confirm how the guidelines will interact with other NCA controls
Establish enforcement consequences for non-implementation
Until the final document is published, organizations cannot reliably compare the draft with the final text or determine which consultation comments were accepted.
Statements that organizations are already required to comply with all 42 draft guidelines would therefore go beyond what the official material currently confirms.
How the draft relates to existing Saudi cybersecurity requirements
The proposed guidelines should not be treated as a replacement for Saudi Arabia’s existing cybersecurity and data-protection requirements.
The draft’s four-domain structure resembles the structure used in other NCA instruments. This makes it practical to incorporate AI risks into an existing cybersecurity programme. It does not necessarily establish a formal one-to-one crosswalk.
Organizations should continue determining applicability separately for instruments such as:
The Essential Cybersecurity Controls
The Critical Systems Cybersecurity Controls
The Data Cybersecurity Controls
The Cloud Cybersecurity Controls
Other NCA requirements applicable to particular systems, data or operating models
Cybersecurity frameworks and instructions issued by sector regulators
Saudi personal-data protection and data-governance requirements
The Critical Systems Cybersecurity Controls are expressly described by the NCA as an extension and complement to the Essential Cybersecurity Controls for national critical systems. The proposed AI guidelines have not yet been given the same confirmed relationship in a final instrument.
A regulated entity should therefore create an AI-specific control layer within its existing programme instead of opening an entirely separate compliance structure.
For example, a financial institution subject to the Saudi Central Bank’s Cyber Security Framework should continue meeting that framework’s governance, application-security, supplier, monitoring and assurance requirements. The AI draft may help the institution interpret those existing control areas for AI systems, but it does not displace them.
The same principle applies to organizations processing personal data. Implementing cybersecurity controls for an AI system does not resolve separate questions about lawful processing, transparency, purpose limitation, data-subject rights, international transfers or breach notification under Saudi data-protection rules.
Start with an AI inventory and clear ownership
An organization cannot secure AI systems it has not identified.
The inventory should extend beyond internally developed machine-learning models. It should include:
Public generative-AI services used by employees
AI features embedded in SaaS products
Models accessed through APIs
Locally hosted or open-source models
Retrieval-augmented generation systems
Vector databases and knowledge repositories
AI agents and orchestration frameworks
Plugins, tools and external data connectors
AI-assisted software-development tools
AI functions supplied by outsourcers or managed-service providers
Experimental systems and business-led pilots
For each system, record at least:
Business purpose and operational status
Business owner and technical owner
Model and service provider
Hosting and processing locations
Users and affected business processes
Data sources and data classifications
Whether personal, confidential or regulated data is involved
Connected applications, tools, APIs and repositories
Agent permissions and service accounts
Degree of automation or autonomy
Human review and approval points
Logging arrangements
Vendor and contract references
Risk assessment and approval status
Planned review and retirement dates
A spreadsheet can be sufficient for an initial inventory. The more important requirement is that ownership, review responsibilities and escalation routes are clear.
Classify AI systems by potential impact
Not every AI deployment requires the same level of control.
An internal drafting assistant with no access to confidential data creates a different risk from an agent that can modify customer accounts, approve transactions or issue instructions to operational systems.
A practical classification should consider:
Sensitivity of accessible data
Importance of the supported business process
Whether outputs affect individuals or customers
Degree of system autonomy
Scope of tools and permissions
Possibility of financial, safety, legal or operational harm
Reversibility of the system’s actions
Availability of effective human review
Dependence on external providers
Ease of isolating or shutting down the system
Higher-impact systems should require formal approval before production, more extensive security testing, stronger monitoring, stricter change control and more frequent review.
This approach reflects the consultation draft’s focus on risk-based classification, formal approval for high-impact AI projects and gradual introduction of agent autonomy.
Secure generative AI as a system, not just a model
The model is only one part of a generative-AI deployment.
The wider system can include prompt templates, data repositories, embeddings, retrieval components, APIs, plugins, authentication services, output filters, user interfaces, logs and third-party infrastructure.
Security reviews should therefore examine the full data and instruction path.
Relevant controls include:
Restricting the information users may enter
Validating and sanitizing retrieved content
Treating data from external tools, memory and APIs as untrusted
Detecting hidden instructions and prompt injection
Separating instructions from retrieved or user-supplied content
Applying input and output guardrails
Testing generated code before use
Protecting prompts, embeddings, model weights and system configurations
Controlling model and knowledge-base updates
Preventing uncontrolled production retraining
Monitoring for abnormal output or usage patterns
Restricting data retention and provider reuse where the service allows it
A generic “employees must use AI responsibly” policy is not enough when the AI service is connected to company repositories or production applications.
Agentic AI requires stronger operational controls
Agentic AI adds planning, memory, tool use and action-taking to the risks associated with generative AI.
An agent might read a message, retrieve records, update a CRM, send an email, create a payment instruction or change a system configuration. The main question is no longer only whether the model’s output is accurate. It is also whether the agent should be permitted to perform the action.
Organizations should apply several control principles.
Give agents their own identities
Do not allow an agent to operate through a broadly privileged shared account.
Each production agent should have an identifiable service identity, limited permissions, defined credential ownership and a documented purpose. Permissions should be narrower than those of a human administrator wherever possible.
Separate reading from acting
An agent that can retrieve information does not automatically need permission to modify or delete it.
Read, create, update, approve, transmit and delete permissions should be assessed separately.
Increase autonomy gradually
Begin in an observation or recommendation mode. Introduce limited execution only after testing and documented approval.
High-impact or difficult-to-reverse actions should require human confirmation.
Define limits outside the model
Do not depend entirely on an instruction in the system prompt to prevent harmful actions.
Apply enforceable technical limits such as:
Allowlisted tools and destinations
Transaction and usage thresholds
Rate limits
Time and session restrictions
Segregation of duties
Approval workflows
Network and egress restrictions
Credential scoping
Prohibited-action rules
Emergency disablement
Preserve human override
The responsible person must be able to stop the agent, revoke its access, reject an action or move the process to a safe manual alternative.
Review third-party models, APIs and AI services
Many organizations do not build their own AI models. They connect to external models or purchase software containing AI capabilities.
The draft’s third-party domain indicates that outsourcing does not remove the need to understand and manage cybersecurity risk.
Due diligence should cover:
Provider identity and service ownership
Model and component provenance
Hosting, processing and support locations
Data retention and deletion
Use of customer content for training or service improvement
Subprocessors and important technical dependencies
Authentication and access-control options
Encryption and key-management arrangements
Logging and customer access to logs
Vulnerability disclosure and patching
Security testing and independent assurance
Incident-notification commitments
Service continuity and provider exit
Model or service changes
Secure return, transfer or destruction of information
Support for investigation and evidence preservation
Contracts should translate important supplier statements into enforceable obligations. A public security page or marketing claim is weaker than a contractual commitment covering notification, access control, data use, audit information and termination.
Where the provider cannot supply complete information, the organization should document the uncertainty and decide whether additional restrictions, monitoring or human review can reduce the residual risk.
Improve AI logging and incident readiness
Traditional application logs may not explain what happened during an AI incident.
Investigation can require context such as:
User or agent identity
Authentication and authorization events
Model and configuration version
Prompt or instruction version
Data sources and repositories accessed
Tools and APIs invoked
Records created, changed, downloaded or deleted
Approvals and human interventions
Guardrail or policy decisions
Output disposition
Errors and abnormal behaviour
Relevant timestamps and correlation identifiers
Organizations should decide which information is necessary for security and investigation without creating unnecessary collections of sensitive prompt content.
Logs must also be protected against unauthorized access, alteration and deletion. Their retention period should be aligned with incident, regulatory, contractual and privacy requirements.
The incident-response plan should include AI-specific scenarios such as:
Sensitive data entered into an unapproved service
Prompt injection through retrieved content
Compromise of an AI service account
Unauthorized tool execution
Malicious or corrupted model update
Poisoning of memory or a knowledge repository
Exposure of prompts, embeddings or model weights
Unexpected autonomous actions
Provider outage or security incident
Loss of reliable human oversight
An AI failure is not automatically a reportable regulatory incident. The organization should assess the affected data, systems, persons and services against its existing notification matrix.
For example, if an AI incident compromises personal data, the Saudi Personal Data Protection Law and its implementing rules may create separate notification obligations. The National Data Governance Platform describes notification to the competent authority within 72 hours of awareness where the applicable harm-based conditions are met.
The consultation draft itself does not establish a new universal AI-incident reporting deadline.
Build resilience, rollback and manual alternatives
AI systems can fail without being conventionally “hacked.” A provider may become unavailable, a model update may change behaviour, an agent may enter a destructive loop, or a knowledge repository may become unreliable.
Organizations should define:
Safe shutdown procedures
Emergency access revocation
Rollback to a known model or configuration
Restoration of protected data and components
Isolation of compromised tools or integrations
Manual operating procedures
Alternative suppliers or services where justified
Recovery-time and recovery-point expectations
Criteria for returning the system to production
Post-incident review and reapproval
Backups alone are insufficient if the organization has never tested whether the AI system, its dependencies and its operational process can be restored.
Penetration testing and adversarial evaluation should also verify that the human-override mechanism works under realistic conditions.
Collect evidence while implementing controls
The consultation draft does not prescribe a universal audit package or require organizations to submit evidence at this stage.
Nevertheless, documenting work now is useful for security assurance, customer reviews, internal governance and any future regulatory mapping.
Evidence should demonstrate what was actually approved, configured, tested and reviewed—not simply that a policy exists.
Practical controls and evidence to retain
Workstream
Action to take now
Useful evidence
Inventory and ownership
Identify models, AI-enabled services, agents, data sources, integrations and accountable owners.
Inventory export, architecture record, ownership assignment and lifecycle status.
Risk and approval
Classify systems by data sensitivity, impact, autonomy, reversibility and dependency.
Risk assessment, threat model, approval record, exceptions and residual-risk acceptance.
Secure development
Apply security by design, controlled changes, code review and testing before production.
Development standard, review records, test results, release approval and change history.
Agent permissions
Give agents distinct identities, least-privilege access, thresholds and human approval points.
Authorization matrix, service-account record, tool allowlist and approval workflow.
Data protection
Protect training data, prompts, embeddings, model weights, contexts, outputs and logs.
Establish rollback, safe shutdown, restoration and manual operating alternatives.
Recovery procedure, exercise report, rollback test, shutdown test and lessons-learned record.
People and awareness
Train users, developers and reviewers on sensitive prompts, generated code and AI-specific incidents.
Training material, attendance record, competency checks and confidentiality commitments.
A practical preparation sequence
Organizations can begin with the following sequence:
Identify sanctioned and unsanctioned AI use.
Create an AI-system inventory and assign owners.
Classify systems by data sensitivity, impact, autonomy and reversibility.
Restrict high-risk or unknown use pending review.
Map existing cybersecurity controls to the AI environment.
Assess models, APIs, plugins and other suppliers.
Apply least privilege to users, agents and service accounts.
Define logging requirements and integrate critical events with monitoring.
Test prompt injection, data leakage, unauthorized tool use and human override.
Establish rollback, safe shutdown and manual operating procedures.
Record approvals, exceptions, test results and residual risks.
Review the final NCA publication when it becomes available and perform a controlled gap assessment.
This work does not require organizations to claim formal compliance with an unfinished document. It creates a defensible baseline that can be adjusted when the final position becomes clear.
What to monitor in the final text
The final publication may retain the consultation structure, change individual guidelines, add compliance language or clarify how the document relates to existing requirements.
Organizations should compare the complete final document—not merely its title or publication announcement—with the consultation version.
Final-publication monitoring checklist
Issue to verify
Why it matters
Required response
Document status and terminology
“Guidelines,” “controls” and “requirements” can carry different compliance implications.
Confirm the final title, version number, approval status and operative language.
Mandatory or advisory classification
This determines whether implementation is recommended or formally required.
Update policies, risk acceptance and compliance reporting to reflect the final status.
Applicability to private entities
The intended audience of the draft is broad, but binding scope requires precise confirmation.
Assess entity type, sector, systems, Saudi operations and any stated exemptions.
Relationship with ECC and CSCC
Organizations need to know whether the final text supplements, extends or cross-references existing controls.
Build a formal control crosswalk and eliminate duplicate testing where possible.
Interaction with cloud, data and sector rules
AI systems may already fall under other binding cybersecurity, privacy or sector requirements.
Update the regulatory-applicability matrix and control ownership.
Implementation and transition dates
A final document may introduce deadlines or staged implementation.
Create a prioritized remediation plan with accountable owners and milestones.
Audit and evidence requirements
The final version may introduce self-assessment, attestation, audit or evidence expectations.
Compare existing evidence with any prescribed format, frequency and submission channel.
Generative and agentic AI treatment
Definitions, autonomy thresholds or required human controls may change.
Reassess agent permissions, approvals, tool access, guardrails and shutdown controls.
Incident and notification provisions
The final text may clarify AI-specific incident handling or links to existing reporting duties.
Update the incident classification and regulatory-notification matrix.
Changes to the 42 draft guidelines
Controls may be added, removed, renumbered or materially rewritten.
Perform a line-by-line comparison rather than relying on summaries.
Conclusion
The Saudi AI cybersecurity consultation has closed, but the regulatory process is not yet complete.
The consultation draft remains valuable because it identifies a practical direction: organizations should know which AI systems they use, assign responsibility, secure the entire AI architecture, restrict agent permissions, investigate suppliers, preserve useful logs and prepare for safe shutdown and recovery.
These measures can be implemented without assuming that every proposed guideline is already mandatory.
The immediate objective should be operational readiness—not premature claims of compliance.
Kooch helps organizations turn emerging cybersecurity and AI-governance expectations into practical inventories, risk assessments, supplier reviews, control mappings and evidence registers. Where the final instrument creates a material question of Saudi legal applicability, organizations should also obtain advice from appropriately qualified Saudi counsel.
