Why access needs governance

A question nobody can answer

An auditor visiting Harbor Clinic asks a question that sounds simple: who can open oncology patient records, and why?

Jordan Ellis, one of the clinic's IT administrators, can answer the first half before lunch. The patient records system can list every account allowed to read and update oncology records, a setting it calls EHR_ONC_RW. There are 46 of them. Most belong to oncology nurses, physicians, and pharmacists, and nobody needs to ask why they have it.

The rest are harder. One belongs to a nurse who covered oncology shifts during a staff shortage two winters ago. One belongs to a physician whose contract ended in the spring. One is called onc-test, and nobody remembers creating it. Another belongs to a billing analyst who was given the oncology team's access to check a batch of claims, because copying an existing setup was quicker than finding something narrower. The project finished long ago.

Jordan can see that each account has the access. Jordan cannot say who decided it should, whether that reason still holds, or whether anyone has looked since. The list answers who. The why lives in old emails, closed help desk tickets, and people's memories, if it lives anywhere at all.

How access drifts

Nobody at Harbor set out to give the wrong people oncology access. Access drifts away from what people need through ordinary events, each of which seemed reasonable at the time. Here is how three of them play out when nothing connects the clinic's records about people to the accounts those people use.

Sam Reyes has been a pediatrics nurse for four years and is moving to the oncology unit. On the first morning in oncology, Sam cannot open the records of the patients on the ward, so the charge nurse calls the help desk, and oncology access is added by hand within the hour. Nobody calls to remove Sam's pediatric access. Sam does not need it, it causes no problem anyone can see, and nobody is looking. Months later, Sam can still read and update the record of every child the clinic treats.

People who change jobs rarely lose access by themselves. Each new job adds what it needs, the old access stays behind, and a long-serving employee who has moved two or three times can end up with more access than any single job requires. This slow build-up is often called privilege creep.

Dr. Lee Moreau, a locum physician, covers the emergency department on a three-month contract. The medical staffing office records the contract and its end date in its contractor register, and someone in IT creates the doctor's accounts from an email sent by the department's medical director. When the contract ends on a Friday evening, the register shows it. Nothing connects the register to the accounts, so they stay open. Weeks later, the patient records account still works, and nobody would notice if someone used it from a home computer. An account that no longer belongs to anyone currently at the organization is often called an orphaned account, and it is one of the most common findings when anyone does look.

At the main site's reception desk, the scheduling system stays open all day under one login, frontdesk, with its password written on a card in a drawer. It was set up so whoever is on shift can book appointments without signing in and out. When an appointment is cancelled by mistake, the record shows only that frontdesk did it. When a receptionist leaves, the password does not change, because everyone else would need the new one. Anyone who has ever worked a shift at that desk still knows it.

None of these is a failure to authenticate. Sam, Dr. Moreau, and the reception staff all sign in correctly with valid credentials. The trouble is that the access no longer matches a reason: a job Sam has left, a contract that has ended, or a login the clinic cannot tie to any one person. Authentication checks who is signing in. It cannot tell whether that person should still have what the account allows.

Writing access down next to its reason makes the drift visible. Here is how Sam's access could look a few months after the move:

Only one row has a clear, current reason. Three have reasons that ended, and one has a reason nobody has checked. None of the rows says when it should end. Sam has done nothing wrong. Each grant was an event, and no event ever took anything away.

Administration and governance

Harbor's first instinct might be to ask IT to clean up. Jordan could remove Sam's pediatric access in a minute. But Jordan does not know which of the 46 oncology accounts are still needed, and a one-off cleanup does nothing to stop the same build-up from starting again the next day.

It helps to separate two kinds of work. Identity administration is the work of creating accounts, granting and changing access, and disabling and removing it: the changes Jordan makes in each system, by hand or through automation. Identity governance is the decision-making and oversight around that work: deciding who should have what and for how long, checking that it is still right, and keeping records that prove what happened and why. Together they are often called identity governance and administration (IGA).

The two halves depend on each other. Administration without governance is fast and blind. Access is granted whenever someone asks, and nothing marks when it should end, which is exactly how Sam's list grew. Governance without administration produces decisions that never reach the systems. A manager agrees in a meeting that the billing analyst's access should go, and the account stays as it was because nobody carried out the change. The arrangement that works links the two: a decision triggers the change, and the change leaves a record that points back to the decision.

Deciding what someone can do described least privilege as granting only the access a task needs. That lesson looked at a single access decision. Governance keeps least privilege true over months and years, as people join, change jobs, and leave. What is Identity? described identity and access management as including how access changes when circumstances change. Governance is how an organization makes sure it actually does.

The lifecycle of access

Access changes at predictable moments in a person's time at an organization. Each moment has a governance question to answer and administrative work to carry out.

Joining and leaving mark the beginning and the end. Changes, requests, and reviews can happen many times in between, and those middle stages are where Sam's access piled up.

The stages start from facts that other systems already record. The HR system knows when an employee starts, moves, or leaves. For locums, students on placement, and supplier engineers, the medical staffing office's contractor register holds the same facts, along with the name of the person who sponsors each of them. When those records drive the lifecycle, a departure recorded in HR becomes a departure everywhere, instead of depending on someone remembering to tell IT. Had Dr. Moreau's accounts followed the register, they would have closed with the contract.

The lessons that follow take these stages in turn, following the same people through processes designed to stop the drift. The next few look at where identity data lives and which system owns each fact. Then come joiners, movers, and leavers, following a new nurse, a transfer, and a departing locum, and provisioning, which carries those changes into applications. Later lessons cover how access is granted through rules, requests, and roles, and finally how it is reviewed and how the results are shown to people like the auditor.

Who decides

When the charge nurse called the help desk about Sam, the person who decided Sam should have oncology access was whoever answered the phone. That is common. The person who can make a change becomes, by default, the person who decides it. Jordan Ellis can add anyone to anything in the patient records system, but Jordan has no way to know whether a billing project still needs oncology records, or whether a nurse covering a shift should keep access afterwards.

Governance gives each decision to the people who hold the knowledge it needs:

• Managers know what their staff's jobs require. The oncology nurse manager can say whether Sam needs the oncology research database.
• Owners know what access to their systems allows and who should hold it. Morgan Hale, the records manager, owns access to the patient records system.
• HR and the medical staffing office know the facts: who works at the clinic, in which job, under which manager, and until when.
• IT carries out the changes, runs the systems that make them, and is accountable for doing that correctly.

An owner is not necessarily the person who runs the system. Jordan administers patient records. Morgan decides who should be able to read and change them, because Morgan understands what the records contain and what health privacy rules expect of the clinic. In the same way, when the pharmacy manager approves each new pharmacy account, it is not because Jordan cannot click the button. It is because the pharmacy manager knows whether a person's work involves ordering or receiving controlled medication.

Separating decisions from changes has a second benefit. If Jordan could both decide who gets access and grant it, nothing would stop Jordan from granting access to Jordan, or quietly doing a favor for a colleague. When someone else makes the decision and both the decision and the change are recorded, each person's work checks the other's. Requesting and approving access and Separation of duties develop that idea.

Every one of these decisions concerns a person and the access they hold, spread across systems that each know that person by a different name. Before anyone can govern it, Harbor needs a clear way to describe it. Continue to Identities, accounts, and entitlements to separate a person from their accounts and from what each account allows.