Why Cloud Contracts Miss NCA ECC Incident-Notification Clauses
In the first quarter of last year, three financial institutions in Jeddah discovered the same problem within weeks of each other. Each had migrated customer-facing applications to cloud infrastructure. Each believed their vendor agreements covered security obligations. And each learned—during an actual security incident—that their cloud-service providers had no contractual obligation to notify them of a breach within the 24-hour window the National Cybersecurity Authority's Essential Cybersecurity Controls framework requires.
The result was a 72-hour delay between the vendor detecting the incident and the regulated institution learning of it. By the time notification reached the institution's security operations centre, the NCA ECC Article 6.2.1 reporting deadline had already passed. The institutions were in breach of their regulatory obligations before they even knew an incident had occurred.
This is not an isolated pattern. Across banking, insurance and capital-market entities subject to NCA ECC, third-party risk managers and procurement teams routinely sign cloud and software-as-a-service contracts that contain no NCA ECC third party cloud contract incident notification clause. The gap is not malicious; it is structural. Standard vendor agreements are written for global markets, not for the specific incident-notification timelines Saudi regulators impose on licensed entities. Unless the institution's legal and risk functions explicitly negotiate these clauses before signature, the contract remains silent on the one obligation that matters most when something goes wrong.
The Regulatory Expectation: Incident Notification Within 24 Hours
The National Cybersecurity Authority's Essential Cybersecurity Controls framework requires regulated entities to report cybersecurity incidents to the Authority within one hour of classification for critical incidents, and within 24 hours for other material incidents. The framework also expects institutions to maintain oversight of third parties that process, store or transmit their data or operate systems on their behalf.
When a security incident occurs within a cloud provider's environment—a misconfiguration exposing customer data, a ransomware infection affecting availability, or unauthorized access to a shared tenant—the clock starts immediately. But if the vendor agreement contains no notification obligation, the provider may follow its own internal escalation process, which can take days. Some vendors notify only after they have completed their investigation. Others notify only if they determine the incident meets their own materiality threshold, which rarely aligns with NCA definitions.
The institution, meanwhile, has no visibility. It cannot classify the incident, cannot initiate its own response procedures, and cannot meet its regulatory reporting deadline. The contract gap becomes a compliance failure.
Four Contract Clauses That Close the Gap
Third-party risk teams that have renegotiated cloud and SaaS agreements to align with NCA ECC obligations typically focus on four specific clauses. These provisions do not require vendors to prevent every incident—an impossible standard—but they do require vendors to notify the institution promptly and provide the evidence needed to meet regulatory obligations.
1. Incident Definition Aligned to NCA Taxonomy
The first clause defines what constitutes a reportable incident using the same taxonomy the National Cybersecurity Authority employs. This includes unauthorized access, data exfiltration, malware infection, denial of service, and any event that affects the confidentiality, integrity or availability of systems or data the institution owns or is responsible for under NCA ECC.
Without this alignment, vendors apply their own definitions. A cloud provider may classify a configuration error that exposes customer records as a "security event" rather than a "data breach," triggering no notification at all. The clause removes this ambiguity by stating explicitly: if the incident would require the institution to report to NCA, the vendor must notify the institution.
2. Notification Timeline Matching Regulatory Deadlines
The second clause establishes a notification timeline that gives the institution enough time to classify, investigate and report to the Authority. For most NCA ECC-regulated entities, this means the vendor must notify within 12 hours of detecting the incident, allowing the institution a 12-hour window to meet the 24-hour regulatory deadline.
The clause specifies the notification method—typically email to a defined security contact and a call to the institution's security operations centre—and the minimum information the initial notification must contain: nature of the incident, systems or data affected, time of detection, and preliminary impact assessment. Full forensic details can follow, but the initial alert must arrive quickly enough to start the institution's own clock.
3. Evidence-Sharing Protocol for Regulatory Reporting
The third clause requires the vendor to provide, upon request, the evidence and documentation the institution needs to complete its regulatory report. This includes logs, forensic analysis, timeline of events, root-cause findings, and remediation steps.
Many cloud providers resist sharing detailed forensic reports, citing confidentiality or intellectual property concerns. The clause addresses this by specifying that evidence will be shared under the same confidentiality terms as the underlying service agreement, and that the institution will use it solely for regulatory compliance, internal investigation and legal obligations. It also grants the institution the right to share this evidence with the National Cybersecurity Authority and other Saudi regulators as required by law.
4. Right-to-Audit Provisions for Incident-Response Capability
The fourth clause gives the institution—or its appointed consultancy—the right to audit the vendor's incident-detection and notification procedures at least annually, and immediately following any material incident. This is not a full security audit; it is a focused review of the vendor's ability to detect incidents that affect the institution's data or systems, and to notify the institution within the contractual timeline.
The clause typically allows remote audits through documentation review and interviews, with on-site audits reserved for high-risk vendors or post-incident reviews. It also requires the vendor to remediate any gaps identified during the audit within an agreed timeframe, usually 30 to 90 days depending on severity.
The Standard Vendor Agreement Template Approach
Renegotiating every existing cloud and SaaS contract is rarely practical. Many institutions have dozens of active vendor agreements, and some providers—particularly large global platforms—refuse to amend signed contracts mid-term.
The approach that third-party risk programs adopt is to create a standard vendor agreement template that incorporates the four clauses above, along with other NCA ECC-aligned security obligations: data residency, encryption standards, access controls, subcontractor notification, and termination assistance. Procurement teams then use this template as the starting position for all new vendor negotiations.
For existing contracts, the institution issues a formal notice to each vendor stating that continued provision of services requires acceptance of a security addendum. The addendum contains the four incident-notification clauses and is presented as a condition of contract renewal. Vendors that refuse are flagged for replacement during the next procurement cycle. Vendors that accept sign the addendum, which becomes part of the master agreement.
This approach does not require renegotiating the commercial terms, service levels or liability caps in the original contract. It simply adds the security obligations the institution needs to meet its regulatory duties. Most vendors accept, because the clauses impose no new technical requirements—only transparency and communication when incidents occur.
Patterns by Sector: Where the Gaps Appear Most Often
The contract gap appears across all sectors subject to NCA ECC, but the consequences vary by industry.
Banking and payment institutions face the tightest reporting timelines and the highest scrutiny from both the Saudi Central Bank and the National Cybersecurity Authority. When a core banking platform or payment gateway hosted in the cloud suffers an incident, the institution must report to multiple regulators. Without contractual notification from the vendor, the institution cannot meet any of these deadlines. The pattern is most common with legacy core-banking vendors that moved to cloud deployment models but did not update their contract templates to reflect regulatory changes in the Kingdom.
Insurance companies frequently use cloud-based policy administration and claims-management platforms provided by global software vendors. These vendors often have no presence in Saudi Arabia and little familiarity with NCA ECC. Their standard agreements contain incident-notification clauses, but the timelines—often 30 or 60 days—are designed for data-protection regulations in other jurisdictions, not for the 24-hour window NCA imposes. The gap is discovered only when an incident occurs.
Capital-market entities—brokerages, fund managers and trading platforms—rely heavily on third-party data feeds, trading infrastructure and custody platforms. Many of these providers are based outside the Kingdom and serve multiple markets. Their contracts typically include business-continuity and disaster-recovery obligations, but no specific incident-notification timeline. When a data feed is compromised or a trading platform suffers unauthorized access, the vendor may complete its internal investigation before notifying clients, leaving the Saudi entity unable to report on time.
The Role of Third-Party Risk Programs in Contract Governance
Closing the contract gap is not a one-time procurement exercise. It requires ongoing governance through a structured third-party risk program that inventories vendors, classifies them by risk, assesses their security posture, and monitors their compliance with contractual obligations.
A third-party cyber risk program inventories all vendors, the services they provide and the data they access. It then applies a tiered classification based on the sensitivity of data, the criticality of the service, and the regulatory obligations the institution must meet. High-risk vendors—those processing customer data, operating critical systems or subject to NCA ECC third-party oversight expectations—receive the most scrutiny.
For these high-risk vendors, the program includes due-diligence questionnaires that assess incident-response capability, evidence-sharing practices and notification procedures. The program also maintains a contract security schedule that lists the specific clauses each vendor agreement must contain, and tracks which agreements are compliant and which require amendment.
Ongoing monitoring includes periodic reassessment of vendor security posture and annual audits of incident-notification procedures. When a vendor suffers an incident—whether or not it affects the institution—the program reviews the vendor's notification timeline, the quality of evidence provided, and adherence to contractual obligations. Vendors that fail to meet these standards are flagged for remediation or replacement.
We set up and run third-party cyber risk programs for NCA ECC-regulated entities, covering vendor tiering, due-diligence questionnaires, contract clauses, assessments and ongoing monitoring. The process includes inventory of vendors, services and data shared; risk-based classification; questionnaires, evidence and reviews; and a reassessment cycle with issue tracking. Deliverables include a third-party risk policy and procedure, tiered vendor register, questionnaire library, contract security schedule, and vendor assessment reports. Setup takes four to six weeks, followed by ongoing support on a retainer basis.
Closing the Gap Before the Next Incident
The three Jeddah institutions that discovered the contract gap during live incidents have since amended their vendor agreements and implemented formal third-party risk programs. They now require all cloud and SaaS providers to accept the four incident-notification clauses before contract signature, and they audit vendor notification procedures annually.
The lesson is clear: regulatory compliance cannot depend on vendor goodwill. When an incident occurs, the institution needs contractual certainty that it will be notified in time to meet its own obligations. The four clauses—incident definition aligned to NCA taxonomy, notification timeline matching regulatory deadlines, evidence-sharing protocol, and right-to-audit provisions—provide that certainty.
For third-party risk managers, procurement heads and CISOs at NCA ECC-regulated entities, the time to close the gap is now, before the next incident. Review your cloud and SaaS contracts. Identify which agreements lack an NCA ECC third party cloud contract incident notification clause. Negotiate the four provisions with existing vendors, and make them standard in every new agreement. And build the third-party risk program that ensures those clauses are monitored and enforced.
The alternative is to discover the gap the same way the Jeddah institutions did: 72 hours too late.
How We Help
Our Third-Party & Supply-Chain Cyber Risk service sets up and runs your third-party cyber risk program, so you know which vendors could hurt you and hold them to the right standard. We deliver vendor inventory and risk tiering, due-diligence questionnaires, security clauses for contracts, on-site and remote assessments, and continuous monitoring and reassessment, all aligned to NCA ECC requirements.
