Appearance
Policy Attestation
Publishing a policy puts it in force. Attestation records that the people it binds have seen it.
Campaigns
An attestation campaign addresses a published policy to a defined audience and tracks who has responded.
| Campaign state | Meaning |
|---|---|
draft | Being prepared; not yet issued |
active | Issued; responses being collected |
closed | Complete; results frozen |
Campaigns are governed records and are never deleted. A closed campaign remains as evidence of what was attested, by whom, and when.
Managing campaigns requires policy.write.
Acknowledging and declining
Every workspace role holds policy.attest — anyone can be asked to acknowledge a policy addressed to them.
| Response | Meaning |
|---|---|
| Acknowledge | The person confirms they have read and understood the policy |
| Decline | The person does not acknowledge, with a reason |
Declining is a first-class outcome, not a failure state
An attestation system that only permits acknowledgement produces 100% acknowledgement and no information.
A decline with a reason — "this policy requires me to use a system I have no access to", "clause 6 conflicts with the operating procedure my team follows" — is more valuable than the ninety acknowledgements around it. It is the only signal the process generates about whether the policy is workable.
Where attestations appear
Employees access their assigned attestations through the dedicated self-service Employee Policy Portal (/my-policies) and through their personal Workbench tasks.
Attestation due dates project into the GRC Calendar.
"Opened" != "Acknowledged"
To preserve legal and evidentiary integrity during audits, the platform records when an employee opens the policy (opened_at), but opening the document does not acknowledge it. The employee must explicitly submit an Acknowledge or Decline decision.
Semantic Doctrine: Attestation != Effectiveness or Compliance
Attestation is evidence of awareness, not of compliance
An acknowledged policy proves the person confirmed they read and understood it. It does not prove they follow it, and it does not satisfy an obligation the policy addresses.
- Attestation != compliance: High attestation rates confirm communication; they do not certify operational compliance.
- Attestation != control effectiveness: 100% acknowledgement does not mean technical or procedural controls are operating effectively.
- Evidence Fabric integration: Where an obligation specifically requires evidence of awareness (e.g. annual code of conduct acknowledgement), campaign results can be projected into the Evidence Fabric as an attestation assertion (
ASN-).
Coverage reporting
Campaign reporting tracks acknowledged, declined, and outstanding counts by organizational unit, role, and individual:
- Departmental non-response: Concentrated non-response usually flags distribution gaps or management communication issues rather than widespread refusal.
- Reasoned declines: Reviewing reasons submitted with declines provides direct intelligence on operational friction or policy unworkability.
- Onboarding coverage: New starters joining after a campaign closes require automated onboarding enrolment or scheduled delta campaigns.
Running a campaign well
- Publish the policy first. Attesting to an unpublished policy attests to nothing.
- Define the audience precisely. "All staff" for a policy that binds forty people generates noise that trains everyone to click through without reading.
- Set a realistic deadline. Two weeks is usually enough; two days produces reflexive acknowledgement.
- Read the declines before closing the campaign.
- Close the campaign so the results are frozen and reportable.
- Plan for new starters — either a periodic follow-up campaign or an onboarding step.
Permissions
| Action | Permission |
|---|---|
| View policies and campaigns | policy.read |
| Create and manage campaigns | policy.write |
| Acknowledge or decline an attestation addressed to you | policy.attest |
Requires the policy_governance entitlement.
Example
Campaign: Information Security Policy v3.1, all staff with system access.
| Element | Value |
|---|---|
| Audience | 1,847 |
| Issued | 8 April |
| Deadline | 25 April |
| Closed | 30 April |
Results:
| Response | Count |
|---|---|
| Acknowledged | 1,791 |
| Declined | 9 |
| Outstanding at close | 47 |
The 47 outstanding were, on investigation, mostly long-term absence and one department whose distribution list was stale. The stale list was the more important finding — it also meant that department had missed two prior campaigns.
The 9 declines included three raising the same point: the policy required multi-factor authentication for a legacy application that does not support it. That was already known and covered by exception EXC-2026-0031 — but the policy text did not reference the exception, so the people bound by it had no way to reconcile the two.
Outcome: the policy was amended at its next revision to reference the exception register, the distribution list was corrected, and an onboarding attestation step was added.
The nine declines produced a better policy. The 1,791 acknowledgements produced a number.
Troubleshooting
"I cannot create a campaign." Requires policy.write. Attesting requires only policy.attest.
"A campaign cannot be deleted." Correct. Campaigns are governed records. Close it instead.
"Someone did not receive their attestation." Check the audience definition and notification configuration. Outstanding attestations also appear in the Workbench regardless of notification delivery.
"Attestation coverage is not affecting compliance status." It does not automatically. To have attestation coverage feed requirement assurance, record it as an evidence assertion against the relevant obligation.