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.]

The call comes on a Tuesday. Your auditor needs to verify that your Acceptable Use Policy was active and acknowledged by a specific employee — someone who left the company eight months ago — on a date roughly six months before that.

You open your shared drive. There are four files with variations of the same name. You’re not sure which one was current at the time. You check your email for an approval thread. You find three. You’re not sure which one was final. You check your HR system for the acknowledgment record. It doesn’t store historical policy versions.

You have two hours before you need to respond.

Something has gone wrong. The details don’t matter — a breach, an access failure, a data handling violation. What matters is that legal is now involved, and they’re asking a question that sounds simple: can you prove that your employees were trained on the relevant procedure before this happened?

You know they were. You’re almost certain. But “almost certain” isn’t what your legal team needs. They need a record — a timestamped, versioned, auditable record — of who acknowledged what, and when, and under which version of which policy.

You start making calls. You start checking folders. You realize, slowly, that the answer might be no.

These aren’t edge cases. They’re the moments that compliance programs are ultimately judged by — and most programs aren’t built for them.

There’s a version of compliance that exists to pass an audit. It looks fine from the outside: policies exist, procedures are documented, HR is tracking attestations as part of onboarding. During a routine review, it holds together. But the audit that digs into a specific moment in time, or the incident that demands a complete chain of evidence going backward — that’s a different kind of pressure. And it reveals something important about the difference between a compliance program and a compliance program.

Most compliance programs are designed to pass an audit during calm times. Few are built to survive scrutiny after something goes wrong.

This guide is for both kinds of reader: the compliance manager who has been through an audit and wants to build something that holds up better next time, and the operations or legal professional who is living through an incident right now and trying to understand where the gaps are.

We’re going to walk through each layer of a compliance program — frameworks and controls, policies, procedures, evidence, attestations, and action plans — and look at where risk accumulates when these layers aren’t actively managed. For each area, we’ll cover what auditors look for, what an incident exposes, and what a well-run program looks like in contrast.

The goal isn’t checkbox compliance. It’s the kind of program that, on its worst day, can still tell a clear, defensible story.

Frameworks & Controls: The Foundation That Has to Hold

Before we get into what goes wrong, it helps to be precise about what we’re talking about — because “control,” “policy,” and “procedure” get used interchangeably in a lot of organizations, and that imprecision is itself a risk.

A control — the what. A specific requirement your organization commits to meeting. “Access to production systems shall be reviewed quarterly” is a control.

A policy — the why and who. The formal organizational statement that establishes the rule and assigns accountability for it.

A procedure — the how. The step-by-step operational instructions that turn a policy commitment into repeatable action.

A compliance framework like SOC 2 or HIPAA is essentially a collection of controls — a structured set of requirements your organization needs to meet and demonstrate. The controls are the skeleton. Policies and procedures are what give that skeleton muscle and motion. And evidence is how you prove, to an auditor or a court, that the whole system actually moved.

Which is why the first place risk accumulates is at the control level, before you ever get to policies or evidence. Specifically: controls that aren’t mapped to anything.

An unmapped control is one that exists in your framework — you’ve acknowledged it, you’ve committed to it — but there’s no policy that formally owns it and no procedure that operationalizes it. It’s a promise with no mechanism behind it. During an audit, an unmapped control is a finding waiting to happen, because the auditor’s job is to trace the control from commitment to evidence. If that chain is broken at the first link, there’s nothing to test.

Audit scenario

Your auditor asks to walk through your SOC 2 CC6.1 control — logical access controls. You can confirm the control exists in your framework. But when they ask which policy governs it, you name one that, on closer inspection, covers access provisioning but not quarterly access reviews. When they ask which procedure operationalizes the review itself, there isn’t one documented. The control was added when you first mapped your framework. Nobody ever built anything under it.

That’s a finding. Possibly two.

Incident scenario

A breach occurs in an area where your compliance framework says you have coverage. Your security posture documentation, your certifications, your sales collateral — all of it asserts that you control access to this category of data. But when counsel starts pulling the thread, the control in your framework maps to no policy. The policy that seems adjacent was never formally linked. There’s no procedure, no evidence, no chain.

You had coverage on paper. Legally, the question is whether you had it in practice. An unmapped control makes that question very hard to answer in your favor.

The other risk at the framework level is staleness. Compliance frameworks evolve — new controls are added, existing ones are updated, and your organization’s scope changes as you grow. A framework mapping that was accurate eighteen months ago may have drifted meaningfully from both the current framework requirements and your current operating environment. Controls with no assigned owner drift fastest, because there’s no one whose job it is to notice.

Key risk indicators:

• Controls in your framework that aren’t linked to at least one active policy

• Controls with no designated owner

• Framework mappings that were configured at implementation and never formally reviewed

• A gap between your certified scope and your actual operating environment

Policies: Your Statement of Intent (That Has to Hold Up Under Oath)

A policy is easy to underestimate. It looks like a document. It lives in a folder. Someone wrote it, someone approved it, and now it sits there being a policy. That mental model is the source of most policy-related risk.

A policy is actually an organizational commitment — a formal, dated, authorized statement of what your organization will do, who is accountable for it, and under what circumstances. When an auditor reviews your policies, they’re evaluating the integrity of that commitment: is it current, is it approved by the right people, has it been reviewed on schedule, and can you prove all of that? When an incident occurs and litigation follows, opposing counsel is doing the same evaluation — except they’re also asking whether the people affected by the policy actually knew about it.

That shift in framing — from document to legal instrument — changes how you think about policy hygiene. An outdated policy isn’t just a compliance gap. It’s a gap in your organization’s ability to defend its own stated standards.

The lifecycle of a policy matters as much as its content. A well-written policy that hasn’t been reviewed in three years, or that’s sitting in a pending approval state for six weeks, or that was updated last quarter but hasn’t been redistributed — each of those states carries its own risk profile.

Audit scenario

Your auditor asks for your policy review log for the past twelve months. You pull up what you have — a mix of email threads, a shared doc with some notes, and a handful of approval records in your policy management system, though not all policies went through that system consistently.

They start asking about specific policies. Your Remote Work Policy was last formally approved fourteen months ago. Your Incident Response Policy was updated eight months ago but shows as pending final approval — someone was out, the review stalled, and it was never formally closed. Your Data Classification Policy has two versions in your system with overlapping effective dates and no clear record of which superseded which.

None of these are catastrophic individually. Together, they paint a picture of a policy program that isn’t actively managed. That picture is a finding.

Incident scenario

A data handling violation occurs. Your Data Classification Policy was updated six months ago to address exactly this category of data — new language, clearer requirements, explicit handling rules. The update was thorough. The problem is that the update was never formally approved through your documented approval chain. It exists in your system as a draft. Legally, it was never your policy.

The version that was legally your policy at the time of the incident is the one from two years ago — before the new data category was even part of your business. Your organization violated a standard it hadn’t yet formally committed to. That’s a different legal position than violating a standard you had committed to, and not necessarily a better one.

Version control isn’t bureaucracy. It’s the mechanism by which you establish what your organization’s obligations actually were at a specific point in time.

The approval chain deserves particular attention. Policies approved by the wrong person — someone without documented authority to approve that category of policy — can be challenged. Policies with no approval record at all are difficult to defend as having been formally adopted. In a well-run program, every policy has a clear owner, a documented approver, an effective date, and a scheduled review date. The absence of any one of those elements is a gap an auditor will note and a lawyer will use.

A note on policy updates: every time a policy is materially updated, the review and approval cycle resets. An updated policy with a stale approval record isn’t an approved policy — it’s a draft with a legacy signature on it. And if the update was significant enough to change employee obligations, a fresh attestation cycle should follow.

The last policy risk worth naming is the one that feels the most administrative and carries the most consequence: scheduled reviews that don’t happen. Most frameworks require annual policy reviews. A defensible review is documented — it has a date, a reviewer, a record of what was considered, and either a confirmation that no changes were needed or a change log if they were. “We reviewed it” is not a review record.

Key risk indicators:

• Policies overdue for their scheduled review cycle

• Policies in a pending approval state for more than a few weeks

• Multiple versions of the same policy with unclear supersession records

• Policies approved by individuals without documented approval authority

• Updated policies where re-attestation hasn’t been triggered

• No documented record of what was considered during a scheduled review

Procedures: Where Policy Meets Reality

The compliance chain runs: Controls define what you commit to → Policies establish who owns that commitment and why → Procedures describe exactly how employees fulfill it → Evidence proves it happened. Procedures are the operational layer — the point where an organizational promise becomes a human action.

If a policy is what your organization promises, a procedure is what your employees actually do. That distinction sounds obvious until you start looking at the gap between the two — and in most compliance programs, that gap is where operational risk quietly accumulates.

A procedure removes ambiguity. It answers the questions a policy leaves open: not just “access shall be reviewed quarterly” but who performs that review, using which system, following which steps, producing which output, by which deadline. When a procedure is well-written and formally distributed, there’s no reasonable defense of “I didn’t know how to do it.” When it isn’t — when the procedure is missing, stalled in approval, or distributed to the wrong departments — that defense becomes available, and it cuts both ways.

That bidirectional liability is what makes procedures uniquely important in incident scenarios. A missing or undistributed procedure can shield an employee from individual accountability while simultaneously exposing the organization — because if the employee was never given documented operational guidance, the failure was systemic, not personal. Courts and regulators tend to find systemic failures more consequential, not less.

Audit scenario

Your auditor asks you to walk through how your organization performs its quarterly access review. You describe the process — IT pulls a report, managers review their direct reports, exceptions are escalated, the results are logged. It sounds solid.

Then they ask to see the procedure document. You find one, but it references your old identity management system, which you migrated away from eighteen months ago. The steps are functionally obsolete. More importantly, it was never updated after the migration, which means the procedure your team has been following exists only as institutional knowledge — not as a documented, approved process.

The auditor notes that your access review control lacks a current supporting procedure. The evidence you’ve been collecting is real, but it’s evidence of an undocumented process. That’s a weaker position than it should be.

Incident scenario

An employee in your customer support department improperly accesses and shares a category of customer data they shouldn’t have touched. Your Data Handling Policy clearly prohibits this. But when you trace the incident, you find that your Data Handling Procedure — the document that translates that policy into specific, role-based guidance for support staff — was approved six months ago and distributed to the engineering and operations departments. It was never sent to customer support.

The employee violated a policy they were aware of in principle. But they were never given documented operational guidance on what that policy meant for their specific role and their specific access. The organization published a rule without operationalizing it for the people most likely to need it.

That’s not a technicality. It’s a material gap in your compliance program, and it’s the kind of gap that shapes how regulators and courts assess organizational culpability.

The approval problem for procedures deserves its own moment. Unlike policies, which typically flow through a centralized approval chain, procedures often require departmental approval. And departments, being busy places run by people with other priorities, are where procedures go to stall.

A procedure sitting in departmental approval limbo is in a dangerous state. Employees can’t be held to a standard they were never officially given. Evidence collected against an unapproved procedure is evidence of informal practice, not documented process. The procedure needs to complete its approval cycle to be real in any compliance or legal sense.

