Security & Access · Software Insight

The leak that was a permission

Most data incidents do not involve an attacker; they involve permissions that were too broad. A folder shared with ‘everyone’ three years ago, an account for someone who left, a report emailed to a list that has since grown. Information was available to more people than anyone would have chosen.

A quarterly review, recorded, with a named approver on every line

Why permissions accrete

Access tends only to be added, not removed. Someone needs a file for a week and keeps access after the week ends. A role change adds responsibilities and keeps the old ones. A shared login survives its contract by years. These are not deliberate decisions; they are the absence of a scheduled reversal.

Permissions as part of the data model

Permissions are part of the data model, not an afterthought. Three principles are built into Insight Docs and Insight Care: grant by role, not by person; default to least privilege; and log retrieval as well as change. Disposal surfaces what is due for review and a human confirms.

What to do about it, whatever you buy

Run a quarterly access review, not an annual one, and make it a document: who has access to what, who approved it, what changed since last time. Delete accounts the week people leave — the offboarding checklist should include every system by name, not ‘IT to action’. Separate the roles that should never be combined, particularly the ability to create a supplier and the ability to pay one. And keep sensitive material out of general-purpose shared drives entirely; a folder with forty permissions is not a controlled location, whatever the folder is called.

Fast exceptions

Tight controls that block work get switched off. The fix is to make the exception fast: a request that is logged, approved by the record owner, time-limited, and expiring on its own. That gives the audit trail without slowing the work.

Questions this view raises

How much logging is enough?
Enough to answer three questions without an investigation: who changed this record, who retrieved it, and what did it look like before. Change history covers the first, retrieval logging the second, and version history the third. Log retention should follow the same schedule as the records themselves — a log of who read a file is itself a record about a person, and it deserves the same discipline as the file.
Does least privilege make everyday work slower?
Only when the exception path is slow. Least privilege with a fast, logged, time-limited override is quicker in practice than broad access with ad-hoc restrictions, because the request is a single decision by the record owner rather than a negotiation. Where it does slow work, the answer is usually better role design: most friction comes from roles drawn too narrowly around an old org chart rather than from the principle itself.
Where this shows up in our software

Insight Docs and Insight Care grant access by role and log retrieval as well as change. You can see these principles applied on the projects pages and throughout the InsightSuite module pages.

« All Insights Next Insight »