Building a Defensible Hiring Audit Trail for Compliance

A candidate files a discrimination complaint six months after you passed on them. Or your SOC 2 auditor asks who downgraded an interviewer to read-only last March. Or legal wants to know who approved an offer that later got rescinded. If your answer is "let me check Slack," you don't have a record — you have a memory. A real hiring audit trail turns "we think it happened this way" into "here is exactly who did what, when, and from where."

TL;DR: A defensible hiring audit trail is append-only, captures the full who-did-what-when-where for every consequential action, and retains that history under a policy you can name. In Intervy, viewing the audit log is a Growth-and-above feature; CSV export for auditors is Scale-only. Both are scoped per organization so one tenant never sees another's history.

---

Why "We Remember What Happened" Isn't a Hiring Audit Trail

Most teams think they have an audit trail. What they actually have is a pile of artifacts that feel like evidence until someone tests them. Screenshots can be cropped. Email threads go missing when people leave. Spreadsheet edit history gets overwritten the moment two people open the same file.

None of that survives scrutiny. A defensible record has properties that ad-hoc artifacts can't fake.

• Attribution. Every action ties to a specific person — or to "System" when automation did it, never to a vague "someone."
• Immutability. Once written, an entry can't be quietly edited to tell a friendlier story.
• Completeness. The consequential actions are all captured, not just the ones someone remembered to screenshot.
• Retention. The history sticks around long enough to answer questions that arrive months later.

Why this matters: In a dispute, the burden is on you to show your process was fair and consistent. An audit trail you can't tamper with is the difference between proving that and asserting it.

This is the gap a structured interview tool should close by default — not as a bolt-on you have to remember to turn on, but as a byproduct of every action people already take.

---

What a Defensible Hiring Audit Trail Records

A hiring audit trail is only as good as the fields it captures. A log that says "settings changed" is useless. A log that says "Priya Shah changed the scoring scale from IP 10.x.x.x at 14:32 UTC" is evidence.

Intervy records the full picture on every event. Each entry stores the acting person's identity (name and email), the action, the target it affected, the originating IP and user agent, structured metadata, and a precise timestamp — written in a single append-only insert. Nothing about an event can be altered after it lands.

Automated actions aren't a blind spot. System-generated events are attributed to "System" rather than a person, so a scheduled change or a webhook-driven update is just as attributable as a human click.

The events themselves span five categories — membership, role, settings, billing, and data — covering the moments that actually carry compliance weight: who was invited or removed, who changed someone's permissions, who edited org settings or branding, billing changes, and data exports or CV downloads.

Tip: When you evaluate any technical interview platform for compliance, ask what each log row contains. "An activity feed" and "a defensible audit trail" are not the same product.

---

Why Your Hiring Audit Trail Has to Be Immutable

A trail you can edit isn't a trail — it's a draft. The whole point is that nobody, not even an admin, can rewrite history after the fact.

Intervy's audit log is append-only by construction. There is exactly one write path and it only ever inserts new rows. There is no "update this entry" or "delete this entry" function for individual events.

That immutability is enforced at the API boundary too. The audit surface exposes only read endpoints — list, filters, and export. There is no endpoint to modify or remove a single record.

• No edit endpoint. History can't be rewritten to make a decision look cleaner.
• No single-row delete. Individual entries can't be cherry-picked out of existence.
• Policy-only removal. The sole deletion path is scheduled, tier-based retention — covered next.

Note: Append-only isn't a limitation; it's the feature. The moment an audit log becomes editable, its value as evidence drops to zero.

---

Retention Is a Compliance Decision, Not a Default

How long you keep your hiring records is a policy question — and a defensible trail makes that policy explicit instead of accidental. Intervy ties retention directly to plan tier, defined in exactly one place so there's no ambiguity about how long your history lives.

• Free / Starter: 90 days of history.
• Growth: a full 365 days — long enough to cover a hiring cycle and the questions that arrive after it.
• Scale: the log is never automatically purged.

Removal is policy-driven, not manual. The only deletion routine walks each tier, computes its window, and deletes rows older than that window — scoped per organization by current plan. No human reaches in to clean up entries by hand.

That same window also bounds what you can read. When you request a date range, the API floors your start date to your tier's retention window, so a query can never reach past data that no longer exists.

Why this matters: "How long do you keep hiring records?" is a question every auditor asks. A named, enforced retention window is a far stronger answer than "until someone deletes the spreadsheet."

---

Reading the Trail — Audit-Log View Is Growth+

A hiring audit trail you can't read isn't worth much, so the next question is access. Viewing the log requires both a plan feature and a specific permission.

• Feature gate: audit log viewing is available on Growth and Scale plans.
• Permission gate: even on those plans, a member needs the Audit View permission — access is data-driven, not granted by job title.
• Tenant scope: every read is isolated to your organization, so one org's trail is invisible to another.

Once you're in, the log is filterable by actor, action, category, and date range, with stable cursor pagination so large histories stay navigable. Control over who can see the trail is itself part of your defensibility story — pair it with role-based access controls so the audit log is visible only to the people who should hold it.

Tip: Pairing audit view with least-privilege roles means your most sensitive record is also one of your most tightly held — exactly what a reviewer expects to see.

---

Exporting for Auditors — CSV Export Is Scale-Only

At some point an auditor wants the data, not a dashboard. Exporting the hiring audit trail to CSV is a separate, stricter capability than viewing it — and it's Scale-only.

• Distinct capabilities. Viewing the log in-app and exporting it to CSV are two separate features, so they are deliberately decoupled and independently gated.
• Stricter tier. Growth can read the log in-app; only Scale can pull the full CSV.
• Fixed columns. Every export carries the same auditable schema: When, Actor, Email, Action, Category, Target, IP.

The export streams rather than buffering, so even a large log downloads cleanly. Null-actor rows are labelled "System" and fields are RFC-escaped to ensure the file opens correctly in any spreadsheet tool. And because the same retention floor applies, an export never reaches past your retained window.

Note: The view/export split is intentional. Most teams need to read their trail on Growth; teams with formal audit obligations get portable, hand-it-to-the-auditor CSV on Scale.

---

Make Your Hiring Audit Trail Part of the Process

An audit trail isn't a compliance afterthought — it's the connective tissue that makes the rest of your hiring defensible. It only delivers when it's wired into how decisions actually get made.

• Pair it with permissions. A trail tells you who acted; role-based access controls decide who can act in the first place. Together they answer both "what happened" and "should it have."
• Pair it with structured scoring. When ratings are consistent and the trail shows who entered them, a contested decision has an evidentiary backbone. Start with how to score candidates fairly.
• Pair it with bias controls. A clean trail is most useful when the underlying process is sound — see reducing bias in interviews for the practices it should be recording.

The bottom line: A defensible hiring audit trail isn't about distrust — it's about being able to prove, calmly and completely, that your process did what you say it did. On a hiring platform built for this, that proof is a byproduct of normal work, not a fire drill when the auditor calls.

Ready to make every consequential hiring action attributable, retained, and exportable? Explore Intervy's permissions and access controls and build the audit trail your next compliance review will thank you for.