Compliance
Compliance claims are cheap. This page describes the actual mechanisms — where the audit trail is enforced, what a signature is bound to, and what happens when a signed record changes.
What each requirement means in this system, and how it is implemented.
| Control | Reference | How it works |
|---|---|---|
| Attributable e-signatures | 21 CFR 11.100, 11.200 | Signing re-authenticates the signer with their user ID and password at the moment of signature. A signature is bound to one person and cannot be applied on someone else's behalf. |
| Signature manifestations | 21 CFR 11.50 | Every signature records the printed name of the signer, the date and time it was executed, and the meaning of the signature — authored, reviewed, approved, acknowledged, closed or rejected. The meaning is stored, not inferred from where the button was. |
| Record–signature linking | 21 CFR 11.70 | A signature stores a hash of the exact record content it approved. If the underlying record is later revised, the prior signature remains attached to the version it actually signed. |
| Append-only audit trail | 21 CFR 11.10(e) | Audit entries are written by database triggers that reject updates and deletes outright. The application role has no privilege to rewrite history — the trail is enforced below the app, not by convention inside it. |
| Controlled versioning | 21 CFR 11.10(c) | Signed records — CAPAs, controlled documents, design reviews, change approvals — are frozen as immutable revision snapshots. From the second revision on, a documented reason for change is required by the database, and the result is a new version rather than an edit to the old one. |
| Sequencing and authority checks | 21 CFR 11.10(f), 11.10(g) | Lifecycle transitions run through guarded database functions, so a CAPA cannot close with open actions, skip effectiveness verification, or close as effective while a document it revised is still a draft or its training is unacknowledged. Role checks are enforced server-side on every query. |
| Tenant isolation | 21 CFR 11.10(d) | Limiting system access to authorised individuals is enforced twice: every query is scoped to the caller's organization, and row-level security in the database refuses cross-tenant reads for the application role, which is a non-owner with no policy escape. A forgotten predicate returns nothing rather than another company's records. |
| Accurate copies | 21 CFR 11.10(b) | Records and their full audit history export in both forms the rule asks for: a print-ready inspection copy of any CAPA, the ISO 13485 §5.6.2 management review pack, and CSV or JSON extracts of every record set. Every export is itself audited. |
Each of these shapes a surface that exists today — the workflow is derived from the predicate rules rather than bolted onto a generic ticket tracker.
Corrective and preventive action for medical devices. The eight lifecycle stages map one-to-one onto 820.100(a)(1) through (a)(7).
Electronic records and electronic signatures. Covered by the controls table above.
Design controls. User needs, inputs, outputs, verification and validation are held as a traceability matrix that names its own missing links, and a design review freezes that state — gaps included — under a signature.
Risk management for medical devices. Hazards, risk evaluation, controls and residual risk sit on the same graph as the design objects they belong to, so an unmitigated risk is visible rather than filed.
Nonconforming product. Disposition — use-as-is, rework, return to supplier, scrap — is recorded against the event with its justification, and a rework is not complete until it is re-verified against the original acceptance criteria.
Medical device reporting. Each complaint carries a recorded reportability determination, and a reportable one starts a computed 30-day or 5-working-day clock that is chased until it is filed.
Document control, training and competence, and change control. Documents become effective only by signature against a frozen revision; training is an acknowledgement of a specific version; a change reports what it touches before it can be approved.
Management review. The input pack is assembled from the records themselves, and a surface you do not run prints as a written statement rather than as a zero.
Investigation of discrepancies for drug products. The vocabulary is configurable for pharma use, though the device workflow is what ships today.
CAPAPath is compliance-ready. The technical controls described above are implemented and in the product today. Formal computer system validation — an executed IQ/OQ/PQ package against a frozen release — is staged for our design-partner build and is not yet complete.
That distinction matters, so we will not blur it. No software vendor can make your quality system compliant on its own: validation is performed against your intended use, and the regulatory obligation remains with you as the device manufacturer. What we provide is a system whose controls are built to withstand that validation, plus the documentation to support it.
If you are evaluating CAPAPath for a regulated process and need the validation package, a supplier qualification questionnaire, or a data processing agreement, .
Every record carries its organization. Each query is scoped to the signed-in user's organization and role in the server layer — never in the browser — with row-level security in the database as a backstop.
Passwords are stored only as salted hashes and are never logged. Email one-time codes are available as a passwordless sign-in option.
Quality records are retained for the life of your account, and you export them yourself at any time without asking us. Audit entries and signatures are never deleted, by design — which is also why removing someone ends their access rather than erasing them: their signatures have to stay attached to a real person.
Ask us for the controls documentation before you commit to anything.