{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-08-03T04:16:41.003Z"},"content":[{"type":"documentation","id":"eefb768d-ee94-456c-a0a2-44f52cd639b0","slug":"research-data-access-controls-audit-trail","title":"Research Data Access Controls and Audit Trails: Who Can See Your Interview Data","url":"https://www.koji.so/docs/research-data-access-controls-audit-trail","summary":"Vendor certifications like SOC 2 prove the platform is secure; they say nothing about which internal colleague opened a raw transcript. Research data should be tiered by identifiability — raw recording, verbatim transcript, de-identified transcript, aggregate report — with access narrowing by roughly an order of magnitude at each tier and granted by role rather than by request. A defensible audit trail records eight fields per event (timestamp, actor identity, role at the time, object, sensitivity tier, action, source context, justification) and must cover research-specific events: recording playback, export and download, share-link creation, cross-study search, redaction changes, permission grants and API or MCP token use. ISO 27001:2022 A.5.15, A.5.18 and A.8.15, SOC 2 CC6, GDPR Articles 32 and 5(2), and HIPAA 45 CFR 164.312(b) all require review of logs, not merely collection. Koji reduces the number of access grants needed by answering most stakeholder questions at the aggregate tier through structured questions, with team roles of owner, admin and member and workspace-scoped project access.","content":"**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.\n\nThis 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.\n\n## The core principle: access should narrow as identifiability rises\n\nMost 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.\n\n| Tier | Artefact | Contains | Who genuinely needs it |\n|---|---|---|---|\n| 1 | Raw audio or video recording | Voice, accent, background, sometimes face — biometric-adjacent, effectively impossible to de-identify | The researcher running the study, and almost nobody else |\n| 2 | Verbatim transcript | Names, employers, health and financial disclosures, off-hand third-party details | The researcher plus named analysts |\n| 3 | De-identified transcript | The reasoning, with direct identifiers stripped or tokenised | The wider product team |\n| 4 | Aggregate report and quote set | Themes, distributions, approved quotes | Anyone with a legitimate interest |\n\nThe 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.\n\nThis 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.\n\n## The role model\n\nAccess should be granted by role against tier, not by individual request. A workable default for a product or research organisation:\n\n| Role | Tier 1 raw | Tier 2 verbatim | Tier 3 de-identified | Tier 4 report |\n|---|---|---|---|---|\n| Study owner / researcher | Yes | Yes | Yes | Yes |\n| Research ops / admin | On request, logged | Yes | Yes | Yes |\n| Named analyst on the study | No | Yes, study-scoped | Yes | Yes |\n| Product manager, designer, engineer | No | No | Yes | Yes |\n| Executive, sales, marketing | No | No | No | Yes |\n| External agency or contractor | No | Time-boxed, study-scoped | Yes | Yes |\n| Legal, privacy, compliance | On request, logged | On request, logged | Yes | Yes |\n| Vendor support staff | Only with break-glass approval, logged and notified | | | |\n\nTwo 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.\n\n**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?\n\n## What the standards actually require\n\nIf you are being audited, the requirements are more specific than most teams assume.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\nNotice what is common to all four: not one of them is satisfied by *having* logs. They all require that someone reviews them.\n\n## What an audit trail must record\n\nA log line that says \"transcript viewed\" is nearly useless. A defensible research audit trail records eight fields per event.\n\n| Field | Why it matters |\n|---|---|\n| Timestamp (UTC, with timezone) | Correlates with incident timelines and shift patterns |\n| Actor identity | A named human or a named service account — never a shared login |\n| Actor's role at the time | Roles change; the trail must reflect what was true then |\n| Object | Study, interview, transcript or export — identified precisely |\n| Sensitivity tier of the object | Lets you filter \"who touched Tier 1 this quarter\" in one query |\n| Action | View, play, search, export, share, redact, delete, grant |\n| Source context | IP address, device or API client |\n| Justification | Ticket reference or stated reason, for privileged and break-glass access |\n\nShared logins destroy all of this. If three people use one \"research@\" account, your audit trail has exactly one actor and zero evidentiary value.\n\n## The research-specific events nobody logs\n\nGeneric application logging captures logins. Research data governance needs more, and these are the events that matter when something goes wrong:\n\n- **Recording playback**, separately from transcript viewing — voice is the most sensitive artefact you hold.\n- **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.\n- **Share-link creation**, including whether the link was public, expiring or restricted.\n- **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.\n- **Redaction and de-identification changes** — including who un-redacted something.\n- **Permission grants and revocations**, which is how you reconstruct who could have seen what on any given date.\n- **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.\n\n## Where Koji fits\n\nKoji is built around the assumption that most stakeholders should never open a raw transcript at all, and the product structure reflects that.\n\nTeam 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.\n\nThe 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.\n\nBecause 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.\n\n## The quarterly access review\n\nProvisioning is easy; deprovisioning is what fails. Run a recertification every quarter and treat it as a documented control:\n\n1. **Export the current access list** by user, role, workspace and tier.\n2. **Reconcile against HR joiners, movers and leavers.** Movers are the dangerous category — people accumulate access as they change teams and lose none of it.\n3. **Expire all external access** that has passed its project end date. No exceptions, no \"they might come back.\"\n4. **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.\n5. **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.\n6. **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.\n\n## The evidence pack an auditor asks for\n\nWhen the questionnaire arrives, you will be asked for some version of these six items. Assemble them once and keep them current:\n\n- The written access-control policy, including the tier model and the role matrix.\n- A current user access list with roles and grant dates.\n- Evidence of the last two access reviews, with changes made.\n- A sample of audit log entries showing the eight fields above.\n- Evidence that logs cannot be altered by the people they record, and the log retention period.\n- The list of third parties and vendor personnel who can reach research data, with the controls on each.\n\n## Common failure patterns\n\n**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.\n\n**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.\n\n**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](/docs/research-data-retention-deletion) for the retention side of the same problem.\n\n**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.\n\n## Frequently asked questions\n\n**Is a vendor's SOC 2 report enough to cover internal access to research data?**\nNo. 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.\n\n**How long should we keep research access logs?**\nLonger 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.\n\n**Do we really need to log read access, or just changes?**\nRead 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.\n\n**Should stakeholders get access to raw transcripts at all?**\nUsually 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.\n\n**What counts as a \"break-glass\" access and how should it work?**\nBreak-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.\n\n**How do access controls interact with anonymous research?**\nThey 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.\n\n## Related Resources\n\n- [Structured Questions Guide](/docs/structured-questions-guide) — the six question types that let stakeholders read findings without opening a verbatim\n- [Research Data Retention and Deletion](/docs/research-data-retention-deletion) — how long to keep each tier, and how to delete it properly\n- [Enterprise Security for AI Customer Research Platforms](/docs/enterprise-security-ai-research-platforms) — SOC 2, SSO and the vendor-side review\n- [AI Interview Data Privacy and Security](/docs/ai-interview-data-privacy-security) — the buyer's evaluation checklist\n- [Research Data Residency and International Transfers](/docs/research-data-residency-international-transfers) — where the data physically lives\n- [AI Governance for Customer Research](/docs/ai-governance-frameworks-research) — ISO 42001, the NIST AI RMF and what procurement asks\n- [Anonymous Employee Research with AI Interviews](/docs/anonymous-employee-research-ai-interviews) — keeping an anonymity promise you can actually defend","category":"Research Operations","lastModified":"2026-08-01T03:16:20.992314+00:00","metaTitle":"Research Data Access Controls & Audit Trails: A Practical Guide","metaDescription":"Who on your team can open a raw interview recording — and can you prove it? Access tiers, the role matrix, what ISO 27001 and SOC 2 require, and the quarterly access review.","keywords":["research data access control","research audit trail","who can access research data","least privilege research data","research data governance","interview transcript permissions","access review research","ISO 27001 logging research"],"aiSummary":"Vendor certifications like SOC 2 prove the platform is secure; they say nothing about which internal colleague opened a raw transcript. Research data should be tiered by identifiability — raw recording, verbatim transcript, de-identified transcript, aggregate report — with access narrowing by roughly an order of magnitude at each tier and granted by role rather than by request. A defensible audit trail records eight fields per event (timestamp, actor identity, role at the time, object, sensitivity tier, action, source context, justification) and must cover research-specific events: recording playback, export and download, share-link creation, cross-study search, redaction changes, permission grants and API or MCP token use. ISO 27001:2022 A.5.15, A.5.18 and A.8.15, SOC 2 CC6, GDPR Articles 32 and 5(2), and HIPAA 45 CFR 164.312(b) all require review of logs, not merely collection. Koji reduces the number of access grants needed by answering most stakeholder questions at the aggregate tier through structured questions, with team roles of owner, admin and member and workspace-scoped project access.","aiPrerequisites":["A research platform or repository holding interview recordings and transcripts","A list of everyone who currently has access to research data","Awareness of which compliance frameworks apply to your organisation"],"aiLearningOutcomes":["Tier research artefacts by identifiability and set access limits per tier","Build a role-versus-tier access matrix instead of granting access ad hoc","Record the eight audit-trail fields that make a log evidentially useful","Log the research-specific events that generic application logging misses","Run a quarterly access recertification that survives an audit","Assemble the evidence pack auditors request for access controls"],"aiDifficulty":"advanced","aiEstimatedTime":"12 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}