Access, Training & Part 11 Basics

Why this matters

In clinical research, regulators and sponsors must be able to answer four simple questions for every change to data: who did it, what changed, when it happened, and why it was done. Getting access and training right—then proving it with audit trails and electronic signatures—protects participant safety, the study blind, and the credibility of your results.

Core concepts & definitions

• 21 CFR Part 11 — The US FDA regulation that sets when electronic records and electronic signatures can be trusted like paper records and handwritten signatures. Its core controls are the ones in this chapter: a validated system (tested and documented to work as intended), access limited to authorized, trained users with unique IDs, secure time‑stamped audit trails, and electronic signatures linked to their records. An EDC whose accounts are controlled by the sponsor or its vendor is usually treated as a closed system, and ICH E6(R3) and EU computerized‑system guidance (e.g., EU GMP Annex 11) expect the same controls.
• Role‑based access control (RBAC) — People receive permissions based on their role (for example: Investigator, Study Coordinator, Data Manager, Monitor). Start from least privilege and add only what is needed to perform assigned tasks. The system blocks actions outside the user’s role, and conflicting duties are kept apart (segregation of duties): no sponsor or contract research organization (CRO) user role can edit site‑entered data, and no one approves or grants their own access.
• Unique credentials — Each user has their own account and login. No shared or “site1” generic accounts. Identity must be traceable to a real person. A user ID is never reused or reassigned to someone else, passwords stay confidential and follow the system’s rules, and repeated failed logins lock the account.
• Training evidence — Dated, versioned proof that a person completed role‑relevant training (e.g., protocol, EDC system use, Good Clinical Practice). Typical evidence includes a learning management system (LMS) certificate, signed training log, or acknowledgment of a training module within the system. Completion alone does not prove competency: people must also be qualified for their tasks by education, training and experience (e.g., a current CV and any required professional license), and many studies require passing a short EDC assessment before an account is activated.
• Audit trail — A computer‑generated, time‑stamped record that captures original value, new value, user identity, date/time, and where applicable the reason for change. Audit trails must be secure, readable, and retained as long as the records they describe; users cannot edit or switch them off, and a change never hides the original value.
• Electronic signature (e‑sig) — The legally binding electronic equivalent of a person’s handwritten signature, applied to a specific record with a stated meaning (e.g., “reviewed,” “approved,” “signed as Investigator”). The signed record must display the signer’s name, the date/time, and the meaning (intent). Each e‑sig is unique to one person, uses at least two components (e.g., user ID and password), and is linked to its record so it cannot be cut out or reused to falsify another record.
• Time accuracy — System time must be correct and consistent (e.g., synchronized servers) so that audit trails and e‑sigs reflect the true sequence of events.
• Blinding — Separating who can see or export treatment‑revealing data (randomization, unblinded lab results) from those who must remain blinded. Access controls should enforce this separation.

The process, step‑by‑step

1. Define roles & permissions

   • Create a permissions matrix listing what each role can view, add, edit, approve, export, and whether they may see unblinded data.
   • Identify high‑risk permissions (e.g., code‑break, randomization, bulk export) and restrict them.
   • Proof: Version‑controlled role catalog and matrix.

2. Map training to roles

   • For each role, list required training with acceptable evidence (e.g., EDC 101, protocol v2.0, privacy/SOPs); this role‑by‑training table is the training matrix.
   • Set retraining triggers: protocol amendments, role changes, and EDC upgrades that change what users see or do. A documented impact assessment of each upgrade decides this; an upgrade with no user‑facing change needs only a communication (e.g., release notes), not retraining.
   • Proof: Role → training curriculum mapping; LMS or signed logs.

3. Provision access only after training is complete

   • Intake request (who, site, role, approval) → verify identity → verify training completion → create account with least privilege. For site staff, the principal investigator (PI) approves the request and the role must match the tasks delegated on the delegation log; the sponsor approves the PI’s own access.
   • Communicate responsibilities: no sharing of credentials; use of e‑sig; locking screens.
   • Proof: Access request ticket; first login captured in the system’s access log.

