Digital Twin for Middle East Refineries: SACS-002 Data Residency Considerations

Data Residency Is a Design Constraint, Not an Afterthought, in Gulf Refineries

A refinery asset integrity team in Jubail, Ras Tanura, or Ruwais evaluating a digital twin platform for corrosion monitoring and inspection management runs into a question that a US Gulf Coast refinery rarely has to ask first: where, physically and legally, does this data live. In Saudi Arabia and the UAE, that question is not a procurement nicety — it is shaped by national data protection law, sector-specific cybersecurity controls, and increasingly by contractor-level data classification requirements that operators push down onto every vendor touching asset integrity records, sometimes referenced informally on site under designations like SACS-002. Getting the architecture wrong doesn't just create friction; it can disqualify a vendor from a bid or trigger a compliance finding well after the platform is already in production.

The Regulatory Landscape: PDPL, NCA ECC-1:2018, and Cloud Frameworks

Saudi Arabia

The Kingdom's Personal Data Protection Law (PDPL), enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA), restricts cross-border transfer of personal data absent an adequacy decision or specific safeguards — and while most raw NDT and corrosion data is not "personal data" in the PDPL sense, the technician names, certification numbers, and sign-offs embedded in every inspection report typically are. Separately, the National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-1:2018) apply to government entities and, by extension through contractual flow-down, to many contractors and vendors serving critical national infrastructure, including hydrocarbon processing facilities. The Communications, Space and Technology Commission's Cloud Computing Regulatory Framework further classifies cloud services by data sensitivity tier and, for the higher tiers, expects in-Kingdom hosting or a licensed local cloud service provider.

United Arab Emirates

The UAE's Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data sets its own cross-border transfer conditions, layered on top of free-zone-specific regimes — the DIFC Data Protection Law No. 5 of 2020 in Dubai's financial free zone and the ADGM's equivalent regulations in Abu Dhabi — that can apply depending on where the operating entity or its data processor is legally domiciled. ADNOC and its operating companies, along with most major EPCs active in the UAE, layer their own vendor data handling addenda on top of the statutory baseline, and those addenda are usually more specific and more restrictive than the underlying law about where asset integrity and inspection data can be processed and stored.

What SACS-002 Style Contractor Requirements Usually Demand

Operators across the Gulf increasingly issue their own internal data classification and handling standards that contractors and software vendors must sign onto before touching asset integrity data — inspection records, corrosion monitoring history, and RBI (risk-based inspection) datasets are routinely classified above "public" or "internal" because they describe the condition and vulnerability of critical infrastructure. A contractor-level code like SACS-002 typically sets out three things a digital twin vendor needs to satisfy before deployment: a data classification schedule specifying which record types — UT thickness data, RT film or digital images, corrosion loop history, isometric drawings — fall into which sensitivity tier; a residency requirement specifying that data at or above a given tier must be hosted within the country, or in some cases within a facility physically controlled by the operator; and an access control and audit logging standard specifying who can view, export, or modify records and how that activity is logged for periodic audit. None of this is unusual by international standards — it mirrors what NERC CIP does for North American grid operators or what IEC 62443 zone-and-conduit models expect for industrial control environments — but it does mean a digital twin vendor's default cloud architecture, built for a US or European customer base, usually needs real modification, not just a configuration toggle, to satisfy it.

Asset Integrity Data That Actually Needs to Move

Not every dataset in a refinery's asset integrity program carries the same sensitivity, and treating all of it as equally restricted is how projects stall. RBI assessments performed under API 580 and API 581 methodology — corrosion rate assumptions, probability of failure calculations, consequence categories — are usually the most sensitive, because they describe exactly where a facility is most vulnerable to loss of containment. Raw UT thickness readings and RT images are moderately sensitive on their own but become highly sensitive once tied to a specific tag number, line, or vessel with corrosion trend context. Equipment master data — tag numbers, nominal dimensions, material specifications pulled from ASME Section VIII or API 650/653 design records — is typically lower sensitivity and often already shared with multiple contractors on site. A well-architected digital twin separates these tiers at the data model level so the residency and access control requirements can be applied precisely instead of blanket-applied to everything, which is usually what drives vendors toward an unnecessarily restrictive, and expensive to operate, all-in-Kingdom architecture when only a subset of the data actually requires it.

Architecting a Digital Twin That Satisfies Residency Without Losing Functionality

In-Country Hosting and Data Segregation

The practical pattern that works across most Gulf deployments is a segregated architecture: the sensitive asset integrity dataset — RBI outputs, tagged inspection history, corrosion trend data — hosted in-country or in a facility the operator has approved, with the visualization and modeling layer of the digital twin able to query it locally rather than replicating it to a foreign region. Less sensitive reference data, such as generic equipment catalogs or standard material property tables, can live wherever is operationally convenient. This segregation has to be a deliberate part of the data model from day one; retrofitting it after a platform has been built around a single unified cloud region is a substantially larger effort than designing for it up front.

OT/ICS Security Alignment

Where a digital twin pulls live data from process historians or SCADA/DCS systems rather than periodic exports, it needs to sit cleanly within the facility's IEC 62443 zone-and-conduit architecture — typically as a Level 3.5 (DMZ) or Level 4 business-system consumer reading from a historian via a one-way or tightly firewalled connection, never with a live write-path back into the control network. NIST SP 800-82 guidance on industrial control system security and API 1164 for pipeline SCADA security are useful references even where they are not directly mandated, because Gulf operators' own internal OT security standards are frequently built on the same foundations.

