Hay muchas formas
de hacer GRC.
Yo empiezo
por el entorno.

Antes de ser auditor, fui el que montaba los sistemas que hoy se auditan. No llegué al GRC desde la teoría, ni desde un catálogo de controles, ni desde una carrera hecha alrededor del documento. Llegué desde la operación, desde la infraestructura, desde el servicio que se cae a las tres de la mañana y desde la decisión que no admite medias tintas porque detrás hay negocio, usuarios y reputación.

He trabajado en entornos híbridos, virtualización, bases de datos, hardening, continuidad, seguridad perimetral, respuesta a incidentes y coordinación de equipos y proveedores. Eso deja dos hábitos que hoy forman parte de mi manera de trabajar: subir y bajar de nivel sin perder el fondo técnico, y documentar desde la arquitectura real, no desde el template bonito.

Cuando escucho una decisión de negocio, intento ver inmediatamente qué dependencia técnica la sostiene. Cuando reviso una arquitectura, no me quedo en el dibujo; busco la parte operativa, las excepciones, los accesos, los propietarios reales y el punto exacto en el que una debilidad se convierte en exposición. Y cuando alguien me enseña una política, la primera pregunta no es si está aprobada. Es si esa política ha conseguido cambiar el comportamiento del entorno.

Una de las ventajas reales que me ha dado la trayectoria técnica es la traducción. No me refiero a traducir siglas, sino a traducir decisiones. Un comité necesita entender exposición, prioridad y capacidad de respuesta. Un responsable de GRC necesita ver coherencia entre requisito, riesgo y control. Un equipo técnico necesita instrucciones claras, criterios inequívocos y un alcance exacto. Si esas capas no se entienden entre sí, el control se deforma por el camino.

Por eso una parte importante de mi trabajo consiste en conectar esos niveles sin simplificar en exceso. No maquillo el riesgo para que parezca cómodo, pero tampoco convierto una revisión en una tormenta de detalle inútil. Intento que cada capa reciba la información que necesita para decidir y actuar.

Si un control parece correcto en papel, todavía no doy por cerrada la revisión. Suelo recorrer una secuencia bastante estable: entender el servicio, identificar dependencias, localizar la parte crítica, mirar cómo se aplica de verdad, comprobar qué excepciones existen y, por último, buscar evidencia suficiente. Lo importante no es rellenar una lista; lo importante es que la cadena tenga continuidad y que una afirmación pueda ser seguida hasta su prueba.

El problema no es la norma. El problema aparece cuando la norma se interpreta como un destino administrativo y no como una herramienta para mantener el control. He visto controles perfectamente redactados que nadie sabía ejecutar en una situación anómala. He visto análisis de riesgos impecables en formato y muy pobres en entendimiento. Y he visto servicios supuestamente cubiertos por continuidad que no habían probado nunca una recuperación completa.

Por eso doy tanta importancia al criterio. Porque el criterio detecta el hueco entre lo que el documento afirma y lo que el entorno permite hacer de verdad.