Demostrar la conformidad en el tiempo, no una sola vez

Un técnico activa el MFA en la cuenta de Microsoft 365 de un cliente, hace una captura de pantalla y la guarda en la carpeta de pruebas. Ocho meses después, la aseguradora cibernética del cliente — o su auditor ISO 27001 — pide la prueba de que el MFA ha estado activo de forma continua desde la última renovación. La captura no lo demuestra. Solo demuestra que, en el instante en que se tomó, el parámetro estaba activado.

Es la diferencia más frecuente entre lo que un técnico llama prueba y lo que un auditor llama prueba — y sale cara justo en el momento en que se descubre, es decir, durante la auditoría.

¿Qué llama prueba un auditor?#

Una observación fechada, repetida en el tiempo, que muestra que un control ha aguantado durante todo el periodo de que se trata — no una declaración puntual que muestra que funcionaba en un instante dado. La norma ISO/IEC 27001:2022 lo formaliza en su cláusula 9.1: la organización debe hacer seguimiento y medir la eficacia de sus controles, y conservar información documentada como prueba de los resultados — no como prueba de que un técnico comprobó un día el parámetro.

Para un técnico, la prueba responde a «¿está activado?». Para un auditor, responde a «¿estuvo activado durante todo el periodo revisado, y cómo lo sabe usted sin haber ido a comprobarlo cada día?».

La profesión de la auditoría separa esas dos preguntas desde hace mucho, y el vocabulario es útil aunque usted no pase nunca una certificación. Por un lado, la prueba de diseño: el control existe, está configurado como prevé la política, alguien puede mostrarlo en pantalla. Por otro, la prueba de eficacia operativa: el control ha producido el efecto esperado, sin interrupción inexplicada, durante todo el periodo revisado. Una captura de pantalla responde a la primera pregunta y deja la segunda enteramente abierta. Es exactamente la diferencia entre un informe de atestación referido a un instante y uno referido a un periodo — y es el segundo el que una aseguradora o un cliente regulado acaba pidiendo siempre.

¿Por qué una atestación puntual nunca basta?#

Porque no dice nada de lo que ocurrió antes o después del día en que se produjo. Una auditoría de certificación ISO 27001, o un control realizado por una autoridad de supervisión, recae sobre un periodo — generalmente el año transcurrido — no sobre el instante de la auditoría. Una atestación única, por sincera que sea en el momento de firmarse, cubre literalmente un solo día de trescientos sesenta y cinco.

El riesgo no es ni siquiera la falta de honestidad. Es que una atestación puntual recogida justo antes de la auditoría describe exactamente el periodo menos representativo del año: aquel en el que todo el mundo acaba de comprobar y de corregir lo que no estaba bien.

Y el intervalo entre dos registros se paga hoy más caro que antes: la compresión del plazo hasta la explotación hace que una brecha que haya pasado tres meses invisible ya no sea una brecha teórica.

Hay una razón todavía más mecánica, y sorprende a muchos prestadores la primera vez. Un auditor no vuelve a leer el periodo entero: hace un muestreo. Elige fechas dentro del periodo revisado — a menudo sin avisar de cuáles — y pide la prueba del estado del control en esas fechas. Si su expediente solo contiene una captura fechada la víspera de la auditoría, cada fecha muestreada es un agujero. No puede rellenarlos a posteriori: una consola de gestión muestra el estado de hoy, no el del 14 de marzo. El registro del 14 de marzo existía ese día o no existe.

¿Cómo se desajusta un parámetro de seguridad sin que nadie lo haya hecho a propósito?#

Por el uso normal del sistema, no por una falta. Un usuario se queda bloqueado fuera de su cuenta, un técnico desactiva temporalmente el MFA para desbloquearlo un viernes por la tarde, y nadie se acuerda de reactivarlo el lunes. Una actualización de la consola de gestión devuelve una directiva de grupo a su valor por defecto. Un nuevo dispositivo se incorpora al parque antes de que se le aplique la política de conformidad. Una regla de seguridad apunta a un grupo de usuarios cuya composición cambia con las altas y las bajas, sin que nadie resincronice el perímetro.

Cada uno de esos hechos es anodino por separado. Sumados a lo largo de doce meses, en decenas de cuentas y varias herramientas, producen exactamente lo que un auditor teme: un control que era cierto el día en que se comprobó, y que ha dejado de serlo hace tres meses sin que nadie se haya dado cuenta.

Lo que hace costosas esas derivas no es su gravedad, es su discreción. Ninguna dispara una alerta, porque ninguna es una avería: el sistema funciona exactamente como se le pidió. Puestas una al lado de otra, todas tienen la misma firma.

La columna de la derecha es la única que responde a la pregunta del auditor. Las otras tres describen el estado de hoy, lo que es útil para operar pero no tiene valor para demostrar.

¿Qué debe tener una prueba para resistir una auditoría?#

Cinco propiedades, y ninguna es opcional: sin una de ellas, el expediente cae a la pregunta siguiente. La regla que las resume cabe en una frase — la ausencia de registro es una ausencia de prueba, no una prueba favorable.

Una prueba sin fecha no demuestra nada sobre un periodo. Una prueba sobrescrita por la siguiente — un panel que solo muestra el último registro — pierde el rastro del momento en que el control dejó de aguantar. Y un día sin medición no debe contarse nunca como un día conforme por defecto, porque el primer auditor que se dé cuenta pondrá en cuestión todo el resto del expediente, incluidas las partes que eran correctas.

¿Qué aspecto tiene un registro de prueba, en concreto?#