The same logic applies to procedures that reference outdated policy versions. When a policy is updated, any procedure built on it needs to be reviewed and reissued. A procedure pointing to a superseded policy is a broken link in your compliance chain — and broken links are exactly what auditors are trained to find.

Key risk indicators:

• Procedures stalled in departmental approval with no clear resolution timeline

• Procedures that reference outdated or superseded policy versions

• Procedures distributed to some departments but not the ones most affected

• Operational processes your team follows that exist only as institutional knowledge, not documented procedure

• Procedures that haven’t been reviewed since a significant system or process change

Evidence: Proof That Any of This Actually Happened

The compliance chain runs: Controls define what you commit to → Policies establish who owns that commitment → Procedures describe how employees fulfill it → Evidence proves it happened. Evidence is the terminus of the chain — the layer that makes everything above it auditable and defensible.

Every control in your framework, every policy commitment your organization has made, every procedure your employees are supposed to follow — none of it means anything to an auditor without evidence. Evidence is the documented record that a control was actually executed, not just designed. It’s the difference between a compliance program that exists on paper and one that exists in practice.

But evidence isn’t simply proof that something happened. It’s proof that the right thing happened, at the right time, in the way your procedures said it would. That three-part standard is where most evidence programs quietly fall short. Organizations collect something — a screenshot, a log export, a sign-off email — but what they collect doesn’t cleanly correspond to the procedure it’s supposed to support, or it covers the wrong time window, or it was never formally reviewed before being submitted to an auditor.

The mechanics of evidence collection matter more than most compliance programs acknowledge. Evidence is typically organized around collection periods — defined windows of time during which a specific control is supposed to be executed and documented. When a period is missed, late, or only partially completed, the control it supports is effectively untestable for that window. You can’t retroactively collect evidence of something that wasn’t documented when it happened.

Audit scenario

Your auditor requests evidence for your quarterly access review control across the past four quarters. You have solid documentation for Q1 and Q4. Q3 is thin — a single spreadsheet with no clear date stamp and no record of who reviewed it or what exceptions were flagged. Q2 is missing entirely. Someone was out, the review happened informally, and nothing was saved in a retrievable format.

When you explain Q2, the auditor’s follow-up question is predictable: if the review wasn’t documented, how do you know it happened? You’re confident it did. But confidence isn’t evidence, and the auditor’s job is to test controls, not take your word for them.

One missing period is a finding. Two questionable periods starts to look like a pattern. Patterns suggest the control isn’t operating as designed — which raises questions about every period, including the ones that look clean.

Incident scenario

A breach occurs, and the post-incident investigation focuses on whether your access controls were functioning in the months leading up to it. You have evidence for some periods. Others are gaps. A few have documentation that’s inconsistent — different formats, different levels of detail, no clear record of who reviewed the output.

In a litigation context, inconsistent evidence collection is almost as damaging as missing evidence. A gap in your record doesn’t just leave that period undefended — it invites scrutiny of the periods where evidence does exist. Opposing counsel will argue that the inconsistency undermines the reliability of your entire evidence record.

The organizations that weather post-incident scrutiny well are the ones with consistent, structured, complete evidence records. Not perfect ones — auditors and courts understand that organizations are run by humans. But consistent ones, where gaps are documented and explained, not simply absent.

The alignment between evidence and procedure is worth dwelling on. Evidence doesn’t exist in isolation — it’s supposed to document the execution of a specific procedure, which is itself supposed to operationalize a specific policy, which is supposed to fulfill a specific control. When evidence is collected informally, without reference to the procedure it supports, that chain of alignment breaks down. You end up with evidence of something, but not necessarily evidence of the right thing.

Evidence review before submission is a step many programs skip entirely. Collecting evidence and submitting evidence are two different activities. A formal review — confirming that what was collected covers the right period, corresponds to the right procedure, and is complete enough to be meaningful — is the difference between evidence that holds up and evidence that raises more questions than it answers.

Key risk indicators:

• Missing or incomplete collection periods for active controls

• Evidence that doesn’t correspond to a specific procedure or collection window

• Inconsistent evidence formats across periods for the same control

• No formal review of collected evidence before auditor submission

• Evidence stored in unstructured locations with no clear retrieval path

• Controls where evidence collection depends on a single person with no documented backup

Attestations: The Human Layer of Compliance

The compliance chain runs: Controls define what you commit to → Policies establish who owns that commitment → Procedures describe how employees fulfill it → Evidence proves it happened. Attestations run alongside the entire chain — they’re the documented record that the people responsible for executing your compliance program were formally made aware of what was expected of them.

Every other layer of your compliance program is about documents, processes, and records. Attestations are about people. They’re the mechanism by which your organization formally communicates its policies to the humans who are supposed to follow them — and creates a record proving that communication happened.

That record is load-bearing in ways that compliance programs frequently underestimate. An attestation isn’t a formality. It’s a documented acknowledgment that a specific person, at a specific point in time, was presented with a specific version of a specific policy and confirmed they understood it. Strip away any one of those specifics and the attestation loses its evidentiary value.

The most common misunderstanding about attestations is treating them as an onboarding event rather than an ongoing program. HR collects signatures during new hire orientation — code of conduct, acceptable use policy, data handling agreement — and files them away. The box is checked. But policies change. New policies are introduced. Annual re-attestation requirements exist precisely because a signature from three years ago doesn’t reflect what an employee understood about a policy that has since been materially updated. An attestation record tied to onboarding alone is a historical artifact, not an active compliance mechanism.

The version of the policy an employee attested to matters as much as the fact that they attested at all. If your Acceptable Use Policy was significantly updated last year and you didn’t trigger a fresh attestation cycle, your most recent acknowledgment record reflects a policy that no longer says what it said when people signed it. That’s not an attestation program — that’s paperwork.

Participation rates are the metric that exposes attestation program health most directly. An attestation campaign that closes at 67% completion means roughly a third of your workforce has no documented acknowledgment of the policy in question. During a routine audit, that’s a finding. In the context of an incident involving someone in that 33%, it becomes something more serious — documented evidence that your organization was aware of incomplete coverage and didn’t resolve it.

The tracking problem compounds quickly in organizations with any meaningful employee turnover. Former employees who never completed an attestation before leaving represent open records in your program — gaps that can’t be retroactively closed. Contractors, seasonal staff, and volunteers create their own complications, particularly in organizations where those populations touch regulated data or systems.

Audit scenario

Your auditor asks for your annual security awareness policy attestation results. You pull the report: 71% completion across the organization. They ask about the remaining 29%. You explain that reminders were sent, some people were on leave, a few are contractors who were harder to reach. The auditor asks whether you have a documented escalation process for non-completions and a record of it being followed. You don’t — the campaign ran, reminders went out, and whatever completion rate resulted was accepted.

They then ask which version of the policy the attestation was tied to. You check. The attestation campaign was launched against a policy version that was superseded three months into the campaign window when a material update was approved. The employees who completed early attested to the old version. The ones who completed late attested to nothing — the link wasn’t updated when the policy changed.

Two findings. One could have been avoided with a completion threshold and escalation process. The other required version-aware attestation management that most email-based programs simply can’t provide.

Incident scenario

An employee makes a decision that results in a data exposure. Your Data Classification Policy was updated eight months ago to explicitly address this category of data and this type of decision. Your attestation record shows that this employee completed their initial onboarding attestation two years ago, before the update. When the policy was revised, a re-attestation campaign was planned but deprioritized. It was on the list. It hadn’t happened yet.

The employee didn’t know the policy had changed. Not because they were careless — because your organization never formally told them. You updated your commitment without updating the people responsible for honoring it.

In a regulatory investigation, this distinction matters enormously. An employee who violated a policy they had formally acknowledged presents one set of facts. An employee who violated a policy they were never informed had changed presents another. Neither outcome is good. But the second one raises questions about organizational due diligence that the first one doesn’t.

Role-based attestation is worth raising here as well. Not every policy applies equally to every employee. A data handling policy has different implications for an engineer with database access than for a sales representative with access only to a CRM. Attestation programs that treat the entire workforce as a single audience miss the opportunity — and sometimes the obligation — to ensure that the people with the highest-risk roles have specifically acknowledged the policies most relevant to what they do.

Key risk indicators:

• Attestation campaigns closing below a defined completion threshold with no escalation process

• Policies that have been materially updated without triggering a re-attestation cycle

• Attestation records tied to policy versions that have since been superseded

• Former employees with open or incomplete attestation records

• Contractors, volunteers, or seasonal staff with no attestation program at all

• No role-based differentiation for high-risk populations

• Attestation managed entirely through HR onboarding with no ongoing compliance ownership

Action Plans: The Remediation Record That Proves You Take Risk Seriously

Action plans are what close the loop. When any layer of your compliance chain reveals a gap — an unmapped control, an overdue policy review, a stalled procedure, a missing evidence period, a low attestation rate — an action plan is the documented commitment to fix it. It’s proof that your organization doesn’t just identify risk. It responds to it.

There’s a particular kind of legal and regulatory exposure that only action plans can create — and it’s different in character from every other risk we’ve discussed in this article. A missing policy, an incomplete evidence period, an unsigned attestation: each of those is a gap. Gaps can be explained, contextualized, remediated. They suggest a program that needed improvement.

A stalled action plan is something else. It’s documented proof that your organization identified a specific risk, assigned someone to address it, set a deadline, and then didn’t follow through. It transforms a gap into a known gap. And in compliance, as in most legal contexts, knowing and not acting is a fundamentally different — and fundamentally worse — position than simply not knowing.

This is why action plan discipline matters so much. It isn’t enough to open a plan when a risk is identified. The plan needs an owner with actual authority to drive remediation. It needs a realistic timeline with documented milestones. It needs status updates that reflect genuine progress. And when a plan is closed, there should be a documented validation that the remediation actually worked — not just that the deadline passed.

Audit scenario

Your auditor reviews your prior year findings. Three were identified in your last audit cycle. You’ve remediated two of them cleanly — documented fixes, evidence of the corrective action, formal closure. The third is still open. The target date passed four months ago. The most recent status update is a note from two months back saying it’s in progress.

The auditor’s response is measured but clear: a prior year finding with an overdue, stagnant action plan is a repeat finding. Repeat findings carry more weight than new ones — they signal that the organization’s remediation process itself isn’t working. You’ve now given the auditor two concerns where there was previously one.

A finding with an active, progressing action plan — even one that isn’t complete — is a recoverable position. A finding with a stalled plan and no recent activity is not.

Incident scenario

A security incident occurs. During discovery, opposing counsel requests all internal risk assessments, audit findings, and remediation records from the past three years. What they find is an action plan opened eighteen months ago following an internal security review. The plan identified a specific access control gap in the system category where the breach occurred. It was assigned to a team lead who left the company. It was never reassigned. It was never updated. It was never closed.

Your organization didn’t just have a gap. It found the gap, named it, documented it, and then watched it sit unaddressed for a year and a half while the risk it described materialized into an actual incident.

