Nearly every organization that asks us about policy acknowledgement already has a process. It’s a Microsoft Forms survey with a checkbox, or an email that says “reply to confirm you’ve read the attached,” and somewhere there’s a spreadsheet or an Outlook folder where the confirmations land. It records that a person acknowledged a policy once. It does not record which revision they acknowledged, because the form or the email had no way to know.
Then the policy gets rewritten. The handbook changes in 2025, nobody is asked to re-acknowledge, and when the auditor asks for proof that staff have read the current version, the organization produces evidence that they read the 2023 one. The process worked exactly as designed. The design was missing one column.
This post is about building policy acknowledgement in SharePoint so that the record ties a person to a specific revision of a specific policy, re-acknowledgement fires automatically when the policy changes, and the report an auditor asks for is a filtered view rather than a weekend of spreadsheet work. It assumes the policies themselves already live in a SharePoint library with content approval and versioning, which our guide to managing policies and procedures in SharePoint sets up. If they don’t yet, start there, because acknowledgement without a controlled source is a record of people reading an unmanaged document.
What a Policy Acknowledgement Record Has to Capture
A defensible acknowledgement record captures five things: who acknowledged, which policy, which revision of that policy, when, and by what method. Miss any one and the record is weaker than it looks. Miss the revision and the record is useless the first time the policy changes, which is the failure the Forms survey has built in. Everything else in this post follows from getting those five fields into one list.
The sixth thing isn’t a field, it’s a trigger. When a policy is revised in a way that matters, the system has to know that the previous acknowledgements no longer count and new ones are required. A record that captures revision but never asks for a fresh signature on a new revision is only half the fix. The design below handles both.
Why Forms Surveys and Email Replies Fail an Audit
A Forms survey or an email reply records intent, not evidence, and it records it against a policy name rather than a policy version. The auditor’s question is “can you show me that everyone who should have read the current version of the information security policy has done so.” The Forms response export shows names and a date. It does not show which version was current on that date, it does not know the policy has since changed, and it has no way to re-ask. The email folder is worse: it proves someone replied, and the attachment they replied to is whatever was attached that day.
There’s a second failure that shows up later. Forms are owned by the person who created them, so when that person leaves, the responses and the form go with their account unless someone transferred ownership. We’ve seen an organization lose three years of acknowledgements this way. A SharePoint list has no such owner; it belongs to the site.
Four Ways to Track Policy Acknowledgement in SharePoint
Four approaches cover nearly every case, and they range from a patched-up version of what most organizations already have to a signed document with legal weight. The right one depends on how many policies you have, how often they change and how hard your auditor pushes on the word “signed.”
Forms plus a flow writing to a list
The cheapest repair of the existing process keeps the Forms survey but adds a Power Automate flow that writes each response into a SharePoint list, stamping it with the policy and the revision that was current at the time. It works for a small policy set that rarely changes, and it buys time. It still carries the ownership problem and the form still can’t present the revision to the reader, so it’s a bridge rather than a destination.
List-based attestation
A SharePoint list records one row per person per policy revision, created by a flow when a new revision is approved and completed when the employee clicks an acknowledgement button on the policy page. This is the model we recommend for most mid-sized organizations because every one of the five fields is a column, the re-acknowledgement trigger is the same flow that creates the rows, and reporting is a list view. The next section walks through the build.
Power Automate approvals
The Approvals action in Power Automate sends each employee an approval request for the policy, and their response is recorded in the Approvals system with a timestamp. It suits small audiences, such as a leadership team acknowledging a conflict-of-interest policy, where the formality of an approval card is useful. It scales poorly past a few hundred people, the Approvals history isn’t a list you can report on without more flow work, and it inherits every ownership rule that applies to approval flows generally.
SharePoint eSignature
SharePoint eSignature, part of SharePoint Premium, collects a legally recognized electronic signature on the policy document itself and stores the signed copy with an audit trail. It’s the right tool when the policy is a contract-like document (a code of conduct, an acceptable-use agreement) where “signed” has to mean signed, or when a regulator or counsel asks for it. It is billed pay-as-you-go through an Azure subscription where available, and it is heavier than most routine policy acknowledgement needs. Use it for the handful of policies that need it, not all of them.
The List-Based Attestation Model We Recommend
The build has two lists and one flow. The Policies library already exists: it holds the controlled documents with content approval, major and minor versioning, and at minimum a Policy ID, Owner, Effective Date, Review Date and Audience column. Add one more column, a yes/no called Requires Re-acknowledgement, which the approver sets when they publish a revision. That single column is what separates a typo fix from a change that everyone has to read again.
The second list is Acknowledgements. Its columns are Employee (person), Policy (lookup to the Policies library), Revision (text, copied from the policy’s major version number at the time the row is created), Status (choice: Pending, Acknowledged, Overdue), Due Date, Acknowledged On (date and time, set by the flow when the button is clicked) and Method (choice: Button, eSignature, Manual). Every one of the five required fields is here, and the lookup to the policy means the record survives a policy title change.
The flow triggers when a policy’s content approval status changes to Approved on a major version. It reads the Audience column, resolves it to a list of people (a Microsoft 365 group or an Entra security group works best), and creates one Pending row per person with the current revision number and a due date, typically fourteen or thirty days out. A second scheduled flow runs daily, sends a reminder for Pending rows approaching the due date, flips rows past due to Overdue, and sends the manager a digest of their team’s overdue items. On the policy page itself, a button (a simple Power Apps form or a formatted list button) sets the employee’s row to Acknowledged and stamps Acknowledged On. The employee never touches the list directly.
The whole thing is buildable in a few days by someone comfortable with Power Automate, and it uses nothing beyond the licenses most Microsoft 365 organizations already hold. Our Power Automate best practices cover the error handling and run-history hygiene that keep it reliable.
Re-Acknowledgement on Revision: The Step Everyone Skips
Re-acknowledgement works because the flow only fires on approved major versions where Requires Re-acknowledgement is set to Yes. The approver makes that call at publication: a corrected date or a reformatted heading is a minor version and nobody hears about it; a changed rule is a major version flagged for re-acknowledgement, and every person in the audience gets a new Pending row for the new revision number. Their old Acknowledged row for the prior revision stays in the list as history.
This is the design decision that most acknowledgement processes, including most third-party tools’ default configurations, get wrong in one of two directions. Either every change triggers a re-sign, and employees learn to click through without reading, or no change does, and the record goes stale. Putting the decision on the approver, as a required field at publish time, makes it deliberate. Write the criteria into the policy management procedure so approvers apply them consistently: changes to what employees must or must not do require re-acknowledgement; changes to formatting, contacts or references do not.
Reporting: Proving It to an Auditor
The report an auditor wants is a filtered view of the Acknowledgements list, and with the schema above it takes under a minute to produce. Filter by Policy and the current Revision, group by Status, and you have the acknowledgement rate for the current version with the names of everyone still Pending or Overdue. Filter by Employee and you have a person’s full acknowledgement history across every policy and revision. Export either to Excel if the auditor wants a file.
For ongoing oversight rather than audit response, a Power BI report over the list gives compliance a dashboard: acknowledgement rate by policy, overdue count by department, time-to-acknowledge trend. That’s the view the third-party tools sell, and it’s about a day of Power BI work once the list exists. The point is that the data model does the work; the report is a view of it, not a separate project.
Ownership: Why the Flow Can’t Belong to One Person
The flows in this design must run under a service account or a solution-aware connection, not the account of whoever built them. We covered the reasoning in our document approval workflow post and won’t repeat it here, except to say that acknowledgement is the worst place for a flow to die silently. An approval flow that breaks gets noticed when a document doesn’t publish. An acknowledgement flow that breaks gets noticed at the audit, when the list shows that nobody has acknowledged anything since the builder left.
Put the flow ownership rule, the service account name and the Requires Re-acknowledgement criteria into the policy management procedure itself. Then the design is documented in a controlled document, which is what an auditor will ask to see next.
When to Buy an Acknowledgement Add-On Instead
Buy a product when the audience is large and spread across people without Microsoft 365 licenses, when comprehension quizzes are required, or when compliance needs the reporting dashboard on day one and nobody is available to build it. DocRead does acknowledgement and quizzes as a SharePoint add-on and leaves your library as the source of truth; ConvergePoint adds acknowledgement as part of a broader policy workflow suite that also runs inside SharePoint Online. Both solve the revision problem by design, because both track against the document version.
Below those thresholds, the list-based model costs a few days of build and nothing in licenses, and it keeps acknowledgement data in a list your organization owns rather than a vendor’s schema. Our comparison of native and third-party policy management software covers the broader buy-versus-build decision; this post is the build.
Frequently Asked Questions
Can SharePoint track policy acknowledgement without a third-party tool?
Yes. A SharePoint list recording one row per employee per policy revision, created by a Power Automate flow when a revision is approved and completed when the employee clicks an acknowledgement button, captures who, what, which revision, when and how. Reporting is a filtered list view or a Power BI report over the list.
How do you handle re-acknowledgement when a policy changes?
Add a Requires Re-acknowledgement yes/no column to the policy library, set by the approver at publication. The acknowledgement flow fires only on approved major versions where it’s Yes, creating new Pending rows for the new revision while the previous acknowledgements stay as history. Document the criteria so approvers apply them consistently.
Is a Microsoft Forms survey enough for policy acknowledgement?
Rarely. Forms records a name and a date against a policy title, not a revision, so it can’t prove which version was acknowledged or re-ask when the policy changes. Forms are also owned by the person who created them and can be lost when that person leaves. It’s a bridge while you build a list-based model, not a destination.
When is SharePoint eSignature the right choice for policy acknowledgement?
When the policy is contract-like and counsel or a regulator requires a legally recognized signature on the document itself, such as a code of conduct or an acceptable-use agreement. It’s part of SharePoint Premium and billed pay-as-you-go, so use it for the few policies that need it and the list-based model for the rest.
If your acknowledgement process is a Forms survey and you’d like to know what it would take to make it audit-proof, our forms and workflow readiness assessment scopes the build. Or tell us what you’re tracking today and we’ll tell you whether it’s a few days of Power Automate or a product.
Reviewed By
