21 CFR Part 11 and EU Annex 11: how SmartBook meets each clause

SmartBook publishes this mapping instead of handing it out on request. It covers every clause of 21 CFR Part 11 and the clauses of EU GMP Annex 11 that bear on an electronic lab notebook. For each one it says how SmartBook meets it, where in the code that happens, which automated tests demonstrate it, what remains the customer's responsibility, and what is not met yet.

Last revised 2026-11-10. On 2026-11-10 the count of append-only kinds of record under 11.10(c) went from 62 to 63: a breakpoint default change, which records an org admin setting the organization's default breakpoint guideline for new assays, with who did it and why, was added with this list updated in the same pull request. On 2026-11-10 the count of append-only kinds of record under 11.10(c) went from 61 to 62: a proposal decision note, which records a proposal being sent back or rejected with its note and who did it, so that a note written after a proposal holds a signature never changes a column that signature covers, was added with this list updated in the same pull request. On 2026-11-10 the count of append-only kinds of record under 11.10(c) went from 60 to 61: a proposal part approval, which records one approver's approval of one part of a proposal that needs more than one -- a new compound entered with in-house QC ranges, approved by the compound's approvers and by QA -- with the revision it approved (D111), was added with this list updated in the same pull request. On 2026-11-10 the count of append-only kinds of record under 11.10(c) went from 58 to 60: an edit the Lab Assistant proposed in chat for a QC workbook under review, and a person's accept or reject of each item of it, were added with this list updated in the same pull request. On 2026-11-10 the count of append-only kinds of record under 11.10(c) went from 57 to 58: a QC workbook suggestion, which records what the Lab Assistant suggested about the layout and names of a lab's QC workbook -- from its labels and layout, never its values -- before a person accepts any part of it, was added with this list updated in the same pull request. On 2026-11-10 work requests, assay blockers and resistance tags joined the records that keep field-level history, and 11.10(b), 11.10(e) and Annex 11 §10 now name what is not yet versioned field by field: configuration (assay templates, table recipes, import mappings, breakpoint and approval settings), labs, teams and memberships, notebooks and instrument bookings. Before that, the history page was described as covering every record and in-app configuration as versioned, which was true only of some. On 2026-11-10 the count of append-only kinds of record under 11.10(c) went from 55 to 57: a retention period, which records how long an organization keeps one kind of record before it is due for review, and a retention decision, which records a reviewer keeping a record past its period, with who and why, were added with this list updated in the same pull request. On 2026-10-19 the count of append-only kinds of record under 11.10(c) went from 42 to 55: a reference import, which records where each value on a reference sheet came from, a plate decision, which records a plate's rejection or reinstatement with its reason, a review mode change, which records an organization switching its review of new records off, to listed types or to every type, with who, when, why and whether they re-authenticated, an upload trace, which records how an uploaded file was read into an assay's data table and exactly what a row or column limit left out, a blocker's links to the blockers it waits on, with the withdrawal of a link declared by mistake, a gene call, which records one AMRFinderPlus result resolved against a strain's existing resistance tags, a transcription source, which records exactly which image and page were read and the image sent to be read, with a transcription reading, which keeps each AI model's reading of it as returned, a legal hold, which records what was placed under hold, by whom and why, with its release, an instrument's calibration and maintenance log, which records each calibration, check, qualification, maintenance, repair, excursion and change of service with who recorded it, and the history of a bug report, which records each step a report takes from reported to deployed, were added with this list updated in the same pull request. On 2026-10-11 the count of append-only kinds of record under 11.10(c) was corrected from 32 to 42 to match the code: identity verifications, signature acceptances, training records, method reviews, procedure versions, uptime readings, the assistant's import suggestions, strain import sources, changes to whether administrators generate data, and feature-switch changes had been added without the list being updated. The same file is in the source repository (docs/validation/part11-mapping.md) and is served at /brief/part-11/. When a clause's status changes, this file changes in the same pull request.

The production tier. Where this page says "the production tier", it means the tier-a configuration in this repository's infrastructure code (infra/terraform/tier-a/): those controls are defined there, and no customer data runs on that tier yet.

How to read the status.

Tests, and what they prove. The tests named below carry a @verifies("<clause>") tag in the code. Each release's Validation Summary Report lists every tagged test with its result on that release. To see the live list on any installation, run python manage.py traceability_matrix --id "21CFR11.10(e)". A tagged test demonstrates part of a clause. It does not on its own prove that the whole clause is met, which is why the narrative below states what is and is not covered.

Scope. This applies to the records SmartBook keeps under its compliance controls:

• the audit trail;
• versions of every project, experiment, assay, compound, strain and data table;
• electronic signatures and delegations;
• stored files;
• approvals;
• migrated records;
• reaction schemes, breakpoint tables, and derived results such as S/I/R calls.

Discussion comments are versioned: an edit keeps the earlier text as a version, and a removal retires the comment with a reason instead of deleting it. AI-generated content reaches a record two ways: a Lab Assistant chart or table pinned to an assay, and a Data Scientist chart or table sent from the Analysis canvas to a record. Both carry provenance recorded on the server as the assistant produced them: the model id and inference profile, the provider, the effort and an assistant version. Both are marked as AI-generated on the page and in every export, and stay pending review until a named person accepts them. That acceptance is audited, and on a signed assay it is an amendment with a reason. Postgres refuses any change to the content, its provenance or an acceptance once written. Pending content is not part of the record, and the signing panel says no signature covers it. Other assistant output is not a record: chat replies, canvas items not sent to a record, finding specs the assistant suggests into a form a person saves, and generated slide decks.

Summary

21 CFR Part 11, Subpart B: electronic records

11.10(a) Validation

Status: Shared. The system must be validated for accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

• What SmartBook provides.
• The full automated test suite runs on every merge to main. Each test that demonstrates a requirement or a clause is tagged with it.
• Every merge produces a Validation Summary Report. It contains the traceability matrix, the test results and an IQ of a reference installation.
• manage.py validation_iq and manage.py validation_oq repeat the IQ and OQ on the customer's own installation.
• Altered records are detectable in two ways. Every signature stores a SHA-256 fingerprint of the content it signed, and an hourly check reports any signed record whose content no longer matches. Hourly checks also confirm that the database triggers enforcing immutability are still in place.
• Where in the code. apps/validation/ (traceability, IQ, OQ, report), apps/pipeline/signature_lock.py (content digests and drift), apps/audit/management/commands/check_audit_integrity.py, apps/pipeline/management/commands/check_signature_integrity.py, .github/workflows/ci.yml.
• Tests. apps.pipeline.tests_signature_controls.ContentDigestTests, and the validation package's own tests in apps.validation.tests.
• The customer's part. A validation plan for the intended use, an approved risk assessment, PQ (template in docs/validation/pq-template.md), and release of the system for GxP use.
• Gaps.
• The requirements specification (docs/requirements.md) is still Draft v0.1, not an approved, frozen URS. Each report records its SHA-256 so that the exact text is named.
• The per-requirement risk classification in the matrix is a supplier draft.
• The audit trail is hash-chained, so an audit event changed by someone who bypassed the triggers is detected by the hourly check. Two limits apply. Someone holding the database owner's credentials could recompute the chain too, until its latest link is also held where the application cannot rewrite it, which is planned with the write-once audit copy. Record versions and other append-only tables are protected by triggers only, not by a chain.

