Document Access

Who Can Read a Document

A document has no permission list of its own. Who can read it is worked out from the records it is attached to — and then checked against its classification.

Where to find it

Architect Panel → Security:

• Document Access — what was read, and what was refused

On a document, the Sharing panel shows every route by which somebody reaches it.

The union rule

If you can read any record a document is attached to, you can read the document. Not all of them — any of them.

That is the right model for casework and it is the one thing to understand before attaching anything. A survey on a planning application and an enforcement case is readable by both teams, and that is a feature rather than a leak: it is why the file exists once instead of twice.

Classification is checked first, and separately

A document can carry a classification level, and a level can demand a clearance. That check runs before any route is considered, so no attachment and no grant reaches past it.

The ordering is the security property. Were it the other way round, attaching a classified document to an open case would be a way to launder it — and it would look like a feature.

Reading and downloading are different

A classification can permit reading and forbid export: the content may be looked at and must not leave. That distinction is enforced at the download, which is the one place it can be.

An inline preview is a download. The browser has the file either way, so a preview is offered only where a download would be.

A document with no links

Readable by the person who created it, by anybody granted it, and through the library. That is narrower than most people expect, and it is the safe direction — an adopted file store document or an unlinked upload does not quietly become public.

Every refusal says the same thing

“No such document” and “you may not see this document” are the same sentence, deliberately. Two different answers would let somebody find out which document IDs exist, and roughly how sensitive each one is, by trying them.

Worked example

A safeguarding report is attached to one restricted case and classified. A colleague on the general enquiry that led to it cannot read it — no route — and somebody with a route but no clearance cannot read it either. The Sharing panel on the document names both facts, so the manager can see which one to fix.

Recommendations

• Think of attaching as granting, because it is.
• Classify the document, not the record, when it is the content that is sensitive.
• Check the Sharing panel before assuming somebody cannot see something.
• Use export-forbidding levels sparingly — they stop share links and off-site OCR as well as downloads.

Sharing With One Person

Sometimes one person needs one document and has no business seeing the case it is attached to. A grant does that without widening anything.

Where to find it

On a document, the Sharing panel — administrators only. It lists existing grants, live links and every route by which somebody reaches the document.

Why it exists

Before grants, the only way to let the auditor see a contract was to attach it to a record they could read — which gave them everything else on that record too — or to e-mail a copy out of the system entirely. Both are worse.

A grant adds. It never subtracts.

The union rule is the floor. Somebody who can already read a linked record still can, whatever the grants say, and there is deliberately no “deny”.

A deny would make the answer to “can this person read it” depend on the order two rules were evaluated in, and the first time that produced a surprise it would be a disclosure or a refusal nobody could explain.

It cannot reach past a classification

Clearance is tested before any route, so granting a document to somebody without the clearance for it does nothing at all.

Read is not download

A grant is read or download. A read grant lets somebody look and not take a copy, which is the entire point of lending a document to an auditor.

It caps the download only where the grant is that person’s sole route. Somebody who can already reach the document through a case they work on is not made worse off by also being granted it.

A team, not just a person

A grant to a security group follows the group: somebody joining it gains the document and somebody leaving loses it, with nobody reissuing anything.

Revoked, not deleted

Revoking records when and by whom, and the row stays. “Who could see this, and between which dates” is the question after an incident, and a deleted row answers it with silence.

An expiry date does the same job without anybody having to remember.

Worked example

An external auditor needs three contracts from a procurement case they are not on. Each is granted to them at read with a six-week expiry and a reason. They can open all three and download none, the grants lapse on their own, and the register still shows the arrangement a year later.

Recommendations

• Always set an expiry for anything time-boxed. It is the only control that works unattended.
• Write the reason. Afterwards the question is never “was there a grant” but “why”.
• Grant to a team when the answer is really a role.
• Prefer a grant to an attachment when only the document is meant to be shared.

Share Links

A link that opens one document for somebody with no account — expiring, revocable and limited by number of uses.

Where to find it

On a document, the Sharing panel → Create link. The link is shown once and cannot be shown again.

Shown once, on purpose

Only a hash of the token is stored, so there is nothing to show you later. Copy it when you create it; if you lose it, revoke it and make another.

Three things checked before any bytes move

• Is the token real, unexpired and unspent?
• Is it for this purpose? A token minted to do something else must not open a document because somebody pointed it at this endpoint.
• Does the file it names belong to this document? Without that last check, a link to one document is a link to every file in the system by changing one number in the URL.

A use is consumed before the file is served

So a link with two uses is worth two downloads, whatever happens afterwards.

What minting refuses

• A document whose classification forbids export. “May be looked at, must not leave” — and a share link is the most complete way of leaving there is. Refused when you create the link, where you can do something about it, rather than at the door.
• A document that lives in a file store. The store has its own permissions resolved from the caller’s security groups, and a token holder has none. Adopting one file out of a store must not become a way round somebody’s decision about a whole library.

Downloads through a link are logged

As a link rather than as a person, because that is what is known. A link opened forty times from three countries is visible in the access log.

It is still the whole document

A link is not a redaction. Whoever has it has the file, including any version history the link exposes. For anything that needs less than the whole document, send an extract.

Worked example

A surveyor with no account needs the site plan. A link is created with a seven-day expiry and two uses, pasted into an e-mail, and forgotten about. It stops working on its own, the access log shows it was used once, and nobody had to create an account or remember to tidy up.

Recommendations

• Shortest expiry that works. A week is generous.
• Few uses. One or two covers a genuine recipient and not a forwarded e-mail.
• Revoke when the job is done rather than waiting for the expiry.
• Check the access log if the number of uses looks wrong.

Who Has Access to This

The first question anybody asks after an incident, and until recently one the platform could not answer at all: who can see this document, and how?

Where to find it

On a document, the Sharing panel. Below the grants it lists every route to the document.

What it shows

• The creator, named exactly.
• Grants, named exactly, with their level and expiry.
• Live share links, with what is left of them.
• Each linked record, and the teams holding Read on that record’s datastore, by name.
• The classification, reported separately as a cap rather than as a route.

Routes, not a list of people

It deliberately does not enumerate the members of every team. A named list of everybody who could open a document is a different and more sensitive artefact than a list of the doors, it is out of date the moment somebody changes team, and it invites the reader to believe it is complete.

The doors are the thing you can actually change.

The classification is a cap, not a door

Shown apart from the routes because it does not grant anything. It only ever narrows what the routes allow, which is why it reads as a separate line.

Use it before sharing, not only after

The panel is most useful before attaching a document to another case: it shows what access already exists, so you can see what you are about to add to.

Worked example

A manager is asked how a valuation reached a contractor. The Sharing panel shows one grant to a named person that expired last month, one live link with one use left, and two linked records — one of which is a case the contractor’s team can read. The answer is the second record, and it took one screen rather than a week.

Recommendations

• Check it before attaching a sensitive document to an additional record.
• Treat a long route list as a finding. A document reachable six ways is usually attached to something it should not be.
• Revoke what the incident found from the same panel.