Resumen

  • La solicitud de propuestas publicada por ICANN el 5 de agosto busca un servicio SaaS integrado para políticas, riesgo empresarial y de terceros, auditoría interna, cumplimiento, paneles y recopilación automatizada de evidencia. Las ofertas vencen el 11 de septiembre; no hay proveedor, contrato ni implantación acreditados.
  • Un registro central debe mantener separadas las funciones de propietario del riesgo, operador del control, recolector de evidencia, verificador, responsable de corrección y supervisor. Una concordancia portable entre autoridad y evidencia podría conservar el rol, fundamento, procedencia, impugnación y rectificación que sostienen cada estado.

Que una casilla diga «cerrado» no significa que el sistema haya adquirido el poder de cerrar el asunto.

La diferencia parece obvia hasta que toda la organización empieza a mirar la misma pantalla. Esa es la cuestión de gobernanza que acompaña a la licitación de ICANN para una solución de Governance, Risk, and Compliance. El anuncio del 5 de agosto describe una plataforma mundial alojada que integre políticas, registros de riesgo, evaluación de terceros, auditoría interna, mapas de cumplimiento, informes y recopilación automática de documentación.

ICANN afirma que hoy esas actividades se distribuyen entre funciones, procesos en gran medida manuales y repositorios separados, con menor eficiencia, visibilidad y consistencia y más riesgo de versiones documentales.

Un expediente común puede resolver problemas reales. La aprobación de una política deja de depender de cuál copia abrió el lector. Un hallazgo de auditoría conserva su relación con la medida correctiva. Equipos dispersos utilizan los mismos identificadores. La evidencia aparece junto al periodo y control que pretende respaldar.

El peligro no reside en reunir datos, sino en reunir también significados y competencias. «Aceptado», «eficaz», «corregido» o «dentro del apetito» son conclusiones. Alguien con una atribución concreta las adopta para un alcance y un periodo, sobre evidencia susceptible de excepción o desacuerdo. La aplicación registra ese acto; no recibe por ello la autoridad para realizarlo.

La competición sigue abierta

El resumen público enumera una ambición extensa. La gestión de políticas incluiría creación, revisión, aprobación, publicación y automatización. El riesgo empresarial se alinearía con COSO e ISO 31000 y ofrecería registros centralizados a equipos descentralizados. El riesgo de terceros tendría evaluación, seguimiento y documentación. La auditoría interna cubriría plan, ejecución, hallazgos, correcciones e informes. La capa de cumplimiento relacionaría ISO/IEC 27001, SOC 2, SOC 3 y requisitos de privacidad. Los paneles mostrarían posturas y métricas en tiempo real, y las integraciones recopilarían evidencia de controles cuando fuera apropiado.

Entre los requisitos generales figuran un SaaS global, entorno certificado ISO 27001, alta disponibilidad, permisos por rol, trazas de auditoría, API, implantación, soporte y capacitación. La evaluación contempla funciones, automatización, informes, facilidad de uso, soporte, salud financiera, precios, referencias y mitigación de conflictos de interés.

Son criterios de selección, no resultados. Las propuestas deben llegar antes de las 23:59 UTC del 11 de septiembre. La evaluación está prevista del 14 de septiembre al 13 de noviembre y la diligencia, contratación y eventual adjudicación a partir del 16 de noviembre. ICANN puede alterar las fechas, rechazar propuestas, retirar la licitación o no adjudicarla. La documentación comprobada no identifica ganador ni plataforma operativa.

Además, el texto público no constituye todo el expediente: materiales adicionales se encuentran en SciQuest/Jaggaer. Resulta legítimo preguntar por portabilidad, salida, titularidad de datos, retención, incidentes o linaje de evidencia. No resulta legítimo afirmar que faltan en los materiales restringidos, en las ofertas o en un futuro contrato sólo porque no aparecen en el resumen público.

El mapa institucional antecede a la herramienta

El documento de octubre de 2022 sobre el marco de riesgo de ICANN asigna al presidente y director ejecutivo la propiedad global de los riesgos y la delegación funcional al ejecutivo correspondiente. La función de Risk Management facilita el marco y no se convierte en propietaria. Las funciones mantienen la responsabilidad próxima a la actividad que origina la exposición. El comité ejecutivo revisa informes y planes; el Consejo y su Risk Committee supervisan el marco y el tipo y nivel de riesgo aceptado.

Ese documento refleja 2022 y no certifica que cada detalle operativo siga igual. La carta vigente del Board Risk Committee, aprobada el 20 de julio de 2026, confirma el núcleo actual: supervisa identificación, evaluación, prioridad y mitigación, además del apetito y la tolerancia. En auditoría interna aprueba alcance, planes y presupuesto; examina la independencia de proveedores; recibe hallazgos; y conoce el estado de las acciones correctivas de la dirección.

