Electronic signatures and Part 11

An electronic signature in X7 Insight is a legally binding attestation: a specific person, at a specific moment, certified a specific snapshot of data with a specific meaning. The signature is designed for 21 CFR Part 11 (Subpart C) and EU Annex 11: it carries the signer’s printed name, the date-time, and the meaning, and is inseparably linked to the signed data.

0:000:00

Signing a form with re-authentication — the signer certifies a snapshot of the data

What makes a signature 'legally binding'

Three things together: (1) it belongs to a single person and cannot be reused; (2) at the moment of signing a fresh authentication is performed — it is not enough that you are already logged in; (3) it is permanently bound to that exact snapshot of data — change the data, and the signature is automatically invalidated.

How a signature is applied

A signature is applied on the form page (the signature.apply permission). The steps:

1. Choosing the coverage. What exactly you are signing — a single form, an entire visit, or the subject’s entire casebook. The investigator can sign the whole casebook with a single Part 11 act.
2. The coverage manifest. The system assembles the exact list of covered form instances and the versions of their values, and shows a coverage preview (what is already signed, what will be included for the first time).
3. Reauthorization. You confirm your identity anew — see below. The current session token is not enough.
4. The signature’s meaning. You choose a meaning from the canonical catalog.
5. Commit. A signature record is created with a fingerprint of the snapshot of the covered data, along with an event and a record in the audit trail.

Where to sign

The queue of forms awaiting signature is visible to the signer (usually the PI) in their tasks, but the signing itself always happens on the form page. For the step-by-step scenario, see Sign, lock, export.

Reauthorization: fresh authentication for every signature

Every signature requires re-confirming the identity of the signer specifically — the fact that a session is open does not matter (Part 11 §11.200(a)). The confirmation is a personal factor of the signer (one of):

• re-entering the password — for a user with password login (the core’s default method); the signer’s identifier comes from the authenticated session and the password is entered afresh — together they form the Part 11 §11.200(a)(1) signature components;
• the signer’s own current one-time TOTP code — if the factor is configured it is preferred and checked first;
• a fresh login check at the identity provider (OIDC) for the same user.

A single TOTP code cannot be used for two signatures — reuse of a code is blocked; repeated wrong attempts temporarily lock the factor out. The confirmation method is recorded in the signature record itself. Sharing your credentials with another person is forbidden by policy: a signature is a personal act.

A signature is not a 'checkbox'

Reauthorization deliberately takes effort: you are certifying data under your own name and responsibility. The organization is required to have a written policy on accountability for actions taken under an electronic signature (Part 11 §11.10(j)).

The meaning of a signature

The meaning is taken from the canonical catalog — you cannot enter arbitrary text. The core catalog has two values:

Meaning	When it is used
Responsibility for data	the signer accepts responsibility for the data
Review and approval	the signer has reviewed and approved the data

Informed consent (eConsent) is deliberately absent from the catalog: consent is an act of the subject within the ICF process outside the EDC, not a meaning of the investigator’s signature over a CRF.

The meaning is shown on all views of the signed record and on all printed forms — next to the signer’s printed name and the date-time (Part 11 §11.50).

What is visible on a signed record (the Part 11 manifestation)

On any page and in any printed copy of a signed value, the following are displayed:

• the signer’s printed name (captured at the moment of signing and not changed, even if the profile changes later),
• the date and time in UTC (plus a local representation for convenience),
• the signature’s meaning.

This also holds in the print-ready HTML casebooks of the closeout package, where a registry of electronic signatures accompanies the data.

Binding to data and auto-invalidation

A signature captures a cryptographic fingerprint of the snapshot of the covered values: for each field — the value, its version, and its completion status. From then on, a rule that cannot be turned off applies:

valid → any covered value changes →

invalidated

• Any edit of a covered value, a new row in a log (a repeating section), or clearing a completion mark → the signature automatically moves to the “invalidated” state (a system action, with an audit record and an event).
• This rule cannot be disabled — this is the essence of Part 11 §11.70: a signature is inseparably linked to the record and cannot be “transferred” to changed data.
• Invalidation is terminal: re-signing is a new signature record. The old record is never deleted; it remains in the history with the “invalidated” status.

Editing data under a valid signature

If you edit a field covered by a valid signature, the interface warns you: saving will invalidate the signature, and re-signing will be required. The same happens with an amendment that tightens the rules (mandatoriness, ranges): signatures become stale and must be applied again.

The signature and the design version

A signature captures not only the values but also the design version (StudyVersion) and the versions of the approved translations — this is critical for electronic consent (eConsent), where the exact wording the participant saw is what matters.

Verifying signatures and integrity

Signatures rely on the same trust mechanism as the audit trail: their application and invalidation are recorded in the immutable hash chain. The chain’s integrity is checked with the Verify trail integrity button — see Audit trail. Both the inspection packet and the closeout package include a registry of electronic signatures together with chain verification.

Audit trailThe immutable journal and the hash-chain verification that signatures are bound to.

Sign, lock, exportA practical scenario: how to sign a form, a visit, or a casebook.

Lifecycles and status axesSignature statuses and related axes: SDV, completion, lock.

Permissions catalogsignature.apply, SoD constraints, and who can sign.