Preguntas de entrevista de Governance, Risk & Compliance

No. La nube funciona con un modelo de responsabilidad compartida: el proveedor asegura la infraestructura subyacente («seguridad de la nube»), pero tú sigues siendo responsable de tus datos, la gestión de identidades y accesos, la configuración y — en IaaS — el sistema operativo y los parches («seguridad en la nube»). La gran mayoría de las brechas en la nube son errores de configuración del cliente, como buckets públicos e IAM demasiado permisivo, no fallos del proveedor. Suponer que el proveedor asegura tus datos es justamente cómo ocurren esas brechas.

No. Una VPN cifra el tráfico hasta el servidor VPN y oculta tu IP al destino, pero el proveedor puede ver y registrar tu actividad, y los inicios de sesión, las cookies y la huella del navegador siguen identificándote. Traslada la confianza de tu red local/ISP al operador de la VPN — eso es privacidad frente a la red local, no anonimato. Tor y una disciplina operativa estricta son herramientas distintas para un objetivo distinto.

Un modelo de terceros es una dependencia de cadena de suministro: verifica que provenga de una fuente de confianza con sumas de verificación/firmas coincidentes, que su licencia permita tu uso, y que el formato de archivo no ejecute código arbitrario al cargarse (prefiere serialización segura frente a formatos tipo pickle). «Se carga» y «velocidad de descarga» no dicen nada sobre la confianza, y suponer que los modelos públicos son seguros ignora los riesgos reales de envenenamiento y deserialización.

Enviar PII de clientes a una API externa la expone al procesamiento y la retención de un tercero y puede incumplir obligaciones de privacidad. Minimiza y redacta lo que se envía, confirma los términos de uso/retención del proveedor y un acuerdo de procesamiento de datos (o garantías de no entrenamiento), o pasa a un despliegue privado para datos sensibles. La longitud de la clave es irrelevante, y enviar más PII aumenta la exposición.

La integridad probatoria se basa en hashear la imagen en la adquisición (por ejemplo, SHA-256) y verificar el hash después para probar que no fue alterada, mantener una cadena de custodia documentada, y analizar una copia de trabajo para que el original quede intacto. Renombrar el archivo no hace nada por la integridad, y comprimirlo para ahorrar espacio no prueba la integridad ni ayuda a la admisibilidad. Tocar el original arriesga una destrucción de pruebas que puede hacer que se descarte la evidencia. Hashea, documenta la custodia y trabaja sobre una copia verificada.

Los auditores comprueban evidencias, no intenciones: muestra la política de revisión de accesos, los registros fechados de cada revisión con la firma de un aprobador y la confirmación de que los accesos señalados se revocaron y verificaron. Una confirmación verbal no prueba nada reproducible, una promesa de empezar el próximo trimestre demuestra que el control no operó durante el periodo auditado, y un organigrama describe líneas jerárquicas, no decisiones de acceso. Solo los artefactos fechados y atribuibles demuestran que el control operó según lo diseñado durante todo el periodo.

Las copias de seguridad son necesarias pero no suficientes: la recuperación ante desastres y la continuidad de negocio son la capacidad probada de restaurar las operaciones dentro de los objetivos acordados de tiempo y punto de recuperación (RTO/RPO), lo que exige un plan documentado, dependencias mapeadas, runbooks y restauraciones validadas, no solo la existencia de archivos de copia. Afirmar que son lo mismo confunde una copia de datos con una capacidad operativa. El DR no es solo contratar un seguro, que transfiere la pérdida financiera pero no restaura los sistemas. Y las copias no hacen innecesario un plan de DR: las copias no probadas fallan habitualmente cuando por fin se necesitan. La aclaración: el DR debe ejercitarse, no presumirse.

Los marcos fijan un mínimo y pueden cumplirse por completo mientras persiste un riesgo real, así que una lista de verificación superada no significa seguro: señala la brecha, evalúa su riesgo e impulsa su tratamiento, sea cual sea el estado de cumplimiento. Concluir que es seguro porque el cumplimiento pasó es una confusión peligrosa entre dos cosas distintas. Eliminar la brecha del informe es una tergiversación, e incluso fraude. Esperar al próximo ciclo de auditoría deja a sabiendas una exposición real abierta. La postura madura trata el cumplimiento como prueba de un suelo, no de un techo, y actúa sobre el riesgo que realmente puede verse.

