How your data is handled

Who can see a respondent’s answers

The organization that published the conversation sees the answers, along with anyone they choose to share them with. Three of our own systems handle them on the way, and it matters which:

• An AI model provider. The conversation is adaptive, so deciding what to ask next means sending the questions and the answers so far to a large language model run by a third party. We send a per-request instruction not to retain or train on the content. We do not pin which upstream provider serves the request — the router chooses. The subprocessor list names who is in that path.
• Email, if the organization turns on completion notifications. That email contains the full question-and-answer set, and it travels through an SMTP relay like any other mail.
• Wherever the organization sends it. Google Sheets, a webhook, their inbox. Those are their systems, and once an answer arrives there it is outside anything we can delete.

Our own staff do not read conversation content in the ordinary course of running the service. What we cannot yet offer is a mechanism that enforces that with a customer-issued, expiring grant — today it is role-based access plus an audit trail, not a consent gate.

What the respondent is told

Before the first question, every conversation names the organization that will receive the answers, says the respondent can stop at any point, and discloses that they are talking with an AI assistant. There is no setting that removes any of the three. The white-label option removes our name from the conversation; the disclosure and the privacy link stay either way.

Encryption

• Every public surface is served over TLS. There is no unencrypted path in.
• The database is encrypted at rest by Amazon Web Services, which hosts it, under an encryption key held in our own AWS account rather than a shared one. Backups, and the copies replicated to a second region, are encrypted the same way.
• Every application secret is held in AWS Secrets Manager, encrypted at rest under that same key, and read at start-up by the running service through a role permitted to read that one secret and nothing else. No secret is kept in a code repository.
• Google OAuth tokens — for customers who connect Google Sheets — are additionally encrypted at the application layer with AES-256-GCM, under a key held outside the database. A stolen database backup on its own does not yield a usable Google token.

What we cannot claim.

• Answers and conversation turns are stored as ordinary columns. They are protected by AWS’s disk encryption and nothing above it — there is no application-layer encryption of response content.
• No key of your own. The encryption key is ours, held in our AWS account. You cannot supply one, hold one, or revoke ours.
• No specific at-rest cipher. Disk encryption is AWS’s own implementation and we have not inspected it, so we say “encrypted at rest by AWS” rather than naming a cipher.

Keeping one customer’s data away from another’s

Every table carries a tenant identifier and every query filters on it. There is a dedicated regression test that seeds a record under one account and asserts that every authenticated route returns 404— not 403, which would confirm the record exists — for another account’s valid token. Respondent pseudonyms are salted per account, so the same person answering two organizations’ conversations does not produce a value that joins across them.

Accounts, passwords and keys

• Passwords are hashed with scrypt, per-user random salt, compared in constant time.
• API keys and single-use tokens are 32 random bytes, stored only as SHA-256 digests. Reading the database cannot recover a usable key. Keys are scoped rather than all-or-nothing.
• Access tokens last 15 minutes; refresh tokens 7 days; password resets 1 hour.
• Staff access to our own systems requires an account with multi-factor authentication — mandatory, with no self-service way to switch it off — and administrative actions are recorded in an audit trail.
• Outbound requests, including customer-supplied webhook URLs, are filtered so they cannot be aimed at internal network addresses.

What we cannot claim.

• Application secrets are rotated by hand. They sit in a dedicated secrets manager, but nothing rotates them on a schedule — a person does, and we will not imply otherwise. The database’s own password is the exception: AWS generates and rotates it, and it never reaches a person, a laptop or a repository.
• Multi-factor authentication is available to customer users and off by default. We cannot require it on your account.
• No SSO or SAML. “Sign in with Google” exists and is on every plan, but that is social login, not single sign-on against your own directory. If your security review asks for SAML or OIDC, the answer today is no.

Your own audit log

