Salesforce Validation for 21 CFR Part 11: A Practical Implementation Guide

21 CFR Part 11 validation is one of the most misunderstood obligations in pharmaceutical Salesforce implementations. Companies either ignore it entirely — a regulatory risk they’ll feel during an FDA inspection — or they over-validate everything, spending $200K+ validating CRM functionality that has no GxP relevance. The gap between those two errors is where a practical implementation guide lives.

This post explains what Part 11 actually requires, how Salesforce satisfies (and doesn’t satisfy) those requirements natively, what a validation package needs to include, and how much this realistically costs.

What 21 CFR Part 11 Actually Requires

Title 21 CFR Part 11 is the FDA regulation governing electronic records and electronic signatures used in place of paper records and handwritten signatures. It applies when electronic records are “required to be maintained” or “submitted to FDA” under any FDA predicate rule — think 21 CFR Part 211 (drug manufacturing), Part 820 (medical devices), or Part 58 (Good Laboratory Practice).

The regulation breaks into two main requirements:

Electronic records must be: generated and protected by computer system controls that ensure authenticity, integrity, and confidentiality; maintained with audit trails documenting record creation, modification, or deletion; accessible for review and copying by the FDA; and retained for the period required by the applicable predicate rule.

Electronic signatures must be: unique to one individual, not reused or reassigned; verified before being applied; linked to their respective records in a manner that prevents the signature from being excised, copied, or otherwise transferred; and accompanied by printed name, date/time, and meaning (approval, review, etc.).

The critical scoping question that most companies get wrong: Part 11 applies only where an FDA predicate rule requires paper records. If no predicate rule requires a paper record, Part 11 doesn’t apply. Commercial CRM data (sales call logs, HCP contact information, marketing campaign records) is not subject to a predicate rule. The FDA doesn’t require you to keep a paper record of every rep’s call plan, so the electronic version of that record doesn’t need to meet Part 11 requirements.

GxP-adjacent processes that typically do require validation in a Salesforce implementation: sample lot tracking (21 CFR Part 203), adverse event intake and forwarding to pharmacovigilance systems, medical device complaint handling records (21 CFR Part 820), and any quality management process (deviations, CAPAs) if you’re running Quality Cloud on Salesforce.

How Salesforce Satisfies Part 11 Requirements — and Where It Doesn’t

Audit Trail

Part 11 §11.10(e) requires a computer-generated, time-stamped audit trail that records operator entries and actions that create, modify, or delete electronic records. The trail must be retained for a period at least as long as the record itself.

Salesforce native capability: Field History Tracking. Salesforce logs changes to up to 20 fields per object, capturing the old value, new value, changed-by user, and timestamp. Standard history records are retained for 18 months in the platform.

Gaps: Two significant ones. First, the 20-field limit means you can’t track every field on a complex object natively. For a validated process, you need 100% field coverage. Second, the 18-month retention default is inadequate for most pharmaceutical records — Part 211 requires records to be retained for at least 3 years after a batch is distributed, and Part 58 (GLP) requires study records for 2 years after study completion. Validated implementations address both gaps either through third-party audit trail packages (Compliance Quest, Titan, or custom Lightning platform event logging) or through archival automation that exports history records to long-term storage before the 18-month window closes.

Access Controls

Part 11 §11.10(d) requires that system access is limited to authorized individuals.

Salesforce native capability: This is one of Salesforce’s genuine strengths. Profiles, permission sets, role hierarchy, field-level security, and record-level sharing rules provide a granular access control architecture that can satisfy Part 11’s requirements. User authentication with mandatory password complexity, session timeout configuration, and single sign-on integration are all available natively.

Gap: The validation must document that these controls are correctly configured and tested. “Salesforce has permission sets” is not a Part 11 compliance argument — “we configured permission set X to restrict record editing to authorized users, and we have test evidence confirming this behavior” is.

Electronic Signatures

Part 11 Subpart C governs electronic signatures. Salesforce does not have a native electronic signature capability that satisfies Part 11 out of the box. An electronic signature in Salesforce — in the compliance sense — requires a separate signature workflow that: captures the signatory’s credentials at the time of signing (not just their logged-in session), attaches the signature to the specific record version being signed, records the meaning of the signature (reviewed, approved, etc.), and cannot be edited after the fact.

This is typically implemented through one of three approaches: DocuSign for Salesforce (which has a validated edition specifically for regulated industries), a custom Flow-based signature capture with a locked audit record, or a third-party validated e-signature tool integrated via API. Each approach has different cost and validation implications.

The Validation Framework: IQ/OQ/PQ Applied to Salesforce

Pharmaceutical computer system validation (CSV) traditionally uses the IQ/OQ/PQ framework, borrowed from equipment validation. Applied to Salesforce:

Installation Qualification (IQ) confirms that the system is installed correctly in the validated environment according to approved specifications. For Salesforce, IQ documentation covers: Salesforce org configuration (edition, enabled features, integrations), network and security architecture, user provisioning processes, and evidence that the production org matches the validated specification.

Operational Qualification (OQ) confirms that the system operates as designed across its full functional range, including boundary conditions. OQ for Salesforce means executing test scripts against every in-scope function — creating, editing, deleting records; triggering automated processes; applying electronic signatures; confirming audit trail entries are correctly captured. Test scripts must be pre-approved, executed in a dedicated OQ environment (not production), and documented with actual results vs. expected results, tester identity, and date.