Un manejo inconsistente suele significar que no hay una definición compartida de sensibilidad, así que el control fundamental es un esquema de clasificación de datos (p. ej., público/interno/confidencial/restringido) con requisitos definidos de manejo, almacenamiento y compartición por nivel, que permite a los equipos aplicar controles proporcionados. No cifrar nada 'para simplificar' o tratar todos los datos como públicos despoja de protección a los datos que la necesitan. Borrar todos los datos de más de un día destruye registros que el negocio y la ley requieren. Solo un esquema de clasificación alinea la fuerza de los controles con la sensibilidad real de los datos.

El riesgo de una baja es el acceso que persiste, así que el control a verificar es el desaprovisionamiento puntual de cada vía de acceso —cuentas de directorio, SSO, VPN, credenciales privilegiadas y de servicio, y SaaS de terceros— conciliado con el proceso de alta/cambio/baja (JML). Suponer que RR. HH. lo gestiona todo sin verificar deja brechas sin propietario. Mantener la cuenta activa 'por si vuelve' es un riesgo permanente y no supervisado. Desactivar solo el correo ignora los muchos otros sistemas que la persona aún podría alcanzar. La clave es verificar que el acceso se elimina real y completamente, no confiar en que así fue.

El alcance de PCI DSS abarca los sistemas que almacenan, procesan o transmiten datos de titulares de tarjetas, más cualquier sistema conectado a ellos o capaz de afectarlos, así que una segmentación de red eficaz aísla el entorno de datos de tarjetas (CDE) y saca de alcance los sistemas ajenos, reduciendo coste, esfuerzo y riesgo. Cifrar todos los servidores no define una frontera y los sistemas conectados siguen en alcance; añadir cortafuegos por todas partes sin un objetivo no es segmentación si no restringe ni valida los flujos de datos; y dejar de leer en voz alta los números de tarjeta es higiene, no un control de alcance. La respuesta sistémica es controlar dónde viven los datos de tarjetas y qué puede alcanzarlos.

La gobernanza significa que el riesgo se captura y se gestiona, no se maneja de manera informal: regístralo en el registro de riesgos con la probabilidad y el impacto evaluados, asigna un propietario responsable, decide y documenta el tratamiento (mitigar, transferir, aceptar o evitar) y fija una fecha de revisión. Resolverlo tú mismo en el momento se salta la propiedad, la priorización y el seguimiento, y puede que ni siquiera te corresponda. Ignorarlo hasta que se convierta en un incidente es negligente, y enviarlo por correo a todos genera ruido pero ninguna responsabilidad ni seguimiento. El registro convierte una observación puntual en una decisión rastreada, con propietario y revisada.

Un informe SOC 2 solo te aporta garantía si lo lees de verdad: confirma que es del tipo correcto (el Tipo II prueba la eficacia operativa a lo largo del tiempo, el Tipo I solo el diseño en un momento), revisa el alcance y qué criterios de servicios de confianza cubre, que el periodo es actual y no tiene huecos, qué opinión emitió el auditor (sin salvedades o con salvedades) y examina las excepciones señaladas más los controles complementarios de la entidad usuaria (CUEC) que te corresponden. Limitarse a confirmar que el informe existe —o juzgarlo por el logo de la portada o el número de páginas— no dice nada sobre la eficacia real de los controles del proveedor ni sobre tus obligaciones residuales.

El código transitivo se ejecuta en tu aplicación, así que una CVE crítica es tu riesgo. Evalúa si la ruta de código vulnerable es realmente alcanzable, luego remedia subiendo o anulando la versión (o mitigando) y verifica en producción. Ignorarla por ser transitiva deja un agujero conocido que un atacante puede explotar. Silenciar la auditoría solo oculta el aviso. Reinstalar node_modules trae la misma versión vulnerable. Haz seguimiento mediante SCA, no la acalles.

