How to Collect Compliance Evidence Without a $200K GRC Platform
A structured approach to evidence collection that actually holds up in an audit — without the implementation project.
Every compliance program eventually runs into the same wall.
Audit season arrives. The auditor sends their evidence request list. And somewhere in your organization, a very stressed person starts opening browser tabs, pinging colleagues on Slack, and digging through shared drive folders with names like “Compliance 2024 FINAL v3.”
It’s not that nobody cared about evidence collection. It’s that nobody built a system for it — or the system they bought was so complicated that it quietly became shelfware six months after implementation.
Enterprise GRC platforms like ServiceNow GRC and RSA Archer were designed to solve this problem. And for Fortune 500 organizations with dedicated implementation teams, multi-year onboarding budgets, and a full-time administrator to keep the system humming, they do. But for the compliance manager at a 200-person healthcare organization, or the IT director at a fintech company navigating their first SOC 2 audit, those platforms aren’t a solution. They’re a second problem.
The good news: rigorous evidence collection doesn’t require enterprise infrastructure. It requires clear ownership, a consistent structure, and traceability back to the compliance obligations that require the evidence in the first place.
What Evidence Collection Actually Is
Let’s be precise about this, because “evidence collection” gets treated like a synonym for “screenshot folder.”
Evidence is documented proof that a specific control is operating as designed. It answers a very particular set of questions: What was collected? When? By whom? What did it show? Who verified it?
That last part — who verified it — is where most informal evidence programs fall apart.
Mature evidence collection operates on a two-role model:
Assignee: the person responsible for gathering and submitting the evidence on schedule
Reviewer: a second person who crosschecks the evidence for completeness, accuracy, and any anomalies that need follow-up, then formally approves it
This isn’t bureaucratic overhead. It’s separation of duties — a principle that auditors for SOC 2, HIPAA, and NIST-aligned programs will specifically look for. Single-person evidence collection, where the same individual who executes a control is also the only one who documents it, is a finding waiting to happen.
Evidence is also inherently point-in-time. It’s a snapshot, not a live feed. What turns a collection of snapshots into a defensible audit record is consistency — the same data, collected on the same schedule, reviewed by the same process, month after month.
Why Evidence Must Be Tied to Your Compliance Chain
Here’s something that surprises people when they first think through it carefully: evidence sitting in a folder — even a very well-organized folder — is organizationally meaningless without context.
When an auditor reviews your evidence, they’re not just confirming that the data exists. They’re confirming that the data corresponds to a specific control, that the control is governed by a documented policy, and that someone is accountable for executing it through a defined procedure. The chain looks like this:
Controls → Policies → Procedures → Evidence
Controls define what must be true in your environment
Policies establish the organizational commitment and the why
Procedures define the how — the specific steps someone takes to satisfy the control
Evidence proves the procedure was actually executed
When evidence is detached from this chain, you lose the ability to answer the auditor’s most fundamental question: “What policy governs this control, and how does this evidence demonstrate compliance?”
This isn’t a theoretical concern. It’s the difference between walking into an audit with a coherent story and walking in with a pile of data that raises more questions than it answers.
It’s also worth noting that this structure mirrors how NIST CSF and SOC 2 are actually architected. Both frameworks are built around controls as the backbone. Evidence that can’t be traced to a specific control — and from there to a policy — doesn’t map cleanly to either framework, which creates gaps in your audit narrative.
A Real-World Example: The Monthly AWS IAM Review
Let’s make this concrete.
One of the most common evidence collection requirements across SOC 2 and NIST CSF programs is periodic access review. The principle is straightforward: you need to demonstrate that you know who has access to your systems, that access is appropriate, and that you’re actively reviewing and remediating accounts that shouldn’t have the access they do.
Under NIST CSF PR.AC (Identity Management and Access Control), organizations are required to manage identities and credentials for authorized users, devices, and processes. Under SOC 2 CC6.2 and CC6.3, auditors specifically look for evidence of logical access provisioning and removal — including proof that someone is periodically reviewing whether active accounts should remain active.
For organizations running on AWS, this typically means a monthly IAM account review. The evidence template should capture:
Field Purpose Account Name / Username Identifies the account under review Account Created Date Flags accounts that may have been provisioned without a current business need Last Login Date Surfaces dormant accounts — a common finding Attached Roles or Policies Reveals over-permissioned accounts, particularly unexpected admin access Account Status Active / Inactive / Flagged for remediation Reviewer Notes Documents the human judgment applied to anomalies
The reviewer, working through this evidence, is looking for specific red flags: accounts with no login activity in 90 or more days, service accounts with admin-level policies that exceed their operational scope, accounts attached to roles that no longer reflect the user’s current responsibilities.
Now consider two scenarios.
Without structure: Someone exports a CSV from the AWS IAM console, drops it into a shared drive folder labeled “Q2 IAM Evidence,” and moves on with their day. Three months later, the auditor asks who reviewed it, what action was taken on the two accounts with no logins since January, and where that review is documented. Nobody knows. The evidence exists, but the compliance program doesn’t.
With structure: The evidence template is linked to the Monthly IAM Access Review procedure. That procedure is linked to the Access Control Policy, specifically the article governing access provisioning and periodic review. The policy maps to SOC 2 CC6.2. The assignee submits the completed template. The reviewer approves it — or flags the dormant accounts and opens a remediation task. The record is timestamped, immutable, and traceable from evidence back to control in three clicks.
Same underlying data. Completely different compliance posture.
When Evidence Breaks Down: Action Plans
In a perfect world, evidence is collected on schedule, every time, without fail. In the actual world, assignees leave the company, system changes break collection workflows, and procedures that were perfectly clear when written become ambiguous when the person who wrote them is no longer around.
A gap in evidence collection isn’t just a documentation problem. It’s a signal that a control may not be operating reliably — which is a systemic risk that needs active remediation, not just a note in a spreadsheet.
This is what Action Plans are for.
When evidence collection breaks down, an Action Plan documents the gap formally:
What failed: the specific control and the nature of the failure (e.g., “IAM access review not completed for three consecutive months”)
Who owns remediation: a named individual with accountability
Timeline: a specific date by which the control should be operating reliably again
Progress tracking: checkpoints between now and the remediation deadline
Action Plans aren’t punitive. They’re how mature compliance programs handle the reality that things break. The alternative — quietly hoping nobody notices — is how organizations walk into audits with gaps they can’t explain.
Critically, open Action Plans should be visible in your overall risk posture. A critical control with an open remediation item represents elevated organizational risk. That should show up somewhere leadership can see it — not sit in a tab that only the compliance manager has bookmarked.
The Integration Problem — and the One-Click Solution
Here’s the part that makes evidence collection genuinely painful for most organizations: the data you need doesn’t live in your compliance platform. It lives in AWS. In Okta. In your HRIS. In your ticketing system. In Google Workspace.
The traditional approaches to this problem are all bad in different ways:
Manual exports are error-prone, time-consuming, and depend entirely on the person remembering to do them on schedule. They also tend to capture slightly different data each time, which creates noise in your evidence record.
Custom scripts solve the consistency problem but create a maintenance problem. The person who wrote the script leaves. The API endpoint changes. The script breaks quietly and nobody notices for two months.
Enterprise GRC integrations solve both problems, but they cost six figures, take months to implement, and require ongoing administration that smaller compliance teams simply don’t have capacity for.
PolicyCo takes a different approach. With connections to over 500 API providers, you connect your data source once. Then the PolicyCo agent writes the collection code for you — no developer involvement, no script to maintain. For the IAM example: connect AWS, tell the agent which fields your evidence template requires, and you have a one-click workflow that captures every IAM account with the required metadata on whatever schedule you set.
The evidence doesn’t just get collected. It gets collected into the evidence template, linked to the procedure, linked to the policy, linked to the control. It’s born inside the compliance chain rather than needing to be retrofitted to it after the fact.
That distinction matters more than it might seem. Evidence that arrives pre-connected to its compliance context is ready for review immediately. Evidence that has to be manually linked to its context after collection introduces the exact kind of friction that causes programs to slip.
Everything Feeds the Risk Dashboard
Evidence collection doesn’t happen in a vacuum. Every piece of evidence — submitted, overdue, flagged, or remediated — is a signal about whether your controls are actually operating.
Overdue evidence means a control may not be executing on schedule. An open Action Plan means a systemic gap is actively being remediated. A cluster of flagged reviewer notes in a single control area means something worth investigating.
A compliance program that treats these signals as isolated administrative tasks is always going to be reactive — finding problems when auditors find them, rather than before. A program where all of that activity feeds into a unified risk view gives compliance leaders something genuinely valuable: the ability to know where their exposure is before anyone asks.
That’s what the Risk Dashboard in PolicyCo is designed to surface — a real-time view across your full compliance chain, from frameworks to policies to procedures to evidence to attestations to action plans. When something slips, it shows up. When it’s remediated, that shows up too.
The goal isn’t a perfect dashboard. It’s an honest one.
The Right Size for the Job
Enterprise GRC platforms solve real problems. If your organization has a dedicated GRC team, a multi-year implementation budget, and compliance obligations that span dozens of frameworks across thousands of controls, that level of infrastructure is probably justified.
For everyone else, the goal is a compliance program that’s rigorous without being laborious. Evidence collection done right is owned by specific people, reviewed by a second set of eyes, traceable back to the obligations that require it, and automated wherever consistency matters more than manual effort.
That’s not a simplified version of compliance. That’s what compliance actually looks like when it’s working.
Want to see how PolicyCo handles evidence collection end-to-end — from template design to API-connected collection to the Risk Dashboard? [Schedule a demo at policyco.io/schedule.]