What Are Open and Closed Systems?
21 CFR Part 11 draws a fundamental distinction between two types of environments in which electronic records are created and maintained. The distinction determines how much additional control burden falls on the organisation — and it's one of the most frequently misunderstood concepts in the regulation.
A closed system is one where access is controlled by the persons responsible for the content of the electronic records stored on the system. In plain English: the system is within your organisation's direct control, and only authorised users of your organisation can access it.
An open system is one where access is not controlled exclusively by the persons responsible for the records. This includes systems accessible via the internet, public networks, or third-party infrastructure where your organisation does not control who could potentially access the data.
"Open" and "closed" do not refer to whether the system software is open-source or proprietary. They refer to who controls access to the electronic records. A system running on open-source Linux on your own secure network is a closed system. A system running on proprietary software but accessible via the public internet is an open system.
Closed Systems — Where Most PLC/SCADA Projects Live
The vast majority of pharmaceutical automation projects operate as closed systems. Your PLC/SCADA is on the plant's operational technology (OT) network, access is controlled through your client's IT/OT security infrastructure, and only authorised site personnel can interact with the system.
For closed systems, Part 11 §11.10 applies. The requirements are the ones covered in our main Part 11 article: validation, record integrity, access control, audit trail, and electronic signatures where applicable.
Open Systems — The Additional Requirements (§11.30)
When a system is classified as open, Part 11 §11.30 adds three requirements on top of everything in §11.10. These are specifically designed to protect data integrity when the transmission path between the record and its authorised users passes through infrastructure the organisation doesn't fully control.
§11.30(a) — Document encryption
Electronic records transmitted over open networks must be encrypted to prevent unauthorised interception or modification. In practice this means TLS/SSL for web-based systems, VPN tunnels for remote connections, and encryption at rest for records stored in cloud environments.
§11.30(b) — Use of digital signatures
Where signatures are required on records in an open system, those signatures must be digital signatures as defined by appropriate standards — not simply a typed name or a scanned signature image. A digital signature cryptographically links the signer's identity to the specific record and detects any subsequent modification.
§11.30(c) — Transmission procedures and controls
Appropriate procedures and controls must exist to ensure the authenticity, integrity, and confidentiality of electronic records sent over open networks. This includes not just technical controls but documented procedures for how records are transmitted, who can transmit them, and how transmission failures are handled.
The Grey Areas — Remote Access and Cloud
The open/closed boundary becomes genuinely ambiguous in two increasingly common scenarios: remote access to an on-site SCADA system, and cloud-hosted historian or MES systems.
Remote access via VPN
If your SCADA system sits on a plant OT network but authorised engineers can connect remotely via a corporate VPN, the access control is still within your organisation's control — the VPN and the corporate network are managed by the authorised parties. This generally supports a closed system classification, particularly if the VPN uses multi-factor authentication.
However, if remote access is provided via a third-party vendor portal or a system integrator's remote desktop platform where the integrator controls the access credentials independently, the argument for closed system becomes much harder to sustain. This is a conversation to have explicitly with your client's QA team before system design is finalised.
Cloud historians and cloud SCADA
A cloud-hosted historian where data is transmitted to a third-party data centre over the internet is almost certainly an open system. The organisation does not control the transmission path, the hosting infrastructure, or who at the cloud provider could theoretically access the data. Open system requirements — encryption, transmission security — apply.
This is an area EU GMP Annex 11 (in its upcoming 2026 revision) addresses more explicitly than Part 11, which was written before cloud computing existed. For now, apply the open system controls and document your risk assessment justifying the classification.
Open vs closed system classification should be documented in your Validation Plan, agreed with the client's QA team, and justified with a brief risk assessment rationale. Do not leave it implicit. An inspector who finds no documented classification decision will assume the worst-case scenario applies — and then check whether you implemented the open system controls.
What to Do in Practice
For most PLC/SCADA projects the practical steps are straightforward:
- Document the system classification (open or closed) in the Validation Plan with a brief justification
- If closed: ensure all §11.10 requirements are met and tested in your OQ
- If open or ambiguous: add §11.30 requirements to your URS before design begins — retrofit is expensive
- For remote access: document the access control mechanism in the IQ and test authentication in the OQ
- For any cloud components: classify as open, implement encryption at rest and in transit, and document in the Validation Plan
The Validation Plan template includes a system classification section with a documented rationale template for open vs closed determination. The URS template includes optional §11.30 requirements for open system scenarios, clearly marked as conditional on classification. The OQ includes remote access test cases covering VPN authentication, session timeout, and transmission security.