7 Señales de que tu Creador de Formularios en Línea No es Seguro para Datos Sensibles

La mayoría de los creadores de formularios se ven similares desde el exterior. Un editor de arrastrar y soltar, un botón de publicación, notificaciones por correo electrónico al enviar. Nada en esa interfaz te dice si los datos están encriptados, quién puede acceder a ellos, o a dónde van después de la recopilación.

Las fallas de seguridad en los creadores de formularios rara vez son visibles antes de convertirse en un problema. Aparecen en notificaciones de violación, auditorías de cumplimiento, o solicitudes de usuarios que quieren saber qué pasó con sus datos.

Sin embargo, las señales de advertencia son en su mayoría visibles con anticipación, en la documentación, en los conjuntos de características y en las respuestas a preguntas específicas. Este artículo cubre siete de ellas.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Consulte a un profesional calificado en protección de datos para obtener orientación específica para su organización.

Señal 1: No hay Acuerdo de Procesamiento de Datos disponible

Un Acuerdo de Procesamiento de Datos (DPA) es un contrato legalmente vinculante entre la organización que recopila datos (el controlador) y la plataforma que los procesa (el procesador). Donde se aplica el GDPR y un controlador utiliza un procesador de terceros, el Artículo 28 requiere un Acuerdo de Procesamiento de Datos conforme antes de que el procesador maneje datos personales en nombre del controlador.

El contrato debe definir, como mínimo: el objeto y la duración del procesamiento, el tipo de datos y categorías de individuos involucrados, las instrucciones del controlador al procesador, las obligaciones de seguridad, la divulgación de subprocesadores, los procedimientos para manejar solicitudes de derechos de los interesados, los plazos de notificación de violaciones, y la eliminación o devolución de datos al finalizar el contrato.

Esto no es una casilla de verificación. El Artículo 28(3) especifica explícitamente cada uno de estos elementos. Una política de privacidad no es un DPA. Los términos de servicio no son un DPA. Un DPA es un instrumento bilateral separado firmado por ambas partes.

La señal: El sitio web del creador de formularios no tiene un DPA descargable. Buscar “DPA” o “Acuerdo de Procesamiento de Datos” no arroja resultados, o redirige a una política de privacidad general.

Lo que esto significa en la práctica: Sin un DPA firmado, usar la plataforma para recopilar datos personales de individuos en la UE crea una exposición legal para su organización, no para la plataforma. Bajo el GDPR, el controlador (usted) tiene la responsabilidad principal de asegurar que haya un acuerdo conforme al Artículo 28. No tener un acuerdo de procesamiento conforme al Artículo 28 es en sí mismo un problema de cumplimiento, independientemente de si ocurre una violación de datos personales.

Principios de responsabilidad similares existen bajo otros marcos de privacidad. CCPA/CPRA, la LGPD de Brasil y la PIPEDA de Canadá esperan que las organizaciones utilicen salvaguardias contractuales apropiadas al contratar proveedores de servicios de terceros, aunque los mecanismos legales difieren del Artículo 28 del GDPR.

Qué buscar: Un DPA disponible públicamente y descargable que pueda ser firmado sin requerir una negociación empresarial. Para organizaciones bajo el GDPR, el DPA también debe abordar los subprocesadores, los terceros en los que el creador de formularios confía para infraestructura, almacenamiento o procesamiento. El centro de confianza de un proveedor suele ser el lugar adecuado para encontrar esta documentación. Para una lista de verificación completa de implementación del GDPR, consulte Cumplimiento del GDPR para Formularios en Línea: Una Lista de Verificación Práctica.

Señal 2: Scripts de terceros se ejecutan en las páginas de formularios sin divulgación

Cuando un usuario abre su formulario, puede estar compartiendo sus datos con más que solo usted.

La mayoría de las aplicaciones web, incluidos los creadores de formularios, cargan JavaScript de terceros para análisis, publicidad, grabación de sesiones, monitoreo de errores y pruebas A/B. Algunos de estos scripts tienen acceso a los valores de los campos del formulario a medida que los usuarios escriben. Esto significa que un nombre, dirección de correo electrónico o número de teléfono puede salir del dispositivo del usuario antes de que haya hecho clic en “Enviar.”

Este es un comportamiento documentado. Un estudio de 2022 realizado por investigadores de la Universidad de Radboud, KU Leuven y la Universidad de Lausana, titulado “Formularios Fugas: Un Estudio de Exfiltración de Correos Electrónicos y Contraseñas Antes de la Envío del Formulario”, encontró que 1,844 sitios web en una muestra de 100,000 recopilaban direcciones de correo electrónico de usuarios antes de la envío del formulario a través de scripts de seguimiento de terceros, sin el consentimiento del usuario. Los datos fueron exfiltrados silenciosamente, antes de que ocurriera cualquier evento de envío.

El mecanismo es sencillo: los scripts de análisis y marketing adjuntan oyentes de eventos a los campos de entrada y transmiten el contenido a puntos de recopilación remotos. El propio creador de formularios puede no pretender este comportamiento, pero si los scripts de terceros se cargan en la misma página, los datos fluyen hacia ellos de todos modos.

La señal: El creador de formularios no documenta qué scripts de terceros se ejecutan en las páginas de formularios publicados. Su política de privacidad describe su propia recopilación de datos, no el comportamiento de recopilación de los scripts que se ejecutan en sus formularios.

Lo que esto significa en la práctica: Si su formulario carga un píxel de análisis de terceros o una herramienta de grabación de sesiones, los datos que sus usuarios escriben pueden ser transmitidos a ese tercero sin consentimiento. Esto afecta la precisión de su política de privacidad, su cumplimiento del GDPR (base legal para el procesamiento), y en contextos de salud, potencialmente sus obligaciones bajo HIPAA.

Qué buscar: Documentación explícita de los scripts cargados en las páginas de formularios publicados. Una plataforma que maneja datos sensibles debería poder indicar, con precisión, qué servicios reciben datos de los envíos de formularios y en qué forma. Formularios servidos en dominios aislados de primera parte sin scripts de publicidad o análisis son la solución más sólida.

Señal 3: Las afirmaciones de encriptación son vagas o están ausentes

“Sus datos están seguros” es una declaración de marketing. No describe un control técnico. Dos afirmaciones específicas importan para los datos de formularios:

Encriptación en tránsito significa que los datos están encriptados mientras viajan entre el navegador del usuario y el servidor. El estándar actual es TLS 1.2 o superior. Esto es ampliamente estándar en la web, pero debería indicarse explícitamente, con la versión del protocolo.

Encriptación en reposo significa que los datos almacenados, los envíos de formularios que están en una base de datos, están encriptados. El estándar actual para datos sensibles es AES-256. Aquí es donde las plataformas difieren. Algunas encriptan los datos de envío en reposo; muchas no. Una plataforma puede tener una excelente encriptación en tránsito mientras almacena sus datos en texto claro.

La distinción importa porque los modelos de amenaza son diferentes. La encriptación en tránsito protege contra la interceptación durante la transmisión. La encriptación en reposo protege contra el acceso no autorizado a los datos almacenados, que es la amenaza relevante en la mayoría de los escenarios de violación. Según el Informe de Costo de una Violación de Datos de IBM 2025, la violación promedio tarda 158 días en identificarse y 83 días en contenerse, un ciclo de vida total de 241 días, el más bajo en nueve años, según IBM Security. Durante esa ventana, los datos almacenados son la exposición principal.

El Top 10 de OWASP (2025) enumera “Fallos Criptográficos” como A04, uno de los riesgos más críticos de seguridad de aplicaciones web, específicamente incluyendo “datos almacenados en texto claro” como un modo de falla principal.

