Security

1. 1.1The part that runs inside your Shopify admin holds no customer personal data at all - only your session and your settings. Keeping personal data out of it means the piece most exposed to the browser is the piece with least to lose.
2. 1.2Calls, transcripts, recordings, contacts and consent records live in a single database in the European Union.
3. 1.3We use a small number of suppliers, each named at otengo.com/subprocessors, and no data broker, advertising network or analytics provider ever receives your customers’ data.

1. 2.1Encrypted in transit, over TLS, everywhere - including to our suppliers.
2. 2.2Encrypted at rest: the database, file storage, and the backups.
3. 2.3Secrets and API keys are held in the platform’s secret storage, never in the codebase, and are rotated when someone with access leaves.

Every row of data carries the store it belongs to, and the database enforces that boundary itself through row-level security rather than trusting application code to filter correctly. A bug in a query cannot return another merchant’s calls, because the database will not release them.

The same principle applies to the tools the assistant uses during a call: each is bound to the store whose call is in progress, and a request that does not match is refused rather than logged and allowed.

1. 4.1Stored in private storage with no public address. There is no URL that can be guessed, shared or indexed.
2. 4.2Playback goes through a permission check, which then issues a link valid for a few minutes. The link expires whether or not it was used.
3. 4.3Deleting a call deletes the audio and the transcript at our speech provider as well as in our own storage.

1. 5.1Access is limited to the people who need it to run the service. Individual named accounts, strong passwords, and multi-factor authentication - no shared logins.
2. 5.2Access to a merchant’s account is possible in two situations only: you have asked us for help with something specific, or we are investigating a fault or suspected abuse of the calling rules.
3. 5.3Every such access is logged - who, when, and which store - and kept for 24 months. You can ask for the entries relating to your store.
4. 5.4Access is removed the day someone stops needing it.

This is worth stating explicitly because it is the control most often broken quietly. A single debugging line added in a hurry can copy a transcript into a log system with different retention, different access rules and different geography - so in this codebase it is a rule enforced in review, not a preference.

Runtime logs at our hosting provider are kept for one day and are not forwarded anywhere.

The most reliable protection for data is not holding it. Deletion runs as a daily automated job against the retention schedule, rather than depending on anyone remembering:

1. 7.1Recordings and transcripts go on your chosen schedule - up to a year, 90 days by default, with no unlimited option.
2. 7.2Everything about your customers goes within 48 hours of you uninstalling.
3. 7.3In-progress call records are cleared after 24 hours, so a call that fails halfway does not leave a phone number behind indefinitely.

Any new place personal data is stored has to be added to that job. In this codebase, omitting it is treated as a defect rather than a follow-up task.

1. 8.1Development and testing run against separate infrastructure. Real merchant or customer data is never copied into a test environment.
2. 8.2Changes go through review before release, and database changes are versioned migrations rather than manual edits.
3. 8.3Inbound webhooks are authenticated by signature, and a request that fails verification is rejected rather than processed.
4. 8.4Dependencies are monitored for known vulnerabilities and updated.

1. 9.1We have a written incident response procedure covering detection, containment, assessment, notification and review, and a written data loss prevention strategy. Both are reviewed at least annually.
2. 9.2If a breach affects your customers’ data we tell you within 48 hours of becoming aware of it - not when the investigation concludes - because your own regulatory deadline is 72 hours and it starts before you hear from us.
3. 9.3We keep a register of incidents, including those we assess as not notifiable and the reasoning for that assessment.

If you have found a security problem in Otengo, please tell us at info@otengo.com. Include enough detail to reproduce it.

1. 10.1We will acknowledge within two business days.
2. 10.2We will not pursue you for a good-faith report, provided you do not access, modify or keep other people’s data, and do not degrade the service.
3. 10.3Please give us a reasonable chance to fix it before publishing, and we will tell you when it is done.