Seguridad #

EthicsPortal gestiona datos sensibles de informantes. Esta página documenta las medidas técnicas y organizativas específicas que tenemos implantadas. Está dirigida a responsables de cumplimiento, delegados de protección de datos y equipos jurídicos que evalúan la plataforma.

Última actualización: 2026-11-04.

Cifrado de los datos #

Los campos sensibles de la base de datos que se indican a continuación se cifran en reposo mediante Rails ActiveRecord Encryption con cifrado no determinista (cada cifrado produce un texto cifrado único, lo que impide el análisis de patrones). El cifrado de campos no cubre los volcados completos de la base de datos ni los archivos adjuntos; estos se cifran por separado, como se describe en archivos adjuntos y copias de seguridad.

El cifrado no determinista significa que estos campos no pueden consultarse por valor a nivel de base de datos. Incluso con acceso total a la base de datos, un atacante no puede buscar un nombre concreto de informante entre los registros.

Archivos adjuntos #

Los archivos adjuntos a comunicaciones, mensajes y notas internas, las grabaciones de voz y las exportaciones de datos de casos se cifran en reposo en Hetzner Object Storage con AES-256, con una clave aleatoria distinta para cada archivo (cifrado del lado del servidor con claves proporcionadas por el cliente). La clave se envía con cada solicitud al almacenamiento, y Hetzner rechaza cualquier lectura realizada sin ella. EthicsPortal la guarda en la base de datos bajo el ActiveRecord Encryption descrito arriba, de modo que las credenciales del almacenamiento por sí solas no permiten leer un archivo: también se necesitan la base de datos y las claves de cifrado de la aplicación. Los archivos llegan a los usuarios autorizados mediante transmisión a través de la aplicación, nunca mediante un enlace directo al almacenamiento.

Los archivos subidos antes del 6 de octubre de 2026 se volvieron a cifrar en esa fecha, y se eliminaron sus copias sin cifrar, incluidas las versiones anteriores conservadas. Los archivos que no son datos de comunicaciones, como las fotos de perfil y las imágenes para compartir de las organizaciones, no se cifran de este modo. Nada de esto protege frente a un compromiso del servidor de la aplicación, que alberga a la vez las credenciales del almacenamiento, la base de datos y las claves.

Todas las conexiones a EthicsPortal usan HTTPS/TLS. Las solicitudes HTTP sin cifrar se redirigen.

Anonimato y privacidad #

Direcciones IP #

EthicsPortal no registra la dirección IP de un informante con las comunicaciones, los mensajes ni los registros de auditoría, y los registros de la aplicación del canal de denuncias no contienen direcciones IP.

La limitación de tasa en el canal de denuncias (presentación de comunicaciones, consulta de casos, mensajería) se basa en un hash SHA-256 con clave y truncado de la IP de la solicitud. El hash es seudónimo, no anónimo: no puede leerse como una dirección, pero cualquiera que disponga del secreto de la aplicación podría comprobar direcciones candidatas contra él. Se usa solo durante la ventana de limitación (10 minutos como máximo), y una tarea en segundo plano lo elimina de la caché en un plazo de 5 minutos tras el fin de la ventana.

El proxy TLS situado delante de la aplicación mantiene su propio registro de solicitudes: dirección IP, ruta de la solicitud, agente de usuario y estado de la respuesta. La ruta de la página en la que un informante consulta su comunicación contiene el identificador del expediente, por lo que una entrada de esa página puede vincularse a la comunicación. Se guardan en un único archivo de registro de 10 MB que se sobrescribe a medida que se llena, actualmente al cabo de unos dos días; las instantáneas del servidor de 7 días descritas en copias de seguridad pueden contener una copia.

Eliminación de metadatos de los archivos #

Los archivos subidos se depuran automáticamente de metadatos identificativos antes de su almacenamiento:

La eliminación de metadatos se realiza en el lado del servidor antes del almacenamiento. Para los tipos de archivo gestionados por exiftool, depende de que esté presente la herramienta de producción estándar.

Dentro de un PDF se conservan los nombres que figuran en los comentarios y los metadatos de las fotos incrustadas, como la posición GPS y el número de serie de la cámara. El informante que quiera eliminarlos debe subir las fotos como archivos de imagen independientes y eliminar los comentarios antes de subir un PDF.

Análisis antivirus #