Las actas de febrero de 2025 expresaron la separación de forma directa para aquel momento: el comité supervisaba la planificación, ejecución y resultados; la dirección respondía por la corrección.

Una plataforma no debe colapsar esas posiciones en un usuario genérico. Administrar el proceso no es poseer el riesgo. Probar un control no es operarlo. Supervisar una medida no es ejecutarla. Cerrar una tarea no equivale a resolver el juicio de auditoría.

Automatizar la captura no automatiza la conclusión

La evidencia automática puede ser mejor que capturas y archivos copiados a mano. Conserva frecuencia, fecha, fuente y cobertura con menos fricción. Una conexión con identidades, incidencias o infraestructura puede producir un historial más consistente.

Pero cualquier evidencia necesita una proposición. Una lista de cuentas desactivadas puede servir para comprobar una baja, no para acreditar que todo privilegio restante fue aprobado. Un parámetro confirma una configuración, no necesariamente sus excepciones. Un ticket finalizado acredita actividad, no la eficacia de la solución. Un panel recién actualizado puede conservar una hipótesis vieja.

La pregunta correcta es qué afirmación respalda la recogida, para qué población y periodo, mediante qué consulta o transformación, con qué excepciones y bajo la revisión de quién. La continuidad mejora la frecuencia; no fabrica relevancia ni juicio.

Una concordancia para que el estado conserve su sentido

La salvaguarda adecuada no es publicar riesgos sensibles. Es unir, en el expediente protegido, cada estado con el acto de autoridad que le da validez.

Cada riesgo, control, excepción, hallazgo o corrección material tendría un identificador estable, una función responsable y un rol. El registro distinguiría poseer, evaluar, aprobar, aceptar, probar, cuestionar, supervisar y corregir. También enlazaría la política, declaración de apetito, plan de auditoría o decisión que fundamenta la competencia.

La misma ficha conservaría afirmación, alcance y periodo, junto con procedencia: sistema de origen, colector o consulta, transformación, marca temporal, versión, cobertura y revisor. Las excepciones y pruebas contradictorias no desaparecerían. Todo cambio indicaría quién actuó, con qué rol, cuándo, por qué y qué impugnación o rectificación siguió.

Los accesos privilegiados del proveedor, los cambios de configuración y las transformaciones también formarían parte del historial. La exportación tendría que preservar identificadores, relaciones, decisiones y correcciones de manera comprensible para otro sistema y un revisor independiente. Descargar miles de PDF no es portabilidad si se pierde la relación que explica su significado.

Esta concordancia de autoridad y evidencia es una propuesta de Daniel Kade, no un requisito anunciado por ICANN. Busca que el sistema sea fuerte como custodio y deliberadamente débil como pretendida fuente de autoridad.

Transparencia sobre la estructura, reserva sobre el riesgo

ICANN no necesita publicar registros de riesgo, vulnerabilidades, papeles de auditoría, evidencia bruta, detalles de terceros, datos personales, asesoramiento jurídico ni correcciones sensibles. Puede ofrecer garantías proporcionales: mapa de autoridad aprobado, separación de funciones, independencia de auditoría, pruebas de procedencia y corrección, revisión de accesos privilegiados y un ensayo real de exportación.

También puede informar en agregado sobre acciones atrasadas al órgano competente sin revelar su contenido. La finalidad pública es mostrar que el estado del software no sustituye una decisión responsable.

La centralización ayuda cuando conecta hechos. Perjudica cuando fusiona roles que la gobernanza separó por una razón. La prueba duradera será si, tras la implantación o tras abandonar el producto, todavía puede responderse quién tenía autoridad, qué decidió, con qué evidencia y quién podía impugnarlo. Si esas respuestas sobreviven fuera del panel, la herramienta sirve a la gobernanza. Si sólo viven en la pantalla vigente, el tenedor de libros empieza a redactar la constitución.

Fuentes

  1. ICANN — anuncio de la licitación de la solución GRC, 5 de agosto de 2026
  2. ICANN — resumen del proyecto para la licitación Governance, Risk, and Compliance
  3. ICANN — resumen del marco de gestión de riesgos, octubre de 2022
  4. ICANN — carta del Board Risk Committee aprobada el 20 de julio de 2026
  5. ICANN — resolución que adopta la carta revisada del Risk Committee, 20 de julio de 2026
  6. ICANN — actas del Board Risk Committee, 10 de febrero de 2025