Equilibra usabilidad y riesgo: impón acceso condicional ligado a la postura del dispositivo y aísla los datos corporativos en un contenedor gestionado (MAM/MDM) para poder controlarlos y borrarlos selectivamente sin apoderarte de todo el dispositivo personal. El acceso sin restricciones arriesga la fuga en endpoints no gestionados, posiblemente comprometidos. Una prohibición rotunda empuja a soluciones inseguras como reenviar datos al correo personal. Y enviar los datos como adjuntos los dispersa de forma incontrolable por dispositivos que nunca recuperarás.

Ningún producto único detiene todos los ataques, así que la seguridad madura superpone controles independientes —la defensa en profundidad— para que el fallo de uno no signifique la compromisión. Asocia el gasto propuesto a las brechas reales en identidad, red, endpoint, datos y detección, y conserva los controles complementarios que ya funcionan. Apostarlo todo a una sola herramienta crea un punto único de fallo, y arrancar los controles existentes para sustituirlos reduce la cobertura. No gastar nada en absoluto ignora brechas reales.

El cifrado en reposo defiende exactamente una amenaza — el robo físico o de disco — y no hace nada frente a una aplicación comprometida, credenciales robadas o tráfico interceptado, porque la base de datos descifra de forma transparente para cualquier consulta autorizada. Un diseño sólido también exige TLS en tránsito, autenticación y autorización fuertes, y una gestión de claves adecuada con separación de funciones. Duplicar el cifrado en reposo añade coste sin cambiar el modelo de amenazas, y cifrar solo las copias de seguridad deja expuestos los datos en producción y sus rutas de acceso.

El modelado de amenazas es más barato y eficaz en la fase de diseño, antes de que el código fije las decisiones: recorre los flujos de datos, enumera amenazas con un marco como STRIDE, integra las mitigaciones y revísalo a medida que el diseño evoluciona. Hacerlo solo tras un incidente o en el pentest anual encuentra los problemas cuando ya son caros de corregir y están expuestos. Y fiarse de «desarrolladores cuidadosos» es una esperanza, no un control repetible y auditable.

Enviar datos personales a un tercero extiende tu frontera de confianza, así que primero realiza una evaluación de seguridad del proveedor — tratamiento de datos, cifrado, controles de acceso, certificaciones como SOC 2 / ISO 27001, subencargados, condiciones de notificación de brechas — y firma un acuerdo de tratamiento de datos (DPA) antes de cualquier transferencia. Un contrato de precio o la palabra verbal de un comercial no es diligencia debida. Y un «sitio web pulido» no dice nada sobre cómo protege realmente los datos el proveedor; tú sigues siendo responsable.

«Seguro» no es binario; un CISO comunica en el lenguaje del riesgo de negocio: los riesgos más relevantes, cómo los controles actuales los reducen frente al apetito de riesgo del consejo, las inversiones previstas y el riesgo residual que se acepta. Un «sí» absoluto es una falsa garantía que se derrumba en cuanto ocurre un incidente. «No, nunca estaremos seguros» es técnicamente cierto pero inútil y delata falta de control del problema. Una lista de cortafuegos y herramientas refleja gasto, no riesgo ni resultados que el consejo pueda gobernar.

La gestión de una brecha se rige por la ley y el contrato: trabajar con el área legal para cumplir los plazos de notificación obligatorios (como las 72 horas del RGPD ante la autoridad de control) e informar a las personas afectadas con exactitud. El ocultamiento expone a multas mucho mayores, sanciones y daño reputacional cuando sale a la luz. Difundir prematuramente detalles técnicos en bruto y sin verificar puede confundir a los clientes y ayudar a los atacantes. Culpar públicamente a un empleado no es exacto, ni legal, ni una gestión de crisis eficaz.

Las métricas de nivel de consejo deben conectarse con el riesgo y los resultados: tiempos de detección y respuesta (MTTD/MTTR), cumplimiento de SLA de parcheo en sistemas críticos, cobertura de controles y cómo evoluciona el riesgo residual frente al apetito. El número de ataques bloqueados por el cortafuegos, el recuento de firmas de antivirus y el total de correos recibidos son cifras vanidosas — impresionan pero no dicen nada sobre si el riesgo baja. El consejo gobierna el riesgo, así que las métricas deben dejarle ver la tendencia y decidir.