Los archivos adjuntos a comunicaciones, mensajes y notas internas se analizan automáticamente en busca de malware mediante ClamAV, un motor antivirus de código abierto. El análisis se realiza en el lado del servidor en un proceso en segundo plano tras la subida. Los archivos que no han superado el análisis quedan bloqueados para su entrega, y los archivos infectados se eliminan automáticamente.

Los archivos se analizan en la infraestructura de EthicsPortal: no se envían datos de archivos a servicios de análisis de terceros.

Comunicaciones por correo electrónico #

Cada canal de denuncias tiene su propia dirección de correo electrónico en report.ethicsportal.eu. Un correo enviado a esa dirección se convierte en un caso de ese canal de denuncias, igual que una comunicación presentada mediante el formulario de denuncia en línea. Las comunicaciones por correo electrónico están activadas por defecto. Una organización puede desactivarlas en la configuración del canal; la dirección rechaza entonces el correo nuevo en menos de un minuto.

• Servidor de correo propio. El correo para estas direcciones lo recibe el propio servidor de correo de EthicsPortal, en la misma infraestructura en Alemania, y no un proveedor de correo externo. Solo acepta correo para las direcciones de los canales, rechaza cualquier otra dirección y no reenvía nada.
• Cifrado en tránsito. El servidor ofrece TLS 1.2 o superior con un certificado de Let’s Encrypt. El TLS es oportunista: un servidor remitente que no lo admite entrega el correo sin cifrar.
• Dirección del remitente oculta a los gestores. La dirección del remitente se almacena cifrada y nunca se muestra a los gestores del caso, ni en el caso, ni en su PDF, ni en las exportaciones. EthicsPortal solo la usa para enviar al informante el acuse de recibo y los avisos de nuevos mensajes.
• Acceso sin correo electrónico. El acuse de recibo contiene la referencia del caso y una contraseña de un solo uso para el buzón seguro, que se sustituye en el primer inicio de sesión. Las preguntas y respuestas de seguimiento se quedan en el buzón seguro, no en el correo. Cuando el propio dominio del remitente rechaza la dirección en su política DMARC, la comunicación se conserva, pero no se envía ninguna contraseña. Superadas 10 comunicaciones por correo electrónico a una organización, o 50 en todo EthicsPortal, en 24 horas, las siguientes se conservan pero no se envía ningún correo: ni acuse de recibo al informante ni aviso por correo a los administradores, que siguen viendo el caso en la aplicación.
• Archivos adjuntos. Los archivos reciben la misma eliminación de metadatos y el mismo análisis antivirus que los que se suben mediante el formulario. Los archivos que no se pueden aceptar (de otro tipo, demasiado grandes o imposibles de depurar) se descartan, y se informa al informante de cuántos son.
• Copias. Un mensaje espera en la cola del servidor de correo, en el mismo servidor, solo hasta que la aplicación lo acepta. La aplicación conserva el correo original cifrado hasta que se guarda el caso y después lo elimina. Los registros del servidor de correo anotan las direcciones de los canales, nunca la dirección del remitente.
• Comprobaciones del remitente. SPF, DKIM y DMARC se comprueban en la infraestructura de EthicsPortal. No se envía ningún dato de los mensajes a un servicio externo de antispam o de reputación.

El correo electrónico no es anónimo: el proveedor de correo del propio informante, y los sistemas de correo de la organización si escribe desde una cuenta del trabajo, pueden guardar copias y registros del mensaje. El acuse de recibo lo indica y enlaza al formulario de denuncia en línea para los informantes que quieran mantener el anonimato.

Correo para recibir novedades #

El formulario de denuncia en línea tiene un campo opcional de correo electrónico para recibir novedades. A esa dirección se envían el acuse de recibo y un aviso cuando un gestor escribe, nunca el contenido de la comunicación. Se almacena cifrada y, al igual que la dirección del remitente de una comunicación enviada por correo electrónico, no la muestra ninguna página de los gestores, ningún PDF ni ninguna exportación. Sigue disponible cuando el informante comunica de forma anónima. Solo si el informante desactiva la comunicación anónima y marca «mostrar también mi dirección de correo a los gestores del caso», la dirección se convierte en una dirección de contacto que ven los gestores.

Anonimato del gestor #

