External & Certification Audit Prep: PBC Evidence Request Tracker

The problem this kills

An ISO, SOC 2, customer, or regulatory audit kicks off and the auditor sends a "prepared-by-client" (PBC) list - sometimes a hundred-plus line items, each asking for a specific document, policy, screenshot, or record. What happens next is almost always the same: a giant spreadsheet, a flurry of "hey, can you send me the latest version of the access-review report?" emails, files scattered across inboxes and shared drives, and a controller or quality manager trying to remember which items are done, which are stuck, and which the auditor already kicked back as "not what we asked for."

It is slow, it is stressful, and it is risky. Evidence gets shared before someone checks it for the right version or unredacted personal data. Re-requests fall through the cracks. Nobody can answer the auditor's favorite question - "where are we on the list?" - without an hour of digging.

This Implementation Plan replaces that scramble with one tracked workflow that knows the state of every request and refuses to release anything until a person has approved it.

What you'll build

A private web app for your audit team that:

• Imports the auditor's PBC list by pasting it or importing a CSV / Google Sheet - item number, description, owner, due date.
• Assigns each request an owner and a due date, and tracks its status from requested to in-progress to submitted to accepted (or rejected and re-requested).
• Collects evidence files uploaded as they're gathered, and keeps the old version when a file is replaced so you always know what was shared and when.
• Holds a human approval gate: the engagement owner reviews each uploaded item and marks it "ready to share" before it can go into the auditor package. Nothing is exposed until approved.
• Builds the auditor package from only the approved items, with a redaction reminder before anything leaves the building.
• Emails a status digest to your team via Resend so everyone sees what's outstanding and what's overdue.
• Exports the full request log as a CSV for your records and the audit file.

What's inside the Implementation Plan

• It starts by interviewing you about your business. Before a single line of code, the plan has the AI agent ask you about your real audit process - which standard you're preparing for, how your auditor numbers requests, who your owners are, your typical and peak request volumes, your approval rules, and your messy edge cases (re-requests, partial evidence, evidence that lives in another system). It reads a short tailored spec back to you and waits for your thumbs-up. You get a tool shaped to how you actually run audits, not a generic template.
• A clear definition of done so you know exactly what "finished" looks like.
• Step-by-step build instructions, each ending with a ready-to-paste prompt for your AI coding agent.
• A complete data model for engagements, requests, evidence versions, and the audit trail.
• The status workflow (requested / in-progress / submitted / accepted / rejected) with re-request handling and version history.
• A "No API yet?" fallback so you can build the whole thing today from a CSV or Google Sheet, with a clean CSV export in the exact columns you need - no integration required.
• A verification checklist to confirm every piece works before your real audit starts.

The governance it includes (this is the point)

This is not a toy. The plan builds in the controls an auditor would actually want to see in your own tooling:

• Login so only your team can use the tool.
• Row-level security so each organization (or engagement) only ever sees its own data - you can run multiple audits without leaks.
• A complete audit trail recording who did what and when: who imported the list, who uploaded evidence, who approved it, when status changed.
• A hard human-in-the-loop approval gate before anything is released to the auditor package - the tool drafts and stages, a person reviews and approves, and only then is it shareable.
• Duplicate guards keyed on engagement + request-id so the same request can't be imported or processed twice.
• A redaction reminder before evidence is shared, plus version retention so a replaced file is never silently lost.

Who it's for

Compliance leads, quality managers, internal auditors, and controllers preparing for ISO, SOC 2, customer, or regulatory audits - anyone who has lived through a PBC list and never wants to chase evidence by email again. You do not need to be a developer. If you can describe how your audits work and paste a prompt, you can build this.

You've got this - paste the first prompt and let the interview tailor it to your audit.