Audit Trail Template for Qualitative Research (Files to Keep + Logs to Maintain)

An audit trail in qualitative research is a clear record of what you collected, how you processed it, and why you made key decisions. You build it by keeping the right files (raw data, transcripts, codebook versions, memos, decisions) and by logging every meaningful change over time in a simple, repeatable format.

This article gives you a copy-ready audit trail template, including what to retain, a change log format (date, change, reason, who approved), and a recommended folder structure you can use on day one.

Primary keyword: audit trail template for qualitative research

Key takeaways

• Keep both raw data (unaltered audio/video) and processed data (transcripts, cleaned files) with clear versioning.
• Track changes in a single master log plus short, project-specific logs (transcription, coding, consent, and analysis decisions).
• Use a consistent folder structure so anyone can find the latest “approved” files in under a minute.
• Write down why you made changes, not just what changed, and record who approved them.
• Protect participants by separating identifiers from data and restricting access.

What an audit trail is (and what it is not)

An audit trail is your project’s “paper trail,” but stored as organized digital files and logs. It helps you (and others on your team) understand the path from raw data to findings.

It is not extra paperwork for its own sake, and it is not the same as publishing your entire dataset. You can maintain a strong audit trail while still protecting confidentiality and following your consent terms.

What a strong audit trail usually covers

• Data collection: when, how, and under what conditions you gathered data.
• Data processing: transcription, cleaning, anonymization, translation, and formatting choices.
• Analysis decisions: how you coded, revised codes, resolved disagreements, and moved from codes to themes.
• Version control: what changed across time, why, and who approved it.

Audit trail template: files to keep (what to retain and why)

Use the checklist below as your “minimum viable” audit trail. If you work with a team, treat this as your shared agreement on what belongs in the record.

1) Raw data (retain unaltered originals)

• Raw audio/video recordings (original files, unchanged): these are your primary data source.
• Field notes captured at the time (scan or digital originals): preserve first impressions and context.
• Chat logs or platform exports (if interviews happened over messaging): keep the original export file.
• Photos/documents collected from participants (if applicable): keep originals plus access notes.

Tip: If you must convert formats (e.g., .m4a to .wav), keep both the original and the converted file, and log the conversion.

2) Consent, ethics, and participant management (retain separately)

• Consent forms (signed copies) and consent scripts used.
• Recruitment materials (ads, emails, screeners) and eligibility criteria.
• IRB/ethics submissions and approvals (if applicable) and any amendments.
• Participant ID key (a separate file linking real names to participant IDs).

Store the participant ID key in a restricted folder with limited access. Keep identifiers out of working transcripts whenever possible.

3) Transcripts and processing outputs (retain each stage)

• Verbatim transcript (initial) before edits, labeled as a draft.
• Reviewed transcript after your QC pass (typos fixed, speaker labels checked).
• Anonymized transcript (names/places removed or replaced) with a note describing the anonymization rules.
• Timestamped transcript (if you rely on timestamps for analysis or verification).
• Translation files (if used): keep source transcript, translated transcript, and any glossary.

If you outsource transcription, save the delivery email or receipt and the specification you requested (verbatim vs clean read, speaker labels, timestamps).

4) Codebooks and coding artifacts (retain all versions)

• Codebook versions (v1, v2, v3…) with change notes.
• Coding memos that explain how you applied codes and edge cases.
• Inter-coder agreement notes (if you double-code), including how disagreements were resolved.
• Software exports (e.g., coded segments, code frequency, project backups).

Rule: Never overwrite your codebook without creating a new version, even for “small” edits. Small edits change meaning.

5) Analytic memos and decision records (retain your reasoning)

• Method memos (sampling changes, interview guide adjustments, protocol deviations).
• Theme development memos (how codes clustered into categories/themes).
• Negative case memos (data that challenged emerging themes).
• Data exclusion decisions (e.g., unusable audio, withdrawn consent) with justification.

These documents often matter more than perfect formatting because they capture the “why” behind your analysis.

6) Outputs and reporting materials (retain what you shared)

