/manage/access-log

Sensitive data access log

Every sign-in to the admin area, every screen opened inside it, and every read of a single player's record. The rows are written by the system as the work happens, never typed in afterwards. A refused attempt is recorded the same way a successful one is.

Nothing here can be edited or removed — including by you

This table is append-only in the database, not merely in the interface: there is no update route and no delete route for a row. A log that the logged person can tidy up is not a log. The account with the most power in this system is also the most heavily recorded — your own reads are in the list below, under your name.

Kept for 12 months, then removed in a single batch by a scheduled job — never one row at a time, and never by hand. A copy goes to the external auditor each quarter, so the highest level of access inside the organisation is not the only pair of eyes on it.

This is not the 90-day technical log. Truncated IP, sign-in outcome, device and fault events are short-lived security/reliability data. This 12-month dataset is the separate append-only accountability trail for privileged staff access to sensitive records.

Reads of a player record

last 30 days · every one tied to a request

Refused attempts

4 from an account outside the organisation

Reads with no matching request

flagged automatically · reviewed 25/07

Rows edited or deleted

no route exists that could do it

Filter the log

Staff account

Event

Outcome

Player account code

Codes only. There is no name or email field to search on.

From

Exporting the log writes a row to the log, under the name of whoever exported it. There is no quiet way to take a copy.

Showing 17 of 412 rows 24–27 July 2026 Refused · 6 Flagged · 1 Newest first

When	Account	Session	Event	What was touched	Reason on record, and who confirmed it	Outcome
27/07 08:12	Marcus Hale System admin	s-7f13c	Sign-in	—	Two-factor confirmed on a registered device	Allowed
27/07 08:14	Marcus Hale System admin	s-7f13c	Screen opened	/manage/users	List of account codes only. No player record was opened from it.	Allowed
27/07 08:31	Marcus Hale System admin	s-7f13c	Record read	U-10466 Account status and cooldown state	Suspension request #CD-0041 — signs the account holder is under 18. Confirmed by Dr Alice Brennan at 08:26, before the record was opened.	Allowed
27/07 08:33	Marcus Hale System admin	s-7f13c	Record read	U-10412 Account status and cooldown state	Erasure request #DR-0031 — confirm the request came from the account holder before anything is destroyed. Confirmed by Dr Alice Brennan at 08:28, before the record was opened.	Allowed
27/07 08:36	Marcus Hale System admin	s-7f13c	Export	U-10188 Export file built for the account holder	Export request #DR-0030, due 31/07. The file was built by the system and released to the account holder. Confirmed by Tom Whitfield at 08:34. No staff account opened the contents — there is no screen that displays them.	Allowed
27/07 09:02	Sam Okafor Content admin	s-7f2aa	Screen opened	/manage/videos	Inside their own area	Allowed
27/07 09:07	Sam Okafor Content admin	s-7f2aa	Screen opened	/manage/accounts	Outside the content admin's area. The screen the account saw named no page and gave no reason — a refusal must not tell someone what exists behind it.	Refused
27/07 06:40	Priya Raman Impact analyst	s-7ef01	Sign-in	—	Two-factor confirmed	Allowed
27/07 06:44	Priya Raman Impact analyst	s-7ef01	Screen opened	/manage/metrics	Aggregate figures with a minimum group size. No player record can be reached from that screen, so this session produced no read.	Allowed
26/07 21:40	Nina Ward Content admin · awaiting activation	no session	Sign-in refused	—	Three attempts in four minutes. Two-factor has not been set up, so no session could be created. The details typed in are not recorded — not in plain text, not hashed, not anywhere.	Refused
26/07 17:55	Dr Alice Brennan Clinical reviewer	s-7e8b4	Record changed	Staff account request #AC-0116	Raised a request to revoke access for a staff account. Changes to who holds which role are also listed on staff accounts.	Allowed
25/07 14:02	Marcus Hale System admin	s-7dc90	Record read	U-10307 Cooldown state	Reason given: "checking a support email". No request or ticket was linked, so the row was flagged the moment it was written. Reviewed the same day by Dr Alice Brennan — see the note below.	Allowed · flagged
24/07 16:20	Tom Whitfield Sponsorship manager	s-7d411	Screen opened	/manage/sponsors	Inside their own area	Allowed
24/07 11:03	Marcus Hale System admin	s-7d3a7	Record read	U-10466 Registration date and account status	Preparing suspension request #CD-0041. Confirmed by Dr Alice Brennan at 10:58, before the record was opened.	Allowed
24/07 09:15	Elena Marsh · Riverside Grocers Sponsor · outside the organisation	s-7d102	Sign-in	—	Two-factor confirmed	Allowed
24/07 09:24	Elena Marsh · Riverside Grocers Sponsor · outside the organisation	s-7d102	Screen opened	/manage/metrics	Outside the partner area. Nothing was returned, not even a count.	Refused
24/07 09:25	Elena Marsh · Riverside Grocers Sponsor · outside the organisation	s-7d102	Screen opened	/manage/users	Second refusal in 90 seconds from an account outside the organisation. Raised with Tom Whitfield the same day — see the note below.	Refused · flagged

