Existe una implementación trazable en los repositorios revisados para el alcance indicado.
Seguridad y confianza
La confianza se diseña desde el principio.
docu.works organiza la información dentro de entornos controlados, con separación por organización, roles, permisos y mecanismos de trazabilidad.
Esta página describe arquitectura y controles trazables en el código revisado. No sustituye una auditoría, una certificación ni la validación del entorno de producción.
01Identidad
02Membresía del Hub
03Rol y alcance
Resultado esperadoAcceso al contexto necesario
Modelo de evidencia
Cada afirmación muestra el nivel de verificación disponible.
La arquitectura del producto, la base del sitio público y la operación de producción no son la misma evidencia. Por eso cada control conserva un estado visible.
La arquitectura o configuración existe, pero falta verificar su aplicación efectiva en el backend, proveedor o ambiente productivo.
El control o documento todavía no cuenta con implementación y evidencia suficientes para publicarse como disponible.
La estructura está prevista, pero el contenido requiere responsable legal, alcance contractual y aprobación humana.
Alcance de esta revisión
Se revisó el sitio público Angular/PHP/MySQL y la arquitectura de permisos del cliente de producto. Las reglas completas del backend de producto, la configuración del proveedor y la operación del ambiente productivo requieren evidencia separada antes de afirmar su cumplimiento.
01
Identidad y acceso
Cada persona accede solo al contexto que necesita.
El producto modela identidad, membresía, roles, perfiles y alcance por Hub y Espacio. La aplicación efectiva de estas decisiones debe permanecer en reglas y servicios de backend.
Autenticación
El cliente de producto integra Firebase Authentication, validación de sesión y verificación de correo. Proveedores, políticas y configuración productiva requieren validación operativa.
Roles
El modelo contempla propietario, administrador, responsable, miembro y solo lectura; la interfaz calcula experiencia, no la frontera de seguridad.
Permisos por Hub
La membresía del Hub conserva permisos y estado. Las reglas del backend deben comprobar esa membresía en cada lectura o escritura.
Permisos por Espacio
Perfiles y niveles pueden acotar Espacios, Colecciones y Docu.Types. La autoridad final debe validarse en reglas y funciones.
Acceso de colaboradores
Existe un flujo de invitación, membresía y asignación de alcance en el cliente, con operaciones sensibles mediadas por funciones.
Altas y bajas
El modelo distingue estados activo, inactivo, suspendido, pendiente, rechazado y eliminado. Falta validar el ciclo completo en producción.
Sesiones
Los guards revisan usuario, token y verificación de correo. Duración, revocación, alertas y políticas productivas deben documentarse por separado.
Autenticación multifactor
MFA no se presenta como disponible hasta completar integración, recuperación, soporte y validación de producción.
02
Separación de organizaciones
Cada Hub funciona como un entorno organizacional independiente.
Los datos, miembros y configuraciones se administran dentro del contexto autorizado de cada Hub.
Arquitectura, no garantía automática
El aislamiento efectivo depende de reglas backend versionadas, pruebas de autorización y configuración productiva. El cifrado de rutas o una opción oculta en la interfaz no sustituye esos controles.
EntornoHub A
Espacio 01Espacio 02
Contexto aisladoEntornoHub B
Espacio 01Espacio 02
Contexto aisladoEntornoHub C
Espacio 01Espacio 02
Contexto aislado03
Protección de datos
Publicamos el control y también lo que falta demostrar.
Los controles siguientes se limitan a evidencia concreta. Cuando dependen del hosting, Firebase, MySQL o la operación diaria, se marcan para validación de producción.
01NavegadorCaptura mínima, sin secretos ni acceso directo a la base de datos.
02Aplicación y APIValidación de entrada, autorización y contratos JSON del lado servidor.
03Proveedor y operaciónCifrado, almacenamiento, respaldo, monitoreo y respuesta verificables en producción.
Cifrado en tránsito
HTTPS es un requisito documentado de despliegue; debe comprobarse en los dominios y endpoints reales antes de publicarlo como control operativo.
Cifrado en reposo
Depende de la configuración efectiva de almacenamiento, bases de datos, backups y proveedor. No se afirma sin esa evidencia.
Gestión de secretos
El sitio público mantiene credenciales fuera de Angular y excluye configuración privada, variables, logs y datos locales del repositorio.
Restricciones de almacenamiento
Apache deniega el directorio privado y la API limita contenido, formato y tamaño; el acceso productivo debe conservar esas restricciones.
Validaciones de acceso
La API pública valida método, tipo de contenido, origen permitido y datos del lado servidor. Los permisos del producto requieren autoridad backend.
Retención
No existe aún una política aprobada ni eliminación automática de prospectos. Debe definirse por categoría, finalidad y obligación aplicable.
Eliminación
Los flujos verificables de solicitud, autorización, borrado y evidencia de ejecución todavía deben diseñarse y probarse.
04
Desarrollo seguro
La seguridad también forma parte de cómo cambia el producto.
El repositorio conserva controles técnicos de construcción. Los procesos organizacionales solo se describen como operativos cuando existe evidencia revisable.
Revisión de código
Git conserva cambios revisables, pero el requisito de aprobación, responsables y excepciones necesita un proceso formal verificable.
Dependencias
Versiones y licencias directas están registradas, el lockfile se conserva y el proyecto dispone de auditoría reproducible.
Análisis estático
TypeScript estricto y el compilador Angular detectan errores, pero no equivalen a un SAST de seguridad dedicado.
Pruebas
El sitio cuenta con pruebas automatizadas y un gate que valida formato, tests, imágenes y build de hosting.
Separación de ambientes
Angular separa desarrollo y producción; secretos y configuración de servidor permanecen fuera del bundle público.
Gestión de vulnerabilidades
La ruta pública existe, pero canal seguro, alcance, prioridades, tiempos y coordinación de divulgación siguen pendientes.
Control de cambios
El historial Git y las validaciones locales permiten cambios trazables; la aprobación operativa debe definirse según el riesgo.
Registro de despliegues
El build es reproducible, pero un inventario productivo de versiones, responsable, fecha y rollback requiere integración con el proveedor.
05
Disponibilidad y continuidad
La continuidad requiere operación, no solo arquitectura.
No se publican objetivos ni garantías hasta verificar respaldos, restauración, monitoreo, respuesta y responsables en el entorno real.
Consultar el estado actual del servicio
Backups
El checklist exige respaldos, pero frecuencia, alcance, cifrado, ubicación y evidencia productiva están pendientes.
Recuperación
Una restauración solo se considerará verificada cuando se ejecute una prueba y se documenten resultados y responsables.
Monitoreo
No hay todavía alertas ni observabilidad centralizada confirmadas para el servicio público.
Estado del servicio
La ruta está reservada, pero no representa monitoreo en tiempo real hasta conectar una fuente operativa.
Gestión de incidentes
Se deben definir severidades, escalamiento, comunicaciones, registro, aprendizaje y responsables.
Objetivos de recuperación
RTO y RPO solo se publicarán después de aprobación formal, capacidad técnica y pruebas periódicas.
06
Privacidad
La privacidad parte de reglas claras y un aviso integral.
El aviso integral suministrado identifica al Responsable, los datos tratados, las finalidades, transferencias, conservación y derechos. Su aplicación debe mantenerse alineada con los sistemas, proveedores y contratos reales.
Aviso de privacidad
El aviso integral con actualización del 20 de julio de 2026 está publicado en /privacidad. Su vigencia material depende de mantenerlo alineado con la operación y de la revisión jurídica correspondiente.
DPA
El acuerdo de tratamiento debe definir roles, instrucciones, seguridad, subprocesadores y terminación antes de publicarse.
Derechos ARCO
El aviso define buzon@anivia.mx, requisitos y plazos para Acceso, Rectificación, Cancelación y Oposición; la operación debe conservar evidencia y verificar identidad.
Subprocesadores
Existe una ruta inicial; la lista contractual espera confirmar proveedores, finalidad, ubicación y responsable.
Transferencias internacionales
No se afirman destinos ni mecanismos hasta contar con inventario de datos, proveedores y revisión jurídica.
Retención
El aviso define criterios generales de conservación, bloqueo y eliminación; los periodos específicos por sistema, respaldo y obligación deben documentarse.
Cookies y almacenamiento local
Idioma y región se conservan como preferencias necesarias. La medición propia y Google Analytics permanecen desactivados hasta recibir permiso; la publicidad y personalización están deshabilitadas.
07
Cumplimiento
Un estado preciso vale más que un logotipo.
Cada marco debe indicar su alcance, evidencia, responsable y fecha. Las categorías siguientes no conceden certificación por sí mismas.
No hay certificaciones públicas verificadas en esta versión.
No se muestran logotipos ni se afirma conformidad con ISO, SOC, PCI u otro marco. Cualquier cambio requiere evidencia formal y revisión humana.
Evaluación formal vigente emitida por una entidad autorizada para un alcance definido.
Controles comparados y documentados contra un marco, sin afirmar certificación.
Programa activo con alcance, responsables, brechas y evidencia en construcción.
Considerado para una etapa futura, sin programa formal iniciado.
Fuera del alcance documentado, con justificación y revisión correspondientes.
Los logotipos de certificaciones solo pueden aparecer después de obtenerlas formalmente y confirmar el alcance autorizado de uso.
08
Vulnerabilidades
Ayúdanos a investigar de forma responsable.
Si identificaste una posible vulnerabilidad en docu.works, repórtala de forma responsable para que nuestro equipo pueda investigarla.
El canal seguro y la política coordinada aún requieren aprobación. No envíes secretos, datos personales ni evidencia sensible mediante formularios generales.
09
Centro de confianza
Un catálogo público, con disponibilidad verificable.
Los recursos se publicarán como descargas únicamente después de revisión técnica, legal y operativa. Mientras tanto, la ficha muestra su estado real.
Resumen de seguridad
Síntesis ejecutiva de controles, alcance, evidencia, límites y responsables.
Descarga todavía no publicadaArquitectura
Diagrama revisado de componentes, fronteras de confianza, datos y responsabilidades.
Descarga todavía no publicadaLista de subprocesadores
Inventario contractual de proveedor, finalidad, ubicación y mecanismo aplicable.
Consultar estadoDPA
Acuerdo de tratamiento de datos aprobado para clientes y alcance correspondiente.
Descarga todavía no publicadaRespuesta a incidentes
Roles, severidades, escalamiento, comunicación y aprendizaje posterior.
Descarga todavía no publicadaContinuidad
Respaldo, recuperación, pruebas, dependencias y objetivos aprobados.
Descarga todavía no publicadaPreguntas frecuentes
Respuestas sobre alcance, evidencia, cifrado, certificaciones y documentos.
Consultar estadoEstado de certificaciones
Registro público del estado y alcance de cada marco sin insignias prematuras.
Consultar estadotrust.docu.works queda reservado como evolución futura del centro de confianza; esta versión canónica vive en /seguridad y no implica que el subdominio esté activo.
Preguntas frecuentes
Respuestas con el alcance visible.
¿Esta página demuestra la seguridad de producción?
No. Documenta evidencia de código y arquitectura revisada. La configuración, reglas, proveedores y operación productiva deben validarse de forma separada.
¿docu.works cuenta con certificaciones?
No se publica ninguna certificación verificada en esta versión. Cuando exista una, se mostrará su alcance, vigencia y entidad emisora.
¿Los datos están cifrados?
HTTPS es requisito de despliegue, pero el cifrado en tránsito y reposo solo se afirmará después de verificar dominios, servicios, almacenamiento, bases de datos y respaldos reales.
¿Puedo descargar el DPA o la arquitectura?
Todavía no. El catálogo mantiene visibles esos recursos, pero las descargas permanecerán cerradas hasta que el documento esté aprobado y sea consistente con la operación real.
Confiar antes de actuar
Revisemos el contexto y los requisitos de tu organización.
Comparte el proceso, los datos y el nivel de gobierno que necesitas. La demostración puede enfocarse en arquitectura, permisos y límites verificables.