Electronic signatures in Controlled Documents
What happens when someone signs a controlled document in Confluence, what the signature records, how it is protected, and the one limit you should know before you validate. Each point describes the app as it is released.
Runs on Atlassian Your data stays in your Atlassian site.
Two identification components
- The person’s Atlassian account. They must be signed in to Confluence. The app takes their identity from Atlassian, never from a field they type.
- A signing password of their own. Each person creates it in the app the first time they sign. It is separate from their Atlassian password and is stored only as a salted scrypt hash, in the app’s storage in your Atlassian site. Nobody can read it, administrators included.
Only the approvers named for the revision can sign it. By default, the person who submitted a revision, or who owns the document, cannot approve it.
What a signature records
| Item | Details |
|---|---|
| Name | The person’s full name as shown in Atlassian, with the Atlassian account ID. Atlassian’s personal data rules for apps require the name to be kept current, so it follows a later change of the profile name; the account ID never changes. |
| Date and time | Taken from the server clock, not from the person’s computer; the evidence file and page comments show it in UTC. |
| Meaning | Approved, Reviewed or Authored, as set for each approver; or Rejected, with a mandatory reason. |
| Statement | The sentence the person signs, in their language, for example: “By signing, I approve this revision of the document. I intend this electronic signature to be the legally binding equivalent of my handwritten signature.” |
| What was signed | The document number, the revision, the Confluence page version and the SHA-256 fingerprint of the page title and content. |
Bound to the content
- A signature is refused if the page has changed since the revision was submitted.
- If the page changes while the approval is open, the signatures already collected are voided and the approvers sign again.
- If an effective document is edited, it is flagged “Edited since approval”, with a link to the approved version.
Wrong passwords and forgotten passwords
- After 5 wrong signing passwords in a row, signing is blocked for that person for 15 minutes. Site administrators can set 3 to 10 attempts and 5 to 1,440 minutes.
- Attempts are checked one at a time per person, so parallel guesses cannot get around the count. A malformed request is refused before the password check and never counts.
- The minimum length is 8 characters; site administrators can raise it up to 64.
- A forgotten password is reset by a site administrator, who never sees or chooses it: the person then creates a new one. Each reset is recorded with who did it and when.
Audit trail and evidence file
- Every submission, signature, rejection, voided approval, entry into force, read confirmation, obsolescence and settings change is recorded with date, time and person. The app offers no way to edit or delete these events.
- The PDF evidence file and the full list of read confirmations can be opened by the document’s owner, its approvers and the space administrators. Other readers see the audit trail without other people’s read confirmations.
- The PDF evidence file lists each signature with the name, meaning, date and time in UTC, the signed statement and a signature ID, together with revisions, read confirmations and audit events.
- Read confirmations can also require the signing password, in the space settings.
The limit to know before you validate
Signing does not re-authenticate the person with your company’s identity provider (single sign-on, SAML, your multi-factor prompt). Atlassian’s platform does not give apps a way to request it at the moment of signing. The second component is therefore the app’s signing password, not a fresh sign-in through your identity provider. If your procedures require a fresh sign-in through your identity provider, record this in your validation and describe the control you rely on instead.
Also note: when Atlassian reports that an account has been closed, the app must remove that person’s personal data. The name in their signatures becomes “Closed account”; the date, meaning and fingerprint stay.
What stays with you
- Validation for your intended use: run the operational qualification script on a test space.
- The written policy that makes electronic signatures binding in your organization, and, for 21 CFR Part 11, your certification to the FDA.
- One account per person, never shared, and the sign-in rules of your Atlassian organization.
Requirement by requirement: 21 CFR Part 11 mapping for Controlled Documents. The app is designed to help you meet these requirements; it is not certified. Questions from your quality team or auditor: [email protected]. See how Clearlane Controlled Documents works →