Salesforce is not "Part 11 compliant" out of the box, and neither is any other platform. 21 CFR Part 11 governs how you use a system, so the configuration, procedures and validation evidence are yours to provide. We have set up Part 11 electronic signatures in Salesforce many times, and auditors tend to ask the same six questions.
1. Who signed, when, and why?
A signed record must show the signer's name, the date and time, and the meaning of the signature, such as Reviewed or Approved. Auditors want to see this on the record itself, not just in a log.
2. Is the signature tied to the record?
A signature cannot be moved or copied to another record. Show how the record locks after signing, and what happens if someone edits it later: the signature is invalidated or superseded, and the change is logged.
3. Is each signature unique, and re-authenticated at signing?
No shared accounts and no reused credentials. Explain how the signer proves their identity at the moment of signature, not just at login.
4. Do you have an audit trail?
Teams often mix up two layers. Record history shows who changed data and when, and Salesforce Shield's Field Audit Trail extends how long it is kept. The Setup Audit Trail logs changes to the system itself, but it keeps only 180 days. An on-demand export cannot show a change from nine months ago unless you saved a copy earlier.
There are four common ways to keep the configuration history:
- A daily copy into a read-only custom object, with triggers that block edits and deletes.
- A copy in immutable storage outside Salesforce, which is the strongest answer to "who can alter your audit copy?"
- A backup or archive product that keeps history outside the org.
- Change control records that show every deployment, paired with a rule against direct production edits.
Be clear in your documentation about what each one guarantees. A custom object protected by triggers is tamper-resistant, not immutable, and Salesforce does not log every setup change.
5. Can you prove it works?
This is the validation package: requirements, risk assessment, test scripts and results, and traceability between them. Auditors look for evidence that testing matched the risk, including negative tests such as trying to edit a signed record and confirming it fails.
6. Who is allowed to sign?
Show which permission sets grant signing, how often access is reviewed, and what happens when someone leaves.
From the field
A mid-size biotech's QA team needed batch record approvals signed in Salesforce. The auditor's first question was how re-authentication at signing is enforced.
We built a Lightning Web Component that re-prompts the signer for credentials, verified by Apex through a connected app. On success it records the signer's name, timestamp and meaning on a signature record and locks the batch. Users with Modify All Data could still edit signed batches, so we added an Apex trigger and removed that permission from the signing profile.
For the audit we kept a requirements traceability matrix, test scripts for sign, reject and edit-after-sign, and the permission set review.
Before your next audit
- Map each Part 11 requirement to the Salesforce feature and the evidence behind it.
- Decide how you keep the Setup Audit Trail beyond 180 days, and write it down.
- Retest signatures after major Salesforce releases.
- Review signing permissions on a schedule.
This post is general guidance, not legal or regulatory advice. Have your QA and regulatory teams review any approach before relying on it.
Planning Part 11 signatures in Salesforce? Talk to us