Supplier security programmes are enforced by procurement, not by a regulator, which makes the deadline a contract date and the penalty a lost account. SABIC's runs on a requirement pack issued directly to vendors, and most of the effort turns out to be scoping and documentation rather than new technology. Here is how to approach both.
SABIC CyberTrust: the third-party cybersecurity programme run by SABIC, which requires suppliers and vendors connecting to its systems or handling its data to demonstrate a defined set of security controls. It is a commercial condition rather than a legal one, which changes who enforces it and how fast.
Accuracy note. CyberTrust is SABIC's own programme and its requirement set, scoring and assessment cadence are communicated to suppliers directly and revised over time. This covers the control areas the programme consistently examines and how to prepare infrastructure for them. Work from the requirement pack and questionnaire SABIC issues to you, not from a summary. This is not legal advice.
Why a Buyer Programme Behaves Differently
A regulator can fine you. A customer can stop buying from you, and the timeline for that is a purchase order cycle rather than an enforcement action. Suppliers who treat CyberTrust as paperwork to be handled later tend to discover the deadline is a contract renewal date.
The other difference is scope negotiation. With a national framework, applicability follows from what you are and what data you hold. With a supplier programme, applicability follows from the connection: which of your systems touch SABIC data or SABIC networks. That boundary is worth drawing carefully and early, because everything inside it inherits the requirements and everything outside it does not.
Draw the boundary as a diagram of data flows, not a list of departments. A finance system that receives purchase order data is in scope even if nobody in finance has heard of the programme.
The Control Areas That Get Examined
The programme covers a familiar span, and infrastructure carries a large share of it.
| Area | What it looks for | Where it lives |
|---|---|---|
| Identity and access | Least privilege, MFA on remote and privileged paths, account lifecycle | Platform and directory |
| Data protection | Encryption in transit and at rest, classification, segregation of buyer data | Platform and process |
| Network security | Firewalling, segmentation, DDoS resilience, remote access via VPN | Platform |
| Endpoint security | Anti-malware with current definitions, host firewall, patch state | Your estate |
| Email security | SPF, DKIM and DMARC on the sending domain, anti-phishing controls | Domain and mail platform |
| Logging and monitoring | Security events captured, retained, and actually reviewed | Platform plus a named function |
| Backup and continuity | Backups taken, restoration tested, recovery objectives documented | Platform and process |
| Governance | Written policies, awareness training, incident response plan | Entirely yours |
The last row is where small and mid-sized suppliers lose the most points. Technical controls are frequently present and undocumented; a programme assessment cannot credit a control it cannot see evidence of.
The Two Honest Starting Points
Suppliers arrive in one of two states, and the work differs enough that conflating them wastes months.
You have infrastructure already. The task is a gap assessment: map your current estate against the requirement pack, close what is missing, and document what already works. Most of the cost is documentation and a handful of missing components, typically email authentication, centralised logging, and tested restores.
You are building for this. The task is to deploy an environment where the controls are already configured, then write the policies around it. This is usually faster than remediating a sprawling estate, and it has the side benefit of a small, defensible scope boundary.
If your existing estate is large and poorly documented, consider standing up a separate in-scope environment for SABIC-related work rather than certifying everything you own. A narrow scope is cheaper to prove and cheaper to keep proven.
What Assessors Ask For That Teams Forget
Four things come up repeatedly and are rarely ready.
Evidence with dates. A screenshot of an MFA setting proves the setting today. An access review record signed quarterly proves the control operates. The second is what earns credit.
A restore that happened. Backup configuration is not backup assurance. A dated restore record, including what was restored and how long it took, answers the question the configuration cannot.
Named ownership. Every control needs a person or role accountable for it. Unowned controls decay, and assessors know this.
Subprocessor visibility. If your service depends on other vendors, their security posture is part of yours. Maintain the list.
The Frameworks Underneath
CyberTrust does not exist in isolation. A supplier operating in Saudi Arabia is likely also within scope of the national baseline, and if it processes personal data, of the data protection law as well. The control overlap is substantial.
Build one control set mapped to every applicable framework and produce evidence once. Running a CyberTrust programme separately from a national compliance programme duplicates roughly two thirds of the effort. Our explainer on NCA Essential Cybersecurity Controls covers the Saudi baseline, and Saudi PDPL and data residency covers the placement question, which is separate from the control questions and constrains options far more sharply.
Where MassiveGRID Fits
Several rows of that table are platform properties rather than projects. MassiveGRID enforces MFA on management interfaces, applies AES-256 encryption at rest and TLS 1.3 in transit, provides role-based access control with account lockout, and offers dedicated instances and private cloud for the tenant segregation the programme expects of buyer data. Network controls include host and network firewalling with segmentation, and DDoS mitigation is standard rather than an upsell. Continuity comes from Proxmox high-availability clustering with automatic failover over Ceph storage that replicates each block three times across independent NVMe drives, with backup services for the restore evidence. Where logging exists but nobody reviews it, SOC and NOC services supply the named function the requirement implies.
On placement, MassiveGRID deploys into partner facilities operated by Equinix, Digital Realty, Sparkle and NTT, a published footprint of more than 700 datacenters across 85 metros, 30 countries and six continents, and infrastructure can be ordered in any of them. Saudi Arabia is not among the metros currently listed on the datacenter page, and partner footprints change, so if a classification or a contract clause requires in-Kingdom placement, confirm current availability directly and treat colocation or a private cloud in a local facility as the route.
The governance row stays yours. See the SABIC CyberTrust alignment for the gap assessment and turnkey deployment paths, including the policy templates that shorten the documentation half of the work.