Data Handling & GDPR

This page answers the data-protection questions merchants and their legal teams ask most often. It's written so you can lift answers directly into your own privacy documentation or forward the link to your DPO.

Who is the controller, and who is the processor?

When you use Octocom to serve your customers, you are the data controller and Octocom is your data processor. We process your customers' personal data only on your instructions, under a data processing agreement (DPA) between us.

Practically, this means:

Your customers' conversation data belongs to you. We process it solely to deliver the service.
Your own privacy policy is the document that covers your customers. The standard approach is to name Octocom as your processor and link to our subprocessor list — GDPR does not require you to enumerate the full chain.
If one of your customers contacts us directly about their data, we will refer them to you, since the controller decides how such requests are handled.

Octocom acts as a controller only for its own operations — for example our website visitors and dashboard account holders. That processing is covered by the Octocom privacy policy, which does not apply to your customers' conversation data.

Where is data stored and processed?

Conversation data is stored and processed in the European Union, on Microsoft Azure and Google Cloud EMEA infrastructure. This includes AI model inference: models run on EU-based infrastructure operated by Microsoft and Google under enterprise agreements. Your data is never sent to a model vendor directly, and it is never used to train general-purpose AI models — see How your data is used with AI models.

The full list of subprocessors, with contracting entities and processing locations, is published on the Subprocessors page.

How long is conversation data kept?

Conversation data is retained under your instructions as the data controller. By default it is kept for the life of your account, so your team retains full conversation history — the same default as conventional helpdesks.

Two mechanisms sit on top of that default:

Deletion on request. You can ask us to delete specific conversations, all data for a specific customer, or any other subset, at any time. See the next section.
Retention schedules by agreement. If your policies require a fixed retention period (for example, deleting conversations older than a set number of months), we can agree and implement an automated schedule for your workspace. Talk to your account manager.

For your own privacy policy, this means you can either state criteria-based retention ("kept for as long as needed for customer support and dispute resolution, deleted earlier on request") or, if we've agreed a fixed schedule, state that period.

Why we don't delete conversations on our own

Ticket history is a business record, and deleting it is a decision only you can make.

Conversations are often the evidence in payment disputes and chargebacks (card-network dispute windows run from months to over a year), in warranty and consumer-rights claims (two years minimum in the EU), and in complaint handling generally — "the customer agreed to this in chat" only helps if the chat still exists. History also powers day-to-day support quality: returning customers get context, and your team can see what was promised before.

Under GDPR the retention decision belongs to you as the controller in any case. As your processor we act on your instructions — a vendor that quietly discarded your tickets after some interval of its own choosing wouldn't be privacy-friendly, it would be destroying your business records and acting outside its mandate. So the default is to keep, and anything shorter is a choice you make knowingly.

The short answer for most merchants: yes, with a sentence of justification in your privacy policy. The longer answer, with the usual caveat that we are not your lawyers, jurisdictions differ, and this is a description of common industry practice rather than legal advice:

GDPR's storage-limitation principle (Art. 5(1)(e)) sets no fixed deletion deadline. It says personal data may be kept as long as necessary for the purposes — and the controller defines those purposes. For support tickets, long retention is straightforward to justify:

Active customer relationship — while someone remains your customer, keeping their support history serves the relationship directly.
Legal claims and disputes — tickets are evidence, and limitation periods for contract and consumer claims run from two to ten years depending on the member state.
Statutory record-keeping — tickets containing order, invoice, or refund details often fall under accounting retention laws that require keeping them for six to ten years.

This is why keep-for-the-life-of-the-account is the default across the helpdesk industry, and why merchants' legal teams overwhelmingly accept it. What the principle does rule out is retention with no policy at all — data kept forever because nobody ever decided anything. The fix is not a short deletion timer; it's a documented position: retained for support, dispute-resolution, and legal purposes, deleted on request.

The processing duration is also already agreed between us as a matter of contract: your data processing agreement defines the duration of processing (the term of your agreement, with deletion at the end — see below), which is the documented retention instruction GDPR expects between a controller and processor (Art. 28(3)). If you want a shorter horizon on top of that, that's the retention-schedule option above.

How do we get a customer's data deleted?

The flow follows the GDPR roles: your customer asks you (the controller), and you instruct us (the processor).

Your customer sends you an erasure request.
You forward it to us — through your account manager or [email protected] — identifying the customer (typically by email address).
We delete the customer's conversation data and confirm back to you.

Deletion requests are fulfilled well within the one-month window GDPR gives controllers to respond. Your team can also delete individual conversations directly from the dashboard at any time.

Access and portability requests work the same way. If your customer asks for a copy of their data (a subject access request) rather than deletion, forward it to us identifying the customer, and we'll compile their conversation data and return it to you in a commonly used format to pass on. You can also export conversation data yourself from the dashboard at any time.

What happens to our data when we stop using Octocom?

By default, when your contract ends, all workspace data — conversations, customer records, configuration — is deleted within 30 days, except where law requires specific records to be retained. Written confirmation of deletion is available on request.

If your agreement with us sets its own end-of-contract terms (for example a different deletion window, or return of data before deletion), those terms apply instead.

What happens if there's a data breach?

If a personal data breach affects your data, we notify you without undue delay after becoming aware of it, with the information you need to meet your own notification obligations as controller (GDPR gives you 72 hours to notify your supervisory authority, and we act so you can make that window). We also report to relevant authorities where we're required to directly. Incident response procedures are covered in Security Controls.

Do you train AI models on our data?

No. Octocom never uses your conversations or customer data to train or fine-tune AI models, and our infrastructure providers commit contractually to the same. Conversation data reaches models only to generate responses in your own workspace. The full statement is in the Security Overview.

Nothing, until the visitor opens the chat. The widget sets no cookies, and no data is written to the browser or sent to our servers on page load. When a visitor opens the chat, a functional session reference is stored so their conversation stays continuous, and it expires automatically after 180 days of inactivity.

The full breakdown — every key, when it's written, and cookie-consent guidance for your banner — is on Browser Storage & Consent.

How do we get a DPA?

Contact your account manager or [email protected]. We'll put a data processing agreement in place covering processor obligations, the subprocessor list, and international transfer terms.

Who do we contact with data protection questions?

Your account manager, or [email protected]. If your DPO or legal team needs something specific — a signed compliance summary, deletion confirmation, details on a subprocessor — we're happy to provide it.