Politica de confidențialitate

Who we are

Polimorf ("we", "us") operates polimorf CRM, a multi-tenant sales CRM that we host and run as a service. There is no on-premise edition and no per-customer instance. This policy covers the marketing site at polimorf.md and the application at crm.polimorf.md.

Controller and processor

Two different kinds of personal data pass through polimorf, and our role differs for each.

• The data in your workspace. Your contacts, their messages, your call recordings, your notes. You decide why it is collected and what happens to it. Under the GDPR you are the controller and we are your processor. We process it on your documented instructions and for no purpose of our own.
• Our relationship with you. The account of the person who signs in, billing details, support correspondence, security logs. Here we are the controller.

The difference is practical, not decorative. If one of your customers asks to see or erase their data, that request is yours to answer — we give you the tooling and we act on your instruction. If such a request reaches us directly, we route it to the workspaces it concerns instead of deciding it ourselves. We do not use anything in your workspace to build products, to profile people, or to train models, and there is no cross-workspace index of any kind.

What we collect

Account data

There is no public sign-up. An account exists because an administrator of an existing workspace invited it, so what we hold about a user is what that invitation carried and what the user then set: email address, display name, a password hash, and any multi-factor credential they enrolled. We record sign-ins, permission changes, exports and other security-relevant events — including every refusal, because a denial is evidence too.

Workspace data

Each customer workspace — a tenant — lives in its own isolated Postgres schema. Inside it sit your projects, contacts, deals, custom objects, pipelines, documents and files. A request can only reach the schema its authenticated session belongs to. No client names its own tenant: not through a header, a path, a subdomain or a token claim.

Customer communications

polimorf is built so that conversations with your customers happen inside it. Where you connect a channel we receive and store the messages on both sides — WhatsApp Business Platform, Facebook Messenger and email today, the last through the Gmail API, Microsoft Graph or plain IMAP and SMTP. With them come attachments, the phone numbers and email addresses involved, the display name and profile the platform exposes, delivery and read events, and the raw payload the provider sent. This is personal data about people who are your customers, not ours.

Email open and click tracking is off by default and is something you switch on per project, because in the EU a tracking pixel is access to someone's device and that decision belongs to the controller. Where it is on, we never present an open as a fact — a mail proxy fetching an image is not a person reading a message.

Calls, recordings and transcripts

Telephony records call metadata: numbers, direction, duration, timestamps, outcome and which of your users handled the call. Audio recording is off by default and is switched on per project by you. Where it is on, we store the recording, and — where the AI features are enabled — a transcript. Every access to a recording is itself logged, and that access log outlives the recording it describes.

Technical logs

We log requests, errors and performance metrics to run and secure the service. These carry identifiers, timestamps and surrogate references rather than message content, contact details or credentials, which is deliberate: it keeps operational data out of scope for access and erasure requests instead of leaving it as a problem to solve later.

Cookies

We use strictly necessary cookies for authentication and a preference cookie on this marketing site. There is no analytics or advertising cookie on either surface. See our Cookie Policy.

Why we collect it

• To provide, operate and secure the service.
• To carry your customers' messages and calls over the channels you connect.
• To bill you and to answer your support requests.
• To detect abuse, investigate incidents and keep an audit trail.
• To comply with legal obligations.

Legal bases (GDPR)

For the data we control — your account, billing and security records — we rely on:

• Contract. to give you the service you agreed to.
• Legitimate interest. to keep the service secure and working.
• Legal obligation. accounting records, and answering lawful requests.

For the data in your workspace the legal basis is yours to determine, because you are the controller. The product asks you to record it rather than assuming it: you set a lawful basis per purpose, and consent, objection and suppression are held per contact and enforced by the platform on every send, with no override and no bypass.

Where your data lives

The primary region is the European Union, hosted in Frankfurt. Your tenant schema, your files, your recordings and your backups are there. Our voice infrastructure may relay a call through another point of presence, but recordings and records are always stored in your region — a relay is not a store.

One exception is outside our control, and we state it during onboarding rather than burying it here. WhatsApp's data localization setting has no EU-wide option — Germany is the closest European choice — so every WhatsApp number we register for you is registered with DE. That is decided once per phone number and cannot be changed afterwards without deregistering the number. You have to acknowledge it before we will register anything.

AI features

Transcription, summarisation, reply drafting and semantic search over your conversations are part of the product's design. They are off by default and are switched on by you, per feature and per project. Turning one on is not possible until three things are true: a specific model provider is named, you have acknowledged that provider as a sub-processor and the transfer it involves, and a versioned transparency disclosure exists. The database refuses the change otherwise.

Where AI-generated content reaches one of your customers it is disclosed as such, as the EU AI Act requires, and an AI-drafted reply is always shown to your user for confirmation rather than sent on its own. Any model or speech-to-text provider we use is contractually bound to zero retention and to not training on your data; we do not enable a provider that is not. We do not analyse voice for emotion or affect, and we will not build it.

Who we share with

Sub-processors run parts of the service on our behalf: cloud hosting and storage, the messaging platforms you connect, transactional email for our own notifications, error monitoring, and — only where you turn the AI features on — a model provider. We maintain a register naming each recipient, its country, the classes of data it receives and the transfer mechanism, and a record of processing generated from that register is published to your workspace. Ask contact@polimorf.md for the current list.