Un 30 % de clics es una línea base que mejorar, no una lista de personas a castigar: combinar formación dirigida por rol y un botón de reporte sin fricción con defensas técnicas (MFA, filtrado de correo, mínimo privilegio) para que un solo clic no derive en compromiso, y seguir la tendencia en el tiempo. Avergonzar públicamente a los empleados suprime el reporte del que dependes. Declarar al personal irrecuperable elimina un control que deberías reforzar. Otro correo alarmista a toda la plantilla no es una intervención medible ni cambia el comportamiento.

El gasto en seguridad debe seguir al riesgo, no a la moda: usar una evaluación de riesgos para dirigir el dinero donde el impacto al negocio y la probabilidad son más altos y la cobertura de controles actual es más débil, y luego medir la reducción lograda. Comprar lo que vende el proveedor popular ignora tu perfil de amenaza real y a menudo financia herramientas sin usar. Repartir el presupuesto por igual infrafinancia las pocas áreas que más importan. Copiar a los competidores asume que su perfil de riesgo es igual al tuyo, lo cual rara vez ocurre.

Las simulaciones ensayan el lado humano y de decisión de la RI — quién tiene autoridad para declarar un incidente, cómo fluye la comunicación legal/RR. PP./dirección y dónde se rompe el manual — para que la primera vez que tomes esas decisiones no sea durante una crisis real. Es mucho más barato encontrar brechas en un ejercicio que en plena brecha. No son una casilla de cumplimiento vacía, no sirven para asignar culpas por incidentes pasados, y son transversales, no solo del SOC — la dirección debe practicar las decisiones que solo ella puede tomar.

Cuando no puedes remediar, gestionas el riesgo: reducir la exposición con controles compensatorios (segmentación de red, restricción de accesos, monitorización reforzada), cuantificar el riesgo residual y lograr que el propietario de negocio responsable lo acepte formalmente con una fecha de revisión definida. Un apagado unilateral excede la autoridad del CISO y daña al negocio. Ignorarlo porque no se puede arreglar es negligencia. Omitirlo del registro de riesgos oculta la responsabilidad, rompe el rastro de auditoría y significa que nadie consta como dueño de la decisión.

La brecha de un proveedor también es tu incidente: invocar la respuesta a incidentes para acotar qué datos e integraciones quedaron expuestos, rotar todos los secretos compartidos, claves API y relaciones de confianza SSO, evaluar tus propias obligaciones de notificación regulatoria y exigir al proveedor su divulgación. Esperar pasivamente al proveedor cede el control de tu propio calendario y obligaciones. Una rescisión pública del contrato es teatro prematuro antes de conocer siquiera tu exposición. Asumir que no te afectó omite precisamente la evaluación que esperan los reguladores y tus clientes.

El cambio manual en la consola es deriva de configuración: el próximo terraform apply puede revertir en silencio el arreglo, y el cambio además se saltó la revisión y la auditoría. Reconcílialo codificando el cambio en Terraform, ejecutando plan/apply para que el código y la realidad coincidan, y añadiendo salvaguardas contra cambios ad hoc en la consola (acceso a consola con mínimo privilegio, SCP, detección de deriva). No hacer nada deja una mina para el próximo apply. Borrar el estado de Terraform es destructivo y puede dejar recursos huérfanos o duplicados. Abandonar Terraform tira por la borda la reproducibilidad, la revisión y los rastros de auditoría.

Las reglas de enfrentamiento suelen excluir la denegación de servicio en producción, y una caída no planificada causa un daño real al negocio y puede anular el compromiso. Verifica primero el alcance; si una prueba de concepto destructiva no está autorizada, demuestra la vulnerabilidad por medios más seguros y documenta claramente el impacto probable. Lanzar el exploit por una captura de pantalla es temerario. Ejecutarlo repetidamente por «métricas de fiabilidad» multiplica la caída. Omitirlo en silencio oculta al cliente un riesgo serio y explotable.

