Digital Twin Data Security: What Asset Owners Should Ask Before Adoption

Why Digital Twin Security Is an OT Problem Wearing an IT Costume

When a refinery or terminal evaluates a digital twin platform, the conversation usually starts in the wrong department. IT gets pulled in to review the vendor's cloud architecture, run through a standard third-party risk questionnaire, and check a box. But a digital twin for an inspection-driven asset — one that ingests UT thickness data, corrosion mapping, RT and PAUT records, P&IDs, isometrics, and equipment tag data tied to physical process units — is not really an IT system. It is an operational technology (OT) adjacent system wearing IT clothing, and it deserves the scrutiny that OT-connected systems get, not the scrutiny of a marketing CRM tool.

The reason this matters is specific: the data inside a digital twin is a detailed map of exactly where an asset is weak. Shell thickness readings trending toward retirement minimum on a specific tank course, corrosion rates on a specific pipeline segment, overdue inspection intervals on a specific pressure vessel — in the wrong hands, that is not just competitively sensitive information, it is a targeting map for anyone wanting to understand where a facility is physically vulnerable. Asset owners in oil and gas, chemicals, and power generation need to evaluate digital twin security with that reality in mind, not with a generic "do you encrypt data" checklist.

This is not a hypothetical concern. The 2017 TRITON/TRISIS incident, in which attackers compromised the safety instrumented system at a Middle East petrochemical facility, remains the industry's clearest public reminder that systems adjacent to process safety and asset condition data are worth serious attacker effort, and that OT-adjacent platforms deserve the same scrutiny given to control systems themselves, not the lighter scrutiny typically reserved for office productivity software. A digital twin is not a safety instrumented system, but it sits close enough to sensitive operational data that the same threat model applies when you are deciding who gets access and how that access is monitored.

Start With Data Classification, Not Technology

Before asking a single question about encryption algorithms or cloud regions, an asset integrity manager should classify what is actually going into the platform. Not all twin data carries the same risk. Generic 3D geometry of a publicly visible tank farm carries low sensitivity — anyone can see the tanks from a public road or a commercial satellite image. Inspection results, RBI risk rankings, and real-time sensor feeds carry considerably higher sensitivity, because they reveal condition and vulnerability rather than just shape.

Data classification should drive every downstream security decision: what gets hosted where, who gets access, what gets encrypted at what level, and what triggers a formal risk review before it is uploaded at all. Skipping this step and jumping straight to "is the vendor SOC 2 compliant" is a common mistake — a vendor can pass every audit in the world and still be handed data that should never have left the plant's own network in that raw form.

What's Actually Sensitive in an Inspection-Driven Twin

• RBI risk rankings and inspection intervals under API 580/581 — these effectively rank which equipment is closest to failure
• Thickness trending data approaching retirement thickness per API 510, API 570, or API 653 — a direct indicator of remaining safe life
• Process safety information tied to specific equipment — design pressures, temperatures, and material specifications
• Site layout and access route detail beyond what is publicly visible — security-relevant for critical infrastructure
• Personnel and technician certification records if the platform also tracks workforce qualifications

The Standards Frameworks Worth Knowing

You do not need to become a cybersecurity engineer to have this conversation with a vendor, but knowing the vocabulary of the frameworks that actually apply changes the quality of the conversation. ISA/IEC 62443 is the standard most directly relevant to industrial automation and control systems security, and while a digital twin platform typically sits above the control system layer rather than inside it, vendors serving industrial clients should be able to speak fluently about 62443 zones and conduits, and where their platform sits relative to your OT network.

The NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover) is a useful general-purpose structure for asking a vendor to describe their program rather than just naming certifications. API 1164, developed for pipeline SCADA systems, is worth knowing if your twin platform touches pipeline operations data. And ISO/IEC 27001 remains the baseline international standard for information security management systems — a vendor holding current 27001 certification, or actively pursuing SOC 2 Type II attestation, has at minimum been through an external audit of its security controls, which is more than can be said for a platform running on someone's personal cloud account.

None of these frameworks certifies a vendor's product as "secure" in an absolute sense — no framework does that. What they do is give you a documented basis for the questions you ask and a paper trail you can point to later if your own auditors or insurers ask how you evaluated a third-party data platform touching critical asset information.

Cloud, On-Premise, or Hybrid — The Real Tradeoffs

Most digital twin platforms today run on cloud infrastructure — AWS, Azure, or Google Cloud — because the compute and storage demands of large point clouds and continuously updating inspection data are expensive to run on-premise, and because cloud vendors' baseline physical and network security typically exceeds what a mid-sized plant's own IT department can maintain. That is a legitimate and often correct choice. But "cloud" is not a single answer, and the follow-up questions matter more than the initial yes.

Ask where the data physically resides — data residency matters for multinational operators subject to different regional requirements, and for any facility designated as critical infrastructure under CISA guidance in the US. Ask whether your data is logically isolated in a single-tenant or dedicated environment, or commingled in a shared multi-tenant database with other customers' asset data. Ask what the vendor's incident response plan looks like, specifically: who notifies you, within what timeframe, and what information you receive if their environment is breached. A hybrid model — geometry and general visualization data in the cloud, the most sensitive inspection and RBI data replicated to an on-premise or private-cloud instance behind your own firewall — is a reasonable middle path for operators with the IT resources to support it, and worth asking any vendor whether they support.

