Feature-Policy attestation

[kisero]

@sam

• Enable attestation: toggle, default off
• Audience: multiple-select on users and groups
• Button text: short string, default “Acknowledged”, customisable per policy (“Understood”, “Read and accepted”, whatever the customer wants)
• Deadline: integer + type (days, weeks, months) measured from the moment the version is published. Mandatory when attestation is enabled.
• Reminders: same logic as awareness reminders, two settings:
• After publish: N days after publish, if not yet attested
• Before deadline: N days before deadline, if not yet attested

I would make a Setting / Attestation setting where you define Templates, then when a policy is created you simply select which template you want to use.

Note: this feature can only be used if the policy portal is “Enabled”, if the portal is disabled while this setting is enabled attestations will stop working (notifications in particular)

@sam

We add one extra step on the approval modal when the policy already has at least one published version:

this is only applicable if the “Attestation” is enabled on the document

@sam

• Pending banner on portal homepageWhen a logged-in user has one or more policies waiting for attestation, the homepage shows a banner at the top: “You have N policies awaiting your acknowledgement”. Clicking the banner takes them to a filtered list of just those policies.

this is good

@sam

When a user opens a policy that requires their attestation, the policy renders as today, with a sticky bar at the bottom containing the customised button (“Acknowledged” by default). Click is single-action - no second confirmation modal, the click itself is the attestation. After clicking, the bar is replaced with a small confirmation: “Acknowledged on YYYY-MM-DD HH:MM”.

ok

@sam

1. Bulk attestation from the pending listOn the filtered list of pending policies, the user can multi-select and click a single “Acknowledge selected” button. Each selected policy still gets its own individual attestation record (policy + version + user + timestamp), there is no shared row. The audit trail is the same as if the user had clicked each one in turn, this is just a UX shortcut.

this is not ok, policies must be opened and accepted one by one, the whole point of attestation is that in tehory they read them.

@sam

When workflows are enabled on the policy module, a new “Attestation” tab is added to the policy form.

this is only possible when the content is “Attachment” or “Content Editor”, is impossible to do it with URLs

@sam

• On publish: sent to every audience member, includes a link to the policy portal
• After publish reminder: per the policy’s reminder setting
• Before deadline reminder: per the policy’s reminder setting
• Overdue: sent once when the deadline passes, to the audience member and to the policy GRC contact. Without this the deadline is just a colour on the index, the overdue notification is what makes it real.

this is ok, but the “Overdue” is not important to contact the GRC contact, they would otherwise get many emails.

@sam

Each attestation is a row with:

• Policy ID
• Policy version
• User ID
• Timestamp

ok

@sam

Statistics on the policy index

Two new columns on the main policy index, hidden by default and enabled per user from the column settings:

• Attestation %: x of y users in the audience have attested to the current published version.
• Attestation deadline: the deadline date for the current version, probably based on review date.

These columns should answer:

• which policies are attested by how many % of employees
• which policies missing attestation

ok , but the “probably based on review date” is not correct, is based on the “Attestation Deadline” for that particular document (based on when it was published).

The “review date” triggers a workflow review, which must be approved, this instead triggers a new attestation cycle (because it starts when is approved). the “review date” and “attestation date” can be different.

We need a “system report” that shows “who did the attestation for a given document when”, we need the full list of people who also are missing. make this a static report, no “Tab” in the module.