Los informantes nunca ven los nombres reales ni las direcciones de correo de las personas que gestionan su comunicación. Todos los mensajes de los gestores se muestran como «Gestor del caso». Esto protege la identidad del gestor y previene la ingeniería social.

Sin seguimiento #

EthicsPortal no usa cookies de seguimiento de terceros, píxeles publicitarios ni scripts de huella digital. Usamos Plausible Analytics solo en el sitio de presentación, servido desde nuestro propio dominio. No instala cookies ni almacena direcciones IP. Cloudflare, que entrega el sitio de presentación, trata metadatos de solicitud, incluidas direcciones IP, como se describe en el Aviso de privacidad. El propio canal de denuncias no tiene analítica.

Estado actual de las garantías #

EthicsPortal no reclama actualmente una certificación acreditada ISO 27001 en este sitio. Tampoco publica actualmente una auditoría independiente de terceros de la arquitectura de anonimato. Si esto cambia, el alcance y la fecha se publicarán aquí.

Materiales de revisión de seguridad #

Los clientes que requieran materiales de revisión de compras o jurídica pueden solicitarlos durante el proceso de compras. Los materiales disponibles pueden incluir un DPA firmado, pruebas registrales y fiscales, un cuestionario de seguridad cumplimentado y respuestas por escrito que cubran los procedimientos de copia de seguridad y restauración, el acceso privilegiado a producción y la gestión de la respuesta a incidentes.

Control de acceso #

La autorización se aplica a nivel de aplicación mediante políticas de Pundit.

• Los gestores no pueden ver comunicaciones a las que no están asignados ni en las que no participan. Los participantes los añade expresamente un administrador o el asignatario principal (por ejemplo, para implicar a jurídico o RR. HH.).
• Los informantes no tienen cuenta de usuario: abren su comunicación con una referencia del caso (WB-XXXX-XXXX) y una contraseña que el sistema genera cuando se presenta la comunicación.
• Cada acción de controlador comprueba la autorización. Los intentos de acceso no autorizado se bloquean y se registran.

Autenticación de dos factores #

Las cuentas de gestores y administradores pueden activar la autenticación de dos factores basada en TOTP mediante cualquier aplicación de autenticación estándar (Google Authenticator, 1Password, Authy y alternativas compatibles). Una vez activada, el inicio de sesión requiere tanto la credencial principal como un código rotativo de 6 dígitos.

Inicio de sesión del informante #

Los informantes inician sesión con su referencia del caso y una contraseña. La referencia del caso identifica el caso y no es secreta. La contraseña consta de 16 dígitos aleatorios y la genera el sistema cuando se presenta la comunicación; el informante no la elige. Se almacena únicamente como un resumen bcrypt, por lo que nadie puede recuperarla, y EthicsPortal no tiene ninguna función que permita al informante, al gestor del caso o al operador restablecerla. Si el informante la pierde, presenta una nueva comunicación y menciona la referencia del caso. Las comunicaciones presentadas antes del 18 de octubre de 2026 conservan la contraseña de 6 dígitos que el informante eligió en su momento, y esa contraseña sigue funcionando. La bandeja de seguimiento y la publicación de mensajes están protegidas por sesión tras esta comprobación, de modo que una referencia del caso filtrada por sí sola no puede leer la comunicación ni suplantar al informante.

Justo después de la presentación, una página de confirmación muestra la dirección del buzón seguro, la referencia del caso y la contraseña. Solo está disponible en ese navegador mientras el caso está desbloqueado, y desaparece cuando el buzón se bloquea tras 30 minutos sin actividad o cuando el informante sale. En la página de inicio de sesión, el campo de la contraseña es un campo de texto visible con el autocompletado desactivado, en lugar de un campo de contraseña enmascarado, para que los navegadores no ofrezcan guardar la contraseña, ya que un navegador gestionado por la empresa podría sincronizarla con la cuenta del empleador. Se puede pegar, y los espacios se ignoran.

Cuando el personal registra una comunicación recibida por teléfono, en una reunión presencial, por carta o por correo electrónico, y el informante quiere hacer seguimiento del caso en línea, el sistema genera una contraseña de un solo uso para que el gestor se la transmita. Solo sirve una vez: cuando el informante inicia sesión por primera vez, se sustituye, en el servidor, por una contraseña nueva que solo ve el informante.

