Access review tooling for a regulated lender

The lender had to demonstrate to its regulator that access to customer data was reviewed periodically and that leavers lost access promptly. The existing process was a spreadsheet exported from four systems, emailed to about sixty managers, and returned by roughly half of them, usually approved wholesale without being read. It was failing on two counts: it did not actually reduce access, and it could not produce evidence anyone believed. There had also been a finding about accounts belonging to people who had left months earlier, which is the kind of thing that turns an internal problem into a deadline.

Senior backend engineer, one of four on a platform team, for about eleven months. I led the technical design and did roughly half the implementation, working to a compliance manager who owned the requirement and a product owner who owned everything else the team was doing and had to keep re-prioritising us against it. I also presented the design twice to a governance forum, which was a new experience and taught me to bring one diagram rather than six.

I owned the connectors that pull entitlements out of the source systems and the model that normalises them into something a manager can read — which is most of the difficulty, because a permission in one system is a group in another and a database role in a third. I built the review campaign engine: who is asked what, when it expires, what happens on no response, and the revocation queue that comes out the other end. I also owned the evidence export the auditors receive. I did not build the manager-facing UI, though I wrote the API for it and rewrote it once after watching a manager use it.

The decision that shaped everything was translating raw entitlements into plain statements before showing them to a manager. The obvious build shows the underlying group names, and a manager confronted with a list of internal group identifiers approves all of them, which is exactly what the spreadsheet already achieved. So we invested in a mapping layer that says what an entitlement lets a person do in business terms, and accepted that it needs curating. I also argued successfully for making no-response a revocation rather than a retention — a default that the compliance manager supported and that two department heads fought hard, which took a governance decision rather than a technical one.

The regulator's timetable was fixed and public, so the first full campaign had to complete before a stated date, which meant we cut the fourth system's connector into a later phase and said so in writing rather than pretending. Two source systems were vendor products with rate-limited APIs and no bulk export, so the pull ran over hours and had to be restartable. Nothing could revoke access automatically in the lending platform itself because a mid-transaction revocation has real consequences, so we produced a queue that a named administrator actions. And every design decision had to survive a security review by a team of two who were, correctly, harder on us than anyone else.

The first campaign covered about nineteen hundred accounts and led to roughly a fifth of reviewed entitlements being removed, which tells you what the spreadsheet years had accumulated. Response rate from managers went from around half to over ninety per cent, mostly because a default of revocation is a strong motivator. The leaver gap — the time between someone leaving and losing access — went from a median of eleven days to under two, though that was as much a process change as a technical one. The auditors accepted the evidence export without a follow-up request, which the compliance manager described as the best possible outcome and the least interesting sentence in the report.

The compliance manager translated between the regulator's language and ours and is the reason we built the right thing rather than a very good wrong thing. A colleague on the platform team built the manager UI and ran the usability sessions that made me rewrite the API. The two-person security team reviewed the design twice and found a genuine flaw in how I was handling connector credentials the first time.