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 5— 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 diarias gestionadas por el proveedor de base de datos, con retención de treinta días y recuperación a un instante concreto.
• 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 comportamiento, ni píxeles de seguimiento, ni publicidad, ni cesión de datos con fines comerciales.
• 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.

5. Lo que todavía no está hecho

Este apartado existe porque un anexo de seguridad sin él no permite evaluar nada. Estado a 6 de septiembre 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.

6. 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.

7. 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.