El acceso del informante termina cuando selecciona «Salir» o tras 30 minutos sin actividad. Unos dos minutos antes del bloqueo, un aviso ofrece mantener el buzón abierto; si nadie responde, el caso desaparece de la pantalla. El acceso se guarda en una cookie cifrada en el navegador del informante, y el servidor no conserva ninguna sesión del informante.

Ciclo de vida de la sesión #

Cada sesión autenticada registra last_seen_at en cada solicitud (con antirrebote). Los usuarios pueden revisar sus sesiones activas, ver cuándo estuvo activa cada una por última vez, revocar cualquier sesión individualmente o cerrar todas las demás sesiones a la vez desde la configuración de la cuenta.

Las sesiones expiran automáticamente tras 14 días de inactividad. La siguiente solicitud de una sesión inactiva destruye el registro del lado del servidor, borra la cookie y obliga a una nueva autenticación mediante un enlace mágico nuevo. Un trabajo nocturno barre las sesiones abandonadas con el mismo tiempo de espera, de modo que user_agent e ip_address no se conservan más allá de la ventana de inactividad, ni siquiera cuando el usuario no vuelve nunca.

La autenticación con enlace mágico limita el alcance del impacto de las sesiones de larga duración: una cookie de sesión robada no proporciona una credencial reutilizable, y la nueva autenticación requiere acceso al correo electrónico.

Acceso de los miembros y baja #

El acceso a la organización se aplica en la frontera de la solicitud. Cuando se desactiva a un miembro:

• El acceso a la organización se rechaza de inmediato, incluso en URL previamente guardadas como favoritas.
• Las asignaciones de comunicaciones abiertas se anulan.
• Se eliminan las participaciones.
• Se conserva el historial del registro de auditoría atribuible al miembro.
• Se notifica al miembro desactivado.
• La reactivación no restaura automáticamente el acceso anterior a los casos.

El propietario de la organización, el último administrador activo y el responsable de cumplimiento designado del canal de denuncias no pueden desactivarse. Todos los eventos de desactivación y reactivación se escriben en el registro de auditoría en modo solo anexión.

Retirar a un miembro desactiva su pertenencia en lugar de eliminarla, de modo que el registro de auditoría y el historial de las comunicaciones siguen siendo resolubles. Una pertenencia solo se elimina definitivamente cuando se suprime la propia cuenta del miembro o la propia organización.

Supresión de la cuenta #

Cuando un miembro cierra su propia cuenta, su dirección de correo electrónico se sustituye por un marcador no enrutable y se eliminan definitivamente su foto de perfil, sus credenciales de dos factores, sesiones, tokens de API y preferencias; la cuenta ya no puede autenticarse ni ser contactada. Si la cuenta nunca actuó dentro de una organización, el registro se elimina por completo. En caso contrario, el nombre del miembro se conserva mientras sus pertenencias se desactivan, de modo que las notas de casos, los mensajes y las entradas de auditoría conservados siguen siendo atribuibles. El Responsable del tratamiento determina el plazo de conservación conforme a sus instrucciones documentadas y a la legislación aplicable; los derechos de supresión del RGPD quedan sujetos a las excepciones aplicables por obligaciones legales o reclamaciones.

Una cuenta depurada no puede autenticarse por ninguna vía: enlace mágico, aserción SSO ni token de API.

Limitación de tasa #

Los puntos de acceso públicos del canal de denuncias están sujetos a limitación de tasa para prevenir abusos y ataques de enumeración:

La limitación de tasa usa el hash con clave de la IP descrito más arriba: no se almacena ninguna dirección IP para ello. El límite por referencia del caso usa como clave la propia referencia del caso, que se elimina de la misma caché en un plazo de 15 minutos.

Auditoría y cumplimiento #

Registro de auditoría en modo solo anexión #

Los eventos definidos de comunicaciones y cuentas se registran con:

• Marca de tiempo (UTC)
• Actor (qué usuario o proceso del sistema realizó la acción)
• Tipo de acción (por ejemplo, comunicación creada, estado cambiado, mensaje enviado, gestor asignado, comunicación exportada o comunicación suprimida). Cada consulta de una comunicación por un gestor se registra, deduplicada a una entrada por gestor y por comunicación cada 24 horas, y las consultas de seguimiento del informante se registran del mismo modo. Las lecturas de otros recursos no se registran.

