Hemos estado trabajando estos meses en la implementación de controles SOX. La Ley Sarbanes-Oxley (SOX), aprobada en Estados Unidos en 2002, se centra específicamente en la transparencia y precisión de los informes financieros de las empresas públicas, vía la imposición de un control interno exhaustivo que previene fraudes y malas prácticas.
Precisamente, el estar centrado en la información financiera y protección del inversor es lo que marca la diferencia con otras leyes de cumplimiento como GDPR, HIPAA o PCI-DSS. En todos los casos, a partir de la identificación de un potencial riesgo, se desarrolla una norma que lo previene o determina actuación ante el fallo de cumplimento. A esta norma han de adaptarse los sistemas informáticos.
Hay otros casos, sea un ejemplo las tecnologías de inteligencia artificial, donde no es tan fácil la concreción de este riesgo, el diseño de la norma y por tanto su cumplimiento.
Volvamos al ejemplo de inicio. SOX implica, sin duda, un mayor estándar de compliance financiero, que genera grandes retos para las empresas europeas que saltan al mercado americano, y en concreto a las españolas, acostumbradas a una CNMV que se basa más en la mejora continua, el self assessment, la colaboración. Existen marcos de control interno, sí, pero no tan exigentes:en SOX los controles han de ser continuos, demostrar su eficacia, afectan a todas las capas de arquitectura tecnológica (aplicaciones, servidores, bases de datos, comunicaciones, integraciones), es decir, impacta a los foundation de los sistemas. Es una norma completa y exhaustiva. Es punitiva.
Las empresas han de estar preparadas, si quieren ser globales, para cumplir con múltiples normativas y marcos muy estrictos. Si quieren ser competitivas, deben apostar por nuevas tecnologías. Como en el resto de las arquitecturas de todos los tipos, se tiene éxito si se actúa sobre unas bases sólidas.
¿Cómo lograrlo de forma más ágil y eficiente en un entorno donde los sistemas son cada vez más numerosos y complejos?
Desde el diseño
¿No debería ser esta búsqueda de la fiabilidad y trazabilidad de la información, sea financiera o no, un requisito de los sistemas tecnológicos? ¿No deberían estar estos sistemas diseñados para proteger al máximo el mayor activo con el que trabajan que es el dato?
El resultado del análisis de gap que presentan los sistemas para poder afrontar una auditoría SOX da también una idea del gap de esos sistemas en cuanto a ser estrictos en la gestión de la información y evidenciarlo. Elevar estos estándares de diseño de sistemas debería ser la ambición y una medida imprescindible en un mundo cada vez más digitalizado, con capacidades más avanzadas en los diferentes campos tecnológicos, con mayores y más sofisticadas amenazas. No todo vale si, aunque cumpla el propósito, el diseño de un sistema no puede garantizar la protección y seguridad del dato y mostrar la traza de sus cambios.
¿Por qué resulta tan difícil adaptar los sistemas a estas normativas?
Principalmente porque no fueron diseñados para ello.
Como en todas las arquitecturas, la tecnológica también responde más fácilmente a cambios en fase de diseño que una vez construida la solución. Incluir en los diseños de arquitecturas y sistemas los requisitos fundamentales legales es una necesidad cada vez más real y decisiva. Nada de esto es un reto ni ha de sorprender a ningún ingeniero informático: automatización de controles internos, trazabilidad de la información, seguridad de datos y control de accesos, redundancia, resiliencia, integración de sistemas y datos, monitorización proactiva, alertas tempranas…
Las normas no son fáciles de entender. Es el principal argumento de “start-ups” y departamentos de tecnología: “Es difícil entender la regulación a la primera, tienes que dedicar a ello tiempo que no destinadas a I+D”.
Capacitación
Qué lejos están demasiadas veces los equipos legales y los tecnológicos. A los equipos tecnológicos se les pide entender las normas; a los equipos legales se les pide entender la velocidad de la innovación, especialmente en los foundation tecnológicos.
Una brecha que, sin duda alguna, hemos de disminuir con urgencia, dotando de una mayor capacitación de los equipos, tanto legal como técnico, en una y la otra materia.
Es imprescindible dotar a las empresas de un sólido equipo multidisciplinar, donde esté muy presente la disciplina legal; legal-tech no es solo un equipo legal que ha entendido la tecnología para mejorar sus procesos. Legal-tech es un equipo legal que ha entendido la importancia de embeberse en los departamentos tecnológicos para intervenir e influenciar desde las bases del diseño, en todo ciclo de vida (como ya lo hiciera Seguridad Informática hace años, modificando la metodología de diseño “agile” de DevOps a DevSecOps).
Adaptarse a las normas actuales o venideras no debería ser tan retador si las arquitecturas fundacionales respetaran los principios básicos.
