Open vs. Closed Systems Under 21 CFR Part 11

The distinction between an open and a closed system under 21 CFR Part 11 is based on control of system access, not on whether the software is cloud-hosted, connected to the internet, or supplied by a third party.

This distinction matters because open systems require the controls appropriate to closed systems plus additional measures, such as document encryption and suitable digital-signature standards, where needed to protect authenticity, integrity, and confidentiality. For the complete framework, see our FDA 21 CFR Part 11 electronic signatures guide.

The regulatory definitions

Part 11 defines a closed system as an environment in which access is controlled by the people responsible for the content of the electronic records on the system.

An open system is an environment in which access is not controlled by those responsible for the content of the electronic records.

The key question is therefore: who controls access throughout the relevant record lifecycle?

Why cloud does not automatically mean open

A cloud application can operate as part of a closed system only when the persons responsible for the content of the electronic records control access to the relevant environment. A service provider's administrative role must be assessed within that control model; cloud hosting, contractual authorisation, or validation alone does not determine the classification.

Conversely, a locally installed application can participate in an open system if records move through channels or environments outside the responsible organisation’s access control.

Classification should follow the actual workflow, including integrations, external collaborators, email delivery, file transfer, archival repositories, and recipient access. Once the boundary is defined, use it to set the depth of software validation and the required audit-trail controls.

Controls for closed systems

Section 11.10 identifies controls designed to protect authenticity, integrity, confidentiality where appropriate, and non-repudiation. They include:

• system validation;
• accurate and complete record copies;
• record protection and retrieval;
• authorised access;
• secure, time-stamped audit trails;
• operational and authority checks;
• device checks where appropriate;
• qualified and trained personnel;
• accountability policies;
• documentation and change control.

These controls should be applied according to intended use and risk, together with applicable predicate-rule requirements.

Additional controls for open systems

Section 11.30 requires controls designed to protect electronic records from creation to receipt. It incorporates the § 11.10 controls as appropriate and calls for additional measures such as encryption and appropriate digital-signature standards when necessary.

Potential controls include:

• encryption in transit and at rest;
• strong recipient authentication;
• cryptographic integrity protection;
• digital signatures where the risk warrants them;
• controlled links with expiration and access restrictions;
• secure exchange protocols;
• monitoring for unauthorised access;
• verifiable receipt and delivery evidence.

The right combination depends on the sensitivity of the record, the parties involved, and how much control the responsible organisation retains.

A practical classification workflow

Map each stage:

1. Where is the record created?
2. Who can access or change it?
3. How are users identified and authorised?
4. Does it leave the controlled environment?
5. Which external parties or platforms handle it?
6. How is integrity protected during transmission?
7. Where are the final record and audit evidence retained?

Classify the workflow at its weakest relevant boundary. A process may contain both closed and open segments, requiring different controls at different points.

Questions for vendors and system owners

Ask:

• Can access be restricted by named user, role, and organisation?
• Which authentication methods are available?
• Can external recipients be authenticated to the required level?
• Are signed records and evidence cryptographically protected?
• What is recorded in the audit trail?
• Can administrators alter completed records or audit history?
• How are APIs authenticated and monitored?
• Can complete records be exported for inspection and migration?
• How are encryption keys and credentials managed?

Answers should be verified against the configured workflow, not accepted as generic marketing claims.

How eSign.AI supports controlled signing

eSign.AI supports access-controlled workspaces, configurable signer authentication, signing order, electronic and digital signature options, event evidence, and integrations with business systems. These controls can support closed-system workflows and higher-assurance exchanges that cross organisational boundaries.

The regulated organisation should still document the system classification, validate intended use, select controls appropriate to risk, and maintain procedures for access, records, training, change, and incident management.

Sources and further reading

• 21 CFR § 11.3 — Definitions
• 21 CFR § 11.10 — Controls for closed systems
• 21 CFR § 11.30 — Controls for open systems