Medidas de seguridad

Qué es esto. El Anexo II del contrato de encargo del tratamiento: las medidas del artículo 32 del RGPD que Huequia S.L. (NIF B05731047) aplica para proteger los datos que le confían los negocios.

Está escrito para que lo pueda leer quien decide, no solo quien programa. Y tiene un apartado —el 6— que dice qué no está hecho todavía, porque un anexo de seguridad que solo enumera aciertos no sirve para evaluar a nadie.

1. Principios

• Minimizar. La plataforma no pide ni guarda datos que no use. No hay analítica de comportamiento, ni píxeles, ni publicidad, ni venta de datos, ni entrenamiento de modelos con datos de clientes.
• Compartimentar. Los datos de cada negocio están separados de los de los demás, y los de categoría especial separados del resto.
• Registrar. Lo que se hace con los datos deja rastro, y ese rastro no se puede borrar desde la aplicación.
• Fallar cerrado. Ante la duda, el sistema deniega. Una consulta sin contexto de negocio no devuelve filas; un permiso que no consta, no existe.

2. Medidas técnicas y organizativas

• Cifrado en tránsito. TLS obligatorio en todas las conexiones, incluidas las de la base de datos. Las webs se sirven solo por HTTPS, con redirección forzada y HSTS.
• Cifrado en reposo. Los volúmenes de la base de datos y del almacenamiento de ficheros están cifrados por el proveedor. Los datos sensibles de configuración se cifran además en la propia columna.
• Separación entre negocios. Cada consulta a la base lleva el identificador del negocio y se ejecuta a través de una capa que lo impone; una consulta sin contexto de negocio no devuelve filas. El aislamiento a nivel de base de datos está desplegado parcialmente y su estado exacto se documenta en el registro interno.
• Control de acceso. Autenticación por identidades gestionadas, con permisos por rol y por operación. Los entornos internos y de vista previa están detrás de un control de acceso con identidad, no de una contraseña compartida.
• Documentos de categoría especial. Los consentimientos y cuestionarios de salud se guardan en almacenamiento privado, se sirven mediante enlaces firmados que caducan en sesenta segundos y cada descarga deja una fila en el registro de accesos.
• Registro y trazabilidad. Las operaciones sobre datos personales dejan registro de auditoría con autor, momento y objeto. El registro no se puede editar desde la aplicación.
• Depuración de datos personales en las trazas. Las trazas de error pasan por un depurador que elimina correos, teléfonos, credenciales e identificadores antes de salir de nuestra infraestructura.
• Copias de seguridad y recuperación. Copias automáticas diarias gestionadas por el proveedor de base de datos, dentro de la Unión, que rotan en un máximo de treinta días.
• Gestión de vulnerabilidades. Análisis automático de dependencias y de secretos en cada cambio propuesto. Ningún cambio llega a producción sin pasar la batería de pruebas y los análisis.
• Disponibilidad y vigilancia. Comprobaciones de salud internas, monitorización externa independiente de nuestra infraestructura y página de estado pública con el historial de incidentes.
• Minimización. La plataforma no pide datos que no use. No hay analítica de visitas ni de comportamiento, ni píxeles de seguimiento, ni publicidad, ni cesión de datos con fines comerciales, en ninguna de sus superficies.
• Separación entre encargos. Lo que decide un negocio sobre sus datos solo se ejecuta sobre los suyos: borrar o bloquear a un cliente en un negocio no toca su ficha en otro, y la cuenta de acceso común solo se cierra cuando lo pide su titular o cuando ya no la usa ningún negocio.
• Personal. El acceso a datos de producción está limitado a las personas que lo necesitan para prestar el servicio, sujetas a deber de confidencialidad expreso y por escrito.

3. Desarrollo y cambios

• Todo cambio pasa por revisión de otra persona y por una batería de pruebas automáticas antes de llegar a producción.
• Cada cambio propuesto se analiza en busca de secretos filtrados y de dependencias vulnerables; si el análisis falla, el cambio no entra.
• Los entornos de desarrollo, vista previa y producción están separados y el acceso a los internos exige identidad, no una contraseña compartida.
• Las credenciales de producción se guardan cifradas y no viajan por correo ni por mensajería.