Las entradas del registro de auditoría son de solo anexión. Ningún usuario, incluidos los administradores de la organización, puede editar una entrada ni eliminar una de forma selectiva: los disparadores de PostgreSQL rechazan la modificación y el truncado a nivel de base de datos. Las entradas solo se eliminan por el ciclo de retención o cuando se elimina la propia organización, y la intervención privilegiada en la base de datos sigue siendo un riesgo residual documentado (registro de riesgos R-08). El registro de auditoría completo se incluye en las exportaciones de expedientes en PDF para revisión normativa.

Conservación de los datos #

Las organizaciones configuran su propio período de conservación: 12, 24, 36, 48 o 60 meses tras el cierre de una comunicación. Cuando el período de conservación expira, un trabajo en segundo plano suprime la comunicación y los datos asociados de producción; las copias de seguridad caducan conforme a su ciclo de vida documentado por separado.

Los correos enviados a un informante no dejan registro en el historial de envíos de EthicsPortal, por lo que no queda ninguna dirección de informante después de suprimirse la comunicación.

El Responsable del tratamiento sigue siendo responsable de elegir un período que cumpla la limitación del plazo de conservación del RGPD y las normas nacionales aplicables de conservación de registros.

Protección CSRF #

Todos los envíos de formularios están protegidos contra la falsificación de solicitudes entre sitios mediante los tokens CSRF integrados de Rails.

Ciclo de vida de desarrollo seguro #

EthicsPortal sigue un ciclo de vida de desarrollo documentado para los cambios que tocan el Servicio. Las fases se indican aquí para que un revisor de compras pueda asociarlas a los controles A.8.25-A.8.29 de la norma ISO/IEC 27001:2022 (consulte el mapa de controles para la correspondencia completa).

Gestión de dependencias y parches #

EthicsPortal no despliega componentes de software al final de su vida útil. La aplicación se ejecuta sobre versiones con soporte activo de Rails, Ruby, PostgreSQL y el sistema operativo subyacente; las versiones de seguridad upstream se aplican de forma continua.

Las dependencias se analizan de forma continua en la integración continua:

• Brakeman señala las vulnerabilidades específicas de Rails en cada cambio.
• bundler-audit comprueba el Gemfile con la Ruby Advisory Database en cada cambio y de nuevo a diario, de modo que los avisos recién divulgados se detectan incluso cuando no ha cambiado ningún código.
• importmap audit analiza las importaciones de JavaScript en busca de vulnerabilidades conocidas en cada cambio y de nuevo a diario.
• Dependabot abre solicitudes de incorporación de cambios semanalmente para las gemas de Ruby y las GitHub Actions desactualizadas, agrupadas por actualizaciones de versión menor/parche.

Los controles de la cadena de suministro limitan lo que puede alcanzar una versión comprometida de una dependencia:

• Periodo de espera. Las nuevas versiones de gems solo se adoptan tras llevar tres días publicadas; las actualizaciones de versión de Dependabot esperan 3, 7 o 14 días para versiones de parche, menores y mayores. Las versiones secuestradas suelen retirarse dentro de ese plazo.
• Acciones de CI fijadas. Cada paso de GitHub Actions está fijado a un SHA de commit completo, de modo que una etiqueta redirigida no puede cambiar lo que se ejecuta.
• Descargas verificadas. Los binarios descargados al construir la imagen del contenedor se comprueban con una suma de verificación SHA-256 fijada.
• Actualizaciones automáticas controladas. Las pull requests de Dependabot solo se fusionan automáticamente después de superar el conjunto completo de pruebas y el análisis estático.

Los componentes que alcanzan el final de su vida útil upstream se sustituyen o actualizan antes de que se cierre su ventana de soporte.

Infraestructura #

