Um encurtador de URL parece ser uma superfície pequena em uma revisão de compras. Dois parágrafos no questionário de segurança do fornecedor, uma atestação rápida, uma caixa de seleção. Então, a equipe de segurança abre o diagrama de arquitetura e descobre que o encurtador está no caminho da requisição de cada URL de campanha, cada link de e-mail transacional, cada redirecionamento de QR-code. A revisão de dois parágrafos transforma-se em três semanas de acompanhamento.
Este post responde às perguntas que as equipes de compras corporativas realmente fazem sobre SOC 2 Type II e HIPAA ao avaliarem um fornecedor de rastreamento de links. Ele foi escrito para a pessoa que preenche o questionário e para a pessoa que revisa a resposta.
A versão curta#
A Elido possui certificação ISO 27001. O SOC 2 Type II está em andamento, com conclusão prevista para o segundo semestre de 2026 — a janela de auditoria começou em fevereiro de 2026, a coleta de evidências vai até julho e o relatório Type II é esperado para o final do Q4. O HIPAA é suportado nos planos Business e Enterprise com um Business Associate Agreement assinado; os controles subjacentes são os mesmos utilizados para o SOC 2.
A postura de conformidade com o GDPR é separada do SOC 2 e HIPAA e é abordada no pilar GDPR para encurtadores de URL. Este post foca nos frameworks de atestação de estilo americano que impulsionam as revisões de compras corporativas.
O que o SOC 2 realmente diz sobre um encurtador de URL#
O SOC 2 é um relatório, não uma certificação. Um auditor independente (uma firma de CPA nos EUA ou um órgão de auditoria reconhecido na UE) examina uma organização de serviços em relação aos Trust Services Criteria do AICPA e emite uma opinião. O Type I documenta que os controles foram projetados adequadamente em um determinado momento; o Type II documenta que eles operaram de forma eficaz durante um período — geralmente de seis a doze meses.
Os Trust Services Criteria dividem-se em cinco categorias. Cada relatório SOC 2 abrange Security; os outros quatro (Availability, Processing Integrity, Confidentiality, Privacy) são incluídos conforme a escolha da organização de serviços com base nas necessidades da sua base de clientes.
Security — a categoria sempre inclusa#
Os critérios de Security cobrem controle de acesso, gestão de mudanças, monitoramento, resposta a incidentes e avaliação de riscos. Para um encurtador de URL, os controles que mais importam são:
- CC6.1 Logical access: quem pode criar, modificar ou excluir um link curto, e como esse acesso é concedido e revogado. A auditoria rastreará usuários específicos desde o registro de admissão do RH até o IdP (Ory Kratos para a Elido), passando pela atribuição de funções no workspace, e verificará se o acesso foi removido dentro do prazo da política após o desligamento.
- CC6.6 External access: como os usuários externos (proprietários de domínios personalizados, consumidores de API, integrações de parceiros) se autenticam e quais escopos eles recebem. O modelo de token de API com chaves de idempotência e escopo por workspace é o artefato que o auditor deseja ver.
- CC7.2 Monitoring: o que é registrado, para onde os logs vão e como as anomalias surgem. Para um serviço de redirecionamento, os sinais relevantes são volumes de redirecionamento incomuns por workspace, acionamentos de rate-limit no edge e falhas de autenticação.
- CC8.1 Change management: mudanças de código desde o pull request até o deploy, com segregação de funções entre o engenheiro que escreveu a mudança e o revisor que a aprovou. A auditoria amostrará pull requests e percorrerá o registro de aprovação e deploy.
Os critérios de Security também são onde o SOC 2 espera um plano de resposta a incidentes documentado. Para um serviço de redirecionamento, os incidentes relevantes são a criação não autorizada de links, adulteração do destino de redirecionamento e exfiltração de dados por meio dos endpoints de exportação de analytics. O runbook em /docs/runbooks/ cobre o playbook para cada um.
Availability — a segunda categoria mais comum#
Availability cobre compromissos de uptime, planejamento de capacidade e recuperação de desastres. Para um encurtador de URL, os artefatos relevantes são:
- Um service-level objective documentado. O SLO publicado da Elido é de 99,95% de disponibilidade de redirecionamento por trimestre, com SLOs separados para o dashboard (99,9%) e para a API de analytics (99,5%).
- Evidência de teste de capacidade. O serviço de redirecionamento no edge executa testes de carga contínuos em staging; a auditoria busca evidências de que o envelope de capacidade de produção é conhecido e monitorado em relação ao SLO.
- Evidência de backup e restauração. O Postgres executa Patroni HA com point-in-time recovery; o ClickHouse exporta diariamente para o object storage; a auditoria solicita o log do teste de restauração mostrando que o restore time-objective é alcançável.
- Documentação de failover multi-região. Os três POPs (Frankfurt, Ashburn, Singapura) são active-active para redirecionamentos; o auditor lerá o runbook de failover e o post-mortem do evento regional mais recente.
Confidentiality e Privacy — incluídos seletivamente#
Confidentiality e Privacy adicionam categorias que se sobrepõem à postura do GDPR. A maioria dos clientes corporativos na UE prefere abordar a privacidade por meio da documentação do GDPR (acordos de operador do Artigo 28, avaliações de impacto de transferência, o DPA público) em vez do SOC 2 Privacy. O escopo atual da auditoria SOC 2 da Elido inclui Security, Availability e Confidentiality. O Privacy é abordado separadamente por meio do conjunto de documentação do GDPR em /trust.
O motivo da divisão: o SOC 2 Privacy mapeia para os Generally Accepted Privacy Principles do AICPA, que foram projetados para frameworks de privacidade do estilo americano. O GDPR é um framework jurídico separado com seus próprios controles. Misturar os dois em uma única atestação tende a enfraquecer ambos.
O que o HIPAA realmente diz sobre um encurtador de URL#
O HIPAA — o Health Insurance Portability and Accountability Act, conforme atualizado pelo HITECH e pela Omnibus Rule de 2013 — regula como as Protected Health Information (PHI) são tratadas por entidades abrangidas (provedores de saúde, pagadores, câmaras de compensação) e seus Business Associates.
Um encurtador de URL torna-se um Business Associate quando o link curto ou os dados por trás dele carregam PHI. A questão interessante é se isso chega a acontecer, e a resposta é mais sutil do que a maioria das revisões de compras assume.
Quando o PHI flui através de um redirecionamento#
Um link curto por si só — s.elido.me/abc123 — não é PHI. A URL de destino, os metadados do workspace e as tags de campanha também não são PHI no caso geral.
A questão do PHI reside em três lugares específicos:
- URLs de destino que contêm identificadores: um link curto que redireciona para
https://provider.example/patient/12345/resultscontém um identificador de paciente no caminho da URL. Essa URL de destino é armazenada pelo encurtador e, portanto, é PHI no sentido estrito — mesmo que o link funcione perfeitamente sem que ninguém no encurtador interprete o identificador do paciente. - Parâmetros personalizados anexados no momento do clique: se um redirecionamento anexar um identificador de sessão ou um identificador de usuário como parâmetro de URL e esse identificador for posteriormente vinculável a PHI, o evento de clique passará a fazer parte da cadeia de PHI.
- Eventos de clique com dados de referrer: um evento de clique inclui a URL de referrer. Se um referrer incluir, por acaso, um identificador de paciente (uma página de portal de paciente com link direto que encaminhou o usuário para o link encurtado), o campo de referrer será PHI.
A maioria dos casos de uso de marketing de saúde não gera PHI por meio de nenhum desses canais. Um departamento de marketing de um sistema de saúde que executa campanhas para vacinas contra a gripe, eventos de bem-estar ou conteúdo de saúde geral produz redirecionamentos com destinos livres de PHI e referrers livres de PHI. Para essa carga de trabalho, o BAA é precaucional, não arquitetonicamente necessário.
Para cargas de trabalho que roteiam por destinos de PHI — portais de pacientes, links de confirmação de consultas, URLs de entrega de resultados de exames — o BAA é obrigatório, e os controles arquitetônicos descritos abaixo precisam estar implementados no encurtador.
A HIPAA Security Rule mapeada para um serviço de redirecionamento#
A HIPAA Security Rule (45 CFR Part 164, Subpart C) prescreve salvaguardas administrativas, físicas e técnicas. Para um serviço de redirecionamento que lida com PHI em destinos:
- Controles de acesso (164.312(a)): identificação única de usuário, logout automático, criptografia de ePHI em trânsito e em repouso. A Elido impõe identificadores de usuário únicos atribuídos pelo IdP, timeout de sessão configurável por workspace, TLS 1.3 em todos os endpoints externos e criptografia de envelope AES-256 em repouso para os armazenamentos de dados relevantes.
- Controles de auditoria (164.312(b)): registro e exame da atividade em sistemas que contêm ou usam ePHI. A Elido emite logs de auditoria para criação de links, modificação de links, alterações de destino e exportação de analytics para um armazenamento append-only à prova de adulteração. A retenção do log de auditoria é de 24 meses por padrão nos planos Business+.
- Controles de integridade (164.312(c)): proteção de ePHI contra alteração inadequada. As URLs de destino são armazenadas com histórico ao nível da linha; qualquer modificação é registrada com a identidade do ator e o timestamp, e o valor anterior permanece na tabela de histórico.
- Segurança de transmissão (164.312(e)): proteção de ePHI em trânsito em redes abertas. TLS 1.3 em todos os endpoints de redirecionamento; HSTS preload; certificate pinning disponível em domínios personalizados.
As salvaguardas administrativas e físicas (treinamento da força de trabalho, políticas de sanção, controles de acesso às instalações) sobrepõem-se fortemente aos controles de Security do SOC 2. A mesma evidência suporta ambas as auditorias, razão pela qual as executamos em um cronograma de evidências compartilhado.
O que o BAA cobre e o que não cobre#
Um Business Associate Agreement é um contrato sob o HIPAA 164.504(e). Ele compromete o Business Associate com salvaguardas específicas, prazos de notificação de violação e obrigações de repasse para subcontratados. Ele não altera a arquitetura subjacente; ele compromete o fornecedor a operar a arquitetura de uma maneira em conformidade com o HIPAA.
O BAA padrão da Elido, disponível nos planos Business e Enterprise, cobre:
- As quatro categorias de salvaguardas da HIPAA Security Rule aplicadas a todos os dados que o cliente roteia pelo serviço de redirecionamento.
- Notificação de violação em até 60 dias após a descoberta, com cronogramas detalhados de resposta a incidentes cobertos no BAA e no runbook correspondente em
/docs/runbooks/incident-response. - Repasse para subcontratados para os sub-processadores nomeados (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) sob seus próprios BAAs, onde aplicável. A lista atual de sub-processadores está em
/legal/subprocessorse é a mesma lista usada para a documentação do Artigo 28 do GDPR. - Devolução ou destruição de PHI no encerramento do contrato, com uma janela de 30 dias para o cliente exportar os dados antes da exclusão.
O que o BAA não faz: ele não torna elegível um nível de plano não elegível para HIPAA. Os planos Free e Pro não incluem a execução do BAA. A infraestrutura é the mesma em todos os níveis pagos; os compromissos legais não são.
O questionário de compras — respostas que você pode colar#
A maioria dos questionários de compras corporativas faz o mesmo conjunto de perguntas. As respostas abaixo são as que fornecemos diretamente, com links para os artefatos.
Você tem um relatório SOC 2 Type II atual? Certificação ISO 27001; auditoria SOC 2 Type II em andamento, relatório Type II previsto para o Q4 de 2026. Cartas de ponte (bridge letters) e o certificado ISO 27001 atual estão disponíveis sob NDA via /trust. O SOC 2 Type I foi concluído em novembro de 2025; o relatório Type I também está disponível sob NDA.
Vocês assinarão nosso BAA? Assinamos nosso BAA padrão nos planos Business e Enterprise. BAAs em papel do cliente são revisados nos planos Enterprise; modificações comuns (janelas de notificação de violação expandidas, atestações de salvaguardas adicionais, controles de subcontratados especificados pelo cliente) são aceitas. Entre em contato com [email protected] para o texto padrão ou para iniciar uma revisão de papel do cliente.
Onde os dados são armazenados? Clientes da UE têm como padrão Frankfurt (Hetzner FRA1, região UE). Clientes dos EUA podem escolher Ashburn (Hetzner ASH). Singapura (OVH SGP) está disponível para clientes APAC. A replicação entre regiões é opt-in por workspace; sem ela, todos os dados do cliente permanecem na região escolhida. O post sobre residência de dados cobre a arquitetura de residência em detalhes.
Qual criptografia está em uso? TLS 1.3 em trânsito em todos os endpoints externos (redirecionamento, API, dashboard, analytics). Criptografia de envelope AES-256 em repouso para o Postgres primário, cluster ClickHouse e object storage. O KMS fornecido pelo cliente é suportado nos planos Enterprise por meio da integração BYO KMS.
Como o acesso é provisionado e desprovisionado? Single sign-on por meio de SAML ou OIDC via WorkOS; provisionamento SCIM para o ciclo de vida do usuário. Controle de acesso baseado em funções ao nível de workspace com funções personalizadas disponíveis no Enterprise. O post sobre SCIM e SSO cobre a integração e os controles de ciclo de vida.
Qual é o seu processo de resposta a incidentes? Runbook documentado com um SLA de resposta inicial de 60 minutos, SLA de atualização técnica de 24 horas e rotações de comandantes de incidentes nomeados. As notificações de violação seguem os prazos em nosso BAA e em nosso DPA. O índice completo de runbooks está em /docs/runbooks/.
Quem são seus sub-processadores? Cinco sub-processadores nomeados: Hetzner (infraestrutura, UE), OVH (infraestrutura, APAC), Postmark (e-mail transacional), Cloudflare (proteção DDoS em superfícies de marketing públicas; não no plano de dados de redirecionamento), monobank Plata (faturamento para a base de clientes da UE). A lista completa com detalhes de contato está em /legal/subprocessors.
Por quanto tempo vocês retêm os dados do cliente? Eventos de clique retidos pelo prazo do contrato mais a janela de exportação de 30 dias no encerramento, e depois excluídos. Configuração de links retida pelo prazo do contrato mais a janela de exportação. Métricas agregadas (contagens de links por workspace, contagens de cliques por dia, sem PII) retidas além do contrato para faturamento e planejamento de capacidade interna.
O arquivo de evidências que um auditor deseja ver#
Se você for um cliente corporativo executando sua própria auditoria SOC 2 e a Elido for um fornecedor no escopo, seu auditor provavelmente solicitará evidências sob seus controles CC9.2 (gestão de fornecedores) e CC1.4 (compromissos). O arquivo do fornecedor deve conter:
- Nosso certificado ISO 27001 atual (renovável anualmente).
- Nosso relatório SOC 2 Type I e a carta de ponte do SOC 2 Type II (disponíveis sob NDA).
- Nosso DPA e BAA assinados, onde aplicável.
- Nossa lista de sub-processadores e as datas de quaisquer alterações.
- Snapshot da nossa página de segurança pública em
/truste a versão mais recente da política de privacidade. - Nosso histórico de notificações de violação (o histórico público está vazio — o log interno é revisado durante o processo de compras sob NDA).
O arquivo de evidências é criado uma vez por contratação de cliente e atualizado anualmente. A lista acima é o conjunto padrão; adições específicas de auditores são tratadas caso a caso.
O que é genuinamente difícil#
Duas coisas são genuinamente difíceis sobre SOC 2 e HIPAA para um serviço de redirecionamento, e as mencionamos porque a conversa de compras geralmente as traz à tona eventualmente.
A evidência de monitoramento contínuo para os POPs do edge não é trivial. O plano de dados de redirecionamento processa altos volumes de tráfego em três regiões, e o auditor quer evidências de que o monitoramento está operando continuamente, não apenas por amostragem. A abordagem atual utiliza redirecionamentos sintéticos de cada região a cada minuto, com o estado de alerta capturado em um log à prova de adulteração. O custo deste monitoramento é real e o design passou por três iterações para obter a relação sinal-ruído correta. O guia de observabilidade na documentação cobre a configuração atual; o ADR subjacente está em /docs/adr/0024-sla-monitoring.md.
Os prazos de notificação de violação do HIPAA são mais curtos que os do GDPR. O HIPAA exige a notificação dos indivíduos afetados em até 60 dias após a descoberta; para violações que afetam mais de 500 indivíduos, são necessárias notificações adicionais ao HHS e à mídia. O GDPR permite 72 horas para a autoridade de supervisão, mas o prazo de notificação do indivíduo afetado é "sem atraso indevido". Para uma violação multi-jurisdicional, o prazo do HIPAA geralmente domina. Comprometemo-nos com o prazo do HIPAA por padrão para qualquer incidente que toque dados de clientes roteados pelos EUA, e nosso runbook de resposta a incidentes reflete isso.
Leitura relacionada#
- GDPR para encurtadores de URL: o que seu DPO realmente quer ver — o pilar para o cluster de conformidade.
- Residência de dados na UE para marketing analytics — a arquitetura de residência e opções de fixação (pinning).
- Schrems II e seus pixels de rastreamento — contexto de avaliação de impacto de transferência.
- SCIM e SSO para ferramentas de marketing — os controles de controle de acesso que satisfazem o CC6.1.
- Atribuição de cliques após o Safari ITP — post adjacente sobre restrições de privacidade do lado do navegador.
- Passo a passo operacional: o guia de evidências SOC 2 na documentação — como a coleta de evidências funciona na prática.
- Superfície do produto:
/solutions/compliancee/solutions/enterprisepara elegibilidade de nível de plano e mapeamento de recursos.