Why auditors ask about policy acknowledgement
Writing security policies is only half of the control. A SOC 2 auditor also wants to know that the people those policies apply to were told about them and agreed to follow them. Policy acknowledgement tracking is how you show that: a record, per person and per policy, that the employee read the policy and accepted it. You will also hear it called a policy attestation.
In the Trust Services Criteria this sits mostly in the control environment and communication criteria. CC1.1 covers the organization's commitment to integrity and ethical values, which in practice includes setting standards of conduct and checking that people follow them. CC2.2 covers communicating internal control information, including people's responsibilities, inside the organization. That is why the Acceptable Use Policy, the Code of Conduct and the Information Security Policy are the usual starting points for acknowledgement. Your auditor decides exactly how they test it, and your own control descriptions set what they test against.
Auditors typically look at two moments:
- Onboarding. New hires acknowledge the relevant policies within a set time of starting. The auditor may pick a sample of people who joined during the audit period and ask for each person's record.
- Changes and periodic re-acknowledgement. When a policy changes in a way that matters, existing staff acknowledge the new version. Some organizations also commit to a yearly re-acknowledgement, often alongside annual security awareness training.
Whatever you commit to in your policies and control descriptions is what you will be tested on. If your Human Resources Security Policy says new hires acknowledge policies within 30 days, the evidence needs to show 30 days.
What good employee policy acknowledgement evidence looks like
A useful test: could someone who wasn't there reconstruct, from the record alone, exactly what a given person agreed to and when? Good evidence answers four questions for every acknowledgement:
- Who. A stable identity, not a name typed into a box. If two people share a name, or someone's name changes, the record should still point at the right person.
- Which policy. Unambiguous, even if the policy is later renamed.
- Which exact version. This is the one most often missing. "Acknowledged the Acceptable Use Policy" is weaker than "acknowledged version 4 of the Acceptable Use Policy, the version approved on a given date".
- When. A timestamp you can compare with the person's start date and with the date the version was approved.
On top of the individual records, you want a completion view per policy: how many people were required to acknowledge this version, how many have, who is outstanding and who is overdue. That view is what you look at every week, and what an auditor scans before choosing a sample.
Finally, the records should be hard to alter quietly. An append-only log or a system that keeps history is easier to defend than a spreadsheet anyone can edit.
Common approaches and where they fall short
Most small teams start with whatever is at hand. Each option can work, but each has a predictable weak spot.
| Approach | What works | Typical weakness |
|---|---|---|
| E-signature tool | Strong identity and timestamps | The signed document is a copy, so it drifts from the live policy. Every update means a new envelope for everyone. |
| Spreadsheet | Free and flexible | Version is rarely recorded, anyone can edit a row, and new hires depend on someone remembering to add them. |
| Learning management system | Good for training completion | Policies end up duplicated outside your documentation, and versions in the course fall behind the source. |
| Online form | Fast to set up | Identity is self-reported, the form rarely links the exact version, and completion has to be worked out by hand. |
The same three problems come up again and again:
- The version isn't recorded. Six months later you can't say which text someone agreed to, especially if the policy was edited in between.
- New hires are missed. Onboarding acknowledgement depends on a person remembering to send the request. The audit sample finds the one person nobody asked.
- Chasing people eats time. Someone has to work out who is outstanding, message them, and do it again a week later.
When employees need to re-acknowledge a policy
Not every edit should send the whole company a new request. If people are asked to re-read a policy every time someone fixes a typo, they stop reading. A simple rule works for most teams:
- Material change: the change affects what people must do or must not do. A new password rule, a new requirement to report lost devices within a set time, a new restriction on personal devices. Ask everyone in the audience to acknowledge the new version.
- Minor change: typos, formatting, a renamed team, a corrected link, clearer wording with the same meaning. Approve the new version, but keep existing acknowledgements.
Decide which kind of change it is when the new version is approved, and record that decision with the approval. That gives the auditor a clear reason why some versions triggered a new round and others didn't. For how approvals and versions fit together, see policy approvals and version control auditors accept.
Periodic re-acknowledgement. Whether you also need a yearly re-acknowledgement of unchanged policies depends on what your own policies and control descriptions commit to. Write down the rule you actually follow (on hire, on material change, yearly, or a combination) and ask your auditor early if you are unsure what they expect.
Audiences: all employees or specific groups
Some policies apply to everyone: acceptable use, the code of conduct, the information security policy. Others only matter to a group. A secure software development policy is for engineers, and asking the sales team to attest to it adds noise without adding assurance.
Defining an audience per policy keeps requests relevant and makes completion figures meaningful. It also creates a moving target: people join groups, change teams and leave. Your tracking needs to notice when someone moves into a group and ask them, and stop counting someone who has left, without deleting what they already acknowledged.
It is also normal for some policies not to need acknowledgement at all. A risk management policy or a vendor management policy is still approved and reviewed, but it is written for the people who run those processes. For a full list of what a SOC 2 program usually includes, see which policies you need for SOC 2.
Chasing, reminders and due dates
Give every acknowledgement request a due date, so "outstanding" and "overdue" mean something. A window of a few weeks is common. Then make reminders systematic rather than personal:
- Remind when the request is first made, again shortly before the due date, then periodically while overdue.
- Cap how often one person is reminded, so a backlog doesn't turn into a flood of messages.
- Review completion on a fixed schedule (weekly works well) and escalate only the stubborn cases.
- Have a recorded way to excuse someone who genuinely can't acknowledge, such as a person on long-term leave, with a reason.
When the audit arrives, you want a report rather than a scramble. Keeping the acknowledgement report alongside the rest of your evidence is covered in SOC 2 evidence collection.
Policy acknowledgement tracking in Confluence
If your policies already live in Confluence, Compliance in a Box tracks acknowledgements on the policy pages themselves, with no copies and no separate system. Here is how it handles each of the points above. The policy acknowledgements chapter of the user guide has the full detail.
Click-through on the exact approved version
Employees see what they owe in My Tasks and under the title of the policy page itself (Please acknowledge). They open the approved version, select I have read and understand this policy and click Acknowledge. The app records the person's Atlassian account ID, the time, the policy version, the Confluence page version and a hash of the content, so each acknowledgement is tied to the text the person read. If the page has edits that aren't approved yet, people are pointed to the approved version instead.
Campaigns, material and minor changes
An acknowledgement campaign opens when a policy that requires acknowledgement is first approved, and again whenever a later version is approved as a material change. The policy owner chooses this when submitting the version, with a Material change checkbox. A minor change opens no campaign and existing acknowledgements still count. Everyone in the campaign has 30 days.
Audiences, new hires and leavers
Each policy's audience is All employees (the default) or Specific groups that you pick from your Confluence groups. Once a day the app compares each open campaign with the current audience: new hires and people who move into a group are asked, due 30 days from that day, and people who left before acknowledging show as Left the audience. Acknowledgements already given are never removed. Compliance Admins can Excuse someone with a reason, which goes into the audit log.
Reminders and completion tracking
Reminders arrive as Confluence tasks on each person's private compliance tasks page, so Confluence notifies them: when they are first asked, 3 days before the due date, then once a week after the due date (up to 4 times). Admins can also send a reminder by hand to one person or everyone outstanding. The Acknowledgements tab shows progress by policy and by employee, and policy owners see the percentage for their own policies. For the auditor, the app generates a Policy Acknowledgement Report as Confluence pages, refreshed daily. See Dashboard, tasks and reminders and Evidence, reports and audits.
The SOC 2 policy set it provisions already marks which policies need acknowledgement (the SOC 2 content reference lists them). The app asks again on material changes and for new audience members.
Frequently asked questions
Is a click-through acknowledgement enough for SOC 2?
In most cases, yes. SOC 2 doesn't require a signature. What matters is that the record reliably identifies the person, the policy version and the time. Your auditor decides what evidence they accept, so confirm early if you are unsure.
How quickly should new hires acknowledge policies?
There is no fixed SOC 2 deadline. Pick a window you can meet, commonly somewhere in the first few weeks, write it into your policies, and make sure your records show you meet it.
Do contractors need to acknowledge policies?
If contractors have access to your systems or data, they are usually in scope for the same policies. Decide who is in the audience, write it down, and treat it consistently.
What if someone never acknowledges?
Remind them, escalate to their manager, and keep the record of the reminders. A small number of overdue acknowledgements with a documented follow-up is easier to explain than a list nobody has looked at.