Mar 28, 2025·8 min
Build a Web App for Centralized Audit Evidence Collection
Learn how to design a web app that centralizes audit evidence: data model, workflows, security, integrations, and reporting for SOC 2 and ISO 27001 audits.
Learn how to design a web app that centralizes audit evidence: data model, workflows, security, integrations, and reporting for SOC 2 and ISO 27001 audits.
Centralized audit evidence collection means you stop treating “evidence” as a trail of emails, screenshots in chat, and files scattered across personal drives. Instead, every artifact that supports a control lives in one system with consistent metadata: what it supports, who provided it, when it was valid, and who approved it.
Most audit stress isn’t caused by the control itself—it’s caused by chasing proof. Teams commonly run into:
Centralization fixes this by making evidence a first‑class object, not an attachment.
A centralized app should serve several audiences without forcing them into one workflow:
Define measurable outcomes early so the app doesn’t become “just another folder.” Useful success criteria include:
Even an MVP should acknowledge common frameworks and their rhythms. Typical targets:
The point isn’t to hard‑code every framework—it’s to structure evidence so it can be reused across them with minimal rework.
Before you design screens or pick storage, get clear on what your app must hold, who will touch it, and how evidence should be represented. A tight scope prevents a “document dump” that auditors can’t navigate.
Most centralized evidence systems settle into a small set of entities that work across SOC 2 and ISO 27001:
Plan for evidence to be more than “a PDF upload.” Common types include:
Decide early whether evidence is:
A practical rule: store anything that must not change over time; reference anything that’s already well‑governed elsewhere.
At minimum, every Evidence Item should capture: owner, audit period, source system, sensitivity, and review status (draft/submitted/approved/rejected). Add fields for control mapping, collection date, expiration/next due, and notes so auditors can understand what they’re looking at without a meeting.
A centralized evidence app is mostly a workflow product with a few “hard” pieces: secure storage, strong permissions, and a paper trail you can explain to an auditor. The goal of the architecture is to keep those parts simple, reliable, and easy to extend.
Start with a modular monolith: one deployable app containing the UI, API, and worker code (separate processes, same codebase). This reduces operational complexity while your workflows evolve.
Split into services only when needed—for example:
Assume multi‑tenant from the start:
A centralized evidence app succeeds or fails on its data model. If the relationships are clear, you can support many audits, many teams, and frequent re‑requests without turning your database into a spreadsheet with attachments.
Think in four main objects, each with a distinct job:
A practical set of relationships:
Audits always have dates; your model should too.
Avoid overwriting evidence. Model versions explicitly:
evidence_items(id, title, control_id, owner_team_id, retention_policy_id, created_at)evidence_versions(id, evidence_item_id, version_number, storage_type, file_blob_id, external_url, checksum, uploaded_by, uploaded_at)evidence_version_notes(id, evidence_version_id, author_id, note, created_at)This supports re‑uploads, replaced links, and reviewer notes per version, while keeping a clean “current version” pointer on evidence_items if you want fast access.
Add an append‑only audit log that records meaningful events across all entities:
audit_events(id, actor_id, actor_type, action, entity_type, entity_id, metadata_json, ip_address, user_agent, occurred_at)Store event metadata like changed fields, task status transitions, review decisions, and link/file identifiers. This gives auditors a defensible timeline without mixing operational notes into business tables.
A good evidence workflow feels like a lightweight to‑do system with clear ownership and rules. The goal is simple: auditors get consistent, reviewable artifacts; teams get predictable requests and fewer surprises.
Design the workflow around a small set of actions that map to how people actually work:
Keep statuses explicit and enforce simple transitions:
Support two common patterns:
Bulk creation should still generate individual requests so each owner has a clear task, SLA, and audit trail.
Add automation that nudges without spamming:
Security is the first feature auditors will test—often indirectly—by asking “who can see this?” and “how do you prevent edits after submission?” A simple role‑based access control (RBAC) model gets you most of the way there without turning your app into an enterprise IAM project.
Start with email/password plus MFA, then add SSO as an optional upgrade. If you implement SSO (SAML/OIDC), keep a fallback “break‑glass” admin account for outages.
Regardless of login method, make sessions intentionally boring and strict:
Keep the default set small and familiar:
The trick is not more roles—it’s clear permissions per role.
Avoid “everyone can see everything.” Model access at three simple layers:
This makes it easy to invite an external auditor to one audit without exposing other years, frameworks, or departments.
Evidence often includes payroll extracts, customer contracts, or screenshots with internal URLs. Protect it as data, not just “files in a bucket”:
Keep these safeguards consistent, and your later “auditor‑ready view” becomes much easier to defend.
Auditors don’t just want the final file—they want confidence that the evidence is complete, unchanged, and reviewed through a traceable process. Your app should treat every meaningful event as part of the record, not an afterthought.
Capture an event whenever someone:
Each audit log entry should include actor (user/service), timestamp, action type, object affected (request/evidence/control), before/after values (for changes), and source context (web UI, API, integration job). This makes it easy to answer “who changed what, when, and how.”
A long list of events isn’t helpful unless it’s searchable. Provide filters that match how audits happen:
Support export to CSV/JSON and a printable “activity report” per control. Exports themselves should be logged too, including what was exported and by whom.
For every uploaded file, compute a cryptographic hash (e.g., SHA‑256) at upload time and store it alongside the file metadata. If you allow re‑uploads, don’t overwrite—create immutable versions so the history is preserved.
A practical model is: Evidence Item → Evidence Version(s). Each version stores file pointer, hash, uploader, and timestamp.
Optionally, you can add signed timestamps (via an external timestamping service) for high‑assurance cases, but most teams can start with hashes + versioning.
Audits often span months, and disputes can span years. Add configurable retention settings (per workspace or evidence type) and a “legal hold” flag that prevents deletion while a hold is active.
Keep the UI clear about what will be deleted and when, and ensure deletions are soft‑deletes by default, with admin‑only purge workflows.
Evidence capture is where audit programs usually slow down: files arrive in the wrong format, links break, and “what exactly do you need?” turns into weeks of back‑and‑forth. A good evidence app removes friction while still being safe and defensible.
Use a direct‑to‑storage, multipart upload flow for large files. The browser uploads to object storage (via pre‑signed URLs), while your app keeps control of who can upload what to which request.
Apply guardrails early:
Also store immutable metadata (uploader, timestamp, request/control ID, checksum) so you can later prove what was submitted.
Many teams prefer linking to systems like cloud storage, ticketing, or dashboards.
Make links reliable:
For each control, provide an evidence template with required fields (example: reporting period, system name, query used, owner, and a short narrative). Treat templates as structured data attached to the evidence item so reviewers can compare submissions consistently.
Preview common formats (PDF/images) in‑app. For restricted types (executables, archives, uncommon binaries), show metadata, checksums, and scanning status instead of trying to render them. This keeps reviewers moving while maintaining safety.
Manual uploads are fine for an MVP, but the fastest way to improve evidence quality is to fetch it from the systems where it already lives. Integrations reduce “missing screenshot” issues, keep timestamps intact, and make it easier to re‑run the same evidence pull every quarter.
Start with connectors that cover most documents teams already maintain: policies, access reviews, vendor due diligence, and change approvals.
For Google Drive and Microsoft OneDrive/SharePoint, focus on:
For S3‑like storage (S3/MinIO/R2), a simple pattern works well: store object URL + version ID/ETag, and optionally copy the object into your own bucket under retention controls.
Many audit artifacts are approvals and proof of execution, not documents. Ticketing integrations let you reference the source of truth:
For tools like cloud logs, SIEM, or monitoring dashboards, prefer repeatable exports:
Keep integrations safe and admin‑friendly:
If you later add an “integration gallery,” keep setup steps short and link to a clear permissions page like /security/integrations.
Good UI/UX isn’t decoration here—it’s what keeps evidence collection moving when dozens of people contribute and deadlines pile up. Aim for a few opinionated screens that make the next action obvious.
Start with a dashboard that answers three questions in under 10 seconds:
Keep it calm: show counts, a short list, and a “view all” drill‑down. Avoid burying the user in charts.
Audits are organized around controls and time periods, so your app should be too. Add a Control page that shows:
This view helps compliance owners spot gaps early and prevents end‑of‑quarter scrambles.
Evidence piles up fast, so search must feel instant and forgiving. Support keyword search across titles, descriptions, tags, control IDs, and request IDs. Then add filters for:
Save common filter sets as “Views” (e.g., “My Overdue”, “Auditor Requests This Week”).
Auditors want completeness and traceability. Provide exports such as:
Pair exports with a read‑only auditor portal that mirrors the control‑centric structure, so they can self‑serve without gaining broad access.
Evidence collection apps feel fast when the slow parts are invisible. Keep the core workflow responsive (request, upload, review) while heavy tasks run safely in the background.
Expect growth along multiple axes: many audits at once, lots of evidence items per control, and many users uploading near deadlines. Large files are the other stress point.
A few practical patterns help early:
Anything that can fail or take seconds should be asynchronous:
Keep the UI honest: show a clear status like “Processing preview” and provide a retry button when appropriate.
Background processing introduces new failure modes, so bake in:
Track operational and workflow metrics:
These metrics guide capacity planning and help you prioritize improvements that reduce audit stress.
Shipping a useful evidence collection app doesn’t require every integration or every framework on day one. Aim for a tight MVP that solves the recurring pain: requesting, collecting, reviewing, and exporting evidence in a consistent way.
Start with features that support a complete audit cycle end‑to‑end:
If you want to prototype quickly (especially the workflow screens + RBAC + file upload flow), a vibe‑coding platform like Koder.ai can help you get to a working baseline fast: React for the frontend, Go + PostgreSQL on the backend, and built‑in snapshots/rollback so you can iterate on the data model without losing progress. Once the MVP stabilizes, you can export the source code and continue in a more traditional pipeline.
Pilot with one audit (or one framework slice like a single SOC 2 category). Keep the scope small and measure adoption.
Then expand in stages:
Create lightweight docs early:
After the pilot, prioritize improvements driven by real bottlenecks: better search, smarter reminders, integrations, retention policies, and richer exports.
For related guides and updates, see /blog. If you’re evaluating plans or rollout support, visit /pricing.
Centralized audit evidence means every artifact that supports a control is captured in one system with consistent metadata (control mapping, period, owner, review status, approvals, and history). It replaces scattered emails, screenshots in chat, and files on personal drives with a searchable, auditable record.
Start by defining a few measurable outcomes, then track them over time:
A solid MVP data model usually includes:
Support more than “PDF upload” from day one:
This reduces back-and-forth and fits how controls are actually proven.
Use a simple rule:
Minimum useful metadata includes:
Add collection date, expiration/next due date, control mapping, and notes so auditors can understand the artifact without a meeting.
A common, defensible approach is:
Avoid overwriting. Store checksums (e.g., SHA-256), uploader, timestamps, and version numbers so you can show exactly what was submitted and when.
Use a small set of explicit statuses and enforce transitions:
When evidence is Accepted, lock edits and require a new version for updates. This prevents ambiguity during audits.
Keep RBAC simple and aligned to real work:
Enforce least privilege by audit, framework/control set, and department/team so an auditor can access one audit without seeing everything else.
Log meaningful events and prove integrity:
Make logs filterable (by control, user, date range, action) and log exports too so the “record of record” is complete.
audit_start_at, audit_end_at on an audits table.period_start, period_end) because a SOC 2 period may not match request dates.valid_from, valid_until (or expires_at). This lets you reuse a valid artifact instead of re‑collecting it.This keeps relationships clear across many audits, teams, and re-requests.