Times are server times. A row appears here whether the action succeeded or was refused, and the row is written before the response is returned, so a refusal cannot be lost by closing the browser.

What the flags picked up

A read with no request behind it — 25/07, U-10307

A cooldown state was opened with the reason "checking a support email" and nothing linked to it. The system cannot tell a good reason from a bad one, so it does not try: it flags any read that has no request or ticket attached and sends it to the clinical reviewer the same day.

Outcome, recorded 25/07 by Dr Alice Brennan: the read was legitimate — a player had written in about a cooldown that looked wrong — but the request should have been raised first, not afterwards. The read stands, the flag stays on the row permanently, and the reviewer's note is attached to it. There is no way to clear a flag.

Two refusals in 90 seconds from an account outside the organisation

Elena Marsh at Riverside Grocers holds a sponsor account. That account can reach the partner area and nothing else. On 24 July it touched pilot figures and then the player list within a minute and a half, and both were refused.

This is the earliest useful signal of misuse there is, which is why refused attempts sit in the same table as successful ones rather than in a separate technical log nobody opens. Raised with Tom Whitfield the same day; the answer was a bookmarked link from an old pilot document. The rows stay either way.

Two roles that can never generate a read

Counted over the last 30 days

Account	Role	Reads of a player record	Refused attempts	Why the number is what it is
Priya Raman	Impact analyst	0	0	Reaches pilot figures only, and those are aggregates with a minimum group size. There is no screen, route or export in that role that returns a single player.
Elena Marsh · Riverside Grocers	Sponsor · outside the organisation	0	4	Reaches its own campaign totals only. The four refusals returned no data at all, so the count of reads stays at zero.
Marcus Hale	System admin	9	0	The highest level of access in the system, and the most recorded. Every one of the nine is tied to a request approved by someone else.
Dr Alice Brennan	Clinical reviewer	5	0	Confirms requests before a read and reviews flagged rows. Her own reads are logged by the same rule as everyone else's.

Zero is the number to look at. It is not a promise that the analyst and the sponsor behave well — it is the shape of what those two roles can reach at all.

What this log does not hold

The contents of what was read. The row says a record was opened, never what was in it. A log that copied the data would double the risk instead of reducing it.
Names, emails or phone numbers of players. Targets are account codes and nothing else.
AI companion conversation text. The current outbound companion does not send or store a transcript in tibbi, so none can appear here.
Passwords or one-time codes, including from failed sign-ins, in any form.

Staff names are shown in full. Being accountable for your own work is the point of the page.

Where these rows come from

The confirmations recorded above are the same ones raised on these screens. If a request says it was written to the log, this is the log it means.

Players & cooldown — cooldown status, extensions and suspensions; valid cooldowns have no early-release action
Data requests — exports and erasures with a legal deadline
Staff accounts — who was granted or refused which role, kept as its own register
System settings and Jobs & queues — configuration changes and manual job runs

Not available here: editing a row · deleting a row · hiding your own activity from the list · signing in as another person, which would put their name on your actions · taking a copy of the log without that copy being recorded. If any of those five ever appears in a build, treat it as a release blocker, not a new feature.