An auditor asks for evidence that everyone read the security policy, and the answer is a spreadsheet and some emails. Here is the model behind a tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A policy attestation tracker needs four things: versioned policies with an effective date, assignment rules that target the right population, an attestation record tied to a specific version, and a completion report that distinguishes not yet due from overdue. The detail that makes it audit-grade is the version binding. An attestation that says someone accepted "the security policy" proves nothing if the policy has since changed, so every record must name the exact version and the date it was accepted.
Attestations
2
Waiting on you
94%
Completed, in scope
31
Outstanding, not yet due
11
Overdue
| Policy | Version | In scope | Completed | Overdue |
|---|---|---|---|---|
| Information security | v4.2 | 412 | 387 | 11 |
| Acceptable use | v2.0 | 412 | 401 | 0 |
| Code of conduct | v3.1 | 412 | 409 | 0 |
| Data handling | v1.4 | 96 | 71 | 4 |
| Trading policy | v2.2 | 38 | 38 | 0 |
You run compliance, security or people operations. You already have policies. What you want is to know who has accepted which version, to chase the rest automatically, and to export the evidence without assembling it by hand.
What happens when a policy is published, and what an auditor gets at the end.
With an effective date and a note of what changed, so existing attestations stay bound to the version they were made against.
A flag per version. A typo fix should not send 400 people back to a document.
Rules over department, role, location and employment type, so joiners and internal movers pick up what they need automatically.
With the statement text they agreed to recorded alongside it. Immutable once made.
Reminders before the due date, manager notified after it.
Every person in scope, the version, the timestamp and the statement, as a file an auditor can read without explanation.
An attestation tracker is not a mailing list with a read receipt. It is four parts, and the first one is what makes the record hold up.
Each policy with a version, an effective date, the document itself, an owner, a review cycle, and whether a new version requires re-attestation from everyone or only from new joiners.
Who must attest, expressed as conditions over department, role, location and employment type, evaluated continuously so joiners and movers are picked up automatically.
Person, policy, exact version, timestamp, and how they attested. Immutable once made, because an editable attestation is not evidence.
By policy, by version, by team, separating completed, outstanding within the window, and overdue. Exportable for a period in one click.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Publishing rather than editing, and choosing when re-attestation is warranted.
In this Helix project, build me a policy attestation tracker.
Policies have versions, and versions are never edited. Each version has a
number, an effective date, the document, a summary of what changed from
the previous one, who published it and when.
Add a flag per version saying whether it requires everyone to re-attest,
or only people who have never attested. That flag is what keeps this
proportionate. A typo correction should not send four hundred people back
to a document, and forcing it destroys engagement with the ones that
matter.
Show the summary of changes to anyone re-attesting. People deserve to know
what is different, and a written summary field is enough.
Flag policies past their review date, and any version with no effective
date set.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. An attestation against a document that has since changed proves nothing. Binding it to a version number and effective date is what makes it evidence.
Because a generated list is stale the day after you generate it.
Now assignment. Write rules over person attributes: department, role, level,
location, employment type. Each rule says which policy applies and how
many days somebody has, counted from the later of the version's effective
date and that person's start date.
Evaluate those rules continuously rather than at publish time. A new
joiner picks up every policy they need, and someone changing role picks up
the new ones. A one-off assignment list is stale the day after it is
generated, and joiners and movers are exactly the people most likely to be
missed.
Let me see, per version, the current assigned population and how it was
derived, so I can check a rule before publishing.
And handle leavers: their outstanding attestations close as not applicable
rather than sitting overdue forever and quietly ruining the report.The record, and getting people to make it.
An attestation records the person, the exact policy version, the timestamp,
the method, and the statement text they accepted. Immutable once created.
The page shows the policy, requires the person to reach the end before the
accept action is enabled, and states plainly what they are attesting to.
Support optional comprehension questions per version, configurable, with
answers recorded. Use them for the few policies where it matters rather
than everywhere.
Notify on assignment, remind on a schedule before the due date, then
notify the person's manager once it passes.
Give everyone a personal view of what they owe, what is outstanding, and
what they have already accepted with the version and date.
And do not allow an attestation to be made on somebody's behalf. If a
paper process is genuinely needed, record it as a separate evidence type
with the document attached and a note of who recorded it.Worth knowing. Recording the exact statement text alongside the timestamp is what makes the record defensible. What people accepted matters as much as when.
Three states, never two, and a one-click export.
Report completion by policy, version, department and manager, and always
separate three states: completed, outstanding but not yet due, and
overdue. Collapsing the last two into one outstanding figure makes the
completion percentage meaningless the week after a policy is published.
Give managers a view of their own team's outstanding items.
Report time to attest, as a median and a distribution per version. A
policy that takes six weeks to reach ninety percent has a distribution
problem rather than a compliance one, and that is a different fix.
Then the export: every person in scope for a period, the policy version,
the attestation timestamp, and the statement accepted. One click, as a
file an auditor can read without explanation.
Plus an exceptions view of people who have never attested to something
assigned to them, and a per-person history of every version they have ever
accepted, which is what gets requested when one individual becomes the
subject of a question.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Workday>. Read department, role, level, location and start date,
evaluated continuously so joiners are never missed.
<Okta>. Authenticate every attestation, which is what makes the record
evidence rather than a claim.
<Google Drive>. Hold each policy version, so an attestation points at
exactly what was accepted.
<Slack>. Remind before the due date and escalate to a manager after it.
<Vanta>. Push completion evidence in as it happens, so nobody exports the
same attestation record twice.
<Gmail>. Send the attestation request and the reminders, timestamped
against the due date.
<Snowflake>. Keep the historical record queryable, so a per-person history
survives a policy being retired.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. An attestation is only evidence if the identity behind it is verified, which is exactly what Access Control and SSO give you. Set it before sharing.
Assignment has to be continuous, which means reading the org rather than a list somebody exported.
Workday
Read department, role, level, location and start date, evaluated continuously so joiners are never missed.
Okta
Authenticate every attestation, which is what makes the record evidence rather than a claim.
Google Drive
Hold each policy version, so an attestation points at exactly what was accepted.
Slack
Remind before the due date and escalate to a manager after it.
Vanta
Push completion evidence in as it happens, so nobody exports the same attestation record twice.
Gmail
Send the attestation request and the reminders, timestamped against the due date.
Snowflake
Keep the historical record queryable, so a per-person history survives a policy being retired.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. Its output is evidence, and evidence has to be attributable, so identity and access control are the core of the design.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
An attestation is only evidence if the identity behind it is verified. SSO means every record is tied to an authenticated person rather than a typed name, which is the difference between a record and a claim.
App Security
Pulling the current staff list and role attributes from an HR system keeps assignment accurate. Granting that access to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It holds versioned policies, works out who must accept each one from rules over role and department, records each acceptance against a specific version, and produces the completion evidence an audit asks for.
Because a record saying someone accepted "the security policy" proves nothing once the policy has changed. Binding the record to a version number and effective date is what makes it evidence rather than a note.
No, and forcing it destroys engagement. Make it a flag per version: material changes require everyone to re-attest, and minor corrections apply only to people who have never attested. A typo fix should not send 400 people back to a document.
By rules over department, role, location and employment type, evaluated continuously rather than as a one-off list. A generated list is stale the day after, and new joiners and internal movers are exactly the people most likely to be missed.
Three states, never two: completed, outstanding but not yet due, and overdue. Collapsing the last two into a single outstanding figure makes the completion percentage meaningless the week after a policy is published.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your assignment rules and which versions genuinely warrant re-attestation.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
Legal and Compliance
Log every request the day it arrives, verify who is asking, work a system inventory rather than a memory, and evidence what you did before the deadline. Prompts to build it, and what it takes to run it.
Legal and Compliance
Tier vendors by the risk they actually carry, ask each tier only what it warrants, track findings to closure, and re-review on a schedule. Prompts to build it, and what it takes to run it.
People
Generate the right task list per role, route each task to the team that owns it, and prove that access was actually removed. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.