How Caskwork handles your data

What we hold

Caskwork is a logbook. Everything in it is either something a person at your distillery entered, or something worked out from those entries.

• Your ledger. Every production event you log — mashes, distillation runs, barrel entries, gauges, transfers, dumps, bottlings, removals, losses, adjustments — with the date it happened, the date it was entered, the quantities, the vessels and lots involved, and who logged it. The ledger is append-only: nothing in it is ever edited or erased. A correction is a new entry that sits beside the original.
• Gauge readings. What was measured, the raw readings (weight or volume, apparent proof, observed temperature) and which edition of the federal gauging tables was applied. Proof gallons are derived from these and kept alongside them so a figure can be reproduced later.
• Your distillery profile. Plant and vessels, mash bills, cooperage, bottle formats, the customers and suppliers you name on transfers and removals, and your filing identity — legal name, registry number, EIN, premises address, reporting period.
• Documents you upload. Filed returns, scans, spreadsheets — whatever you hand over during onboarding or afterwards — and the figures transcribed from them.
• Reports. The monthly TTB operations reports and excise figures are derived from the ledger each time they are viewed. What we store is the record of a period having been marked as filed, and the files you download.
• Accounts. For each person with a seat: name, email address, role, seat status, and the invitations that brought them in (the address invited, the role, who sent it, whether it was delivered).
• An audit trail. Every change made outside the ledger — a profile edit, a document removed, an invitation sent, a sign-in, a sign-out, a failed sign-in and why — with who did it and when. It is append-only too.
• Request logs. For each request to the app: a request id, which distillery and seat it was made under, the path, and the outcome. No request bodies, and secrets are scrubbed before a line is written.

Passwords are not held by Caskwork. Sign-in is handled by Amazon Cognito, which holds your email address and your credential. Our database stores only the identifier Cognito assigns you. There is no password, hash or reset token anywhere in our own tables.

Where it lives

In one Amazon Web Services account operated by Caskwork, in the US East (Ohio) region (us-east-2). The database, your documents, the audit checkpoints, the sign-in service and the logs are all there. Nothing is hosted with any other provider.

Database backups are copied to a second region, US West (Oregon) (us-west-2), so a recovery point survives the loss of the first. Certificates and the edge protection rules are managed from N. Virginia (us-east-1), as AWS requires. The app is served through AWS's edge network: edge locations cache the app's static files, and pass every request for your records through to Ohio without storing the response.

Who can see it

Your distillery is a hard boundary

Each distillery is its own organization, and a request is bound to exactly one. The boundary is enforced twice, independently:

• In the database. Postgres row-level security, with a policy named org_isolation on every one of the fourteen tables that hold a distillery's records, forced for every role including the table owner. It fails closed: a connection with no distillery bound reads zero rows, not everything. The application's own database role cannot bypass it and does not own the tables.
• In the application. A second guard on every read and every write, stamped from the seat making the request. The organization is never taken from anything the browser sends.

A request for another distillery's record is answered as if the record did not exist.

Inside your distillery, seats decide

An owner invites people and gives each a role. The role decides which screens exist for that person — a screen a seat is not granted is absent, not greyed out — and what they may do on them. Owners can suspend or remove a seat at any time.

What Caskwork itself can see

Caskwork's own tooling brings a distillery into existence and manages seats and invitations. It does not read ledgers, gauges or filings, and there is no screen or interface in the product through which anyone at Caskwork can read across distilleries. Caskwork's operators — today, its founder — can reach your records only through administrative access to the AWS account, and use it for three things: founding your distillery, support you have asked for, and recovery. A shell opened into the running service is logged in full, and AWS records administrative actions taken in the account.

How it is protected

