build.allanninal.dev

Part 1 of 7 · Compliance tracker series ~5 min read

A compliance tracker on AWS for a few dollars a month

A small business has more recurring checks than anyone keeps in their head. The monthly fire-safety walk-through that has to be logged. The quarterly data-access review that nobody enjoys doing. The annual policy sign-off every staff member needs to complete. The weekly backup test, the cleaning-log sign-off, the equipment inspection that the insurer asks about every renewal. None of these is a one-off deadline — they come around again and again, and each one needs a quick note or photo to prove it actually happened. This post walks through the design of a small tracker that holds all of them, reminds the right owner when each is due, collects the proof, and shows what’s done and what’s overdue.

Key takeaways

  • Three sources for tracked tasks: a Drive task list, a starter-pack lane, and an inbox forwarding lane.
  • Every task ends in one of four moves on each tick: on-track, due now, overdue, or escalate.
  • Per-task chains: a monthly check gets a 5-days-before / on-the-day / 2-days-after nudge; an annual sign-off gets 30/14/3 before.
  • Reminders respect quiet hours and your holiday calendar. A task marked done goes quiet until next time.
  • Designed on AWS for about $1.80/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System architecture: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Tracked tasks" — a Google Drive task list holding each recurring compliance task with its control area, how often it repeats, its owner, what proof to keep, and the date it was last done, plus a starter-pack lane and an inbox forwarding lane that add new tasks to the list. Centre, "Rules and voice" — a Drive folder with a rules doc covering per-task reminder chains, owners, and the escalation point, plus a voice doc with the reminder message templates. Far right, "Owners" — the team members responsible for each control; reminders land in their Slack DMs or, if no Slack ID is set, their email. Each connects via an arrow to the AWS account container below. Tracked tasks have an outgoing arrow into AWS. Rules and voice feed in to ground every reminder. Owners receive reminders with the task, when it is due, what proof to keep, a link to the task row, and a Done button. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Task intake — receives tasks from each source, reads forwarded policies via Textract and Bedrock, and writes the cleaned task into the list. In the middle, the Scheduler — runs daily; reads the task list; computes the next due date per task from its repeat rule; picks one of four moves: on-track, due now, overdue, or escalate. On the right, the Reminder — sends the reminder via Slack or email, respects quiet hours and the holiday calendar, and tracks done-and-evidence per task. Internal arrows flow left to right. A note at the bottom reads: every reminder leaves with full context — the tracker never just says "something is due." Tracked tasks list, starter pack, inbox Rules and voice chains, owners, templates Owners where reminders land tasks in grounds reminder with context AWS account Task intake read, normalize, add to the list Scheduler picks one of four: on-track, due, overdue, escalate Reminder Slack or email, respects quiet hours task move Every reminder leaves with full context — the tracker never just says “something is due.”
Fig 1. Three sources outside, three pieces inside AWS. Tasks flow in from a Drive list, a starter-pack lane, and an inbox forwarding lane. The Scheduler runs daily and picks one of four moves. The Reminder sends the right message to the right person at the right time.

What you set up once (the outside)

  • Tracked tasks. A Google Sheet in a Drive folder, one row per recurring task: name, control area (safety, data, finance, HR, IT, facilities), how often it repeats (weekly, monthly, quarterly, yearly), owner email, what proof to keep (a note, a photo, a signed form), and the date it was last done. You can fill it in once and forget it; new tasks can also enter via two other lanes covered in Part 2 — a starter-pack lane (load a ready-made set of common controls for your industry and edit from there) and an inbox-forwarding lane (forward a policy or checklist to a dedicated address and the tracker proposes a task for one-tap approval).
  • A rules folder. Two short Google Docs in a Drive folder. The rules doc covers the reminder chain for each task — how many days before the due date the tracker should nudge, and how many times. A monthly safety check typically gets a nudge 5 days before, on the day, and 2 days after; an annual policy sign-off gets 30, 14, and 3 days before. The doc also lists the owner per control area (or per individual task, if it overrides), the escalation target if the owner doesn’t act, the quiet hours, and any holiday calendars to skip. The voice doc holds one reminder message template per control area — what the Slack DM or email actually says.
  • Owners. The people responsible for each control. Each owner has a Slack member ID (so the reminder is a DM, not a public ping) or, if Slack isn’t set up for them, an email address. Reminders land with the task name, the due date, what proof to keep, a link to the task row, and a “Done” button that records the task complete and stops further nudges for this cycle.

