Identity and Access Management Solutions

The access nobody owns

Ask an institution who could see customer records in March and the honest answer is that it would take a week to work out. Ask what happened to the access of everyone who left last quarter and the answer is that most of it was probably removed. That is rarely negligence. It is what a business inherits by growing one system at a time, each with its own administrator and its own user list, and nobody holding the whole picture.

Three things go wrong, nearly everywhere. People leave and keep access for months, because the process that tells anyone is a conversation somebody forgot to have. People move, branch to head office, operations to credit, and new access is added while the old stays, so an officer five years in reaches far more than the job needs. And on a busy branch floor logins get shared, because a queue is forming and the new officer's access has not come through. When something is investigated afterwards, three people used one login and the record cannot say which.

Some of this is particular to how institutions here are staffed. Regional branch networks, with transfers and secondments covering leave, produce exactly that accumulation. Field officers, agent supervisors, outsourced contact centre staff and engineers from an old implementation all reach your systems without appearing on your payroll. The Personal Data Protection Act has also changed the question's standing: who inside the institution may see customer information is now a legal position you hold. For a bank supervised by the Bank of Tanzania, internal access is a standing audit item. For a small SACCO the problem inverts: too few people, one of whom holds every credential. For a fintech or a telco whose headcount doubled in a year, whoever set up the first accounts has left.

Joiners, movers and leavers, treated as one process

A new employee should be able to work on their first morning. A line manager or HR raises the request, the access their job carries comes with it, the approving manager signs it, and the person starts. What arrives is what the job needs: a teller gets what tellers get. Anything beyond that is asked for on its own, with a reason and a name against the approval.

The move is the case most institutions handle worst. Someone transfers branch, changes department or is promoted, and the access from the old job is still there years later. It is how a teller ends up able to do things only a manager should. Temporary staff, contractors and vendor engineers can be given access with an end date fixed when it is granted. And a leaver's access ends when their employment does, which is the control auditors ask about most and the one institutions most often cannot evidence.

Day to day, a department head can see what their own people can do and say what is wrong, which is the only reliable way that list gets corrected. Someone under investigation, or who has walked out, can be stopped at once by the officer whose job that is. Staff can clear a locked account themselves, the largest single category of call most service desks carry. Which systems come in first is decided with you: the ones holding customer money and customer data usually come before the stationery order.

The questions an auditor asks

Internal audit, your external auditors and your supervisor all ask versions of one question, always about the past. Who could approve a payment above a given value in March. Who could see customer records at the branch where the loss happened. What became of the accounts of everyone who left last quarter. Which individuals can do two things that ought never to be done by the same person.

Institutions that cannot answer rarely fail an audit outright. They spend weeks assembling an answer from several systems and several people's recollection, one nobody will fully stand behind, and take the same finding again the year after. What you get here is a record that answers directly: what access exists now, what existed then, who asked, who approved, and when it ended. That is also what an internal investigation needs, and what the review your department heads sign is built on.

The customer side, and where this sits

Establishing who a customer is in the first place is onboarding work, covered separately. This is the part that runs for years afterwards: recognising the same customer whenever they come back, on whichever channel they use, to the standard your risk function has set for what they are about to do. The return is in what they can then settle without calling you: a locked profile, a new phone, a forgotten credential, a device they no longer have. Those are the calls that fill a contact centre on a Monday.

Commercially this sits underneath the rest of your estate rather than beside it. Every channel and every internal system has to know who has arrived and what they are allowed to do. Where that has grown up separately in each one, nobody can answer the question across the institution, which is exactly the question an auditor asks. It can be built alongside a channel programme or brought in once several already exist.

What you have to settle, and most of it is not software

The role definitions are the work. Somebody has to write down the jobs your institution actually has and what each one needs to reach. HR holds job titles, and titles rarely match reality: two people with the same one in different branches often do different work. The knowledge sits with department heads and branch managers, and holding them to a decision takes longer than most institutions plan for. It shapes the timeline more than anything we do.

Then a joiner, mover and leaver process with a trigger that actually fires. Someone must be told that a person is starting, moving or leaving, in time, and be accountable for telling. Notice periods, dismissals, resignations effective the same day and staff who simply stop coming in each need an answer, and that answer belongs to HR and operations. Nothing else here matters much if a last day is discovered a fortnight after it passed.

Then a review cadence with a name against it: how often each manager confirms what their people can reach, what happens when one does not reply, and who chases. A review nobody signs is worse than none: your auditor reads the policy that requires it.

And a position on shared and privileged accounts: the counter login three tellers use on a busy morning, the administrator account with unlimited reach, the engineer who has to get in at night when something breaks. Each exists for a reason and each is an exposure. Where headcount makes separation of duties impossible, and in a small institution it often does, the honest answer is a stated position with compensating controls, not a pretence.

How an engagement runs

We start with discovery: the systems you run, the people who use them, the roles you actually have, and what your last audit said. That produces a scope and a plan, and the plan is yours whether or not we build it.

Through delivery you see working software in an environment you control rather than status reports, and the source code and documentation are yours from the first commit. Afterwards we support it and train the people who will run it day to day. There is no lock-in, by design and by contract.