TagData holds information you care about keeping private. Here’s how we protect it, and what to do if you find a problem.
The short version
- Your files are stored in Amazon S3, encrypted the moment they’re written.
- Many sensitive fields — ID numbers, account numbers, medical names — are encrypted before they’re saved. Not everything is, and we list what isn’t.
- You must set up a second sign-in factor before your account is ready.
- No one at TagData has a screen that shows the inside of your vault.
- We have not had a third-party security audit yet — more below.
Where your information lives
TagData stores your account information and records in a database on Microsoft Azure. Files you upload are stored separately, in Amazon S3.
A “vault” isn’t one file — it’s database rows plus any files you’ve attached, tied to one profile.
Getting your information to us
Everything you send between your browser and TagData travels over HTTPS, so no one in between can read it.
Your browser is also told to use HTTPS with TagData, and only HTTPS, for at least a year afterward — even an old bookmark gets corrected automatically.
Encryption where it is stored
These fields are encrypted with AES-256-GCM before they’re written: bank and brokerage account numbers; credit card numbers; insurance policy, member, group and payer IDs; passport, licence, visa and other ID numbers; Social Security numbers; passwords you store; the names of conditions, allergies, medications, immunizations, procedures and tests, and the condition a medication is for; wire and direct-deposit details; connected-bank tokens; two-factor secrets; and the notes on health, insurance, document, personal-information and credit-card records.
A lot of your vault is not individually encrypted, and you should know which parts. Your name, email and phone number; the titles you give records and documents; dates and file names; and the descriptive body of most records — an institution or employer name, a balance or payment amount, an address, a vehicle’s VIN, plate and loan or lease account number, the medical problem, hospital and doctor on a hospitalization, the lab and clinician on a test result, a credit card’s limit, rate and rewards programme, and the notes on financial, property, vehicle and career records. We keep those as plain text so we can search and sort your vault. They sit behind the same access controls as everything else.
Text pulled from a document you upload is encrypted the same way.
The keys that protect live data aren’t in our source code. The server receives them as configuration from our hosting provider, and each stored value records which key wrote it, so a key can be replaced without losing what it already protected.
We hold the keys, so this isn’t end-to-end encryption. Encryption at rest protects you if a disk or database copy is stolen — it isn’t a promise TagData can’t read your records. What limits that is explained next.
Your files
Uploaded files are stored as objects in Amazon S3, encrypted with AES-256 the moment they’re written by our code — not a setting someone could switch off. Amazon manages the key for that one.
Your files are never available at a public link; every view and download is an authenticated request through our API.
The one exception is a SmartShare link you create yourself. Anyone holding it can open what you shared without signing in. It’s a long random secret, stored on our side only as a scrambled version, rate-limited against guessing, and you can revoke it anytime.
My Tag works differently. Its QR code holds only a link containing a random code — no name and no personal information. Opening it shows nothing until someone signs in to their own TagData account, and nothing is shared until you approve that person’s request. Replacing the code turns the old one off.
Getting into your account
- We never store your password — only a slow, one-way hash of it.
- Passwords need at least eight characters: upper and lower case, and a number.
- Too many wrong passwords locks the account for a while; sign-in is also rate-limited by address and by account.
- A second sign-in factor is required to finish setup; you can turn it off later in Settings.
- Your second factor can be an authenticator app, a text message, an emailed code, or a passkey — and a passkey alone can sign you in.
- Recovery codes are shown once and work only a single time.
- Sessions renew quietly after about an hour. In your browser the renewal token lives where page scripts can’t read it, and we only ever store a hash of it.
- Closing your browser ends your session, unless your browser is set to reopen your previous tabs. “Remember my email” fills in only your email — never your password.
- You can mark a browser as trusted to skip the second factor for 30 days.
Who can see your records
Every record belongs to exactly one vault and one owner — that check happens inside the database query itself, not just the screen that asks for it.
There is no screen anywhere in TagData that shows a staff member the inside of your vault. The only internal tools are a page of aggregate usage counts and an admin-only command that resets the second factor on an account whose owner has lost it.
We do not sell your personal information.
The vault assistant is shown only the records and document text that match your question, never your whole vault. Whatever it is shown — and any photo or document you ask us to read — goes to Amazon Bedrock, which runs inside our own AWS account. We send it to Amazon, not to Anthropic.
This doesn’t change what we said above: we hold the keys, so TagData can technically read your records. Access control is what limits that.
The companies we rely on
A few outside companies help run TagData:
- Microsoft Azure — hosts our servers and database.
- Amazon S3 — stores your uploaded files.
- Amazon Bedrock — runs the AI features (photo scan, document reading, and the vault assistant) inside our own AWS account.
- Amazon SES — delivers the emails TagData sends you.
- Stripe — handles payment on its own pages; we never see your card details. We keep only Stripe’s customer and subscription identifiers.
- Plaid — handles bank sign-in when you connect an account; TagData never sees your bank username or password. Plaid sends us a report of the linked accounts, which is filed in your vault as a document.
- Twilio — sends the text messages used for two-factor codes.
- Google — only if you add your My Tag to Google Wallet: Google keeps that pass, which shows your name and your tag’s link. When you delete your account we ask Google to expire it.
Deleting your information
Deleting your account erases every vault on it — every record, document, and file, not just the one you were last looking at. The database part happens as one all-or-nothing operation, and we then delete the stored files. If deleting one of those files fails, nobody can reach it through TagData any more, but we don’t automatically retry it.
The moment you delete something, it’s gone from the live service. Our database host also keeps automatic backups, so a copy can linger there for a while. We use those only to bring the whole service back after an outage, never to restore something you deleted.
You can start a deletion from Settings.
Audits and certifications
TagData has not had a third-party security audit, a SOC 2 report, or an external penetration test. We’re a small company, and we’d rather say that plainly than let you assume otherwise.
Here’s what we do instead: we ran our own documented security audit of the whole codebase — sign-in, keeping one customer’s data separate from another’s, data exposure, encryption, and deployment — and fixed every finding it raised except two we reviewed and chose to accept. Every build checks the software libraries we depend on against published vulnerability lists, and stops if a serious one turns up.
Telling us about a security problem
Have a general question? Email support@tagdata.co — we use it for everything else too. If it’s a security problem, use the address below instead.