4. Gestión de incidentes

4.1. Existe un procedimiento escrito de respuesta con responsable asignado, canal de recepción (ops@huequia.com) y plantillas de comunicación.

4.2. Ante una violación de la seguridad que afecte a datos de un negocio, se le notifica dentro de las veinticuatro horas desde que la conocemos, con lo que se sepa en ese momento y ampliaciones posteriores si hace falta. La notificación a la Agencia y a los interesados corresponde al negocio, como responsable, y se le presta toda la asistencia para hacerla dentro de las 72 horas del artículo 33.

4.3. Cada incidente se documenta con su causa, su alcance, las medidas adoptadas y las correcciones aplicadas.

4.4. El estado del servicio y el historial de incidentes de disponibilidad se publican en la página de estado.

4.5. Las aplicaciones móviles son productos con elementos digitales a efectos del Reglamento (UE) 2024/2847, de ciberresiliencia. Desde el 11 de septiembre de 2026, si una vulnerabilidad de cualquiera de ellas se explota activamente, o un incidente grave afecta a su seguridad, lo notificamos por la plataforma única de notificación de ENISA, que lo traslada al equipo nacional de respuesta: alerta temprana en veinticuatro horas, notificación en setenta y dos e informe final en catorce días desde que hay corrección (o en un mes, si es un incidente). Además informamos a quienes usan la aplicación del problema y de lo que pueden hacer para protegerse.

5. Dónde está la infraestructura y quién podría pedir acceso

El artículo 28 del Reglamento de Datos obliga a decir a qué jurisdicción está sometida la infraestructura que presta el servicio, y qué se hace frente a un acceso de autoridades de fuera de la Unión que contradiga el Derecho europeo.

• Jurisdicción. La base de datos y los ficheros están en la Unión Europea (Irlanda), y las trazas de error, también (Alemania). La API y las webs se ejecutan en el Reino Unido, y los buzones de correo están en Suiza. Algunas de las sociedades que operan esa infraestructura están domiciliadas en Estados Unidos y en Singapur, y quedan sometidas también a sus leyes. El detalle, proveedor por proveedor, está en la página de subencargados.
• Medidas. Cifrado en tránsito y en reposo; minimización de lo que sale de nuestra infraestructura; contratos que obligan a cada proveedor a tratar los datos solo conforme a nuestras instrucciones, a avisarnos de cualquier solicitud de una autoridad salvo que se le prohíba y a impugnarla cuando haya motivos; y el compromiso propio de avisar al negocio y de impugnar nosotros esas solicitudes en los mismos términos (cláusula 8.4 del contrato de encargo).

6. Lo que todavía no está hecho

Este apartado existe porque un anexo de seguridad sin él no permite evaluar nada. Estado a 1 de octubre de 2026:

Este apartado se actualiza cuando cambia el estado de cualquiera de las líneas. Si alguna de ellas es determinante para contratar, conviene decirlo antes de firmar y no después.

7. Comunicar una vulnerabilidad

Si encuentras un fallo de seguridad, escríbenos a ops@huequia.com. Pedimos lo de siempre:

• Danos un plazo razonable para corregirlo antes de hacerlo público.
• No accedas a datos que no sean tuyos, no los descargues y no los conserves.
• No degrades el servicio: nada de pruebas de denegación de servicio ni de fuerza bruta contra cuentas reales.

A cambio: acusamos recibo en cuarenta y ocho horas hábiles, te contamos qué hemos hecho, y no emprenderemos acciones legales contra quien investigue de buena fe respetando lo anterior.

8. Revisión

Estas medidas se revisan al menos una vez al año y cada vez que se produzca un cambio relevante en la plataforma o un incidente que aconseje revisarlas. Cualquier modificación que reduzca el nivel de protección se comunica a los negocios con treinta días de antelación.