No compliance program is perfect. Auditors, regulators, and courts understand that. What they don’t extend grace for is documented awareness paired with documented inaction. That action plan — opened in good faith, abandoned in practice — is now the most damaging document in your discovery record.

Closing an action plan without validating the remediation is its own risk. A plan marked complete because the deadline passed, not because the fix was verified, gives false confidence and creates a misleading record. If the remediation didn’t actually work, you now have a closed plan on a problem that’s still open — which is harder to defend than a plan that was honestly left active while work continued.

Action plans also serve a forward-looking function that’s easy to overlook. A well-maintained action plan record tells a story about your organization’s risk posture over time — what you’ve identified, what you’ve fixed, and how quickly. That story matters to auditors assessing the maturity of your compliance program, to prospective customers doing due diligence, and in incident scenarios where demonstrating a consistent pattern of identifying and remediating risk is one of the strongest arguments for organizational good faith.

Key risk indicators:

• Action plans past their target date with no status update in the past thirty days

• Plans with no assigned owner, or assigned to someone who has left the organization

• Prior year audit findings that appear as open action plans with no documented progress

• Plans closed without a documented validation that the remediation was effective

• No regular review cadence for open action plans across your compliance program

• Risk areas with known gaps and no corresponding action plan at all

The Snapshot Problem: Why Point-in-Time Visibility Changes Everything

Every section of this article has described a different layer of compliance risk — unmapped controls, stale policies, stalled procedures, missing evidence, incomplete attestations, abandoned action plans. Each one is a real problem on its own. But there’s a structural issue underneath all of them that makes every other risk harder to manage and harder to defend against.

Most compliance programs are built to answer one question: where do we stand right now? Current policy status, current attestation completion rate, current evidence collection progress. That’s a useful question. It’s the wrong question when an auditor or an incident forces you to look backward.

Audits and incidents don’t ask about now. They ask about then. And “then” is a specific, unforgiving point in time — a date, sometimes a particular hour — at which your entire compliance posture needs to be reconstructable and defensible. Not approximately. Not based on best recollection. Precisely.

When an auditor or opposing counsel asks about your compliance posture on a date that is now six, twelve, or eighteen months in the past, the questions sound simple:

• Was that policy approved and in effect on that date — and which version?

• Had that employee formally acknowledged it before the incident occurred?

• Was the evidence collection period for that control complete at that point in time?

• Was that action plan open or closed — and if open, what was its last documented status?

• Which version of that procedure was in distribution to that department on that date?

If your compliance program lives in a collection of shared drives, spreadsheet trackers, email threads, and HR onboarding records, those questions are not answerable with confidence. You can approximate. You can reconstruct. You can make reasonable inferences. But you cannot point to a system and say: here is the verified, timestamped state of our compliance program on that date, across every layer of the chain.

The organizations that survive audits and incidents with their programs intact aren’t the ones with perfect compliance records. They’re the ones that can prove what their records actually were — at any point in time.

This distinction — between knowing your current posture and being able to reconstruct a past one — is what separates a compliance program from a compliance archive. A program generates a living, timestamped record as it operates. Every policy approval, every attestation, every evidence submission, every action plan update carries a date, a version, and a chain of accountability. That record doesn’t just support audits. It makes the audit almost mechanical — here is the state of the program on the date in question, here is the evidence, here is the chain.

An archive is what you’re left with when a program wasn’t built that way. Documents saved when someone remembered to save them. Attestations collected through processes that weren’t designed to be queried later. Evidence organized around the people who collected it rather than the controls it supports. When an audit or incident demands a point-in-time view, an archive requires reconstruction — and reconstruction is always incomplete, always subject to challenge, and always more expensive than the alternative.

Compliance program Compliance archive Timestamped records generated automatically as the program operates Documents saved when someone remembered to save them Point-in-time posture reconstructable on demand Past posture requires manual reconstruction, always incomplete Evidence tied to specific controls, versions, and collection periods Evidence organized around the people who collected it Audit response is retrieval Audit response is reconstruction

The good news is that this isn’t a problem that requires a perfect compliance program to solve. It requires a deliberate one — one where the infrastructure for capturing and preserving the state of the program over time is built in from the start, not bolted on when an audit notice arrives. The organizations that build that infrastructure rarely think of it as a defensive measure. They think of it as the only rational way to run a compliance program at any meaningful scale.

Build the Program for the Hard Day, Not the Easy Audit

We started this article with two scenarios. An auditor asking about a specific employee, a specific policy, a specific date. A legal team asking whether you can prove what your employees knew before something went wrong. Those scenarios aren’t hypothetical worst cases — they’re the moments compliance programs are ultimately built for, whether the people building them know it or not.

Most don’t build for them explicitly. They build for the next audit. They patch gaps when they’re found, collect evidence when it’s requested, run attestation campaigns when the calendar says it’s time. The program passes. The certification renews. And then something happens — an auditor who digs deeper than usual, an incident that puts the program under a different kind of scrutiny — and the seams show.

What we’ve walked through in this article isn’t a checklist of compliance failures. It’s a map of where risk accumulates when a program is managed reactively rather than proactively — when controls float unconnected above the policies and procedures that should anchor them, when policies are updated without the people who need to follow them being told, when evidence is collected informally and evidence gaps are explained rather than prevented, when action plans are opened in good faith and abandoned in practice.

Each of those failures is recoverable in isolation. What makes them dangerous is the compound effect — and the snapshot problem that sits underneath all of them. When an audit or an incident demands a point-in-time view of your program, every layer of the chain has to hold. A strong evidence record doesn’t rescue an attestation gap. A clean policy approval history doesn’t paper over a stalled action plan. The chain is only as defensible as its weakest link at the moment being examined.

The organizations that build compliance programs worth having aren’t trying to pass audits. They’re trying to run programs they’d be comfortable defending on their worst day — to an auditor, to a regulator, to a court, or to themselves.

That’s a higher standard than checkbox compliance. It requires treating policies as legal instruments, not living documents that can drift. It requires ensuring that procedures reach the people who need them, not just the departments that were easy to get sign-off from. It requires collecting evidence with enough structure that it’s retrievable and meaningful, not just technically present. It requires following through on remediation — not because an auditor will check, but because an open action plan on a known risk is the most dangerous document in any discovery request.

And it requires infrastructure that preserves the state of the program over time, so that when someone asks what your compliance posture looked like on a specific date in the past, the answer is a retrieval, not a reconstruction.

None of this is beyond reach. It doesn’t require a large team or an enterprise budget. It requires clarity about what a well-run compliance program actually looks like — and the discipline to build toward that, one layer at a time.

If any of the risk indicators in this article felt familiar, you’re not alone — and the gap between where your program is and where it needs to be is almost certainly smaller than it feels right now. The hard part isn’t knowing what good looks like. It’s having the right system to get there and stay there.

PolicyCo’s Risk Management Dashboard gives you a real-time view of risk across every layer of your compliance program — frameworks, policies, procedures, evidence, attestations, and action plans — so the gaps surface before an auditor or an incident does. If any of this resonated, we’d love to talk through where your program stands. Book a demo and we’ll walk you through it together.

In 493 of 494 SOC 2 reports generated for Delve’s customers, auditors used nearly identical boilerplate language — including the same grammatical error, copied verbatim across hundreds of supposedly independent assessments. All 259 Type II reports contained word-for-word identical conclusions. Same missing word. Every single one.

That detail, surfaced by an anonymous whistleblower in March 2026, is the most clarifying fact in a story that has otherwise generated more heat than light. It tells you everything you need to know about what Delve’s platform actually produced: not evidence of compliance, but the shape of compliance — a document that looked right from a distance and meant nothing up close.

Delve raised $32 million at a $300 million valuation. It was a Y Combinator darling, founded by MIT dropouts, profiled in the New York Times. And according to the whistleblower known as DeepDelver, it may have convinced hundreds of companies — including NASDAQ-traded firms and HIPAA-covered healthcare organizations — that they had earned security certifications they never actually earned.

YC has since cut ties with them. The lawsuits will sort out the rest.

But the more important question isn’t what Delve did. It’s why it worked for as long as it did — and what it reveals about a compliance industry that got confused about which end of the process evidence actually belongs on.

HOW THE FRAUD WORKED: THE INVERSION

To understand what Delve allegedly did wrong, you first need to understand what the right order looks like.

A legitimate compliance program follows a chain. You start with a framework — SOC 2, HIPAA, NIST — which defines the controls your organization is expected to operate. Those controls get linked to specific articles within policies: the written commitments that say “this is how our organization behaves.” Policies get operationalized into procedures: the step-by-step instructions that tell specific departments and people exactly what to do and when. And then — only then — evidence gets collected: the artifacts that prove the procedures are actually being followed.

Controls → Policies → Procedures → Evidence.

That sequence isn’t bureaucratic formality. It’s the logical dependency chain of a real program. Evidence is only meaningful if there’s a procedure it’s proving. A procedure only has authority if there’s a policy behind it. A policy only has teeth if it maps to a real control requirement.

What Delve allegedly did was run this chain backwards. According to DeepDelver, the platform generated audit conclusions before observation periods ended. Controls were marked effective before evidence was collected. Reports were drafted before auditors had tested anything. The whistleblower called it precisely what it was: “Delve places itself in the role of both implementer and examiner. This is not a technicality. It is a structural fraud that invalidates the entire attestation.”

The auditor independence problem made it worse. Most Delve customers were routed toward a small cluster of audit firms — two in particular, reportedly operating primarily out of India with nominal U.S. presence — that appear to have rubber-stamped whatever conclusions the platform generated. An auditor who doesn’t design their own tests isn’t an auditor. They’re a notary.

The result was a machine that produced the paperwork of compliance without any of the underlying program. Fast. Cheap. Catastrophically fraudulent.

THE OUTLINE THAT WASN’T THERE

Here’s a way to think about why this matters structurally, not just legally.

Imagine hiring a researcher to write a book. Instead of doing the research, drafting an outline, writing chapters, and then adding citations to support what was written — they start with the citations. They generate a bibliography first, then work backwards to invent the text those citations were supposed to support. The book looks like a book. It has footnotes. It even has a table of contents.

But there’s no argument. No substance. The footnotes don’t prove anything because there was never anything to prove.

That’s what happened at Delve. Evidence is the footnotes of a compliance program. It exists to prove that something real happened — that a board actually reviewed a risk assessment, that access logs were actually reviewed, that incident response was actually tested. When you generate the footnotes before writing the book, you haven’t documented a program. You’ve fabricated one.

This matters beyond Delve because the pressure that created Delve hasn’t gone away. The compliance automation market was built on a single pitch: we can get you to certification faster. Speed became the competitive differentiator. Platforms that could generate evidence quickly won customers. Nobody asked the obvious follow-up question — faster than what, exactly? Faster than doing the underlying work? That’s not automation. That’s omission.

WHY BUYERS COULDN’T SEE IT

The uncomfortable truth is that Delve’s customers were mostly asking the wrong question.

The question most compliance buyers ask is: “Will this get us certified?” The question they should be asking is: “Will this make us actually secure?” Those sound like they should be the same question. In a well-functioning market, they would be. But the SOC 2 certification became so thoroughly commoditized — so thoroughly a sales tool and vendor questionnaire checkbox — that the substance got quietly decoupled from the signal.

