SharePoint is where most organizations keep their policies, and it is good at that. What it does not do is ask the right people to read a policy, follow up until they have, and show afterwards who confirmed which version. Policy Confirm adds that on top, and the documents can stay exactly where they are.
Keep the policies in SharePoint. Add who has to confirm them, the follow-up, and the proof.
A policy in Policy Confirm is a name, a version, the people it applies to, and a pointer to the document. The pointer can be any of three things, and you can mix them across your policies.
Point the policy at the page or file where it already lives. Recipients open it there, and the confirmation is recorded here.
For the policies that are files rather than pages, upload the version and Policy Confirm serves it on the confirmation page.
For a document Policy Confirm cannot open, write where it is kept. Recipients see that note instead of a View button.
The left column is a SharePoint library on its own. The right column is the same library with Policy Confirm linking to it.
| What | SharePoint alone | With Policy Confirm |
|---|---|---|
| Where the document lives | SharePoint | Still SharePoint. The policy links to the page, or you upload a PDF, or you note where it is kept |
| Who has to read it | Whoever has access to the library, which is often everyone or no one | The groups and people you choose per policy: a department, a site, a role, one person |
| Asking people to read it | An email you write and send yourself | A cycle: each person gets their own email and link, and a message in Teams or Slack if you want one |
| What counts as done | The access log shows a file was opened | The person confirms the policy, after a one-time code or Microsoft sign-in, and a quiz or signature if you require it |
| Versions | The library keeps versions of the file | Each confirmation is recorded against the version that was current, so a new version asks again |
| Deadlines and reminders | Yours to track and chase | A deadline per person, reminders before it, and Overdue after it, with no chasing by hand |
| People who join later | Someone has to remember to send the email again | Added to a running cycle automatically, with their own deadline |
| The proof | Access logs and a spreadsheet you keep next to them | Who confirmed which version, when, and how, as a PDF or CSV per person, per group or for the whole organization |
The access log says an account opened a file. It does not say the person read it, agreed to it, or which version was on the screen. When a customer or an auditor asks for evidence, that is the gap they find first.
SharePoint keeps versions of the file. It does not keep, per version, the list of people who confirmed it. When the file is updated, nothing asks the people who confirmed the old one to confirm the new one.
A library does not know who is late. Reminders, deadlines, the person who joined three weeks in, and the overdue list are all someone's manual job, and they are the first things to slip.
If all you need is for policies to be available, SharePoint does that well, and it is already part of Microsoft 365. The need for something more arrives with the first question you cannot answer from the library: who has confirmed the current version of this policy, and who has not? That question comes from an auditor, a customer doing due diligence, or your own management, and it is the one Policy Confirm is built to answer.
Drafting, review and storage stay in SharePoint. Policy Confirm takes over at the point where a version is final: who it applies to, asking them, following up, and the record. The organization keeps its intranet, its folders and its habits. What changes is that the question "who has confirmed this?" now has an answer.
Microsoft sign-in and Entra ID group sync are there for organizations that want them, so the people and groups in Policy Confirm can be the ones you already maintain. Teams can carry the cycle notice. None of it is required to start.
Do I have to move my policies out of SharePoint to use Policy Confirm?
No. A policy in Policy Confirm can be a link to the SharePoint page or file where the document already lives. Recipients read it there, and the confirmation is recorded in Policy Confirm against the version that was current.
Can SharePoint track policy acknowledgement on its own?
With Power Automate flows, a form and a list, you can collect confirmations. Tying each confirmation to a document version, giving each person a deadline, reminding and reporting overdue, and producing a per-person record for an auditor all have to be built and kept working by someone. Policy Confirm has those as standard.
Does SharePoint's access log count as proof of acknowledgement?
It shows that a file was opened by an account. It does not show that the person read it, that they agreed, or which version they saw. Auditors and customers asking for evidence usually want a confirmation by a named person against a named version, with a time.
What happens when the policy changes in SharePoint?
You create a new version of the policy in Policy Confirm, pointing at the same page or at the new file, and send a cycle. Everyone who should confirm the new version is asked again, and the old confirmations stay on record against the old version.
Free for up to 10 recipients. Point a policy at the page where it already lives, choose who it applies to, and send a cycle.