Who may access is no longer the only question

Picture an account that has worked quietly for months. It belongs to an intern or to a service, reads a few tables, exports the odd report, nothing special. Then someone uses that very account to run a single query and pulls the entire customer database. Technically everything was allowed. The account was permitted to read, and read it did. And yet, in that moment, damage may well have been done that plain access control could not stop.

Stories like this are not the exception. What makes the insider so hard to catch is that they leave no trace that looks like a break-in. No forced login, no firewall torn down, no alarm going off. Every single step stays within what the account is allowed to do and, taken on its own, paints a clean picture. Only the sum adds up to harm, and nobody sees that who looks only at the permission. Now that AI helpers are moving into internal workflows, this gains new force, because the same rights are suddenly exercised with a very different reach.

The question "who may access this?" answers who gets to the data. It says nothing about what they then use it for.

That is where the real gap sits. We have learned to tie access to identities: this person, this role, this service may see or change this record. That is right and stays necessary. But it answers only half the question. Whether the use matches the purpose we once collected the data for is on another page entirely, and few keep that page.

Why the AI helper changes the maths

The new tools in the building work in the context and with the permissions of the person operating them. So they hold the same rights, but far greater ability to do things fast and at scale. An account that was utterly harmless for a single human for years takes on a different weight the moment an assistant sits behind it and sweeps across the whole data set in seconds.

The uncomfortable part is that no attacker needs to be at work here. All it takes is a helpful assistant that reads a task too literally and, to answer a harmless question, scans half the database because nobody told it not to. The limit used to lie in human inertia, in the fact that a person does not casually eyeball ten thousand records by hand. That inertia falls away, and what remains is the question of whether the use was ever intended at all.

Suddenly questions are on the table that were comfortable to leave slumbering in the background. Who actually consumes the data across all those new internal tools, which values do they build their results on, and do those fields still mean there what they meant when the data was collected? You can only answer that if you know where the data came from.

Do you know what you are looking at?

Anyone who uses data needs its origin, its provenance. That sounds academic but means something very practical: knowing what you actually have in front of you before you build a decision or an automated result on top of it. Four questions capture it.

• How is this value composed? Does it come straight from one source or is it computed from several, and through which steps? That is the line of origin, the lineage.
• How current is it? A value from this morning and one from six months ago look identical but carry very different trust.
• What was the purpose of collection? An address gathered for shipping is not automatically cleared for marketing scoring.
• By which definition? A status field only means something if everyone who reads it understands the same thing the person who once filled it did.

The last question is the most treacherous, and it shows itself in an everyday moment. You search the database for a new report and find a field "active" that seems to fit exactly. With an assistant like Claude the automation on top of it is built in half an hour, and it delivers neat numbers right away. What you do not see: for the person who maintains that field, "active" does not mean what you assume. Perhaps it means "seen in the last 24 hours" and only holds together with a second field; perhaps that owner changes the meaning at some point without ever telling you, because they have no idea anyone is building on it.

From then on your fine automation runs on an assumption that was never true or has quietly shifted. The business process that decides on these numbers turns from a helper into a hazard, and the tricky part is the reach. It is the game of Chinese whispers: every station passes on, in good faith, what it believes it understood, and nobody lies, yet something different arrives at the end than at the start. The moment another tool or a colleague builds on your result, the misunderstanding travels transitively down the chain until nobody can say which original meaning the whole thing even rests on. Schema drift is therefore no longer a mere database problem but the question of whether a whole chain of machines still speaks the same language, and it is precisely the well-meant, uncontrolled downstream use that makes it dangerous.

The question access leaves open

Once you know the origin, the security question shifts almost on its own. It moves away from plain access control towards purpose-bound use. No longer just "who may reach this record", but "for which purpose may this record be used, and does the current use fit it".

This is not a new idea; the GDPR calls it purpose limitation. What is new is that it is becoming technically tangible. As long as only humans worked with the data, purpose limitation stayed largely a matter of trust and spot checks. With machines running against defined rules, the question "does this use match the stored purpose" can be asked at the very spot where the access actually happens.

That means read access has to be taken as seriously as write access. Whoever may change something is usually watched, because a wrong write leaves a visible trace and most logs record what was changed and why anyway. A read, by contrast, changes nothing, shows up in no change log, and is exactly for that reason the more convenient route for a leak. Anyone who wants to govern use has to record reading with the same care as changing, and not just that something was read, but what and what for.

In practice that means stamping every access with the same set of details, whether it reads or writes: who, what, what for, and when. This creates a complete access trail, a log that records every single access together with its purpose. The "what for" field is the decisive one, because only the recorded purpose answers later whether an access matched what was actually allowed. An export logged with the purpose "invoicing" can then be told apart from an export with no purpose behind it at all, and it is exactly that distinction you need when it matters.

A trail like this allows one more thing: spotting when an access steps out of line even though, on its own, it was allowed. An account that makes the same handful of queries for weeks and then suddenly combs through half the data set is a signal, long before any damage shows up on the balance sheet. Oddity runs in both directions, because just as telling as the sudden spike is the silence: an access that held a load-bearing role and goes quiet all at once is either broken or being bypassed.

