Sentinel

Problem

An organisation needed to run its internal controls somewhere better than scattered spreadsheets and email. Controls have to be done on time, by the right person, with proof they happened, and reviewed by someone other than whoever did them. And when an auditor asks "show me that this was done, by whom, and when", the answer has to be there without a scramble.

What I built

• A catalogue of controls: what has to be checked, how often, and who is responsible for each. The controls are data, so the organisation can add, retire or change them without a rebuild.
• Evidence attached to execution: doing a control means leaving proof, so a completed control is a record with its supporting evidence, not just a tick.
• States and alerts: each control moves through clear states and flags when something is due or overdue, so nothing lapses quietly and the right people are told in time.
• Approval flow: one person executes, another reviews and approves, so no control is closed on a single person's word.
• Roles and separation of duties: who can execute, who can review and approve, and who can see everything, enforced on the data itself. The person who performs a control cannot approve their own work.
• An audit trail: an immutable history of who did what and when, so a review or an external audit can be answered from the system rather than reconstructed.

Results

The value of a system like this is not the screens, it is the guarantees underneath: that a control cannot be marked done without evidence, cannot be approved by the same person who did it, and cannot be quietly changed after the fact. That is a data-model and permissions problem before it is an interface problem, which is where I spend the design effort.