Evidence and governance metrics
An auditor asks
In January, an auditor reviewing Harbor Clinic's access controls sends two requests. First, show that Dr. Lee Moreau's access ended when the locum contract ended, on Friday 27 November at 18:00. Second, show who approved Sam Reyes's access to the oncology research database, ONC_RESEARCH_R.
Jordan Ellis could answer quickly and miss the point. The patient records system shows that Dr. Moreau's account is disabled today, and that Sam's account holds ONC_RESEARCH_R today. Neither answers what was asked. An account that is disabled in January says nothing about when it was disabled, and access that exists says nothing about who agreed to it. The auditor is asking about the past, and the past is available only from records made at the time.
In identity governance, evidence means those records: made when something happened, showing what was done, by whom, to whom, when, and why. Each process at Harbor produces some. The contractor register holds the contract's end date. The identity system holds Sam's request and its approvals. Each application records the changes made to it, and the access reviews record every decision. Whether Harbor can answer the auditor depends on whether those records are complete, connected, and believable.
What good evidence contains
Here is the record the patient records system wrote when it disabled Dr. Moreau's account.
{
"event_id": "evt-5d72a1c9",
"time": "2026-11-27T18:02:07Z",
"recorded_by": "records.harborclinic.example",
"actor": { "type": "service", "id": "harbor-provisioning" },
"subject": { "identity_id": "hc-4n8v6t", "name": "Dr. Lee Moreau" },
"action": "account.disable",
"resource": { "system": "patient records", "account": "lee.moreau" },
"outcome": "succeeded",
"sessions_ended": 1,
"refresh_tokens_revoked": 1,
"reason": "contract_ended",
"correlation_id": "chg-20261127-0193"
}
All names, hosts, identifiers, and records in these examples are fictional.
Each field answers part of the auditor's question.
| Field | The auditor's question | What this record says |
|---|---|---|
time | When did the access end? | At 18:02:07 UTC on 27 November, two minutes after the contract ended. |
recorded_by | Who says so? | The patient records system, where the access existed. |
actor | Who carried it out? | The identity system's provisioning service, acting automatically. |
subject | Whose access was it? | Dr. Moreau's identity, whose ID never changes even when accounts do. |
action and resource | What changed, and where? | The account lee.moreau in patient records was disabled. |
outcome | Did it work? | It succeeded. An open session was ended and a refresh token revoked. |
reason | Why did it happen? | The contract ended. |
correlation_id | What else belongs with it? | The contract end in the register and the same change in every other system. |
The time is in UTC, which at Harbor in November is also local time. It comes from a clock the system trusts, so records written by different systems can be put in order. The actor is not a person. The provisioning service disabled the account automatically when the contract ended, and the decision behind it is the end date the sponsor confirmed in the contractor register. The reason and the correlation ID lead back to that decision.
A correlation ID is what joins separate records into one story. The identity system assigned chg-20261127-0193 when it saw the contract end and sent it with every change that followed. Searching for it returns the register entry, the identity system's record of disabling the directory account at 18:01, this record, and scheduling's record from 02:00 on Saturday, when its nightly import caught up. The evidence answers honestly: Dr. Moreau's access ended within two minutes in the directory and patient records, and eight hours later in scheduling. The auditor will ask about that gap, and Harbor can explain it because the records show it.
Sam's research access is answered the same way, through a chain of records that share the request's correlation ID.
correlation_id: REQ-26-04417
2026-11-16T09:12:40Z request.submitted actor: hc-2m8w4t (Sam Reyes)
resource: ONC_RESEARCH_R, patient records
reason: "Member of the chemotherapy outcomes study
team for its data review. I need to read
enrolled patients' treatment and outcome
records."
requested_end: 2027-02-15
2026-11-16T14:30:18Z request.approved actor: hc-6v3n8r (oncology nurse manager)
2026-11-17T10:05:02Z request.approved actor: hc-9d1r6v (Morgan Hale, owner)
2026-11-17T10:06:11Z entitlement.granted actor: harbor-provisioning
outcome: succeeded
recorded_by: records.harborclinic.example
2026-11-17T10:07:03Z request.confirmed actor: identity system
detail: patient records lists ONC_RESEARCH_R
for Sam's account
Sam asked, with a reason and an end date. The oncology nurse manager approved that Sam's job needed the access, and Morgan Hale, as the owner, approved that it suited the resource. The provisioning service granted it a minute after the second approval, patient records recorded the grant, and the identity system confirmed it by reading Sam's access back.
Good evidence also includes what was refused. A sign-in attempt on Dr. Moreau's patient records account at 18:40, rejected because the account was disabled, shows the change taking effect. If Sam had been holding a manager's delegated approvals when the request arrived, the identity system's decision to skip Sam and send it to the head of nursing would belong in the record too. Records that show only successes cannot show that any control ever stopped anything. Rejected attempts are also where detection starts: a disabled account that keeps trying to sign in may be someone testing a stolen password. Detecting identity attacks looks at how to spot that kind of activity and decide when it needs a response.
Evidence you can trust
The auditor does not have to take Harbor's word for anything, and good evidence does not ask them to. Three properties make a record believable.
First, it is recorded together with the change. The patient records system wrote its record at 18:02:07 because it disabled the account at 18:02:07, as part of the same operation. A spreadsheet filled in at the end of the month from memory and tickets can be wrong in ways nobody can detect afterwards.
Second, it is protected from editing by the administrators it describes. Through the administrator account adm-jordan.ellis, Jordan can disable accounts and grant entitlements. If Jordan could also edit or delete the records of doing so, the records would prove only what Jordan chose to leave in them. Harbor sends audit records to a separate store that administrators of the recorded systems cannot change, and reading that store is itself recorded. The actor in each record also has to be identifiable. A record that says relief-pharm or a built-in administrator account did something attributes it to nobody in particular, which is one more reason to give such accounts owners and replace shared logins with individual ones.
Third, it is kept for a defined period. A record is useful only if it still exists when someone asks, and audits often look back a year or more. Records also contain personal information, so keeping everything forever is not the answer either. Harbor sets a retention period for each kind of record, keeps it that long, and then deletes it on schedule.
Auditors rarely stop at the cases they asked about first. This one picks another leaver from Harbor's list: Lin Wong, a pharmacist who left on 31 August. The pharmacy system is changed by hand from tickets, and the only trace of the removal is a ticket, "Disable pharmacy account for Lin Wong", marked done on 31 August. The ticket shows that someone said the work was done. It does not show which account changed, whether it was disabled or only had its password reset, or when the change took effect, and nothing from the pharmacy system backs it up. Here the ticket was wrong. December's reconciliation found lwong still enabled, more than three months after the ticket was closed. Harbor now has the identity system read pharmacy accounts back after each ticket closes and record what it finds, with the same correlation ID as the rest of the change. That record reflects the pharmacy system's actual state, not someone's report of it.
Measuring whether it works
Evidence answers questions about single events. Harbor also wants to know whether its governance works in general, and the same records can be counted. A handful of measures cover most of what matters.
| Measure | What it shows | Harbor, last quarter |
|---|---|---|
| Time to remove a leaver's access | How long access outlives its reason, from the end time in the authoritative source to confirmed removal in the last system | Median 7 hours, because scheduling imports changes nightly. Longest 103 days, for Lin Wong's pharmacy account. |
| Orphaned accounts over time | Whether reconciliation, and the fixes to what causes orphans, are working | 31 in September, 12 in December. |
| Reviews completed on time | Whether reviewers decide by the deadline | 97 percent of review items. |
| Review items that removed or changed access | Whether reviews find anything to correct | 6 percent. |
| Exceptions past their end date | Whether end dates on exceptions and temporary access are enforced or only written down | 2, both in billing. |
Removal time is measured to confirmed removal in the last system, not to the first system or to a closed ticket. By its ticket, Lin Wong's pharmacy access ended on 31 August. By the pharmacy system's own state, it ended in December. The slowest system is where the work is, and here it points straight at the pharmacy tickets.
The orphan count matters more as a trend than as a single number. A steady fall suggests reconciliation and the fixes behind it are working. A sudden rise usually means a process has broken somewhere, such as a leaver feed that stopped arriving.
Exceptions past their end date are the clearest of the five. Every exception and temporary grant at Harbor is given an end date when it is approved, and each one still running afterwards is access that nobody has decided to keep. The two in billing go back to their owners for a decision this week.
When the numbers mislead
Consider a measure that looks perfect. For two years, the quarterly reviews of EHR_ADMIN have been 100 percent complete and on time. Over the same two years, they have never removed or changed anything. People have moved, projects have ended, and contractors have come and gone, so a list of administrators that never needs a single change is unlikely. It looks much more like the 412 decisions Morgan once made in six minutes, described in Access reviews.
Completion measures activity: reviewers opened the list and recorded a decision. It does not measure the outcome, which is whether the access afterwards is right. Harbor watches both, and pairs measures that check each other. Completion sits beside the share of items that changed something, and beside how long reviewers spent per decision. Leaver removal time comes from the target systems' records, because closing tickets faster improves a ticket count without removing anything. The orphan count sits beside how each orphan was resolved, because deleting accounts without investigating them also makes the count fall. And access that a review removed, only for it to come back after the next sync, counts against that review, since the source still grants it.
A number that looks wrong is a reason to look, not a verdict. A small, stable team might keep the same access quarter after quarter for good reasons. The evidence behind the number shows which explanation is true: who decided, how long they took, and what they saw when they did.
The auditor will look at both kinds of material. The records answer the questions about Dr. Moreau and Sam. The measures, read with the evidence behind them, answer the larger question those two cases stand for: whether access at Harbor follows a reason, and ends when the reason does.
Governance assumes the people holding access are the people it was granted to. An attacker who signs in with a nurse's stolen password inherits every entitlement the nurse holds, however carefully each was approved. Continue to Why attackers go after identity to see why identities are such a common target, and the routes attackers take to reach them.