Home / Knowledge hub / Need to know
Knowledge hub
Need to know
Limiting information to the people whose work actually requires it.
What it means
Need to know sends information to the people whose work requires it, rather than to everyone who could be trusted with it. Trust is not the test. The test is whether the job can be done without the data.
The idea comes from classified handling, where a clearance on its own grants nothing. As the NIST glossary puts it, somebody who already holds the information decides whether a recipient needs it to carry out their duties.
Why it matters
Every extra person holding a record is another laptop, another inbox and another account somebody can phish. The exposure grows with the size of the audience, whatever anyone intends.
It also keeps incidents small. A support team that sees order histories but never full card numbers cannot lose card numbers. The cheapest protection available is for most of your staff and most of your systems never to hold the data at all.
How it shows up
Inside an application this means decisions at field level rather than page level. A support agent confirms the last four digits of a card. An analyst counts customers in a region without reading their names and addresses.
The leaks are predictable. Spreadsheet exports, admin tools built in a hurry that show the entire record, production data copied into test, reports emailed round the company. Mask by default, reveal on a specific logged action, and enforce it on the server. OWASP is blunt about that last part: never rely on a check that runs in the browser. See how we walk role against resource.
Questions people ask
Need to know, answered
Is need to know just another name for least privilege?
They overlap and they are not the same. Least privilege asks what an account may do, across systems, services and machines. Need to know asks what a person may see.
In practice you use both. Need to know decides whether somebody gets near the data; least privilege decides what they can do once they are there.
If somebody has the right role, why hold information back?
Because a role says a person is allowed to see this kind of data, not that this particular record is any of their business. A support agent handles tickets that reach them, not the whole customer table.
The point is to discourage browsing, which is where most internal misuse starts.
Does this only apply to classified information?
No. The language came from government, and the principle transfers directly to ordinary products. Customer records, salaries, medical notes and identity documents all deserve the same treatment.
If anything it matters more in a commercial application, because far more people log in.
How do we apply it without stopping people doing their jobs?
Mask by default and make the full value available through one deliberate action that gets logged. Almost every support task needs the last four digits, not the whole number.
When someone does need more, they get it, and you have a record of who looked and why.
Who decides what somebody needs to know?
In classified handling it is whoever holds the information. In a product it is whoever owns that data, usually with the team lead who knows what the job actually involves.
What does not work is leaving the decision to whoever built the admin screen, because the quickest thing to build is the one that shows everything.
Sources
Where this comes from
Related
Terms that sit next to this one
Least privilege
Giving every person and service the minimum access the job requires.
PII
Any data that points at a specific human being.
Access control
The rules deciding which person can see or do which thing in your app.
Tenant isolation
What keeps one customer's data unreachable from another's session.
Data breach
Information you hold ends up somewhere it should not be.
Which fields does each role see?
We sign in as every role you have and record which records and fields came back, with the request behind each one. That grid is usually the surprise. Ask about a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.