Prove where every file lives.
And who touched it.
In regulated software the storage layer is where the hard questions land: which region, whose bucket, who accessed it, when was it deleted. Uplint answers each one by policy and by record — so the answer is a lookup, not an investigation.
Five questions.
Five requests.
Every storage question an audit raises is answered by one record or one event list — the same ones your product uses every day, not a report assembled the week before.
{ id: "file_8Kx92m", name: "patient-record.pdf", storage: "phi-india", location: { provider: "s3", region: "ap-south-1", bucket: "phi-in" }, metadata: { tenant: "apollo", classification: "PHI" }}Six controls.
Set once. Always on.
Each control is a setting on a storage target, applied to every file that lands there. Nothing depends on a developer remembering.
location on the file record · refused-move eventsstorage connection · credential scope and rotationurl events with actor, time and TTLdelete event with reason and provider confirmationevents per file, filterable by tenant and actorconnection settings · provider attestationBuilt for the questions
these frameworks ask.
Different regimes, the same storage questions underneath. Uplint doesn’t make your product compliant — your programme does. It makes the storage part of that programme a set of settings with evidence attached.
- Classification travels with the file as metadata
- Retention is a target-level setting, not a cron job you wrote
- The refusal is recorded too — an audit trail of what did not happen
One product.
Every approved region.
Indian health records in Mumbai, EU identity documents in Frankfurt, a bank’s statements in the bank’s own bucket — from one deployment, with one upload call, decided by the target the file is classified into.
- Targets carry the allow list; files carry the classification
- A customer-owned bucket is a target like any other
- Moves between approved regions keep the file ID
phi-india: {allow: [{ provider: "s3", region: "ap-south-1" }],retention: "7y", access: "signed-url-only", max_ttl: 900},pii-eu: {allow: [{ provider: "azure", region: "westeurope" }],retention: "5y", deny_move_outside: true},bank-statements: {connection: "bank-own-bucket", // customer credentialsretention: "10y"}await uplint.files.upload({ file, storage: "phi-india", metadata: { patient: id, classification: "PHI" } });Straight answers.
Uplint is the file layer that gives your product the storage controls and evidence those programmes ask about. Certification and the overall programme remain yours: the objects live in your buckets, under your provider’s attestations, and Uplint supplies the policy enforcement and the per-file record you hand to the auditor.
Only by a move you explicitly request, and only to a destination the target’s allow list permits. A move outside the list is refused, and the refusal is recorded as an event on the file.
The delete removes the object at the provider and appends a delete event to the record with the actor, the time, the reason and the provider’s confirmation. The event trail outlives the object.
Your application does. Uplint never serves bytes on its own; it issues a short-lived signed URL when your code asks for one, and records who asked. Your authorisation check runs before that call.
Yes. Events and records are available per file and per tenant, so a compliance owner can pull the trail for one customer or one classification without a database query.
Answer with a lookup,
not an investigation.
Connect the buckets your regulator already approved, write the policy once, and let every file carry its own evidence.