Buyers optimized for the signal. Vendors supplied it. When an auditor hands you a clean Type II report and your sales team can put a SOC 2 badge on your trust page, the incentive to ask deeper questions basically disappears. That’s not naivety. It’s rational behavior inside a broken system.

The Delve scandal exposed the full cost of that rationality. Context AI, an AI startup that used Delve for its security certifications, later disclosed a data breach that cascaded into a security incident at Vercel. The compliance paperwork didn’t stop anything. It couldn’t have — it was never connected to the controls it claimed to document.

Companies facing potential criminal liability under HIPAA and fines of up to 4% of global revenue under GDPR are now discovering that the certificate was not the program.

WHAT REAL COMPLIANCE INFRASTRUCTURE ACTUALLY LOOKS LIKE

The antidote to the Delve model isn’t more skepticism about automation — it’s understanding what automation is actually for.

Automation is legitimate and valuable when it supports a program that already exists. Automated reminders that policies are due for review. Dashboards that surface unlinked controls before an auditor finds them. Evidence collection workflows attached to procedures that departments actually own and operate. These are tools that make a real program easier to run. They’re not substitutes for the program itself.

The compliance chain has to be built in the right order. Frameworks get mapped to controls. Controls get linked to specific articles within policies. Policies get operationalized into procedures owned by real people in real departments. Evidence gets collected against those procedures. And risk gets monitored continuously — not assembled retroactively at audit time when it’s too late to do anything about it.

That last point is worth dwelling on. One of the quieter lessons of the Delve story is that the compliance programs that failed weren’t just missing evidence — they were missing visibility. Nobody in those organizations could look at their compliance program on a random Tuesday in February and say “here are the three things most likely to create exposure before our next audit.” The only moment of reckoning was the audit itself. Which, it turns out, was also fabricated.

A compliance program built correctly has risk visible at every layer. Unlinked controls are a signal. Overdue policy reviews are a signal. Departments sitting on unapproved procedure drafts are a signal. Attestation campaigns with 30% completion rates are a signal. Missing evidence collection periods are a signal. Stalled action plans on failed controls are a signal. None of those require an auditor to surface. They should be visible on a dashboard your team checks the same way you check your pipeline.

QUESTIONS WORTH ASKING YOUR COMPLIANCE VENDOR RIGHT NOW

If you’re evaluating a compliance platform — or reconsidering one you already use — the Delve story gives you a useful diagnostic framework. A few questions worth putting directly to your vendor:

Does your platform require existing policies before it lets you collect evidence? If evidence collection has no dependency on documented procedures, you’re building footnotes for a book that doesn’t exist.

Can you trace a single control from framework requirement to policy article to procedure to evidence artifact? If the chain is broken anywhere, the attestation is theoretical at best.

Who selects your auditors, and do they have a financial relationship with your platform vendor? Auditor independence isn’t a nice-to-have. It’s the entire mechanism by which an attestation means anything.

What does your compliance posture look like between audits — not just before them? If your platform can only show you a clean dashboard when you’ve just prepared for an audit, it’s not showing you your compliance posture. It’s showing you your audit preparation.

COMPLIANCE IS A DRAFT, NOT A DEADLINE

The Delve story is being told as a fraud story, and it is one. But underneath the fraud is a more widespread failure of category thinking.

The compliance industry convinced itself — and its customers — that the certificate was the goal. Get certified. Renew annually. Show it to prospects. The program was the means to an end, and if you could skip the program and go straight to the end, so much the better.

What gets lost in that logic is the only thing that makes any of this worth doing. Policies aren’t paperwork. They’re the written commitments that tell your organization what it stands for and how it operates. Procedures aren’t busywork. They’re the operational translation of those commitments into daily practice. Evidence isn’t a deliverable for auditors. It’s proof to yourself that the program is real.

When you build evidence on top of nothing, you haven’t accelerated compliance. You’ve written the last chapter of a book with no story behind it. The auditor gets a report. The customer gets a badge. And nobody, anywhere, is actually more secure.

Real compliance programs are living documents. They get written, reviewed, revised, and operated by real people who own real procedures. The risk is visible continuously, not assembled on deadline. The goal was never the certificate.

The goal was the program.

---

PolicyCo is a policy lifecycle management platform built around the compliance chain — from framework controls through policies, procedures, evidence, and attestations. If you’re building a program that’s meant to hold up to more than a typo check, start here: https://policyco.io

Something has shifted in how people work with software. Over the past year, AI chat agents have gone from novelty to daily driver. Teams are using tools like Claude, ChatGPT, and Copilot not just to draft emails or summarize documents, but to pull real answers from real data, in real time, without switching tabs or hunting through dashboards.

The connective tissue behind this shift is a standard called MCP — the Model Context Protocol. Think of MCP as a universal adapter that lets AI agents plug into the tools and platforms your team already uses. If APIs are the plumbing that lets software systems exchange data, MCP is the fitting that lets an AI agent turn on the faucet. It gives agents structured, permissioned access to your data so they can do something useful with it — not just parrot back what’s on your screen, but actually reason over what’s behind it.

Today, we’re bringing that capability to PolicyCo.

Meet the PolicyCo MCP Connector

The PolicyCo MCP Connector lets AI agents connect directly to your PolicyCo environment. That means your team can interact with policies and procedures from inside their chat agent — Claude, for example — without ever leaving the conversation to open the platform.

Right now, the connector supports foundational capabilities: listing policies and procedures, searching across your document library, and asking natural-language questions about the content of those documents. Need to know what your data retention policy says about third-party processors? Ask your agent. Want to pull up the onboarding procedures for a specific department? Same thing.

But what makes this genuinely powerful isn’t just convenience. It’s what happens when an AI agent has structured access to the relationships PolicyCo already maintains between your policies, procedures, and controls.

Why Relationships Matter

Most organizations manage policies as isolated documents — PDFs in a shared drive, pages in a wiki, maybe a spreadsheet mapping controls to frameworks. The problem isn’t just that it’s tedious. It’s that the connections between documents exist only in someone’s head, or worse, in no one’s head at all.

PolicyCo is built differently. Every policy connects to related procedures. Procedures map to controls. Controls tie back to compliance frameworks. These aren’t loose references; they’re structured, maintained relationships that reflect how your compliance program actually works.

When an AI agent can access that relationship graph, it stops being a search tool and starts being an analyst. It can trace a question about a single procedure upstream to the policy that governs it and downstream to the evidence that supports it. It can surface connections across documents that would take a human hours to piece together manually.

Where We’re Headed

This initial release is deliberately focused. We want to get the foundation right and let real usage guide what comes next. On the roadmap: deeper analytical capabilities around risk exposure, gap identification, and cross-framework coverage — the kind of bespoke reporting that turns a policy library into a strategic asset.

The goal hasn’t changed. PolicyCo exists to give organizations a smarter way to manage policies and procedures — one built on structured relationships that can be mined for clarity, maintained as you grow, and now, queried conversationally through the tools your team already uses every day.

The PolicyCo MCP Connector is available now. Connect your account and start asking questions.

There’s a growing trend in SaaS: replace every human touchpoint with a chatbot, staff support teams as thin as possible, and hope customers figure it out on their own. For compliance software — where the stakes include audit failures, regulatory penalties, and organizational risk — that approach isn’t just frustrating. It’s negligent.

At PolicyCo, we made a deliberate choice to build something different. Not a platform that serves thousands of anonymous accounts, but a partner that knows your team, your compliance goals, and the specific challenges keeping you up at night.

Real People, Not Ticket Queues

When you have a question about PolicyCo, you reach a dedicated support resource who already understands your environment. They know which frameworks you’re mapping to, how your organization structures its policies, and where you are in your compliance journey. That means fewer explanations on your end and faster, more relevant answers — including hands-on help configuring your workspace when you need it.

This isn’t a luxury tier or an upsell. It’s how we operate for every customer.

Training That Respects Your Time

Our onboarding and training sessions are led by humans who can read the room, adjust to your team’s experience level, and field the unexpected questions that inevitably surface when compliance meets reality. We build in extensive Q&A because we’ve learned that the most valuable insights emerge from unscripted conversations — the edge cases your team encounters daily that no knowledge base article will ever cover.

Your Feedback Shapes the Product

When you submit a feature request or report a bug, it enters a transparent process with genuine two-way dialogue. You’ll hear back about prioritization decisions and timelines, not just a form confirmation that disappears into a backlog. Our product team is accessible because we believe the people using the software daily have the clearest view of what it should become next.

This feedback loop isn’t performative. Customers who look at our release notes regularly see their input reflected in the product.

The Boutique Advantage

We’re not trying to be the compliance vendor for every company on earth. PolicyCo is built for organizations that understand a compliance platform isn’t a commodity purchase — it’s an operational relationship that compounds in value over time. As your policies mature, your frameworks evolve, and your team grows, a vendor who has been in the room with you adapts in ways a self-serve platform simply cannot.

That long-term partnership creates something no AI agent or automated workflow can replicate: institutional knowledge about your organization that lives in the people who support you, not just the database that stores your documents.

The Cost of Cheap Support

Every hour your compliance team spends wrestling with unhelpful chatbots or waiting on undertrained support reps is an hour not spent strengthening your actual compliance posture. The vendors racing to cut human interaction from their cost structure are passing that cost directly to you — in wasted time, mounting frustration, and risk that quietly accumulates when questions go unanswered.

We’d rather invest in knowing our customers well than in scaling to customers we’ll never meet.

If your compliance program deserves more than a ticket number, let’s talk.

Sandra had been a home care coordinator at a regional nonprofit for eleven years. She knew the intake process cold. So when a new volunteer, David, called her confused about the emergency escalation steps in the updated onboarding procedure, she wasn’t worried. She walked him through it from memory.

Two weeks later, a client situation escalated. David followed the written procedure — not Maria’s verbal override — and called the wrong contact. Everyone was fine, eventually. But the incident report revealed something uncomfortable: the procedure itself was wrong. A phone number had changed six months ago. Nobody had updated the document.

David had noticed the number looked odd when he first read it. He had no way to say so.

The Gap Between the Reader and the Writer

Procedures are written by people who understand a process deeply. They’re read by people who are closer to the work, often finding edge cases and real-world gaps that the author never encountered. Without a channel for that knowledge to travel upstream, organizations run on documents that drift further from reality with every passing month.

The solution isn’t a rating system. Ratings tell you that something’s wrong. They don’t tell you what or how to fix it. What you need is a voice — a structured way for the person reading a procedure to say: this step is missing a decision point, or the contact here retired in March, or in our region, this works differently.

Feedback as a Living Signal

Imagine David, reading that escalation procedure on his first week, sees a small prompt: Something missing or unclear? Let us know. He types a note: “The emergency number in Step 4 doesn’t match what’s posted at the front desk. Which one do we use?”

That comment doesn’t disappear into a void. It routes directly to the procedure owner — in this case, the Director of Care Operations. She sees it flagged in her queue, alongside the specific section David was reading when he wrote it.

