Gestión de riesgo y evidencia

Has montado los controles y traducido los marcos. Queda la parte que separa a un equipo que dice que es seguro de uno que puede demostrarlo: la evidencia y la gestión del riesgo. Dos públicos esperan algo de ti. El auditor quiere pruebas trazables de que cada control operó. Tu CTO quiere una página que le diga qué arde, cómo vais y qué decisión necesitas de él. Esta nota va de producir ambas cosas sin que te consuma la vida.

Evidencia: que la produzca la máquina#

La peor forma de preparar una auditoría es a mano, la semana antes: capturas de pantalla, exportaciones sueltas, un Excel que envejece mal. No escala y, sobre todo, no demuestra que el control funcionó todo el periodo (justo lo que mira un SOC 2 Type II). La alternativa es que la evidencia se genere sola, de forma continua.

Evidencia automatizada: del control al informe ejecutivo

Cumplimiento · Riesgo

Paso 1 de 5Los emisores

Tres controles producen señales todo el tiempo: AWS Config (conformidad), CloudTrail (accesos) y Security Hub (hallazgos y puntuación de postura).

AWS Config + conformance packs

Las reglas de AWS Config evalúan continuamente tu configuración; un conformance pack agrupa decenas de reglas alineadas con un marco (CIS, PCI, NIST) y te da una puntuación de cumplimiento por cuenta y por toda la organización.
Security Hub como agregador de postura

Security Hub normaliza hallazgos de Config, GuardDuty, Inspector y Access Analyzer, y puntúa tu postura contra estándares como el FSBP o el CIS AWS Foundations. Un número por cuenta, uno por organización.
AWS Audit Manager para el mapeo a marcos

AWS Audit Manager toma esa evidencia (CloudTrail, Config, Security Hub, llamadas a la API) y la asocia a cada control de un marco predefinido o propio, produciendo un assessment report trazable, con fecha y origen.

Gestión de riesgo: el registro, las excepciones y la prioridad#

La evidencia demuestra lo que cumples; la gestión de riesgo ordena lo que no cumples todavía. Su herramienta básica es el registro de riesgos (risk register): una lista viva donde cada riesgo tiene dueño, probabilidad, impacto, estado y plan.

Campo	Ejemplo (Citas)
Riesgo	Llave de acceso legacy `ci-deploy-legacy` sin rotar
Impacto	Alto — acceso de despliegue a producción
Probabilidad	Media — está en un secreto, pero es permanente
Dueño	Equipo de plataforma
Estado	En tratamiento — migrando a OIDC
Fecha límite	2026-11-30

Excepciones con fecha de caducidad#

A veces no puedes arreglar algo ya, y aceptas el riesgo temporalmente. Bien, pero una excepción sin fecha de caducidad es deuda para siempre. Toda excepción necesita: quién la aprueba, por qué, hasta cuándo y qué se hará al vencer. Cuando caduca, se revisa o se renueva de forma explícita, nunca por inercia.

Priorizar por impacto al negocio#

No todos los riesgos valen lo mismo. Un bucket público con PII de pacientes está por encima de una recomendación de hardening en una cuenta de pruebas, aunque ambos sean «hallazgos». Prioriza por impacto al negocio (qué dato, qué sistema, qué obligación legal), no por el número de hallazgos ni por el que grita más fuerte. Esa es, además, la lógica de un CNAPP: correlacionar «recurso expuesto + identidad con exceso de permisos + CVE» en una ruta de ataque priorizada, en lugar de mil alertas sueltas.

El informe ejecutivo de una página#

Tu CTO no va a leer el assessment report de 200 páginas. Necesita una página que responda a tres preguntas, en lenguaje de negocio:

Riesgos principales (3–5)

Los que de verdad importan, con su impacto en términos de negocio: «exposición de PII de pacientes», no «security group con 0.0.0.0/0».
Estado

Hacia dónde vamos: puntuación de postura y su tendencia, cuántos riesgos altos abiertos, qué cerramos este trimestre. Un semáforo honesto.
Decisiones que pides

Lo que necesitas de la dirección: presupuesto, una aceptación formal de riesgo, prioridad entre dos iniciativas. Si no pides nada, no es un informe ejecutivo: es un diario.

Nota multicloud#

Casi nadie vive solo en AWS. Conviene saber traducir estos conceptos a las otras nubes, aunque sea a grandes rasgos:

El modelo que hemos usado: identidad con IAM / IAM Identity Center, evidencia con Config + Security Hub + Audit Manager, gobierno con Organizations (SCP/RCP).

La identidad es Microsoft Entra ID (el nuevo nombre de Azure Active Directory / Azure AD): usuarios, grupos, conditional access y managed identities para cargas. El gobierno a escala se hace con Management Groups y Azure Policy, y la postura con Microsoft Defender for Cloud.

La identidad es Cloud Identity / Google Workspace con Cloud IAM (roles sobre una jerarquía de organización → carpetas → proyectos). El gobierno usa Organization Policies, y la postura, Security Command Center.

Cuando operas en varias nubes a la vez, una herramienta CNAPP/CSPM (como Wiz o Prisma Cloud de Palo Alto) te da una capa única de postura, identidades y rutas de ataque sobre AWS, Azure y GCP, con su propio motor de evidencia. Es la forma pragmática de no tener tres paneles desconectados.

Tu turno

Escribe tu informe ejecutivo de una página

Toma tu entorno real (o Citas). Redacta una sola página con:

3 riesgos principales, cada uno en una frase de impacto al negocio (sin jerga técnica).
Estado: una línea de postura y tendencia, y cuántos riesgos altos siguen abiertos.
2 decisiones concretas que le pedirías a tu CTO.

Después, para el riesgo más grave, escribe su fila en el registro de riesgos (impacto, dueño, estado, fecha límite) y, si lo vas a aceptar temporalmente, su fecha de caducidad.

Reto

¿Por qué una excepción sin fecha de caducidad es tan peligrosa?

▸Mostrar solución

Porque convierte una decisión temporal y consciente en un agujero permanente e invisible. El contexto que la justificaba (una migración, un proveedor) desaparece, pero el acceso abierto se queda, sin que nadie lo revise. Con fecha de caducidad, el riesgo vuelve a la mesa de forma forzada; sin ella, solo lo encuentra el atacante o el auditor.