Skip to main content

    21 CFR Part 11: what the Ivy record covers

    How Ivy's hash-chained, time-stamped audit trail maps to FDA 21 CFR Part 11, clause by clause: what the platform provides today and what your team adds.

    complianceauditpart-11gxp

    FDA 21 CFR Part 11 sets the conditions under which electronic records and signatures are trusted in place of paper. No software is "Part 11 compliant" on its own: compliance belongs to a regulated organization's validated system, procedures and people. What a platform can do is supply controls those procedures rely on.

    This page maps each relevant clause to what Ivy provides today and what remains your team's job. Ivy's Part 11 readiness is in progress, and the status page tracks it. The mechanism behind the audit-trail rows is described in The audit trail of a run.

    Clause by clause

    ClauseWhat it asks forWhat Ivy provides todayWhat you still need
    §11.10(a) ValidationA system validated for accuracy, reliability and consistent performanceNothing that substitutes for validation. Ivy publishes no validation package todayYour own risk-based validation of the workflows you rely on
    §11.10(b) CopiesAccurate, complete copies in human-readable and electronic formPer-job export with raw inputs, parameters, audit trail and checksums; a chain-of-custody report as JSON or HTMLConfirmation that the export covers your record definition. A chat's long message bodies sit outside the chain
    §11.10(c) Record protectionRecords retrievable throughout their retention periodRecords are kept, and the hash-chained logs are retained even through erasure requestsEnforced retention periods and legal holds, which Ivy does not yet offer
    §11.10(d) Limited accessAccess limited to authorized individualsAuthentication with multi-factor support; database row-level security scoped to your tenantYour user provisioning and review procedures
    §11.10(e) Audit trailSecure, computer-generated, time-stamped audit trails of record creation, modification and deletion that do not obscure earlier entriesEvery event of a signed-in run is hash-chained (SHA-256), rolled into Merkle roots, and time-stamped by an RFC 3161 authority. You can verify a chat's chain yourselfA reason-for-change field (none today). Note that a single event's timestamp is not covered by its hash; the time-stamp covers the chain segment
    §11.10(g) Authority checksOnly authorized individuals can use the system or alter recordsRole-based access control across organization, project and chatYour role assignments
    §11.10(k) Documentation controlsControl over system documentationPublic docs and a dated changelogYour controlled copies and change control
    §11.50, §11.70 SignaturesSigned records show the signer, time and meaning, and signatures are linked to their recordsNot available. Ivy has no electronic-signature workflow in productionAn e-signature step outside Ivy, or wait for this row to move
    §11.100, §11.300 IdentificationUnique user identity and controls on credentialsA unique identity per user, multi-factor authentication, and API keys bound to an accountYour identity proofing and credential procedures

    What the audit trail adds

    Many AI and LLM tools keep logs that whoever runs the database can change without trace. Ivy's record is different in one checkable way: a change to any recorded event breaks the chain, and you can run the check from your own account without asking Ivy for anything. The RFC 3161 time-stamps come from an outside authority, so they do not depend on trusting Ivy's own clock for when a segment existed.

    The boundary matters as much as the claim. The chain detects modification; it does not prevent it, and a privileged database role can still edit rows. Treat the record as tamper-evident evidence that feeds your procedures, not as a substitute for them.

    Was this page helpful?

    On this page

    On this page

    Loading...