Los compromisos profesionales terminan con una limpieza completa y un inventario de artefactos, para no dejar nueva superficie de ataque ni enturbiar el entorno del cliente. Dejar shells o cuentas para que el cliente las encuentre es negligente y peligroso: un atacante real podría reutilizarlas. Mantener una puerta trasera «para la próxima» es poco ético y probablemente ilegal. Borrar tus propios registros de actividad destruye la pista de auditoría que el cliente necesita para validar la prueba y reconstruir lo que hiciste.

Descubrir una intrusión activa es una emergencia fuera de banda: las reglas de enfrentamiento deben definir una ruta de escalada, así que invócala de inmediato, preserva las pruebas y evita contaminar un incidente en curso. Seguir probando puede interferir con el atacante real o destruir las pruebas que necesitan los respondedores. Intentar expulsar tú mismo al atacante queda fuera de alcance, es arriesgado y puede alertarlo. Esperar al informe final podría significar días de brecha continua y pérdida de datos.

Las pruebas de ingeniería social deben mantenerse dentro de pretextos acordados y éticos: lo bastante realistas para ser útiles, pero sin coacción, sin suplantar autoridades ni explotar situaciones personales o médicas. Un restablecimiento genérico de contraseña de IT acordado en las reglas de enfrentamiento es válido. Hacerse pasar por el hijo enfermo de un empleado real o amenazar a alguien con el despido causa un daño psicológico genuino. Hacerse pasar por las fuerzas del orden suplanta a una autoridad y suele ser ilegal incluso con un compromiso firmado.

Demuestra la vulnerabilidad sin perjudicar al cliente ni acumular sus datos: muestra que puedes leer datos arbitrarios mediante la versión de la base, el esquema o una sola muestra anonimizada, y detente ahí. Volcar todo el conjunto de datos personales genera responsabilidad de notificación de brecha y de tratamiento para ambas partes. Eliminar una tabla es destructivo y va mucho más allá de una prueba de concepto. Cifrar la base y exigir una recompensa es extorsión, no una prueba: es un delito, no un hallazgo.

La autorización define el compromiso: probar fuera del alcance acordado es potencialmente ilegal e infringe las reglas de enfrentamiento, por muy tentador que sea el objetivo. Documenta lo que viste, detente y obtén la aprobación escrita del cliente antes de continuar. Explotarlo por «más hallazgos» nunca justifica un acceso no autorizado. Explotarlo en silencio confiando en que no te pillarán es a la vez poco ético y un delito, y ampliar el alcance por tu cuenta priva al cliente de su consentimiento informado.

Un informe útil impulsa la remediación: clasifica por riesgo de negocio (probabilidad × impacto), destaca las cadenas de explotación que llevan a un compromiso crítico y da soluciones accionables para cada hallazgo. El orden alfabético entierra lo importante bajo lo que empieza por «A». Lo más largo primero premia la verborrea sobre la gravedad. Eliminar los hallazgos bajos oculta riesgo real y los patrones que el cliente necesita para la defensa en profundidad, dejándolo con una imagen falsamente tranquilizadora.

Una RCE sin autenticar en un servidor expuesto a Internet es de nivel emergencia: reduce la ventana de exposición con un despliegue probado, por etapas o gradual, y añade controles compensatorios (restringir el acceso, reglas WAF) mientras tanto. Esperar a la ventana trimestral deja un agujero explotable como un gusano abierto durante semanas. Parchear a ciegas en producción en horario laboral sin pruebas arriesga una caída y un rollback chapucero. Confiar en el firewall perimetral no sirve de nada — el servicio ya está expuesto y el exploit no necesita credenciales.

Los directivos son precisamente las cuentas que quieren los atacantes (BEC, fraude de transferencias), así que eximirlos invierte el modelo de riesgo. Resuelve la fricción, no el control: despliega passkeys/FIDO2 resistentes al phishing, más rápidos que los códigos. Ceder a la exención destruye la credibilidad del programa y deja sin protección tus cuentas de mayor valor. Cancelar el proyecto de MFA abandona un control de primer nivel. Activarlo a escondidas a sus espaldas destruye la confianza y la rendición de cuentas.

