Policy attestations that survive a site visit.

Attestation — a record that a staff member has read and acknowledged a policy — is one of the easier compliance artifacts to produce and one of the easier ones to produce badly. The bad version looks identical to the good version until someone examines it.

The versioning problem, which is the whole problem

A staff member acknowledged the infection control policy. Which one? The policy was revised in March. If your record is a single flag on a person — acknowledged: yes — then the revision silently inherited every prior acknowledgement, and your evidence now asserts that people read a document that did not exist when they signed.

That is not a technicality. The reason to revise a policy is that something changed; the acknowledgement that matters is the one against the changed text. Attest to a version, not to a title.

The practical test: pick a policy you revised in the last year and ask what percentage of affected staff have attested to the current version. If your system cannot distinguish that from the all-time figure, the number you have been reporting is not the number you think.

Report the exceptions, not the percentage

Attestation dashboards are almost always built the wrong way round. 87% attested is a statistic. What an administrator needs is the thirteen names, grouped by supervisor, so that following up is a short conversation instead of a project.

The same inversion applies to the policies themselves. The useful view is not how many are current — it is which are overdue for review, who owns each, and by how long.

Who is required to attest, and to what

Not every policy applies to every person, and pretending otherwise degrades the evidence in both directions: it manufactures non-compliance for staff who were never in scope, and it hides genuine gaps in the noise. Define the audience per policy — by role, by site, by function — and track against that audience.

This also makes onboarding tractable. A new hire's attestation set is derivable from their role rather than assembled by whoever is doing orientation that week.

What the record has to contain

• Who — the individual, not the department.
• What version — identified specifically, and retrievable as it stood then.
• When — a date, not a period.
• What they affirmed — the text of the attestation itself, which may change over time and is part of the evidence.

An attestation record missing the version is the common failure. An attestation record where the policy text of that version can no longer be produced is the same failure one step later.

The connection to approval

Attestation sits downstream of a governance act. For a Health Center Program organization, the governing board has authority to establish or adopt policies for the conduct of the project and to update them when needed — which means the review cycle is not housekeeping, it is an exercise of a required authority.

So the full evidence chain for a policy is: the board approved it, the minutes record the approval, the approved version was published, the staff in scope attested to that version, and the review date is tracked. Most organizations have every link and cannot assemble the chain, because each link is stored by a different person in a different place.

What to do this quarter

• Pick three policies revised in the past year. For each, produce the version, its approval, and the list of staff who attested to that version. Time how long it takes.
• Wherever an attestation cannot be tied to a version, decide whether to re-attest. Usually the answer is yes, and doing it deliberately is much cheaper than doing it under a deadline.
• Write down the audience for each policy. Half the work of attestation tracking is knowing who was supposed to.

How RIEL structures this is covered in policies and governance, but the exercise above is worth running whatever you use.