How to automate policy distribution when onboarding new employees
Originally published:
Last updated:
Automating policy distribution at onboarding means one specific thing: the event that creates a new employee in your systems is also the event that sends them their policies. Not a checklist item, not a reminder in someone's calendar, and not a welcome email that a manager writes by hand.
Almost every organization already has the two halves of this. IT creates the account, the mailbox, and the group memberships on or before day one. Somewhere else, a set of policies exists that the new hire is expected to read. What is usually missing is the wire between them, and that gap is why onboarding is the most common place for acknowledgement records to be incomplete. The reasons that matters in an audit are covered in Onboarding and policy acknowledgement: where most compliance gaps begin. This article is about the mechanics of closing it.
What actually has to be automated
Most attempts at automation solve the sending and leave the other three parts manual, which is why they still produce gaps. A process that survives a new joiner arriving in a busy week has to handle four things without human intervention:
| What | The question it answers | Manual failure mode |
|---|---|---|
| The trigger | What starts the distribution? | Someone has to remember, during the busiest week of the hire |
| The targeting | Which policies does this person need? | Everyone gets everything, or the wrong set for the role |
| The version | Which version were they given? | A PDF attachment with no version, or a link that changed later |
| The record | Can you show it a year from now? | A sent-items folder and a checklist that says "done" |
Note that three of the four have nothing to do with sending. Automating only the email produces a faster version of the same missing record.
Wire it to the directory, not to a checklist
The most reliable trigger is the one that already happens for every single hire without exception: the creation of their user account. In a Microsoft 365 organization that is the company directory, Microsoft Entra ID, previously called Azure AD. If you have an IT team, this is the system they use to give a new employee their login, their mailbox, and their access on day one. Nobody starts work without it, which is exactly the property you want in a trigger.
With directory sync enabled, the setup is three steps, and only the first two involve any work.
1. Import your groups from the directory
You do not build a second group structure by hand. The groups come in from the directory as they are, which for most organizations means the ones already used for licence assignment, shared mailboxes, Teams membership, and file permissions: all employees, engineering, finance, field staff, the Oslo office. Membership stays in step with the directory afterwards, so the group in Policy Confirm is the group your IT team maintains rather than a copy of it.
This is the part that decides whether the rest works. If a group called Finance already decides who reaches the finance folder, it can decide who reads the finance policies, and no one has to answer that question again per hire.
2. Attach each policy to the groups it applies to
Upload each policy, give it a version and an effective date, and attach it to the imported groups it applies to. This is the only part that requires judgment, and it is a one-time exercise, not a per-hire one.
| Group imported from your directory | Policies attached |
|---|---|
| All employees | Information security, acceptable use, code of conduct |
| Engineering | Secure development, change management |
| Finance | Anti-fraud, payment approval, expenses |
| Field staff | Driving, lone working, equipment handling |
The rule worth stating plainly is that policies are attached to groups, never to individuals. A policy assigned to twelve named people is a list that goes stale the first time someone joins or changes role. A policy attached to an imported group stays correct as the group changes underneath it, and the group changes in the directory.
3. Nothing, which is the point
When IT creates the new employee and places them in their department group, they appear as a recipient in Policy Confirm with the policies for that group already assigned. If a confirmation cycle is running for those policies, the new hire is included in it and notified straight away. If none is running, they are counted as awaiting distribution and picked up by the next catch-up cycle, which can be created automatically on a weekday you choose.
From the new employee's side, the whole mechanism is invisible. They get one email that lists the policies they need to read, they open each one, and they confirm. No account to create, no password to choose, and no software to learn on their first day. They can confirm through a magic link or with their work account through Microsoft single sign-on, which also ties the confirmation to a verified identity rather than to whoever had access to the mailbox.
The cases that break onboarding automation
A trigger and an imported group cover the ordinary hire. The cases below are the ones that quietly produce the missing record, and they are worth checking explicitly against whatever process you end up with, ours or anyone else's.
- Joining mid-cycle. Someone hired in week two of a rollout has to join the cycle already in progress, on the same version as everyone else. If your process captures recipients at the moment of sending, that person is invisible until the next round. Group membership has to stay live for the duration of the cycle.
- Joining between cycles. The more common case, and the easier one to miss, because nothing looks wrong: policies are assigned, no cycle has reached them, and they are not a non-responder either. This is what catch-up cycles are for.
- Belonging to no group. A recipient in no group receives nothing and never shows up as overdue, since nothing was ever sent. The same is true of a group with no policies attached. Both are structural gaps rather than people problems, and they need to be flagged before a cycle runs.
- Changing role or department. An internal move is a small onboarding. If the directory group changes, the policy set should change with it, which is the second reason to target groups rather than individuals.
- Leaving. A leaver should stop receiving requests, without their historical acknowledgements disappearing. The record of what a former employee confirmed, and when, is precisely the record you need if a dispute arrives after they have gone.
- Contractors and consultants. People who do the work but often have no directory account, or one created outside the normal process. They still need the acceptable use and security policies, which usually means adding them as recipients directly. Covered in Vendor policy acknowledgement.
What the automation has to leave behind
The output of an automated onboarding flow is not a sent email. It is a record, per person and per version, that can be produced on request months later. To be worth anything in an audit or a dispute it needs to be version-specific, attributable to an identifiable individual, timestamped at the moment of confirmation, and retrievable without reconstructing anything from mailboxes. The detail behind each of those properties is in How to prove policy acknowledgement during an audit.
The version point deserves emphasis in an onboarding context specifically. A hire who joined in March acknowledged the March version. When the policy is updated in September, that March acknowledgement is still valid evidence for the period it covers, and the new version starts a new round. A process that overwrites the old state loses the ability to answer the only question an auditor asks about a specific person: which version did this individual confirm, and when.
If you do not have directory sync
Directory sync removes the last manual step, but most of the benefit comes from the structure rather than from the integration. Without it, recipients are imported in bulk from CSV or Excel and grouped the same way, and adding a new hire is a single entry rather than a distribution exercise. Because the policies hang off the group, everything after that entry is still automatic: assignment, inclusion in the active cycle, reminders, and the record.
That is the practical difference between the two. With the integration, the trigger is account creation. Without it, the trigger is one person added to a group. In both cases nobody is deciding which policies apply, chasing confirmations by hand, or maintaining a spreadsheet whose accuracy depends on the person who built it, which is the failure mode described in Why Excel is not an audit trail.
A setup sequence
- List the policies a new hire in each department actually has to read on day one. It is usually three to six, not the whole library.
- Give every one of them a version number and an effective date, so an acknowledgement has something specific to point at.
- Create groups that mirror the groups your directory already maintains, rather than inventing a second structure that has to be kept in step by hand.
- Attach each policy to its groups, and check that no group is left with nothing attached and no recipient is left in no group.
- Import the groups, and confirm the result with one real new hire before trusting it for the next twenty.
- Turn on automatic catch-up cycles for the weeks when no rollout is running, and reminders for the people who open the email and forget.
- Set the recurring cycle for annual re-acknowledgement, so onboarding coverage does not decay into a one-time event that nobody repeats.
What automation does not fix
Three things stay your responsibility, and no amount of wiring changes them. An out-of-date policy distributed automatically is an out-of-date policy delivered faster. A group structure that does not reflect how people actually work will target the wrong set of documents with great reliability. And a confirmation is evidence of receipt and acceptance, not of understanding: where comprehension genuinely matters, questions have to be added deliberately, which is the subject of Acknowledgement vs comprehension: when to add a quiz to a policy.
What automation does fix is the failure that no amount of diligence solves: a person joining in a week when everyone was busy. That is the gap worth engineering away, because it is the one that recurs.
Frequently asked questions
Can policy acknowledgement be automated as part of onboarding?
Yes. The reliable way is to make account creation the trigger. Groups are imported from the company directory, policies are attached to those groups rather than to individuals, and a new employee who lands in one of them is added as a recipient and notified automatically. No onboarding checklist item is involved, so nothing depends on somebody remembering.
How does automatic policy distribution work with Microsoft Entra ID?
Groups are imported into Policy Confirm from your directory, which for most Microsoft 365 organizations is Microsoft Entra ID, formerly Azure AD, and membership stays in step with it. Directory group membership therefore decides who receives which policies. When IT creates the new employee and places them in the department, location, or role group they belong to, the policies attached to that group are sent to them.
What happens if a new employee joins in the middle of a confirmation cycle?
They are included in the cycle that is already running and notified when they are added, because group membership stays live for the duration of a cycle. They receive the same policy version as everyone else in that cycle, so the record is comparable across the group rather than being a separate one-off send.
What happens to someone who joins between cycles?
They are counted as awaiting distribution: policies are assigned to them, but no cycle has reached them yet. A catch-up cycle covers exactly those people, and it can be created automatically on a weekday you choose, so a joiner who arrives in a quiet week is picked up without anyone noticing them first.
Do you need an HR system to automate policy distribution to new hires?
No. The directory is usually the better trigger. An HR record often exists weeks before the start date and does not always reflect the department someone actually works in, while the account and mailbox are created because work is about to begin, which is the moment the policy obligation starts. The trade-offs of running acknowledgements inside an HR platform are set out in Policy Confirm vs HRIS acknowledgement modules.
How soon after the start date should a new hire acknowledge policies?
Before, or shortly after, they begin work that the policies govern. Most frameworks phrase the requirement as awareness from the point work begins rather than as a fixed number of days, which in practice means the request should be waiting on day one and reminders should run until it is confirmed.
Get started. Free up to 10 recipients.
Import your groups from the directory, attach your policies once, and every new hire receives the right policies without anyone sending anything.
Get startedAbout the author
The team behind Policy Confirm has hands-on experience across full-stack development, product growth, compliance leadership, and executive technology roles such as CTO and CPTO. They have led and supported ISO 27001 implementations, policy governance initiatives, and audit-driven compliance projects in regulated environments. This background informs a practical, audit-oriented approach to policy management and policy acknowledgements.
Related content
- Onboarding and policy acknowledgement: where most compliance gaps begin
- Essential IT policies: the documents to have, and how to prove they were read
- July 2026 release: Recurring cycles, supervisors, and full coverage
- Employee handbook acknowledgment form: Why a signature is mandatory
- Email template: How to ask employees to read and sign new policies
Legal disclaimer
The information provided in this article does not, and is not intended to, constitute legal advice; instead, all information, content, and materials available on this site are for general informational purposes only. You should contact your attorney to obtain advice with respect to any particular legal matter.