• Figures, tables, and models used in drafts.
• Drafts of reports/papers with tracked changes or version numbers.
• Quote selection notes (why you chose certain excerpts and how you protected identities).

Logs to maintain: simple formats you can copy

Logs turn a folder of files into an audit trail. Keep logs short, consistent, and easy to update so your team actually uses them.

The master change log (use this for the whole project)

Create one file named 00_MASTER_CHANGE_LOG (spreadsheet or table in a doc). Add a new row whenever you change something that could affect interpretation, reproducibility, or confidentiality.

• Date: YYYY-MM-DD
• Item changed: file name(s) or component (e.g., codebook, transcript P07)
• Change: what you did (specific and measurable)
• Reason: why you did it (link to memo if needed)
• Approved by: name/role (or “N/A” for solo projects)
• Links: path to files, memo IDs, or meeting notes

Copy-ready table (paste into a spreadsheet):

Date | Item changed | Change | Reason | Approved by | Links/notes
2026-04-11 | Codebook_v02.docx | Added split between “Access barriers” and “Cost barriers”; updated definitions | Coders used the same code for two different ideas | PI (J. Smith) | /04_Coding/Codebook/Codebook_v02.docx; Memo_M03
2026-04-12 | P07_Transcript_v01.docx | Corrected speaker labels for 12:10–14:02 | QC found mismatch with audio | Lead coder (A. Lee) | /03_Transcripts/Reviewed/P07_Transcript_v02.docx; QC_Log row 18

Optional (but helpful) supporting logs

Use supporting logs if your project is large, regulated, or has multiple staff members. Keep them in the same style as the master log.

• Transcription & QC log: tracks transcription status, reviewer, issues found, and final approval.
• Anonymization log: lists what identifiers you replaced and the rule used (without storing identifiers in the log).
• Coding decisions log: records coder disputes, resolution, and updates to the codebook.
• Data access log: records who received access to restricted folders and when access ended.

Transcription & QC log (simple format)

• File/Participant ID
• Transcribed by
• Date received
• Reviewed by
• QC issues found (brief)
• Status (Draft / Reviewed / Final)
• Approved by

Coding decisions log (simple format)

• Date
• Decision (e.g., merge codes, add new code, redefine code)
• Reason (what problem it solves)
• Applies to (which transcripts/waves)
• Approved by
• Codebook version created

Recommended folder structure (copy and adapt)

This structure keeps raw data separate from working files and makes “latest approved” easy to find. Use leading numbers so folders stay in the same order for every team member.

• 00_Admin/
  • 00_MASTER_CHANGE_LOG.xlsx
  • Project_Scope_and_Timeline.docx
  • Team_Roles_and_Approvals.docx
  • Meeting_Notes/
• 01_Ethics_Consent_RESTRICTED/
  • Consent_Forms/
  • IRB_or_Ethics/
  • Participant_ID_Key_RESTRICTED.xlsx
  • Access_Log.xlsx
• 02_Raw_Data_READONLY/
  • Audio/
  • Video/
  • Field_Notes_Originals/
  • Imports_Exports/
• 03_Transcripts/
  • Draft/
  • Reviewed/
  • Anonymized/
  • Timestamped/
  • Transcription_QC_Log.xlsx
• 04_Coding/
  • Codebook/
  • Coding_Decisions_Log.xlsx
  • Coder_Memos/
  • Software_Project_Files/
  • Exports/
• 05_Analysis/
  • Analytic_Memos/
  • Theme_Maps_Models/
  • Negative_Cases/
• 06_Reporting/
  • Drafts/
  • Figures_Tables/
  • Quote_Selections/
• 07_Archive_FINAL/
  • Final_Codebook/
  • Final_Transcripts/
  • Final_Report/
  • Readme_Audit_Trail_Summary.txt

Naming and versioning rules (keep it boring and consistent)

• Use participant IDs, not names (e.g., P07, INT12).
• Use dates in ISO format: YYYY-MM-DD.
• Use versions: v01, v02, v03 (always two digits).
• Mark status: DRAFT, REVIEWED, FINAL (avoid “final_final”).

