Attestation types
ClearPolicy supports two types of attestation, which you set at the document level and can override per request:- Acknowledgment
- Signature
The recipient reads the document and clicks a button to confirm they have read and understood it. This is the simplest form of attestation — one click, no typing required. Use acknowledgments for policies and notices where a confirmed read is sufficient.
How requests are sent
When you send an attestation request, ClearPolicy:- Creates a request record linked to the specific document revision and the recipient.
- Stores the recipient’s name and email on the request at the time it is sent.
- Generates a unique, personal token for that recipient.
- Sends an email to the recipient containing a link that includes their token.
Open requests keep the name and email from when they were sent. If you later edit the person’s profile, pending requests still use the original recipient details. Request emails and reminders go to the address on the request, not the person’s current email.
The recipient experience
The recipient clicks the link in their email and lands on a public page that shows the document content. The page requires no login. From there, depending on the attestation type:- For an acknowledgment, they click to confirm they have read the document.
- For a signature, they type their name into a field and submit.
Recipients access their attestation page through a personal link only. If they lose the email, you can send them a reminder from within ClearPolicy.
What gets recorded
When a recipient completes a request online, ClearPolicy creates an attestation record that captures:- Timestamp — the exact date and time of completion.
- IP address — the network address of the device used.
- User agent — the browser and operating system information.
- Signature name — for signature-type attestations, the name the recipient typed.
- Document hash — a cryptographic fingerprint of the document content at the time of signing, used to verify the document has not been altered.
Request lifecycle
An attestation request moves through the following statuses:Sent
Sent
The email has been delivered to the recipient. They have not yet opened the attestation link.
Viewed
Viewed
The recipient has opened their personal link and viewed the document.
Attested
Attested
The recipient has completed the request. A permanent attestation record has been created.
Canceled
Canceled
The request was canceled before the recipient completed it. A request can be canceled manually by your team, or automatically by ClearPolicy when a newer revision supersedes the one the request was sent for.
Expired
Expired
The request passed its expiration date without being completed. Expired requests can no longer be completed by the recipient. You can configure requests to expire automatically in your organization settings.
Bounced
Bounced
The request email bounced and could not be delivered to the recipient’s inbox.
Delivery failed
Delivery failed
The request email could not be sent or was rejected by the recipient’s mail provider.
Complained
Complained
The recipient or their mail provider marked the request email as spam.
Superseded requests
When you publish a new revision of a document and send fresh requests, ClearPolicy automatically cancels any pending requests that were tied to an older revision of the same document for the same person. This keeps your request list clean and ensures recipients only receive the latest version. For example, if you sent a request for version 1 of a policy and then published version 2 and sent new requests, any still-pending version 1 requests are automatically canceled. The activity log for each canceled request shows “Superseded by a newer revision” so you can see exactly why it was closed.Only pending requests are affected. Requests that have already been completed, expired, or manually canceled are not changed.
Sending reminders
If a request is still pending, you can send the recipient a reminder email. The reminder delivers the same personal link to their inbox so they can complete the request without searching for the original email. You can also set up automatic reminders to follow up with recipients on a schedule. ClearPolicy does not send reminders while a request needs delivery follow-up. See when reminders are not sent for how to follow up after a bounce or delivery problem.Paper on file
Electronic completion is the default path: the person opens their link and finishes the request online. When someone cannot or will not complete online — for example wet ink is required, they prefer paper, or they cannot use the link for that step — a team member can still keep a complete record in ClearPolicy. Paper on file means a team member records that they obtained a wet-ink signature or paper acknowledgment on a pending request and uploads the signed paper copy (PDF or image). A file is always required.What happens
- An authorized team member opens a pending request.
- They choose Record Paper Signature.
- They upload the signed paper copy and confirm they obtained the wet-ink completion from that person.
- ClearPolicy marks the request complete for that document revision. Compliance status for that revision updates the same way as an electronic completion (typically Compliant when the request is on the latest published revision).
- Reminders stop for that request. Activity shows Paper Signature Recorded.
How paper differs from electronic completion
| Electronic | Paper on file | |
|---|---|---|
| Who completes | The person, online | A team member records after collecting paper |
| Evidence stored | Typed name (for signatures), timestamp, IP, browser, document hash | Uploaded signed paper copy, timestamp, team member who recorded it |
| Download label | Download Signed Document or Download Acknowledged Document | Download Uploaded File |
| Status note | Completed online | Paper on file |
| Certificate | Electronic attestation certificate included | No electronic certificate |