Backup and disaster recovery deserve their own line of questioning, separate from the day-to-day security conversation. Ask the vendor to state their Recovery Time Objective (RTO) and Recovery Point Objective (RPO) in writing — how long until service is restored after an outage, and how much data, if any, could be lost in the process. A platform holding years of accumulated UT surveys, RT film records, and RBI history represents a substantial investment of field labor; losing even a few weeks of recently uploaded inspection data to an unrecoverable outage is a real operational cost, not just an inconvenience. Ask whether backups are geographically separated from the primary environment and how frequently backup restoration is actually tested, as opposed to simply configured and left unverified.

Twelve Questions to Ask Every Digital Twin Vendor

Before signing a contract or starting a pilot, put these questions in writing and get written answers, not just a verbal assurance on a sales call:

• Where is our data physically hosted, and can that location change without notice?
• Is our data encrypted in transit and at rest, and with what standard (AES-256 is the common baseline)?
• Is our environment single-tenant, dedicated, or shared multi-tenant infrastructure?
• What role-based access control (RBAC) options exist, and can we restrict RBI and thickness data to a smaller group than general geometry viewers?
• Do you undergo independent third-party security audits, and can we see a current SOC 2 Type II report or ISO 27001 certificate under NDA?
• What is your data breach notification timeline, contractually, not just in a policy document?
• Who owns the data once it is uploaded, and in what format can we export it if we terminate the contract?
• How is our data segregated from your other clients' data, technically, not just contractually?
• Do you conduct regular penetration testing, and how recently was the last one completed?
• What integrations exist with our CMMS, historian, or ERP, and what credentials or network access do those integrations require?
• What happens to our data if your company is acquired or shuts down?
• Can we run a phased pilot with a single unit or a subset of low-sensitivity equipment before migrating our full inspection history?

Network Segmentation and the Purdue Model

Anyone with a process control background will recognize the Purdue Enterprise Reference Architecture — the layered model separating the physical process (Level 0/1), control systems (Level 2), site operations (Level 3), and the business network and internet-facing systems (Level 4/5). A digital twin platform, if it is cloud-hosted, lives conceptually at Level 4 or above. The critical security question is how data gets from the OT side of that boundary, where the actual inspection instruments and sometimes live sensors operate, up to the twin platform without creating a new pathway into the control network.

A well-designed integration pulls data one-way, out of a historian or a DMZ (demilitarized zone) data replica, rather than allowing the cloud platform any inbound path toward Level 2 or Level 1 systems. If a vendor's proposed integration requires opening an inbound connection from the cloud into your control network, or installing an agent directly on OT equipment, that is worth a hard stop and a conversation with your control systems engineer before proceeding, regardless of how convenient it makes the data flow. Most digital twin data — inspection results, thickness readings, work orders — originates from systems that already sit at Level 3 or above, like a CMMS or an inspection database, which is the right layer for that data to move from in the first place.

Data Ownership, Portability, and Vendor Lock-In

Security and data ownership are related questions that get conflated too often. Even with airtight technical security, a contract that does not clearly state you own your inspection data, your geometry, and your historical records — and that specifies a usable export format if you leave the platform — creates a different kind of risk: operational dependency on a single vendor with no practical exit path. Ask specifically what export format your point cloud and model data would come out in, whether your inspection history exports in a structured, reusable format or a locked proprietary one, and whether there are any fees or delays built into the offboarding process.

This is worth raising early, before a contract is signed, not after a relationship has soured. A vendor confident in their platform's value should have no hesitation committing to clear data portability terms in writing.

It is also worth looping in whoever manages your cyber liability insurance before finalizing a digital twin contract, not after. Many insurers now ask specific questions about third-party data processors with access to operational or asset condition data as part of underwriting or renewal, and some policies carry exclusions or sub-limits for incidents originating at a vendor rather than the insured's own network. Confirming how a digital twin vendor's data handling fits within your existing coverage — and whether the vendor carries their own technology errors-and-omissions or cyber liability coverage — is a five-minute conversation with your broker that can prevent a much longer one after an incident.

Building Security Into the Rollout, Not Bolting It On After

The most common security failure in digital twin adoption is not a sophisticated breach — it is an internal rollout that grants broad access by default because nobody took the time to define roles before go-live. A field technician who needs to view geometry and upload inspection photos does not need visibility into RBI risk rankings across the entire facility. A corporate reliability engineer reviewing trend data across a multi-site portfolio does not need edit access to raw field records. Defining these roles up front, before the first user account is created, is cheaper and far more effective than trying to retrofit access controls after fifty people already have administrator rights out of convenience.

The same discipline applies to your own inspection program. Pairing platform rollout with proper NDT training on how field data should be captured, tagged, and uploaded reduces the amount of loosely controlled data — screenshots, unstructured PDFs, personal cloud shares — that ends up circulating outside the platform entirely, which is very often the actual source of a data exposure rather than a sophisticated attack on the vendor's infrastructure. Whether you are evaluating Atlantis NDT's digital twin platform or any competitor's offering, running through this checklist before you sign is the difference between adopting a tool that strengthens your asset integrity program and quietly creating a new attack surface you did not know you had. If you want a second set of eyes on a vendor's security posture or your own rollout plan, that is exactly the kind of question worth bringing to an ASNT Level III consulting engagement alongside your IT and OT security teams.

Atlantis NDT Products & Services