OTAP

What is OTAP?

OTAP (Development, Test, Acceptance and Production) is a way of working in which software and configuration changes pass through four separate environments, so that every change has been tested and formally approved before it touches the production process. The acronym comes from the Dutch Ontwikkeling, Test, Acceptatie, Productie; internationally the same model is known as DTAP. Within industrial automation, you apply OTAP to changes in SCADA systems, PLC software, HMI screens or Historian configurations, for example. The difference from office IT: in OT, a mistake does not just mean an outage but possibly downtime, lost product or a safety hazard.

The aim of OTAP is to verify and validate changes before they affect the production environment, in order to minimise the risk of errors and downtime.

🧠 What happens in each OTAP phase?

Each phase has its own environment, permissions and documentation requirements. A change only moves on to the next phase once the exit criterion of the current phase has been met.

The classic activities per phase remain:

1. Development - designing and programming software, scripts or configurations in an isolated environment, with version control (e.g. Git).
2. Test - technical testing of syntax and logic, IO simulations and, where needed, hardware-in-the-loop, in which real control hardware runs against a simulated process.
3. Acceptance - functional testing by end users or engineers, validation against specifications and standards, often including approval through change management.
4. Production - final rollout, monitoring and logging during the first production cycle, and a rollback plan that has been tested in advance.

🎯 Why is OTAP harder in OT than in IT?

In IT an extra test server is cheap. In OT you cannot copy a reactor, a packaging line or a sewage pumping station. That is why an OTAP pipeline in a factory looks different from one in a data centre:

• The process cannot be duplicated - the test environment contains the controllers and software, but the physical process is simulated.
• Hardware is expensive and vendor-specific - an identical DCS controller or safety PLC for the acceptance environment can cost as much as the production system.
• Long lifecycles - plants run for 15 to 25 years; the test environment has to keep tracking the same firmware and software versions.
• Real-time behaviour - timing, scan times and network load behave differently in simulation than on the shop floor.
• Maintenance windows - rollout to production is often only possible during a planned shutdown.

OT therefore often combines virtual and physical means. PLC simulators such as Siemens S7-PLCSIM in TIA Portal, or a TwinCAT runtime on an ordinary PC, cover the test phase. Virtual commissioning with a digital twin of the machine lets you test control logic against a process model before the hardware even exists. With virtualisation, SCADA, historian and MES servers are easy to clone for test and acceptance.

🏭 What does an OTAP pipeline look like in a plant?

Typical changes that pass through this pipeline are PLC programs, SCADA screens and scripts, new alarm logic in line with alarm management, recipe management in ISA-88 batch environments, reports, and firmware and network configurations. Operating system updates follow the same route: patch management in OT means a patch first proves in test or acceptance that the control software keeps working.

🔄 How does OTAP relate to FAT, SAT and validation?

In projects, the acceptance phase often coincides with the formal test milestones of IEC 62381:2024. That standard describes the Factory Acceptance Test (FAT) at the vendor, the optional Factory Integration Test (FIT) added in 2024, the Site Acceptance Test (SAT) on location and the Site Integration Test (SIT) with the rest of the plant. OTAP is effectively the ongoing, operational version of what happens once in a new-build project.

In the pharmaceutical and food industries the validated state is central. GAMP 5 (second edition, ISPE, July 2022), the FDA rule 21 CFR Part 11 and EU GMP Annex 11 do not prescribe the word OTAP, but they do require changes to computerised systems to be controlled, tested and documented. An OTAP pipeline is the usual way to demonstrate that. A thoroughly revised Annex 11 was out for public consultation from July to October 2025; until the new text formally takes effect, the 2011 version applies.

🔍 What is the difference between OTAP, DevOps and direct changes?

DevOps is therefore not an alternative to OTAP but a way to automate the transitions between the phases. Online changes to a running PLC still happen in practice; a mature organisation records such an emergency change afterwards and brings it back into the development environment, so the environments do not drift apart.