She responds: “Great catch, David. The front desk number is correct — we updated the system in Q3 but the procedure wasn’t synced. I’ll revise this week.”

That exchange matters. It’s not just a correction. It’s a signal that feedback is read, that the process is responsive, and that frontline workers have real influence over the tools they use. That signal makes the next person more likely to speak up.

From Comment to Release

The Director revises Step 4, marks it for internal review, and a second set of eyes approves the change. The procedure moves to a new version — not a quiet overwrite, but a tracked revision with a change summary: Updated emergency escalation contact to reflect Q3 staffing change. Flagged by onboarding volunteer.

Now the system does something important: it identifies everyone who previously attested to Version 1.2. They receive a notification. This procedure has been updated. Please review the changes and re-acknowledge.

David gets one too. He reads the update, sees his name acknowledged in the change log, and signs off. The audit trail is clean. The organization can demonstrate, if ever asked, exactly when the error was discovered, how it was corrected, and who confirmed the updated version.

Closing the Loop Is the Product

The feedback wasn’t the end of the story. It was the beginning of a process — comment, conversation, revision, release, attestation — that transformed a passive document into a living one.

Organizations that treat procedures as finished products the moment they’re published are accumulating invisible risk. The people closest to the work almost always know something the document doesn’t. The question is whether you’ve built a way for them to tell you.

PolicyCo makes that loop possible — from the first read to the final signature.

Maria had a problem. As the Operations Director for a regional conservation non-profit, she managed 500 field volunteers spread across 40 different programs—from wetland restoration crews to wildlife monitoring teams to community education ambassadors. Each program had its own set of procedures, roughly 25 per group on average. That’s 1,000 procedures, all living in a tangled web of Google Docs, shared drives, and email threads.

And every single one of them was a liability waiting to happen.

The Breaking Point

The incident that finally pushed Maria to find a better solution wasn’t dramatic. A volunteer on the invasive species removal team used an outdated herbicide application procedure. The old version had been superseded three months earlier after new safety guidelines came out. The volunteer wasn’t negligent—they’d simply downloaded the procedure to their phone for offline access back in the spring and never thought to check for updates.

Fortunately, no one was hurt. But Maria spent the next two weeks fielding questions from the board, documenting the gap in their process, and wondering how many other outdated procedures were floating around in email inboxes and phone downloads across her 500-person volunteer network.

She knew the answer: probably dozens.

The Hidden Complexity of Procedure Management

Most people think procedure management is simple. You write a document, you share it, people follow it. But Maria had learned the hard way that effective procedure management actually involves solving several interconnected problems at once.

First, there’s the writing and approval process. Procedures don’t spring into existence fully formed. They start as drafts, get reviewed by subject matter experts, require sign-off from leadership, and often go through multiple revision cycles before they’re ready for distribution. Maria’s team had no consistent way to track where each procedure was in this pipeline. Draft versions sometimes got distributed accidentally. Approved versions sat in someone’s inbox for weeks before being shared.

Then there’s version control. When a procedure changes—and they always change—you need to know exactly what changed, when it changed, and why. Maria’s team used a naming convention with version numbers in the filename, but it was honored more in the breach than the observance. She’d find documents named “Volunteer_Safety_v3_FINAL_revised_ACTUAL.docx” and have no idea if it was newer or older than “Volunteer_Safety_v4_draft.docx.” The history of how a procedure evolved over time was essentially lost.

Distribution presents its own challenges. Not every volunteer needs every procedure. The wildlife monitoring team doesn’t need the community event setup checklist. The education ambassadors don’t need the chainsaw safety protocol. Maria needed to get the right procedures to the right people—and only those people. With 40 different volunteer groups, each with different procedure sets, maintaining accurate distribution lists was nearly a full-time job.

Finally, and perhaps most critically, there’s the question of acknowledgment. Sending a procedure isn’t the same as someone reading it. Maria could email an updated procedure to 50 volunteers, but she had no way of knowing if 5 or 45 of them actually opened and read it. When something went wrong, she couldn’t demonstrate that volunteers had been properly informed. She was exposed, and she knew it.

Finding a Better Way

Maria started researching procedure management solutions with a clear list of requirements. She needed a system that could handle the full lifecycle of a procedure—from initial draft through approval, distribution, and eventual retirement. She needed rock-solid version control that would automatically track every change and maintain a complete history. She needed granular distribution controls so procedures only went to the volunteers who needed them. And she needed attestations: a way for volunteers to formally acknowledge that they’d read and understood each procedure.

What she found surprised her. Most document management tools solved one or two of these problems but not all of them. Standard cloud storage platforms offered version history but no approval workflows or attestation tracking. Email could distribute documents but created no record of who actually read them. Enterprise compliance platforms had all the features but were priced for Fortune 500 companies and designed for full-time employees, not volunteer workforces.

She eventually found a purpose-built procedure management platform that addressed each of her pain points directly. The system maintained a complete version history automatically—no more filename gymnastics. When she updated a procedure, the system incremented the version number, logged what changed, and preserved the previous version for reference. If she ever needed to see what the herbicide application procedure said six months ago, that information was two clicks away.

The approval workflow meant procedures moved through a defined pipeline: draft, review, published. Nothing went out to volunteers until it was formally reviewed, and the system maintained a record of who approved what and when.

Distribution became targeted and automatic. Maria could assign procedures to specific volunteer groups, and when she updated a procedure, only the relevant volunteers received notifications. The wildlife monitoring team got their updates; the education ambassadors got theirs. No more blast emails to the entire volunteer list with instructions to “ignore if this doesn’t apply to you.”

Most importantly, the attestation feature gave Maria something she’d never had before: proof. When volunteers received a procedure notification, they were asked to confirm they’d read and understood the content. The system tracked who had attested and who hadn’t, with timestamps and a complete audit trail. Maria could finally answer the question “did everyone on the wetland restoration team read the updated safety protocol?” with certainty instead of hope.

The Transformation

Six months after implementing her new procedure management system, Maria’s world looked different. She’d consolidated all 1,000 procedures into a single, organized platform. Each volunteer group had access to exactly the procedures they needed—no more, no less. When regulations changed or best practices evolved, she could update a procedure and have confidence that the right people would be notified and that she’d have a record of their acknowledgment.

The board stopped asking nervous questions about liability exposure. New volunteer onboarding became smoother because procedures were easy to find and clearly organized. Program managers could see at a glance which of their volunteers had completed required procedure reviews and which needed reminders.

Maria still managed 500 volunteers across 40 programs. The complexity hadn’t gone away. But the chaos had. And that made all the difference.

PolicyCo.io helps organizations like Maria’s manage procedures from creation through attestation. If you’re ready to bring order to your procedure chaos, we’d love to show you how.

Sarah drummed her fingers on her desk, staring at the email from her biggest prospect yet. TechCorp wanted to send 500 decommissioned servers to GreenCycle for secure data destruction and recycling. The contract would triple her revenue. There was just one problem.

“We’ll need to see your SOC 2 Type II report before we can proceed.”

GreenCycle had been in business for 18 months. Ten employees. No board of directors. No compliance officer. Just Sarah (CEO), two logistics coordinators, four technicians who handled the actual e-waste processing, two sales reps, and an accountant who came in twice a month.

Sarah had heard about SOC 2, but always figured it was something for “later” — when they were bigger, more established, had a real office instead of a warehouse with a corner desk area. But TechCorp wasn’t the first client to ask. If GreenCycle wanted to move beyond small business clients and tap into enterprise contracts, SOC 2 wasn’t optional anymore.

The question was: where do you even start?

The Scoping Conversation That Changed Everything

Sarah called her friend Marcus, who ran a small security consultancy. “I need SOC 2,” she told him. “But I keep reading about these massive implementation projects, governance committees, and hundreds of controls. We’re ten people, Marcus. We don’t have a board. We don’t even have an HR department.”

Marcus laughed. “Sarah, you don’t need to boil the ocean here. You need to scope your audit to what actually matters for your business. Let me ask you something: what does GreenCycle actually do with client data?”

“We track what comes in — asset tags, serial numbers, client information. We document the destruction process. We provide certificates of destruction. Everything’s in our system.”

“Okay. And where does that happen?”

“Our warehouse in Oakland. We have a small office area, but most work happens on the floor — receiving, processing, documenting.”

“Any remote work?”

“Sales team works from home. I work from everywhere. The accountant is remote.”

“Cloud services?”

“We use Google Workspace. Our tracking system runs on AWS. We use Stripe for payments. That’s pretty much it.”

Marcus pulled out a notepad. “This is your scope, Sarah. This is what you’re actually protecting for your clients, and this is what an auditor needs to examine. Everything else? Out of scope for now.”

Mapping GreenCycle’s SOC 2 Scope

Over the next hour, Marcus helped Sarah map out what would actually be included in GreenCycle’s first SOC 2 Type II audit:

In Scope:

• The Service: Client data intake, tracking, secure destruction, and certificate generation

• The System: Their custom tracking platform (hosted on AWS), Google Workspace, and Stripe

• The People: All ten employees who touch client data or the systems that process it

• The Locations: The Oakland warehouse and remote work locations for sales team

• The Data Flow: From client submission through tracking, processing, documentation, and certificate delivery

Explicitly Out of Scope:

• Physical security of the warehouse (beyond basic controls for the office area where computers were kept)

• E-waste recycling processes themselves (that was a different certification)

• Financial systems beyond what was needed for audit logging (the accountant’s QuickBooks setup wasn’t handling client data)

• Future plans for a customer portal (didn’t exist yet)

“But wait,” Sarah interrupted. “Doesn’t SOC 2 require a board of directors? Doesn’t it require separate security and compliance teams?”

“No,” Marcus said firmly. “SOC 2 requires effective controls. It doesn’t prescribe your organizational structure. You’re small. That’s fine. What matters is that you can demonstrate you’re doing the right things consistently.”

The Baseline Control Set

Marcus helped Sarah understand that for a company GreenCycle’s size, pursuing Trust Services Criteria with a focused scope, they could start with a manageable set of controls:

Security (required for all SOC 2 audits):

• Access controls for their tracking system and Google Workspace

• Password policies and multi-factor authentication

• System monitoring and logging

• Regular security updates

• Vendor security assessments for AWS and Stripe

• Basic incident response procedures

• Background checks for employees handling sensitive data

Confidentiality (relevant for GreenCycle’s service):

• Non-disclosure agreements with employees

• Secure data destruction procedures

• Encryption for data in transit and at rest

• Secure certificate delivery to clients

Sarah noticed what was missing from the list: no change advisory board (they used a simple Trello board for tracking system updates), no formal risk committee (Sarah reviewed risks quarterly with her leadership team of three), no dedicated security operations center (they used AWS CloudWatch and set up basic alerts), no disaster recovery site (they had AWS backups and a documented recovery process).

“This doesn’t look like the SOC 2 requirements I’ve been reading about,” Sarah said.

“That’s because most SOC 2 content is written by enterprise consultants for enterprise companies,” Marcus explained. “The actual Trust Services Criteria are principles-based, not prescriptive. They say you need to identify risks, implement controls, and monitor effectiveness. They don’t say you need a 40-person security team to do it.”

