Research Data Access Controls and Audit Trails: Who Can See Your Interview Data

Answer first: a vendor security certificate and an internal access-control model are two different things, and only one of them is your job. SOC 2, ISO 27001 and a signed DPA tell you the platform holding your interview data is run competently. None of them tell you which of your own colleagues opened a raw transcript containing a customer's health disclosure last Tuesday, whether they had any business reason to, or whether you could prove it six months later when a regulator asks. That second question — internal access control and the audit trail behind it — is the control that customer research teams most consistently skip, and the one that turns a routine privacy request into an incident.

This guide covers the four sensitivity tiers of interview data, the role model that should sit on top of them, exactly what an audit trail has to record to be worth anything, the research-specific events almost nobody logs, and the quarterly access review that keeps the whole thing honest.

The core principle: access should narrow as identifiability rises

Most research teams treat "the study" as the unit of access. Someone is either in the project or not. That is far too coarse, because a single interview produces four artefacts with wildly different risk profiles.

The rule that follows is simple and almost never implemented: the number of people with access should fall by roughly an order of magnitude at each tier. If forty people can open a raw recording, you do not have an access-control model — you have a shared folder.

This tiering is also what makes the difference between a defensible and an indefensible answer to the data-minimisation question. Under GDPR Article 5(1)(c) and its equivalents in most modern privacy laws, you are expected to limit processing to what is necessary. "The whole product org had standing access to raw recordings because it was easier" is not a necessity argument.

The role model

Access should be granted by role against tier, not by individual request. A workable default for a product or research organisation:

Two rows deserve comment. Contractors and agencies are where most real leakage happens: access is granted for a project, the project ends, and the account stays live for two years. Every external grant should carry an expiry date at the moment it is created, not a calendar reminder to review it later.

Vendor support access is the row buyers forget to ask about during procurement. The right question is not "can your staff see my data?" — the honest answer for almost every platform is "yes, under some circumstances." The right questions are: does support access require customer approval, is it time-boxed, is it logged in a trail I can read, and am I notified when it happens?

What the standards actually require

If you are being audited, the requirements are more specific than most teams assume.

ISO/IEC 27001:2022 splits this across several Annex A controls. A.5.15 (access control) requires rules for physical and logical access based on business and security requirements. A.5.18 requires that access rights be provisioned, reviewed, modified and removed against a documented policy. A.8.15 (logging) requires that logs record user activities, exceptions, faults and security events, that they be protected from tampering and unauthorised access — explicitly including by privileged administrators who might otherwise edit their own trail — and that they be analysed, not merely collected. The practical implication of that last clause is append-only or write-once storage for the log repository, plus an access control list for the logs themselves.

SOC 2 covers the same ground under the CC6 common criteria: logical access provisioning and removal, restriction of privileged access, and evidence that access is reviewed periodically. An auditor testing CC6 will ask for a user list, the role each user holds, the date access was granted, and evidence of the most recent recertification.

GDPR Article 32 requires appropriate technical and organisational measures including the ability to ensure ongoing confidentiality, and Article 5(2) — accountability — means you must be able to demonstrate compliance rather than assert it. An audit trail is the demonstration.

HIPAA, if any of your interviews touch health information, is unusually blunt: 45 CFR §164.312(b) requires audit controls that record and examine activity in systems containing electronic protected health information, and §164.308(a)(1)(ii)(D) requires regular review of information system activity such as access logs.

Notice what is common to all four: not one of them is satisfied by having logs. They all require that someone reviews them.

What an audit trail must record

A log line that says "transcript viewed" is nearly useless. A defensible research audit trail records eight fields per event.

Shared logins destroy all of this. If three people use one "research@" account, your audit trail has exactly one actor and zero evidentiary value.

The research-specific events nobody logs

Generic application logging captures logins. Research data governance needs more, and these are the events that matter when something goes wrong:

• Recording playback, separately from transcript viewing — voice is the most sensitive artefact you hold.
• Export and download. This is the single most important event in the entire trail, because it is the boundary at which your controls stop. A transcript exported to a spreadsheet, a wiki page or a slide deck now lives in a system with different permissions, different retention and no link back to consent. Log it, alert on unusual volume, and prefer in-platform sharing over export wherever the workflow allows.
• Share-link creation, including whether the link was public, expiring or restricted.
• Cross-study search. Searching a repository for a person's name is a different act from opening one study, and it should be visible as one.
• Redaction and de-identification changes — including who un-redacted something.
• Permission grants and revocations, which is how you reconstruct who could have seen what on any given date.
• API and integration access, including tokens used by automation and by AI assistants connected over MCP. A token is an actor; it needs a name, an owner and a scope.

Where Koji fits

Koji is built around the assumption that most stakeholders should never open a raw transcript at all, and the product structure reflects that.

Team accounts use three roles — owner, admin and member — with shared workspaces that scope which projects a member can see, so access is granted by workspace rather than by handing out a universal login. Reports are shared as their own artefact, which means a stakeholder can read findings without being granted access to the underlying recordings.

