Policy versioning and acknowledgements

Summary

• A policy version is YYYY.N and identifies one approved edition. The number advances only when a new draft is opened from an approved policy or when you revert to an earlier version; ordinary content edits do not bump it, and an approved policy cannot be edited in place.
• Once a day Noru rolls overdue review dates forward by the policy's review frequency and notifies the assignee and approver. It sends notifications, not tasks.
• Acknowledgements are collected through training plans: a policy-acknowledgement step, a campaign, per-person assignments, and a signed link. Completion is recorded only on an explicit submit and is recorded once per person and edition.

Concepts

How it works

When the version number changes

The next version is computed from the current one: if the current version is from an earlier year, the new version is the current year with N at 1; otherwise N is incremented. A policy with no version yet starts at the current year and 1.

Only two actions call this rule: opening a new draft from an approved policy, and reverting to an earlier snapshot. Editing content on a draft keeps its number. Editing an approved policy is refused with "Cannot edit an approved policy"; open a new draft instead.

A version snapshot is taken when a policy is approved and whenever you click Create version explicitly.

What the policy log records

Every entry carries the version in force at the time.

Generation and regeneration

Policy templates come from the shared catalog's evidence items. Generate and Regenerate use the AI model (see AI and Cortex) and prefer framework-curated canonical documents, such as the ISO 27001 and 27002 sets, before falling back to per-item generation. Regeneration skips policies that already exist unless you choose to overwrite, skips approved policies unless you choose to open a new draft for them, gives new policies an annual review frequency, and links each policy to its controls with a "mapping verified" entry in the control's log. One regeneration at a time is allowed per organization.

The daily review pass

Once a day, for every policy that is not Draft or Archived, Noru checks whether it needs review: an Approved policy with no review date, or any policy whose review date has passed. For each such policy it:

1. Computes the next review date from the frequency: monthly adds one month, quarterly three months, biannually six months, annually one year.
2. Writes the new date as the system user, which also produces an "updated" entry in the policy log.
3. Notifies the assignee and the approver with a Policy Review Required notification linking to the policy.

The pass creates no tasks and does not change control mappings.

The acknowledgement chain

Because a step is pinned to a version snapshot, an acknowledgement always names the exact edition someone read.

Activation and dispatch

A plan needs at least one step to activate. Activation creates the first campaign immediately (Upcoming if the start date is in the future) and schedules the invitation emails for that start; recurring plans also schedule the creation of future campaigns on the plan's frequency. Reminders (sent a configurable number of days before the due date, three by default) and marking assignments Overdue are not automatic; they run when you trigger them from the app, the API, or the MCP server.

Signed links

An invitation carries a signed, single-purpose link bound to one assignment, one step, and your organization. Links expire after 14 days. Opening a link establishes a short-lived session for that attestation page only; the page is excluded from search engines and sends no referrer. Nothing is recorded when the page is opened. Completion happens only on an explicit submit, which records the step completion and the acknowledgement; submitting twice does not create a second record. When every step is complete the assignment is marked Completed. Links for cancelled assignments and archived campaigns are refused.

Edge cases and failure modes

• The version did not change after an edit. That is by design: drafts keep their number until approval, and approved policies cannot be edited. Open a new draft from the approved policy to get the next number.
• Two policies share a version number. Versions are per policy, not per organization; 2026.1 on one policy is unrelated to 2026.1 on another.
• Someone acknowledged the old edition. Acknowledgements are pinned to a version snapshot. Approving a new edition does not carry acknowledgements forward; run a new campaign.
• Review reminders keep coming. The daily pass re-checks every day; if nobody records a review, the date is rolled forward by the pass itself, so the reminder recurs on the next cycle rather than every day.
• A link stopped working. Links expire after 14 days and are refused for cancelled assignments and archived campaigns. Sending a reminder issues a fresh link.
• Reminders and overdue marking are manual. Nothing sends reminders or flips assignments to Overdue unless someone triggers it.
• Regeneration skipped a policy. Existing policies are skipped unless you choose to overwrite; approved ones need the new-draft option.

What you can influence

• Review frequency and review date on each policy drive the daily pass.
• Assignee and approver receive the review notification.
• Create version whenever you want a snapshot without approving.
• Training plan audience and frequency decide who is asked, how often, and whether campaigns recur.
• Manual acknowledgements for people who attest outside Noru.

Related guides

• Policies
• Policy editor
• Training and acknowledgement
• Statuses
• Control status and coverage