Compliance · Electronic records and signatures
21 CFR Part 11 conformance.
Last updated 2026-05-02. KumoKodo, Inc. asserts that Kodori implements the technical controls specified in 21 CFR Part 11 — Electronic Records; Electronic Signatures — Subparts B (Electronic Records, §§11.10, 11.30, 11.50, 11.70) and C (Electronic Signatures, §§11.100, 11.200, 11.300). The technical substrate is live today; customer-side procedural controls (training, certification filing, written SOPs) remain the customer’s responsibility.
Scope
This conformance claim addresses the technical substrate Kodori provides. 21 CFR Part 11 is a shared-responsibility regulation: the system must support the controls (Kodori’s scope) and the regulated organization must operate the system in conformance (the customer’s scope, per §11.10(i), §11.10(j), and §11.100(c)). Kodori does not transmit a representation that any particular customer’s use is conformant — that determination is the customer’s and their FDA inspector’s.
Subpart B — Electronic Records (§11.10)
Closed-system controls. All twelve subsections of §11.10 are mapped below. Where the requirement is procedural rather than technical, the customer-side responsibility is identified explicitly.
| Section | Requirement | Kodori control |
|---|---|---|
| §11.10(a) | Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. | Hash-chained audit log: every event in the per-tenant stream stores `prev_hash` = SHA-256 of the previous event. The `verifyAuditChain` MCP tool walks the chain end-to-end. A weekly Inngest cron (`audit-chain-verify-weekly`) verifies every tenant chain and emits `audit.verification.completed` on a sister stream — auditors get continuous tamper-evidence going back arbitrarily far. |
| §11.10(b) | The ability to generate accurate and complete copies of records in both human-readable and electronic form suitable for inspection, review, and copying by the agency. | Audit log CSV export with date + actor filters at /audit. Document-content export at /api/v1/documents/[id]/blob (original bytes) and /api/v1/documents/[id]/text (extracted text). Conversation export as Markdown / text via /api/agent/conversations/[id]/export. |
| §11.10(c) | Protection of records to enable their accurate and ready retrieval throughout the records retention period. | Content-addressable storage: SHA-256 of the document IS the storage key — modification produces a new hash, not a silent overwrite. Object Lock / WORM lands for legally-held blobs at retention-class enforcement. Tombstones are soft deletes (status flip) during the retention window; hard purge runs at retention-class expiry on a cron with a longer grace period. |
| §11.10(d) | Limiting system access to authorized individuals. | SSO-only authentication via Google Workspace or Microsoft Entra ID — no Kodori passwords exist. WorkOS SAML/SCIM as escape hatch for SAML-only contracts. Permission-trimmed retrieval at the SQL index — a user without read access never sees a search hit, dashboard count, or extracted-text snippet. |
| §11.10(e) | Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. | Every consequential mutation appends an event to the hash-chained log with `actorId`, `actorKind` (user / agent / system), `eventType`, `subjectId`, `payload` (before/after where relevant), and a server-clock timestamp (immutable client clock skew is rejected upstream). The chain is per-tenant; chain integrity in tenant A does not depend on tenant B. |
| §11.10(f) | Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. | Reversible-transaction model: every agent transaction is preview-then-commit, and consequential actions (delete, restore, sensitivity-change, retention-change, hold-change, bulk over 10) require explicit user confirmation before commit. Hold-deny-wins gate enforces sequencing for held documents (delete refused, retention disposal refused, sensitivity downgrade refused). |
| §11.10(g) | Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand. | Role-based access control (RBAC) with deny-rules-always-win composition. The agent uses the exact same `canReadDocument` gate the UI uses — there is no agent-bypass. Authority for legal-hold custodians is captured per-row on the hold record and enforced at the deny gate. |
| §11.10(h) | Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction. | Device fingerprinting via Auth.js session metadata (user-agent, IP, geo-region) recorded at each sign-in. Anomaly detection cron flags off-hours sign-ins, sudden device changes, and high-volume reads against a 7-day baseline. Inbound webhook devices (Cloudflare Email Worker, customer-side webhooks) sign with HMAC-SHA256 over `<timestamp>.<body>` — replay protection via 5-minute drift check. |
| §11.10(i) | Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks. | Customer-side responsibility. Kodori provides /help articles for every major workflow and the optional onboarding drip sequence with 21 CFR Part 11 references for QMS-tier customers. |
| §11.10(j) | The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures. | Customer-side responsibility (operator policy) — Kodori provides the technical mechanism (every action carries `actorId`; sign-in is identity-provider-anchored; policy violations are anomaly-flagged). |
| §11.10(k)(1) | Use of appropriate controls over systems documentation, including adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance. | System documentation lives in-platform under /help and is permission-gated by the same RBAC layer as document content. Versioning + audit-trail apply uniformly. |
| §11.10(k)(2) | Revision and change-control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation. | Document versioning model: every document edit creates a new version with monotonic version number; the prior version is preserved. Side-by-side diff at /doc/[id]/versions. Every version creation emits a `document.version-created` event. |
Subpart B — Signature Manifestations (§11.50, §11.70)
| Section | Requirement | Kodori control |
|---|---|---|
| §11.50(a) | Signed electronic records shall contain information associated with the signing that clearly indicates the printed name of the signer, the date and time of the signature, and the meaning (such as review, approval, responsibility, or authorship) associated with the signature. | Every event row carries `actorId` (FK to the users table — printed name + email resolvable), the server-clock `createdAt` timestamp, and `eventType` (which encodes the meaning — `document.tombstoned`, `document.classified`, `document.legal-hold-applied`, etc.). |
| §11.50(b) | The information described in paragraph (a) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout). | Audit metadata is rendered alongside record content in the document detail page, in CSV exports, and in API responses. Same hash-chain protection applies. |
| §11.70 | Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. | Linkage: every event row carries `subjectId` (the document, collection, hold, or retention class the action targets) plus the `prev_hash` chain dependency. Excising a signature/event from the log breaks the chain and is detected at next verification — by the on-demand verifier, by the weekly cron, or by deposition counsel inspecting the chain. |
Subpart C — Electronic Signatures (§§11.100, 11.200, 11.300)
| Section | Requirement | Kodori control |
|---|---|---|
| §11.100(a) | Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. | Identity is anchored to the SSO provider’s `sub` claim — uniqueness and non-reassignment are enforced by Google Workspace / Microsoft Entra ID lifecycle rules. Local users table mirrors the SSO `sub` claim; `actorId` references this row. |
| §11.100(b) | Before an organization establishes, assigns, certifies, or otherwise sanctions an individual’s electronic signature... the organization shall verify the identity of the individual. | Identity verification is delegated to the customer’s SSO provider — the customer’s IT / HR onboarding processes are the verification step. |
| §11.100(c) | Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. | Customer-side responsibility — the customer files the certification with FDA. Kodori provides the technical substrate that makes the certification supportable. |
| §11.200 | Electronic signatures that are not based upon biometrics shall employ at least two distinct identification components such as an identification code and password. | SSO-only auth via Google Workspace / Microsoft Entra ID delegates to multi-factor authentication enforced at the IdP. WorkOS SAML/SCIM honors the IdP’s MFA posture. No passwords are set on Kodori. Sign-in provides two distinct components (the SSO session token + the IdP’s MFA challenge). |
| §11.300(a) | Maintaining the uniqueness of each combined identification code and password. | Not applicable — Kodori does not store passwords. Identity uniqueness is enforced at the IdP. |
Validation evidence
- Audit-chain integrity: the on-demand `verifyAuditChain` MCP tool, the /audit dashboard verify-button, and the weekly cron all run identical code (shared helper at `packages/events/src/verify.ts`). Output is a per-event chain pass/fail with the row identifier of the first divergence.
- Test fixtures: deterministic hash-chain regression fixtures live in `packages/evals/src` and run on every CI pull request. 88 test cases as of 2026-05-01.
- Soft-tamper-evidence demos: available on request — we run a controlled tamper (modify an event, recompute the chain) and show how the verifier surfaces the divergence.
Inspection cooperation
KumoKodo will reasonably cooperate with FDA inspections that touch a customer’s use of Kodori, including providing control documentation, system architecture diagrams, and access-log evidence as the customer authorizes under their DPA. Inspection cooperation is part of the executable DPA available via security@kumokodo.ai.
Cross-references
- Security & compliance overview
- SOC 2 controls mapping
- How the audit log works
- Legal hold workflow
- Sensitivity model
Questions
Email compliance@kumokodo.ai or security@kumokodo.ai.