Why ISA-95 Still Matters as Plants Add Cloud and AI

The practical point. Cloud platforms and artificial intelligence (AI) change where plant data travels and who uses it. They do not change what the data means or which systems are allowed to act on the process. The ISA-95 standard from the International Society of Automation (ISA) still gives operational technology (OT) and information technology (IT) teams the shared model they need: clear levels, clear boundaries and a common vocabulary [1], [2]. Plants that keep that model get more from new tools, with less risk.

An old model for a new argument

Every few years our industry hears that the layered model of the plant is obsolete. First it was the industrial internet of things (IIoT), then the cloud, and now AI. The argument is always the same: data can now flow from any sensor to any application, so why keep the layers? I understand the frustration behind it. Layered architectures can be slow to change, and the interfaces between layers have often been expensive to build and maintain. But the argument confuses two different things: the path the data takes, and the responsibilities of the systems that use it.

Some history helps here. In 1994, Theodore J. Williams published an account of the Purdue Enterprise Reference Architecture, whose layered view of manufacturing became known across the industry as the Purdue model [3]. ISA built on that tradition when it approved the first part of ISA-95 in 2000: a set of terminology and object models for deciding what information should be exchanged between enterprise systems and control systems [1]. The International Electrotechnical Commission (IEC) adopted the work as IEC 62264, and published the second edition of Part 1 in 2013 [2]. These are not new ideas. They have lasted because they describe something real about how plants work.

What the levels are for

ISA-95 describes a functional hierarchy. Level 0 is the physical process itself. Levels 1 and 2 sense, manipulate, monitor and supervise that process, through programmable logic controllers (PLCs), distributed control systems and supervisory control and data acquisition (SCADA). Level 3 is manufacturing operations management, where the manufacturing execution system (MES) lives. Level 4 is the business: planning, logistics and enterprise resource planning (ERP) [1], [2].

The point of the levels was never that data must climb a ladder one rung at a time. The point is that each level has a different job, a different time scale and a different tolerance for failure. A planning system that is an hour late is an inconvenience. A control loop that is a second late can scrap a batch or hurt someone. Part 3 of ISA-95 adds reference models for the activities at Level 3, covering production, quality, maintenance and inventory [4]. That vocabulary lets an ERP team, an MES team and a controls team talk about the same order, the same lot and the same piece of equipment without talking past one another.

What cloud and AI change, and what they do not

Cloud platforms and AI do change three things. Data leaves the plant more often and in larger volumes. New users, including data scientists and remote specialists, want access to it. And there is growing pressure to let software outside the plant recommend actions on the process, or even take them.

They do not change the physics, the safety case or the need for clear accountability. The National Institute of Standards and Technology (NIST) describes OT as programmable systems and devices that interact with the physical environment, and its guide to OT security is written around the particular performance, reliability and safety requirements of those systems [5]. Those requirements do not relax because a model was trained in a data centre.

This is where the levels earn their keep. They give architects a principled answer to the questions that matter most:

• Where can this model read data? Almost anywhere, through well-defined interfaces, provided the data is described in ISA-95 terms so it means the same thing in the cloud as on the shop floor.
• Where can it write? Recommendations can go to Level 3 or Level 4 systems, where people and existing workflows review them. A direct write to Level 1 or Level 2 needs the same engineering rigour as any other change to the control system.
• Who is accountable? Each level has an owner. A model that crosses levels without an owner is a risk that nobody has accepted.

Security follows the same boundaries

Industrial cybersecurity standards rest on the same idea. IEC 62443-3-2, published in 2020, describes how to divide an industrial automation and control system into zones of assets with common security requirements, joined by conduits that carry communication between them, with target security levels derived from a risk assessment [6]. The ISA-95 levels are a natural place to start drawing those zones.

Two recent developments make this more pressing. In December 2025, cybersecurity agencies from the United States, Australia, Canada, Germany, the Netherlands, New Zealand and the United Kingdom published joint guidance on integrating AI into OT. It rests on four principles: understand AI, consider AI use in the OT domain, establish AI governance and assurance frameworks, and embed safety and security practices into AI-enabled OT systems [7]. In the European Union, the Cyber Resilience Act entered into force in December 2024. It sets cybersecurity requirements for products with digital elements. Its duty to report actively exploited vulnerabilities and severe incidents will apply from September 2026, and most of its other obligations from December 2027 [8]. Plants that buy connected equipment and software will feel these changes through their suppliers.

The common failure mode

In OT and IT integration, the failure I have seen most often over the years is not a technical one. It is two capable teams, with different instincts, working on the same plant without a shared model. IT teams are trained to patch quickly, change often and scale out. OT teams are trained to change rarely, test thoroughly and keep the process running above all else. Both instincts are correct in their own domain. ISA-95 does not settle the argument between them, but it gives both sides the same map, so the argument is about real trade-offs rather than vocabulary.

The operators and maintenance crews deserve a seat in that conversation as well. They know which signals can be trusted, which instruments drift, and which alarms are ignored because they fire too often. A model trained on plant data without their knowledge will learn the plant’s bad habits along with its good ones.

Practical advice for plant and operations leaders

1. Keep the model current. Maintain an ISA-95 based description of your equipment hierarchy, materials and interfaces, and require every new project to use it.
2. Draw the write boundary. Decide in writing which systems may change setpoints or recipes, and apply control-system change management to anything that writes to Level 1 or Level 2.
3. Zone before you connect. Define zones and conduits along IEC 62443 lines before you open any new path to the cloud.
4. Give every AI use case an owner at the right level. Accountability for a recommendation sits with the people who act on it.
5. Ask suppliers about their regulatory road map. Where products are sold into the European Union, ask how your suppliers will meet the Cyber Resilience Act timelines.
6. Bring operations into data work. Pair data scientists with operators and maintenance technicians from the first week, not the last.

New tools will keep arriving, and many of them will be useful. The plants that benefit most will be the ones that can say, clearly and in shared terms, what each system is for and what it is allowed to touch.

References

1. ANSI/ISA-95.00.01-2000, “Enterprise-Control System Integration, Part 1: Models and Terminology,” International Society of Automation, 2000.
2. IEC 62264-1:2013, “Enterprise-control system integration, Part 1: Models and terminology,” 2nd ed., International Electrotechnical Commission, Geneva, 2013.
3. T. J. Williams, “The Purdue enterprise reference architecture,” Computers in Industry, vol. 24, no. 2-3, pp. 141-158, Sept. 1994.
4. ANSI/ISA-95.00.03-2013, “Enterprise-Control System Integration, Part 3: Activity Models of Manufacturing Operations Management,” International Society of Automation, 2013.
5. K. Stouffer, M. Pease, C. Tang, T. Zimmerman, V. Pillitteri, S. Lightman, A. Hahn, S. Saravia, A. Sherule, and M. Thompson, “Guide to Operational Technology (OT) Security,” NIST Special Publication 800-82 Rev. 3, National Institute of Standards and Technology, Sept. 2023.
6. IEC 62443-3-2:2020, “Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design,” International Electrotechnical Commission, Geneva, June 2020.
7. Cybersecurity and Infrastructure Security Agency, Australian Signals Directorate’s Australian Cyber Security Centre, et al., “Principles for the secure integration of artificial intelligence in operational technology,” joint guidance, Dec. 2025.
8. European Parliament and Council of the European Union, “Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act),” Official Journal of the European Union, L series, Nov. 20, 2024.