Policy Management Software: The AI-Era Buyer’s Guide

Key takeaways

• Policy management software used to be judged on storage, workflow and attestation. Since 2025 it is also judged on whether it can produce evidence a regulator accepts.
• The EU AI Act turns policy into a statutory deliverable: Article 4 requires AI literacy measures from providers and deployers, and Article 53(1)(c) requires providers of general-purpose AI models to put a copyright policy in place.
• ISO/IEC 42001 Annex A control A.2 requires a documented AI policy, aligned with other organisational policies and reviewed at planned intervals.
• An attestation proves a document was opened. It does not prove a control operates, and it covers nothing for AI tools that never entered your inventory.
• Buy for provability: policy bound to control, control bound to an owner and a date, and the whole chain exportable for any point in the past.

What policy management software actually does

Policy management software centralises the lifecycle of internal rules: drafting, review, approval, publication, distribution, acknowledgement, monitoring, periodic review and retirement. The category exists because shared drives and email threads cannot answer the only question that matters during an audit, which is which version of which rule applied to which people on a given date. Most buyers arrive expecting a better repository. The repository is the least interesting part. Four capabilities separate real policy management software from a well-organised folder:

• Enforced approval separation. The person who drafts a policy cannot be the person who approves it, and the system records both identities and the moment of approval.
• Point-in-time reconstruction. You can show what the published version said on 14 March, not only what it says today.
• Scoped acknowledgement. The right subset of people is asked to attest, based on role, entity or system, and the exceptions stay visible.
• Audit export. The evidence leaves the tool in a form an assessor can read without a licence.

Everything else, including the AI drafting assistants now bundled into most products, is convenience. If those four are weak, no amount of authoring polish will save the audit. This is the same logic that separates a document store from a working compliance management system.

Policy, standard, procedure: the distinction that decides your tooling

A policy states intent and assigns accountability. A standard sets the measurable threshold. A procedure describes the steps. Teams that collapse the three into one document end up rewriting the whole artefact whenever a technical parameter changes, which is why their review cycles slip. Tools differ sharply here. Some model a single flat document type, others model a hierarchy in which a standard can change without reopening the policy that authorises it. If your AI controls will be revised more often than your governance intent, and they will, insist on the hierarchy.

Why 2026 changed the requirements

Until recently, having a policy was good practice. For anyone building or deploying AI, it is now a legal obligation with named articles behind it. The EU AI Act’s Article 4 on AI literacy has applied since 2 February 2025. It requires that “providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf”. Those measures have to be recorded, aimed at the right roles and kept current, and the record of who received which training is exactly what a policy tool is supposed to hold. Article 53(1)(c) goes further for providers of general-purpose AI models, who must “put in place a policy to comply with Union law on copyright and related rights”. The wording matters. The obligation is not to behave well, it is to have a policy, and a regulator can ask to see the document. Our guide to general-purpose AI obligations sets out the rest of that regime. Standards point the same way. ISO/IEC 42001 Annex A control A.2 requires a documented AI policy, alignment with the organisation’s other policies, and review at planned intervals for continued relevance and effectiveness. Clause 7.5 makes that policy mandatory documented information, so an assessor will ask for it by name during certification. The NIST AI RMF is consistent: GOVERN 1.2 expects the characteristics of trustworthy AI to be integrated into organizational policies, processes, procedures and practices, while GOVERN 1.1 expects legal and regulatory requirements to be understood, managed and documented. The UK’s AI Management Essentials draft, published by the Department for Science, Innovation and Technology, makes the point most plainly. Of its ten self-assessment themes, the second is simply “AI policy”, and the tool assesses organisational processes rather than the AI products themselves. Nobody is asking whether your model is good. They are asking whether your management system works. Most buyer’s guides in this category were written before any of these instruments existed, which is why their feature lists stop at version control. The practical consequence for anyone shortlisting policy management software is a change in the question being asked. The old question was whether the tool could get a document to everyone and record that they opened it. The new question is whether the tool can hand an assessor a defensible answer to a narrow, awkward request: show me the policy that discharges this obligation, the version that was in force in the period you are claiming, the people it applied to, and the evidence that the control behind it actually ran. Products that were designed as distribution engines answer the first question well and the second one badly.

The attestation trap: a signature is not compliance

Every product in this category counts attestations, and most buyer’s guides treat the attestation rate as the headline metric. It is a weak proxy. An attestation records that a named person opened a document and clicked to confirm. It does not record that they understood it, that their behaviour changed, or that the control the policy describes is operating. A department can sit at 100 per cent acknowledgement on an acceptable-use policy while running an unreviewed model in production, and the dashboard stays green throughout. The gap widens with AI. Acceptable-use policies apply to the tools you know about. Shadow AI, meaning the models and assistants staff adopt without passing through any intake process, is unattested by construction: a tool that never entered the inventory was never in scope for any acknowledgement campaign. Attestation coverage measured against a register missing a third of the estate is a measurement of the register, not of compliance. What an assessor asks for instead is a chain. Which obligation requires this control, which policy states it, who owns it, and what evidence shows it operated during the period under review. Tooling that stops at “published, 94 per cent acknowledged” leaves you assembling that chain by hand, in a spreadsheet, the week before the audit. That is the practical test of auditability, and it is where policy tooling ends and governance tooling begins. None of this makes attestation worthless. It remains the cheapest way to establish that a rule was communicated, and communication is a genuine legal element of several obligations, including the AI literacy duty above. The error is treating the acknowledgement percentage as the outcome rather than as one input. Read it as a distribution metric, keep it, and then ask the harder question separately: for each policy, what independent artefact would convince someone who does not trust us that the rule was followed?

Nine evaluation criteria that matter now

Feature checklists in this category run to fifty items, most of which every product satisfies. These nine separate them.

1. Policy-to-control-to-evidence binding. Can a policy clause point at a control, and can that control point at the artefact proving it ran? If the answer is a hyperlink to a shared folder, that is not binding.
2. Multi-framework mapping. One policy usually satisfies several obligations at once. A single clause should carry mappings to the EU AI Act, ISO/IEC 42001 and the NIST AI RMF simultaneously, so adding a framework does not mean rewriting the library. Our AI governance framework guide covers the crosswalk logic.
3. Event-driven review triggers. Annual cycles were designed for stable regulation. Ask whether a review can be triggered by an external instrument, a model version change or an incident, not only by a date.
4. Effective dates and supersession. Version numbers are not enough. You need an effective date, a supersession chain and the ability to answer what was in force at an arbitrary past moment.
5. Scoped attestation. Acknowledgement targeted by role, legal entity, jurisdiction or specific AI system, with a visible exception queue. Blanket campaigns to all staff produce high numbers and low signal.
6. Inventory linkage. The policy library should read from the same system of record as your AI inventory. Maintained separately, the two will diverge, and the divergence becomes the audit finding.
7. Structured, exportable data. Policies held only as PDFs cannot be queried, compared or fed to downstream controls. Ask for an API and a structured export before you ask for templates.
8. Immutable audit trail. Every state change logged, with the log itself protected from editing by administrators.
9. Delegated authoring with enforced separation. Subject matter experts draft in their own areas while approval authority stays with the accountable owner.

Where the tool categories differ

Naming products dates quickly and tells you little, since feature parity in this market is reached within a release or two of anyone shipping something genuinely new. The categories are more stable, because they reflect where each product came from. Four groups currently sell policy management software, and each carries the assumptions of the problem it was originally built to solve. Document-control suites grew out of quality management and public-sector accreditation. Lifecycle, versioning and attestation are excellent, often the best available. Framework mapping is usually shallow, and AI-specific obligations are absent or treated as a generic document type. Horizontal GRC platforms map policies to risks, controls and regulations as a first-class function, which is exactly criterion one. The cost is configuration: these deployments are measured in quarters, and the AI content is typically a module added to a pre-AI data model. Intranet and productivity-suite tools win on adoption, because staff are already there, and on price, because the licence is often already paid for. They are weakest on evidentiary rigour: approval separation, immutable logs and point-in-time reconstruction tend to be conventions rather than enforced behaviour. AI-native governance platforms start from the obligation rather than the document, so policies arrive already bound to controls and to an AI system inventory. The category is younger, so breadth outside AI governance varies. Most organisations already own something in the first three categories, so the realistic question is rarely a full replacement. It is which layer holds the evidence. We work through that trade-off in AI governance tools: the compliance platform versus the stack around it.

The build-on-SharePoint question

Building on an existing document platform is defensible when your policy count is low, no sector regulator is involved, and nobody has yet asked you to reconstruct a past state. It stops being defensible the first time you need enforced approval separation and an immutable log, because both have to be built and then maintained as the underlying platform changes. Budget for the maintenance, not only the build.

Where this is heading: machine-readable policy

