Data & Security

1. Separation between customers

Every customer is a separate workspace. Every stored row carries its workspace identifier, and every read filters on it.

Two things worth stating precisely, because a reviewer will ask:

• Separation is enforced in the application, not by database row-level security. That is a deliberate choice: connection pooling combined with session-scoped database settings is a combination that fails open, and failing open is the one behaviour a separation control must never have.
• The separation is covered by automated tests that try to cross it, including a concurrency test running two workspaces’ reads against each other in parallel. They run on every change.

Inside a workspace, an administrator can restrict a member to particular files and particular rows. Those restrictions are applied at the point the data is read, on both the document path and the spreadsheet path — not filtered out afterwards.

2. Encryption

• In transit: HTTPS to the application; TLS to the database and to object storage.
• At rest: storage and database encryption provided by AWS.
• Credentials and mailbox tokens are encrypted again at the application layer, with a key held outside the database, so disclosure of the database alone does not expose them.
• The application refuses to store a credential if that key is not configured, rather than quietly falling back to plain text.

3. Where the data lives

• Subscription. Amazon Web Services, in the [to confirm: AWS region] region. Data does not leave that region in normal operation.
• Self-hosted licence. Entirely inside your own infrastructure — no telemetry, no phone-home, no shared database. This is the deployment for organisations whose data cannot cross their perimeter at all.

Where processing happens

Answering a question sends the relevant passages — not the whole corpus — to a language model. On the subscription service that model is Amazon Bedrock, called within AWS. Under Bedrock’s terms, prompts and responses are not used to train models and are not retained by the model provider. If you supply your own provider key instead, those passages go to that provider under your own agreement with them.

4. Who can reach it

• Your side: members of your workspace, as narrowed by your administrator. Sign-in is by password or through your own Microsoft Entra directory.
• Our side: [to confirm: the roles with production access, and that access is individually credentialed and logged]. Access exists to operate and support the service, and is not used to read customer content otherwise.
• Sub-processors: [to confirm: the sub-processor list].

5. Retention and deletion

• You can delete files, conversations and your account from inside the product. Deleting a file removes its searchable fragments with it.
• Deleting a workspace removes everything belonging to it: the schema cascades deletion from the workspace record through every dependent row.
• Deleted data can persist in encrypted backups for [to confirm: backup retention period].

6. Breach handling

[to confirm: notification commitment in hours, and who owns the assessment]. India’s DPDP Act requires notification to the Data Protection Board and to affected individuals. As a processor, our obligation is to inform you promptly enough that you can meet yours.

7. Requests from individuals

The people whose data appears in your documents are your data principals, not ours: you are the Data Fiduciary and we are a processor acting on your instructions. Requests for access or erasure come to you, and the product gives you the tools to act on them yourself. If one reaches us directly we refer it to you and help.

8. What is not yet in place

Stated deliberately. A reviewer finds these anyway, and finding them undisclosed is worse than reading them here.

• No external security certification. No SOC 2, no ISO 27001. If you require one, tell us early rather than at contract stage.
• No formal penetration test has been commissioned yet.
• Audit logging is partial. Requests are logged with timing and a trace id; there is not yet a per-record access trail you can query yourself.

9. Asking for more

If your procurement process needs a security questionnaire completed, a DPA signed, or a call with whoever runs this, write to security@talkingbird.ai. For what we hold and for how long, see the privacy policy.