La señal: La documentación de seguridad de la plataforma utiliza frases como “usamos seguridad estándar de la industria” sin especificar el algoritmo de encriptación, la versión del protocolo o el alcance de la cobertura. No hay mención de AES-256 o TLS 1.2+.

Lo que esto significa en la práctica: Las afirmaciones vagas de encriptación no proporcionan ninguna garantía verificable. Para datos regulados, salud, finanzas, legales, la encriptación en reposo es frecuentemente un requisito de cumplimiento, no una preferencia. La Regla de Seguridad de HIPAA (45 CFR § 164.312) aborda específicamente la encriptación como una salvaguarda “direccionable”, lo que significa que las entidades cubiertas deben implementarla o documentar por qué una alternativa equivalente proporciona la misma protección.

Qué buscar: Una declaración técnica clara: “Los datos de envío están encriptados en reposo usando AES-256 y en tránsito usando TLS 1.2+.” Si esto no se puede encontrar en la documentación pública, típicamente en el centro de confianza o página de seguridad de un proveedor, pregunte directamente. Una plataforma que maneja datos sensibles debería responder sin ambigüedades. Para un desglose completo de cómo debería ser la pila de seguridad, consulte Seguridad de Datos para Formularios en Línea: Lo que Toda Empresa Debería Saber.

Señal 4: No hay retención de datos configurable

¿Cuánto tiempo almacena la plataforma sus datos de envío? Si la respuesta es “indefinidamente, a menos que los elimine manualmente”, eso es un problema.

El principio de limitación de almacenamiento del GDPR (Artículo 5(1)(e)) requiere que los datos personales se “mantengan en una forma que permita la identificación de los interesados por no más tiempo del necesario para los fines para los que se procesan los datos personales.” Almacenar envíos de formularios para siempre, incluso de hace años, casi nunca cumple con este requisito.

También hay un riesgo práctico: cuanto mayor sea el conjunto de datos que posea una plataforma, más valioso se vuelve como objetivo de violación. Los envíos de formularios de hace tres años, aún en un servidor, todavía están en riesgo. La eliminación automática reduce esa exposición.

Diferentes flujos de trabajo tienen diferentes necesidades legítimas de retención:

La señal: La plataforma almacena envíos indefinidamente por defecto. No hay configuraciones para configurar un horario de eliminación automática. La única opción es la eliminación manual.

Lo que esto significa en la práctica: El cumplimiento de los requisitos de retención de datos depende de la acción humana. Las políticas automatizadas no. Una organización que depende del personal para eliminar manualmente los envíos de formularios antiguos eventualmente perderá un ciclo de eliminación, especialmente durante transiciones de personal o períodos de alto volumen.

Qué buscar: Períodos de retención configurables a nivel de cuenta o formulario. El rango debería acomodar tanto retención corta (para flujos de trabajo de alta privacidad) como retención extendida (para mantenimiento de registros requerido por cumplimiento). Opciones como “eliminar inmediatamente después de exportar a almacenamiento en la nube” representan la mejor práctica para flujos de trabajo críticos de privacidad.

Señal 5: No hay registro de auditoría para el acceso a envíos

Cuando se abre un envío, ¿quién lo abrió? ¿Cuándo? ¿Alguien lo exportó? ¿Se compartió a través de un enlace? ¿Se eliminó, y por quién?

En ausencia de un registro de auditoría, ninguna de estas preguntas puede ser respondida. Esto crea una brecha significativa de responsabilidad, una que se hace visible en auditorías regulatorias, solicitudes de acceso de los interesados, o investigaciones internas.

La Regla de Seguridad de HIPAA aborda explícitamente esto. El estándar de controles de auditoría (45 CFR § 164.312(b)) requiere que las entidades cubiertas “implementen mecanismos de hardware, software y/o procedimientos que registren y examinen la actividad en sistemas de información que contengan o utilicen información de salud protegida electrónica.” Registrar quién vio un envío y cuándo es una implementación directa de este requisito.

