Every pharma client planning a cloud DMS migration eventually asks the same question, usually late in the evaluation: “Are we actually Part 11 ready, or are we going to fail the first audit after go-live?” It is the right question, and it is almost always asked too late — after the platform has been selected and the implementation SOW has been signed.
This checklist is the one I use with pharma operations and quality teams before the shortlist is finalized, not after. It is organized around the five control areas that an FDA or EMA inspector will actually test when they look at your new cloud DMS: access control, audit trail, electronic signatures, system validation, and data integrity under ALCOA+.
1. Access control and user management
Part 11 §11.10(d) and §11.10(g) require that the system limit access to authorized individuals and use authority checks for signatures, record changes, and operations. Cloud DMS platforms handle most of this out of the box — but “most” is not “all.”
Checklist items:
- Unique user identity for every individual who touches the system. No shared service accounts for end users. SSO via the corporate IdP is acceptable and preferred.
- Role-based access control mapped to the SOP-defined roles (Author, Reviewer, Approver, QA, Reader). Every role is documented and the mapping is signed off by QA before go-live.
- A joiners-movers-leavers process that is demonstrated, not promised. The auditor will ask you to produce the access termination record for a specific person who left three months ago.
- Privileged access (admins, validators) is logged separately and reviewed on a defined cadence. Most platforms can produce this report; confirm yours can export it in a format the auditor will accept.
- Periodic access reviews are scheduled, owned by a named role, and evidenced in the QMS.
2. Audit trail — the part inspectors actually read
Part 11 §11.10(e) is short, but audit trail deficiencies are the single most common finding in DMS audits. Inspectors spend more time on the audit trail than on any other control. Your checklist must go beyond “the platform has audit trail.”
Checklist items:
- Every create, read (where required), update, delete, download, print, and status change is captured with user, timestamp (server-side, UTC), before/after value where applicable, and reason for change where the SOP requires one.
- Timestamps are tamper-evident. The cloud vendor’s attestation is necessary but not sufficient — confirm the audit trail cannot be edited by any role in the system, including the super-admin.
- Audit trail is reviewable on-screen and exportable to a human-readable format (PDF or CSV). A trail that can only be viewed record-by-record is a finding waiting to happen.
- Review frequency is defined in SOP. For critical GxP documents I recommend a documented periodic review (monthly or quarterly) with evidence of the reviewer’s signature.
- Retention matches or exceeds the record retention period. If your retention SOP says 15 years, the audit trail must also be available for 15 years — including after the vendor contract ends. Confirm the export-on-termination clause in the MSA.
3. Electronic signatures that will survive an inspection
Part 11 §11.50 and §11.70 govern signatures. Cloud DMS platforms generally handle the mechanics well; the gaps are usually in policy and enrolment.
Checklist items:
- Signature manifestation shows the printed name, date/time, and meaning of the signature (Approved / Reviewed / Authored). The meaning is visible on every signed copy, including PDF exports.
- Signatures are linked to their records so that copying, moving, or modifying the record breaks the signature binding. This is a platform capability question — confirm in writing.
- Signature enrolment is evidenced. A §11.100© certification letter is sent to the FDA on first implementation (most multinationals already have this on file; confirm).
- Re-authentication is required at signature. Session-continuity signing (one login, multiple signatures without re-auth) is allowed for continuous sessions only, per §11.200(a)(1)(ii).
- Signature controls for delegated approvers are defined — including what happens when the nominated approver is unavailable and a delegate must sign.
4. Validation: CSV, CSA, and what is actually expected in 2026
Validation has shifted toward the FDA’s Computer Software Assurance (CSA) guidance, which emphasizes critical thinking and risk-based testing over paper-heavy CSV. A 2026 cloud DMS migration should plan for CSA, not 1997-era CSV.
Checklist items:
- A validation plan that articulates intended use, risk assessment, and testing strategy per process — not per screen. Risk drives test depth.
- Vendor-supplied qualification documents (IQ, OQ) are leveraged, not re-executed in full. Your team validates your configuration and integrations, not the vendor’s platform.
- User acceptance testing is scripted against the actual SOPs the DMS will enforce, not against generic “can the user log in” scripts.
- Change control is in place before go-live, with a documented process for vendor-pushed releases in a multi-tenant SaaS — you do not control the release schedule, so your control must be assessment and regression, not prevention.
- A validation summary report and traceability matrix that an auditor can follow from requirement → risk → test → evidence.
5. Data integrity under ALCOA+
ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available) is the lens a modern inspector will use to test your records. Your checklist should confirm each attribute is preserved across the migration.
Checklist items:
- Attributable / Contemporaneous: every document action is stamped to a user and a timestamp in real time. No batch uploads on behalf of other users without explicit audit notation.
- Legible / Original: the rendered PDF and the underlying source both remain accessible. If your platform only serves rendered PDFs after signing, confirm where the source is held.
- Accurate / Complete: metadata migrated from the legacy system is reconciled and signed off. A metadata gap is a data integrity gap.
- Consistent: document numbering, version numbering, and lifecycle state naming are standardized across document types before go-live.
- Enduring / Available: backup, disaster recovery, and contract-termination data egress are documented and tested. An “available” record that you cannot retrieve during a vendor dispute is not available.
Using this checklist
I walk through this checklist in the first week of a full DMS implementation engagement, usually as part of a broader system audit of the current document landscape. Most teams score 60–70% ready on first pass. The 30–40% gap is where the next four to six weeks of work actually lives — and it is cheaper to close those gaps before the SOW is signed than after.
If you are sitting on a cloud DMS shortlist and are not yet sure whether you will clear Part 11 on go-live, let’s talk about it. The goal is not a perfect score on paper. The goal is a system your QA team will actually defend to an inspector — and a migration path that does not turn your production release into a compliance emergency.