Category
Author
DATE
Executive summary: Distributing company policies is relatively straightforward. Ensuring that the correct employees receive the appropriate versions, complete the required interactions and leave a reliable record is where operational complexity emerges.
Artificial intelligence (AI) is changing both sides of this process. It can accelerate the development of custom tracking workflows and potentially allow employees to search extensive policy registers using ordinary questions rather than document names. Behind these capabilities, however, sit important dependencies involving employee identity, HR and IT data, version control, access permissions, exception handling and record retention.
This guide examines the practical requirements organisations should evaluate before building a custom policy tracking system, extending existing tools such as Microsoft 365 or purchasing a dedicated policy distribution and tracking platform.
Most organisations already have a way of making policies available. What differs is how they manage distribution, employee responses and evidence.
There are three familiar approaches:
Each approach can work. A small organisation with 30 employees and ten relatively stable policies may have no difficulty managing its records manually. An organisation with 5,000 employees, multiple subsidiaries and several hundred policies faces a rather different administrative problem.
Digitising files doesn’t automatically digitise the process. Moving signed forms from a filing cabinet into a shared folder may improve storage and retrieval, but somebody may still be responsible for distributing documents, checking employee lists, collecting responses, updating spreadsheets and following up on outstanding employees.
Existing systems can often automate more of this than organisations realise. SharePoint, for example, can be combined with Microsoft 365 workflow tools to support policy distribution and acknowledgement processes. But those workflows must be configured, maintained and operated.
Before investing in new software, establish which activities you want to automate, which records you actually need and which responsibilities your team will retain.
Automated policy distribution depends on accurate employee information. Assigning a universal Code of Conduct may require the full employee population, while procurement policies, site-specific safety procedures, and specialist declarations require more detailed organisational attributes.
These might include department, job title, branch, site, manager, executive reporting line, division or cost centre.
At Compliance Online, we’ve noticed a recurring pattern in our work with larger organisations: the bigger the organisation, the more likely we are to encounter employee data problems. One particularly common issue is conflicting information from HR and IT.
It’s understandable. Human Resources and Information Technology maintain employee information for different operational purposes.
HR information systems typically focus on employment records, payroll, organisational reporting lines, departments and job titles.
IT identity systems, such as Active Directory or Microsoft Entra ID, typically focus on user identities, account status, authentication, access permissions and security groups.
In larger organisations, these functions often operate in separate departments with different systems, identifiers and update schedules.
An employee may have moved from Logistics to Operations in the HR system while retaining their previous IT group membership. A departed employee may have been removed from payroll but retain an active account. A contractor may exist in IT’s directory without appearing in the permanent employee population.
Neither department has necessarily made a mistake. Each may be maintaining information correctly for its own purposes. But if policy assignments depend on the records agreeing, these differences become an operational problem.
| Data discrepancy | Typical cause | Operational and evidence impact | What to establish |
|---|---|---|---|
| Conflicting departments or job titles | HR updates a role or reporting line before IT updates the corresponding identity attributes or groups. | Employees may receive the wrong policies or miss documents relevant to their current responsibilities. | Which system is authoritative for each assignment attribute, and how changes will be synchronised. |
| Active accounts belonging to leavers | Employment status changes and account deactivation are not synchronised. | Former employees may appear as outstanding, while historical access may remain active unnecessarily. | Reliable deactivation processes that preserve legitimate historical evidence. |
| Duplicate employee identities | Name changes, inconsistent identifiers or repeated imports create separate profiles. | Acknowledgement histories may be fragmented, and completion counts may be misleading. | Stable identifiers, identity matching and a process for resolving duplicate records. |
| Contractors or temporary workers | External workers exist in IT systems but not in the permanent HR employee register. | Relevant people may be omitted from mandatory policy distribution. | Which non-permanent populations are in scope and how their records will be maintained. |
| Employees without work email addresses | Frontline or site-based roles do not require corporate accounts. | Employees may be unable to receive notifications or access standard sign-in processes. | Suitable alternative identification, authentication and access methods. |
Integrations can reduce the work involved in keeping employee records current, while AI-assisted data processing may help identify duplicates, inconsistent fields and possible identity matches.
But automation cannot settle every disagreement about which source is correct. The organisation needs rules for data authority, reconciliation and exception handling.
One assumption worth testing during procurement is whether a claimed HR or identity integration actually supports the attributes and updates your assignments depend on. Automatically creating a user account is not necessarily the same as maintaining an accurate organisational profile.
Automating assignments based on flawed employee data simply distributes incorrect policies more efficiently.
A major opportunity in policy management is shifting from simply storing documents to helping employees find information inside them.
Traditionally, an employee looking for guidance might need to locate the policy register, identify the relevant document, open a lengthy PDF and search for a term that may not even appear in the policy.
Consider an employee who wants to know whether they can accept a R750 gift from a supplier.
The answer could be in the Gifts and Hospitality Policy, the Anti-Bribery and Corruption Policy, the Code of Conduct or a combination of documents. The employee may not know where to begin.
AI-assisted search, including retrieval-augmented generation (RAG), can make this considerably easier. Instead of searching by document title, an employee asks a question in ordinary language.
Employee question: “Can I accept a R750 gift from a supplier?”
Desired system response: Retrieve the relevant provisions from the organisation’s approved policies, explain what they say, identify any required approval process and provide references to the exact source documents and sections.
Unlike an invented example of a company’s gift threshold, the system’s answer must come from the policies that apply to that employee.
This approach can also help with questions such as whether employees may have outside business interests, where to report a conflict of interest, or what approval is needed before sharing particular information.
For organisations with extensive policy registers, the improvement could be substantial. Employees would no longer need to know which document contains the answer before they can ask the question.
The usefulness of AI-assisted policy search depends on how reliably the system retrieves, interprets and presents the underlying material.
RAG can reduce unsupported answers by drawing on selected organisational documents, but it does not eliminate interpretation errors or guarantee that the source material is complete or legally sufficient.
AI-powered policy search is therefore a capability worth evaluating when buying or building a system, rather than a feature that should automatically be assumed to exist in every platform.
A well-maintained policy library with strong conventional search may also be sufficient for some organisations.
Uploading a new policy is relatively straightforward. Managing its history becomes more complicated when employees have already received, acknowledged or been assessed against earlier versions.
Imagine the policy owner approves version three of the Code of Conduct. The organisation now needs to decide who must receive the new version, whether fresh acknowledgements are required and what happens to the assessment questions and responses associated with version two.
The system needs to support three important processes:
An employee who acknowledged version two in March and version three in September has completed two distinct events.
If an investigation concerns something that happened in June, the organisation may need to establish which version was applicable at the time and which version the employee had acknowledged.
Replacing the old PDF without preserving the relevant record makes that exercise difficult. So does keeping multiple unsigned, undated or unapproved copies in folders called Code_of_Conduct_FINAL_v3_Updated_FINAL.pdf.
Good version management also depends on the policy register itself. Document owners, approval dates, review dates, status, categories and archived versions need to be maintained so the correct policies are made available to the correct people.
The technical capability is useful only when the organisation has a dependable process for approving and publishing changes.
Not every corporate document requires the same level of employee engagement. Treating every policy as a mandatory acknowledgement can create unnecessary administration and encourage employees to respond mechanically.
The interaction should follow the policy’s purpose, the intended audience and the evidence the organisation needs.
| Interaction type | System action | What the record establishes | Possible use |
|---|---|---|---|
| Access or read-only | Make a document available and, where supported, record an opening event. | Availability or a defined access event, not proof that the document was read or understood. | General guidance, procedures and reference information. |
| Formal acknowledgement | Present an identified document and acknowledgement statement for a recorded response. | The employee made the recorded acknowledgement; not necessarily that they understood the policy or will follow it. | Code of Conduct, information security or anti-harassment policies. |
| Comprehension assessment | Present questions with a defined result or pass mark. | Performance on the particular questions asked at that time. | Checking recognition of important rules or expected actions. |
| Declaration or survey | Collect specified information or statements from employees. | What the employee submitted, not whether the disclosure is complete or acceptable. | Gifts, conflicts of interest and outside business activities. |
There is a design decision behind each of these interactions. Someone needs to decide what the employee should be asked, whether the questions are appropriate and what follow-up is required.
AI can help draft acknowledgement statements, generate assessment questions or identify questions frequently answered incorrectly. But those outputs still need to be evaluated against the actual policy and the awareness objective.
Repeated incorrect answers may indicate employee misunderstanding. They may also indicate a poorly worded question or a policy that is difficult to interpret. Those are different problems, requiring different responses.
Suppose a policy is assigned to 1,000 employees, with 230 still outstanding after 14 days.
Automated reminders can help, but the outstanding list may contain two very different categories of employee:
| Employees who received the assignment but haven’t responded | Employees affected by delivery, access or data problems |
|---|---|
| Employees who haven’t completed the required action, despite having practical access to it. | Employees with bounced notifications, incorrect contact details, inaccessible accounts or no suitable device. |
| May need proportionate reminders, manager follow-up or other agreed intervention. | Need the underlying delivery or data problem investigated and resolved. |
A former employee who should no longer be assigned the policy is another kind of exception, as is a person who completed the acknowledgement under a duplicate profile.
Repeated reminders to employees who never received the original notification won’t solve the problem. They can, however, make the outstanding report increasingly difficult to interpret.
A useful system should help administrators identify failed deliveries, monitor overdue actions, report on relevant employee groups and make the follow-up process manageable.
But somebody still needs to resolve access failures, correct source data and determine when a line manager or another internal owner should intervene.
Before selecting or configuring a policy tracking system, organisations should identify which legal, governance, contractual and industry requirements the process needs to support.
These requirements may influence the controls, records and retention arrangements you need. They do not automatically prescribe a particular software platform.
Depending on the organisation, the following may shape how policies are distributed, acknowledged and retained:
None of these prescribes a particular platform, and each applies differently depending on the organisation and the record involved. The organisation’s Legal, Compliance or Information Governance function should establish the applicable requirements before technology choices are finalised.
When moving away from spreadsheets and manual records, organisations generally have two technology choices: configure or develop a solution using existing infrastructure, or buy a dedicated platform.
AI-assisted development can reduce some of the effort involved in building an internal application. Existing Microsoft 365 licences, identity services and document management tools may also provide much of the required infrastructure.
But building a system means taking responsibility for its continued operation, not merely producing a working first version.
| Evaluation criterion | Internal build or configured workflow | Purpose-built policy tracking platform |
|---|---|---|
| Initial cost | May reuse existing licences and internal skills, but design, configuration, testing and development still have a cost. | Usually involves licence, subscription or implementation costs, depending on the product and scope. |
| Time to implementation | Depends on the complexity of the requirements and existing technical capability. Simple workflows may be deployed quickly. | Existing functions can reduce development work, although configuration, data preparation and testing still take time. |
| HR and IT data integration | Can use existing connectors, APIs or custom integrations. Reconciliation rules still need to be established. | Import and integration capabilities vary by platform. Confirm exactly which systems, attributes and updates are supported. |
| Document versioning | Requires deliberate configuration or development linking versions, assignments and historical responses. | May provide established version-linked records. Check what remains retrievable after updates or archiving. |
| Audit trail and reporting | Must be designed and tested against the events and reports the organisation actually needs. | Typically includes reporting and recorded activity, but audit-trail detail and export capabilities should be verified. |
| AI-powered policy search | Can be developed using suitable search and AI services, with appropriate source, permission and privacy controls. | Availability varies. Confirm whether the capability exists today, is planned or requires another product. |
| Ongoing maintenance | Internal team maintains custom workflows, integrations, security configuration and changes to underlying services. | Supplier usually maintains the core platform; client configuration, employee data and operational responsibilities remain. |
| Long-term dependence | Depends on internal expertise, documentation and underlying technology providers. | Depends on supplier continuity, product development, support, contractual terms and data portability. |
Neither approach is automatically cheaper, faster or more reliable.
A capable internal IT team may be able to create a highly effective solution using tools the organisation already owns. A dedicated platform may reduce the work involved in developing and maintaining specialised functions.
The comparison should account for the total cost and ongoing responsibility involved in keeping the process dependable as the organisation, employee population and policy register change.
Before committing to a policy tracking system, the relevant departments should be able to answer the following questions:
Many of these responsibilities can be consolidated, and automation can reduce much of the routine workload. But they still require clear ownership, suitable expertise and enough capacity to handle the exceptions.
At Compliance Online, we’ve developed Policy Passport to manage the employee-facing part of policy distribution and tracking.
It helps organisations distribute approved documents to defined employee groups, record acknowledgements, attestations and other configured responses, maintain version-linked records, monitor outstanding employees and produce reports of what happened.
Policy Passport is designed to support workflows relevant to South African legal and governance requirements, including policy communication and acknowledgement practices associated with ISO/IEC 27001. Whether a particular implementation satisfies the organisation’s obligations depends on the requirements, configuration and operating practices.
Policy Passport can be operated by the client or supported through agreed managed administration, depending on how much of the operational work the organisation wants to retain.
The case for policy tracking software is straightforward: reduce repetitive administration, improve employee access, make follow-up more manageable and preserve a more useful record of policy communication.
Whether that is best achieved through existing tools, a custom system or a dedicated platform depends on the organisation’s requirements and its capacity to operate the solution.
Before deciding, make sure the team understands the employee data dependencies, approval and versioning rules, interaction requirements, exception workflows and evidence the system will need to support.
The software can make the process considerably easier. The important thing is knowing which work it removes, and which work your organisation will still need to do.
Related posts