Making It Work Without a Board

One thing kept nagging at Sarah: “Every policy template I’ve found references board oversight and board approval. We don’t have a board. Does that kill this whole thing?”

“Not at all,” Marcus assured her. “You need governance and oversight, but it doesn’t have to be a formal board. Who owns the company?”

“I do, completely. I’m the founder and sole owner.”

“Perfect. You’re the ultimate authority. You can act as the governing body. Your policies will say something like ‘The CEO, acting as the governing authority for GreenCycle, reviews and approves all information security policies annually.’ You’ll document those reviews. You’ll show the auditor that you’re making informed decisions about risk and controls.”

Sarah felt the weight lift a bit. “So I just... approve things?”

“You govern things,” Marcus corrected. “You make informed decisions about what risks to accept, what controls to implement, and how to allocate resources. You document those decisions. You review them periodically. That’s governance. A board of directors would do the same thing — you’re just doing it as the CEO because you are the highest authority in the company.”

For management review meetings, Sarah would involve her three key people: the Operations Manager (who oversaw the warehouse), the IT contractor who managed their systems, and the Sales Director. Together, they’d review:

• Security incidents and near-misses

• Access reviews (who had access to what)

• Vendor assessments

• Policy effectiveness

• New risks from business changes

“Document those meetings,” Marcus advised. “Take notes. Track action items. That’s your evidence that you’re actively managing your security program.”

The Six-Month Journey

Marcus laid out a realistic timeline for GreenCycle’s first SOC 2 Type II:

Months 1-2: Foundation and Documentation

• Finalize scope with the chosen auditor

• Document policies (information security, acceptable use, access control, data classification, incident response)

• Implement any missing technical controls

• Set up evidence collection processes

Months 3-8: The Observation Period

• Live with the controls for six months (minimum for Type II)

• Collect evidence continuously

• Conduct monthly access reviews

• Hold quarterly management reviews

• Document any incidents or exceptions

Months 9-10: Audit

• Auditor testing and fieldwork

• Respond to auditor questions

• Remediate any findings

• Receive the SOC 2 report

“Ten months total,” Sarah said. “That’s actually doable.”

“It’s doable because you’re being realistic about scope,” Marcus emphasized. “You’re not trying to implement every control in the NIST Cybersecurity Framework. You’re implementing the controls that make sense for protecting client data in your specific business model.”

What “Light Scoping” Really Means

As Sarah worked through the scoping process, she realized “light scoping” didn’t mean “weak security.” It meant:

Focus on what matters: Client data protection for e-waste services, not every possible security control that could theoretically apply

Right-size your controls: Multi-factor authentication and password policies instead of enterprise single sign-on and privileged access management systems

Document what you actually do: Their weekly team huddles where they discussed any security issues became “management security review meetings” once they started taking proper notes

Scale appropriately: Their three-person leadership team reviewing quarterly risks was just as effective as a large company’s formal risk committee — it was just smaller

Be honest about limitations: GreenCycle’s SOC 2 report would include a clear description of what was in scope. Clients would know exactly what was being attested to.

The Payoff

Eight months later, Sarah received GreenCycle’s first SOC 2 Type II report. Clean opinion. No exceptions.

More importantly: she understood her own security program. The scoping process had forced her to think clearly about what GreenCycle was promising clients, what systems delivered on those promises, and what could go wrong. The controls weren’t busywork — they were genuine protections that made the business more reliable.

The TechCorp deal closed. Then three more enterprise contracts followed in the next quarter.

“Best part?” Sarah told Marcus over coffee. “We’re not scrambling. When larger clients ask about our security program now, I can actually explain it. When they ask about our board oversight, I explain our governance structure and they get it. When they want to know about our scope, I can articulate exactly what we protect and how.”

“That’s what good scoping does,” Marcus said. “It gives you clarity. Not just for the auditor, but for your business.”

Lessons for Your First SOC 2 Scope

If you’re approaching SOC 2 from a similar position — small team, no formal board, limited budget — here’s what GreenCycle’s experience teaches:

Start with your service: What are you actually promising clients? What data are you handling? What systems deliver your service? That’s your scope.

Don’t scope for the company you want to be: Scope for the company you are today. You can expand scope in future audits as you grow.

Governance doesn’t require a board: It requires informed decision-making and documented oversight. A CEO can provide both.

Use your size as an advantage: Smaller teams can often implement controls more quickly and consistently than large, siloed organizations.

Be explicit about boundaries: Clearly document what’s in scope and what’s not. This protects you and sets accurate expectations for clients.

Your first audit is about learning: Yes, you need the report for clients. But the real value is understanding your own security posture and building controls that scale.

Ready to scope your first SOC 2 audit? PolicyCo’s platform helps organizations of any size document their scope, map controls to Trust Services Criteria, and maintain the evidence auditors need — without enterprise complexity. Schedule some time with us to see how policy lifecycle management can support your compliance journey from day one.

We’ve been working hard to improve the PolicyCo platform. Here’s a list of features added and bugs squashed.

Features Added

Document Import

We’ve made it a lot easier to bring your word documents into PolicyCo. Before this upgrade, it was a pretty tedious process to bring in complete policies. Now, we have a way for you to upload your word document and let you set breaks for each article. You need a basic understanding of the Markdown text language, which we can walk you through one on one.

Multi Period Downloads

When you need to download gathered evidence over a range of periods (think 12 months of a year), it’s now just a few clicks in platform.

Archive / Unarchive Procedures

Sometimes you don’t need that procedure anymore. Now you can archive it with peace of mind knowing that you can come back to it at a later date and bring it back to life.

Table Width

Reproducing tables used to be a problem, but now we are more accurately setting the width of tables between the editor view and the PDF/Word exports.

ChatGPT

We’ve upgraded our platform to the latest ChatGPT model to help you converse with our platform in a natural way. This is a great way to obtain natural responses to Vendor / Third Party Assessments.

Action Plans

Sometimes a full blown action plan isn’t necessary to remediate failed evidence collection. You can now cancel an action plan if it’s not necessary.

Table of Contents and Cover Pages

Set your preference at the organization level to include or exclude, while still keeping the ability to override that setting at download.

Edit Review Cycle

Change the review cycle and the reviewer without altering the policy. Thanks to our clients for bringing this to our attention.

Bypass Period

Sometimes you need to bypass a period when gathering evidence. Think of this as an Action Plan light.

Bugs Squashed

• Improve response of audit log listing

• Attestations not showing correctly in some edge cases on the viewer

• Attestations categories improved (removed ‘superseded’ language)

• Some procedure downloads failing

• Improve keyword search across policies and procedures

• Provide ability to copy redline text for candidates

• Table rendering fixes

• Document share fixes

• Bulk author updates fixed

Introduction

In today's fast-paced business world, organizations must ensure that their employees are aware of and adhere to company policies and procedures. This is where attestations come into play. Attestations are an essential part of the governance process, as they provide a means for organizations to capture signatures from their team members, demonstrating that policies have been acknowledged and understood. In this article, we will discuss the importance of attestations in governance and accountability, with a focus on legal responsibility and the role they play in ensuring that employees are aware of company standards related to their work behavior.

The Role of Attestations in Governance

Governance refers to the system of rules, practices, and processes by which an organization is directed and controlled. It involves balancing the interests of various stakeholders, such as shareholders, management, customers, suppliers, financiers, government, and the community. Attestations play a crucial role in governance by providing a formal mechanism for employees to acknowledge their understanding of and commitment to company policies and procedures.

One of the primary objectives of governance is to ensure that organizations operate within the confines of the law and adhere to established ethical standards. Attestations help achieve this goal by creating a clear audit trail that demonstrates employees' awareness of and compliance with company policies. This not only helps organizations maintain a strong legal standing but also fosters a culture of accountability and transparency.

Legal Responsibility and Attestations

From a legal standpoint, attestations serve as evidence that employees have been informed of their responsibilities and the company's expectations regarding their work behavior. This is particularly important when it comes to policies that have legal implications, such as those related to data privacy, workplace safety, and anti-discrimination.

For example, ensuring that employees have signed an acceptable use policy (AUP) is crucial for organizations that handle sensitive data or operate in highly regulated industries. An AUP outlines the acceptable use of company resources, including computer systems, networks, and electronic devices, and helps protect the organization from potential legal liabilities arising from unauthorized or inappropriate use of these resources. By obtaining employee attestations for the AUP, organizations can demonstrate that they have taken the necessary steps to inform employees of their responsibilities and expectations, thereby reducing the risk of legal issues and potential penalties.

Similarly, attestations can play a critical role in demonstrating compliance with workplace safety regulations. By obtaining employee signatures on safety policies and procedures, organizations can show that they have made a concerted effort to educate their workforce on safe work practices and have taken the necessary steps to minimize the risk of accidents and injuries.

Attestations and Accountability

In addition to their legal benefits, attestations also promote a culture of accountability within an organization. When employees sign off on company policies, they are effectively acknowledging their understanding of the rules and their commitment to abide by them. This not only helps to ensure that employees are aware of their responsibilities but also fosters a sense of ownership and personal accountability for their actions.

Moreover, attestations can serve as a valuable tool for management to gauge employee engagement and identify potential areas of concern. For instance, if a significant number of employees have not signed off on a particular policy, this may indicate a lack of understanding or awareness, signaling the need for additional training or communication efforts.

Implementing an Effective Attestation Process

To fully realize the benefits of attestations in governance and accountability, organizations must implement an effective attestation process. This includes:

1. Establishing clear and comprehensive policies: Organizations must develop well-defined policies that outline employee responsibilities and expectations. These policies should be easily accessible and written in a language that employees can understand.

2. Communicating policies to employees: It is essential to ensure that employees are aware of company policies and understand their implications. This may involve conducting training sessions, distributing policy documents, or using digital platforms to disseminate information.

3. Obtaining employee attestations: Organizations should establish a formal process for obtaining employee signatures on policy documents. This may involve using digital tools, such as electronic signature platforms, to streamline the process and maintain a secure audit trail.

4. Monitoring and enforcing compliance: Management must regularly review employee attestations to identify potential areas of concern and take appropriate action to address any issues. This may involve conducting audits, providing additional training, or implementing disciplinary measures for non-compliance.

5. Continuously updating and improving policies: Organizations must regularly review and update their policies to ensure that they remain relevant and effective. This may involve soliciting employee feedback, monitoring industry trends, and staying abreast of changes in laws and regulations.

Learn more...

Conclusion

Attestations are a vital component of the governance process, serving as a means to demonstrate legal compliance and promote a culture of accountability within an organization. By implementing an effective attestation process, organizations can not only protect themselves from potential legal liabilities but also foster a transparent and responsible work environment that benefits all stakeholders.

We recently released our attestations module.

It’s almost impossible to calculate the time individuals spend ensuring policy consistency across an organization. We painstakingly attempt to follow style guides to underscore brand uniqueness. Templates for decks, docs and spreadsheets help, but they are limited because content creators can override template styles.