What runs on every tick (the inside)

  • The task intake. Three sources feed the list. The Drive sheet itself is the canonical store. New tasks can also be added via the starter-pack lane (pick a ready-made set of common controls for your industry and the tracker drops them into the sheet for review) and the inbox forwarding lane (forward a policy PDF to controls@your-company.com, the tracker uses Textract to read it and Bedrock Haiku 4.5 to suggest a task name, control area, and repeat rule, then drops a one-tap approval card in the owner’s Slack to confirm before the row is added).
  • The scheduler. Runs once a day at 8am local. Reads the task list. For each task, computes the next due date from its repeat rule and the last-done date. Compares against the per-task reminder chain in the rules doc. Picks one of four moves. On-track: more than the first nudge away — do nothing. Due now: just crossed the first nudge threshold — remind the owner with full context. Overdue: the due date has passed with no completion — re-nudge, mention when the previous reminder went out. Escalate: stayed overdue past the final nudge — tell the escalation target named in the rules doc; log it. The scheduler itself doesn’t call a model on the daily tick — the move logic is plain Python.
  • The reminder. Reads the voice doc, formats the reminder message for the chosen move and control area, and sends it. Slack DMs go through the Slack Web API. Email goes through SES outbound. Both honor quiet hours (no reminders between 6pm and 8am local by default) and the holiday calendar (no reminders on configured days). Every reminder writes a row in DynamoDB so the next day’s tick can tell whether the owner marked it done. A weekly digest summarizes everything done that week, plus what’s coming up. A monthly summary writes a board-ready paragraph: count by control area, tasks done on time, longest-overdue items.

In plain words

Your monthly fire-safety walk-through is due on the 1st. The owner is your office manager Maria, and the proof to keep is a photo of the signed checklist. On May 27 (5 days before) the tracker pings her in Slack: “Monthly fire-safety walk-through — due June 1, please keep a photo of the signed sheet. [link to the task]” with a Done button. Maria’s busy that week and doesn’t open it. On June 1 she gets the on-the-day reminder. She does the walk-through, taps Done, and attaches a photo of the checklist. The tracker stamps the date, files the photo as proof, and computes the next due date — July 1. It stops nudging her. Next month the cycle starts again, and the board summary now shows the May check was done on time with evidence on file.

The cost of running this is about $1.80 a month at SMB volume. The cost of not running it is the missed safety check the insurer asks about after an incident, or the data review nobody did before the audit, or the policy sign-off half the team forgot.

Design rules that shaped every decision

  • Every reminder ships with full context — task, due date, what proof to keep, link to the row. The owner never has to dig.
  • Four moves, always. On-track, due now, overdue, escalate. There is no fifth.
  • Quiet hours and holidays are respected. Reminders are a finite resource; bad timing burns them.
  • Done stops further nudges for this cycle and stamps the date. The next due date is computed from the repeat rule.
  • The task list lives in Drive. Adding a task, changing an owner, or shifting a repeat rule doesn’t need a deploy.
  • Every reminder and every completion is logged with its proof. Audit a control next year and you can see it was done.

Why this shape

Most teams track recurring compliance in one of three places: a spreadsheet that nobody opens, a calendar invite that gets dismissed, or somebody’s head. The spreadsheet works until it doesn’t — one missed month and the whole thing goes stale. The calendar invite is the worst kind of false comfort: it pings on the day, with no context and no place to record that you did it, when there’s no longer time to plan. And the head, of course, fails the moment the person who held it goes on holiday or leaves the company — and leaves no proof behind that anything was ever done.

The setup above moves the source of truth into a list the team already edits, but adds a small system that looks at that list every day and acts only when something needs doing. Reminders come early enough to plan around. They include what proof to keep so the owner doesn’t have to ask. They escalate cleanly when the owner is out. And they collect the note or photo right there, so the audit trail builds itself. The tracker is invisible most days; visible only on the days a control actually needs attention.

The next four posts walk through each piece in turn: how a compliance task gets set up, how a control comes due, how a reminder reaches the right person, and how evidence gets captured and the cycle restarts. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts