Privacy policy

01

Who we are

The controller for the data described here is TDACRM SOLUTIONS SRL, a company registered in Romania. Its registered address and company number are set out at the foot of this page, together with the address that reaches us.

There is one contact route for anything to do with data: that same address. Write to it to ask what we hold, to have something corrected, or to have it deleted. We answer in English, French or Italian, within one month of the request, and sooner where the request is a simple one.

02

Controller or processor — which we are, and when

Two roles run through this policy, and confusing them is how documents like this usually go wrong. For the correspondence that passes through the app — the messages your staff write, the replies that come back, the attachments — the customer is the controller and we are a processor. We hold that material because the customer's portal asked the app to send and collect it, and we act on the customer's instructions.

For what is ours to run — the account, the subscription, support requests, the audit log, the security of the service — we are the controller ourselves. That is the part of this policy where the legal bases below are ours rather than the customer's.

This policy, read with the licence agreement, sets out the subject matter and duration of the processing, its nature and purpose, the types of data and the categories of people involved, and our obligations — the matters Article 28 of the GDPR requires a controller and a processor to agree in writing. If your organisation needs those terms on its own paper, write to us and we will sign a data processing agreement.

03

What the app takes from your mailbox

The app connects to one mailbox per portal: SMTP to send, IMAP to read. It could technically see everything in that mailbox. It does not, and the way it is built is what lets us say so — every polling round asks your server for message headers only: who wrote, what the subject is, which message it answers.

A body is downloaded only when those headers prove the message belongs to a conversation started from a deal or a lead. What we store for such a conversation is this:

• Messages sent from the app: the recipients, the subject, the body and the attachments — the message your colleague wrote.
• Replies matched to a conversation: the sender, the subject, the body and the attachments — the answer you asked for.
• Routing headers: Message-ID, In-Reply-To and References. Without them a reply cannot be tied back to the right record.
• For every other message in the mailbox: the technical identifier of the message, its number in the mailbox, and the moment we saw it go past. No sender, no subject, no body, no copy. Those rows expire on their own after thirty days.

The screen where an administrator can attach a stray reply by hand asks your server for those headers live, at the moment the page is opened. If the administrator attaches the message, that is when it reaches us. If not, we never held it at all.

04

What we never collect

Each of the following would be easy to collect from where the app already sits, and is deliberately not collected.

• The rest of your mailbox — invoices, internal mail, private correspondence. It stays on your server.
• Your Bitrix24 contacts, your calendar, and the files on your portal that nobody attached to a message.
• Behavioural analytics, cross-site tracking and profiling. There is no tracking pixel in the mail the app sends, no open tracking and no click tracking.
• Special categories of data. Nothing in the app asks for them. If they end up inside a message somebody wrote, they are stored like the rest of that message and deleted like it.

05

What you set up, and what we log

The rest of what we hold is the configuration you enter and the record of what was done with it.

• The mailbox connection: SMTP and IMAP host and port, the username and password, and the address messages are sent from.
• Your supplier list: name, company, address, phone and notes. You enter it; we never enrich it from anywhere else.
• Templates, signatures and standing blind-copy rules.
• The interface language each user chose.
• An audit log: which Bitrix24 user did what, from which IP address, and when. It answers the question a director eventually asks, which is who wrote to that supplier.
• Bitrix24 authorisation tokens, so the app can write into a record's timeline and upload files to your portal.

06

Support requests and billing

The support form inside the app stores your request in our database, encrypted, and it stays there: no support request leaves our servers. So that somebody notices it, the app sends a short notice to our own support mailbox — and that notice carries two numbers, the request's own number and the internal number of your portal. No name, no address, no subject, no message. Until 7 August 2026 the notification went to an outside chat service and carried the whole request, text and all; it does neither now.

Payment is taken by Stripe. Card details never reach our servers: the checkout page and the billing portal belong to Stripe, and you enter your billing details there. What we hold about all of this is:

• The support request itself: your name, the reply address, the subject and the message. All four are encrypted at rest, and none of them is sent anywhere outside our servers.
• Optional diagnostics, only if you tick the box: your portal domain, the app version, your mailbox host and port, and the result and date of the last twenty messages sent from your portal. No subjects, no bodies, no recipient addresses, no mailbox username or password.
• The Stripe customer and subscription identifiers, the subscription status and the date your paid period ends. Nothing else about the payment.
• An operational alert to that same mailbox of ours when a portal's mailbox connection fails three times in a row. It carries the portal's internal number and the reason the connection failed, with any host name, mailbox address or IP address in that reason masked before it is sent. No correspondence, and nothing that names a person or a mailbox.

07

What is encrypted at rest, and what is not

Not everything in the database is encrypted, and a policy claiming otherwise would be easier to write and untrue. These fields are encrypted at rest with AES-256-GCM:

• Message bodies — the plain text, the HTML and the quoted parts.
• Message subjects, on the way out and on the way back.
• The sender and recipient addresses inside messages.
• The username and password of your SMTP and IMAP connection.
• The name, reply address, subject and body of a support request.

Stored as written, not encrypted: the names and companies in your own supplier list, the text of your templates and signatures, the label on a conversation, the SMTP and IMAP host and port and the configured sender address, and the audit log — action, user, IP address. Field encryption keys and lookup keys are derived separately, and addresses used for searching are indexed by a keyed hash, so a conversation can be found without anything being decrypted.

One known deviation, disclosed rather than smoothed over: when a reply arrives from an address that is not in your supplier list, the label on that conversation keeps the address in clear text, although the same address is encrypted everywhere else. It is an inconsistency we intend to fix, not a decision.

08

Why we process it, and on what legal basis

Each purpose needs a basis of its own under the GDPR, and a policy that lists purposes without naming their bases is only half written. Ours are these.

• Running the app for a customer: sending, collecting replies, storing the conversation Performance of our contract with the customer, Article 6(1)(b). For the personal data of the people your staff write to, the customer is the controller and chooses the basis — in practice the legitimate interests of the customer's business, Article 6(1)(f).
• Subscription, invoicing and the records that go with them Performance of the contract, Article 6(1)(b), together with our obligations under accounting and tax law, Article 6(1)(c).
• The audit log, abuse prevention, keeping the service secure Our legitimate interests in running a service that can account for what it did, Article 6(1)(f).
• Support requests Performance of the contract, Article 6(1)(b) — you asked us for help.

We rely on consent for none of it, so there is nothing for you to withdraw. There is no automated decision-making and no profiling that produces legal effects for anyone.

09

Who else processes it

This is the whole list. Nobody else receives your data, and nobody joins the list without this page changing first.

• Hetzner Online GmbH Nuremberg, Germany — European Union Hosting. The application, the database and the stored attachments run on servers rented from Hetzner. This is where your data physically is.
• Stripe Ireland and the United States Payments. Checkout, the billing portal, invoices and the subscription itself. You give Stripe your billing details directly; all we send Stripe is the plan you chose, the identifier of your portal and your interface language.
• Cloudflare United States, with servers worldwide The network in front of our domains. It terminates the encrypted connection and filters traffic, so it sees connection data — IP address, browser, the address requested — for every request to this site and to the app.
• Zoho European data centre Our own mailbox. Email you send to the address at the foot of this page, and our replies to it, are handled by Zoho's mail service. So are the two internal notices the app sends us — a new support request, and a mailbox connection that has failed three times — which carry internal numbers and, for the failure, a masked reason, and nothing that names a person.
• Bitrix24 Your own portal Not a third party we hand your data to, but your own system. With the tokens you granted at install, the app writes messages into a record's timeline, uploads attachments to your portal's Drive and sends chat notifications. What it writes there is your own correspondence, in your own portal, under your own agreement with Bitrix24.

There is no advertising network on that list, no analytics provider, no data broker and no AI vendor, because there is none in the product. We do not train models on your correspondence and we do not pass it to anyone who would.

10

Data leaving the European Union

Your data sits in Germany, inside the European Union, so the hosting involves no transfer to a third country at all. Two of the processors above are a different matter, and naming which is more useful than the usual sentence about appropriate safeguards.

Stripe and Cloudflare both process data outside the European Economic Area. Both rely on the European Commission's standard contractual clauses, which form part of their own data processing terms, and what they see is narrow: billing details you type at Stripe, connection data at Cloudflare.

Nothing else leaves. Our own mailbox sits in Zoho's European data centre, so the support requests we read and the internal notices the app sends us stay inside the European Economic Area as well. Until 7 August 2026 those notices went to a chat service outside it; they no longer do, and there is no third destination left to name. If you would still rather not use the form in the app, the email address at the foot of this page reaches the same people.

11

How long we keep it

Different things live for different lengths of time, and the honest summary is that most of it lives until you uninstall.

• Conversations, messages and attachments: until you uninstall the app, or until the end of the retention window if you turned one on.
• The register of messages that belong to no conversation: thirty days, automatically.
• Support requests and the audit log: no automatic expiry today. They are deleted with everything else when you uninstall.
• Billing records held by Stripe: kept by Stripe under its own rules and the accounting law that applies to it, independently of us.

Retention is off unless you switch it on, and the window suggested when you do is ninety days. It shortens how long message content is kept; it never touches the small amount of metadata a future reply needs in order to find its conversation.

12

Deletion

Uninstalling the app deletes everything belonging to your portal: conversations, messages, attachment files on disk, suppliers, templates, signatures, blind-copy rules, mailbox credentials and authorisation tokens. It happens by cascade in the database, with nobody having to remember, and there is no residual copy.

Two things survive it, and both are yours. Everything the app wrote into your Bitrix24 timeline and your portal's Drive stays in your Bitrix24 — we do not reach into your portal to remove it. And uninstalling does not cancel your Stripe subscription: cancel that in the billing portal, or it will renew.

The optional retention window deletes message bodies and attachment files from our database after the period you chose. It deletes content only where we can prove that the exact content already reached your Bitrix24 — an archive uploaded to your portal's Drive, confirmed back by Bitrix24 with an identifier and a size. A message for which that proof is missing is never deleted, however old it is, because for that message our copy may be the only one left.

13

Your rights

Where we process your personal data, the GDPR gives you these rights, and exercising them costs nothing:

• To know what we hold about you and to receive a copy of it.
• To have what is wrong corrected.
• To have it deleted, where we have no obligation to keep it.
• To have the processing restricted while a disagreement is resolved.
• To receive what you gave us in a portable form, and to have it sent elsewhere where that is technically possible.
• To object to processing we base on our legitimate interests.

Where we are the processor rather than the controller — anything to do with the correspondence inside a customer's portal — the request goes to that customer, who is the controller of it. If it reaches us first we will pass it on and help them answer, rather than answer it ourselves: deciding what to release from someone else's records is not ours to do.

If you think we have handled your data badly, tell us first, because we would rather fix it. You are also entitled to complain to the Romanian supervisory authority — the National Supervisory Authority for Personal Data Processing, ANSPDCP, at dataprotection.ro — or to the authority in the country where you live or work.

14

How it is protected

Every query in the app is scoped to a single portal, so one customer's data cannot be reached through another customer's session. Traffic between your browser, your Bitrix24 portal and our servers is encrypted in transit. Access to the production systems is limited to the people who run the service. The fields listed above are encrypted at rest; the ones not listed are not.

We claim no certification, no external audit and no compliance standard, because we hold none. If a breach affects your data we will say so without undue delay — to the customer, as their processor, and to the supervisory authority where the law requires it.

15

What we do not do

Some of these are obvious. They are stated anyway, because they are exactly the things that tend to be quietly untrue elsewhere.

• We do not sell your data, rent it out, or share it with anyone beyond the processors named above.
• We do not train machine learning models on your correspondence, and we do not hand it to anyone who would.
• We run no advertising, no profiling and no cross-site tracking.
• This website sets no cookies and carries no analytics. Nothing you do here is measured.
• The app sets one cookie, named ma_session: strictly necessary, short-lived, so it knows which portal and which user is looking at it inside the Bitrix24 frame. There is no other cookie and no tracker.

16

Changes to this policy

The date at the top of this page changes when the text changes, and only then. It is a constant kept next to the text in the source, so the page cannot claim an update it did not have.

If a change materially affects how we handle your data — a new processor, a new purpose, a longer retention period — we will say so on this page, and say what changed, before it takes effect.