Before a new sub-processor becomes active we give notice with a 30-day window to object. We do not sell personal data, and we do not share workspace data with anyone for advertising.

Retention

How long your workspace data is kept is your decision, made per data class within bounds we set. There is no "keep forever" option at any level. The defaults, which you can shorten or lengthen within those bounds, include:

• Message content and attachments — 730 days.
• Call recordings and transcripts — 180 days.
• Call and message metadata — 1095 days.
• The raw payload a provider sent us — 30 days, or 90 for raw email.
• Audit events — 730 days, and never fewer than 365.
• Data exports — 7 days, then the download expires and the archive is deleted.

Shortening a retention period does not take effect for 7 days, and the interface tells you how many records the change will destroy before you confirm it. Our own operational logs are kept 30 days hot and 90 days cold. Statutory accounting records are kept for the period the law requires of us.

Erasure, and what it does and does not reach

Erasure acts immediately and does not wait for a retention period to run out. The person disappears from the interface, from search, from exports, from automations and from the API at once; the physical destruction that follows completes after a short grace window — 7 days by default, which your workspace can set anywhere from none to 30 — so that a mistaken erasure can still be undone. After that it is not reversible. Erasure is also not magic, and we would rather describe it than imply more:

• Message content is destroyed — bodies, payloads, raw provider data, attachments and their keys. The message rows and their timestamps remain, marked as redacted, so that the conversation history, the audit chain and your reporting stay coherent.
• Recordings, transcripts, files and generated documents are deleted from object storage and the key that encrypted them is destroyed. Both, always — destroying a key alone is not erasure.
• The audit log is kept, with the person replaced by a surrogate reference whose mapping is destroyed. It records that something happened, not who it was about.
• A suppression record — the fact that someone asked not to be contacted — is never deleted. Erasing it would let the same person be messaged again on the next import, which is the opposite of what they asked for.
• Backups cannot be rewritten. Database dumps expire after 35 days and the point-in-time recovery window is 14 days; we hold no indefinite archival backups. Every restore re-applies the record of completed erasures before the data is served again.
• An export that has already been downloaded cannot be recalled. We track every export — who, when, what scope — but once a file has left, it is the controller's to look after.

Every completed erasure produces a signed certificate naming what was deleted, and what was kept and under which obligation.

Security

Each tenant is a separate database schema, reached only through the authenticated session, with row-level security as a second boundary and a database role that does not own the tables it reads. Traffic is encrypted in transit; storage and backups are encrypted at rest under a key held per tenant. Recordings, transcripts, attachments and generated documents carry a further key held per contact, which is what makes destroying that key meaningful. Passwords are hashed with Argon2id. Every file that reaches us from outside — an upload, an inbound attachment, an import — is virus-scanned before anyone can download it, and nothing is served from a public bucket.

Message bodies stored in your tenant's database are not individually encrypted, because they have to be searchable. The controls around them are the isolation, the row-level security, the restricted database role and the encrypted volumes above. We say so rather than claim a protection we do not implement.

Our staff do not browse your workspace. There is no vendor account inside your tenant and no standing production-access role. Entering your workspace requires a grant that you create, scoped to what it covers, time-limited, and revocable at any moment; the person entering must re-authenticate, give a ticket reference and a written reason, and every action is written to your own audit log with their name on it. You are emailed when a grant is made and when a session starts and ends. A genuine emergency uses a two-person break-glass path that alerts every workspace owner and is documented in the DPA — an undocumented vendor-access path is a finding, not a feature.

We hold no security certification today. ISO 27001 and SOC 2 Type II are both under consideration and we will not claim either before it is real.

Your rights

Where we are the controller — your own account — you may request:

• Access to the personal data we hold about you.
• Correction of inaccurate data.
• Deletion of your account and the personal data attached to it.
• A copy of your data in a portable form.
• Restriction of processing, or objection to it.

Write to contact@polimorf.md. We answer within one month, and will tell you if we need the extension the GDPR allows and why.

Where the data belongs to a workspace — you are one of our customer's contacts — the workspace owner decides, not us. Send your request to the business you dealt with. If you cannot identify it, write to us anyway: we can match the identifier you give us against the workspaces that hold it and raise the request there on your behalf, and we operate the public deletion-request route the messaging platforms require. You can also stop marketing messages yourself at any time — replying STOP on a messaging channel, or the one-click unsubscribe header on an email, takes effect without a login and without a confirmation step.

If something goes wrong

If we suffer a personal data breach affecting your workspace, we notify you within 24 hours of becoming aware of it — sooner than the law obliges us to, because your own 72-hour clock starts when we tell you — and we give you what you need to make your own notification. Keep your workspace's security contact current; we ask you to confirm it once a year, because that is the address we use.

International transfers

We store and process your data in the EU. Where a sub-processor sits outside the EEA, the transfer runs on Standard Contractual Clauses or on an adequacy decision, with a transfer assessment on file. The register described above names the mechanism for each recipient.

What we will not tell you is that your data never leaves the EU, because for the messaging channels that is not true and no vendor can make it true. Meta operates WhatsApp and Messenger on its own infrastructure: even with German storage set on a WhatsApp number, message content may be processed internationally for a short period in transit, and Messenger has no residency control at all. Connecting a channel means accepting how that platform works. We would rather write this down than let you discover it later.

Changes to this policy

We will tell you before a material change takes effect, and the "Last updated" date at the top always reflects the current revision.