11.10(b) Accurate and complete copies

Status: Partially met. Records must be available as accurate, complete copies in human-readable and electronic form, suitable for inspection.

• What SmartBook provides.
• A one-click Excel export of every record and every data table in a workspace. Readings stay exactly as typed (a value like >128 is not turned into a number), and text that looks like a formula stays text. Each export is written to the audit trail.
• A history page for each project, experiment, assay (with its data tables, results and findings), compound, strain, cell line, procedure, chemical series and MPO profile, showing each version with before and after values and the reason for the change. Other versioned records, such as lots, work requests, assay blockers and resistance tags, keep the same versions but have no history page of their own yet. Notebook entries keep every version of their own.
• Stored files that download byte-for-byte as uploaded; the tests verify this against each file's stored SHA-256.
• A full archive of the organization as one .eln file (RO-Crate 1.2): every record with its versions, signatures and comments, every data table, structures as molfiles, every attached file byte for byte (each checked against the SHA-256 recorded at upload, and any file it cannot vouch for left out and listed), and the audit trail up to and including the export. It is open to QA, Lab Admin, Org Admin and Auditor, refused on the server to anyone else, and audited.
• The organization's audit trail exports as CSV or Excel from the Activity page, each row with its hash-chain link; each export is audited.
• Any experiment, assay, compound or notebook entry exports on its own as a PDF and as JSON. Each export carries all the record's data and tables, every signature's manifestation and whether it still matches what it signed, every version with what changed and why, and the record's audit trail in its organization with each event's hash-chain link. A project or folder exports as one zip of these with a manifest. Each export is audited, and names a verification hash that a reader can recompute from the JSON; the PDF prints it with a QR code.
• Where in the code. apps/pipeline/workbook_export.py, apps/core/xlsx_export.py, apps/history/, apps/files/views.py, apps/core/record_export.py, apps/pipeline/record_export.py, apps/notebooks/record_export.py.
• Tests. apps.pipeline.tests_workbook_export.ExportWorkbookTests, apps.pipeline.tests_workbook_export.EngineTests, apps.files.tests.UploadAndDownloadTests, apps.pipeline.tests_record_versions.VersionCaptureTests, apps.pipeline.tests_record_export, apps.notebooks.tests_record_export.
• Gaps.
• The PDF is not digitally signed itself. It is tied to the record by its verification hash, which is checked against the JSON export.
• The PDF's fonts print Latin-1 only. A character outside it, such as a Greek letter, prints as "?", and a first-page warning says so; the JSON holds the exact text.
• The PDF draws no charts, curves, reaction schemes or structures, and attached files are not inside it; the JSON and the .eln archive carry them.

11.10(c) Protection of records

Status: Partially met. Records must be protected so they can be retrieved accurately and readily throughout the retention period.