Más allá de la salud: el Artículo 5(2) del GDPR establece el principio de responsabilidad, los controladores deben poder “demostrar cumplimiento” con los principios de protección de datos. Un registro de auditoría es un componente fundamental de esa demostración. Sin él, “no accedimos a esos datos” es una afirmación que no puede verificar.

El Top 10 de OWASP (2025) incluye “Fallos de Registro y Alerta de Seguridad” (A09) como un riesgo crítico de aplicaciones web, específicamente: “Eventos auditables, como inicios de sesión, inicios de sesión fallidos y transacciones de alto valor, no se registran.”

La señal: La plataforma no tiene registro de actividad. Los administradores pueden ver envíos pero no pueden ver el historial de acceso, historial de exportación o actividad de compartición.

Lo que esto significa en la práctica: No puede responder preguntas sobre quién accedió a envíos específicos. Si un interesado ejerce su derecho de acceso bajo el Artículo 15 del GDPR, puede solicitar información sobre los destinatarios o categorías de destinatarios con los que se ha compartido su información personal, una pregunta que un registro de auditoría ayuda a responder. Si bien el Artículo 15 no requiere que los controladores mantengan registros de auditoría, tales registros pueden ayudar significativamente a demostrar cumplimiento y responder con precisión a las solicitudes de acceso.

Qué buscar: Un registro de auditoría a nivel de equipo accesible para administradores, que registre como mínimo: eventos de acceso a envíos, eventos de exportación, creación de enlaces de compartición y eventos de eliminación. Los registros deben conservarse por un período consistente con sus requisitos de cumplimiento.

Señal 6: No hay BAA disponible para casos de uso en salud

En los Estados Unidos, cualquier organización que maneje Información de Salud Protegida (PHI) en nombre de una entidad cubierta, incluido un creador de formularios que procese formularios de admisión de pacientes, es legalmente un Asociado Comercial bajo HIPAA (45 CFR § 160.103).

Antes de que cualquier PHI fluya a través de una herramienta de terceros, debe haber un Acuerdo de Asociación Comercial (BAA) firmado. El BAA no es solo una formalidad: establece las obligaciones del Asociado Comercial con respecto a la protección de PHI, los plazos de notificación de violaciones y los usos permisibles de los datos. Sin él, la entidad cubierta asume la responsabilidad por violaciones de HIPAA derivadas del manejo de PHI por parte del Asociado Comercial, independientemente de los controles de seguridad reales de la plataforma.

La OCR ha aplicado consistentemente este requisito. Se han alcanzado acuerdos contra organizaciones de salud por usar herramientas de terceros no autorizadas para procesar PHI, incluso en ausencia de una violación. La violación es el acuerdo faltante, no la violación.

Para las salvaguardas técnicas específicas que HIPAA requiere, que un creador de formularios debe implementar para firmar válidamente un BAA, consulte lo que HIPAA realmente requiere de las herramientas de formularios en línea.

La señal: La plataforma no ofrece un BAA, o lo ofrece solo en niveles de precios empresariales inaccesibles para la mayoría de las organizaciones de salud. Pequeñas clínicas, terapeutas independientes y startups de salud se quedan recopilando PHI sin una relación de procesamiento conforme.

Lo que esto significa en la práctica: Usar un creador de formularios sin un BAA para recopilar datos de pacientes, formularios de admisión, formularios de consentimiento, solicitudes de citas, detalles de seguros vinculados a información de salud, es una violación de HIPAA. No es un área gris.

Qué buscar: Un BAA disponible en un plan de mercado medio, firmado automáticamente (o con mínima fricción) cuando se habilita el modo HIPAA. El BAA firmado debe ser entregado al administrador de la cuenta como un documento que puedan conservar y producir en una auditoría.

Señal 7: No se pueden eliminar envíos individuales a solicitud

El Artículo 17 del GDPR establece el derecho al borrado. Cuando un interesado solicita la eliminación de sus datos personales, el controlador debe cumplir sin demora indebida y en cualquier caso dentro de un mes, sujeto a excepciones limitadas (obligación legal, interés público, etc.). La solicitud se aplica a los datos del individuo específico, no a archivos masivos.

Esto crea un requisito técnico: debe poder identificar el envío de un individuo específico y eliminarlo limpiamente. Muchas plataformas hacen esto difícil. La eliminación masiva a menudo está disponible; la búsqueda y eliminación dirigida por respondente no lo está.

El mismo problema afecta el cumplimiento proactivo. Si su política de retención especifica la eliminación después de 90 días, necesita que la plataforma lo haga cumplir a nivel de registro, no solo proporcionar un botón de “borrar todo” que borre todo.

La señal: La interfaz de envío no tiene búsqueda por identificador de respondente (correo electrónico, nombre). La eliminación es solo masiva. No hay forma de identificar todos los envíos de un individuo específico a través de múltiples formularios.

Lo que esto significa en la práctica: Cuando un usuario presenta una solicitud de eliminación, que el GDPR les da derecho a hacer, cumplirla se convierte en un proceso manual y propenso a errores. Si los envíos abarcan múltiples formularios o períodos de tiempo, encontrar y eliminar todos los registros relevantes se vuelve operacionalmente difícil.

Qué buscar: Búsqueda de envíos por valor de campo, incluyendo dirección de correo electrónico, nombre o cualquier campo identificador. Eliminación de registros individuales desde la interfaz de envío. Para organizaciones bajo el GDPR, la capacidad de ejecutar una consulta cruzada por respondente es valiosa.

Una lista de verificación

Antes de publicar cualquier formulario que recopile datos sensibles:

• Hay un DPA descargable y firmable disponible desde la plataforma
• La plataforma documenta qué scripts de terceros se ejecutan en las páginas de formularios publicados
• La encriptación en reposo (AES-256) y en tránsito (TLS 1.2+) están explícitamente indicadas
• La retención de datos es configurable, con opciones de eliminación automática
• Un registro de auditoría registra el acceso a envíos y eventos de exportación
• Si se recopila PHI, un BAA firmado está en su lugar antes de que se recopilen datos
• Los envíos individuales pueden encontrarse y eliminarse por respondente

Referencias

• Parlamento Europeo y Consejo, Artículo 28 del GDPR — Obligaciones del procesador y requisitos de la DPA, gdpr-info.eu/art-28-gdpr/
• Parlamento Europeo y Consejo, Artículo 15 del GDPR — Derecho de acceso del interesado, gdpr-info.eu/art-15-gdpr/
• Parlamento Europeo y Consejo, Artículo 17 del GDPR — Derecho al borrado, gdpr-info.eu/art-17-gdpr/
• Oficina de Derechos Civiles del HHS, 45 CFR § 160.103 — Definiciones (Asociado de Negocios), ecfr.gov
• Oficina de Derechos Civiles del HHS, 45 CFR § 164.312 — Salvaguardas técnicas, ecfr.gov
• Oficina de Derechos Civiles del HHS, Contratos de Asociados de Negocios, hhs.gov
• Acar, G. et al., Formularios con Fugas: Un Estudio sobre la Exfiltración de Correos Electrónicos y Contraseñas Antes de la Presentación del Formulario, Universidad de Radboud / KU Leuven / Universidad de Lausana, presentado en USENIX Security 2023
• OWASP, OWASP Top 10 2025, owasp.org/Top10 . A04 Fallos Criptográficos; A09 Fallos en el Registro y Alerta de Seguridad
• IBM Security, Informe sobre el Costo de una Brecha de Datos 2025, ibm.com/reports/data-breach . ciclo de vida promedio de una brecha 241 días (158 para identificar, 83 para contener)

Lecturas relacionadas: Cumplimiento del GDPR para Formularios en Línea: Una Lista de Verificación Práctica · Formularios en Línea Cumplientes con HIPAA: Una Guía 2026 · Seguridad de Datos para Formularios en Línea: Lo que Toda Empresa Debería Saber