When writing policy and procedures, content is king. Policies and procedures demand consistency. Font face, size, styles, sections, titles, table of contents, headers, footers, and numbered lists need to be the same across all documents.

Even for a small organization with dozens of policies, maintaining consistency requires dedicated clerical intervention with a critical eye. Even a very small change like adding an underline to every H2, requires opening every policy to make the style change. Imagine combing through scores of policies to ensure numbered points are setup as 1.(A)(i) instead of 1.2.3. The problem is compounded with large organizations.

PolicyCo documents inherit styles from a single source of truth set at the organization level. All styles are set from one place for all documents. Practically, this means your team can write content without the distraction of setting styles. Additionally, you gain the flexibility to change your mind by changing styles for the organization, updating every policy at once. Coupling this with our article-first approach to building policy, the table of contents is also constructed based on your established hierarchy.

Also, our document classification feature has the capability to add custom headers and footers to different document classifications in minutes rather than hours.

We recognize that maintaining policy is different from creating word documents and we developed a platform that specifically caters to the needs of policy writers. Don’t estimate the hidden costs of busywork. If you’d like to learn more visit us at PolicyCo.io.

Homogenize the Enterprise was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Maintaining your compliance posture is hard work. There are many personalities and competing interests. Business Development wants to grow. Operations needs to be nimble. Product wants to innovate and be reliable. Legal strives to stay out of trouble. Leadership needs to manage the big picture. These competing interests naturally create silos of information.

One of the greatest challenges to a compliance program is mining these silos and associating them in some meaningful way to policy. Further complicating this, we recognize that the information and activity in each silo is dynamic often changing on a daily or weekly basis. Some examples include:

• Onboarding and offboarding procedures

• Data architecture diagrams

• Customer service procedures

• Devops procedures

• IT procedures and support guides

• Purchasing and finance guidelines

Policies are generally managed by legal or compliance teams. It’s not uncommon to see outdated procedures tied to policy to keep up with changes to each silo.

Modern Problems Require Modern Solutions

Departments need autonomy when writing procedures, runbooks and process manuals. Managers often use Word or Google Docs and distribute them via email or from a shared drive. Technical teams may opt for Confluence, Github (via readme.md) or Dropbox. These are all great solutions and should continue to be used, but they need some sort of glue to hold them together to ensure your policies have procedural coverage.

PolicyCo addresses this need by giving your departments independent access to write and share procedures. Department members are able to write procedures and submit them for approval to their manager. Managers can grant access to the department or extend access to the organization.

“Finally, the compliance team can stop chasing down outdated procedures. This means less work for everyone.”

Compliance needs to make sure procedures are current. Once a procedure is created, compliance can link it directly to policy. Now, procedures are maintained in real time by departments while legal/compliance benefits by eliminating the upkeep. It’s a win-win for the enterprise.

Policy can be exported with or without procedures attached, depending on the specific need. Further, employees can browse or search procedures with a lightweight mobile-friendly viewer improving knowledge transfer across the organization.

The Champion

Stop fighting the silos and embrace your various systems by recording where procedural source of truth lives.

It takes an operational mindset to address growing inefficiency in an organization. If you are the champion for your organization and are interested in solving this problem, we’d love to talk.

Cooperative Compliance Across the Enterprise was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your organization is an ecosystem of interworking parts; a vast collection of automated and manual agents, ideally pointed in a direction with the intent of improving your chances for success or optimizing market value. Healthy organizations spend an immense amount of time documenting their inner workings though training both verbal and written. But how do we determine if your activities are contributing to positive change?

Obviously, policy plays an important role. SOC2 addresses many of the key points required to operationalize your workflow. It codifies board involvement, hiring, operational flow and security just to name a few. Even with all its strengths, an organization cannot realize the full benefit without oversight.

Oversight

Mature organizations understand the benefits of meaningful oversight. The connotations of oversight range depending on one’s perspective. It’s understandable for an employee to feel mistrusted if their work is always scrutinized by a third-party. As a leader, it’s important to focus on organization excellence and how oversight can unearth meaningful data to inform decisions leading to better outcomes.

At this point, it’s important to visualize an example of oversight applicable to your organization. Let’s assume that your organization conducts background checks on individuals and maintains standards related to the results of those investigations. We can break this down and follow the path through, control, policy, procedure and evidence.

• Control. SOC2 CC1.4.2 contains relevant language related to an employee’s background. While this control isn’t completely prescriptive, it makes that point that you, as an organization, make every effort to hire individuals who have the skills needed to perform their intended job function.

• Policy. If we look to your Workforce Onboarding and Clearance policy, we are likely to find an article related to the Scope of Background Investigations. This article must state the organizational requirements; in this case, that a background check must be performed, reviewed, and stored.

• Procedure. This is where the substantive language begins. The procedure outlines specific steps, vendor names, individual or roles and, properly written, allows for little to no room for interpretation.

• Evidence. (also known as control tests) Evidence captures procedural activity demonstrating that procedures are followed as written. Referring to our example, this might be a list of current employees cross referenced to a list of background checks. Do we have a 1–1 match? If we have standards for rejection based on the background check findings, did we follow those standards?

The steps above are all critical to your compliance effort, but getting to finish line requires several more important steps.

Accountability

Let’s focus on the last step, evidence. I’m going to make a case here for the importance of separation of duties for automated and manual evidence gathering. It’s great when we use API’s to automate gathering routine evidence month after month. For information we cannot gather automatically, we must gather manually.

Automation breaks. Who holds accountable the programmer responsible for the script when it stops functioning as expected or when the returned data is not longer relevant?

Manual processes become outdated. Who reviews manual evidence and compares it to the procedural language to ensure that it satisfies the spirit of the connected procedures, policy and controls?

The answer to both questions points to an independent review process. This means that the person or process gathering evidence must not also bear the responsibly for verifying accuracy. This distinction lays the groundwork for how Management Action Plans can transform your organization.

Self Improvement

Athletes don’t excel by being complacent. It’s a daily routine of self critique, analysis, and a will to improve. Organizations are no different. Oversight highlights weak processes by shedding light on procedural shortfalls, but awareness is only the first step. Next, we must devise a plan to remediate.

Management Action Plans do exactly this. They set into motion a chain of custody between the reviewer and the procedural stakeholder ensuring that steps will be taken according to mutually agreed upon timelines, to resolve failed control tests.

Let’s look at our previous example to see how a Management Action Plan might be used to resolve a failed control test.

• Assignee submits the results of employee background checks monthly.

• Reviewer views each background check and finds that there are 3 employees on the new hire list without a background check on file.

• Reviewer fails the period and sets in motion a Management Action Plan. At this stage, the reviewer (1) crafts a narrative explaining the nature of the failure; (2) assigns a plan Author with the necessary skills to write the plan and; (3) sets a due date for the written plan. “I’m seeing 3 employee background checks missing from February. Please explain why and how you expect to resolve this in the future.”

• The Author is now required to submit their plan by the prescribed date. The Author must also provide an estimated plan completion date. This plan is not considered approved until the initial reviewer accepts the plan. “We changed to a new vendor in mid February and our new vendor isn’t sending the to us. I will notify the vendor to get the missing three background checks and will ask them to setup and automated process to place these in the correct location upon completion.”

• Once the plan is complete, the Author is again responsible for explaining the details of the completion, and this too, is subject to reviewer approval. “Our new vendor was able to provide the past reports and they have agreed, and I have verified that reports are going to the correct location.”

The example above represents a straightforward use case. Management Action Plans can be very complex involving months or years of planning to remediate. It’s plausible that an organization might consider modifying policy or procedures in order to accommodate limitations around evidence gathering activities.

I hope this article has helped you better understand how Management Action Plans can help you and your team think critically and use that information to continually aim for excellence. Reach out to us to learn more.

How Do Management Action Plans Lead to Organizational Excellence? was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

A well-prepared cybersecurity program can minimize threats; however, a company can never eliminate risk due to the human factor. For example, the CIOX incident from July 2021 was from a single email account and yet affected thousands of individuals. Cyber threats have evolved to become more organized and sophisticated, so what happens after a large-scale incident is reported?

Activate the Incident Response Plan

The incident response plan outlines the steps and phases of what to do when a breach has occurred. It also establishes a communication channel so the organization knows who to notify in the event of a violation. A well-established plan should include performing mock sessions and reviewing the plan annually. One of the first steps in any incident response plan will consist of updating the team with as much information about the breach as possible, including:

• How was the threat discovered?

• What areas does this impact?

• Who discovered it?

• When was it first noticed?

Isolation and Eradication

During this time, the team will collect any available data from applications and interview anyone involved with the breach. The team will identify the threat and contain it to prevent further damage. Depending on the nature of the breach, this could include short-term and longer-term containment strategies. Once the team removes the threat, the team will identify the root cause to prevent similar attacks in the future (e.g., patching a system, resetting passwords, or removing malware). Depending on the nature of the episode, you may need to consider engaging with a forensic firm that can identify all areas impacted. For example, a breach of an email account could have further repercussions because a hacker could have spoofed and sent emails to other individuals gaining access to additional accounts.

Analysis of legal requirements

Once the team eradicates the threat, the team needs to review legal and regulatory requirements. Whether there are legal requirements is likely dependent on the type of data exposed and accessed (e.g., Did this involve PHI? Was client data accessed?). Review your contract matrix to determine the notification period and contact details. Identify what regulations you might need to follow (e.g., Do you need to report this to a government entity?). If the analysis concludes the external individuals are affected, you should seek legal counsel. Additionally, depending on the extent of the breach, you may need to notify your cyber liability insurance carrier.

Notification

You will need to start informing victims and relevant government entities at this stage. If the breach is extensive and includes PHI, you might be obligated to report it to the media to comply with HIPAA regulations. You may consider hiring a PR firm to orchestrate the messaging and your legal team. If you are a business associate, you should be prepared to provide enough information to the covered entity to identify all individuals impacted by the incident. Before sending notifications, prepare statements that address frequently asked questions (e.g., Why did this happen? What is the company doing to ensure this does not happen again? Who was involved?). The organization needs to identify which employees can answer questions about the breach and whether they are confidential or still under development. If multiple individuals are involved, you may want to consider setting up a call center that is prepared to answer frequently asked questions. A breach notification can also lead to an external audit. You will want to secure all evidence gathered related to the breach and ensure your policies and procedures are up to date.

Lessons Learned

The incident response team will want to regroup and minimize future threats. Determine the root cause of the breach, identify the risk to eliminate through policy changes, updates, or purchasing cyber security tools, and perform an internal audit to identify additional risks. Need assistance creating an incident response plan or organizing your policies? Contact PolicyCo for help.

How to Survive a Compliance Incident was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Policy architecture is complex, and the difficulty is compounded as your organization attempts to comply with more regulations and frameworks. Ambiguity tends to be the culprit here. Fundamentally, we as humans like to fit things into a neat classification system. However, there is a mountain of terminology to master, and even then, we still often find that certain pieces of policy language can apply to more than one area.

The only reasonable way to navigate multiple control frameworks is to normalize framework concepts into your policy statements. That’s a mouthful, so let’s take a minute to break down the statement.

