Preguntas de entrevista de CISO / Security Leadership

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.

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.

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.

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.

La continuidad del negocio (BCP) es la estrategia amplia para mantener las funciones críticas del negocio operando durante y después de una interrupción; la recuperación ante desastres (DRP) es el subconjunto centrado en TI que restaura sistemas y datos. El RTO es el tiempo máximo tolerable para restaurar una función; el RPO es la pérdida de datos máxima tolerable medida en tiempo.

La clasificación etiqueta los datos por sensibilidad para que la organización aplique controles proporcionales al valor y al riesgo, evitando tanto la infraprotección como la sobreprotección costosa. El propietario de los datos (un rol de negocio) fija la clasificación y acepta el riesgo, mientras que el custodio de los datos (a menudo TI) implementa y mantiene los controles de protección.

La defensa en profundidad superpone controles múltiples, variados e independientes a través de personas, procesos y tecnología, de modo que el fallo de cualquier control no resulte en un compromiso. Asume que todo control acabará fallando y usa la redundancia y la variedad para ralentizar, detectar y contener a un atacante.

La due diligence es la investigación y comprensión continuas de los riesgos (saber qué se debe hacer), mientras que la due care consiste en tomar las acciones razonables que una persona prudente tomaría para abordarlos (hacerlo realmente). La diligence es investigación y supervisión; la care es implementación y mantenimiento.

Una política es la declaración obligatoria de alto nivel de la intención de la dirección; una norma es una regla específica obligatoria que aplica la política (p. ej. AES-256); un procedimiento es el instructivo obligatorio paso a paso; una directriz es una recomendación opcional. Las políticas, normas y procedimientos son obligatorios, mientras que las directrices son discrecionales.

El análisis cuantitativo asigna valores monetarios concretos para calcular la pérdida esperada; el análisis cualitativo clasifica el riesgo en escalas relativas (alto/medio/bajo) mediante juicio experto. El cuantitativo usa SLE = valor del activo x factor de exposición, ARO = ocurrencias esperadas por año, y ALE = SLE x ARO para expresar la pérdida anual esperada en euros.

Puedes mitigar (reducir probabilidad/impacto con controles), transferir (trasladar el impacto financiero mediante seguros o contratos), evitar (detener por completo la actividad arriesgada) o aceptar (tolerar a sabiendas el riesgo residual). La elección depende del apetito de riesgo y de una comparación coste-beneficio frente a la pérdida esperada del riesgo.

Integra la seguridad en cada fase del SDLC en lugar de probar al final: los requisitos incluyen requisitos de seguridad y privacidad, el diseño incluye modelado de amenazas, el desarrollo sigue normas de codificación segura con SAST, las pruebas añaden DAST y revisiones, y el lanzamiento requiere aprobación, todo gobernado por la política, la separación de funciones y el control de cambios. Corregir los fallos pronto es drásticamente más barato que tras el lanzamiento.

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.

Una evaluación de riesgos identifica los activos y su valor, las amenazas y vulnerabilidades que podrían afectarlos, y luego estima el riesgo como función de la probabilidad y el impacto. Puedes hacerla cualitativamente (alto/medio/bajo, rápido y subjetivo) o cuantitativamente (SLE × ARO = ALE, basado en datos pero más difícil). Marcos como NIST RMF e ISO 27005 le dan estructura, y el resultado alimenta el tratamiento del riesgo: mitigar, transferir, evitar o aceptar.

Un buen informe sirve a dos públicos: un resumen ejecutivo que encuadra el riesgo de negocio para la dirección, y hallazgos detallados y reproducibles con evidencias, calificaciones de riesgo precisas y remediación priorizada para el equipo técnico. El informe — no el exploit — es el entregable.