When someone forms a company through a service like ours, they hand over a passport scan, a proof of address, and in time a set of corporate documents that collectively describe who controls a legal entity. That bundle is more sensitive than most of what a typical SaaS application stores.
This post describes how we think about protecting it. It is deliberately practical rather than aspirational.
Start by drawing the boundary in the right place
The instinct in most applications is to treat the perimeter as the security boundary: get past login, and you can see what the application shows you.
For document workflows that is the wrong boundary. The right one is the document itself. Every read of a corporate document should be an event that is authorised and recorded, whether it comes from a customer, a staff member, or another system.
Once you accept that, several design decisions follow.
Storage: encrypt, but be specific about what that buys
"Encrypted at rest" is close to meaningless on its own, because it can describe anything from full-disk encryption on a server to per-object encryption with a managed key.
Full-disk encryption protects against one thing: someone physically obtaining the disk. That is a real threat, and it is not the most likely one. The more likely failure is a compromised application account or a misconfigured storage bucket, and disk encryption does nothing about either — the application reads the plaintext quite happily.
What is worth doing:
- Encrypt objects individually, with keys managed outside the application.
- Keep the key-management boundary separate from the storage boundary, so a storage compromise is not automatically a key compromise.
- Log key usage. A spike in decrypt operations is a signal you want.
Delivery: no permanent links
The most common way a document leaks is not a breach. It is a link.
A URL that permanently resolves to a document is a bearer token in disguise. It gets forwarded, pasted into a support ticket, saved in a browser's history, and synced to somewhere nobody thought about.
Controlled delivery means:
- No permanent public URL. Access goes through a request that is authorised at the moment of access.
- Expiry. Any temporary link has a short life and is single-purpose.
- Explicit permission per document, not per account. Being a customer does not mean being entitled to every document associated with the account.
- Recorded access. Who opened what, and when.
The last point is the one people skip, and it is the one that matters most after an incident. Without access logs you cannot answer the only question that will be asked: what was actually exposed?
Roles: model what people do, not what they are
Role-based access control tends to drift toward a handful of coarse roles — admin, staff, customer — because that is easy to implement. The result is that most staff accounts accumulate far more access than any single task requires.
A more useful model starts from tasks. Someone reviewing an identity document needs to see that document for the case they are working on. They do not need to browse the archive. Scoping access to the case rather than to the collection removes an enormous amount of standing risk.
Two rules that are worth enforcing:
- Access is granted for a purpose and a scope, not as a permanent property of an account.
- Elevated access is temporary by default and expires without anyone having to remember to revoke it.
Retention: deleting is part of the design
There is a strong pull toward keeping everything. Storage is cheap, and deleted data occasionally turns out to have been useful.
But documents you no longer hold cannot be exposed. Retention is a security control, not just a compliance obligation.
That means deciding, per document type, how long you actually need it — driven by the purpose it was collected for and any record-keeping duty that applies — and then implementing deletion as an automatic process rather than a periodic clean-up somebody remembers to run.
Backups: the copy you forgot to protect
Backups are frequently the weakest link, because they are designed for recoverability and recoverability is the opposite of restricted access.
The questions worth answering honestly:
- Are backups encrypted with a different key than production?
- Who can restore one, and is that action logged?
- Does the retention policy apply to backups, or do deleted documents persist in them indefinitely?
- Has a restore actually been tested, or is it assumed to work?
A backup you have never restored is a hypothesis, not a recovery plan.
Recovery: rehearse the boring parts
Disaster recovery planning tends to focus on the dramatic scenario — a region goes down — and skip the mundane one, which is far more likely: a bad deployment corrupts a table, or someone deletes the wrong records.
The useful exercise is to write down, concretely, what happens in the mundane case. How long until the problem is noticed? How is the decision to restore made, and by whom? How much data is lost in the process? What do customers get told, and when?
If those questions do not have answers written down somewhere, the recovery plan is a diagram, not a plan.
Where this sits at Dorsko
Dorsko's live platforms handle corporate documents today, and the controls described here are the ones we design toward: encryption in transit and at rest, role-based access with logged reads, controlled delivery instead of open links, defined retention, and backup and recovery procedures.
Some of what is described above — particularly key management separated from storage, and encrypted backup rotation at scale — is part of the AWS infrastructure roadmap set out on our technology page rather than something running in production today. We have tried to be careful throughout this site about which is which.