Performance Qualification (PQ) confirms that the system performs consistently under actual use conditions over time. PQ is sometimes combined with or replaced by User Acceptance Testing (UAT) in software validation contexts. For Salesforce, PQ typically involves running the validated processes with real users in a staging environment that mirrors production, then documenting that performance meets specifications.

The IQ/OQ/PQ framework produces a set of validation deliverables — together called the Validation Package — that must be stored in a document control system and available for FDA inspection.

What a Validation Package Includes

A complete Salesforce validation package for a GxP process typically includes:

Validation Plan — defines the scope of validation, the risk-based approach, the testing strategy, roles and responsibilities, and acceptance criteria. This is the governing document that reviewers (including FDA inspectors) read first.

User Requirements Specification (URS) — documents what the system must do from the user’s perspective, in user language. Each requirement gets a unique ID that traces through the rest of the package.

Functional Specifications (FS) — translates URS requirements into specific system behaviors. For Salesforce, this describes which objects, fields, automations, and permission configurations satisfy each requirement.

Traceability Matrix — a cross-reference document linking each URS requirement to its FS specification, to its OQ test script, and to the test result. The matrix is how an auditor confirms that everything required was specified and tested.

Test Scripts (IQ, OQ, PQ) — pre-approved, step-by-step test procedures with expected results. Each step requires documented actual results, pass/fail determination, and tester signature.

Validation Summary Report — summarizes what was validated, any deviations encountered during testing, how deviations were resolved, and a formal conclusion that the system is in a validated state.

Change Control Procedure — describes how changes to the validated system will be evaluated, documented, and re-validated as needed. This is where most organizations fail to maintain their validation over time.

Salesforce Releases Three Times a Year: Change Control Implications

This is the part of Salesforce validation that catches most companies off guard. Salesforce releases major platform updates in Spring, Summer, and Winter — three times per year, without exception, and without the ability to opt out. Every release introduces new features, modifies existing behavior, and sometimes deprecates functionality.

A validated Salesforce system doesn’t stay validated automatically when Salesforce releases an update. Each release requires a change control review to assess whether the update affects any validated functionality. If it does, re-validation (typically re-executing the affected OQ test scripts) is required before the release goes live in your production org.

In practice, this means your validated Salesforce implementation requires ongoing validation maintenance. You need a designated validation owner who reviews Salesforce release notes three times per year, assesses impact against your validated functions, executes re-testing where required, and documents the assessment regardless of outcome. If no validated functions are affected by a release, the impact assessment itself (documented) is your evidence. If functions are affected, re-testing is required before the release date — which means you have 2–3 months of lead time from Salesforce’s sandbox preview release to prepare.

Validated organizations typically maintain a sandbox environment that mirrors production for change control testing. This sandbox gets the Salesforce release update first (Salesforce previews releases in sandboxes approximately 4–6 weeks before production) and is where impact assessment testing is performed.

Who Actually Needs to Validate

Most commercial Salesforce implementations in pharma and biotech do not need full 21 CFR Part 11 validation. The following processes typically do not require validation: HCP call logging, territory management and alignment, marketing campaign tracking, quota management, sales performance reporting, and most customer service case management unless the cases involve adverse events.

The following processes typically do require validation when implemented in Salesforce: sample management with regulated lot tracking, adverse event intake and routing (depending on your AE process architecture), medical device complaint records, quality management processes (deviations, CAPAs, change controls), and clinical operations data if Salesforce is the system of record for any GLP or GCP data.

If you’re building a Salesforce implementation that includes a mix of validated and non-validated processes in the same org, you need a system boundary definition in your Validation Plan that explicitly delimits which functionality is in scope for validation and which isn’t. An FDA inspector examining your sample management records doesn’t get to audit your sales call data just because they’re in the same org — but you need to have documented that boundary clearly.

What Validation Costs

Validation cost scales with three factors: the number of in-scope GxP processes, the complexity of the Salesforce implementation (number of custom objects, automations, integrations), and whether you have an internal validation function or are outsourcing to a CRO or consulting firm.

Narrow scope (one GxP process, e.g., sample management only, moderate customization): $30K–$60K for initial validation, $10K–$20K/year for ongoing change control and maintenance.

Mid scope (2–4 GxP processes, multiple integrations, e-signature requirement): $60K–$120K for initial validation, $20K–$40K/year for ongoing maintenance.

Broad scope (full QMS on Salesforce, adverse event management, device complaints, multiple integration points): $120K–$300K+ for initial validation, $40K–$80K/year for ongoing maintenance.

These numbers assume a competent implementation that was designed with validation in mind from the start. Validating a system that was implemented without validation considerations — poor documentation, audit trail gaps, lack of a change control process — costs significantly more because you’re retrofitting structure onto an architecture that wasn’t built for it. Retrofit validations are typically 1.5–2x the cost of a clean initial validation.

The right time to plan for validation is before the implementation starts, not after go-live.

---

Estarei is a boutique Salesforce consulting firm with direct experience delivering validated Salesforce implementations for pharmaceutical and biotech clients. We know how to build GxP-compliant systems from the ground up, without over-engineering the non-GxP pieces. Learn more about our life sciences practice or book a free consultation to discuss your validation scope.