Access Control and Data Minimisation: Who Sees What

Access control decides which named people can read which data. Data minimisation decides how little of it exists to be read at all. The two attack one risk from opposite ends, and the second end is the stronger one. A value that was never collected needs no permission, no place on a quarterly check, and no decision about how long to keep it. Both are counted in people and in fields.

What does the store behind a running chain actually hold?

Both questions are asked about one store, and both are easier to follow once that store is in view. So the store comes first.

At Sumeru Bank Limited, an invented lender, the retail loan intake and decision chain reads four documents on every application and pulls 14 fields out of them. The 14 fields and the document images they were read from sit in one store. In a steady month the chain completes 8,600 files, so the store takes 14 values on each of 8,600 applications, being 120,400 field values a month, and it takes 34,400 document images alongside them. Somebody's declared monthly income is in there. So is the photograph they took of themselves at the front door of the application, and images of whatever they uploaded to prove who they are.

Two questions can now be asked of that store, and they are not the same question wearing different clothes.

The first is: who can read it? Access control is that question. Access control asks about people, and whatever else it produces, the answer is a list of names.

The second is: does all of that need to be in there at all? Data minimisation is that question. Data minimisation asks about the data, and the answer is a list of fields.

Access control is about readers and minimisation is about the data, and keeping the two apart is what makes either of them usable. Access control and minimisation are almost always discussed in the same breath, and fairly so: both defend the same thing. The two are still not one control. Each fails differently, each costs differently, and neither can be used as a substitute for the other.

A household has the same pair sitting in a cupboard somewhere. There is a folder of photocopies in it: the rent agreement, some old salary slips, a copy of a cousin's identity document that went with a loan application three years ago. Deciding who in the house may open that cupboard is access control. Asking why the cousin's document is still in the folder is minimisation. The first question is the one people ask. The second is the one that makes the cupboard smaller.

Why does an access list reach 214 people when the desk is 7?

At month 6, 214 people held read accessThe ability to see what is inside a record, as distinct from the ability to change it or to act on it. to that store. The exception desk whose job it is to work the files is 7 people. The store carries roughly thirty access holdersA named person who currently has the ability to open something, whether or not they have ever used it. for every person paid to look at what is inside.

Nobody decided that. Until the way an access list is built is clear, the number just looks like negligence. Access accumulates, it is not granted. No meeting at this bank ever agreed that 214 people should be able to read every applicant's income, identity documents and photograph. The list arrived one reasonable step at a time.

Here is how the count actually rises. Somebody moves from the credit function to a product team and keeps what they had. Taking it away is nobody's task, and raising it would be an odd thing to do to a colleague on their first week. A data migration needs a group of engineers to see the store for three weeks, and when the migration ends the group is not dissolved. Dissolving groups is also nobody's task. Two teams are joined and the merged group inherits the wider of the two accesses. A narrower merge would break somebody's Monday morning. A new joiner is added to a group that already carried the access, so now they carry it too, without one question ever being asked about them specifically.

Notice what all four have in common. Each one is a step up, and there is no mechanism anywhere in the sequence that produces a step down. ProvisioningThe act of granting somebody access to a system, usually with a request, an approver and a record. has a requester, a form and an approver, so it leaves a trail and somebody is answerable for what happens. Removal has none of those. Nothing triggers it. A person leaving the bank triggers a removal. A person changing what they do for a living does not, and that is the whole of the leak.

Which is why the shape is a staircase and not a curve, and why 214 is not, by itself, evidence that anybody did anything wrong. The number is evidence that nobody looked.

What is access control actually controlling, and at what level?

Now the harder half. Who can see it turns out not to be one question at all: access control operates at a level, and the level decides how blunt the control can possibly be. There are four of them, coarsest first.

Most arrangements sit on the first level. The first level is the one that ships with the system. At the store level there are only two answers available, so everybody whose work touches the chain in any way ends up holding the wide one. That is not laziness in the people granting it. A coarse control has no middle answer to give.

The fourth level is the one that gets forgotten, and at this bank it is the one that did the heavy lifting. A masked routeA way of seeing that a system is working without seeing what is inside it: counts, timings and errors rather than records. shows the machine instead of the contents: how many files are sitting in the queue, how long the reading step is taking, how many errors fired in the last hour, whether values are coming back at the rate they usually do. Every one of those is information about a system. Not one of them is information about a person.

Which gives a single question to put to every name on a list, and it is short enough to actually use: does this job need the contents of the file, or only evidence that the system is working?

What did the four numbered groups genuinely need?

Ashok Pillai, in technology risk, took the list of 214 and did the only thing that makes a list of 214 tractable. He stopped looking at people and started looking at groups.

Group 1 is the exception desk, 7 people. The desk works the 3,010 files a month that come to a person, and working a file means having the file: the documents, the values read off them, and what the chain did with each one. There is no version of that job that runs on a summary.

Group 2 is the credit function, 34 people. The credit function does not work files as they arrive, but it answers for decisions after the fact, and answering for a decision means being able to open the decided file and see what stood behind it. Their need is real and narrower than the first group's. The store level cannot express a narrower need.

Group 3 is technology support, 46 people. Technology support is the interesting group. Nobody on it is there by accident and its need is not imaginary: the job requires knowing whether the chain is running. The job does not require knowing what any applicant earns.

Group 4 is everybody else, 127 people, being 59.3 per cent of the list. Every one of them arrived by one of the routes in the previous section: a role held earlier, a group granted access once, a team absorbed into another. Not one of them was doing anything they should not have been doing.

7 plus 34 plus 46 plus 127 is 214. Sorting the names into four groups is what turns an impossible list into four decisions. Reviewing 214 people one at a time is a project somebody has to be funded to run. Answering four questions about four groups is an afternoon.

What happens when software has to be let in as a person?

Here is where an access list stops being an administrative chore and turns into a record problem, and the case that shows it is already running inside this chain.

The routing sequence at this bank includes a step that types into the core banking system through its screens. The core system has no other way of being handed an instruction. To type into a screen, something has to be let in. The core system knows exactly one way to let something in: it asks for a name and a secret, checks them, and opens. The core system has no notion of software asking to be admitted on its own behalf. So when that step was built it was given the credentials of a person on the operations desk. Those credentials were the only kind of key the door accepted.

Now set what the access list says beside what the record shows.

The access list says one named person on the operations desk holds credentials to the core system. The entry is correct, and it was correct on the day it was issued. The record shows that same name against all 8,600 of the month's decisions, including entries made at hours when nobody on the operations desk was working. And what that person actually did was log in once, on the day the credentials were issued.

The last part gets said carelessly, so say it precisely: that person did nothing wrong. They did not lend anything to anybody, conceal anything or take a shortcut to save an afternoon. A design that could only be admitted as a person produced a record that could only describe a person. The fault is in the design, and it does not sit on the operations desk.

The arrangement is missing a service identityCredentials belonging to a piece of software rather than to a person, so a record can name the software as the thing that acted., meaning credentials belonging to the software itself. Two things follow from not having one.

First, the access list was wrong in a way that no count would ever reveal. There were 214 holders, and at least one of those rows was not a reader at all. A count states how many names can open the store. A count does not state how many of those names are people.

Second, and this is the one that bites during a review: an access reviewA deliberate check of who currently holds access, run on a stated interval rather than when somebody happens to wonder. asks of every row, does this person still need this? For that row the question has no sensible answer. The honest answer is that the person never needed it and the software still does. A review that can only ask about people cannot review a row that is not a person, so the row survives every pass by default. The row that most deserves attention is the one row the review cannot touch.

The failure is worth naming for what it is not. Nothing extra was collected. The store held exactly what it always held, no more and no less. The whole of it is an access failure, and a clean demonstration of why minimisation would not have touched it. Keeping the two apart is not pedantry. Keeping them apart settles which control to reach for.

What did the review remove, and what did it leave?

Four groups, four decisions, and the decisions took the shape the question implied.

Groups 1 and 2 kept read access unchanged, 41 people between them. Group 3, the 46 in technology support, moved to the masked route, so they kept everything their job needs and lost nothing they were using. Group 4, the 127, was removed.

41 people held read access afterwards. From 214 that is 173 fewer, a fall of 80.8 per cent.

A fall of four fifths in a control everybody assumed was roughly sound reads, on first sight, as though the review uncovered something scandalous. It did not. Read the four groups again and every removal is obvious the moment the question has been asked. The finding is not in the removals; it is in how long the question went unasked. Section 9 of this bank's own policy on deployed systems required an inventory of what each use case consumes, and that inventory was not produced until month 11. For eleven months there was no document to hold the list of names against, so there was nothing for a reviewer to be diligent with.

Why did nothing break, and what does that say about the other 173?

Not one person reported being unable to do their work. Not one file was delayed, not one desk raised a request to have something restored, and nothing anywhere in the chain stopped.

There are two ways to read that, and the comfortable one is the wrong one.

The comfortable reading says the review was carefully judged and therefore everything is fine. The review was carefully judged. The uncomfortable reading is the true one. For months, 173 people could open every applicant's income, identity documents and photograph, and taking all of it away changed nothing that anybody noticed. Nobody was using it, then. And something worse follows: nobody would have noticed if somebody had been.

Access nobody exercises leaves exactly the same trace as access exercised wrongly. Both leave none at all. A quiet record is consistent with both. The silence is what makes an unreviewed list dangerous in a way that a badly performing model is not: a model that is getting things wrong eventually produces complaints, and a store that is being read inappropriately produces nothing until the day it produces a great deal.

Overstating the cost teaches badly, so be fair about it. There was no breach at this bank. Nobody read anything they should not have, as far as anybody can establish. The cost was carried risk: through those months the store's only real protection was that nobody happened to look, and a control that rests on nobody happening to do something is not a control at all.

What does Data Minimisation ask of a chain already running?

Everything up to this point has been about readers. Change the question completely.

Data minimisation asks two things about the data itself, and nothing whatever about who can see it. Is this collected, meaning does the value have to enter the store in the first place? And is this kept, meaning once it has entered and done its work, does it have to stay?

Notice what is not on that list. Minimisation never asks who may read a field, and access control never asks whether the field should exist. They are complementary because they act on different populations: one on the population of readers, the other on the population of values. A firm with superb access control and no minimisation is holding more than it needs, carefully. A firm that has minimised beautifully and never reviewed its lists is holding little, loosely. Both are needed, and only one of the two can make a problem go away rather than manage it.

The word carrying the weight in the first question is collected. Not shown, not displayed, not used. A value printed on a document the chain has to read is not collected merely by being on the paper. The value becomes collected the moment the reading step extracts it and writes it into the store, and that is a decision somebody took, usually by not taking it. The reading step was built to pull everything the form carried. Pulling everything is less work than deciding what to pull, and nobody has ever been thanked for a shorter extraction.

The same reflex turns up at a counter. A shop asks for a customer's full postal address before selling a shirt that is being carried out of the door. Nothing in the shop uses it. The address is on the form because the form was designed once, and nobody has removed a field from a form in living memory. The shop is not collecting the address for a reason. The shop is collecting it because the box is there.

Which gives minimisation, applied to a chain already running, one question with an answer nobody has ever looked up: of everything this thing collects, what is actually read afterwards?

How much of what the chain collects does it actually consume?

Somebody at this bank finally looked, field by field, and the split is worth setting out because it is not the split anybody expects.

Of the 14 extracted fields, 9 are consumedActually read by a later step and used for something, as distinct from merely stored where a later step could find it. by a later step in the chain. A step reads the value and does something with it: the identity match compares against it, the income rule computes with it, the scoring model weighs it, the router decides on it. The nine earn their place by being read.

Five do not. Of those five, 2 are needed to complete the application, meaning the form cannot be submitted without them although no later step reads them. 1 is needed only where the file goes to a person, read on the exception path and nowhere else. And 2 are consumed by nothing at all. 2 plus 1 plus 2 is 5, and 9 plus 5 is 14.

The argument usually goes wrong in practice on the middle three, so stop there. A field that no downstream step reads is not automatically a field to remove. Two of them are the price of a complete application. One of them is read by a person on files that reach the exception desk. A person reading it is a real use, even though no component ever touches it. Consumed by a later step and needed are two different tests, and minimisation run with only the first test takes away things people are using.

The last two are the different case entirely. Nothing reads them. No step, no person, no report. The two arrive on 8,600 files a month, so 17,200 values are collected every month and read by nobody, and they have arrived on every file since the chain went live.

What is to be done with the fields nothing consumes?

There are two answers here and the obvious one is wrong, so it is worth three minutes.

The reflex is to restrict access to them. Lock them down, mask them, put them behind a tighter permission. Restricting access solves nothing. The field still exists, so it still needs a rule saying who may read it, still occupies a row on every review from now until somebody removes it, still needs a retentionHow long something is kept once the work it was collected for is finished. decision, still needs a recorded basis, and still needs a line in an inventory that somebody has to keep true. Tightening the permission adds an obligation in order to manage a value that nobody wanted.

The other answer is to stop collecting it. A field that was never collected cannot be read by 214 people, or by 41, or by anybody at all, and removing it ends three recurring obligations outright rather than managing them for ever. At this bank the two fields were removed at month 12 and no downstream step noticed, exactly as the review predicted. Consumed by nothing means precisely that.

So that this does not read as recklessness, here is the check that goes in front of a removal, in order.

Step 4 is the one that gets dropped, and dropping it leaves half a job looking like a whole one. Stopping the collection stops the inflow, a good day's work and easy to announce. The store still holds every value collected before the change, on every file since go-live, and what happens to that has to be decided explicitly, in the same breath, or it will not be decided at all.

There is a quieter saving underneath. Each field the chain consumes carries eight documented items, a grid settled elsewhere and taken as given here: 14 fields against 8 items is 112 cells somebody has to keep true. Taking out two fields takes out 16 of those cells, being 14.3 per cent of the grid, permanently and without anybody having to maintain the removal.

What does minimisation remove that access control cannot?

Take a single field and list what it obliges the firm to do for as long as it exists. A rule saying which named people may read it. A row on every access review, for ever. A decision about how long it is kept. A recorded basis for holding it at all. A line in an inventory somebody has to keep true.

Now tighten access on that field. Read the list again. The first item changed from many names to few names. Every other item is exactly where it was, and the first item is still there, still needing somebody to look at it every quarter.

Now remove the field instead. All five go, and they go permanently, and nobody has to maintain the removal.

The asymmetry fits in one line: access control manages an obligation and minimisation ends it. The asymmetry is also why minimisation is the cheaper control and the one that gets done last. Tightening access is visible, satisfying and finishes inside an afternoon. Removing a field means first finding out what reads it, and nobody has written that down. The inventory at this bank arrived eleven months after the chain went live instead of before it, for precisely that reason.

Minimisation has a limit, and the limit is what keeps both controls honest. Minimisation cannot help with a field that is genuinely needed. The 9 consumed fields are not going anywhere: every one of them is read by a step that would stop working without it, and for all 9 the only available control is who can see them. Minimisation clears the ground so that access control has a smaller job to do properly. Nine fields and 41 names is a control a firm can actually run. Fourteen fields and 214 names is a control a firm can only describe.

How often does this get looked at again, and what does one pass cost?

Both controls decay. Names accumulate again the moment the review ends, and new fields arrive whenever a document changes. So the real question is not whether to do it but how often, and that turns into a cost.

Sumeru Bank's own rate is 6 minutes to review one person's access: pull up what the role requires, look at what the person holds, decide. The 6 minutes assumes the reviewer can see what the role requires, and what the role requires is itself a record the bank had to build. Without that record the 6 minutes is a guess wearing the clothes of a rate.

At 214 holders, 214 times 6 is 1,284 minutes. At the assumed 420 minutes a person a working day, that is 3.06 working days a quarter. At 41 holders it is 246 minutes, being 0.59 of a working day. In money, taking the bank's own assumed fully loaded Rs 9,00,000/- a year for one post across its 20 working day month, being 240 working days a year and Rs 3,750/- a working day, the quarterly review costs about Rs 11,464/- at 214 holders and about Rs 2,196/- at 41. Both money figures are arithmetic on the bank's own assumptions rather than a second measurement, and they are stated as illustration.

Now the part worth stopping on. Minutes are holders times 6 and nothing else, so the relationship is a straight line through zero, and cutting the holders by 80.8 per cent cuts the recurring review cost by exactly 80.8 per cent. Almost no control gets cheaper the better it works, and this one does. A monitoring check costs the same whether it finds anything or not. A reconciliation costs the same on a clean day as on a broken one. An access review bills by the length of the list, so shortening the list and cutting the standing cost of the control are the same act.

A control that gets cheaper the better it works is the argument that gets a review put in a diary rather than promised in a policy. The interval is a separate choice: this bank chose a quarter, its own decision and not anybody's requirement.

How does an auditor, a buyer or a household actually use this?

An internal auditor starts with two counts, and the opening move costs nothing. Two numbers come before anything else: how many people can read the store, and how many people work with what is inside it. At this bank that was 214 against 7. Two numbers like that are not a finding on their own, but they are what produces one. Next comes a single row of the list, picked at random, and why that name is there. If the answer is a role the person no longer holds, the list has never been reviewed, and the count is the least of what has been found.

Somebody assessing a supplier asks the same two questions across the boundary, unchanged. How many of the supplier's people can read what is sent to them, and what is being sent that they never consume? The second is the one buyers almost never ask, and it is the cheaper one to fix. The fix sits on the buyer's own side of the wall and renegotiates nothing. A field that is no longer sent is a field nobody at the supplier needs a rule about.

A lender or an operations head reads the two numbers as a cost as well as a risk. A store with 214 readers is carrying a quarterly obligation of three working days for as long as the list stays that long. Shorten the list and the obligation shortens with it. The safe answer and the cheap answer are the same answer, and that is rare.

And a household runs both controls, badly, like everybody else. The first habit: whose keys, cards and passwords are still live that no longer need to be? Nobody has ever taken a spare key back from a neighbour who watered the plants one summer. The second habit is the stronger one: what does the household hold copies of that it never looks at? A photocopy of somebody else's identity document, kept for one application three years ago, is a field consumed by nothing. Deciding who in the house may see it is the expensive answer. Not having it is free.