La verdadera historia detrás de la ingeniería GRC (contada por alguien que la vivió)

Hace cinco años, el título de "ingeniero GRC" no era conocido por la mayoría de los responsables de cumplimiento normativo. Hoy en día, está por todas partes: en portales de empleo, en ponencias de congresos y en los organigramas de las empresas que se toman la seguridad en serio.

Esta es la historia de cómo sucedió, contada a través de la perspectiva de Kurtes Allen, un ingeniero de GRC cuya trayectoria en este campo siguió las mismas presiones que transformaron la disciplina en general.

Un profesional que casi se echó atrás

Kurtes se inició en la ciberseguridad por la vía más práctica posible. Montó su primer ordenador antes de tomar un curso sobre cómo hacerlo, consiguió un trabajo como técnico de laboratorio informático al terminar el instituto y, finalmente, fue a la universidad a estudiar telecomunicaciones antes de cambiarse al mundo de la ciberseguridad.

Luego llegó al módulo de GRC y lo detestó. Le pareció aburrido, lleno de marcos de trabajo y muy alejado de los sistemas con los que realmente quería trabajar. El instructor tampoco ayudó.

“Solo quería aprobar el curso y deshacerme de él. No tenía ninguna intención de volver a mirar atrás en GRC.”

Así que aprobó el curso y volvió a las áreas de seguridad que le permitían ensuciarse las manos.

Pero esa reacción no era inusual. De hecho, era la reacción que la mayor parte de la industria tenía ante el trabajo de cumplimiento normativo en aquel momento. Y comprender el porqué es el primer paso para comprender por qué fue necesario inventar la ingeniería GRC.

Las presiones que hicieron quebrar el antiguo modelo

A finales de la década de 2010, el cumplimiento normativo estaba fallando en tres frentes a la vez.

La superficie de cobertura se multiplicó exponencialmente. Una empresa que operaba en diversas regiones, con distintos tipos de clientes e industrias, podía verse fácilmente obligada a cumplir con múltiples marcos normativos, desde SOC 2 e ISO 27001 hasta HIPAA, PCI y GDPR. La superposición entre ellos era real, a menudo del 60 al 70 por ciento, pero el proceso de mapeo en sí se convirtió en una tarea a tiempo completo.

Al mismo tiempo, la infraestructura dejó de ser estática. En un mundo de despliegue continuo, el sistema que un auditor certificó en marzo era estructuralmente diferente en junio. Por lo tanto, la evidencia recopilada en un momento dado decía cada vez menos sobre si los controles realmente funcionaban.

Y entonces la magnitud del proyecto rompió la barrera del trabajo manual. La tarea de recopilar capturas de pantalla, mantener hojas de cálculo, localizar a la gente en unidades compartidas y gestionar los correos electrónicos trimestrales era tolerable con cincuenta personas y absurda con cinco mil.

Cualquiera de estas presiones podría haberse absorbido. Sin embargo, en conjunto, obligaron a replantearse la situación.

Mientras tanto, Kurtes se había graduado y comenzó a trabajar como autónomo. Las pequeñas empresas le pedían constantemente ayuda con sus sistemas, pero estos seguían teniendo problemas de cumplimiento normativo. Así que volvió a estudiar GRC, esta vez con un instructor que sentía verdadera pasión por el tema, y ​​la segunda vez que lo hizo, lo entendió. Lo que lo hizo volver fue algo que estaba a punto de transformar el sector: en realidad, no se puede separar el cumplimiento normativo de los sistemas que rige.

La primera respuesta fue estructura y estandarización.

El primer cambio significativo fue la estandarización. Los equipos comenzaron a poner orden en el caos con flujos de trabajo estructurados, bibliotecas de control reutilizables y un lenguaje común. Esto significó que ya no tenían que reconstruir los mismos procesos de cumplimiento desde cero cada vez. Durante un tiempo, esto funcionó bien. La preparación de auditorías se volvió más rápida y la recopilación de evidencias fue más organizada y menos manual.

Pero la estandarización tiene sus límites. Puede ayudar a organizar lo que se debe verificar, pero no siempre puede determinar por sí sola el estado real de los sistemas. Alguien tenía que intervenir, recopilar los datos y verificar lo que realmente estaba sucediendo.

A medida que GRC maduró, los equipos comenzaron a cubrir esa necesidad por sí mismos. Escribieron scripts para obtener configuraciones de proveedores de la nube, recopilar registros y conectar sistemas que no estaban cubiertos por los flujos de trabajo estándar. Con el tiempo, esto se fue acumulando. La función de cumplimiento comenzó a parecerse más a una función de software, aunque todavía no se le había dado un nombre.

Este era el trabajo que Kurtes ya estaba realizando. Python era su lenguaje. Escribió recolectores, creó plantillas y automatizó las partes tediosas, no porque siguiera una moda, sino porque el trabajo mismo lo exigía.

Cómo surgió GRC Engineering

El surgimiento de la ingeniería GRC se produjo al analizar DevOps desde una perspectiva diferente. Esto se debe a que DevOps se había enfrentado a un problema estructuralmente idéntico una década antes y lo había resuelto con un conjunto de principios: infraestructura como código, pipelines como fuente de información fidedigna y calidad como una propiedad del proceso de entrega en lugar de una fase añadida posteriormente.

GRC comenzó a seguir el mismo camino. Las políticas se redactaron como código, por lo que residían dentro de los sistemas a los que se aplicaban. La evidencia se generaba automáticamente durante la ejecución de los sistemas, en lugar de recopilarse posteriormente. Los controles también se integraron en el proceso de implementación, donde podían detener un cambio que no cumpliera con las normas antes de su lanzamiento.

En lugar de comprobar el cumplimiento a posteriori, se convirtió en parte del proceso de construcción y distribución de los sistemas.

En el modelo anterior, el cumplimiento normativo recopilaba pruebas a posteriori. En el nuevo modelo, en cambio, las pruebas se generan como resultado del correcto funcionamiento del sistema. La persona que diseñó esta capa de emisión de pruebas realizó un trabajo que antes no existía, y el mercado necesitaba un término para describirlo. Ese término se convirtió en ingeniero de GRC (Gobierno, Cumplimiento y Revisión).

En realidad, se trata de un cambio de mentalidad.

Desde fuera, la ingeniería GRC parece una cuestión de herramientas. La gente ve los flujos de trabajo y la política como código, y asume que toda la disciplina es puramente técnica y se basa en el código.

Pero no lo es.

En pocas palabras, el cambio es el siguiente: el enfoque pasa de la recopilación manual de pruebas a la creación de sistemas que las generen por sí mismos. El cumplimiento normativo ya no es un proceso independiente que se desarrolla paralelamente a la ingeniería, sino que se integra en el diseño y la operación de los sistemas.

Esta forma de pensar está al alcance de cualquier profesional, programe o no. La mentalidad es lo primero; las herramientas vienen después. Así surgió la ingeniería GRC, gracias al trabajo de profesionales como Kurtes, que se adaptaron incluso antes de que el rol tuviera nombre. Hoy en día, esta forma de trabajar ya no es marginal; se está convirtiendo en una práctica común. Y a medida que la tecnología avanza a pasos agigantados, este cambio se abre a cualquiera que esté dispuesto a adoptarlo. El futuro de GRC ya está tomando forma.