• El almacenamiento central de las comunicaciones y los datos de casos se encuentra en la Unión Europea. La entrega de correo electrónico y la telemetría de la aplicación tienen cadenas de proveedores posteriores propias; véase el DPA.
• No se almacenan números de tarjetas de crédito ni credenciales de pago en los servidores de EthicsPortal. Todos los datos de pago los gestiona Stripe.
• Mailjet envía las notificaciones a los gestores y, opcionalmente, los acuses de recibo y avisos de nuevos mensajes a los informantes. Los avisos a los informantes contienen la dirección de correo electrónico del destinatario, la referencia del caso y un enlace, pero no el relato de la comunicación. El acuse de recibo de una comunicación enviada por correo electrónico contiene además una contraseña de un solo uso para el buzón seguro, que se sustituye cuando el informante inicia sesión por primera vez. La cadena de soporte posterior de Mailjet puede implicar accesos desde fuera del EEE; véase el DPA.
• El sitio de presentación se sirve a través de Cloudflare (CDN, Estados Unidos); el canal de denuncias y la interfaz de los gestores no. Este tratamiento separado del sitio público y sus garantías de transferencia se describen en el Aviso de privacidad, no en la lista de subencargados del DPA del cliente.

Copias de seguridad y restauración #

EthicsPortal opera tres capas de copia de seguridad complementarias, todas conservadas dentro de la UE:

Objetivos de recuperación. El objetivo de punto de recuperación (RPO) es de 24 horas. El objetivo de tiempo de recuperación (RTO) es de 4 horas. Estos objetivos también figuran en el acuerdo de nivel de servicio.

Pruebas de restauración. Una prueba de restauración se ejecuta automáticamente cada mes mediante un flujo de trabajo de CI, y a demanda, restaurando el último volcado en un entorno desechable. Descifra el volcado, lo restaura, compara cada tabla con la producción en vivo y después arranca la aplicación contra la base de datos restaurada para confirmar que una columna cifrada sigue descifrándose, que un archivo adjunto cifrado se abre con la clave contenida en el volcado restaurado y que cada archivo adjunto con más de una hora de antigüedad tiene una copia en la ubicación de copia de seguridad, y se abre una de esas copias para cotejarla con su suma de verificación: el recuento de filas por sí solo no permite distinguir una copia utilizable de un texto cifrado cuya clave ya no coincide. La actualidad de las copias de seguridad se supervisa de forma continua (alerta si el volcado más reciente tiene más de 36 horas).

Cifrado. Según Hetzner, Object Storage no cifra objetos en reposo de forma predeterminada, por lo que los volcados de la base de datos se cifran antes de salir del servidor: GnuPG simétrico AES-256, con la contraseña en poder únicamente del proceso de copia y depositada fuera de la máquina. Los campos de la capa de aplicación cifrados con Rails ActiveRecord Encryption siguen cifrados por separado dentro de cada volcado. Los archivos adjuntos se cifran en reposo con claves por archivo (véase archivos adjuntos). Esas claves solo existen en la base de datos, por lo que cada volcado cifrado las contiene. Los archivos en sí no se copian en el volcado. Cada uno se guarda en Núremberg y se copia, con la misma clave, a un segundo bucket en Falkenstein; ambos conservan las versiones anteriores durante 28 días.

Revisión operativa #

Algunos materiales operativos se comparten durante la revisión de compras en lugar de publicarse en su totalidad en la web abierta, porque contienen detalles de infraestructura y de respuesta más apropiados para una divulgación controlada.

Entre los temas disponibles a petición durante el proceso de compras se incluyen:

• Resumen del acceso privilegiado a producción
• Flujo de trabajo de respuesta a incidentes y contactos de escalado
• Respuestas de continuidad de negocio y de baja/exportación del cliente

Divulgación responsable #

Si descubre una vulnerabilidad de seguridad en EthicsPortal, comuníquela a security@ethicsportal.eu. Le pedimos que:

1. No divulgue públicamente la vulnerabilidad antes de que hayamos tenido ocasión de abordarla.
2. Proporcione detalles suficientes para que podamos reproducir y corregir el problema.
3. No acceda ni modifique los datos de otros clientes.
4. No realice ataques de denegación de servicio ni escaneos automatizados masivos, no intente ingeniería social contra nuestro personal y no envíe comunicaciones a través del canal de denuncias de un cliente.

Acusaremos recibo de su comunicación en un plazo de 2 días laborables y nos esforzaremos por resolver las vulnerabilidades confirmadas con prontitud.

Sin programa de recompensas remunerado. La divulgación no se remunera: no pagamos por los informes de vulnerabilidades ni firmamos acuerdos de confidencialidad, aceptamos condiciones comerciales o mantenemos llamadas como requisito previo para recibir un informe. Envíe el activo afectado, los pasos de reproducción y el impacto que haya constatado a la dirección indicada.

Última actualización: 8 de noviembre de 2026