Skip to content

Electronic Signatures

Every approval, review, attestation, and sign-off in QStack — across every module — runs through the same electronic signature mechanism. This page explains how signing works once, so the module pages can simply say "sign with meaning X" without repeating the mechanics.

Signing meanings

Every signature event carries a declared signing meaning, set when the signing field was created. QStack presents the meaning to you at the moment you sign, and records it permanently. The meanings you'll encounter across the system are:

Meaning Typically used for
Authored Confirming you wrote the content
Reviewed and approved Document and record reviews
Read and understood Training read-and-understood attestations
Attest to accuracy Onboarding import batch attestations
Performed the work Completing a CAPA or change-control action
Witnessed the activity Confirming you observed an activity take place
Verified the information Reviewing someone else's completed work
Authorised for release Final approvals — document effectiveness, CAPA closure, change closure, complaint closure, Vendor Summary Reports
Custom Free text, used only where your tenant has configured it, with an auditor justification on file

You can't sign with the wrong meaning by accident — the field you're signing already carries the meaning it needs, and that's what gets shown to you and recorded.

Sign a document

The signing flow is the same wherever you encounter it — approving an SOP, attesting to training, closing a CAPA action, or signing a Vendor Summary Report:

  1. Open the item from your inbox or from the object itself.
  2. Review the content you're being asked to sign — QStack won't let you sign something you haven't opened.
  3. Click Sign. QStack shows you the declared signing meaning for this field before you commit.
  4. Re-authenticate: confirm your identity again at the moment of signing — with your password, MFA, or passkey, depending on your tenant's authentication policy. Being logged in isn't enough on its own; the signature has to be backed by an authentication event of its own.
  5. QStack records the signature: your identity, the timestamp, your IP address, the signing meaning, and the authenticator method you used — and, if you signed with a passkey, the credential ID, the authenticator's AAGUID, the user-verification flag, and the signature counter.

Strong authentication for final approvals

Your tenant's policy can require a passkey or biometric specifically for final approvals, even if password-plus-MFA is your default authentication method everywhere else.

Segregation of duties

A person can never review or approve an item they authored or performed themselves, regardless of what roles they hold — this floor applies per-object, not per-role, so holding multiple roles (common in a small quality unit) doesn't create a loophole.

Because a one-person quality unit can make this genuinely impossible in practice, QStack allows a justification-logged override: a Quality role holder can authorise the signature anyway by recording a written justification at the moment of signing. The override is permanently flagged in the audit trail and surfaced in the periodic audit-trail review report — it isn't a way to bypass scrutiny, just a way to keep work moving in a small team while keeping the exception visible.

Change requests have their own explicit version of this rule: the Requestor can never be the sole approver of their own change. See Approve a change.

The signing log

Every signature event — across every module — lands in your tenant's signing log: a single, append-only, hash-chained ledger. Each entry embeds a hash of the entry before it, so any retroactive edit to any entry breaks the chain and is detectable. This makes the signing log the single source of truth for non-repudiation.

On a schedule, the signing log is exported to a signed PDF and archived in your own storage — this periodic export anchors the hash chain outside QStack, so even a compromise of the live system can't quietly rewrite history that's already been exported.

The same hash-chaining protects the audit trail — the full record of who did what, when, from where, and with what authentication, for every GxP-relevant event, not just signatures. A verification job re-walks the chain and flags any break on the dashboard's Signing log integrity tile (see Quality metrics).

Verifying a signed PDF

When a document, record, or report reaches its terminal signed state — Effective, Closed, or the equivalent — QStack renders it as a signed PDF that carries the visible signature block: names, dates, meanings, and authenticator methods for every signer.

To verify a signed PDF is authentic and hasn't been altered since signing:

  1. Open the object in QStack and compare its recorded signatures against what's shown in the PDF you have — name, date, meaning, and authenticator method should match exactly.
  2. Check the file hash. Every uploaded or generated file is hashed on creation and re-verified on download — if a PDF's contents were altered after signing, the hash comparison will not match.
  3. For an inspector-facing check, use the periodic signing log export as the outside-the-system anchor: the signature events for that document should appear in the exported log for the period, with a hash chain that verifies cleanly back to the entry before it.

Because signed objects are read-only once their terminal state is reached, the practical way to "tamper" with a signed PDF would be to alter the exported file itself — which is exactly what the hash and the hash-chained signing log are there to catch.

Data integrity behind every signature

Signatures only mean something if the record underneath them is trustworthy. QStack backs every signed object with the ALCOA+ data integrity principles:

Principle How it's met
Attributable Every event is tied to a specific person and signature
Legible Records render as readable PDFs, not raw data dumps
Contemporaneous Timestamps are set by the server, not your browser
Original Uploaded files are hashed on upload and re-verified on download
Accurate, complete, consistent Enforced by the fixed lifecycle and required fields on each object
Enduring Data is backed up with point-in-time recovery
Available Records and signatures stay accessible for the retention period

Tenant data is also isolated at the database level — your organization's records, signatures, and audit trail are never visible to, or mixed with, any other QStack customer's.

Where signatures show up

Every module relies on this same mechanism. A few starting points: