§ 10.1
Lifecycle, handled
Drafts, approvals, versions, owners, review dates, attestation: standard policy and procedure management software duties, in the same ruled register as everything else.
Policy compliance software keeps a company's policies written, approved, distributed, attested and reviewed on schedule. The part most policy management software misses is the reason a policy exists at all: the regulation behind it. Complianceofficer links every policy to the rule it satisfies, so when the rule moves, you know the same day which documents just went stale.
That link is also what turns policy compliance tracking from an administrative chore into evidence. A signed acknowledgement proves someone read a document. Only the mapping proves the document still says what the law requires.
Last updated September 2026. Regulatory citations on this page point to the current text of the rule, not to a vendor summary.
Pick your sector below. The scan returns the obligation register your policy set has to cover, with the last 12 months of regulatory movement and sources linked. No signup, nothing stored.
§ Live · Compliance scan
No signup. Nothing you pick is stored.
Sample register · fintech, US · what a scan returns
§ 10.1
Drafts, approvals, versions, owners, review dates, attestation: standard policy and procedure management software duties, in the same ruled register as everything else.
§ 10.2
Every policy carries its citations: this retention schedule answers GDPR Article 5, this access policy answers SOC 2 CC6. The map is what makes change detection useful.
§ 10.3
A rule change flags exactly the affected policies and drafts the amendment for your review, with the source cited. You approve; the trail records it.
The upstream half of that loop, catching the change at the regulator, is covered on the regulatory change management page; the downstream evidence half lives in the platform's audit trail.
An annual review cycle means a rule change waits up to a year to reach the document that implements it, and auditors read revision histories. Tying the review to the change, rather than the calendar, is the entire trick: the policy updates when its reason does. Planned pricing for the full register is on the pricing page.
Run the compliance scanMost policy libraries in trouble are in trouble for one structural reason: everything was written as a policy. Board-approved documents then contain screen-level instructions, so every operational tweak needs board approval, so nothing gets updated, so the library drifts. Separating the four document types fixes this before any software is involved.
| Document | Answers | Approved by | Changes |
|---|---|---|---|
| Policy | What we require, and why | Board or executive | Rarely, when the obligation itself changes |
| Standard | The measurable threshold that satisfies it | Function owner | Occasionally, as technology moves |
| Procedure | The steps a person follows | Process owner | Often, whenever the process changes |
| Guideline | Recommended practice, not mandatory | Function owner | Freely, and it binds nobody |
Read the approval column downward. It is the reason a policy set that mixes the types cannot be maintained: the change frequency of the bottom row collides with the approval cost of the top row. Good compliance policy management software enforces the distinction with different workflows, not just different folders.
Yes, and more specifically than most teams realize. The HIPAA Security Rule at 45 CFR 164.316 is the clearest example. It requires covered entities and business associates to implement reasonable and appropriate policies and procedures, to maintain them in written form, and then sets a retention rule that catches people out: retain the documentation for six years from the date of its creation or the date when it last was in effect, whichever is later. Deleting a superseded policy on the day you replace it is a violation.
The same section contains the strongest argument against pure calendar review, in the regulator's own words. The updates specification requires you to review documentation periodically and update as needed in response to environmental or operational changes. The rule is event-driven. An annual cycle is a convention layered on top of it, and it is the layer that lets a policy sit unchanged for eleven months after its reason moved.
Row six is where most policy programs actually fail. Frameworks do not merely require that a policy exists; they require evidence it reached the people it governs. That is what attestation records are for, and it is why policy compliance tracking is a compliance control rather than an HR formality. Per-framework detail sits on HIPAA compliance software, SOC 2 compliance software and ISO 27001 software.
Policy compliance tracking is the record of which employees acknowledged which version of which policy, and by when. Nearly every tool reports it as one number, an overall attestation percentage, and that number is close to useless. Ninety-four percent coverage tells you nothing about whether the missing six percent are the wire transfer team.
Three cuts of the same data are worth having instead. Coverage by policy shows which documents nobody has read. Coverage by population shows which teams are exposed, which is the view a regulator will ask for. And time-to-attestation after publication shows whether your distribution actually works, because a policy that takes eleven weeks to reach half the staff was not communicated in any meaningful sense on its effective date.
The fourth thing worth tracking is rarely built: how many policies are currently downstream of a regulatory change that has not been actioned. That is the queue that turns into findings, and it only exists if policies are mapped to obligations in the first place. The upstream detection is covered on regulatory change management software, and the wider automation picture on compliance automation software.
Policy tracking and attestation software does two jobs a document repository cannot: it pushes a specific version of a specific policy to a defined population, and it holds durable proof of who accepted it and when. The second job is the one that matters in an examination, because an acknowledgement is evidence only if it names a version. An attestation against "the code of conduct" with no version reference proves almost nothing about what the employee actually agreed to.
The mechanics of that, what a defensible record has to contain, the denominator error that makes most reported attestation rates wrong, and what the dedicated tools cost against the GRC suites, are covered in depth on policy attestation software. For US enterprises the deciding requirement is usually multi-entity separation, because a holding company has to show attestation per subsidiary rather than one blended number.
Written accountability policies are also a named requirement in some regimes rather than a best practice. Section 11.10(j) of the FDA electronic records rule requires written policies that hold individuals accountable for actions taken under their electronic signatures, which is a policy obligation no product can satisfy on your behalf. If that applies to you, the attestation evidence here is what proves it, and the control set is covered on 21 CFR Part 11 compliant software.
SOX is where a policy library stops being a documentation exercise and starts being audit evidence, and it is worth being precise about why. Section 404 does not ask you to have policies. It asks management to assess the effectiveness of internal control over financial reporting, and the external auditor to attest to that assessment. Policies enter that assessment in two specific places, and both of them are places where a document store with no dates will fail.
The first is the control environment. Under the COSO framework a written, communicated and acknowledged code of conduct and the delegation-of-authority policy are the entity level controls auditors test first, because a weakness there taints everything below it. Testing them means asking who received the policy, when, and what proportion of the in-scope population acknowledged it. An attestation report that cannot break down by legal entity and by role does not answer that question.
The second is process level control documentation. Every key control in the SOX matrix points at a procedure that says how the control is performed. When the procedure is edited mid-year and nobody records the version boundary, the tester ends up sampling transactions performed under one procedure against a document describing a different one. That is a documentation failure that reads as a control failure, and it is entirely avoidable with versioned effective dates.
Practically, a SOX-ready policy library needs four things a generic document management system does not give you: an effective date and a superseded date on every version, attestation captured per person with a timestamp and retained for the audit period, an owner who is a named individual rather than a department, and a link from each procedure to the control it supports so a change to one flags the other. The control side of that mapping is covered on SOX compliance and the testing mechanics on SOX 404 testing. Where duties are split across roles, the policy has to match the actual access model, which is the subject of segregation of duties software.
Policy management software holds an organization's policies and procedures through their whole life: drafting, review, approval, publication, staff attestation, scheduled re-review and retirement. It replaces a shared drive plus a spreadsheet, and its core job is proving who approved which version and who read it, on what date.
Annual review is the common default and most frameworks accept it, but calendar review means a rule change can wait twelve months to reach the document implementing it. The stronger practice is annual review as a floor plus event-driven review triggered by a change in the underlying regulation, an incident, or a material process change.
It depends on the regime, and the trap is that retention usually runs from when the policy stopped applying rather than when it was written. HIPAA requires six years from creation or last effective date, whichever is later. Superseded versions therefore have to be archived with their effective dates, not deleted on replacement.
Usually yes, and there is a real advantage when policies sit next to the controls and risks they support. The cost is that bundled policy modules are often weaker at authoring and attestation than standalone tools, and are rarely priced separately, so insist on seeing the module before assuming it is included.
Compliance should own the framework, the register and the review calendar. The business function should own the content of its own procedures. Libraries owned entirely by compliance drift out of date because the people who know the process have no reason to touch them, and libraries with no central owner develop contradictions.
It is the subset of policy management that proves distribution and receipt: assign a published version to a defined population, capture a per-person acknowledgement with a timestamp, and report the completion rate by group, entity and role. For US enterprises the deciding requirement is usually multi-entity separation, because a holding company has to show attestation per subsidiary rather than one blended number.
Attestation rate is a fraction, and nearly all the error lives in the denominator. If the employee roster comes from a quarterly export, everyone who joined since is invisible and your rate looks better than it is. Join the policy system to a live HR feed, and put the as-of date on the report. That metric and six others are broken down on compliance reporting software.
Judge the tool on the denominator, not the dashboard. Ask how the in-scope population is built: a live HR integration, a scheduled import, or a manually maintained group. Only the first gives an acceptance rate that is right on the day you are asked. Then check that the rate can be sliced by legal entity, department and role, that a re-issued version resets acknowledgement rather than inheriting the old one, and that historical rates are retained as-of rather than recalculated.
It is the same system handling two different document types with different lifecycles. A policy states what must happen and is approved at board or executive level; a procedure states how it happens and is owned by the function that performs the work. The distinction matters commercially because procedures change far more often, so a tool that makes every edit go through the full approval workflow will be abandoned by the operations teams inside a year.
A policy tracking system is the layer that answers status questions rather than content questions: which policies are in force, which are overdue for review, which population has acknowledged which version, and which ones a regulatory change has just put in doubt. Most organizations already have somewhere to store documents. What they lack is the register that tells them, on any given morning, which of those documents can still be relied on.
Standalone policy and attestation tools are usually priced per employee per year and land in the low tens of thousands for a mid-sized company. Bundled inside a GRC suite it is rarely priced separately. Recorded purchase ranges for the broader suites are on compliance software pricing.
§ 99 · Final entry
Leave your work email, confirm the 6-digit code, and we will email you when your spot opens. Nothing is charged before launch.