Give an inspector access
A regulatory inspector or a sponsor auditor needs access to the data and the audit trail — but strictly view-only and for a limited time. There is no special “inspector mode”: an inspector is an ordinary account with the ready-made Auditor (read-only) role assigned with an end date.
Who and when
Section titled “Who and when”Administrator — the access administrator or whoever runs the study team:
you need the right to grant access (access.grant) on the study, and
principal.manage to create a new account. QA & inspection usually agrees the
period and scope with the inspection.
The task comes up before a regulatory inspection or a sponsor audit — as soon as the dates are known.
Before you start
Section titled “Before you start”- The inspection dates are known: access must expire on its own, without reminders to the administrator.
- The scope is known: the whole study or a specific site.
- The Auditor (read-only) role exists in Admin → Roles (it ships with the platform; you can check its contents there).
- If the inspection needs copies of materials, agree in advance who will assemble the inspection packet — the inspector does not export files.
-
Open the study → Team and click Add to team.
-
Pick the person. If there is no account yet — Invite new (or create it in Admin → Users, or connect it via SSO).
-
Choose the Auditor (read-only) role and the scope: Whole study or the site needed.
-
Set Valid until — the end date of the inspection. This is the key step: without it the access stays open-ended.
-
Click Add.
Extend access
Section titled “Extend access”The period is changed only by a new assignment, not by editing the old one: grant history is immutable and cannot be extended retroactively. Assign the role again with a new Valid until date.
What happens
Section titled “What happens”- The inspector sees the study data, value history, queries, signatures, SDV and lock statuses, the audit trail — and can verify chain integrity on their own. They have no write actions at all.
- The assignment is recorded in the audit trail; all of the inspector’s actions are audited like any user’s.
- When the period ends, access stops on its own: the next request simply fails the permission check.
If it doesn’t work
Section titled “If it doesn’t work”- No Add to team button — you do not hold
access.granton the study. - “The user list is unavailable” — the organization-level “Read access” permission
(
access.read) is required; or invite a new person. - No Auditor (read-only) role — it was renamed or deleted; create a role from the “inspector” template (Manage team access).
- The inspector does not see a site — the role is assigned on another site; assign it on the right one or on the whole study.
- The inspector asks for a file or unblinded values — the role lacks
export.runanddata.unblinded.readon purpose; see “If an inspection needs unblinding or an export” below.
More detail
Section titled “More detail”The Auditor (read-only) role
Section titled “The Auditor (read-only) role”The role ships with the platform — there is nothing to assemble from permissions. It suits a sponsor auditor and a regulatory inspector alike: viewing data and value history, queries, signatures, SDV and lock statuses, the audit trail, and verifying its integrity on their own. It has no permission to change anything, export study data or unblind. The same access rules apply as for everyone: default deny and “deny always wins”.
What the inspector sees
Section titled “What the inspector sees”Navigation is the same as for an ordinary user, but without a single write action.
- Study data — subject casebooks, forms, values — read-only.
- The history of every value — all versions of a field: what it was, what it became, who changed it and when, with the stated reason for change (RfC).
- Audit trail — the full chain of events with filters by period, user and action; each event shows before/after and its causal link.
- Self-service integrity check — the Verify trail integrity button recomputes the cryptographic audit chain and gives the verdict Chain intact or Chain broken with the number of the first broken record. The check is a direct answer to the inspection’s key question “how do you prove the audit trail was not edited?”: the inspector does not have to take it on trust. A break found is a critical incident, and the system never quietly “fixes” it.
A typical subject review: the auditor opens the subject, reads its casebook and the audit tab — the history of every value with the reasons for change. They see SDV, signature and lock statuses on the same screens as the team, in view mode. They have no files or printed copies (152-FZ — minimizing copies of personal data): copies for the inspection are issued by the data manager as an inspection packet (the Inspection packet tab in the study’s Exports; the packet is always blinded and verifiable offline).
What the inspector cannot do
Section titled “What the inspector cannot do”The restrictions are not interface cosmetics: the inspector simply has not been given the corresponding permissions. Even bypassing the interface directly ends in a server refusal.
| Action | Why it is unavailable |
|---|---|
| Any edit to data, statuses, queries | no permission to change — view-only access |
| Generating documents (exporting files) | no export.run permission; no buttons, a direct call is refused |
| Unblinding | no data.unblinded.read permission; blinded values are masked (•••) everywhere, incl. audit |
| Extending their own access | the period is changed only by a new grant, never retroactively |