Normalizing Framework Concepts

A mathematician might think of this as finding the least common denominator, which is easy because there is a correct answer. In our world, it’s more complicated. We must rely on our interpretation of framework concepts to craft an appropriate policy statement. Let’s get started with a relatively straightforward example. Each of the controls listed below talks about the concept of encrypting data as it traverses a network. Some are more prescriptive, and others are more general. Note that HITRUST and CIS are very specific about the use of WPA2.

• HITRUST 0502.09m1Organizational.5 — Wireless access points are configured with strong encryption (AES WPA2 at a minimum).

• CIS 12.6 — Use secure network management and communication protocols (e.g., 802.1X, Wi-Fi Protected Access 2 (WPA2) Enterprise or greater).

• PCI DSS 4.1.1 — Encrypt transmission of cardholder data across open, public networks

• SOC2 CC6.7.2 — Uses Encryption Technologies or Secure Communication Channels to Protect Data — Encryption technologies or secured communication channels protect data transmission and other communications beyond connectivity access points.

• HIPAA 164.312(e)(2)(ii) — Implement a mechanism to encrypt electronically protected health information whenever deemed appropriate.

Let’s try to craft a policy statement (we call it an article) in our Wireless Security Policy that normalizes the above language for our use. We can accomplish this by looking at the concepts above and including those concepts that are common to all in our statement. Concepts: encryption, transit, wireless. This can get tricky because several of the controls above make no mention of wireless. It’s our responsibility to understand that transmission can happen over wired or wireless networks.

“Wireless access points must be configured with strong encryption. At a minimum, AES WPA 2 must be configured.”

The process of normalizing policy language is compelling. It means that we can state our intentions in our vernacular while adhering to principles defined by others.

So if we were to take our newly crafted article and bring it into our Wireless Policy, it might look like this:

1.3 Wireless Encryption

Wireless access points must be configured with solid encryption. At a minimum, AES WPA 2 must be configured.

HITRUST 0502.09m1Organizational.5

CIS 12.6

PCI DSS 4.1.1

SOC2 CC6.7.2

HIPAA 164.312(e)(2)(ii)

We’ve responsibly displayed the article and all applicable controls. The problem is that we wrote this in Word or Google Docs, which means these are just words on a page. There is no meaning embedded in these concepts, which means additional repetitive work for everyone. For example:

• We don’t know that Wireless Encryption is the third article in the policy

• We don’t know that this article is linked to 5 different framework controls

• We don’t know the meaning or definitions of these controls

Procedures

Different frameworks place varying emphasis on the presence of procedures. At PolicyCo, we strongly feel that each article should be accompanied by at least one procedure; after all, the article states what you intend to do while the procedure explains how you plan to go about it.

The incredibly vital part of admitting that you need a procedure is knowing that you only need to write it once to satisfy all the controls mapped to the article. In our example above, the procedure for ensuring that wireless access points are encrypted is as follows:

“Encryption is enforced through the Meraki wireless configuration dashboard at https://meraki.com. The dashboard enforces WPA2 for all access points, and the IT Director is in charge of the setup and enforcement of this security setting.”

This procedure, as written, states who is responsible for the execution and where to access the setting. We only had to write the procedure once to satisfy Article 1.3 plus the five related controls.

Evidence (Control Testing)

In much the same way procedures benefit from being tied to a single article, Evidence (Control Testing) benefits. The only responsible way to verify that procedures are being followed is to provide evidence of the activities described in the procedure. Interestingly, by the time we arrive at the description for testing, we don’t care much about the meaning of the controls. Our only responsibility is to validate that the procedure is being followed. This test follows a logical path back to the control (Evidence: Procedure: Article: Control).

Build Relationships

It’s an excellent motto for life and policy management. The only responsible way to tame multiple control frameworks is to normalize your internal language and build these relational connections. The process takes time, and careful consideration, but the rewards come in the form of peace of mind, productivity gains, and preparedness.

• For a given control, which policies are referenced (and where is it in the policy)?

• How many controls and frameworks are applicable for a given article within a policy?

• Do I have control requirements without policy associations?

• Am I missing procedures for some controls/articles?

• Am I collecting Evidence (Control Testing) for all of my controls required?

Those are just five questions, but we can answer dozens more by exploring the rich relationships created in the PolicyCo platform.

Originally published at https://policyco.io on January 4, 2022.

Navigating Multiple Control Frameworks was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

According to Tenable, over 44% of organizations use more than one security framework. Mapping controls from one framework to another is complex and adding to the complexity is the ambiguity of terms across the frameworks. Some frameworks have defined controls to follow, while others offer guidelines. At PolicyCo, we have created a mapping system that standardizes the terminology allowing us to easily map more than one framework to a procedure, policy, or piece of evidence. This required us to dissect the nuanced differences between the security frameworks allowing an organization to follow multiple frameworks while reducing the redundancy across an organization’s cybersecurity program. Below is the glossary of terms specific to mapping security frameworks back to the evidence, policies, and procedures.

ISO

• Standards: Specifications that similar organizations can use to ensure materials, products, processes, and services meet industry best practices

• Clauses: Sections containing specific requirements and processes.

• Controls: Safeguards to reduce security risks

SOC 2

• Criteria: An individual specification

• Category: Sections containing a set of specific criteria related to an aspect of the security program

• Internal Control: An organization’s objective to protect information security

HITRUST

• Category: Section containing specifications and objectives for information security and risk management

• Domain: Organized sections based on standard IT organizational structure

• Objective: Statement of the intended result

• Specification: Policies, procedures, guidelines, practices, or organizational structures, which can be operational, technical, or legal

• Reference: An individual requirement/ control

NIST

• Function: Organized cybersecurity activities and outcomes

• Category: A subdivision of a function that contains cybersecurity objectives

• Subcategory: Outcome driven statements and security controls

• Informative References: Detailed technical resources used to support implementing subcategories

PCI

• Goal: Organized section of requirements that state the intended result

• Requirement: Organized sections of security protocols/controls for securing data

• Sub-requirements: The specific security control for obtaining data

• Compensating Control: A similar method for adhering to the requirement utilized when an entity cannot meet the requirement as expressly stated

• Guidance: The core purpose of the requirement and additional content to assist in the definition of the requirement

Manage Multiple Frameworks with PolicyCo

Cybersecurity compliance can be overwhelming; hopefully, we’ve cleared up some confusion on the language used by some of the most popular frameworks. If you are struggling with managing multiple cybersecurity frameworks, PolicyCo can help. Our platform streamlines compliance processes across frameworks for organizations, and our vCISO team has extensive experience developing cohesive policy language from a variety of framework controls. Contact us for more information.

Originally published at https://policyco.io on December 14, 2021.

The Ambiguity of Compliance Terms was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing and reading employee handbooks can be tedious, so it isn’t surprising that many small businesses skip over them entirely. When your team is small, it may seem easier to talk about ideas, policies, and procedures as they come up in an ad-hoc way.

However, employee handbooks are useful for many reasons. Avoiding working on one because it’s not fun can cause you pain and strife down the road, including high staff turnover or even lawsuits. Effective handbooks clearly state expectations between the employer and employee. When everyone is on the same page, there are fewer risks to the employee, the employer, and the business as a whole. As a small business owner, to have a basic boilerplate employee manual. It needs to be both useful and engaging. If it doesn’t meet those two criteria, it’s probably not going to get read. It’s not going to do you any good if it just sits on a shelf collecting dust.

The basic purpose of an employee manual is to get everyone on the same page when it comes to expectations. Employees need to understand what their role is within the business and how they’re expected to reflect the values of the brand. When expectations are clearly stated upfront, you will be better able to recruit quality employees and prevent high turnover. In an increasingly millennial workforce, this is crucial. According to a study from Gallup, 21% of millennials say that they have changed jobs within the past year. That number is three times higher than non-millennials. Preventing turnover is essential today. It’s important that you only include the information that your employee absolutely needs. Employees will be much more likely to read through an entire employee manual if it is focused and relevant to their position. For instance, Nordstrom’s employee handbook contains only one rule: “Use good judgment in all situations.” If that’s all you need, then that’s all you need. Don’t bog down employees with unnecessary information. While your business may be a bit too complex for a single-line handbook, the idea remains the same: Say what they need to know and say it quickly.

When thinking about handbooks, benefits information, onboarding materials, and basic information about the way the business functions probably come to mind. None of these topics are particularly engaging. To make things a little bit more interesting, some notable companies have opted for a more innovative employee manual design. This approach leaves the basic, boilerplate information out of the employee manual and instead offers that information digitally. For a small business, this approach might be a bit much. However, there is no reason a web-based employee manual can’t be an engaging mix of both aspirational brand values and informative policy information. Your handbook or manual should focus on helping the employee better understand the business, their role within it, and the company’s brand and values.

Employee manuals don’t need to be endless pages of boring corporate information. You are in control of what it contains. What do your employees need to know about working in your organization? What does it mean to be a part of your team? What is acceptable and unacceptable behavior? With a well-written employee handbook, you and your team will work together like a well-oiled machine so that your business can thrive and grow.

Originally published at https://policyco.io on January 17, 2020.

Employee Handbooks and Your Small Business was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

PolicyCo](https://f.hubspotusercontent40.net/hubfs/5557240/Imported_Blog_Media/screen-shot-2021-01-29-at-11-24-09-pm-1.png)

Policies and Procedures commonly need to reference other areas of policies. A great deal of planning went into this feature. Standard hyperlinks are inadequate because it’s not possible to view the information behind the link without navigating to it. Hyperlinks in PolicyCo have a “peek” feature that reveals the contents of the linked content inline. This benefits the end user by promoting continuity while disgesting information. In the example above, we have the word Encryption linked to another article. As you can see, the contents of the hyperlink are visible in a window when the user clicks on it. PolicyCo allows linking to articles and procedures internally and also allows off-site links on the web. PolicyCo makes it easy for your organization to quickly establish policies and procedures pre-mapped to HIPAA, SOC2 and HITRUST controls. We have an advanced editor with strict version control and a groundbreaking evidence gathering workflow engine.

Originally published at https://policyco.io on January 30, 2021.

Hyperlink Articles and Procedures was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve dealt with compliance frameworks, you understand that not every available control applies to your company. There may be controls that reference regional requirements or PCI compliance that don’t apply to your organization. HITRUST has a whopping 1800+ controls. We’ve made it incredibly easy to filter for classes of controls you don’t need and mark them as not applicable. If you need the control at a later time, it can be reactivated as well.

Originally published at https://policyco.io on February 24, 2021.

Bulk Control Management was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

We did it! Link your evidence-gathering activities to multiple external controls. This incredible feature allows you to carefully manage coverage of your evidence-gathering activities back to each relevant control.
Imagine gathering evidence a single time and satisfying multiple controls across multiple frameworks. This update will help you distribute the burden and ensure coverage. Our unique relational approach to managing internal controls, external controls, procedures, and evidence gathering is intuitive and efficient. Want to learn more about our compliance management software platform?

Originally published at https://policyco.io on July 15, 2021.

Link Evidence to External Controls was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.