Los datos sensibles nunca deberían llegar a los registros: redacta o enmascara en el origen primero para detener la hemorragia, luego remedia los registros históricos y restringe el acceso. PCI DSS prohíbe almacenar así los PAN completos y los CVV, y las contraseñas nunca deberían registrarse. Unos registros «internos» siguen siendo un objetivo de primer orden. Cifrar o restringir el acceso al almacén sigue dejando secretos en texto plano en los registros, accesibles para cualquiera con permiso de lectura — copias de seguridad, pipelines de SIEM y administradores los ven todos.

El NIST AI Risk Management Framework (AI RMF 1.0) es un marco voluntario y basado en el riesgo para gobernar una IA confiable a lo largo de su ciclo de vida. Su núcleo son cuatro funciones: Govern (cultura, política, rendición de cuentas, y atraviesa las demás), Map (contexto e identificación de riesgos), Measure (evaluar y seguir riesgos) y Manage (priorizar y responder). También define características de confiabilidad: válida y fiable, segura, segura y resiliente, responsable y transparente, explicable, con privacidad mejorada y justa. Complementa listas técnicas como el OWASP LLM Top 10 a nivel de programa.

Los controles se clasifican de dos maneras. Por tipo: administrativo (políticas, formación, procedimientos), técnico/lógico (cortafuegos, MFA, cifrado) y físico (cerraduras, tarjetas, cámaras). Por función: preventivo (detener un evento — MFA, control de acceso), detectivo (descubrir un evento — SIEM, IDS, registros de auditoría), correctivo (reparar después — restaurar copia de seguridad, aplicar parche), disuasorio (desalentar — banners de advertencia) y compensatorio (una alternativa cuando el control principal no es viable). La defensa en profundidad superpone estos controles para que ningún fallo aislado lleve a un compromiso.

El artículo 5 del GDPR establece siete principios: licitud/lealtad/transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad, y responsabilidad proactiva. Ante una brecha de datos personales, el responsable del tratamiento debe notificar a la autoridad de control competente sin dilación indebida y, cuando sea posible, en un plazo de 72 horas tras tener conocimiento (artículo 33). Si la brecha probablemente entrañe un alto riesgo para las personas, el responsable también debe notificar a los interesados afectados sin dilación indebida (artículo 34).

La gobernanza es cómo la dirección fija el rumbo, define la rendición de cuentas y alinea la seguridad con los objetivos de negocio — las políticas, los roles y la supervisión que dicen cómo es «lo bueno». La gestión de riesgos es el proceso de identificar, evaluar, tratar y monitorizar las amenazas a esos objetivos. El cumplimiento consiste en demostrar la adhesión a las obligaciones — leyes, normativas, contratos y política interna. La gobernanza impulsa las decisiones de riesgo; el riesgo determina qué controles necesitas; el cumplimiento evidencia que esos controles satisfacen las normas exigidas. El cumplimiento es un resultado de una buena GRC, no un sustituto de la seguridad.

HIPAA (la ley estadounidense Health Insurance Portability and Accountability Act) protege la Protected Health Information (PHI). La Privacy Rule rige el uso y la divulgación de la PHI; la Security Rule se aplica a la PHI electrónica (ePHI) y exige tres categorías de salvaguardas — administrativas, físicas y técnicas. Se aplica a las covered entities (proveedores, planes de salud, cámaras de compensación) y a los business associates que manejan PHI en su nombre, vinculados por Business Associate Agreements. La Breach Notification Rule fija las obligaciones de notificar a las personas, al HHS y, a veces, a los medios.

ISO/IEC 27001 especifica los requisitos de un Information Security Management System (ISMS): un marco descendente y basado en el riesgo de políticas, procesos, roles y mejora continua (Plan-Do-Check-Act) que rige cómo una organización gestiona la seguridad de la información. El Anexo A es un catálogo de controles de referencia. No se aplican todos a ciegas — se realiza una evaluación de riesgos, se decide qué controles son necesarios y se documentan las decisiones de inclusión/exclusión con justificación en una Statement of Applicability (SoA).

El NIST Cybersecurity Framework organiza los resultados de ciberseguridad en funciones principales. En el CSF 2.0 hay seis: Govern (la nueva función global para estrategia, roles, decisiones de riesgo y supervisión), Identify (comprender activos y riesgos), Protect (salvaguardas para limitar el impacto), Detect (descubrir eventos), Respond (actuar ante incidentes) y Recover (restaurar capacidades). No son estrictamente secuenciales — funcionan de forma continua y, en conjunto, describen un ciclo de vida completo de gestión del ciberriesgo.

PCI DSS (Payment Card Industry Data Security Standard) es una norma de seguridad mantenida por el PCI Security Standards Council que se aplica a cualquier organización que almacene, procese o transmita datos de titulares de tarjetas. Se organiza en torno a objetivos de control que cubren una red segura, la protección de los datos almacenados, la gestión de vulnerabilidades, un control de acceso fuerte, la monitorización/pruebas y una política de seguridad de la información. El alcance es todo lo que está en el cardholder data environment (CDE) — por lo que la segmentación, la tokenización y no almacenar datos innecesarios son las principales formas de reducirlo.

Trata la concienciación como un cambio de comportamiento, no como una casilla anual. Hazla basada en roles (un desarrollador necesita contenido distinto al de finanzas), continua en lugar de una presentación una vez al año, y anclada en riesgos reales como el phishing, la ingeniería social y el manejo de datos. Refuérzala con simulaciones de phishing, recordatorios en el momento oportuno y canales de notificación claros. Mide resultados — tasa de notificación de phishing, tasa de clics, tiempo hasta notificar — no solo los porcentajes de finalización. Construye una cultura en la que la gente notifique sus errores sin miedo, porque el miedo suprime la notificación.

Un KPI (Key Performance Indicator) mide lo bien que rinde una actividad de seguridad frente a su objetivo — por ejemplo, el tiempo medio de detección, el cumplimiento del SLA de parcheo o el porcentaje de sistemas con MFA. Un KRI (Key Risk Indicator) es una señal prospectiva de que la exposición al riesgo aumenta hacia un nivel inaceptable, con un umbral que debería desencadenar una acción — por ejemplo, el número de parches críticos vencidos, el recuento de dispositivos no gestionados o las revisiones de acceso fallidas con tendencia al alza. Los KPI te dicen cómo lo estás haciendo; los KRI te advierten de hacia dónde te diriges.

Un informe SOC 2 Tipo I evalúa si los controles de una organización de servicios están diseñados adecuadamente en un único momento. Un informe Tipo II va más allá: prueba si esos controles operaron de forma eficaz durante un periodo de revisión, normalmente de 3 a 12 meses. Ambos se basan en los Trust Services Criteria de la AICPA — Seguridad (los criterios comunes obligatorios), más opcionalmente Disponibilidad, Integridad del procesamiento, Confidencialidad y Privacidad.

Trata el riesgo de proveedores como un ciclo de vida, no como un cuestionario puntual. Inventaría a tus terceros y clasifícalos por criticidad y sensibilidad de los datos. Ejecuta una due diligence proporcional al nivel — revisa informes SOC 2 / ISO 27001, cuestionarios de seguridad, resúmenes de pen-test, y los datos y accesos implicados. Incorpora controles al contrato (requisitos de seguridad, derecho de auditoría, notificación de brechas, tratamiento de datos, subprocesadores). Luego monitoriza de forma continua, no solo en el onboarding, y ten un proceso de offboarding limpio para revocar accesos y recuperar o destruir datos. El riesgo de cuarta parte (subprocesadores) también importa.

Las revisiones de acceso (recertificación) son comprobaciones periódicas en las que un propietario responsable confirma que el acceso de cada persona sigue justificado, y revoca lo que no lo está. Son la red de seguridad que detecta la acumulación de privilegios, las cuentas huérfanas y los derechos concedidos para un proyecto ya terminado. El control solo funciona si un propietario competente —normalmente el responsable o el dueño del recurso— examina de verdad el acceso en lugar de aprobarlo sin mirar, y si las revocaciones se aplican.