Security

This page describes how DSAR Desk actually stores and protects data — specifics you can check, not badges. Where a control does not exist yet, it says so, in the last section.

Where data lives

All account, request, and subscription records are stored in Amazon DynamoDB in AWS's Asia Pacific (Mumbai) region, ap-south-1. We do not replicate data to other regions. Data is encrypted at rest with DynamoDB's server-side encryption, using AWS-managed keys — this is AWS's default for every DynamoDB table, so it's a property of the platform we build on rather than something we added. All traffic between your browser and DSAR Desk travels over TLS, served through Amazon CloudFront.

Product isolation

Each Klair product runs isolated from the others: its own DynamoDB tables, its own Lambda function, its own IAM role, and its own signing secrets. A defect in one product cannot read another product's data, because no shared credential exists that spans them.

Who can access production

One person: Sandeep Kavety, the founder. Klair Labs is a one-person company — there are no support staff, contractors, or third parties with access to AWS or to your data. That means no tiered access-control story to tell you, and it also means the list of people who could ever look at a request record has exactly one name on it. When that changes, this page will change first.

How sign-in works

There are no passwords. You sign in with a one-time link — a signed token emailed to your address — so there is no password database to breach. The honest trade-off: your email account's security is the gate. Anyone who can read your email can sign in as you, so protect that account (use two-factor authentication on it) and tell us immediately at hello@klairtech.com if you think it's been compromised.

• Session licences are tokens signed with HMAC-SHA256; the server rejects anything it didn't sign.
• API keys are shown to you once at creation and stored only as SHA-256 hashes — we cannot recover a lost key, only issue a new one.
• Outbound webhook payloads are signed with HMAC-SHA256, so your receiving endpoint can verify that a delivery really came from DSAR Desk.

Backups

Point-in-time recovery is enabled on all DSAR Desk tables (as of 26 August 2026): DynamoDB keeps continuous backups, and we can restore any table to any second within the last 35 days. This protects against operator mistakes and bad deployments, not just hardware failure.

An audit trail even we cannot edit

The audit log — the record of who did what and when in your workspace — is written to an append-only DynamoDB table whose IAM policy carries an explicit deny on UpdateItem, DeleteItem and BatchWriteItem. That deny applies to the application's own role too: even DSAR Desk's own code, and by extension the one person who operates it, cannot alter or delete an audit row once written. This is enforced by AWS IAM, not by application code promising to behave.

Incident response

There is no formal on-call rotation — one person cannot honestly offer one. What we commit to instead:

• A reported security issue is acknowledged within 48 hours.
• If an incident affects your data, we notify affected customers by email without undue delay, and say plainly what happened and what we did.

Reporting a vulnerability

If you find a security problem in DSAR Desk, email hello@klairtech.com. You'll get an acknowledgment within 48 hours and a straight answer about whether and when it will be fixed. There is no bug bounty programme (see below), but reports are read by the person who wrote the code, and acted on.

What we have not done yet