What an Interim-Access Audit Must Establish
An access audit asks a specific question: did information that identified treatment-specific interim results reach a person who was intended to remain blinded at that time? It is not enough to find that a person had an account, that a report existed, or that a file was sent somewhere in the organization. The audit must connect the information, the event, the recipient, and the recipient’s blinding status.
The earlier material on reading an adaptation access plan and building a role-by-information matrix establishes the intended access boundaries. For an audit, those boundaries need to be applied to the actual event date and time. Roles can change, responsibilities can be delegated, and an individual may be authorized for one information type but not another. The relevant question is therefore not simply whether a job title was “blinded,” but whether this person was designated to remain blinded to this information at the time of the event.
“Treatment-identified” depends on what the recipient could interpret, not just on whether treatment names appear in a table. A report labelled “Group A” and “Group B” may still identify treatments if the recipient also received a key that maps those labels to the treatments. Conversely, an unlabeled aggregate table may not identify treatment if no reasonable mapping was available to the recipient. The audit should examine the report and relevant accompanying materials as they were available to that person, rather than judging the report from its filename alone.
A Traceable Chain of Evidence
A useful audit reconstructs a chain with four links: the information’s content and version; the event that made it available or transferred it; the identity of the recipient; and that recipient’s status under the access plan at that time. Each link should be supported by records, and unresolved links should be reported as unresolved rather than silently assumed.
Locate the exact report, table, file, message, or screen. Record its version, creation time, treatment-identification status, and any key or companion material needed to interpret it.
Use source-system records to determine whether the item was delivered, downloaded, opened, viewed, forwarded, or blocked. Preserve event times, system identifiers, and the outcome recorded for each event.
Link account names, email addresses, device or session identifiers, and delegation records to a person. A shared account that cannot be attributed to an individual may support a possible-access finding, but not an individual-specific conclusion.
Consult the access plan and dated role records to establish whether that person was intended to remain blinded to the information at the event time. Record changes or exceptions that were in force.
State what the evidence supports, what it does not establish, and which records are missing or conflicting. Preserve the original logs and document any reconciliation or time conversion.
The logic can be expressed as a conjunction. A confirmed event involving an intended-blinded person requires evidence for each required link; if one link is missing, the conclusion must be narrowed accordingly.
Here, \(I\) means the item contained treatment-identified interim information, \(E\) means a successful delivery or access event is recorded, \(R\) means the event is attributable to the recipient, and \(B\) means the recipient was intended to remain blinded at that time. This is a logical checklist, not a statistical test. Evidence of a permission without a successful event does not establish \(E\); a successful event under a shared account may leave \(R\) unresolved; and an unknown role at the relevant time leaves \(B\) unresolved. The conclusion must reflect the weakest unsupported link.
Worked Examples: Reconstructing Access from Records
Worked Example: A Successful Download of a Treatment-Identified Report
In a hypothetical trial, an interim report is labelled version R17. Its content shows response rates for Drug M and control, and its file identifier is recorded as F-884. The access plan says that Dr. Lee, a site investigator, is to remain blinded. System records show a successful download of F-884 by Dr. Lee’s individual account at 10:14 on 6 May. A dated role register confirms that Dr. Lee had no unblinded role on that date. What can the audit conclude?
Information. The report version is linked to F-884, and its content explicitly identifies Drug M and control. Thus \(I\) is supported.
Event and recipient. The system records a successful download at 10:14, rather than merely a login or an attempted download. The individual account is mapped to Dr. Lee, so \(E\) and \(R\) are supported.
Status and conclusion. The dated role register and access plan show that Dr. Lee was intended to remain blinded at 10:14. Therefore \(B\) is supported, and the four-link conjunction is satisfied. The audit can conclude that treatment-identified interim information was downloaded by a person intended to remain blinded. The download record does not, by itself, establish that Dr. Lee read or understood the report.
Worked Example: A Sent Message and an Ambiguous Attachment
In a hypothetical trial, a gateway log shows that an email was sent to 12 staff members. The message included a link to report R21. Two recipients were intended to remain blinded. The document-management log shows that the link was available to all 12, but its access record shows that neither of the two blinded recipients opened or downloaded it. The report is treatment-identified. What finding is justified?
The email and link records show that the report was made available to the two recipients, so they had an opportunity for access. However, the recorded access events show no successful open or download by either person. The audit has evidence of availability, but not confirmed access. It should not classify either recipient as having viewed or received the report on the basis of these records alone.
The conclusion depends on the scope and reliability of the logs. If the document system captures all access routes and its records are complete for the period, the evidence supports “available, with no recorded access.” If recipients could obtain the report through an unlogged shared folder or forwarded attachment, the logs cannot rule out access through those routes, and the finding should be “possible access; no access recorded in the reviewed system.” The distinction is not semantic: it accurately states what the evidence can establish.
Worked Example: Two Files That Become Identifying Together
In a hypothetical trial, a results table uses the labels “Group X” and “Group Y” rather than treatment names. A separate mapping file identifies Group X as Drug N and Group Y as control. A blinded operations manager downloads the table at 09:20 and the mapping file at 09:23 from the same restricted workspace. Both download events are recorded under the manager’s individual account, and the manager is listed as blinded at both times. Does the masked table prevent an access finding?
No. The table alone uses masked labels, but the mapping file supplies the information needed to identify the treatments. Because the manager downloaded both files, the two items together were interpretable as treatment-identified interim results. The content link \(I\) is supported by the combined materials; the two successful downloads support \(E\); the individual account supports \(R\); and the access plan supports \(B\). The audit can conclude that the treatment-identifying information was accessible to the intended-blinded manager through the combined files.
This conclusion does not depend on assuming that every person who sees “Group X” can infer which treatment it represents. It follows from the documented availability of the specific mapping file to this recipient. If the mapping had remained inaccessible to the manager, the table’s labels alone would require a separate assessment and might not establish treatment identification.
Reconciling Records and Diagnosing Weak Evidence
Logs often come from different systems, and each system records a different part of the event. An identity provider may record authentication; an application may record a view; a file server may record a download; and an email gateway may record delivery. Those are not interchangeable. Auditors should preserve the distinction between signing in, having permission, receiving a link, successfully retrieving the content, and viewing it in an application.
Before combining records, check that they refer to the same item and event. Compare stable file or report identifiers, version numbers, message IDs, recipient addresses, and session IDs. A matching filename is weaker than a matching content hash or unique document identifier because filenames can be reused for different versions. If a report was revised after the event, confirm which version was available at the time.
Time reconciliation is also essential. Systems may record different time zones, daylight-saving conventions, or clock offsets. Convert timestamps to a common time basis while retaining the original value and source. If the order of two events changes under plausible clock offsets, do not assert a precise sequence unless additional records resolve it. The intended-blinding status should be evaluated against the event time, not against a later staff list.
| Record or event | What it can support | What it does not establish alone |
|---|---|---|
| Account has permission | Potential opportunity for access | That an item was retrieved or viewed |
| Successful download under a personal account | Retrieval by an account attributable to a person | That the person read or understood the content |
| Email gateway delivery record | Delivery to a mailbox or address | That the recipient opened an attachment or link |
| Application view record tied to a person and version | Strong evidence that the identified item was viewed in the application | That the person comprehended or acted on it |
| Shared-account access record | Access through the shared account | Which individual used the account, absent corroboration |
Common warning signs include missing log periods, unexplained account sharing, inconsistent identity mappings, records that show only attempted access, and files whose versions cannot be resolved. A successful download from an account is not automatically proof of a particular person’s action if multiple people used the account. Similarly, absence of a log entry is informative only if the system was expected to capture that event, the relevant period is complete, and alternative routes have been considered.
Common Mistakes, Alternatives, and Limits
- Equating permission with exposure. A role setting or access-control list indicates potential access. Look for a successful, attributable event before concluding that information was retrieved or viewed.
- Equating delivery with reading. A delivered email supports mailbox delivery, not comprehension. State the strongest event actually recorded.
- Judging masking from one file in isolation. Labels may be interpretable alongside a key, filename, message, or companion report. Review the information available to the recipient as a whole.
- Using current roles to classify an earlier event. Reconstruct the person’s intended status at the event time using dated records and documented exceptions.
- Treating missing records as proof of no access. A system can rule out only events it reliably captures. Note logging gaps and possible routes outside the reviewed systems.
The main alternative to a log-based reconstruction is to rely on interviews or self-report. Interviews can identify unrecorded routes, shared devices, or context that system logs do not capture, but recollection may be incomplete and cannot substitute for the underlying event record. Conversely, logs can establish that an event occurred without revealing whether a person recognized the report’s significance. A careful audit uses both sources where appropriate, keeps their evidentiary roles distinct, and records disagreement rather than forcing a single account.
An audit is also limited to the evidence and system coverage available. It can establish that a treatment-identified file was delivered or viewed under specified conditions; it generally cannot establish comprehension, downstream decisions, or effects on trial conduct from access records alone. Those are separate questions. The appropriate audit conclusion is therefore precise about the information and event, the person and timing, and the remaining uncertainty.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A blinded statistician’s account has permission to view a report, but the logs show only that the account logged in. What does this establish?
- A system records a successful download of a treatment-identified report under a shared team account. What additional evidence is needed for an individual-specific finding?
- A blinded coordinator receives a table labelled “Arm 1” and “Arm 2,” but there is no evidence that the coordinator could access the treatment key. Can the audit automatically classify the table as treatment-identified for that coordinator?
- An email gateway records delivery of a report to a blinded recipient. The attachment is not logged as opened. What is the most precise conclusion?
Solutions. (1) It establishes a potential opportunity and a login, not retrieval or viewing of the report. A successful, attributable event tied to the report is still needed. (2) The auditor needs evidence linking the shared-account event to the individual, such as a uniquely attributable session, device record, or corroborating transfer record; without it, access is attributable only to the account. (3) No. The audit should assess what accompanying information was available to that coordinator. Without evidence of access to a key or another reliable mapping, treatment identification is not established for that recipient, though the status may remain uncertain. (4) The report was delivered to the recipient’s mailbox, but the available record does not establish that the attachment was opened or read. State the delivery finding and the limits of the log.