El de una línea por medición, no el de un documento. Esta es la forma mínima de una serie utilizable para un solo control — la aplicación del MFA en las cuentas de Microsoft 365 de un cliente — a lo largo de unos pocos días.

Seis líneas, y la historia completa ya se lee. El 14 de marzo, una cuenta salió del perímetro del MFA. El 15, la recogida no se ejecutó — y la línea lo dice, en lugar de arrastrar en silencio el valor de la víspera. El 16 se creó una cuenta: el denominador pasa de 52 a 53, la cuenta nueva todavía no está cubierta por la política, y la cobertura baja una segunda vez sin que nadie haya modificado ningún ajuste. El 17, las dos diferencias están corregidas.

Una captura de pantalla tomada el 17 de marzo habría mostrado un 100 % y habría sido perfectamente sincera. También habría borrado los tres días anteriores, incluido aquel en que la recogida no se ejecutó — el único punto del expediente que un auditor concienzudo le pedirá que explique.

¿Qué hace un auditor con una serie de registros fechados?#

Tres cosas, en este orden, y más vale haberlas anticipado. Primero comprueba el denominador: de dónde sale la cifra 52, cómo se constituye el perímetro y qué pasaría si un puesto no estuviera en ningún inventario. Una tasa de conformidad calculada sobre una población que usted mismo elige no tiene valor probatorio, y es lo primero que pone a prueba un auditor experimentado.

Después hace un muestreo. Toma dos o tres fechas del periodo y le pide que recupere, en la fuente, el estado que su registro afirma. Si la línea del 14 de marzo dice 51 de 52, quiere saber qué cuenta faltaba y por qué. Una serie de registros que no permita bajar al detalle no sobrevive a esa etapa.

Por último, mira los huecos y las caídas — y ahí es donde la intuición de muchos prestadores está al revés. Una curva al 100 % durante trescientos sesenta y cinco días, sin un solo valle, no inspira confianza: sugiere que la medición no mide gran cosa. Una serie que muestra una caída el 14 de marzo, su causa y su corrección el 17 describe un dispositivo de control que funciona. La norma ISO/IEC 27001 prevé además expresamente ese caso en su cláusula 10.2: una no conformidad constatada debe tratarse, examinarse sus causas y conservarse la acción correctora como información documentada. Una desviación documentada y corregida es un elemento de conformidad, no una confesión.

Lo que plantea un problema no es nunca la desviación. Es la desviación que se descubre durante la auditoría porque nadie medía.

¿Qué controles pueden registrarse automáticamente y cuáles no lo serán nunca?#

Solo una parte, y hay que decirlo con franqueza en lugar de dejar creer que una herramienta sustituye a la gobernanza. Los controles cuyo estado vive en una consola consultable se registran de forma continua; los que descansan sobre un acto humano o un documento se demuestran de otra manera, y no hay automatización honesta para ellos.

La columna de la derecha no es un mal menor: es la misma exigencia aplicada a pruebas de otra naturaleza. Un acta de revisión de accesos sin fechar tiene exactamente el mismo defecto que una captura de pantalla de consola sin fechar.

¿Qué hay que recoger de forma continua en lugar de reconstruir en el momento de la auditoría?#

Registros técnicos periódicos de cada control verificable automáticamente — MFA aplicado, copia ejecutada correctamente, agente de protección del puesto presente, parches al día — conservados individualmente en lugar de agregados en un único indicador que aplasta el historial. La diferencia práctica es fácil de formular: en lugar de responder «sí, el MFA está activo» una vez al año, usted puede responder «el MFA se aplicó en al menos el 95 % de los puestos durante 91 de los últimos 92 días», con la fecha del día que se cayó y lo que ocurrió ese día.

La segunda respuesta es verificable. La primera no lo es — pide al auditor que le crea bajo palabra, lo que no es ni su papel ni cosa suya pedírselo.

El mismo razonamiento vale para las decisiones, no solo para las mediciones. Un registro de conformidad que solo muestra su estado actual tiene el defecto del panel: no dice cuándo una entrada pasó de «no conforme» a «conforme». Un historial que conserva el estado anterior, el nuevo estado y la fecha del cambio responde a una pregunta que el auditor hace sistemáticamente — desde cuándo está abierta esa desviación, y qué se ha hecho entretanto.

¿Cuánto tiempo hay que conservar esos registros?#

Como mínimo el periodo que cubre la auditoría, y en la práctica más. El periodo revisado en una auditoría ISO 27001 es generalmente el año transcurrido, pero la duración de un ciclo de certificación y el contenido exacto de las auditorías de seguimiento dependen del esquema que aplique el organismo certificador: es a él a quien hay que preguntar qué periodo cubrir, no a un artículo de blog. Del lado del seguro, la cuestión se plantea en la renovación, es decir, cada año, sobre los doce meses anteriores.

La regla práctica que evita equivocarse: conserve un periodo completo más que el que le piden hoy. Un expediente que empieza exactamente el día en que empieza la auditoría da la impresión — a menudo injusta — de haberse constituido para la ocasión. Y guarde los registros en el formato en que se produjeron, con su marca de tiempo de origen: una exportación retocada, recalculada o reformateada en el momento de la auditoría pierde precisamente la propiedad que la convertía en prueba.

Es el principio que hay detrás del módulo de deriva continua de Vigicap: cada lectura de conector se conserva, nunca se sobrescribe, lo que permite presentar una cobertura fechada como la citada más arriba en lugar de una captura de pantalla aislada. El registro de conformidad sigue la misma regla: cada cambio de estado de un objetivo conserva el estado anterior, el nuevo y su fecha, en lugar de sustituir el valor precedente.