Delivering a corporate document sounds like a solved problem. Attach it to an email, or put it behind a login.
Both of those are worse than they look, and the reasons are worth setting out, because document delivery is where a lot of otherwise careful systems leak.
Why email attachments fail
Email is the default, and it fails on several counts at once.
It is unencrypted in transit between many hops. It is stored indefinitely on servers neither party controls. It gets forwarded, and every forward creates a copy nobody is tracking. It is the single most common target for account compromise, and a compromised mailbox is a searchable archive of every document ever sent.
Most importantly: once sent, an attachment cannot be revoked. If the wrong document goes to the right person, or the right document to the wrong person, there is no undo.
For a passport scan or a document set describing control of a legal entity, that is not an acceptable property.
Why "put it behind a login" is not sufficient either
Authentication is necessary and not sufficient, because it answers the wrong question. It establishes who is asking. It does not establish whether this person should have this document.
In practice, systems that stop at authentication tend to grant access at the account level: log in as the customer, see everything associated with the customer. That is usually too broad. An account may involve multiple people with different entitlements — a founder, a co-director, an accountant given limited access, a former director whose access should have ended.
The useful model is per-document authorisation evaluated at the moment of access, not membership of an account.
What controlled delivery looks like
The properties worth building toward:
Access is a request, not a location. There is no URL that permanently resolves to the file. Each retrieval is authorised when it happens.
Links expire. Where a temporary link is issued, it is short-lived and scoped to one document and one recipient.
Every access is recorded. Who, what, when, from where. This is the log you will need after an incident, and it is not reconstructable retrospectively.
Permissions are revocable and actually revoked. A former director's access ends when their role does. This needs to be an automatic consequence of the role change, not a task on somebody's list.
Downloads are a distinct permission from views. Viewing a document in a controlled viewer and taking a permanent copy are different acts with different risk, and they should be authorised separately.
The recency problem
There is a requirement specific to corporate documents that general file-sharing does not address.
When a bank asks for a certificate of incorporation, it frequently wants one issued within a defined recent period. The document a founder received at incorporation is genuine, correct — and too old to be accepted.
This means document delivery cannot be purely archival. The system has to know:
- When each document was issued
- Which documents have recency requirements attached
- How to obtain a fresh copy when the stored one is too old
A founder who downloads a two-year-old certificate, sends it to a bank, and has it rejected has been failed by the system, even though the file transferred correctly.
Multiple recipients, different scopes
International structures involve more parties than the founder, and each needs a different slice:
- An accountant needs financial filings, not identity documents.
- A bank needs incorporation documents and proof of address, once, at onboarding.
- A co-director needs corporate documents but not another director's personal documents.
- A marketplace or payment provider needs a specific subset in a specific format.
Handled as "send the founder everything and let them forward it", every one of these becomes an uncontrolled copy. Handled properly, each is a scoped grant with its own expiry and its own log entry — which also gives the founder something they otherwise lack: a record of who has what.
Retention, again
The most reliable protection for a document is not holding it.
Delivery design should include an end. How long does a delivered document remain retrievable? When does a grant lapse? When is the underlying file deleted?
These questions are usually deferred because storage is cheap and deletion feels risky. But an indefinitely retrievable archive is an indefinitely growing liability, and the cost of it is only visible after something goes wrong.
The operational reality
One caveat, because it is easy to design a delivery system that is secure and unusable.
The people receiving these documents are not security specialists. They are founders under time pressure, and often the request arriving is from a bank with a deadline. If the secure path is slower or more confusing than email, they will use email, and the system's security properties become irrelevant.
The controlled path has to be the fast path. Fewer steps than an attachment, not more. If it is not, the design has failed regardless of how sound the model is.
Where this sits at Dorsko
Secure document processing, storage, access and delivery is one of the six areas of infrastructure Dorsko builds, and it underpins both live formation platforms.
Some of what is described here is in production today. Some — particularly expiring access at fine granularity and encrypted backup rotation — sits on the infrastructure roadmap on our technology page. We have been deliberate about labelling which is which.