A Practical Example of a Segregated Deployment

Picture a refinery inspection department running RBI under API 580/581 across a crude unit, with UT corrosion mapping data collected weekly and RT files generated during each turnaround. A segregated architecture keeps the RBI risk outputs, tagged corrosion trend history, and turnaround RT archive on servers physically located in-Kingdom or in an operator-approved facility, accessible to the digital twin's visualization layer through a local connection rather than a round trip to a cloud region outside the country. The equipment master data feeding the 3D model — nominal pipe diameters, material specifications, design pressures pulled from the original ASME Section VIII and API 650 documentation — sits in a lower-sensitivity tier that can be hosted more flexibly, since it describes the unit's design rather than its current condition or vulnerability. Technicians and engineers see one unified model in the interface; the sensitivity split is invisible to them and enforced entirely at the infrastructure layer, which is exactly how a residency-compliant deployment should feel to the people actually using it day to day.

Vendor Due Diligence Checklist for Gulf Operators

• Where exactly is each data tier physically hosted, and can the vendor name the specific facility or provider, not just "the region"?
• Does the vendor's data classification scheme map cleanly onto the operator's own classification levels, including whichever internal contractor code, such as SACS-002-style requirements, applies on site?
• Is access control role-based with a full audit log, and can that log be exported for the operator's own periodic security review?
• How does the platform ingest data from OT systems, if at all, and what zone of the IEC 62443 architecture does that ingestion sit in?
• What happens to hosted data on contract termination — is deletion, export, or continued escrow available, and within what timeframe?

Language, Units, and Local Standards Alignment

Beyond data residency, Gulf refinery deployments carry a second layer of localization that often gets underestimated in the initial scoping conversation: documentation and reporting conventions aligned to the Saudi Standards, Metrology and Quality Organization (SASO) and, for many operator contracts, bilingual Arabic/English reporting for inspection summaries and certain regulatory submissions, even where the underlying technical data — UT readings, RT images, corrosion rates — is unit-agnostic and typically reported in metric units regardless of country. A digital twin platform built exclusively around US customary units and English-only reporting fields, common in platforms designed first for a North American market, needs real schema changes, not just a translation layer bolted on afterward, to serve a Gulf operator's actual reporting workflow. This is a smaller issue than data residency in terms of security risk, but it is a common source of deployment delay because it surfaces late, usually during user acceptance testing with the operator's own inspection staff rather than during the initial security and architecture review.

Contract Structure: Data Ownership Between Operator, EPC, and Vendor

Middle East refinery projects frequently involve a three-party data relationship that a digital twin vendor has to navigate explicitly: the operator who owns the asset and ultimately the data, an EPC or main contractor who may hold the original construction and commissioning records, and the software vendor providing the platform itself. Data ownership and portability terms — what happens to the hosted dataset if the operator changes vendors, who retains rights to derived analytics like RBI trend calculations built on top of raw inspection data, and how sub-processor relationships, such as an underlying cloud infrastructure provider, are disclosed and approved — need to be resolved in the contract before deployment, not discovered afterward. Gulf operators increasingly require sub-processor disclosure specifically because their own contractor data codes, including SACS-002-style requirements, extend the residency and access control obligations down through the vendor's own supply chain, not just to the vendor's direct systems.

A Realistic Rollout Path for Refineries Under Residency Constraints

The fastest path to a working deployment is usually not the most ambitious one. Starting with a single unit or a single asset class, tankage under API 653 for instance, where RBI and UT thickness mapping data is well bounded, lets the operator's IT security and the vendor validate the residency architecture against real data before it scales plant-wide. Pairing the digital twin rollout with Atlantis NDT ERP for the surrounding inspection scheduling, technician certification tracking, and equipment calibration management gives the operator a single compliance conversation to have with SDAIA-aligned or NCA-aligned security reviewers instead of one conversation per system. Because every Atlantis deployment is built to be fully customizable rather than a fixed multi-tenant SaaS product, the hosting architecture, including in-Kingdom or operator-facility hosting where a facility's contractor code requires it, is a configuration decision made with the customer, not a constraint imposed by a one-size-fits-all cloud design.

What Changes Once the Platform Is Live

Operators who complete a residency-compliant pilot successfully tend to describe the same shift in how their asset integrity team works: RBI reassessments that used to require pulling data from separate UT, corrosion loop, and inspection scheduling systems into a spreadsheet before an inspection engineer could even begin the API 580 risk calculation now start from a single, current dataset tied directly to the 3D model of the unit. That doesn't eliminate the engineering judgment API 580/581 methodology requires — probability and consequence categorization still depend on a qualified inspector's assessment — but it removes the data assembly step that previously consumed a disproportionate share of the reassessment cycle, the same structural problem seen in nuclear ISI programs half a world away: asset integrity data scattered across systems that don't talk to each other.

The Bottom Line for Asset Integrity Leaders

Data residency in the Gulf is not a single checkbox — it is a layered set of national law, sector cybersecurity controls, and operator-specific contractor requirements that a digital twin vendor has to satisfy simultaneously. Treating it as an architecture decision from the outset, rather than a compliance patch applied after a pilot succeeds technically, is what separates digital twin deployments that survive the operator's security review from ones that get shelved after months of otherwise good engineering work. For operators navigating this for the first time, an independent ASNT Level III consulting review of the proposed architecture against the site's actual contractor data code is usually faster and cheaper than discovering a gap during the operator's own security review.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.