That silence carries a second meaning that is easy to miss. If you make decisions on a value that another process keeps current, your analysis depends on that process running. If it stalls, you keep working on stale data without noticing, and that can distort your conclusions just as badly as a misread field. It gets especially tricky when the updating process is not even yours, because then you are relying on something whose standstill you cannot see yourself. So monitoring is not only the question of whether someone accesses too much, but also whether the suppliers your data lives on are still delivering at all.

You already have the answer

Here something comes into play that many already have without lifting its value. Anyone who processes personal data usually keeps a record of processing activities (an ROPA, required under Art. 30 GDPR), and in an ISMS modelled on ISO 27001 that same inventory is the central building block. It lists which data is processed for which purpose, for how long, and on which legal basis. Exactly the details, in other words, that provenance and purpose limitation need.

The problem is rarely that this record is missing. The problem is that it sits as a Word document in a folder, written once for an audit and then overtaken by reality. It describes a state the system perhaps never truly had and certainly no longer has.

A dead document like that satisfies the form but not the purpose it is actually there for. And it does not reliably survive the audit either, because a serious ISO 27001 audit asks first and foremost not whether the documents are complete, but whether the described measures actually work. Completeness is the entry ticket; what gets tested is effectiveness. A record of processing with no connection to live operations is exactly where that shows.

We describe the same pattern for rules and reporting paths in the article Compliance that answers in everyday work: a rule does not become effective by existing, but by having its knowledge within reach at the decisive moment. The same holds for the record of processing, and the solution runs in the same direction.

From a dead document to a living picture

The bridge from the filed-away document back into live operations can be built today with AI support, in exactly the direction AI is strong: reading, comparing, making deviations visible. An assistant with read-only access can hold the stored inventory against the real database schema and flag where the two drift apart. A new field nobody entered. A field that should long since have been deleted. A table whose purpose is written down nowhere.

That turns the rigid snapshot into something that grows along with the database. And once this picture is accurate, it stops merely documenting. It becomes an instance that hands the access logic a second piece of information it never had before: not just who is reading, but what for. What you can build on that is the genuinely interesting part.

Where the data travels next

Whether an account may read something is one layer. What happens with what was read afterwards, which system processes it on, and whether its understanding still matches the original meaning, is an entirely different one. An access rule ends at the moment of reading. About the journey a record takes after that it says nothing, and it is precisely that journey that decides the damage.

Separate the two layers cleanly and a room opens up that the plain access question never had. It shows itself most clearly when you distinguish whether someone is exploring something new or whether a finished process is doing its work. A CRM with your customer data shows both side by side.

In exploration a human genuinely has to see the data. A sales rep deciding which customers should receive a new newsletter filters by revenue, by contract details, by behaviour. That is her job, and for it she needs rich access, gladly with an AI assistant at her side, as long as the data is cleared for exactly this purpose. Worth noting is what does not belong here: the email address. Nobody needs it to make a selection, so it is not cleared for this purpose. What stands at the end is a selection, a decision about which customers get contacted, not their inbox.

The sending itself is then no longer an exploration step but a finished business process, and it looks completely different. It cannot be that the sales rep pulls all the email addresses onto her machine and sends from there. The sending step runs server-side and receives exactly the fields it needs now, name and email of the selected customers, and nothing else. The address therefore appears only where it is genuinely needed, and the step knows nothing of revenue and nothing of contracts, because those fields are never handed to it.

That is the gain of a clean separation. The send never gets to see revenue and contract, so it cannot give them away either. And because the selected recipients stand fixed as part of the process, nobody can accidentally grab the wrong list. Security then sits in the way the process is built, and does not hang on everyone involved behaving correctly at all times.

Out of exactly this grows a capability that counts beyond the single example: modelling and running server-side process steps cleanly, instead of routing every flow through a human's working environment. Exploration stays with the human and their tools; the recurring process moves behind them, where it only sees the fields it needs for its one purpose.

That tips the whole logic of security. A purpose-bound rule is not an extra lock that shuts things a little tighter. It is more like a valve that lets through things you would previously have forbidden wholesale, because you can now name exactly under which condition and with which fields they are fine. A new tool that would otherwise have foundered on the data-protection question gets a clearly outlined corridor to work in, and everything outside stays shut.

That also shifts what the ISMS is good for. It no longer serves to withhold a clearance at the end, but to describe in advance the corridor in which a new process can get going straight away. The clearance then no longer hangs for weeks in a mail loop, because the condition is already formulated and the check happens automatically. Security and speed do not stand against each other here; they come from the same source, because the same stored purpose carries both.

What this means for you

The question of who may access stays important, but it no longer suffices on its own, and it probably never did. The moment an account is not just a human but an assistant with great reach behind it, the damage is decided not at the access but at the use. Anyone who wants to govern use has to know what their data consists of and what they once collected it for, and an ISMS already carries exactly those details, usually just in the wrong place, namely dead in a document.

Bring that knowledge to life, and security gains a second option alongside the blanket ban: describing a clearly outlined path on which a venture may work, while everything beside it stays shut. That makes some things possible that would otherwise have been dropped as a precaution, without lowering security.

The way there does not start with a big project but with a question about your own holdings: where does your most important data come from, and do you still know what you collected it for? If the answer sits in a Word document nobody opens any more, that is where your lever is. A record of processing that runs along with operations turns the access question into a use question, and that bridge between your ISMS and your live operations is one we are glad to build together with you.