Preguntas de entrevista de GRC / Compliance Analyst

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.

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.

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.

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.

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.

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.

DAC permite al propietario de los datos conceder el acceso a su discreción; MAC aplica el acceso de forma centralizada mediante etiquetas/habilitaciones y es no discrecional; RBAC concede el acceso a través de roles laborales; ABAC evalúa atributos (usuario, recurso, entorno) frente a una política para decisiones detalladas y contextuales.

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 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.

La gestión del ciclo de vida de la identidad rige una cuenta desde su creación hasta su retirada: aprovisionamiento en la incorporación (alta), ajuste de permisos al cambiar de rol (cambio) y desactivación oportuna en la salida (baja), con revisiones de acceso periódicas a lo largo del proceso. Los fallos más comunes son la acumulación de privilegios en los cambios y las cuentas huérfanas por desactivaciones omitidas.

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.

El cifrado en tránsito (TLS) protege los datos que se mueven por la red frente a la escucha y la manipulación; aplica TLS en todas partes y rechaza el texto plano. El cifrado en reposo protege los datos almacenados en discos y copias de seguridad, normalmente mediante claves gestionadas por KMS usando cifrado por sobre. Ambos son controles básicos, pero ninguno detiene una solicitud autorizada pero maliciosa — el servicio descifra de forma transparente para los llamantes válidos — así que el control de acceso sigue siendo lo más importante.

Un usuario es una identidad de larga duración con credenciales permanentes; un rol es una identidad sin credenciales permanentes que cualquier principal de confianza puede asumir para obtener tokens de corta duración; una política es el documento JSON que concede permisos, adjunto a cualquiera de los dos. El privilegio mínimo significa preferir roles a usuarios, acotar las políticas a acciones y recursos específicos, y conceder solo lo que una tarea necesita — y luego revisar y depurar con el tiempo.

El proveedor asegura la nube en sí — centros de datos físicos, hardware, el hipervisor y los servicios gestionados que ejecuta. Tú aseguras lo que pones en la nube — tus datos, identidades, configuraciones, el parcheo del SO cuando corresponda, y los controles de acceso. La línea exacta se desplaza: con IaaS eres dueño desde el SO hacia arriba, con SaaS eres dueño sobre todo de los datos y el acceso.

Una firma digital es el hash de un mensaje transformado con la clave privada del firmante. El verificador recalcula el hash, aplica la clave pública del firmante y comprueba que coinciden. Como solo el firmante posee la clave privada, una firma válida prueba que el mensaje proviene de él (autenticidad), no fue alterado (integridad) y que no puede negarlo de forma creíble (no repudio).

La tríada CIA son los tres objetivos centrales de la seguridad de la información: confidencialidad (solo las partes autorizadas pueden leer los datos), integridad (los datos no se alteran sin autorización) y disponibilidad (los usuarios autorizados pueden acceder a los sistemas cuando los necesitan). Casi todo control se relaciona con uno o varios de estos objetivos.

Una vulnerabilidad es una debilidad (software sin parchear). Una amenaza es un actor o evento que podría explotarla (un grupo de ransomware). El riesgo es la combinación de la probabilidad de que una amenaza explote una vulnerabilidad y el impacto si lo hace. Riesgo = amenaza x vulnerabilidad x impacto, y es lo que realmente se prioriza.

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.

La gestión de vulnerabilidades es un ciclo continuo: descubrir activos y vulnerabilidades (escaneo, inventario de activos), priorizar por riesgo real (CVSS más explotabilidad, exposición y criticidad de los activos — marcos como EPSS y SSVC ayudan), remediar o mitigar, verificar la corrección e informar sobre tendencias y SLA. El escaneo es la parte fácil; la disciplina está en priorizar y cerrar el ciclo para que el riesgo realmente baje con el tiempo.

Un escaneo de vulnerabilidades es un inventario automatizado y en amplitud de debilidades potenciales, a menudo con falsos positivos. Una prueba de penetración la dirige un humano: valida los hallazgos, los encadena y demuestra un impacto de negocio real mediante una explotación efectiva.

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.

El privilegio mínimo significa que cada usuario, proceso o servicio obtiene solo el acceso mínimo necesario para su tarea, y nada más. Reduce el radio de impacto de cualquier compromiso o error. Se aplica con acceso basado en roles, elevación just-in-time, revisiones de acceso periódicas y la eliminación de derechos de administrador permanentes.