🔐 Which security requirements come with OTAP?

ISO/IEC 27002:2022 explicitly lists the separation of development, test and production environments as control 8.31 (in the 2013 edition these were 12.1.4 and 14.2.6). Through ISO 27001 and the Dutch government baseline BIO, that control applies to many organisations. Control 8.33 also requires test information to be protected: production data containing personal data cannot simply be copied to test, partly because of the GDPR (AVG in Dutch). NIST SP 800-82 Rev. 3 (September 2023) advises OT operators to try updates in a representative test environment first, In the zones and conduits model of IEC 62443, the test environment usually gets a zone of its own with controlled connections.

Concrete measures:

• Separate access - access management and access control per phase; developers have no write access to production by default.
• Authorised deployment - only approved, version-controlled releases go to production.
• Audit and logging - who changed what and when is traceable through audit trails in acceptance and production.
• Backup before rollout - a restorable copy of the current production version, preferably as an immutable backup against ransomware.
• Network separation - test and acceptance environments physically or logically separated from production through network segmentation.
• Change management - every change with authorisation, impact analysis and a rollback plan.

An often underestimated security risk is the test environment itself: it is managed less strictly, holds copies of production projects and is sometimes temporarily connected to both the office network and production. Such a bridge undermines the entire segmentation. For organisations covered by NIS2, security in the development and maintenance of systems is also part of the duty of care.

🧭 How do you set up an OTAP pipeline step by step?

1. Identify what changes - which systems (PLC, SCADA, historian, network) receive regular changes? Use your asset register as the basis.
2. Decide the number of environments per system - not every system needs four physical environments; often development and test combined on an engineering station plus an acceptance environment is enough.
3. Choose simulation or hardware - simulation for logic, a physical test bench for timing, communication and firmware.
4. Keep the environments aligned - record firmware, software and configuration versions in configuration management and resynchronise acceptance after every production change.
5. Define handover criteria - test plan, test report and sign-off per phase, linked to the change process.
6. Plan the rollout - maintenance window, backup, rollback procedure and who is present at the first production run.
7. Evaluate - after rollout, compare behaviour in production with the acceptance results and improve the test scenarios.

❓ Frequently asked questions

What is the difference between OTAP and DTAP?

There is no difference in substance: OTAP is the Dutch acronym and DTAP the English one (Development, Test, Acceptance, Production). Both describe the same four separate environments that a change passes through in sequence.

Does every OT installation need four separate OTAP environments?

No, the number of environments depends on risk and cost. Many organisations combine development and test on an engineering station with simulation and keep a separate acceptance environment only for critical systems.

How do you test PLC software without a second plant?

You test PLC software with a simulator, such as S7-PLCSIM for Siemens or a TwinCAT runtime on a PC, connected to an IO or process model. For timing and communication, a test bench with the same hardware complements the simulation; virtual commissioning with a digital twin goes one step further.

Can I use production data in the OTAP test environment?

Process data without personal data is often used for realistic testing, but under the same security as production. If the data contains personal data, such as operator names in audit trails or batch records, ISO 27002 control 8.33 and the GDPR call for masking or anonymisation.

Is OTAP a legal requirement?

OTAP as a term does not appear in any law. However, ISO 27002, the BIO, GMP Annex 11 and the NIS2 duty of care require changes to be controlled and tested, and an OTAP pipeline is the common way to demonstrate that.

Where do you place the OTAP test environment in the network?

The test environment belongs in its own network zone, separated from production and the office network, with only controlled connections for transferring approved releases. This prevents a less strictly managed test environment from becoming a bridge between IT and the production zones.

📌 In summary

OTAP is a structured method for rolling out changes safely and in a controlled manner in industrial networks, by passing every change through development, test, acceptance and production. In OT this calls for smart combinations of simulation, test benches and FAT/SAT, strict separation of environments and change management, so that the risk of downtime, errors and safety issues is greatly reduced.