The current generation of tools treats a policy as a document with metadata attached. The direction of travel is a policy as structured data that systems can act on. The clearest published statement of this is the Policy Cards proposal (Mavracic, October 2025), which argues that Model, Data and System Cards describe a system but lack a normative operational layer. Policy Cards encode allow and deny rules, obligations and evidentiary requirements that an agent enforces at runtime, with crosswalk mappings to the NIST AI RMF, ISO/IEC 42001 and the EU AI Act. Whether or not that specific format is adopted, the requirement behind it is already real for anyone deploying autonomous AI agents. An agent cannot read a PDF and infer that it must not send customer records to an external model. The constraint has to exist in a form the runtime can evaluate. Buyers making a multi-year decision should weight structured policy representation and an open export format more heavily than the authoring interface.

A 30-day evaluation plan

Week 1: inventory what you already have. List every policy, standard and procedure with its owner, its last approval date and its next review date. Most organisations discover two things: several documents have no owner, and the total is higher than anyone estimated. Buy nothing yet. Week 2: map documents to obligations. For each item, record which obligation requires it. Some will map to nothing, which usually means the document is legacy. More useful is the reverse list: obligations that map to no document. On the AI side that gap tends to include Article 4 literacy measures, an acceptable-use position for generative tools, and a model change-management rule. Week 3: pilot two policies end to end. Pick one straightforward policy and one that touches AI. Run both through drafting, approval, publication and scoped acknowledgement in each shortlisted tool, then export the evidence. The export is the test, not the workflow. Week 4: run an audit dry run. Choose a date three months in the past and ask each tool to show what was in force then, who had acknowledged it, and what evidence exists that the related control operated. Score on how much manual assembly the answer required. This mirrors what happens during an AI audit, and it is the part of the evaluation that predicts how a tool behaves under pressure.

FAQ

What is policy management software? Policy management software is a system for managing the full lifecycle of an organisation’s internal rules: drafting, review, approval, publication, distribution, acknowledgement, periodic review and retirement. It replaces shared drives and email chains with enforced workflows, version control with effective dates, a record of who acknowledged each version, and an audit trail covering every change. The stronger products also bind each policy to the controls and obligations it supports. Is policy management software the same as a document management system? No. A document management system stores files and tracks versions. Policy management software adds the governance layer: enforced separation between authoring and approval, scoped acknowledgement campaigns, review scheduling, and reporting built for assessors rather than for librarians. You can build policy management on top of a document management system, but you are then building and maintaining that governance layer yourself. Does the EU AI Act require policy management software? It requires policies, not a particular product. Article 4 obliges providers and deployers to take measures ensuring a sufficient level of AI literacy among staff, and Article 53(1)(c) obliges providers of general-purpose AI models to put a copyright compliance policy in place. Nothing obliges you to buy a tool. In practice, once you must evidence which version applied to whom and when, spreadsheets stop scaling. See our EU AI Act operator’s guide. Do we need a separate AI policy, or can we extend existing policies? Either can work, and ISO/IEC 42001 control A.2 expects alignment with other organisational policies rather than isolation. A separate AI policy is usually easier to evidence, because an assessor asking for the AI policy receives one artefact instead of amended clauses spread across six documents. Whichever route you take, keep accountability named and the review interval explicit. Is free policy management software good enough? For a small organisation with a handful of policies and no sector regulator, a free or bundled tool is often proportionate. It stops being proportionate once you need enforced approval separation, point-in-time reconstruction or evidence export, which are precisely the capabilities free tiers omit. The price of the tool is rarely the deciding factor. The cost of assembling evidence by hand is. What does policy management software cost? Published pricing is uncommon in this category. Most vendors quote per user per year with a platform fee, and the total is driven by the number of people who must acknowledge policies rather than the number who author them. Settle the acknowledgement-user count before requesting quotes, because it moves the price most and is the figure buyers most often underestimate. How often should policies be reviewed? ISO/IEC 42001 requires review at planned intervals without fixing the interval. Annual is the common default and is reasonable for stable areas. For AI policies a calendar interval alone is insufficient, because obligations and systems change between cycles. Add event triggers: a new regulatory instrument, a material model or vendor change, or an incident.

Conclusion

This category has been sold on the same promise for a decade: get your policies out of shared drives and prove people read them. That promise is now the entry ticket rather than the differentiator. Regulation has moved the bar from distribution to proof, and AI moved it fastest, because the systems being governed change far more often than any annual review cycle anticipated. When you evaluate policy management software, run the audit dry run before the feature demo. A tool that cannot reconstruct what was in force last quarter, and show the evidence behind it, will not survive contact with an assessor however good the authoring experience feels. If you are building that evidence layer for AI specifically, start with our AI governance guide.