4. Change roles safely

   • On promotion or scope change, re‑verify training and re‑issue permissions. Avoid “role creep” (permissions only grow).
   • Proof: Change record showing old vs new permissions and training gap closure.

5. Enforce audit trails and e‑signatures

   • Confirm (e.g., during validation) that the audit trail records create/edit/delete, query actions, and key workflow steps (e.g., Investigator sign‑off).
   • Configure signature meaning (e.g., “investigator review complete”) and require credentials at the time of signing.
   • Proof: Sampled audit trail reports and e‑sig verification.

6. Protect the blind

   • Separate blinded and unblinded roles; restrict code‑break screens and exports.
   • Define emergency code‑break: only authorized roles (usually the investigator, even one who is otherwise blinded) can break the code, it is never delayed when the participant’s care needs it, the sponsor is notified automatically, and the reason is documented and reviewed afterwards.
   • Proof: Documented code‑break SOP, access list for unblinded roles, and code‑break logs.

7. Offboard promptly and review periodically

   • On departure or site closeout: disable accounts immediately (rather than delete them, so past entries stay attributable) and document it. When site staff leave, the site tells the sponsor and records the end date on the delegation log.
   • Conduct periodic access reviews (often quarterly; the SOP sets the frequency) in which managers confirm, or attest, that each user still needs their access; reconcile against staffing lists and delegation logs; disable dormant accounts.
   • Proof: Attestation logs and account disablement records.

Tip: Attach “proof of control” to each step (ticket IDs, LMS certificates, access review sign‑offs). It turns an oral explanation into defensible evidence.

What good looks like

• A current, approved role catalog with a clear permissions matrix, including blinded vs unblinded separation.
• Training precedes access every time; access auto‑suspends when mandatory training expires.
• Quarterly user access reviews with manager attestation and prompt disabling of dormant accounts and the accounts of users who have left the study or site.
• Audit trails that are complete, human‑readable, time‑synchronized, and routinely sampled (with findings tracked to closure).
• Electronic signature configurations that clearly present signer name, date/time, and meaning; signatures require credential re‑entry.
• A documented code‑break procedure with limited unblinded roles, start/stop dates for temporary access, and alerting.
• Evidenced backup and restore, including a periodically tested restore proving data + audit trail remain intact.

Worked examples

Example 1 — Onboarding a new Sub‑Investigator at a site

Scenario: A physician joins Site 102 as Sub‑Investigator; the PI has delegated eCRF review and signature to them on the delegation log (the PI still signs each subject’s casebook). Steps & evidence:

1. Site Lead submits access request with identity details and intended role; the PI approves it against the delegation log. (Ticket #SR‑1045)
2. Training verified: Protocol v2.1, EDC User Basics, e‑sig policy. (LMS certs attached)
3. Account created with “Sub‑Investigator (blinded)” role. (Role matrix v3.4)
4. First login recorded. (Access log: user, timestamp, IP)
5. Physician performs an electronic signature on one subject’s visit to confirm review. (E‑sig record shows name, date/time, and meaning: “Reviewed and approved.”)
6. Access review next quarter confirms the account is still needed. (Attestation log signed by Site Lead)

What to look for in an inspection: Training dated before the first login; no shared accounts; e‑sig captured with intent.

Example 2 — Temporary unblinded access for a Data and Safety Monitoring Board (DSMB) meeting

Scenario: A statistician on the independent team that prepares reports for the DSMB needs temporary unblinded access to prepare safety listings. Blinded study‑team members, such as the monitors (Clinical Research Associates, CRAs), are not used for this: access can be switched off, but a person who has seen unblinded data cannot be re‑blinded. Controls:

1. Justification approved by Study Director and Pharmacovigilance Lead with dates. (Memo + ticket)
2. Temporary role “DSMB statistician (unblinded)” granted from June 5–12. (Start/stop dates configured)
3. System sends alerts when unblinded access is activated and when it ends. (Email log)
4. After the meeting, the unblinded role ends automatically; confirm by access report. (Attestation)
5. All exports during the window are logged and reviewed. (Export audit with filenames and purpose)

Key safeguard: Only the minimum set of users receive unblinded access, for the minimum time, with explicit oversight.

Example 3 — Offboarding a departing Coordinator

Scenario: A Site Coordinator resigns effective Friday. Expected controls & evidence:

• Ticket raised to disable EDC account same day as departure. (Timestamped ticket)
• Account shows “disabled” in system admin page; last login predates disablement.
• Quarterly review confirms no active accounts for the departed user.
• If another person inherits duties, new access is granted after training verification.

Example 4 — Training lapse and auto‑suspension

Scenario: Annual privacy training expires. Design: EDC integrated with the LMS; a nightly job flags expired training and automatically suspends data entry permissions until training is complete. Evidence: Suspension entries in the audit trail; reactivation timestamp once training is completed.

Pitfalls & misconceptions

• Shared or generic logins — Destroy traceability; any later “who did this?” becomes unanswerable.
• Granting access before training — Reversing the order (access then training) is a common, citable finding.
• Role creep — Permissions accumulate with job changes; schedule periodic resets against the role matrix.
• Uncontrolled exports — Allowing broad export rights can leak unblinded data; restrict and monitor.
• Missing or unreadable audit trails — If you can’t produce them quickly, compliance is questionable.
• Incorrect system time — Unsynced servers create conflicting time‑stamps; always maintain time synchronization.
• Assuming “backup = restore” — Regulators expect proof that you can restore data and audit trails and that restored records are readable.
• Emergency code‑break without guardrails — No documented reason, no alerts, or no post‑event review—or, the opposite error, approval steps that delay unblinding when the participant’s care needs it.

Practice in the wild (checklist)

• Maintain a role & permission matrix with blinded/unblinded delineation and high‑risk permissions marked.
• Link access provisioning to training completion; disable or suspend when training expires.
• Verify identity before creating accounts; ban shared/generic accounts.
• Configure electronic signature meanings (e.g., “reviewed,” “approved”) and require credential re‑entry at signing.
• Run quarterly access reviews; disable dormant accounts and reconcile against staffing/Site Delegation Logs.
• Sample audit trail entries monthly (creation, edit, delete, export, signature) and investigate anomalies.
• Protect the blind: restrict unblinded roles; implement temporary access windows with alerts.
• Keep system time synchronized across environments that create audit trail records.
• Prove backup and restore at least annually; retain evidence that audit trails restore intact.
• Document and test emergency code‑break procedures (including notifications and post‑event review).

Key points to remember

• Training before access — Grant access only after required, role‑mapped training is completed and evidenced; auto‑suspend permissions when training expires.
• RBAC + least privilege — Use a current role catalog and permissions matrix; restrict high‑risk actions (e.g., code‑break, bulk export) and avoid role creep during changes.
• Unique, verified identities — No shared or generic accounts. Verify identity at onboarding and require users to keep credentials confidential.
• Electronic signatures with intent — Require credential re‑entry at signing; signatures must show signer name, date/time, and meaning (e.g., “reviewed,” “approved”).
• Complete, readable audit trails — Capture who/what/when/why for creates/edits/deletes/queries/exports; keep them secure, human‑readable, and retained after export/restore; sample routinely.
• Protect the blind — Segregate blinded vs unblinded roles. Grant unblinded access only when justified, time‑boxed, and alerted; log and review all exports. Emergency code‑breaks are restricted, alerted and reviewed afterwards, but never delayed when the participant’s care needs them.
• Time integrity — Keep system clocks synchronized so audit trails and e‑signatures reflect the true sequence of events.
• Tight provisioning & offboarding — Link access creation to approved requests and training checks; disable same day on departure; run quarterly access reviews with manager attestation to disable dormant accounts and the accounts of users who have left the study or site.
• Backups aren’t enough — Periodically test restores and keep evidence that both data and audit trails restore intact and remain readable.
• Evidence mindset — Attach ticket IDs, LMS certificates, access lists, and review attestations to each control so your story is traceable and inspection‑ready.