• In transit. Every connection to caskwork.com and the app is over TLS; the minimum accepted is TLS 1.2 with the 2021 cipher set, and browsers are told to use HTTPS only for two years at a time. Plaintext requests to storage are refused outright, whoever signs them.
• At rest. The database and every snapshot of it are encrypted, as are your documents, the audit checkpoints and the logs.
• Sign-in. Passwords are at least twelve characters. Cognito's threat protection is set to enforce: it evaluates each sign-in attempt for compromised credentials and unusual devices or locations, and blocks the risky ones. Caskwork does not yet offer a second factor. Sessions ride two browser cookies that scripts cannot read — caskwork_session, good for an hour, and caskwork_refresh, good for thirty days — and signing out ends the session everywhere.
• At the edge. A web application firewall with AWS's managed rule set and a per-address rate limit sits in front of both the site and the app.
• Least privilege. The app runs under a role that can write to storage but cannot destroy a document version, shorten a retention window, or delete an audit checkpoint. The database and the sign-in service are protected against deletion. Production has no standing shell into the running service; an operator opens one deliberately, uses it, and closes it.
• Nothing else runs on the page. No analytics, no advertising, no third-party scripts, no tracking pixels — on the site or in the app.

What we keep, and for how long

TTB generally requires a proprietor to keep records for three years, and may require up to three more. Every horizon below is at least that long, and the ones sized against your records are ten years, so a figure we hold for you outlasts the period TTB can ask you to produce it for.

What cannot be deleted, on purpose

• Audit checkpoints are written to a bucket with S3 Object Lock in compliance mode, each retained for ten years. In that mode AWS refuses a delete or a shorter retention from any principal, including the account root. A checkpoint is tamper-evidence: it holds a sequence number and a signed hash of the audit trail's head, so that a record quietly removed or rewritten later can be detected. It contains none of your records. An audit anchor that an operator could remove would not be evidence, which is why it is built so that nobody can.
• Database snapshots land in backup vaults locked in compliance mode, in both regions. After a three-day grace period following the lock's creation, no principal in the account can delete a recovery point before its retention — 90 days for a daily snapshot, 400 days for a monthly one — or lift the lock. A backup that whoever deleted the database could delete in the same session would be half a backup.

What this means for you: if you ask us to delete your records, copies of them will persist in encrypted, locked backups until those backups expire on their own — up to 400 days after the last snapshot that included them. Those backups exist for disaster recovery only. We will never restore one in order to reopen a closed account, and a restored database is used only to recover the live system for the distilleries still on it.

Getting your records out

Your records are yours. Some of them you can take out yourself, today, from inside the app:

• each month's assembled figures as a spreadsheet — a draft while items are open, and a filing copy once none are — and the same figures filled onto TTB's own forms as PDFs;
• every document you uploaded, downloaded as the original file;
• the ledger itself, on screen, in full.

A complete export — every ledger entry with its full detail, your distillery profile, your audit trail, and every document, as machine-readable files plus the originals — is done for you on request. An owner writes to hello@caskwork.com; we deliver it within thirty days, and there is no charge. A self-serve export is on the roadmap ahead of general availability; until it ships, this is the mechanism, and it is a real one.

Leaving Caskwork

An owner writes to hello@caskwork.com. Then, in order:

1. We deliver a complete export, if you want one. We will not close an account until you have confirmed you have what you need.
2. We close every seat and remove the sign-in identities that belong to your distillery.
3. We delete your distillery's records from the live database, and every version of every document from storage.

After that, what remains is exactly what the previous section describes and nothing else: backup snapshots until they expire, audit checkpoints (which hold no record content) for their ten years, and our correspondence with you. We may keep a note that your distillery was a customer, with the dates, for our own accounts.

Subprocessors

The third parties that process your data on our behalf. There are two.

We will update this table before adding a provider, and tell every distillery with an open account by email.

Changes to this page

The figures on this page are quoted from the configuration that builds our infrastructure rather than typed from memory, and an automated check fails our build if the two ever disagree. When a figure changes, this page changes in the same release. A change that reduces a protection or shortens a retention will be announced to every distillery with an open account before it takes effect.

Contact

Questions about any of this go to hello@caskwork.com. You will hear back from the founder.