• What SmartBook provides.
• Every kind of record built on the append-only base is refused changes and deletion both by the application and by a PostgreSQL trigger. The IQ and the hourly check take that list from the code, not from a document. At this release there are 63 kinds:
• audit events, their seals and scopes, and signed audit-trail reviews;
• gene calls, each resolved against a strain's existing resistance tags, never a new one;
• record versions;
• notebook entry versions and entry template versions;
• signatures on entries and on records, signature delegations and their revocations;
• compound structures and reaction schemes;
• breakpoint tables, their rows, and derived results such as S/I/R calls;
• point exclusions, QC range tables, QC ranges and QC dispositions;
• plate decisions, which reject or reinstate a plate with a reason;
• instrument log events: each calibration, performance check, qualification, maintenance, repair, excursion and change of service, numbered and chained per instrument;
• reference bioactivity with the lookups that fetched it;
• reference imports, which say which source cell every value on a reference sheet was read from;
• upload traces, which say how each uploaded file was read into an assay's data table and what a row or column limit left out;
• stored files and their fixity verifications;
• retired usernames and access reviews;
• identity verifications, signature acceptances and training records;
• inventory ledger lines;
• approval revisions, approvals of one part of a proposal decided in parts, the notes of a proposal sent back or rejected, and action handoffs;
• changes to an organization's default breakpoint guideline for new assays, with who and why;
• reviews of calculation methods, and procedure (SOP) versions;
• uptime readings;
• the assistant's suggestions for an import's column mapping, and each imported strain's link to the file it came from;
• the assistant's suggestions for reading a lab's QC workbook, which a person accepts part by part, and the edits it proposes in chat, with each person's accept or reject;
• the sources of a table read from an image, and each AI model's reading of them;
• changes to whether administrators may generate data, feature-switch changes, and changes to the organization's review mode;
• migration runs, migrated-record markers and historical signatures;
• a blocker's links to the blockers it waits on, and their withdrawals;
• legal holds and their releases;
• retention periods, and reviewers' decisions to keep a record past its period;
• the history of each bug report, from reported to deployed.
• Nothing a person removes is deleted. It is retired, with a reason.
• A legal hold placed by QA or an Org Admin on a record, a project or a person's records stops anything it covers being retired until the hold is lifted. Lifting asks for the password again and needs a reason, and every QA and Org Admin is told. The hold and its release are themselves append-only.
• An organization may set, per kind of record, how many years a record is kept before it is due for review. There is no default period, and a period never retires or deletes anything: a record past it is listed for QA or an Org Admin, who keeps it for a further period or retires it from its own page, with the same checks as any other retire, which a legal hold still refuses. A record on hold is never due. The periods and the decisions to keep are append-only.
• Once a record carries an Author signature, its signed content is locked in the database as well.
• On the production tier, the database, both object-storage buckets and the volumes are encrypted with one rotating customer-managed KMS key, which the customer holds when the stack runs in the customer's own AWS account. The database runs Multi-AZ with automated backups, and both buckets have Object Lock (write-once) retention in governance mode, which an AWS user granted that specific permission can override. The audit bucket is not yet written to: the audit trail itself lives in the database, append-only and hash-chained, and a write-once copy outside the database is planned.
• Where in the code. apps/core/models.py (AppendOnlyModel), the trigger migrations in each app (for example apps/audit/migrations/0002_auditevent_appendonly_trigger.py), apps/pipeline/migrations/0055_signed_record_lock_triggers.py, apps/history/engine.py, apps/history/holds.py, apps/history/retention.py, infra/terraform/tier-a/ (rds.tf, s3.tf, kms.tf).
• Tests. apps.notebooks.tests.AppendOnlyDbTriggerTests, apps.core.tests_truncate.TruncateGuardTests, apps.pipeline.tests_signature_controls.DatabaseLockTests, apps.files.tests.ImmutabilityTests, apps.pipeline.tests_record_versions.VersionCaptureTests.test_versions_are_append_only_at_the_database_layer, apps.approvals.tests.RevisionTests.test_revisions_are_append_only_at_the_database_layer, apps.pipeline.tests_legal_hold_236.AHeldRecordCannotBeRetiredTests.
• Gaps.
• The application's database role is not yet separated from the role that owns the tables, so the protections hold against every application code path but not against someone holding the owner's credentials (an infrastructure change awaiting the owner's decision). Every append-only table also refuses TRUNCATE, and the audit trail is hash-chained, so a change made with the owner's credentials to an audit event is detected, though not prevented.
• No backup restore drill has been performed on the production tier. The recovery steps, the integrity checks to run after a restore and the drill procedure are written down in docs/assurance/dr-runbook-tier-a.md.
• The audit trail is not yet copied to the write-once bucket.
• Retention is not configurable per organization (NFR-5.1). The current behaviour, deleting nothing, is the safe default.
• A legal hold covers records, not the bytes of a stored file on a tier whose bucket expires them; holding those needs S3 Object Lock legal holds, an infrastructure change awaiting the owner's decision.

11.10(d) Limiting system access

Status: Met. Access must be limited to authorized individuals.

• What SmartBook provides.
• Every workspace page and API call requires an authenticated, active account.
• Every record lookup is scoped to the user's organization; another organization's record answers "not found".
• Two-step verification (TOTP) is available, and an organization can require it for everyone.
• Single sign-on through SAML 2.0 or OIDC, which an organization can make the only way to sign in.
• Per organization: a network allow-list, checked at sign-in and on every request, and an idle sign-out shorter than the platform default. On the production tier the platform default is 30 minutes.
• Sign-in attempts are throttled with an escalating lockout.
• Accounts are deactivated, never deleted.
• Where in the code. apps/core/permissions.py, apps/orgs/permissions.py, apps/accounts/ (mfa.py, middleware.py, policy.py, sso.py, throttle.py), _user_org_ids in apps/pipeline/views/common.py.
• Tests. apps.notebooks.tests.EntryApiRbacTests, apps.files.tests.OrgIsolationTests, apps.core.tests_settings.SessionIdleDefaultTests, apps.accounts.tests_mfa.EnforcementMiddlewareTests, apps.accounts.tests_sso.OIDCSignInTests, apps.accounts.tests_sso.SAMLSignInTests, apps.accounts.tests_sso.OrgPolicyTests, apps.accounts.tests_sso.SSOScopeTests, apps.accounts.tests_sso.PenTestRegressionTests, apps.pipeline.tests_browser.LoginFormTests.
• The customer's part. Deciding who is authorized, granting and revoking access, and reviewing access periodically. The access review page lists who can reach the organization and records each review. Deactivation is done in the administration site.

11.10(e) Audit trail

Status: Partially met. The audit trail must be secure, computer-generated and time-stamped, independently recording the date and time of every entry and action that creates, modifies or deletes a record. A change must not obscure what was recorded before. The trail must be kept as long as the record and be available for review and copying.

• What SmartBook provides.
• Every create, view, edit, sign, failed signature, export, permission change, sign-in, failed sign-in, sign-out and two-step event is recorded with its actor, action, target, details and a server-generated UTC timestamp.
• The actor always comes from the authenticated session, never from the request, so it cannot be supplied by the client.
• Audit events are append-only in the application and in the database, and no role (administrators included) can add, change or delete one, through the administration site or otherwise.
• Every change to a versioned record writes an immutable version holding the full content, the field-level old and new values, who made the change, when and why. Earlier versions are never overwritten. Versioned records include projects, experiments, assays and their data tables, compounds, lots, strains, cell lines, procedures, work requests, assay blockers and resistance tags.
• An hourly check confirms the immutability triggers, including a guard against TRUNCATE, are present and enabled on every append-only table.
• Every audit event is sealed into a SHA-256 hash chain, normally within a minute of being written. The hourly check walks the whole chain. A changed event, a missing or altered link, or an event left unsealed for more than 15 minutes raises a compliance alert and notifies every QA and Org Admin. Nothing repairs itself.
• The installation check reports whether the host clock is NTP-synchronized and whether the database and application clocks agree within 2 seconds.
• An organization-wide audit review on the Activity page: filters, seven review-by-exception lists, each change with its reason, on-demand chain verification, audited CSV and Excel exports with each row's chain link, and signed reviews that ask for credentials again, are append-only, and hold a SHA-256 digest of exactly the events they cover.
• Changes made through the Django administration site are written to the same trail: every create, edit and delete, by any role, with the field-level old and new values. Changes to memberships, roles, account access, groups, single sign-on and the organization's security policy are recorded as permission changes. Passwords and secrets are recorded as "changed", never their values. A test fails if an administration page that can write is not audited.
• Where in the code. apps/audit/ (models.py, services.py, signals.py, mixins.py, admin_audit.py), apps/history/engine.py, apps/core/models.py.
• Tests.
• Append-only audit trail: apps.audit.tests.AuditEventAppendOnlyTests, apps.audit.tests.AuditAdminTests, apps.audit.tests.AppendOnlyTriggerCoverageTests.
• What gets recorded: apps.notebooks.tests.VersioningAndAuditAtomicityTests, apps.notebooks.tests.EntryApiRbacTests.test_spoofed_actor_in_request_body_is_ignored, apps.pipeline.tests.RecordHistoryTests.
• Versions and reasons: apps.pipeline.tests_record_versions.VersionCaptureTests, apps.pipeline.tests_record_versions.ReasonAndAmendmentTests.
• Administration-site changes: apps.audit.tests_admin_audit.AdminAuditTests, apps.audit.tests_admin_audit.AdminAuditCoverageTests.
• Tamper evidence: apps.audit.tests_chain.AuditChainTests, apps.core.tests_truncate.TruncateGuardTests.
• Gaps.
• Timestamps come from the application server's clock. The installation check verifies its synchronization, but the timestamp is not taken from the database or from a trusted third party.
• The hash chain protects an event from when it is sealed, normally under a minute after it is written, not from the moment it is written. Events that existed before the chain were sealed when it was installed, so for them the chain proves only that they have not changed since then. The chain's order is the order events were sealed, which can differ slightly from timestamp order when transactions finish out of order.
• Someone holding the database owner's credentials could rewrite an event and recompute the chain. Holding the chain's latest link where the application cannot rewrite it is planned with the write-once audit copy.
• Not every editable row is versioned field by field yet. Configuration (assay templates and their sheets, table recipes, import mappings, breakpoint settings, organism-group mappings, stage document requirements, approval policies), labs, teams and memberships, notebooks (the container; its entries keep their own versions) and instrument bookings are not.

11.10(f) Operational system checks

Status: Met. The system must enforce the permitted sequence of steps and events.

• What SmartBook provides.
• The Author signature comes first and only once.
• Review and witness signatures are possible only after it.
• One person signs once per version.
• An organization's signing workflow can fix the order of countersignatures and the roles allowed at each step.
• An approval cannot be approved twice.
• Changing a locked record is an amendment that needs a reason and re-opens signing.
• An assay whose QC strains read out of range, or whose results have no QC reading, cannot be signed by anyone until a person records a reasoned decision to accept or invalidate the run. A check that has not run yet is run before signing rather than taken as passed.
• Where in the code. apps/pipeline/signing.py, apps/pipeline/delegation.py (save_workflow), apps/approvals/services.py, apps/history/engine.py, apps/pipeline/qc.py.
• Tests. apps.pipeline.tests.PipelineSigningServiceTests, apps.pipeline.tests.PipelineSignViewTests, apps.pipeline.tests_record_versions.WorkflowTests, apps.signatures.tests.SignEntryTests.test_signing_twice_is_rejected, apps.approvals.tests.ApprovalTests.test_a_proposal_cannot_be_approved_twice, apps.pipeline.tests_qc.SigningGateTests.
• The customer's part. Configuring the signing workflow each kind of record needs.

11.10(g) Authority checks

Status: Partially met. Only authorized individuals may use the system, sign records, access the operation or the device, alter records or perform operations.

• What SmartBook provides.
• Six roles (Scientist, Reviewer/PI, QA, Lab Admin, Org Admin, Auditor), each with a fixed set of capabilities; QA and Auditor cannot write or sign.
• Nobody reviews or witnesses their own record.
• Workflow steps can be limited to roles.
• Only an administrator changes a workflow or runs a migration.
• Administrators are separated from data generation (PIC/S PI 041): Org Admin manages access but neither creates, signs nor approves data. An organization that must combine the duties turns on admins_generate_data, which changes only with a reason, writes an append-only AdminDataGenerationChange and a PERMISSION_CHANGE audit event, and is read-only in the administration site.
• Delegated signing authority is time-boxed, limited to named meanings and recorded.
• An approver can never approve their own proposal.
• The administration site cannot create, change or delete a regulated record: notebook entries, experiments, assays, compounds, signatures, stored files, comments, approval proposals, and every append-only or versioned record are read-only there.
• A password an administrator sets, for a new account or as a reset, must be replaced by its owner before they can reach anything else. The reset and the change are both in the audit trail.
• Where in the code. apps/orgs/models.py (CAN_*), apps/orgs/permissions.py (can_write, can_sign), apps/orgs/segregation.py, apps/pipeline/signing.py, apps/pipeline/delegation.py, apps/approvals/services.py, apps/audit/admin_audit.py (ReadOnlyAuditedAdmin), apps/accounts/middleware.py (PasswordChangeRequiredMiddleware).
• Tests. apps.notebooks.tests.EntryApiRbacTests, apps.pipeline.tests.PipelineSignViewTests.test_a_role_that_may_not_sign_is_refused, apps.pipeline.tests.PipelineSigningServiceTests.test_the_author_cannot_review_or_witness_their_own_record, apps.pipeline.tests_record_versions.DelegationTests, apps.approvals.tests.SegregationOfDutiesTests, apps.orgs.tests.MembershipRbacTests, apps.orgs.tests_admin_segregation, apps.accounts.tests_password_change.AdminSetPasswordMustBeChangedTests.
• Gaps.
• A password reset needs one administrator, not two. The owner must replace the password at next sign-in, so a reset cannot go unnoticed, but dual control is not enforced.

11.10(h) Device checks

Status: Partially met. Where appropriate, the system checks that data or instructions come from a valid source.

• What SmartBook provides. An organization can restrict use to its own networks. The allow-list is checked at sign-in and on every request, so a session cannot be carried off the network.
• Where in the code. apps/accounts/policy.py.
• Tests. apps.accounts.tests_sso.OrgPolicyTests.test_the_network_allowlist_is_checked_at_sign_in_and_on_every_request.
• Gaps. There are no instrument or terminal integrations yet (FR-11), so there are no checks on instrument sources. The customer decides where device checks apply to their intended use.

11.10(i) Training

Status: Customer responsibility. People who develop, maintain or use the system must have the education, training and experience for their tasks.

• What SmartBook provides. In-app guided tours and walkthroughs. Training and qualification records, kept append-only on the Training records page (QA and administrators record them; withdrawing one is a new record). An organization can name a signing qualification; signing there is then refused, on every route, unless the signer has it current and unexpired.
• Where in the code. apps/orgs/models.py (TrainingRecord, Organization.signing_qualification), apps/accounts/procedural.py, apps/pipeline/views/people.py (training_view).
• Tests. apps.accounts.tests_procedural.TrainingGateTests.
• The customer's part. Training and qualification of users and administrators, with records.

11.10(j) Written policies

Status: Customer responsibility. The organization must have written policies that hold people accountable for actions taken under their electronic signatures.

• What SmartBook provides. Every signature dialog states the meaning of the signature being applied. Before a first signature, on every route (password or identity-provider re-authentication), the person accepts a statement that their electronic signature is the legally binding equivalent of their handwritten one and that they are accountable for what is signed under it. The acceptance is append-only, keeps the statement's text as accepted, and is in the audit trail.
• Where in the code. apps/accounts/procedural.py, apps/accounts/models.py (SignatureAccountability), apps/pipeline/signing.py (verify_ceremony).
• Tests. apps.accounts.tests_procedural.SignatureAccountabilityTests.
• The customer's part. The policy, and making sure every signer has read it.

11.10(k) Control of system documentation

Status: Shared. Documentation for operating and maintaining the system must be controlled: distribution, access, and a time-sequenced record of changes.

• What SmartBook provides.
• The supplier's documentation lives in the source repository, so every change is versioned, attributed and reviewed as a pull request.
• Every user-visible change ships with a What's New entry.
• Each Validation Summary Report names the exact requirements text by its hash.
• The customer's part. Controlling its own SOPs and work instructions for SmartBook.
• Gaps. The user and administrator manuals (docs/validation/manuals/) are drafts with document IDs and change logs, but they are not yet approved or under document control.

11.30 Controls for open systems

Status: Partially met. Where the system is open (access not controlled by the people responsible for the records), additional measures such as encryption and digital signature standards are needed.

• What SmartBook provides.
• Each deployment is single-tenant. In the offered model it runs in the customer's own AWS account, which makes it a closed system in most customers' assessment.
• Encryption is used regardless of that assessment:
• TLS on every connection, with HTTPS enforced, secure cookies and HSTS on the hosted tiers;
• storage encrypted with a customer-held KMS key on the production tier;
• signatures bound to content by SHA-256.
• Where in the code. config/settings.py (secure_transport_for_tier), infra/terraform/tier-a/.
• Tests. apps.core.tests_settings.SecureTransportGuardTests.test_tls_terminating_tiers_are_strict.
• Gaps.
• The application does not yet verify the database server's certificate. The IQ reports this as a warning on the production tier.
• SmartBook does not use PKI-based digital signatures.

11.50(a) Signature manifestation

Status: Met. A signed record shows the signer's printed name, the date and time of signing, and the meaning of the signature (such as review, approval, responsibility or authorship).

• What SmartBook provides. Every signature shows:
• the signer's name and title, both kept as they were at the moment of signing;
• the date and time with the time zone labelled;
• the meaning: Authored, Reviewed or Witnessed.

A delegated signature records both the delegate and the person they signed for. A notebook entry is signed by its author only, as Authored.

• Where in the code. apps/pipeline/models.py (PipelineSignature), apps/pipeline/signing.py, apps/signatures/models.py, apps/signatures/services.py.
• Tests. apps.pipeline.tests.PipelineSigningServiceTests.test_the_signature_records_title_and_a_content_digest, apps.pipeline.tests.PipelineSignViewTests.test_the_manifestation_shows_title_timezone_and_an_unchanged_fingerprint, apps.signatures.tests.SignEntryTests.test_correct_password_signs_atomically_and_returns_manifestation, apps.pipeline.tests_record_versions.DelegationTests.test_a_delegate_signs_for_the_delegator_and_both_are_recorded, apps.notebooks.tests_entries.EntrySigningTests, apps.notebooks.tests_pages.SignPageTests.

11.50(b) Manifestation under the same controls

Status: Met. These details are controlled like the record itself and appear in every human-readable form of it.

• What SmartBook provides. The manifestation is stored in the append-only signature record. It appears on the record's page and its history, in the export's signatures sheet, and in the record's PDF and JSON export next to the content it signs, with whether each signature still matches that content.
• Tests. apps.pipeline.tests.PipelineSignViewTests.test_detail_page_shows_signature_and_lock_state, apps.pipeline.tests.PipelineSignViewTests.test_the_manifestation_shows_title_timezone_and_an_unchanged_fingerprint, apps.pipeline.tests_record_export.SignatureManifestationTests, apps.notebooks.tests_record_export.EntryExportTests.

11.70 Signature/record linking

Status: Met. Signatures are linked to their records so they cannot be excised, copied or otherwise transferred to falsify a record.

• What SmartBook provides.
• Each signature names its record and the exact version it was made on, and carries a SHA-256 fingerprint of that version's content. It is append-only.
• After an Author signature, the database refuses changes to the signed content. Workflow fields such as the stage can still change.
• An amendment writes a new version; the old signatures stay attached to what they actually signed.
• The record page shows whether each signature still matches, and an hourly check raises an alert on any mismatch.
• The material used for a record (inventory ledger lines) is fingerprinted in a fixed order. Signatures made before 2026-10-19 hashed those lines in the order the database returned them, and two containers drawn in one action could come back in either order, so an untouched record could read as changed. Such a signature still matches if its fingerprint equals that of the same lines with only the simultaneous ones reordered; any other difference is a mismatch. No stored fingerprint is recomputed or rewritten.
• A QC decision on an assay (accept or invalidate a run whose QC did not pass) carries no separate signature: it is part of the content the Author signature made after it fingerprints, and one recorded on a signed assay is an amendment.
• A compound's signed content covers its structure through the append-only structure row it points at, never through computed keys. The registration key (the InChIKey plus an enhanced-stereo qualifier) and the parent key are derived attributes outside the signed content. When the identity or standardizer rules change, a reviewed re-key updates only those keys: by a Lab Admin, with a reason, versioned in the compound's history with the old key. The structure pointer never moves, so no signature reads as drifted. apps.pipeline.tests_stereo_identity.ReviewedRekeyTests runs the signature integrity sweep before and after a re-key.
• An approval signature on a proposal names the revision that was current when it was made, and its fingerprint covers that revision's id and content as well as the proposal's own fields. Before 2026-11-10 an approval's fingerprint covered the proposal's own fields (kind, target, accepted checks) but not the proposed content, which is held on its append-only revision; those signatures still verify exactly as made, and nothing is recomputed. A later revision is new content, which the approver signs with a fresh ceremony. Every decision on a proposal (approve, reject, send back) names the revision the decider had on screen, and a decision on a revision that is no longer the latest is refused under the proposal's row lock, so nothing unseen is signed or applied; a decision that names no revision is refused the same way. In a proposal approved in parts (D111), the findings a part's approver accepts are kept on that part's append-only approval row for the revision, and that signature's fingerprint covers them, so accepting again on a later revision never changes what an earlier part's signature covers.
• Notebook entries: a signature names the append-only entry version it signed and carries a SHA-256 fingerprint of that version's content, including the hash of every image it shows. Once an entry is signed, the database refuses a new version and any change to the entry's state, title or current version. A signed entry is closed rather than amended. Entry signatures made before fingerprinting carry no fingerprint and are bound by the append-only version they name.
• Where in the code. apps/pipeline/signature_lock.py, apps/pipeline/signing.py, apps/pipeline/migrations/0055_signed_record_lock_triggers.py, apps/pipeline/management/commands/check_signature_integrity.py, apps/notebooks/integrity.py, apps/notebooks/migrations/0005_signed_entry_lock.py.
• Tests. apps.pipeline.tests_signature_controls.ModelLayerLockTests, apps.pipeline.tests_signature_controls.DatabaseLockTests, apps.pipeline.tests_signature_controls.ContentDigestTests, apps.pipeline.tests_record_versions.LockAndAmendmentTests, apps.pipeline.tests.PipelineSigningServiceTests.test_signature_rows_are_append_only, apps.notebooks.tests_entries.FingerprintTests, apps.notebooks.tests_entries.SignedEntryDatabaseLockTests, apps.notebooks.tests_entries.LegacySignatureMigrationTests, apps.pipeline.tests_qc.SignatureDigestTests, apps.pipeline.tests_signed_digest_order_776, apps.pipeline.tests_proposal_signature_933, apps.approvals.tests_seen_revision_974, apps.approvals.tests_part_acceptance_975.

21 CFR Part 11, Subpart C: electronic signatures

11.100(a) Uniqueness

Status: Met. Each electronic signature is unique to one individual and is never reused by, or reassigned to, anyone else.

• What SmartBook provides.
• Every signature references the account that made it and keeps the signer's name as it was. Accounts are never deleted: history protects them, so they can only be deactivated.
• A username can never be changed, and once used it is never given to another account, even if the original account is gone. Case does not matter: "JSmith" and "jsmith" are the same name. The database enforces this, not only the application, and the installation check confirms its triggers are in place.
• Where in the code. apps/accounts/models.py (UsedUsername, User.save), apps/accounts/migrations/0009_usedusername.py, apps/validation/iq.py (check_identity_triggers).
• Tests. apps.accounts.tests_usernames.UsernameIsNeverReassignedTests.

11.100(b) Identity verification

Status: Customer responsibility. The organization verifies a person's identity before establishing, assigning or certifying their electronic signature.

• What SmartBook provides. Single sign-on lets the customer's identity provider, where identity proofing usually lives, decide who gets an account. Creating an account records how the person's identity was verified, append-only and audited. The administration site's new-account form requires the method and what was checked; an account made at first sign-in records the identity provider's verification.
• Where in the code. apps/accounts/models.py (IdentityVerification), apps/accounts/admin.py (AccountCreationForm), apps/accounts/sso.py (complete_login).
• Tests. apps.accounts.tests_procedural.IdentityVerificationTests.

11.100(c) Certification to FDA

Status: Customer responsibility. The organization certifies to FDA that its electronic signatures are the legally binding equivalent of handwritten ones.

• What SmartBook provides. A template for the letter: fda-certification-letter.md.

11.200(a)(1) Two identification components

Status: Met. A non-biometric signature uses at least two distinct components, such as an ID code and a password. The first signing in a continuous session uses all of them; later signings in the same session use at least one.

• What SmartBook provides.
• The first signing in a session asks for the username and password, plus the two-step code for anyone enrolled. Every signing path does this: record pages, the notebook entry page and the entries API.
• Later signings within 30 minutes of the last full one ask for the password alone. After that, or in a new session, the full ceremony returns. The window is configurable.
• A wrong credential signs nothing and is recorded in the audit trail.
• An account that signs in only through single sign-on, and has no password SmartBook can check, signs by re-authenticating at its identity provider. The provider is forced to ask again, and the server refuses an authentication older than two minutes. Each confirmation is good for one signature.
• Where in the code. apps/pipeline/signing.py (verify_ceremony), static/js/sign.js, config/settings.py (SIGNING_CONTINUOUS_SESSION_SECONDS).
• Tests. apps.pipeline.tests_signature_controls.CeremonyTests, apps.pipeline.tests_browser.SignModalTests, apps.signatures.tests.SignEntryTests, apps.pipeline.tests.PipelineSigningServiceTests.test_wrong_password_raises_and_does_not_sign, apps.accounts.tests_sso.OrgPolicyTests.test_an_sso_only_account_is_told_why_it_cannot_sign.

11.200(a)(2) Used only by the genuine owner

Status: Shared. A signature can be used only by its genuine owner.

• What SmartBook provides.
• Signing re-checks the signer's own credentials, and the username entered must be the signed-in user's.
• A notebook entry can be signed only by its author, and only as Author. On an assay, experiment or compound, the person who applies the Authored signature is recorded as its author, and cannot also review or witness that version.
• Tests. apps.pipeline.tests_signature_controls.CeremonyTests.test_a_wrong_username_signs_nothing, apps.signatures.tests.SignEntryTests.test_only_author_may_sign.
• The customer's part. A policy that credentials are never shared, and enforcement of it (11.10(j)).

11.200(a)(3) Misuse requires collaboration

Status: Partially met. Using someone else's signature must require two or more people to collaborate.

• What SmartBook provides.
• Signing needs the owner's password, and their two-step code when enrolled. An organization can require two-step verification for everyone.
• Repeated wrong passwords at signing are throttled like sign-in.
• Tests. apps.pipeline.tests_signature_controls.CeremonyTests.test_repeated_wrong_passwords_are_throttled.
• Gaps. A single administrator can still reset another user's password, sign in with it, choose a new one and then sign as that user, unless the user is enrolled in two-step verification. This cannot go unnoticed: the reset and the change are both in the audit trail, and the owner finds their password no longer works. But it is detected afterwards, not prevented, because the reset does not need a second person. Dual control of password resets is not yet provided.

11.200(b) Biometric signatures

Status: Not applicable. SmartBook does not offer biometric signatures.

11.300(a) Unique identification code and password combinations

Status: Met. No two people can have the same combination of ID code and password.

• What SmartBook provides.
• Usernames are unique, cannot be changed, and are never given to a second account.
• Passwords must be at least 12 characters; an organization can raise the minimum.
• Common and all-numeric passwords are refused.
• Tests. apps.core.tests_settings.SecureTransportGuardTests.test_the_minimum_password_length_is_raised_above_djangos_default, apps.accounts.tests_sso.OrgPolicyTests.test_an_org_can_require_longer_passwords, apps.accounts.tests_usernames.UsernameIsNeverReassignedTests.

11.300(b) Periodic checking and revision

Status: Shared. ID codes and passwords are periodically checked, recalled or revised, for example to cover events such as password aging.

• What SmartBook provides.
• Deactivation, and an organization-level password minimum.
• A password an administrator sets must be replaced by its owner at next sign-in.
• Password expiry and reuse history are available per organization but off by default, following NIST SP 800-63B. An organization whose procedure requires aging can set how many days a password lasts and how many earlier passwords may not be reused.
• An organization can switch off a member's access automatically after a set number of days without signing in. The change is audited and attributed to a named system account, never to a person.
• An access review page shows QA, Org Admins and Auditors everyone who can reach the organization: role, last sign-in, two-step status and password age. Recording a review keeps the list exactly as seen, with its fingerprint, in an append-only record. Reviewers are reminded when a review is overdue.
• Where in the code. apps/accounts/policy.py, apps/accounts/lifecycle.py, apps/accounts/middleware.py.
• Tests. apps.accounts.tests_password_change.AdminSetPasswordMustBeChangedTests, apps.accounts.tests_password_policy.PasswordExpiryTests, apps.accounts.tests_password_policy.PasswordHistoryTests, apps.accounts.tests_lifecycle.InactiveSweepTests, apps.accounts.tests_lifecycle.AccessReviewTests.
• The customer's part. Turning on the settings its procedure requires, and carrying out and recording the periodic access reviews.

11.300(c) Loss management

Status: Partially met. Lost, stolen or compromised tokens and credentials are deauthorized, and replacements are issued with suitable controls.

• What SmartBook provides.
• A user can remove their two-step device. This needs their password and is audited.
• Recovery codes work once each.
• An administrator can deactivate an account.
• An administrator resetting someone's two-step device through the administration site is audited against that user, with the secret never recorded.
• An administrator can reset a forgotten password. The owner must then choose a new one before reaching anything else, and both steps are audited.
• Tests. apps.accounts.tests_mfa.VerificationTests.test_disable_removes_the_device_and_audits, apps.accounts.tests_mfa.VerificationTests, apps.audit.tests_admin_audit.AdminAuditTests.test_a_two_step_device_reset_is_audited_against_its_user_with_no_secret, apps.accounts.tests_password_change.AdminSetPasswordMustBeChangedTests.
• Gaps.
• There is no self-service reset of a forgotten password. An administrator resets it, and the owner then chooses their own. A reset link sent by email would be new attack surface, so it is held.

11.300(d) Transaction safeguards

Status: Partially met. Safeguards prevent unauthorized use of passwords and ID codes, and detect attempted misuse and report it immediately and urgently to the system's security unit.

• What SmartBook provides.
• Failed sign-ins, failed signing re-authentication and failed two-step codes are each recorded in the audit trail.
• Every sign-in attempt is logged, including those against unknown usernames.
• Sign-in and signing are throttled with an escalating lockout.
• A replayed single sign-on response is refused.
• Bursts are reported within five minutes. For repeated failed sign-ins against one account, the organization's QA and Org Admins and the account holder are told. For failed sign-ins from one network address across any usernames, the platform's operators are told. For repeated failed signatures by one person, the organization's QA and Org Admins are told. Each burst alerts once, and every alert is kept.
• Where in the code. apps/accounts/throttle.py, apps/accounts/alerts.py, apps/audit/signals.py, apps/pipeline/signing.py, apps/accounts/sso.py.
• Tests. apps.accounts.tests.LoginThrottleUnitTests, apps.accounts.tests.LoginAttemptLogTests, apps.audit.tests.FailedLoginSignalTests, apps.pipeline.tests_signature_controls.CeremonyTests.test_repeated_wrong_passwords_are_throttled, apps.pipeline.tests.PipelineSigningServiceTests.test_wrong_password_records_sign_failed_reauth_audit_event, apps.accounts.tests_alerts.BurstAlertTests.
• Gaps. Alerts are delivered inside SmartBook, as notifications and a logged security alert. Nothing is sent outside it, by email or paging, so a burst outside working hours waits until someone signs in.

11.300(e) Testing of devices that generate codes

Status: Shared. Devices that bear or generate ID codes or passwords, such as tokens and cards, are tested at the start and periodically to ensure they work and have not been altered.

• What SmartBook provides. Two-step codes use the open TOTP standard (RFC 6238), and SmartBook's implementation is checked against the RFC's published test vectors on every build.
• Tests. apps.accounts.tests_totp.Rfc6238VectorTests, apps.accounts.tests_totp.TotpBehaviourTests.
• The customer's part. Testing any hardware tokens it issues.

EU GMP Annex 11

§1 Risk management

Status: Shared. Risk management applies across the lifecycle, taking patient safety, data integrity and product quality into account.

• What SmartBook provides. Each release's traceability matrix carries a draft GxP risk level for every requirement, so an untested high-risk requirement stands out.
• The customer's part. The risk assessment for the customer's intended use, which decides the extent of validation and of data-integrity controls.

§2 Personnel

Status: Customer responsibility. Personnel have the qualifications, access levels and responsibilities their duties need. See 11.10(i).

§3 Suppliers and service providers

Status: Partially met. Formal agreements set out responsibilities; the regulated user assesses its suppliers, and the supplier's documentation is available for review.

• What SmartBook provides.
• This mapping, published openly.
• The validation package (docs/validation/README.md).
• A SOC 2 readiness assessment and a penetration-test plan (docs/assurance/).
• Gaps.
• No SOC 2 report yet, and no third-party penetration test yet.
• The assessments of SmartBook's own suppliers, AWS, Amazon Bedrock and GitHub (docs/validation/suppliers/), are drafts from public evidence only. They are not approved, and the suppliers' SOC 2 reports have not been read.

§4 Validation

Status: Shared. Validation documentation and reports cover the lifecycle. There is an up-to-date list of user requirements with traceability, and evidence of the test methods and scenarios used. Data migration is validated.

• What SmartBook provides.
• The requirements specification with a traceability matrix, built from tags in the tests, that lists every requirement including those no test covers.
• Test evidence from every merge.
• IQ and OQ that the customer can run.
• Migration from Revvity E-Notebook has a dry run that changes nothing, file checksums, and a reconciliation report of what the source exported, what the bundle held and what was imported.
• Tests. The validation package's own tests (apps.validation.tests), apps.migration.tests.DryRunTests.test_a_dry_run_reports_everything_and_writes_nothing, apps.migration.tests.ImportTests.test_the_report_reconciles_source_bundle_and_imported.
• The customer's part. The validation plan, PQ and the validation report for its use.
• Gaps. The URS is not yet approved and frozen. See 11.10(a).

§5 Data

Status: Partially met. Systems that exchange data electronically include built-in checks that the data is entered and processed correctly and securely.

• What SmartBook provides.
• Every stored file has a SHA-256, and downloads are verified against it in the tests.
• Uploads are identified by their content, not by the type they claim.
• Migration bundles are checked file by file against their manifest.
• A QC range table is imported only when every row is readable: a value off the doubling-dilution series in a EUCAST or CLSI table, a low end above the high end, or two ranges for one strain and agent refuses the whole file, and the file's SHA-256 and each row's line are kept.
• Stored files are re-verified against their SHA-256 on a schedule, the longest-unverified first. A file whose bytes changed, or that is missing from storage, raises a compliance alert, an audit event in its organization and a notification to its QA and Org Admins. Nothing is rewritten, and every check is kept in an append-only log.
• Tests. apps.files.tests.UploadAndDownloadTests.test_uploaded_file_downloads_back_byte_identical, apps.migration.tests.DryRunTests.test_a_changed_file_fails_its_checksum, apps.pipeline.tests_qc.QCCsvImportTests, apps.files.tests_fixity.FindingTests.
• Gaps.
• There are no instrument interfaces yet.
• On the production tier the scheduled checks, this one included, need the Redis broker the tier-a configuration does not yet have (the runbook's §1); until then they are run by hand.

§6 Accuracy checks

Status: Partially met. Critical data entered manually gets an extra accuracy check, by a second person or by validated electronic means.

• What SmartBook provides. For the kinds of record an organization chooses to gate, review-before-record holds each change as a proposal until a second, authorized person approves it with a signature. Submitters cannot approve their own proposals. Review and witness signatures are a second-person check on any signed record.
• Tests. apps.approvals.tests.SegregationOfDutiesTests, apps.approvals.tests.ApprovalTests.test_approving_mints_a_reviewed_signature.
• The customer's part. Deciding which data is critical and turning on review for it.
• Gaps. Review is per kind of record and opt-in. It is not yet available for individual values in data tables.

§7.1 Data storage

Status: Partially met. Data is secured by physical and electronic means against damage, and stays accessible, readable and accurate throughout the retention period. See 11.10(c).

• What SmartBook provides. Stored files are checked on a schedule for being present and unchanged. See §5.
• Tests. apps.files.tests.ImmutabilityTests, apps.files.tests.UploadAndDownloadTests.test_uploaded_file_downloads_back_byte_identical, apps.files.tests_fixity.FindingTests.

§7.2 Backups

Status: Partially met. Relevant data is backed up regularly, and the integrity of backups and the ability to restore them are checked during validation and periodically.

• What SmartBook provides. On the production tier, automated database backups (14 days) and Multi-AZ.
• Gaps. No restore drill has been run, and there is no backup vault lock yet. The business continuity runbook is written (docs/assurance/dr-runbook-tier-a.md); its drill has not been run.

§8.1 Printouts

Status: Partially met. Clear printed copies of electronically stored data can be obtained. See 11.10(b).

• What SmartBook provides. A PDF of any experiment, assay, compound or notebook entry, with its signatures and audit trail.
• Tests. apps.pipeline.tests_workbook_export.ExportWorkbookTests, apps.pipeline.tests_record_export, apps.notebooks.tests_record_export.
• Gaps. The PDF prints Latin-1 only: a Greek letter prints as "?", with a first-page warning that the JSON holds the exact text.

§9 Audit trails

Status: Partially met. Based on risk, the system records all GMP-relevant changes and deletions with their reason, and audit trails are available, convertible to an intelligible form, and regularly reviewed. See 11.10(e).

• What SmartBook provides.
• A reason is required for every change to a signed record and for every retirement.
• Nothing is deleted.
• Each version shows its before and after values and its reason.
• Regular review: the Activity page's organization-wide review, with review-by-exception lists and a signed review sign-off.
• Tests. apps.pipeline.tests_record_versions.ReasonAndAmendmentTests, apps.pipeline.tests_record_versions.RetireTests, apps.files.tests.UploadAndDownloadTests.test_retire_requires_a_reason, apps.audit.tests.AuditEventAppendOnlyTests.
• Gaps.
• A reason is not required for changes to an unsigned draft; this is by design, because a draft is still being written.

§10 Change and configuration management

Status: Shared. Changes to a computerized system, including its configuration, are made in a controlled way under a defined procedure.

• What SmartBook provides.
• Every code change is a pull request that runs the full test suite and ships with release notes and a fresh Validation Summary Report.
• Single-tenant deployments let each customer decide when to take an upgrade.
• Some in-app configuration that shapes records is versioned and audited, for example an organization's signing workflows.
• Tests. apps.pipeline.tests_record_versions.WorkflowTests.test_workflow_changes_are_versioned_and_audited.
• The customer's part. Change control over its own instance: when to upgrade, and impact assessment.
• Gaps.
• A second person's review before a change is merged is not yet enforced by the repository.
• Other in-app configuration is not yet versioned field by field: assay templates and their sheets, table recipes, import mappings, breakpoint settings, organism-group mappings, stage document requirements and approval policies.

§11 Periodic evaluation

Status: Customer responsibility. Systems are evaluated periodically to confirm they remain valid and compliant.

• What SmartBook provides. Material for the evaluation:
• a Validation Summary Report for every release;
• hourly integrity checks;
• the IQ, which can be re-run at any time.

§12.1 Security: access controls

Status: Met. Physical and logical controls restrict access to authorized people. See 11.10(d). Physical security of the hosting is AWS's, under its own certifications.

• Tests. apps.notebooks.tests.EntryApiRbacTests.test_cross_org_retrieve_is_not_found, apps.files.tests.OrgIsolationTests, apps.orgs.tests.MembershipRbacTests.test_scientist_cannot_grant_membership.

§12.3 Access authorization changes recorded

Status: Met. Creating, changing and cancelling access authorizations is recorded.

• What SmartBook provides. Granting a membership through the application, and creating or revoking a signing delegation, are recorded in the audit trail as permission changes. So is every access change made through the Django administration site: memberships and roles, account access (active, staff, administrator, groups, passwords), team memberships, approval policies, single sign-on providers and the organization's security policy, each with its old and new values.
• Tests. apps.orgs.tests.MembershipRbacTests.test_org_admin_can_grant_membership_and_it_is_audited, apps.audit.tests_admin_audit.AdminAuditTests, apps.audit.tests_admin_audit.AdminAuditCoverageTests.

§12.4 Operator identity on data changes

Status: Met. Systems record the identity of the operator who enters, changes, confirms or deletes data, with the date and time.

• What SmartBook provides. Every version and every audit event names its actor, taken from the session, with a UTC timestamp. A record created through approval is attributed to the person who submitted it, and the approval to the approver.
• Tests. apps.pipeline.tests_record_versions.VersionCaptureTests, apps.notebooks.tests.EntryApiRbacTests.test_spoofed_actor_in_request_body_is_ignored, apps.approvals.tests.ApprovalTests.test_the_created_record_is_attributed_to_the_submitter_not_the_approver.

§13 Incident management

Status: Shared. Incidents, not only system failures and data errors, are reported and assessed, and their root cause is identified.

• What SmartBook provides. Security findings are tracked as issues labelled security, and each Validation Summary Report lists those still open. When an hourly integrity check fails, it logs a compliance alert. A broken audit chain and a failed inventory ledger check also notify QA and Org Admins in the application; the signature check does not yet.
• The customer's part. Its incident procedure for its use of the system.
• Gaps. A failed integrity check notifies people inside the application but does not page anyone outside it. There is no written incident response plan yet (docs/assurance/soc2-readiness.md).

§14 Electronic signatures

Status: Met. Electronic signatures have the same impact as handwritten ones within the company, are permanently linked to their record, and include the time and date of signing. See 11.50, 11.70 and 11.200.

• Tests. apps.pipeline.tests_signature_controls.ContentDigestTests, apps.pipeline.tests_signature_controls.ModelLayerLockTests, apps.signatures.tests.SignEntryTests.test_correct_password_signs_atomically_and_returns_manifestation.

§15 Batch release

Status: Not applicable. SmartBook is a research notebook and does not certify batches for release.

§16 Business continuity

Status: Shared. There are provisions so that systems supporting critical processes stay available if they break down.

• What SmartBook provides. On the production tier, a Multi-AZ database with automated backups.
• The customer's part. Business continuity planning for its processes.
• Gaps. No documented, tested recovery runbook with a measured recovery time and recovery point yet.

§17 Archiving

Status: Partially met. Archived data is checked for accessibility, readability and integrity.

• What SmartBook provides. Nothing is deleted. A full .eln archive carries the workspace's projects, experiments, assays, compounds, lots, strains, cell lines, requests and notebook entries with their history and signatures, every attached file checked against its stored SHA-256, and the audit trail; designs, procedures, breakpoint tables, workflows, approvals, training records, role holdings, the instrument register, legal holds, gene calls and image transcriptions are not yet in it. The production tier's object storage is configured write-once (Object Lock, governance mode) with long retention.
• Gaps.
• The audit trail is not yet written to the write-once store.
• A legal hold covers records, not the bytes of a stored file on a tier whose bucket expires them; that needs S3 Object Lock legal holds.