Do we need a dedicated system, or are cloud folders enough?

Folders are enough when the structure is stable and the team is small, provided identity documents live in a separate folder with a short access list. A system becomes necessary when you need field search, version history, permissions derived from client relationship, and a report of who accessed what - four things folders do not offer.

How do we handle a document relevant to two clients?

Store one copy with its own identifier and link it to both clients through a relationship table. Permission is evaluated against the relationship the user arrived through. Duplicating the file into two folders creates two versions that drift apart, and deleting one has no effect on the other.

What do we do with email correspondence relevant to a file?

Store only material decisions and documents, as an item with a correspondence `class` and a date, rather than the whole mailbox. Storing everything makes search worthless and widens exposure for no benefit. What counts as material should be a rule defined in advance, not a per-message judgement call.

How many document classes is too many?

Above eight to ten, misclassification sets in: people cannot remember where a document belongs and pick the first entry in the list. A small number of classes with a `doc_type` field inside them works better, because the types can be extended without touching the permission model.

A Digital Client File: Structure

A digital client file is not a folder named after the client that every file gets dropped into. It is a set of document classes, each with its own metadata, its own readership and its own lifecycle. The moment quotes, contracts, scanned identity documents and collection letters sit at the same level, you cannot narrow access without blocking work.

A client file is a set of classes, not one folder

A class is a document type that behaves differently from the rest in three ways: who needs to read it, which fields describe it, and when it stops being relevant. A typical service business has six to eight classes, not more:

Class	Example document	Identifying fields	Who needs to read it	What ends it
Commercial	Quote, signed contract	Quote number, version, signature date	Sales, management	End of the engagement
Financial	Invoice, receipt, transfer confirmation	Document number, amount, date	Bookkeeping	Per the firm's own policy
Identity	Scanned ID, bank account confirmation	Document type, capture date	A short list named explicitly	End of the purpose it was collected for
Operational	Specifications, working files, deliverables	Job ID, version	The project team	Job closure
Correspondence	Emails carrying material decisions	Date, participants, subject	The project team	Job closure
Collections	Debt letters, payment arrangements	Debt number, status	Collections, management	Debt closed

The third row is the one that needs handling separately. Identity documents are collected for a specific purpose - opening an account, verifying a payment beneficiary - and there is usually no reason for them to stay reachable by everyone who works with that client afterwards. Mapping where personal data lives across a business at all is covered in the personal data map for a small business.

Why is the filename the weakest identifier in the file?

Because it is the only thing in the file that anyone can change and nobody has committed to a format for. final quote final 2 (1).pdf is not an identifier, and neither is 2026-04-12_cohen_quote.pdf once somebody downloads it and re-uploads it.

The structure that works keeps identity in metadata and treats the file as content only:

client_id - a numeric identifier, not a name. Names change, identifiers do not.
class - one of the predefined classes, from a closed list.
doc_type - the type within the class: contract, receipt, spec.
version - an incrementing number. A new version never overwrites the old one.
state - draft, active, superseded, closed, archived.
source - email, manual upload, scan, digital signature.
uploaded_by and uploaded_at - who brought it here and when.
linked_job - a job identifier, where one exists.

The filename stays for convenience only. Search runs on the fields, which turns "every signed contract for an active client in the last quarter" into a query rather than a request for somebody to dig through folders.

Who should be able to open a document, and how is that decided?

A permission in a client file is two distinct mechanisms that are frequently collapsed into one by mistake:

Role decides which document classes the user may see in principle. A collections clerk sees financial and collections; a designer sees operational.
Relationship decides which clients. Assignment to an active project, ownership of the client record, or an explicit staffing entry.

Effective access is the intersection of the two. Role without relationship lets one designer open every client file in the company; relationship without role lets anyone staffed on a project read the identity documents too. Two supporting mechanisms complete the picture:

Time-boxed access with an expiry date, for an external supplier or a covering employee. Without an expiry it becomes permanent within a fortnight.
Logged exceptional access - a manager opening a document they are not staffed on, recorded with who, when and what. This beats a hard block that people route around by downloading to a personal laptop.

What does a document lifecycle look like inside a system?

As a state machine where every transition has a defined trigger, rather than a date somebody remembers:

State	Meaning	What moves it on
Draft	Created, not yet approved	Approval or sending to the client
Active	The currently valid document	A new version, or the engagement ending
Superseded	A newer version exists	Stays readable, never editable
Closed	The engagement or job has ended	The period defined in policy elapsing
Archived	Out of everyday search, retrievable on request	A decision under the policy
Marked for deletion	Awaiting an owner's approval	Execution and logging

The last state exists so that deletion is never a silent event. Deletion removes the content and leaves a record saying that a document of a given type existed and was deleted on a given date by a given person. Without that record you can never explain why a file looks incomplete. The financial side of the same question is covered in a digital archive for bookkeeping documents.

The periodic review that shrinks exposure

Users with broad access that does not follow from their role.
Time-boxed permissions past their expiry date.
Duplicate client records, each copy carrying different permissions.
Identity documents still stored after the purpose they were collected for ended.
Files sitting outside any defined class, and therefore outside every access rule.
Accounts of departed employees still attached to projects.
External share links with no expiry.

This list is a report, not a manual task. If it does not run automatically once a quarter, it does not run. The consequences of holding personal data in spreadsheets are discussed at length in customer spreadsheets after Amendment 13.

What actually breaks

Downloads to personal machines. The permission in the system is precise; the copy on a former employee's desktop is not.
An open share link. Created for one meeting, still live two years later, and appearing in no permissions report.
A folder named after the client. A client that changes name produces a second folder, and from then on half the documents are missing from search.
A scan with no class. A document captured without a class falls outside every access rule and every deletion rule at once.
A version that overwrites. A contract re-uploaded under the same name erases what was there, and two months later nobody can tell what was signed.
A permission granted to a person. The employee changes, the permission stays personal, and the replacement has no access until somebody remembers.

Sources

Israel Privacy Protection Authority

A Digital Client File: Structure That Lets You Find a Document Without Giving Everyone Access to Everything

Key takeaways