Última atualização: 14 de agosto de 2026 · Versão 1.5
Esta Política de Privacidade explica como a Orion Digital Ltda, CNPJ 67.736.996/0001-79, sede na Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA, CEP 65.605-515 ("Sonar", "nós"), trata dados pessoais em relação à plataforma Sonar, em conformidade com a Lei nº 13.709/2018 (LGPD).
Esta Política se aplica a dois grupos de dados, com papéis diferentes:
• Dados dos nossos Clientes (quem assina o Sonar) · aqui o Sonar é Controlador (art. 5º, VI, LGPD). É o foco desta Política.
• Dados dos Titulares finais (visitantes e compradores dos sites dos Clientes) · aqui o Sonar é Operador (art. 5º, VII), e o Cliente é o Controlador. Explicamos esse papel de forma transparente na seção 8; o regramento detalhado está no DPA.
Documento que acompanha esta Política: Destinos de conversão. É a lista de para onde o Sonar envia dados de conversão, o que cada destino recebe, em que país fica e o que vai hasheado e o que vai em claro em cada um. Onde esta Política falar em "destino de conversão", a lista é a de lá.
Para os dados descritos nas seções 3 a 7, o Controlador é a Orion Digital Ltda, CNPJ 67.736.996/0001-79, sede na Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA, CEP 65.605-515.
Encarregado pelo Tratamento de Dados (DPO):
Você pode usar esse canal para exercer seus direitos (seção 9) e esclarecer dúvidas sobre esta Política.
Quando Você cria conta, contrata e usa o painel do Sonar, tratamos:
| Categoria | Exemplos | Origem |
|---|---|---|
| Cadastro e conta | Nome, e-mail, identificador de usuário | Você, no cadastro (via Supabase Auth) |
| Cobrança | Dados necessários à cobrança da assinatura, processados pela Stripe | Você / processador de pagamento |
| Configuração | Projetos, domínios, regras de evento e as contas dos destinos de conversão que Você liga (pixels, contas de anúncio e tokens, armazenados cifrados) | Você, no painel |
| Uso e técnicos | Logs de acesso ao painel, endereço IP, ações realizadas, dados de sessão | Automático, no uso |
| Equipe/compartilhamento | E-mails de membros e convidados que Você adiciona | Você |
Senha: a autenticação é feita pelo provedor de identidade (Supabase Auth). O Sonar não vê nem armazena sua senha.
Cartão: o pagamento é processado pela Stripe. Não armazenamos dados completos de cartão · eles são digitados no ambiente da Stripe e tratados por ela. O Sonar recebe de volta apenas identificadores da assinatura, os quatro últimos dígitos, a bandeira e o resultado da cobrança.
A Stripe processa fora do Brasil. Isso é uma transferência internacional de dados · ver a seção 6.
| Finalidade | Base legal (LGPD) |
|---|---|
| Criar e manter sua conta; prestar o Serviço | Execução de contrato (art. 7º, V) |
| Cobrar a assinatura e cumprir obrigações fiscais | Obrigação legal/regulatória (art. 7º, II); execução de contrato (art. 7º, V) |
| Suporte e comunicação operacional | Execução de contrato (art. 7º, V) |
| Segurança, prevenção a fraude e abuso, isolamento entre contas | Legítimo interesse (art. 7º, IX) |
| Melhoria do Serviço com dados agregados/anonimizados | Legítimo interesse (art. 7º, IX) |
| Comunicações de marketing sobre o Sonar (se houver) | Consentimento (art. 7º, I) ou legítimo interesse, com opção de descadastro |
Para operar o Serviço, o Sonar compartilha dados com prestadores que atuam como operadores/sub-operadores, apenas na medida necessária:
| Prestador | Função | Localização |
|---|---|---|
| Supabase | Banco de dados e hospedagem de dados | AWS us-east-1 · Virgínia, Estados Unidos |
| Vercel | Hospedagem da aplicação | Região definida na conta Vercel · não declarada em vercel.json |
| Cloudflare · rede | Proxy first-party (Worker) e emissão de certificados. Só repassa o tráfego | Rede global |
| Cloudflare · armazenamento (R2) | Guarda o arquivo dos eventos de navegação (bucket sonar-arquivo). Contém o identificador do cookie e o país do visitante | Leste da América do Norte (Estados Unidos) |
| Meta Platforms, Inc. | Destino de conversão — recepção de eventos (CAPI). Ativo | Estados Unidos |
| Destino de conversão — recepção de conversões (Data Manager API). Disponível desde 14/08/2026. Nasce desligado em todo projeto: só recebe dado depois que o Cliente liga | Fora do Brasil | |
| Stripe | Processamento de pagamento da assinatura | Fora do Brasil (Estados Unidos e Irlanda) |
O Google nasce desligado em todo projeto, e quem liga é o Cliente. O caminho de envio existe desde 14/08/2026, e são dois interruptores independentes: um da conta de anúncio e um por produto do funil. Enquanto qualquer um dos dois estiver desligado, nada é enviado ao Google.
Antes de ligar, o Sonar opera em modo sombra: monta a conversão inteira e guarda sem enviar, para o Cliente conferir o número antes. Guardar e enviar continuam sendo etapas distintas — ver a seção 2 do anexo de destinos.
Sobre os destinos de conversão. As duas últimas plataformas de anúncio da tabela acima só recebem dado porque o Cliente ligou aquele destino no projeto dele. Nenhum destino nasce ligado, e o Sonar não liga destino por conta própria. A lista completa, com o que cada um recebe, está em Destinos de conversão. Incluir um destino novo é uma alteração de sub-operador e o Cliente é avisado antes de qualquer envio (cláusula 5.5 do DPA).
Sobre o papel da Cloudflare. Ela faz duas coisas diferentes, e desde 08/08/2026 a segunda existe. A primeira é rede: o tráfego do site do Cliente passa pelo proxy first-party e segue adiante, sem ficar guardado. A segunda é armazenamento: uma vez por dia, o Sonar grava no serviço R2 da Cloudflare uma cópia reduzida dos eventos daquele dia, antes de apagá-los do banco. O que essa cópia contém e por quanto tempo ela fica está na seção 8.4.
Sobre o papel da Stripe. A Stripe não é uma simples operadora nossa. Ela trata os dados da transação também para finalidades próprias, que a lei e a regulação de meios de pagamento impõem a ela: prevenção a fraude, prevenção à lavagem de dinheiro, guarda contábil e disputa de cobrança. Nesses pontos ela decide sozinha, e não segue instrução nossa.
Sobre o papel dos destinos de conversão, e vale para todos eles. O destino é escolhido pelo Cliente e o Sonar só executa o envio. Mas o destino também trata os dados para finalidades próprias, que ele mesmo define — otimização de campanha e políticas da plataforma. Por isso ele aparece nas duas tabelas: na de operadores (esta seção) e na de transferência internacional (6.1). O detalhe está na seção 8 de Destinos de conversão.
Não vendemos dados pessoais. Podemos compartilhar dados quando exigido por lei, ordem judicial ou autoridade competente, e em caso de reorganização societária, preservadas as garantias desta Política.
O Sonar é operado inteiramente a partir de servidores fora do Brasil. Isso vale para tudo: o banco de dados, a aplicação e a cobrança. Não é uma exceção pontual · é como o serviço funciona.
Por quê, em uma frase: o Sonar é construído sobre fornecedores de infraestrutura em nuvem (Supabase, Vercel, Cloudflare) que hospedam nos Estados Unidos. Não mantemos servidor próprio no Brasil.
| Fornecedor | O que ele faz | Guarda o dado? | Onde |
|---|---|---|---|
| Supabase | Banco de dados: tudo o que o Sonar armazena · conta, configuração, visitantes, eventos, vendas, e-mail e telefone de comprador | Sim, é onde o dado mora | AWS us-east-1 · Norte da Virgínia, Estados Unidos |
| Vercel | Executa a aplicação e as rotas de API. O dado passa por ela para ser processado | Não armazena de forma persistente | Região definida na conta Vercel · não declarada em vercel.json |
| Stripe | Processa a cobrança da assinatura | Sim, os dados de pagamento | Estados Unidos e Irlanda |
| Cloudflare · rede | Proxy first-party (workers/sonar-proxy.js) e certificados. Repassa o IP e a localização aproximada do visitante | Não. É caminho de rede, não armazenamento | Rede global (o servidor mais próximo do visitante) |
| Cloudflare · R2 (arquivo) | Guarda o arquivo diário dos eventos de navegação: identificador do cookie, nome e data/hora do evento, país | Sim. É armazenamento, não rede | Bucket sonar-arquivo, Leste da América do Norte (Estados Unidos) |
| Meta Platforms, Inc. | Destino de conversão — recebe os eventos, a mando do Cliente. Ativo | Sim, do lado dele | Estados Unidos |
| Destino de conversão — recebe as conversões, a mando do Cliente. Disponível desde 14/08/2026; desligado até o Cliente ligar | Sim, do lado dele, depois que o Cliente liga | Fora do Brasil |
fbp/fbc vão em claro ao Meta; o endereço IP e o user agent vão em claro aos dois destinos — ao Google desde 14/08/2026, junto com o contexto do clique; e ao Google não vão nome, sobrenome, país, estado, cidade nem CEP, campos que ele aceitaria em claro e que o Sonar não envia (ver 8.2).O art. 33 da LGPD lista as hipóteses que autorizam mandar dado para fora do país. Estas são as que entendemos aplicáveis:
| Destinatário | Hipótese do art. 33 que invocamos |
|---|---|
| Supabase, Vercel, Cloudflare (infraestrutura · inclui o arquivo de eventos no R2) | Inciso II · garantias adequadas por cláusulas contratuais específicas / cláusulas-padrão |
| Stripe (cobrança) | Inciso II, e também inciso IX · transferência necessária à execução do contrato com Você: não há como cobrar a assinatura sem enviar os dados ao processador |
| Destinos de conversão (Meta, Google e os que vierem · ver Destinos de conversão) | Inciso II, e/ou inciso VIII · quando a base do Cliente (Controlador) for o consentimento específico e destacado do Titular, para aquele destino |
Um fato que Você precisa saber antes de contratar. Hoje o Sonar não tem cláusulas-padrão da ANPD assinadas com os fornecedores de infraestrutura nem com os destinos de conversão · o que existe são os termos padrão que cada um deles pratica.
O que é fato verificado são as regiões e os fluxos da seção 6.1, conferidos no código e na configuração. O enquadramento de cada destinatário em um inciso do art. 33, na tabela acima, é a leitura do Sonar.
Guardamos os dados da conta enquanto a assinatura estiver ativa e pelo prazo necessário para cumprir obrigações legais (ex.: fiscais e contábeis) e o exercício regular de direitos. Encerrada a relação, os dados são eliminados ou anonimizados, salvo obrigação legal de retenção. Os dados dos Titulares seguem os prazos da seção 8.4.
Os dados de cobrança ficam também com a Stripe, pelos prazos que a própria Stripe pratica e que a regulação de meios de pagamento impõe a ela. Esses prazos não são definidos pelo Sonar.
Esta seção é informativa e de transparência. Em relação aos visitantes e compradores dos sites dos nossos Clientes, o Cliente é o Controlador e o Sonar é o Operador (art. 39 da LGPD). O tratamento detalhado é regido pelo DPA.
_sonar_id (validade de 400 dias, gravado no domínio do Cliente) e os cookies do Facebook fbp e fbc. O script também espelha o _sonar_id, o fbc, as UTMs, os identificadores de clique do Google e o cache técnico de checkout no localStorage do navegador, com o mesmo prazo do cookie correspondente · só para manter a continuidade do visitante entre páginas quando o cookie falha (apagado, bloqueado ou cortado pelo navegador). O localStorage não atravessa subdomínio; quem cobre essa travessia continua sendo o cookie.fbclid (Meta), gclid, gbraid, wbraid e gad_source (Google). São parâmetros que a plataforma de anúncio acrescenta ao endereço do site quando a pessoa clica no anúncio; servem para ligar a venda ao clique que a originou. Desde 13/08/2026 o Sonar captura e guarda os identificadores do Google (gclid, gbraid, wbraid, gad_source), por 95 dias (seção 8.4). Desde 14/08/2026 eles também podem ser enviados ao Google — só nos projetos em que o Cliente ligou o destino, que nasce desligado.Guardar e enviar continuam sendo etapas distintas. O Sonar guarda os identificadores de clique do Google por 95 dias (seção 8.4), junto com o contexto técnico do clique, em todo projeto. Já o envio ao Google só acontece se o Cliente ligar o destino naquele projeto — e ele nasce desligado. Enquanto está desligado, o Sonar opera em modo sombra: monta a conversão e guarda sem enviar.
Atribuir conversões, deduplicar eventos entre navegador e servidor e enviar eventos de conversão aos destinos de conversão que o Cliente ativou, a mando dele. A lista dos destinos está em Destinos de conversão. Nenhum destino é ligado por padrão: cada um depende de decisão do Cliente, projeto a projeto.
O que é enviado ao Google quando o Cliente liga o destino · esta é a lista inteira: o identificador de clique (gclid, gbraid ou wbraid); o identificador da transação, o valor, a moeda e a data/hora da venda; o e-mail e o telefone do comprador, com hash SHA-256; e, em claro, o endereço IP, o user agent e o contexto do clique (endereço da página de entrada, referenciador e os parâmetros gad_* da URL), que o Google usa para casar a conversão com a navegação.
O que NÃO é enviado ao Google: nome, sobrenome, país, estado, cidade e CEP. O Google aceita esses campos, e é por isso que eles aparecem na tabela da seção 4 de Destinos de conversão — mas o Sonar não os envia. Ele só monta o bloco de endereço quando tem nome, sobrenome, país e CEP juntos, e o CEP não existe no registro de venda do Sonar; sem ele o bloco inteiro fica de fora.
A autorização é do Cliente, pela conta Google dele. Ele autoriza na tela do Google (OAuth). O Sonar nunca vê nem guarda a senha · guarda um token de atualização cifrado, e o Cliente pode revogar o acesso quando quiser. O detalhe do que o Sonar acessa, usa, armazena e compartilha da conta Google está na seção 8.6.
service_role) restrito ao servidor.Nem tudo vai hasheado, e é importante que o Cliente saiba: os cookies fbp/fbc são enviados em claro ao Meta, porque é o formato que ele exige; e o endereço IP e o user agent vão em claro aos dois destinos — ao Google desde 14/08/2026, junto com o contexto do clique (endereço da página de entrada, referenciador e os parâmetros gad_* da URL). A tabela campo a campo, por destino, está na seção 4 de Destinos de conversão.
Hash não é anonimização. O destino consegue casar o dado hasheado com quem ele já conhece — é para isso que o hash é enviado. Tratamos o dado hasheado como dado pessoal pseudonimizado, não como dado anônimo.
No banco de dados, o dado que identifica uma pessoa é guardado por 30 dias. Depois disso o painel do Cliente passa a viver de contagens agregadas por dia, que não identificam ninguém.
Há uma exceção, e ela é nova (08/08/2026). Antes de apagar o dia do banco, o Sonar grava uma cópia reduzida dos eventos num arquivo fora do banco, na Cloudflare (R2). Essa cópia guarda o identificador do cookie e o país do visitante. Hoje ela não é apagada · não existe rotina de eliminação para esse arquivo. Os detalhes estão em "O arquivo de eventos", mais abaixo nesta seção.
Entendemos que a regra dos 30 dias atende ao princípio da necessidade (art. 6º, III) e ao fim do tratamento (art. 15, I) da LGPD. A exceção acima ainda não tem prazo, e é o ponto que precisa de decisão.
O prazo é o mesmo para todos os planos · Grátis, Start, Pro, Scale e Enterprise. Retenção aqui é uma regra de proteção de dados, não um item de pacote comercial.
Os dois lados, e os dois importam:
Os prazos da tabela abaixo foram verificados no código.
Uma rotina automática executa a cada 2 horas.
| Dado | Prazo |
|---|---|
Registro do visitante (visitors) · cookie, IP, user agent, UTMs, geo, e-mail, telefone, nome | Excluído aos 30 dias, a linha inteira |
Evento de navegação individual (events_log) | 30 dias, em todos os planos |
| Conteúdo técnico (JSON) do evento | Removido aos 14 dias |
| Conteúdo bruto do webhook da venda, nome, IP e user agent da venda | Removidos aos 14 dias |
| E-mail e telefone associados à venda | Anonimizados aos 180 dias |
Identificador de clique do Google (gclid, gbraid, wbraid) e o contexto técnico do clique · em produção desde 13/08/2026 | 95 dias · ver a exceção logo abaixo |
Há ainda um teto de 1.000.000 de eventos por projeto: acima disso, os mais antigos saem antes do prazo acima. Ele existe para proteger a infraestrutura, não como política de privacidade.
Por que este número é diferente dos 30 dias, sem rodeio. O Google aceita receber a conversão de um clique que aconteceu há até 90 dias. Boleto pago com atraso, Pix esquecido e recuperação de carrinho caem exatamente nessa janela. Guardado por 30 dias, o identificador de clique morre antes de a venda acontecer, e essa venda nunca poderá ser enviada — nem depois. Os 95 dias são os 90 do Google mais 5 de folga para a rotina de expurgo rodar.
O que fica guardado nessa exceção: o identificador de clique, o projeto, a data e o contexto técnico do clique · o endereço da página de entrada, o user agent e o endereço IP. Esses três acompanham o identificador porque a plataforma de anúncio os exige junto para reconhecer a conversão; separados, o identificador sozinho não é aceito.
Não entram nessa exceção o e-mail e o telefone, que seguem o prazo próprio deles, na tabela acima.
O endereço da página de entrada é gravado como veio. Se o Cliente construir URLs com dado pessoal na query string, esse dado entra aqui junto · é o Cliente, como Controlador, quem decide o que põe na própria URL.
Situação em 14/08/2026: o Sonar guarda o identificador de clique do Google desde 13/08/2026, e o prazo de 95 dias segue o mesmo. O que mudou é o envio: desde 14/08/2026 o Cliente pode ligar o destino Google e passar a enviar. Ligar o destino não altera o prazo de guarda. Detalhes em Destinos de conversão, seção 7.
| Dado | Por quê |
|---|---|
| Resumo diário agregado · contagem de visitas, eventos e vendas por projeto, por dia e por país | Não identifica pessoa. É o que sustenta o histórico do painel depois que o dado individual é apagado |
A venda (purchases) · valor, moeda, produto, status, identificador da transação e atribuição | Guarda fiscal e contábil, e prova da própria venda. O e-mail e o telefone saem aos 180 dias; o registro da venda fica |
| Arquivo de eventos na Cloudflare (R2) · cópia reduzida do evento de navegação, com o identificador do cookie e o país | Permite reconstruir o resumo do painel se um erro de contagem for descoberto depois. Diferente das duas linhas acima, esta identifica um visitante por um identificador online. Ver abaixo |
Transparência sobre o resumo agregado: hoje ele não tem prazo de expurgo agendado. Existe uma rotina de eliminação já escrita, com prazo padrão de 3 anos, ainda não ativada. Quando for ativada, esta Política será atualizada com o prazo real.
O que já foi enviado a um destino de conversão não volta. Os prazos desta seção valem para o que está com o Sonar. O dado entregue ao Meta, ao Google ou a qualquer outro destino está com aquela plataforma, sob as regras dela — e é com ela que a exclusão precisa ser tratada.
O que é. Uma vez por dia, antes de o corte por tempo apagar um dia de eventos, o Sonar grava esse dia num arquivo compactado guardado na Cloudflare (serviço R2), no bucket sonar-arquivo. O corte só apaga um dia depois que o arquivo daquele dia foi gravado, baixado de volta e conferido.
Por que existe. O painel do Cliente é montado a partir de contagens diárias. Se um erro de contagem for descoberto depois que o dado individual já foi apagado, sem o arquivo o histórico ficaria errado para sempre. Com ele, dá para recontar.
O que vai no arquivo · são dez campos, e esta é a lista inteira: identificador interno da linha, projeto, identificador do evento, nome do evento, data e hora, identificador do cookie do visitante (_sonar_id), status do envio, país, e duas marcas técnicas (se foi tráfego de teste e se foi robô).
O que NÃO vai: endereço IP, e-mail, telefone, nome, UTMs, cidade, estado e o conteúdo técnico (JSON) do evento. Esses campos são apagados no banco pelos prazos da tabela acima e não têm cópia no arquivo.
Por quanto tempo o arquivo fica: não há prazo definido. Não existe rotina que apague esse arquivo, nem regra de ciclo de vida configurada no R2. Enquanto isso não existir, a cópia fica por tempo indeterminado. Não vamos publicar um prazo antes de a rotina existir: prometer prazo sem rotina é prometer o que o sistema não faz. Decisão pendente do responsável pela plataforma. Quando o prazo for definido e estiver em execução, esta Política será atualizada com o número real.
Tudo o que está escrito acima foi conferido no código. O identificador do cookie é, em regra, dado pessoal (identificador online, art. 5º, I) · esta Política trata essa cópia como dado pessoal, não como estatística anônima.
Duas observações sobre o corte por tempo do evento individual: (1) a régua foi ligada em 08/08/2026, e a data de ativação está registrada no banco · são 30 dias para os cinco planos. Hoje ela apaga zero linha: a única conta com tráfego é a conta da própria Orion Digital, que está marcada como isenta dos limites. Para as contas de Cliente, o corte passa a apagar quando elas tiverem histórico mais velho que 30 dias. Além disso, o corte só age sobre um dia que já tenha arquivo conferido (ver acima). (2) Eventos de compra (Purchase) não entram no corte por tempo: eles são o registro da venda e seguem a linha de purchases acima.
Se Você é visitante/comprador de um site que usa o Sonar e quer exercer seus direitos (seção 9), o ponto de contato primário é o Controlador (o dono do site/Cliente). O Sonar, como Operador, apoia o Controlador no atendimento, conforme o DPA.
Esta seção é sobre a conta Google do Cliente — a conta que ele usa para autorizar o envio de conversões ao Google Ads. Ela não trata dos dados dos visitantes e compradores, que estão nas seções 8.1 a 8.4.
O que o Sonar acessa. Ao ligar o destino Google, o Cliente é levado à tela de autorização do próprio Google (OAuth) e concede três permissões:
openid — identifica que a autorização é de uma conta Google.email — dá acesso ao endereço de e-mail da conta que autorizou.https://www.googleapis.com/auth/datamanager — é a permissão que permite enviar a conversão à conta de anúncio do Cliente. Sem ela, não há envio.O que o Sonar usa. O e-mail é usado para mostrar na tela do painel qual conta está conectada. A permissão datamanager é usada para uma coisa só: enviar as conversões do próprio Cliente à conta de anúncio que ele indicou.
O que o Sonar armazena. Do login, guardamos o endereço de e-mail da conta que autorizou e o token de atualização, cifrado. O Sonar nunca vê nem guarda a senha da conta Google. O e-mail é mantido como registro de qual conta autorizou o envio naquele projeto.
O que o Sonar compartilha. Nada. O dado da conta Google não é vendido, não é compartilhado com terceiros e não é usado para treinar modelo. O único destino das conversões é a própria conta de anúncio do Cliente.
Como desfazer. O Cliente pode revogar a autorização a qualquer momento, pela tela do Sonar ou pela própria conta Google. Revogada a autorização, o Sonar deixa de conseguir enviar.
Você pode, a qualquer momento e gratuitamente, requerer:
Para exercê-los, contate o Encarregado (seção 2). Podemos solicitar informações para confirmar sua identidade e responderemos nos prazos legais. Titulares finais de sites de Clientes devem observar a seção 8.5.
10.1. No painel do Sonar (para nossos Clientes) usamos cookies estritamente necessários à autenticação e à sessão.
10.2. Nos sites dos Clientes, o script do Sonar grava o cookie first-party _sonar_id e lê cookies do Facebook (fbp/fbc). Ele lê também os identificadores de clique de anúncio que a plataforma acrescenta ao endereço da página (fbclid, gclid, gbraid, wbraid e gad_source). Eles chegam pela URL, e o script os grava em cookie first-party de 90 dias (_fbc para o Meta; _s_gclid, _s_gbraid, _s_wbraid, _s_gad_source e _s_gadx para o Google), para que o clique sobreviva à navegação entre as páginas do funil. O mesmo script espelha esses valores (exceto o _fbp e a trava de sessão do InitiateCheckout) no localStorage do navegador, com o mesmo prazo · só como rede de segurança quando o cookie falha. A base legal e o aviso/banner de cookies desses sites são responsabilidade do Cliente (Controlador) · não do Sonar. Recomendamos aos Clientes exibir aviso de cookies e coletar consentimento quando essa for a base aplicável, cobrindo cada destino de conversão que tiverem ligado.
Adotamos medidas técnicas e administrativas para proteger os dados contra acessos não autorizados e situações acidentais ou ilícitas: cifragem de tokens (pgcrypto), hash da informação pessoal antes do envio aos destinos de conversão · no formato que cada destino exige, conforme a seção 4 de Destinos de conversão ·, RLS, restrição de credenciais privilegiadas ao servidor, limitação de taxa e liberação manual de contas. Nenhum sistema é 100% imune; em caso de incidente de segurança que possa acarretar risco ou dano relevante, comunicaremos a ANPD e os titulares afetados na forma do art. 48 da LGPD.
O Serviço não se destina a crianças e adolescentes. O Cliente é responsável por não inserir dados de menores sem o amparo do art. 14 da LGPD.
Podemos atualizar esta Política. Mudanças materiais serão comunicadas por e-mail e/ou no painel. A data no topo indica a última revisão.
Destino de conversão novo é mudança material: o Cliente é avisado antes de qualquer envio, na forma da cláusula 5.5 do DPA, e a lista de Destinos de conversão é atualizada.
Encarregado (DPO): Felipe Emanoel Silva · oriondigittal@gmail.com
Controlador: Orion Digital Ltda, CNPJ 67.736.996/0001-79, Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA, CEP 65.605-515. Suporte: ajuda@sonartrack.pro.
Autoridade: Autoridade Nacional de Proteção de Dados (ANPD) · gov.br/anpd
Orion Digital Ltda · CNPJ 67.736.996/0001-79 · Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA · CEP 65.605-515