The bigger structural advantage is structured questions. Koji supports six question types — open_ended, scale, single_choice, multiple_choice, ranking and yes_no — and the five non-open types produce genuinely aggregate output: distributions, frequencies and average ranks that carry no identifiable content at all. A well-designed study answers most stakeholder questions at Tier 4. When a PM can see that 68% of enterprise respondents ranked reporting first without opening a single verbatim, the access request never happens — and the safest access control is the one you never had to grant. Traditional survey tools push you the other way, because a free-text-only instrument forces everyone into the verbatims to learn anything.

Because Koji's AI interviewer runs every conversation to the same structured plan, the resulting analysis is consistent enough to be trusted at the aggregate tier — which is precisely what makes the tiering practical rather than theoretical.

The quarterly access review

Provisioning is easy; deprovisioning is what fails. Run a recertification every quarter and treat it as a documented control:

1. Export the current access list by user, role, workspace and tier.
2. Reconcile against HR joiners, movers and leavers. Movers are the dangerous category — people accumulate access as they change teams and lose none of it.
3. Expire all external access that has passed its project end date. No exceptions, no "they might come back."
4. Ask each Tier 1 and Tier 2 holder to justify the access in one sentence. Anyone who cannot loses it. This step alone typically removes a third of standing access.
5. Review the log, do not just keep it. Sample the quarter's Tier 1 events and the top ten exporters by volume. Look for access outside working hours, access to studies the person was never assigned to, and bulk exports before a resignation.
6. Record the review — date, reviewer, changes made. The record is the evidence; the review without the record does not exist as far as an auditor is concerned.

The evidence pack an auditor asks for

When the questionnaire arrives, you will be asked for some version of these six items. Assemble them once and keep them current:

• The written access-control policy, including the tier model and the role matrix.
• A current user access list with roles and grant dates.
• Evidence of the last two access reviews, with changes made.
• A sample of audit log entries showing the eight fields above.
• Evidence that logs cannot be altered by the people they record, and the log retention period.
• The list of third parties and vendor personnel who can reach research data, with the controls on each.

Common failure patterns

The permanent Slack channel. Transcripts pasted into a channel with 200 members. The channel outlives the study, the members change, and no consent notice ever mentioned it.

The one-time export that becomes the system of record. Someone exports everything to a spreadsheet "for analysis," and eighteen months later that spreadsheet is the copy people actually use — outside every control you built.

Deletion that misses the copies. A participant exercises a deletion right; you delete the interview in the platform and miss the export, the slide deck and the meeting recording where it was discussed. Your audit trail of exports is what makes this recoverable. See research data retention and deletion for the retention side of the same problem.

Logging without review. The most common of all, and the one that fails an audit fastest, because every framework above requires the review and not just the log.

Frequently asked questions

Is a vendor's SOC 2 report enough to cover internal access to research data? No. A SOC 2 report covers controls at the vendor. It is evidence about the platform, not about your own team's provisioning, your role model, or who inside your company opened a recording. Auditors will ask for both, and only one of them is something you can produce.

How long should we keep research access logs? Longer than the data they describe, which is the point people get backwards. A common baseline is twelve months of readily searchable logs with a longer archive, but the practical test is whether you can answer "who accessed this participant's data" for the full period during which that participant can still exercise their rights or bring a complaint.

Do we really need to log read access, or just changes? Read access is the one that matters most for research data. Nothing is modified when someone listens to a recording of a customer describing a medical condition, but that is exactly the event a participant, a regulator or an incident review would care about. Log views and playbacks, not only edits.

Should stakeholders get access to raw transcripts at all? Usually not by default. Give them the report tier and grant transcript access per study, with an expiry, when there is a stated reason. Studies designed with structured questions answer most stakeholder needs at the aggregate level, which removes the pressure to hand out broad access in the first place.

What counts as a "break-glass" access and how should it work? Break-glass is emergency access outside the normal role model — a support engineer debugging a broken interview, or an investigator responding to an incident. It should require approval from a named person, be time-boxed to hours rather than days, generate a notification to the data owner, and produce a log entry with a written justification.

How do access controls interact with anonymous research? They become more important, not less. If you promised employees or customers anonymity, the access model is the thing that makes the promise true. Restrict raw data to the smallest possible group, suppress small-sample breakdowns in reporting, and be able to show the access list to the people you made the promise to.

Related Resources

• Structured Questions Guide — the six question types that let stakeholders read findings without opening a verbatim
• Research Data Retention and Deletion — how long to keep each tier, and how to delete it properly
• Enterprise Security for AI Customer Research Platforms — SOC 2, SSO and the vendor-side review
• AI Interview Data Privacy and Security — the buyer's evaluation checklist
• Research Data Residency and International Transfers — where the data physically lives
• AI Governance for Customer Research — ISO 42001, the NIST AI RMF and what procurement asks
• Anonymous Employee Research with AI Interviews — keeping an anonymity promise you can actually defend