Sube tus políticas actuales y un estándar regulatorio, y pídele a Joy que los compare y te muestre dónde tus políticas se quedan cortas frente a los requisitos. Obtienes un análisis de brechas por escrito y accionable, no un montón de cláusulas por leer.
Compara nuestra [política] actual contra el [estándar regulatorio] en el Knowledge Center y muéstrame dónde nos quedamos cortos: para cada requisito, dime si nuestra política lo cumple, la brecha específica y qué cambiar.
Un ejemplo ilustrativo: tu resultado dependerá de tus fuentes, datos y peticiones.
Trabajé a partir de tu Política de Seguridad de la Información y el conjunto de controles del Anexo A de ISO 27001:2022 en el Knowledge Center. La mayoría de los controles están cubiertos; aquí están los cinco requisitos donde el lenguaje de la política todavía no cumple con el estándar.
Comparé tu Política de Seguridad de la Información (v4.2, aprobada en enero de 2026) contra el conjunto de controles del Anexo A de ISO 27001:2022 en el Knowledge Center. Cumples plenamente nueve de los catorce controles que revisé; los cinco de abajo son donde el lenguaje de la política se queda corto frente al estándar.
| Requisito | Política actual | Brecha | Solución recomendada |
|---|---|---|---|
| A.5.17 Información de autenticación | Exige contraseñas robustas rotadas cada 90 días en todos los sistemas | Sin requisito de multifactor; el estándar espera MFA en el acceso remoto y privilegiado | Agregar una cláusula que obligue a MFA para VPN, cuentas de administrador y cualquier servicio accesible desde el exterior |
| A.8.8 Gestión de vulnerabilidades técnicas | Ciclo de parcheo mensual referido en la sección de operaciones de TI | Sin plazos de remediación definidos por severidad, algo que el estándar trata como objetivo de control | Fijar SLA: críticas en 7 días, altas en 30, y registrar las excepciones con firma de aprobación |
| A.5.24 Planeación de gestión de incidentes | Nombra un equipo de respuesta a incidentes y un buzón de reporte | Sin clasificación de severidad ni ruta de escalamiento documentadas, así que la respuesta es improvisada | Agregar una matriz de severidad y una escalera de escalamiento atadas a ventanas definidas de respuesta y notificación |
| A.8.13 Respaldo de la información | Respaldos nocturnos de los sistemas de producción a una región secundaria | Sin cadencia de pruebas de restauración; el estándar exige verificar que los respaldos sean recuperables | Exigir una prueba de restauración trimestral documentada, con los resultados conservados para auditoría |
| A.5.19 Relaciones con proveedores | Los proveedores firman un NDA antes del onboarding | No se trasladan requisitos de seguridad a los proveedores que manejan datos regulados | Agregar un anexo de seguridad para proveedores y un nivel de riesgo que dispare una revisión antes de otorgar acceso |
Las dos brechas que hay que cerrar primero son A.5.17 y A.5.24. La falta de MFA es el tipo de hallazgo que un auditor levantará como no conformidad mayor, y un plan de incidentes sin un modelo de severidad y escalamiento tiende a fallar en el momento en que de verdad se pone a prueba. Las otras tres son reales pero de menor peso y pueden ir en la siguiente revisión.
¿Quieres que redacte las cláusulas faltantes de MFA y de severidad de incidentes, o que priorice las cinco brechas por riesgo de auditoría?
El Analizador de Brechas de Cumplimiento compara tus políticas actuales contra un estándar o marco regulatorio y te dice, para cada requisito, si tu política lo cumple, exactamente dónde está la brecha y qué cambiar. Pon tanto el estándar como tus políticas en el Knowledge Center y pídele a Joy que corra la comparación.
Sube al Knowledge Center tus documentos de política actuales y el estándar o marco regulatorio contra el que quieres medir. JoySuite indexa ambos para que Joy pueda alinear requisito contra texto de política.
Dile a Joy qué política verificar contra qué estándar. Joy recorre el estándar requisito por requisito y empata cada uno con el lenguaje relevante de tu política.
Joy devuelve una tabla: cada requisito, si tu política lo cumple, la brecha específica y una solución recomendada. Cada hallazgo apunta de vuelta a la sección de la política de donde salió para que puedas verificarlo.
Profundiza: «Redacta la cláusula de MFA que nos falta» o «¿Cuáles de estas trataría un auditor como una no conformidad mayor?». Copia el análisis a tu plan de remediación o a tus papeles de trabajo de auditoría.
Guarda esta petición como un comando personalizado en el asistente que tu equipo ya usa, para que cualquiera pueda correrla en un paso.
Recorre todo el conjunto de controles e informa sobre cada requisito, no solo un aprobado o reprobado general.
Cita el lenguaje de tu política frente al requisito para que veas exactamente qué falta o qué está demasiado débil.
Sugiere cambios concretos para cada brecha, y puede redactar la cláusula faltante cuando se lo pides.
Cada hallazgo enlaza de vuelta a la sección de la política de donde salió, para que verifiques antes de actuar.
Mide tus políticas de seguridad contra ISO 27001, SOC 2 o los conjuntos de controles de NIST.
Compara tu política de privacidad y tus DPA contra los requisitos de GDPR, CCPA o HIPAA.
Verifica las políticas de finanzas y reporteo contra los requisitos de SOX o PCI DSS.
Compara la política de una subsidiaria o proveedor contra tu estándar corporativo para detectar divergencias.
Un análisis de brechas de cumplimiento compara tus políticas y controles actuales contra los requisitos de un estándar o marco regulatorio para encontrar dónde te quedas corto. JoySuite lo corre requisito por requisito, diciéndote si cada uno se cumple, cuál es la brecha específica y qué cambiar.
Sube tus políticas y el estándar al Knowledge Center, luego pídele a Joy que los compare. Joy recorre el conjunto de controles, empata cada requisito con el lenguaje de tu política y devuelve una tabla de hallazgos con la brecha específica y una solución recomendada para cada uno.
Joy trabaja solo a partir del estándar y el texto de la política que le das, y cada hallazgo apunta de vuelta a la sección de la política de donde salió para que puedas verificarlo. Saca a la luz las brechas y recomienda soluciones; un responsable de cumplimiento sigue revisando y decidiendo qué adoptar.
Cualquier estándar que pongas en el Knowledge Center. Los equipos suelen verificar las políticas de seguridad contra ISO 27001, SOC 2 o NIST, las políticas de privacidad contra GDPR, CCPA o HIPAA, y los controles financieros contra SOX o PCI DSS. También puedes comparar una política interna contra otra.
Por defecto produce el análisis de brechas por escrito. Cuando se lo pides, Joy puede redactar el lenguaje de la cláusula faltante o revisada para que lo revises, pero nunca edita por su cuenta tus documentos de política en vivo. Tú copias lo que apruebas a tu plan de remediación o a la revisión de la política.
Únete a la lista de espera y sé de los primeros en probar este flujo de trabajo cuando JoySuite se lance.