Responsibility by Clause (draft)
Goal: For each clause, see which of the four parties does what.
NOTE
Draft
Each "What the clause asks" cell is a short paraphrase, to be checked against eCFR (for Part 11) and the published Annex 11 before publishing. Read the rule itself, not this summary. Built means OpenX does this today. Coming means it is specified and not built yet. No row says a clause is met: that is for your QA and your auditor.
The four parties are OpenX, your app, your login system (the directory in App Identity) and your QA. See the Validation Pack for who each one is.
Every row has one more line for your QA: it validates the whole process, as you run it. Vendor data alone is not enough.
21 CFR Part 11 §11.10: controls for closed systems
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §11.10(a) | The system is validated | Publishes this pack, the trace, the IQ and OQ outline and a change notice per release (draft) | Validates its own signing flow | Is part of the validated set-up | Owns the validation and its decision |
| §11.10(b) | Accurate, complete copies in readable and electronic form | Full signature records on read; CSV and JSON export (built); a printable certificate (coming) | Shows signatures where people need them | None | Chooses which copies inspectors get |
| §11.10(c) | Records are protected for their retention period | Storage in your subscription; retention periods; Protected, then Locked when you press Lock permanently (built) | None | None | Sets retention and decides when to lock |
| §11.10(d) | Access is limited to authorised people | The sign right Workspace.Provenance.Sign (built); API Manager rules on the sign route (built) | Decides who may sign what, in its own screens | Holds the accounts | Reviews who holds access |
| §11.10(e) | Secure, time-stamped audit trails | The Provenance hash chain, server time on every record (built); refused signings recorded (coming) | None | Keeps its own sign-in log | Reviews the trail; keeps the login system's log as long as needed |
| §11.10(f) | Operational checks enforce the order of steps | Signature ceremonies; the optional two-person rule (built) | Enforces its own order of steps (for example, review before approval) | None | Defines the order in procedures |
| §11.10(g) | Authority checks | The sign right, and the meaning checked against the workspace's list (built) | Decides which meaning a person may use; OpenX does not read that from its access rules | None | Defines who may sign with which meaning |
| §11.10(h) | Device checks, where needed | None | Checks its own input sources | Applies its own device policy | Decides where this applies |
| §11.10(i) and (j) | Training, and written policies that hold people accountable for their signatures | Documents the product (this site) | None | None | Owns training and the policy |
| §11.10(k) | Control of system documentation | Dated docs and a change notice per release (draft) | Controls its own documentation | Controls its own documentation | Controls the copies it relies on |
§11.50: what a signature shows
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §11.50(a)(1) | The signer's printed name | SignerPrintedName from the login's verified name, on every signature (coming); a login with no name is refused (coming) | Never sends the name itself; a name in the request is ignored | Gives the name claim in its ID token | Confirms the name reads as a printed name |
| §11.50(a)(2) | Date and time of signing | SignedAt, from the server clock, in UTC (built) | None | None | None |
| §11.50(a)(3) | The meaning of the signature | Meaning, checked against the workspace's list (built) | Shows the meaning in the "you are signing this" moment | None | Sets the workspace's list of meanings |
| §11.50(b) | Those items are under the same controls as the record, and appear in readable forms | The whole signature is sealed and chained (built); the certificate shows each item, as text, never as an image (coming) | Shows them where it shows the record | None | Confirms the readable forms it relies on |
§11.70: linking a signature to its record
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §11.70 | A signature is linked to its record so it cannot be cut, copied or moved to another record by ordinary means | BindingDigest is the server's own digest of the record; a digest the signer did not see writes nothing; the link is re-checked on every read, verify and export; each signature is sealed by your workspace's own Key Vault key (built). The login itself is made for that record and meaning (coming) | Sends the digest it showed; uses the published nonce function (coming) | None | Decides on the storage level; the link's strength rests on storage refusing changes, which is firmest once Locked |
§11.100: general requirements
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §11.100(a) | Each signature belongs to one person and is never reused by or given to anyone else | Refuses jobs (built); refuses apps, AI calls and other non-persons by name (coming); one same-person rule across sign-ins (coming) | Never signs on its own word | Gives each person their own account | Forbids shared accounts in procedure |
| §11.100(b) | The organisation verifies a person's identity before giving them a signature | None: OpenX does not check identity documents | None | Holds the verified accounts | Owns identity checks |
| §11.100(c) | The organisation certifies to FDA that its electronic signatures are binding | None | None | None | Owns the certification |
§11.200: signature components and controls
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §11.200(a)(1) | At least two distinct components, such as an ID and a password | Checks a fresh login from your login system, made for this record, used once; keeps the login time and methods on the signature (coming) | Starts a forced login for each signing | Asks for the components, and must really ask (see below) | Sets the login policy and tests it |
| §11.200(a)(1)(i) and (ii) | Within one continuous session, the first signing uses every component and later ones at least one; outside one session, every component each time | Each login signs once, so each signature rests on its own login (coming) | Forces a login per signing, or per batch | Honours the forced login | Decides how its sessions read against this clause |
| §11.200(a)(2) | Used only by its genuine owner | The login's person must be the caller (coming); a different person's login is refused (built for today's sign-in again) | Keeps tokens on its server | Authenticates the person | Owns account hygiene |
| §11.200(a)(3) | Misuse needs two or more people to collaborate | An app-made token is never the proof (coming), so holding an app's key is not enough to sign; the optional two-person rule (built) | Never makes tokens that stand for a person | Issues the only accepted proof | Decides where two people are required |
| §11.200(b) | Biometric signatures | Not applicable: OpenX has no biometric signature | None | Any biometric factor is its own | Decides if it applies |
The limit no design removes. OpenX sees that a login happened, not that a password was typed again. A single sign-on bounce can look like a fresh login. So your login system or your app must force the login, and your validation must test it.
§11.300: identification codes and passwords
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §11.300(a) | No two people share the same ID and password pair | None: OpenX keeps no passwords | None | Keeps accounts unique | Checks it |
| §11.300(b) | Codes and passwords are checked or renewed from time to time | None | None | Its password and account policy | Sets the period |
| §11.300(c) | Lost or compromised credentials are withdrawn and replaced under control | None | None | Disables and reissues | Owns the procedure |
| §11.300(d) | Safeguards stop unauthorised use and report attempts | Records refused signings (coming); signature events for refusals (coming) | Reports what it refuses | Locks out and logs failed logins | Reviews and acts on the reports |
| §11.300(e) | Devices that carry codes, such as tokens or cards, are tested | None | None | Its own devices | Owns the tests |
EU Annex 11 §14: electronic signature
| Clause | What the clause asks (paraphrase) | OpenX | Your app | Your login system | Your QA |
|---|---|---|---|---|---|
| §14 (a) | The same effect as a handwritten signature within the company | None: this is the company's rule | None | None | Owns the policy |
| §14 (b) | Permanently linked to the record | As §11.70 above (built, and the login tie is coming) | As §11.70 | None | As §11.70 |
| §14 (c) | Includes the date and time it was applied | SignedAt, server clock, UTC (built) | None | None | None |
Next steps
- Each control and its tests -> Trace
- What to run -> IQ and OQ outline
On this page
- Responsibility by Clause (draft)
- ╰─▶21 CFR Part 11 §11.10: controls for closed systems
- ╰─▶§11.50: what a signature shows
- ╰─▶§11.70: linking a signature to its record
- ╰─▶§11.100: general requirements
- ╰─▶§11.200: signature components and controls
- ╰─▶§11.300: identification codes and passwords
- ╰─▶EU Annex 11 §14: electronic signature
- ╰─▶Next steps