Every account can read its own event log — through the API, and in the product under Settings → Activity and on each conversation’s timeline. It covers sign-ins, administrative changes, settings and API-key changes, embed origins, conversation lifecycle, integrations and exports. Staff and customer views read the same table, so they cannot quote different numbers for the same event. Event metadata cannot contain answer values or free-text conversation content: that is enforced when the row is written, and a test fails the build if the allowlist is widened unsafely.

What we cannot claim. No export or streaming to your own SIEM — the log is read-only, via API and UI. No tamper-evidence: events are ordinary rows, with no hash chain.

Export and deletion

• Export. Response content as CSV — every question-and-answer pair, filterable — plus a whole-account export. Both self-serve.
• Deleting the account. An owner can delete it from the product, typing the account name to confirm. From that moment every authenticated path is refused, and after a short grace period — during which the owner can cancel — the data is irreversibly purged, well within the seven days our policy promises. Billing is cancelled at the payment provider before anything is deleted.
• Erasing one respondent. Supported, and it returns a receipt with per-table row counts — the artifact you hand to your own regulator. Erasing someone we hold nothing for is a success with zero counts, not an error.

What we cannot claim.

• We cannot recall data already delivered to your own destinations. Rows pushed to your Google Sheet, your webhook endpoint or your inbox are in systems we have no access to. No deletion feature we build will ever change that — it is a boundary of being your processor rather than your controller, not a gap on a roadmap.
• No erasure from backups. The purge is a live-database delete; provider backups age out on their own schedule and there is no restore-and-scrub path.
• Respondent-level erasure is an API call and nothing else — there is no button for it. An account without an engineer opens a support ticket.
• A queued webhook delivery still holds its answer set so you can retry it after fixing your endpoint; erasure severs the link to the conversation but that payload ages out on its own 14-day schedule. Successful deliveries are emptied at delivery time.

How long we keep things

The one fact most easily left out, so it goes first: response content has no expiry. We keep answers until you delete them or delete your account. That is a deliberate product choice — it is your data and you expect it to still be there — but it is not a 90-day window and we will not let you assume it is.

These are the defaults the product ships with. A deployment can be configured differently, and the event windows in particular are implemented rather than contractual — we are not yet offering them as a guarantee.

Training on your data

We do not use your conversations to train models unless you turn it on. It is off by default and it is one switch on your account. Enterprise is excluded structurally — there is no switch to turn on. The corpus keeps no link back to a conversation, a question or a respondent, which is what allows turning the switch off, or deleting your account, to purge it wholesale. The other side of that design: because there is no key to a person, we cannot erase one individual’s contribution to it.

Reporting a vulnerability

Write to security@acquainto.com. It is a monitored address that reaches a person who reads it, and our published disclosure policy is served without a login. There is one monitor and no overnight rota — we will not describe that as a security team or as round-the-clock coverage.

If something goes wrong

We have a written incident response plan with defined severity levels, a posting deadline per severity, a 24-hour commitment to notify affected customers of the most serious class, and a required write-up afterwards. Any suspected exposure of respondent data starts at the highest severity and is downgraded only after investigation.

Detection does not wait for a customer to tell us. Each of our public services is checked from outside our network every 30 seconds, from several locations; a sustained failure raises an alarm that emails a monitored address. Application errors are reported to an error-tracking service as they happen. Someone is on call for those alarms.

What we cannot claim.

• One person on call, not a rotation, and no pager. We will not describe that as a security team or as round-the-clock coverage.
• No status page yet.
• No contractual uptime commitment with any customer.
• No incident history — because none has occurred under this plan. An empty history is not a spotless record and we will not present it as one.

Certifications

How the AI itself is checked

A fixture suite replays real conversations against the live model router on every change to the conversation engine, and scores decision-logic behavior — whether it catches a contradiction, whether it follows up on a vague answer, whether it picks the right input. A regression past a threshold fails the build. We publish the results, worst category included, in the AI quality report.

Questions

privacy@acquainto.com for anything about data handling, or security@acquainto.com for anything about security. If you are working through a security review and want the underlying documents rather than this summary, ask — we would rather send them than have you guess.