Example file name: P07_Interview_2026-04-02_Transcript_REVIEWED_v02.docx

How to log changes over time (a practical workflow)

You do not need complex software to maintain a strong audit trail. You need a routine that your team follows every time.

Step 1: Lock down raw data

• Upload raw audio/video into 02_Raw_Data_READONLY.
• Set permissions so only a small number of people can edit or delete.
• Record uploads in the master change log (date, what was added, who added it).

Step 2: Create a transcript lifecycle

• Create transcripts in 03_Transcripts/Draft.
• Run a QC review and move approved files to Reviewed.
• Anonymize and move to Anonymized if you plan to share working files broadly.

Step 3: Version the codebook on purpose

• Start with Codebook_v01 and lock the file once you begin coding.
• When you need changes, discuss them, document the decision, and save Codebook_v02.
• Log the change in both the coding decisions log and the master change log.

Step 4: Capture decisions as memos (not in your head)

• Write short memos with IDs (e.g., Memo_M01, Memo_M02).
• Each memo should answer: “What happened, why does it matter, what did we decide?”
• Link memos in your logs using a file path.

Step 5: Archive deliverables and freeze the record

• When you finish a phase (e.g., coding complete), copy the approved set into 07_Archive_FINAL.
• Create a short README that lists what is in the archive and where the logs live.

Pitfalls that break audit trails (and how to avoid them)

Most audit trails fail for simple reasons like missing versions or mixed identifiers. Fixing these issues early saves painful cleanup later.

Common mistakes

• Overwriting files: you lose the ability to explain how a decision evolved.
• Storing identifiers with transcripts: you increase confidentiality risk and accidental sharing.
• Logs that are too long: people stop updating them.
• No approval field: decisions look informal and become hard to defend.
• Scattered storage: files live in email threads, desktops, and chat attachments.

Quick fixes

• Use “read-only” permissions for raw data folders.
• Adopt one master log and keep entries to one line when possible.
• Define who can approve changes (PI, lead analyst, project manager) in a one-page roles doc.

Common questions

How detailed should an audit trail be in qualitative research?

It should be detailed enough that another trained person can understand what you did and why, without guessing. Focus on decisions that affect meaning, interpretation, or participant protection.

Do I have to keep raw audio files if I have transcripts?

Many teams keep raw audio because it lets you verify unclear sections and resolve disputes about interpretation. If you cannot keep raw audio due to consent terms or policy, document that restriction and what you retained instead.

What is the difference between a memo and a log entry?

A log entry is a short record of a change (date, change, reason, approval). A memo is a short narrative that explains the thinking behind an approach or decision, and you can link it from a log entry.

How do I handle codebook changes during analysis?

Create a new version every time the meaning of a code changes, a code splits, merges, or gets renamed. Record the reason, who approved it, and which transcripts the change applies to.

What should I do if two coders disagree?

Record the disagreement in the coding decisions log, note the resolution rule you used (discussion, third reviewer, or defined priority), and update the codebook if the disagreement revealed ambiguity.

Can I keep audit trail files in Google Drive, OneDrive, or Dropbox?

Yes, many teams do, but set clear permissions, protect restricted folders, and avoid sharing links that expose identifiers. Use your institution’s or organization’s security rules as the deciding factor.

What is the fastest way to start an audit trail today?

Create the folder structure, add the master change log, and set your naming rules. Then, commit to updating the log every time you change a transcript, codebook, or analysis decision.

Where transcription fits into your audit trail

Transcription often creates the first major “processed” dataset, so it is worth treating transcript stages (draft, reviewed, anonymized) as separate, versioned deliverables. If you use automated tools, consider saving the machine output and the human-edited version so you can show what changed and why.

If you need a hybrid workflow, you can combine fast first-pass tools with a careful review step, such as automated transcription followed by a documented QC pass.

CTA: keep your qualitative record clear and usable

A clean audit trail depends on reliable transcripts and consistent file handling. If you want help creating research-ready transcripts you can version, review, and archive, GoTranscript offers professional transcription services that fit neatly into the folder-and-log workflow above.