Una buena entrevista de ciberseguridad no consiste en pedir definiciones aisladas. La pregunta correcta revela cómo prioriza una persona, cómo comunica un riesgo, qué hace cuando faltan datos y si entiende las consecuencias operativas de sus decisiones. Una certificación puede confirmar formación, pero no demuestra por sí sola que alguien sepa contener una cuenta comprometida, reducir ruido en un SOC o explicar a dirección por qué un control merece presupuesto.
El contexto español hace que esta distinción sea especialmente importante. INCIBE gestionó 122.223 incidentes en 2025, un 26% más que en 2024, y detectó 237.028 sistemas vulnerables notificables (balance de ciberseguridad de INCIBE). La entrevista debe comprobar, por tanto, si el candidato puede trabajar con prioridades reales, no si memoriza vocabulario.
Usa estas 10 preguntas de entrevista de ciberseguridad según el puesto. Para un perfil SOC, profundiza en triage, telemetría y escalado. Para cloud security, exige arquitectura y control de identidades. En incident response, pide cronología y decisiones. En pentesting, separa el hallazgo técnico de la capacidad de demostrar impacto sin romper producción. En governance, evalúa riesgo, comunicación y responsabilidad. En cada respuesta, busca cuatro señales: contexto concreto, acciones propias, criterio técnico y medidas para evitar que el problema vuelva a ocurrir.
1. Cuéntanos sobre un incidente de seguridad que hayas gestionado. ¿Qué salió mal y cómo lo resolviste?
Esta pregunta separa rápidamente la experiencia operativa del conocimiento memorizado. Un candidato sólido no empieza enumerando herramientas. Explica qué ocurrió, cómo se detectó, qué sistemas estaban afectados, cuál era exactamente su responsabilidad y qué decisión tomó primero.
La respuesta debe tener una secuencia reconocible: validación de la alerta, delimitación del alcance, contención, erradicación, recuperación y revisión posterior. Un analista SOC junior quizá describa cómo enriqueció una alerta, aisló un endpoint con Microsoft Defender o escaló el caso. Un perfil senior debería explicar por qué eligió aislar una máquina, bloquear una cuenta o preservar evidencia antes de actuar.
Regla práctica: una historia de incidente sin decisiones personales no demuestra experiencia. Pregunta siempre “¿qué hiciste tú?” y “¿qué habrías hecho distinto?”.
La mejor respuesta reconoce un error sin convertirlo en una confesión vaga. Por ejemplo, el candidato puede explicar que una regla de detección generaba demasiado ruido, que una cuenta de servicio tenía permisos excesivos o que la documentación de escalado era insuficiente. Lo importante es que conecte el fallo con una corrección concreta, como ajustar una regla en Splunk, endurecer IAM o actualizar el playbook.
Si tiene poca experiencia profesional, puede usar un laboratorio, una prueba de seguridad o un pentest autorizado. No le penalices por no haber vivido una brecha grave. Evalúa si razona con método, documenta supuestos y aprende de la prueba.
La señal de alarma es una narración llena de nombres de productos, pero sin cronología, impacto ni responsabilidad. También preocupa quien asegura que todo salió perfecto, porque la respuesta a incidentes exige reconocer incertidumbre y trade-offs.
2. ¿Cómo mantendrías segura la infraestructura cloud de una startup que crece de 20 a 200 empleados en 6 meses?
La respuesta correcta no es “compraría una plataforma de seguridad completa”. Una startup que crece con rapidez necesita controles que acompañen al negocio sin convertir cada despliegue en una aprobación manual. El candidato debe ordenar el trabajo: inventario de activos, identidades, secretos, configuración cloud, protección de endpoints, registro de actividad y respuesta.
Pide que compare prioridades. En AWS, por ejemplo, debería hablar de IAM, roles temporales, MFA, separación de cuentas, CloudTrail, Security Groups y gestión de secretos con servicios como Secrets Manager. En Azure puede mencionar Entra ID, Defender for Cloud y políticas de Azure. En Google Cloud, IAM, Cloud Logging y Security Command Center. Lo importante no es la marca, sino entender qué problema resuelve cada control.
La escalabilidad también se ve en la relación con ingeniería. Un candidato práctico integrará escaneos de infraestructura como código, detección de secretos y validaciones de configuración en el pipeline. No impondrá bloqueos indiscriminados. Puede proponer excepciones documentadas, revisión de riesgos y correcciones priorizadas por exposición.
Para una empresa que está creciendo, conviene contrastar la respuesta con una guía para contratar expertos en ciberseguridad, especialmente al evaluar colaboración con developers y capacidad de comunicación.
La respuesta floja trata cloud como un centro de datos tradicional y olvida permisos, APIs, proveedores externos o cuentas de desarrollo. También es mala señal prometer seguridad absoluta. Un perfil competente explicará qué protege primero, qué acepta temporalmente y cómo revisará esas decisiones.
3. ¿Qué es una política de IAM bien diseñada? Diseña una para un developer junior en una startup
Una política de IAM bien diseñada concede acceso suficiente para trabajar y poco más. En una entrevista, no basta con que el candidato defina el principio de mínimo privilegio. Pídele que diseñe el acceso de una persona que necesita leer logs, desplegar en un entorno de desarrollo y consultar recursos concretos, pero no modificar producción ni acceder a datos reales de clientes.
La respuesta debería distinguir identidad humana, rol de aplicación y cuenta de servicio. También debería evitar credenciales estáticas, exigir MFA para accesos interactivos y separar desarrollo, staging y producción. Si propone una política JSON, comprueba si restringe acciones y recursos, en lugar de conceder permisos amplios con *.
Un candidato con experiencia explicará cómo manejaría una excepción. Quizá el developer necesite ejecutar una migración urgente. La solución madura no es compartir una cuenta de administrador. Es usar elevación temporal, aprobación trazable, duración limitada y revisión posterior.
Qué debe justificar el candidato
- Permisos concretos: Debe explicar por qué el rol puede leer un bucket o consultar un servicio, y por qué no puede borrar datos.
- Condiciones de acceso: Puede incorporar restricciones por entorno, red, dispositivo administrado o autenticación multifactor.
- Revisión: Tiene que describir cómo detectará permisos obsoletos y cómo revocará accesos cuando cambie la función.
- Comunicación: Debe saber explicar la restricción al developer con ejemplos de flujo de trabajo, no con lenguaje punitivo.
Una señal de alarma es diseñar una política que funciona solo porque concede administración total. Otra es hablar de IAM como una tarea aislada de seguridad. En la práctica, los roles deben coordinarse con plataforma, desarrollo y responsables de datos. Para un perfil junior, espera fundamentos y prudencia. Para un senior, exige además diseño de procesos, trazabilidad y automatización.
4. Explica la diferencia entre autenticación y autorización, y cómo implementarías ambas en una API REST
La distinción es básica, pero sigue filtrando respuestas débiles. Autenticación responde a quién es el usuario. Autorización determina qué puede hacer después de identificarse. Un candidato que las confunde puede diseñar una API vulnerable aunque conozca frameworks modernos.
Pídele que describa el recorrido de una petición. La API recibe un token, valida su firma, comprueba emisor, audiencia y expiración, identifica al principal y aplica autorización sobre el recurso solicitado. La autorización no debe limitarse a comprobar que existe un rol. También tiene que verificar que ese usuario puede acceder a ese objeto concreto, para evitar problemas de acceso a recursos de otros clientes.
Una respuesta razonable puede incluir JWT, OAuth 2.0 u OpenID Connect, pero el nombre del protocolo no sustituye al diseño. Pregunta dónde se almacenan los tokens, cómo se revocan, qué ocurre ante un refresh token robado y cómo se protegen los secretos de firma. El candidato debería preferir tokens de acceso con vida limitada y refresh tokens controlados, en lugar de credenciales válidas durante periodos excesivos.
Para valorar si entiende las consecuencias arquitectónicas, contrasta su explicación con las diferencias entre REST y GraphQL. El objetivo no es decidir qué estilo es mejor, sino observar si adapta controles a la forma en que la aplicación expone datos.
La señal de alarma más clara es “si el usuario tiene un JWT válido, puede acceder”. Un perfil competente habla de scopes, roles, ownership, validación de entrada, rate limiting y auditoría. Un junior debe explicar la diferencia sin errores. Un senior debe anticipar abuso, errores de configuración y evolución de permisos.
5. ¿Cómo evaluarías las vulnerabilidades en las dependencias de una aplicación? ¿Qué herramientas usarías?
Una dependencia vulnerable no demuestra por sí sola que la aplicación esté expuesta. La respuesta debe separar vulnerabilidad, exposición e impacto. Una librería puede incluir el componente afectado sin ejecutarlo, estar aislada de Internet o aparecer en una ruta que no procesa datos sensibles. El riesgo sigue registrado, pero la prioridad cambia.
Pide un proceso continuo, no una herramienta aislada. Puede combinar Dependabot o Renovate para actualizaciones con Snyk, Trivy, OWASP Dependency-Check y escáneres del proveedor de repositorios. También debe revisar imágenes de contenedor, dependencias transitivas, archivos de bloqueo y posibles secretos. Para validar hallazgos automatizados, un hacker ético puede complementarlos con pruebas manuales, como explica esta guía para contratar un hacker ético.
La automatización requiere reglas claras. Pregunta cómo trataría falsos positivos, paquetes abandonados y actualizaciones incompatibles. Un perfil competente separa detección de remediación, comprueba si la ruta vulnerable está activa y documenta cada excepción con propietario, justificación y fecha de revisión.
Qué demuestra experiencia real
- Priorización contextual: Relaciona severidad con exposición, privilegios necesarios, datos afectados y facilidad de explotación.
- Integración en CI/CD: Usa controles tempranos y reglas distintas para pull requests, builds y despliegues.
- Corrección verificable: Actualiza, prueba, vuelve a escanear y confirma que el riesgo desapareció.
- Gobierno de excepciones: Evita usar “falso positivo” como etiqueta permanente para cerrar alertas.
Los acuerdos de nivel de servicio por severidad ayudan a ordenar el trabajo, pero no prueban madurez por sí mismos. Pide quién decide, qué evidencia exige y qué ocurre si la corrección se retrasa. Un perfil senior también anticipa que actualizar una dependencia puede cambiar el comportamiento de la aplicación, por lo que exige pruebas antes del despliegue. Un junior debería explicar el flujo sin confundir la presencia del paquete con una explotación confirmada.
6. ¿Qué es OWASP Top 10 y cuál es el riesgo más crítico para una startup SaaS?
OWASP Top 10 es una referencia para riesgos frecuentes en aplicaciones web. No es una lista para recitar de memoria ni un sustituto de un análisis específico. Una startup SaaS debe traducirla a su arquitectura: APIs, gestión de sesiones, aislamiento entre clientes, integraciones, colas, almacenamiento y procesos de despliegue.
No esperes que todos los candidatos elijan el mismo riesgo. Espera que justifiquen la elección. Un fallo de control de acceso puede ser prioritario si permite que un cliente consulte datos de otro. Una mala gestión de secretos puede ser más urgente si expone credenciales de producción. Una dependencia vulnerable puede requerir atención inmediata si está expuesta y permite ejecución remota. La calidad está en conectar amenaza, exposición e impacto.
Una buena respuesta también delimita el alcance del estándar. OWASP Top 10 ayuda con aplicaciones web, pero no cubre por sí solo toda la seguridad de una plataforma SaaS, una aplicación móvil o un entorno cloud. El candidato debería proponer controles preventivos y detectivos, como revisión de autorización, pruebas de API, SAST, DAST, validación de entradas y análisis manual de flujos sensibles.
Pide un ejemplo. “Probaría IDOR” es insuficiente. Mejor: “crearía dos cuentas de prueba, intentaría acceder al identificador de un recurso ajeno, comprobaría la respuesta y revisaría que el backend valide ownership, no solo el frontend”. Ese nivel demuestra comprensión práctica.
La señal de alarma es ordenar los riesgos según una clasificación sin revisar el contexto. Un junior debe conocer el propósito del estándar. Un perfil mid debe aplicarlo a casos. Un senior debe convertirlo en requisitos, controles, pruebas y decisiones de producto.
7. ¿Cómo implementarías un sistema de logging y monitoreo de seguridad para detectar ataques?
El objetivo no es almacenar cada evento. Es conservar la evidencia necesaria para investigar y generar alertas que alguien pueda accionar. Un candidato competente empieza por las fuentes: autenticación, cambios de privilegios, creación de claves, modificaciones de configuración, acceso a datos sensibles, actividad administrativa, procesos relevantes y tráfico anómalo.
La arquitectura puede variar. Un entorno pequeño podría centralizar logs en servicios cloud y usar OpenSearch, Wazuh, Elastic Security o un SIEM gestionado. Un entorno más complejo puede necesitar Splunk, Microsoft Sentinel o Google Chronicle. No evalúes al candidato por escoger una plataforma concreta. Comprueba si sabe normalizar eventos, sincronizar tiempo, controlar acceso a logs y protegerlos contra manipulación.
La detección debe tener contexto. Un inicio de sesión imposible, una elevación de privilegios seguida de descarga masiva o la creación de una clave fuera del patrón habitual merecen más atención que una autenticación aislada. Pregunta cómo reducirá falsos positivos, qué datos añadirá a la alerta y cuándo escalará al responsable de guardia.
Señales que merece la pena buscar
- Cobertura: Identifica activos críticos y fuentes que faltan, en lugar de pedir “más logs”.
- Calidad: Distingue eventos útiles de ruido y define campos consistentes.
- Coste y retención: Considera volumen, almacenamiento, acceso y obligaciones internas sin prometer retención ilimitada.
- Respuesta: Relaciona cada alerta con un playbook, un propietario y una acción concreta.
Un SOC saturado por alertas inútiles pierde capacidad de detectar incidentes importantes. Para un perfil junior, espera investigación disciplinada. Para un senior, exige diseño de casos de uso, métricas operativas y mejora continua de reglas.
8. Describe tu proceso para realizar un code review desde perspectiva de seguridad
Un code review de seguridad no consiste en buscar una cadena sospechosa y bloquear el pull request. El candidato debe demostrar que entiende el flujo de datos y la lógica de negocio. Pregunta cómo revisaría autenticación, autorización, validación de entradas, gestión de secretos, serialización, manejo de errores, consultas a bases de datos y llamadas a servicios externos.
Las herramientas ayudan, pero no sustituyen el razonamiento. Semgrep, SonarQube, CodeQL y otros analizadores pueden encontrar patrones conocidos. El análisis manual sigue siendo necesario para comprobar si una API permite modificar recursos ajenos, si una función de recuperación de contraseña filtra información o si un cambio aparentemente pequeño rompe el aislamiento entre clientes.
Pide un ejemplo de código inseguro y su corrección. Una respuesta útil explica por qué concatenar entradas en una consulta es peligroso y cómo usar consultas parametrizadas. También puede mostrar que no basta con ocultar un error en el frontend, porque el servidor debe aplicar la validación y la autorización.
El mejor reviewer no gana discusiones con developers. Hace que el defecto sea fácil de entender, fácil de corregir y difícil de repetir.
Para perfiles DevSecOps, evalúa cómo incorporaría controles sin crear una puerta manual en cada entrega. Puede combinar reglas automáticas, plantillas seguras, ejemplos reutilizables y revisión humana para cambios de alto riesgo. También debe diferenciar un hallazgo bloqueante de una recomendación que puede entrar en el backlog.
La señal de alarma es revisar solo estilo y dependencias, o afirmar que una herramienta “garantiza” código seguro. Un junior debe identificar defectos comunes. Un mid debe explicar impacto y remediación. Un senior debe influir en patrones de arquitectura y formación sin convertir seguridad en un silo.
9. ¿Cómo manejarías la exposición de datos sensibles descubierta en producción?
Esta pregunta revela madurez porque obliga a coordinar técnica, dirección y cumplimiento. El candidato debe evitar dos errores opuestos: ocultar el problema hasta tener todos los detalles o comunicarlo sin verificar nada ni proteger la investigación. La primera acción debe ser confirmar el hallazgo, preservar evidencia y evaluar si la exposición sigue activa.
Después, debe activar el plan de respuesta y escalar según la estructura de la organización. CTO, dirección, asesoría legal, responsables de privacidad, comunicación y propietarios del sistema pueden necesitar información distinta. Si existe posibilidad de afectar a personas o datos regulados, el equipo legal y de compliance debe participar pronto. Las obligaciones concretas dependen del caso y de la jurisdicción, por lo que el candidato no debería improvisar plazos legales.
Técnicamente, puede ser necesario revocar credenciales, cerrar un bucket, corregir una política de acceso, aislar un servicio, invalidar sesiones o detener una ruta vulnerable. Cada acción debe quedar documentada con responsable y momento. La contención no termina cuando se cierra el acceso. Hay que revisar logs, determinar qué datos estuvieron disponibles, identificar quién pudo acceder y comprobar que no existen copias o rutas alternativas.
Cómo distinguir una respuesta madura
- No minimiza: Diferencia entre un hallazgo potencial y una exposición confirmada, sin restar importancia a ninguno.
- Escala pronto: Sabe cuándo involucrar a dirección, legal, privacidad y comunicación.
- Comunica con hechos: Separa lo confirmado, lo desconocido y las próximas acciones.
- Aprende: Propone corregir la causa, revisar controles similares y actualizar el plan.
Una señal grave es decir que esperaría a tener certeza absoluta antes de avisar a cualquier responsable. Otra es prometer una comunicación técnica idéntica para usuarios, reguladores y dirección. Un perfil senior debe proteger tanto el sistema como la trazabilidad de la decisión.
10. ¿Qué es Zero Trust Architecture y cómo la implementarías en una infraestructura startup?
“Never trust, always verify” no es una arquitectura completa. Si el candidato repite esa frase pero no puede traducirla a controles, la respuesta es teórica. Zero Trust exige verificar explícitamente identidad, dispositivo, contexto y autorización, además de limitar el acceso y asumir que una intrusión puede ocurrir.
En una startup, la implementación debe ser gradual. El primer paso puede ser centralizar identidades en un proveedor como Entra ID, Okta o Google Cloud Identity, exigir MFA y retirar cuentas compartidas. Después conviene revisar accesos entre servicios, separar entornos, usar roles de corta duración y proteger las comunicaciones con TLS. La segmentación, los proxies de acceso y la telemetría de endpoints completan el modelo, pero no sustituyen una política clara.
Pide al candidato que resuelva un caso: un portátil de un developer queda comprometido y la cuenta tiene acceso a repositorios, cloud y sistemas internos. Una respuesta fuerte limita sesiones, revoca tokens, evalúa la postura del dispositivo, restringe el acceso por aplicación y revisa actividad posterior. También reconoce que introducir controles puede afectar productividad y que deben probarse con equipos piloto.
El beneficio técnico no es una promesa abstracta. Si un atacante obtiene una identidad, los permisos limitados y la segmentación pueden reducir su movimiento lateral. La arquitectura, sin embargo, no funciona si la empresa conserva administradores permanentes, excepciones sin dueño o registros que nadie revisa.
Para un perfil junior, espera explicar el principio y algunos controles. Para un senior, exige mapa de dependencias, migración por fases, gestión de excepciones y métricas de adopción. La señal de alarma es vender Zero Trust como un producto único.