Cómo conseguir tu primer trabajo en ciberseguridad sin experiencia
Necesitas experiencia para conseguir trabajo, pero necesitas trabajo para tener experiencia. Ésa es la paradoja más frustrante al intentar entrar por primera vez en ciberseguridad. La salida no es estudiar más, sino transformar lo aprendido en señales que una empresa pueda evaluar. En esta guía recorremos la ruta completa —rol → brechas → práctica → evidencia → CV → candidaturas → entrevista → feedback— para que dejes el ciclo infinito de cursos y salgas al mercado con pruebas reales de lo que sabes hacer.
Cómo Conseguir tu PRIMER TRABAJO en CIBERSEGURIDAD (Sin Experiencia)
Empiezas a mirar ofertas y encuentras puestos etiquetados como junior con una lista que parece escrita para tres profesionales distintos: redes, Linux, Windows, cloud, SIEM, Python, Active Directory, pentesting, gestión de vulnerabilidades, inglés, certificaciones y experiencia previa. Cierras LinkedIn y vuelves a estudiar. Otro curso. Otra certificación. Otra herramienta. Otro roadmap.
Pasan los meses y sabes bastante más que cuando empezaste, pero sigues con el mismo problema: nadie puede evaluar con claridad qué eres capaz de hacer en un entorno parecido al del trabajo que buscas. Ahí está el cambio de enfoque de esta guía. Conseguir tu primer empleo no consiste únicamente en aprender más, sino en transformar lo aprendido en señales que una empresa pueda evaluar.
No es una fórmula oficial ni garantiza una contratación. Es una forma práctica de ordenar un proceso que suele volverse caótico cuando intentas resolver todo al mismo tiempo.
Respuesta rápida: cómo conseguir trabajo en ciberseguridad sin experiencia #
Puedes conseguir un primer trabajo en ciberseguridad sin haber trabajado antes en un departamento de seguridad. Lo que resulta mucho más difícil es conseguirlo sin conocimientos, práctica ni ninguna evidencia que permita evaluar tus capacidades. La diferencia es importante:
- No tener experiencia profesional en ciberseguridad es lo normal en alguien que busca su primer empleo.
- No haber investigado nunca un log, configurado un sistema, montado un laboratorio, documentado un proyecto o resuelto un problema técnico relacionado con el puesto deja a la empresa con muy pocas señales para decidir si puede contratarte.
Tu objetivo, por tanto, no es fingir experiencia profesional. Es construir experiencia relevante antes del primer contrato y saber presentarla con honestidad. Si vienes de cero absoluto, empieza por ordenar las bases con nuestra guía de cómo empezar en ciberseguridad desde cero.
Tu primer error puede ser buscar simplemente "trabajo de ciberseguridad" #
Imagina que alguien dice: "Quiero trabajar en medicina, ¿qué estudio?". La primera respuesta sería otra pregunta: ¿qué quieres hacer dentro de la medicina? En ciberseguridad pasa exactamente lo mismo.
La Agencia de la Unión Europea para la Ciberseguridad (ENISA) organiza el sector mediante su European Cybersecurity Skills Framework (ECSF), que identifica 12 perfiles profesionales representativos con distintas misiones, tareas, conocimientos y competencias. Su objetivo es crear un lenguaje común entre organizaciones, profesionales y proveedores de formación. Por eso "quiero trabajar de hacker" todavía no define un objetivo profesional. Puedes orientarte hacia:
- operaciones defensivas y SOC;
- respuesta a incidentes;
- pentesting y seguridad ofensiva;
- seguridad de aplicaciones (AppSec);
- gestión de vulnerabilidades;
- seguridad cloud;
- IAM e identidades;
- threat intelligence y análisis forense;
- GRC, riesgo y cumplimiento, auditoría e ingeniería/arquitectura de seguridad.
Estos caminos no exigen exactamente lo mismo. NIST añade una distinción útil: un Work Role describe un conjunto de responsabilidades y tareas, pero no es sinónimo de puesto o título laboral. Una empresa puede combinar varias funciones en un mismo puesto y usar nombres distintos para trabajos muy parecidos. Para ver el mapa completo de perfiles y qué hace cada uno, apóyate en nuestra guía de trabajos en ciberseguridad.
Antes de elegir otra certificación, haz algo mucho más útil: lee ofertas reales del trabajo que quieres conseguir. No una, varias. Busca patrones: ¿qué responsabilidades se repiten?, ¿qué conocimientos aparecen una y otra vez?, ¿qué herramientas cambian según la empresa?, ¿qué requisitos parecen centrales y cuáles solo deseables? El mercado laboral puede convertirse en parte de tu temario. Si aún dudas por dónde orientar el estudio, revisa qué estudiar para trabajar en ciberseguridad.
Construye la base técnica que exigen las entrevistas junior: sistemas, redes, procesos, usuarios y controles esenciales, sin tecnicismos innecesarios.
Una empresa no compra certificados: compra señales de que podrás hacer el trabajo #
Una empresa no puede abrir tu cabeza y revisar todo lo que sabes. Solo puede observar señales. Tu CV es una señal. Tus proyectos son señales. Una certificación es una señal. Tu experiencia previa es una señal. Cómo explicas una investigación en una entrevista también lo es. Incluso decir bien "no lo sé" puede convertirse en una buena señal.
Esto explica por qué dos candidatos con exactamente los mismos cursos obtienen resultados muy distintos. Uno escribe:
SIEM, Python, Linux, Windows, Wireshark, Active Directory.
El otro puede enseñar:
Monté un pequeño laboratorio con Windows y un SIEM, generé varios intentos fallidos de autenticación, investigué los eventos, documenté la secuencia y escribí una regla para detectar el comportamiento.
Los dos pueden haber estudiado SIEM. Solo uno aporta contexto sobre lo que hizo.
Lo técnico no es lo único que se evalúa
ISC2 publicó en 2025 un estudio sobre contratación de talento de entrada y junior, con 929 responsables de contratación de Canadá, Alemania, India, Japón, Reino Unido y Estados Unidos. No conviene convertir sus resultados en una regla universal para España o Latinoamérica, pero ofrecen una señal interesante: entre las capacidades mejor valoradas aparecieron trabajo en equipo, resolución de problemas y pensamiento analítico junto a los conocimientos técnicos. Además, el 84 % de los encuestados utilizaba algún tipo de evaluación o prueba basada en habilidades para candidatos entry-level o junior.
Esto desmonta una idea muy extendida: la entrevista no consiste solo en comprobar cuánto vocabulario técnico memorizaste. También quieren ver cómo razonas, cómo preguntas, cómo documentas, cómo colaboras, cómo reaccionas cuando falta información y si eres capaz de aprender sin convertir cada desconocimiento en una crisis.
La oferta "junior" que parece buscar un senior #
Llegamos a una de las experiencias más frustrantes. Encuentras "Cybersecurity Analyst — Junior" y debajo parece pedir varios años de experiencia, cloud, redes, SIEM, EDR, scripting, forense, threat hunting, pentesting, gestión de incidentes, cuatro certificaciones, disponibilidad permanente e inglés avanzado. Un poco más y también necesitan que conduzcas el coche del CEO.
Hay ofertas mal planteadas, descripciones recicladas y empresas que mezclan conocimientos obligatorios con una lista enorme de preferencias. Pero tampoco conviene caer en el extremo contrario y asumir que todos los requisitos se pueden ignorar. La habilidad útil es descomponer la oferta.
Separa una oferta en tres capas
| Capa | Qué significa |
|---|---|
| Requisitos realmente obligatorios | Condiciones legales, contractuales, lingüísticas, de disponibilidad o capacidades imprescindibles para desempeñar el puesto. |
| Núcleo del trabajo | Conocimientos y tareas que aparecen repetidamente y definen la función. |
| Deseables y ecosistema | Herramientas, tecnologías o conocimientos complementarios donde puede existir equivalencia o margen de aprendizaje. |
Supongamos que una oferta menciona repetidamente monitorización, análisis de alertas, Windows, redes, SIEM y documentación; y entre otros quince puntos incluye una herramienta SIEM concreta que nunca has usado. Quizás el problema no sea que desconoces ese producto. La pregunta útil es: ¿puedes demostrar que entiendes logs, eventos, investigación y consultas en otra plataforma suficientemente parecida como para aprender la herramienta específica? Eso es muy distinto de aplicar a un puesto cuyo núcleo completo desconoces.
¿Debo aplicar si no cumplo el 100 %?
No existe un porcentaje mágico. La famosa regla de "si cumples el 60 % o el 70 %, aplica" funciona como estímulo psicológico, pero no es una norma profesional verificable. Si falta un requisito legal o esencial, importa. Si no sabes ninguna de las tecnologías centrales del puesto, también. Pero si comprendes el trabajo principal, tienes fundamentos relacionados y la distancia restante parece razonable bajo supervisión, la candidatura puede tener sentido. No preguntes solo "¿cuántos requisitos cumplo?"; pregunta "¿qué parte del trabajo podría defender hoy con evidencia y qué parte tendría que aprender?".
Qué conocimientos necesitas antes de buscar tu primer empleo #
No existe una lista universal porque depende del rol. Un pentester junior y una persona que entra en GRC comparten fundamentos, pero su día a día no será idéntico. Aun así, en muchos puestos técnicos aparecen cuatro bloques con mucha frecuencia.
Redes: aprende a seguir una conversación
No necesitas convertirte en ingeniero de telecomunicaciones. Pero sí entender direcciones IP, TCP y UDP, puertos, DNS, HTTP/HTTPS, routing básico, NAT, firewalls, conexiones y la captura e interpretación básica de tráfico. Cuando una alerta dice "conexión saliente sospechosa hacia determinada IP", sin redes solo ves números; con redes empiezas a preguntar quién inició la conexión, hacia dónde, por qué puerto, con qué protocolo y si fue una sola conexión o hay periodicidad. La diferencia no es memorizar Wireshark: es poder interpretar lo que Wireshark muestra. Refuerza esta base con redes para ciberseguridad.
Modelo TCP/IP, puertos, direccionamiento IP, DNS, protocolos y análisis de paquetes: el idioma que necesitas para interpretar alertas y tráfico.
Windows y Linux: entiende lo normal antes de buscar lo anormal
Otro error habitual es empezar directamente con herramientas ofensivas. Pero tanto atacantes como defensores trabajan sobre sistemas. Necesitas entender progresivamente usuarios, grupos, permisos, procesos, servicios, sistema de archivos, autenticación, logs, tareas programadas, administración y privilegios. Si vas a Blue Team, Windows y Active Directory ganan importancia; si vas a pentesting, Linux será parte habitual de tu laboratorio, pero entender el sistema objetivo importa más que dominar una distribución concreta. Una idea resume el bloque: es difícil detectar lo anormal si todavía no sabes cómo funciona lo normal.
Fundamentos de seguridad: contexto antes que herramienta
Aprende a pensar en activos, amenazas, vulnerabilidades, exposición, impacto, controles, autenticación, autorización, mínimo privilegio, defensa en profundidad, detección, respuesta y recuperación. Una vulnerabilidad con puntuación CVSS alta no es automáticamente el problema más urgente: importa dónde está, si está expuesta, si existe explotación conocida, qué activo afecta, qué controles hay y qué impacto tendría. La herramienta entrega información; tu trabajo será aprender a darle contexto.
Programación y scripting: no necesitas ser desarrollador
La pregunta "¿necesito saber programar?" tiene una respuesta poco espectacular: depende. Un perfil AppSec necesitará bastante más código que muchos puestos GRC. Pero para numerosos perfiles técnicos, aprender progresivamente Python, Bash o PowerShell es muy útil. No empieces creando una aplicación enorme: automatiza una tarea pequeña —leer archivos, procesar logs, consultar una API, extraer indicadores, comparar hashes, filtrar información o transformar JSON/CSV—. Cuando haces la misma tarea a mano veinte veces aparece la buena pregunta: ¿podría automatizar parte de esto?
La trampa de estudiar eternamente #
Aquí aparece uno de los problemas que menos se reconoce: puedes estudiar muchísimo y seguir estancado. Curso, curso, curso, vídeo, roadmap, certificación, nuevo roadmap, nueva tecnología. ¿Por qué ocurre? Porque estudiar tiene una ventaja psicológica enorme: mientras sigues preparándote no tienes que exponerte a que alguien evalúe tu trabajo. No publicas el proyecto, no presentas el CV, no haces la entrevista, no escuchas un "no". Puedes seguir diciéndote "todavía me falta aprender un poco más".
Pero la ciberseguridad no se aprende solo consumiendo información. Llega un punto en el que tienes que producir: una configuración, un script, una investigación, un informe, un PCAP analizado, una detección, una matriz de riesgos, un laboratorio, un write-up, una presentación técnica. Algo que obligue a convertir información en decisiones. Estudiar te da ingredientes; resolver problemas demuestra que sabes cocinar.
Certificaciones: útiles, pero no son Pokémon #
Las certificaciones aportan valor: estructuran un temario, ayudan a detectar lagunas, dan una credencial reconocible, sirven como señal en ciertos procesos y facilitan que Recursos Humanos interprete tu nivel. El problema aparece cuando la estrategia se convierte en coleccionarlas: curso, certificado, otro certificado, otra insignia… y todavía ningún proyecto terminado.
El estudio de ISC2 encontró que una amplia mayoría de responsables consideraría a candidatos con experiencia IT previa o certificaciones de entrada, incluso sin otras señales tradicionales. Eso confirma que las certificaciones pueden ser útiles; no demuestra que sean obligatorias ni que sustituyan la experiencia práctica. La relación correcta se resume así:
- Certificación → demuestra que has estudiado determinados conocimientos.
- Proyecto → demuestra que intentaste aplicarlos.
- Entrevista → demuestra si entiendes las decisiones que tomaste.
No necesitas 15 certificados para tu primera oportunidad: necesitas que cada inversión tenga una función. Si buscas por dónde empezar, revisa qué certificación de ciberseguridad elegir para empezar y el debate entre máster vs. certificaciones.
El estándar internacional de ciberseguridad para perfiles de entrada: amenazas, arquitectura de control y gestión de incidentes, con práctica orientada al examen.
Universidad, FP, bootcamp, cursos: no lo conviertas en una guerra religiosa #
¿Universidad sí o no? ¿FP? ¿Bootcamp? ¿Cursos? ¿Certificaciones? La realidad es menos divertida para las redes sociales: cada opción resuelve problemas diferentes.
- Una titulación universitaria puede abrir requisitos académicos, procesos formales, prácticas, networking y una base amplia.
- Una FP puede ofrecer una ruta técnica y práctica excelente según el país y el programa.
- Una certificación valida conocimientos concretos frente a un estándar o fabricante.
- Un buen curso acelera el aprendizaje de una habilidad específica.
- Un proyecto demuestra aplicación.
No compiten necesariamente entre sí. Antes de decidir qué formación necesitas, pregunta: ¿qué problema falta resolver en mi perfil? Si quieres profundizar en esta decisión concreta, consulta nuestra guía sobre la carrera universitaria de ciberseguridad.
Experiencia profesional y experiencia relevante no son lo mismo #
Supongamos que nunca has trabajado en un SOC. Es una realidad, no hace falta esconderla. Ahora supongamos que además nunca abriste un log, nunca investigaste una alerta, nunca usaste un SIEM, nunca analizaste tráfico ni documentaste un incidente simulado. Ése es otro problema completamente distinto. El primero no puedes resolverlo solo: necesitas una empresa que decida contratarte. El segundo sí puedes empezar a resolverlo hoy.
Tu práctica debería parecerse progresivamente al trabajo que quieres aprender a hacer.
Si buscas SOC o Blue Team
- 1. Monta un pequeño laboratorio y genera intentos fallidos de autenticación.
- 2. Recoge y correlaciona eventos; crea una detección sencilla.
- 3. Documenta qué sucedió, qué evidencia encontraste, qué hipótesis consideraste, qué decisión tomarías y qué limitaciones tiene la investigación.
Profundiza en el rol con cómo ser analista SOC y en las habilidades de un analista SOC.
Si buscas pentesting
- 1. No te quedes en "conseguí root": la flag termina el reto, el trabajo profesional empieza después.
- 2. Documenta alcance, metodología, hallazgo, evidencia, impacto, reproducción, remediación y limitaciones.
- 3. Practica únicamente en sistemas propios, laboratorios, CTF o entornos con autorización expresa.
Empieza por cómo ser pentester para ordenar la metodología.
Si buscas GRC
- 1. Crea una empresa ficticia sencilla y define sus activos.
- 2. Identifica riesgos, relaciona amenazas y vulnerabilidades y propón controles.
- 3. Justifica prioridades y registra el riesgo residual.
La ciberseguridad no deja de serlo porque no haya una terminal negra en pantalla. Amplía con GRC en ciberseguridad.
Si buscas IAM o Cloud
- 1. Crea usuarios, grupos y roles en un entorno de laboratorio y aplica mínimo privilegio.
- 2. Introduce intencionadamente una configuración excesiva y analiza el riesgo.
- 3. Corrígela y documenta qué cambió y por qué.
No necesitas un proyecto gigantesco. Necesitas un proyecto del que puedas hablar durante diez minutos sin leer un tutorial.
Una de las puertas de entrada en alza y sin requisito de código: activos, riesgos, controles y evidencias, el lenguaje exacto para construir tu proyecto GRC.
El proyecto debería contar una historia #
Existe una diferencia enorme entre "Instalé Wazuh" y esto:
Quería comprobar si podía detectar una secuencia de intentos fallidos seguida de una autenticación correcta. Generé los eventos en mi laboratorio, los recogí en el SIEM, construí una consulta, revisé falsos positivos y documenté qué información adicional necesitaría antes de escalar el caso.
La herramienta es la misma. El segundo ejemplo demuestra problema, hipótesis, procedimiento, evidencia, limitaciones y decisión. Ésa es la estructura que interesa. Puedes usar una secuencia sencilla:
Cuando un proyecto cuenta esa historia deja de ser una colección de capturas de pantalla y se convierte en algo defendible.
Portfolio: tres buenos proyectos pueden decir más que treinta insignias #
No hay un número oficial de proyectos, ni el portfolio es obligatorio en todas las empresas. Pero cuando no tienes experiencia profesional específica, puede reducir muchísimo la incertidumbre. Un recruiter o responsable técnico debería poder entrar y responder rápido: ¿qué intenta aprender esta persona?, ¿qué ha construido?, ¿qué hizo realmente?, ¿sabe explicarlo?, ¿está relacionado con el trabajo?
No necesitas una web espectacular con partículas flotantes: necesitas claridad. Un buen proyecto debería indicar objetivo, arquitectura o entorno, herramientas, trabajo realizado, resultados, capturas o evidencia cuando aporten, problemas encontrados, limitaciones y qué cambiarías en una siguiente versión.
GitHub no debe ser un cementerio de tutoriales
Todos tenemos repositorios experimentales: test, prueba2, python-final-ahora-si. No pasa nada. Pero tu perfil profesional puede estar curado: selecciona, ordena, escribe buenos README y explica por qué existe cada proyecto. Tu README habla por ti cuando no estás delante del recruiter; dale algo interesante que decir.
Tu CV no tiene que conseguirte el trabajo: solo una conversación #
El CV tiene un objetivo más pequeño de lo que crees: conseguir una conversación. Eso cambia cómo lo escribes. No necesita contener todo lo que has aprendido desde que encendiste tu primer ordenador; necesita responder rápido: ¿qué puesto busca esta persona?, ¿qué conocimientos aporta?, ¿qué evidencia tiene?, ¿qué experiencia transferible puede servir?, ¿qué formación es relevante?
Si tu CV mezcla en el mismo nivel SOC, pentesting, machine learning, marketing, AWS, diseño, Java, forense, Scrum, Kubernetes y tres hobbies tecnológicos, quizás el problema no sea que te falten conocimientos: quizás nadie entiende cuál es tu candidatura. Para trabajar el documento en detalle, tienes una guía dedicada de CV de ciberseguridad sin experiencia.
Cada skill escrita en el CV es una pregunta potencial
Pones "Python — Avanzado". Perfecto. ¿Avanzado comparado con quién? ¿Qué hiciste con Python? ¿Clases, APIs, async, testing, automatización, parsing? En lugar de etiquetas vagas, contextualiza cuando sea posible:
Python: automatización básica y procesamiento de logs JSON/CSV.
Ahora existe contexto. Y recuerda una regla útil: si escribes una tecnología en el CV, prepárate para que la siguiente pregunta de la entrevista sea sobre ella. No rellenes habilidades como una colección de keywords: hazlo defendible.
No inventes experiencia para superar el problema de la experiencia
Un laboratorio no es experiencia laboral. Un CTF no es un pentest profesional. Hack The Box no es una consultora. Un proyecto universitario no es un cliente real. Y no necesitan serlo: puedes describirlos correctamente y seguir demostrando muchísimo. "Laboratorio personal de Blue Team" o "Proyecto práctico de análisis de vulnerabilidades" es perfectamente válido. Lo peligroso es transformar eso artificialmente en "Security Consultant — 1 año". La experiencia falsa puede ayudarte durante veinte segundos y después destruir toda la confianza de una entrevista. No inventes una historia mejor: construye una evidencia mejor.
ATS: optimiza para claridad, no para combatir un algoritmo imaginario
Los Applicant Tracking Systems existen, con muchos productos y configuraciones distintas. No hay un único "algoritmo ATS" universal que derrotes con cinco palabras secretas. Haz algo menos espectacular y más robusto: estructura sencilla, texto correctamente seleccionable, títulos de sección comprensibles, terminología real de tu área, skills que puedas defender, adaptación razonable al puesto y un PDF bien generado. Evita elementos que aportan poco, como "Python ████████░░ 80 %": ¿qué significa un 80 % de Python?, ¿quién tiene el 100 %? La precisión gana.
LinkedIn y networking: comprensible, no influencer #
No necesitas publicar cada día ni fotografiar una taza de café junto a "hoy quiero compartir que estoy increíblemente emocionado…". Usa LinkedIn de forma útil: que exista coherencia entre el trabajo que buscas, tu titular, tu descripción, tus proyectos, tu formación y lo que compartes. Si buscas Blue Team y acabas de investigar un comportamiento interesante, explica qué querías detectar, qué hiciste, qué falló y qué aprendiste. Eso muestra dos cosas: que aprendes y que sabes comunicar lo aprendido. Tu objetivo no es parecer famoso, es ser comprensible.
Y networking no es pedir empleo a desconocidos. Esto —"Hola, no nos conocemos, veo que trabajas en una gran empresa, ¿puedes recomendarme?"— coloca a alguien en una situación incómoda. Prueba algo distinto: si acabas de terminar un pequeño proyecto de detección, contacta con alguien que trabaje en SOC y pregunta:
He construido este laboratorio para practicar investigación de autenticaciones sospechosas. Estoy intentando mejorar la parte de triage. ¿Hay alguna señal o fuente de datos que creas que debería incorporar en una siguiente versión?
Ahora existe contexto, trabajo previo, una pregunta concreta y respeto por el tiempo de la otra persona. Quizás responda, quizás no. Pero ya no estás diciendo "dame empleo": estás entrando en una conversación profesional.
Buscar empleo también debería tener telemetría #
Hay una frase que escuchamos muchísimo: "He enviado 100 CV y nadie me contrata". Eso describe frustración, pero para diagnosticar necesitamos más información: ¿cuántos eran del mismo tipo de puesto?, ¿cuántos alineados con tu perfil?, ¿usaste el mismo CV?, ¿cuántos respondieron?, ¿cuántas entrevistas iniciales?, ¿cuántas técnicas?, ¿dónde terminó cada proceso? Porque los problemas pueden estar en partes completamente distintas.
Escenario A: muchas candidaturas, casi ninguna entrevista
Revisa puestos elegidos, requisitos centrales, CV, claridad del objetivo, evidencia visible y localización o autorización de trabajo cuando aplique.
Escenario B: entrevistas iniciales, pero nunca llegas a la técnica
Puede haber un problema de posicionamiento, comunicación, expectativas, experiencia o ajuste con el puesto.
Escenario C: llegas a la técnica pero caes ahí
Fantástico: no por el rechazo, sino porque ahora tienes información mucho más precisa. ¿Dónde fallaste? Redes, Windows, investigación, programación, comunicación, proyecto… Ese feedback construye tu siguiente plan de estudio.
Tu búsqueda laboral también produce logs. Analízalos.
Tu experiencia anterior no desaparece cuando cambias de carrera #
"Tengo 35 años." "Tengo 42." "He trabajado diez años en otra cosa." "¿Empiezo desde cero?" Técnicamente quizá seas junior en cierta función de seguridad, pero profesionalmente no necesariamente eres una persona sin experiencia. Alguien de soporte aporta diagnóstico, trato con usuarios, tickets, Active Directory, documentación y trabajo bajo presión. Un desarrollador traslada conocimientos a AppSec. Un administrador de sistemas ya comprende infraestructura, permisos, servicios y operación. Una persona de auditoría puede estar mucho más cerca de GRC de lo que piensa. Incluso atención al cliente aporta habilidades difíciles de enseñar: comunicación, gestión de conflictos, explicar conceptos complejos y trabajo bajo presión.
No borres tu carrera anterior para parecer un candidato de 19 años. Pregunta: ¿qué parte de mi experiencia anterior reduce el riesgo de contratarme para este nuevo trabajo? Ahí aparece tu ventaja. Si haces un cambio de sector a los 30, 40 o 50, tenemos una guía específica sobre empezar en ciberseguridad a los 30, 40 o 50 años con el framework PUENTE.
La entrevista técnica no premia solo al que memoriza más #
Puedes memorizar qué es DNS, TCP, un firewall, la tríada CIA, el phishing o una SQL Injection. Bien. Ahora llega la pregunta peligrosa: ¿por qué? Después otra: ¿cómo lo comprobarías? Y otra: ¿qué harías primero? Ahí termina el examen de memoria y empieza el razonamiento. En entrevistas junior pueden evaluar fundamentos, resolución de problemas, comunicación, proyectos, comportamiento, experiencia previa o ejercicios prácticos. No existe un único formato. Por eso practica conceptos, pero también escenarios. Puedes profundizar en nuestra guía de preguntas técnicas de entrevista en ciberseguridad.
Usa PISTA cuando tengas que resolver un escenario
Para estructurar respuestas técnicas puedes usar este modelo pedagógico (no es un estándar oficial de respuesta a incidentes, sino una forma de evitar respuestas impulsivas):
Modelo PISTA
- P Problema: ¿qué estamos intentando determinar?
- I Información: ¿qué datos necesito antes de actuar?
- S Señales: ¿qué evidencia tengo y qué indica?
- T Toma de decisión: ¿qué hipótesis es más consistente con la evidencia?
- A Acción: ¿qué haría a continuación y por qué?
Ejemplo de entrevista: PowerShell sospechoso
El entrevistador dice: "Hemos detectado PowerShell ejecutándose en un equipo. ¿Qué harías?" Una mala respuesta sería "bloqueo PowerShell". ¿Por qué? PowerShell es una herramienta legítima usada constantemente por administradores y software empresarial. Necesitas contexto, así que preguntarías: ¿qué usuario lo ejecutó?, ¿a qué hora?, ¿qué comando?, ¿qué proceso lo inició?, ¿con qué privilegios?, ¿qué ocurrió antes y después?
Ahora el entrevistador añade: "El proceso padre es Microsoft Word, PowerShell usa parámetros codificados y después aparece una conexión hacia una dirección externa." La historia cambió. Ahora puedes investigar el documento, el árbol de procesos, la línea de comandos, la conexión, DNS, proxy, EDR, hashes, eventos relacionados y otros endpoints. No se trata de enumerar veinte herramientas, sino de mostrar una progresión lógica: señal → contexto → investigación → decisión. Ese razonamiento es exactamente el que entrenamos en respuesta a incidentes.
Qué responder cuando no sabes algo
Esta habilidad puede salvar muchas entrevistas. Te preguntan algo y no lo sabes. Tienes tres opciones:
- Inventar. La peor: un entrevistador técnico suele detectar rápidamente cuando alguien improvisa conocimiento.
- "No sé" y silencio absoluto. Honesto, pero desaprovecha la oportunidad.
- Reconocer el límite y mostrar método. La mejor.
No recuerdo ahora mismo ese Event ID concreto. Para investigarlo empezaría revisando los eventos de autenticación relacionados —usuario, hora y origen— y después correlacionaría esos datos con el resto de la actividad.
Ahí has demostrado honestidad, fundamentos, procedimiento y capacidad de investigación. Nadie sabe toda la ciberseguridad. El profesional no es quien nunca necesita buscar información, sino quien sabe cómo buscarla, validarla y utilizarla sin inventar lo que todavía no sabe.
¿SOC es siempre la mejor puerta de entrada? #
No. Puede ser una buena opción para determinadas personas y mercados, pero también hay oportunidades en soporte con responsabilidades de seguridad, gestión de vulnerabilidades, IAM, GRC, administración de sistemas, consultoría, desarrollo con transición a AppSec, operaciones cloud y roles de seguridad técnica junior. No conviertas "SOC es una puerta habitual" en "todo el mundo tiene que empezar en SOC"; tampoco conviertas el pentesting en el único destino legítimo.
Tu primera entrada debería maximizar tres elementos: trabajo relevante + aprendizaje + posibilidad de progresión. A veces el mejor primer paso no lleva la palabra cybersecurity escrita en letras gigantes. Para comparar salidas y elegir con criterio, revisa el panorama completo de trabajos en ciberseguridad.
Lleva tu laboratorio SOC un paso más allá: integra análisis de alertas y respuesta automatizada con IA, la evidencia perfecta para una candidatura defensiva.
La IA cambia la barra, pero no elimina los fundamentos #
Una IA puede explicar un comando, escribir un script, resumir logs, crear una consulta, ayudarte con documentación o explicar una vulnerabilidad. Entonces aparece una pregunta lógica: ¿para qué necesita una empresa a un junior? Porque ejecutar instrucciones no es todo el trabajo. Alguien todavía debe decidir qué datos proporcionar, si contienen información sensible, qué preguntar, si la respuesta tiene sentido, si el comando es seguro, si existe autorización, si la conclusión está respaldada por evidencia y qué acción tomar.
La IA reduce el valor de algunas tareas puramente memorísticas y, con ello, aumenta el valor de los fundamentos, el criterio, la validación, el contexto y la comunicación. Una herramienta que produce respuestas más rápido también puede producir errores más rápido. Por eso: la IA puede acelerar tu método, pero no debería sustituirlo.
Un plan de 30, 60 y 90 días para empezar a moverte #
No es una garantía de empleo ni significa que alguien pueda formarse por completo en tres meses. Es un plan para abandonar el ciclo infinito de preparación sin producción.
Primeros 30 días: elegir dirección
- 1. Elige una familia profesional.
- 2. Analiza un conjunto suficiente de ofertas reales.
- 3. Identifica tareas y conocimientos repetidos.
- 4. Compara esos requisitos con tu nivel actual.
- 5. Elige las tres brechas más importantes.
- 6. Define un primer proyecto que produzca evidencia relacionada.
Al terminar deberías poder responder: "¿para qué puesto me estoy preparando?"
Días 31–60: construir
- 1. Cambia el verbo: de estudiar a construir.
- 2. Termina un proyecto; no empieces siete.
- 3. Documenta objetivo, arquitectura, procedimiento, resultados, errores y limitaciones.
- 4. Mejora la presentación y, si puedes, busca feedback técnico.
El objetivo no es crear algo enorme, es aprender a cerrar ciclos.
Días 61–90: exponer el trabajo al mercado
- 1. Prepara portfolio, GitHub, CV y LinkedIn.
- 2. Lanza candidaturas y practica simulaciones de entrevista.
- 3. Empieza a medir: el mercado ya te da feedback real.
Quizás necesites reforzar redes, quizás tu CV no comunica bien, quizás tus proyectos funcionan de maravilla, quizás las ofertas de tu región piden una tecnología que no estaba en tu roadmap. Ahora tu plan deja de construirse solo con consejos de internet e incorpora información real.
Preguntas frecuentes sobre el primer trabajo en ciberseguridad #
¿Puedo trabajar en ciberseguridad sin experiencia?
Sí, puedes conseguir un puesto sin experiencia laboral previa específica en seguridad, dependiendo del trabajo y del empleador. Eso no significa que puedas competir sin conocimientos ni práctica. Construir proyectos, laboratorios, experiencia IT relacionada y otras evidencias permite que una empresa evalúe mejor tu candidatura.
¿Necesito una carrera universitaria?
No existe una respuesta universal. Algunos empleadores, programas o procesos pueden exigir determinada titulación; otros aceptan FP, certificaciones, experiencia IT o combinaciones diferentes. Analiza los requisitos de tu mercado y del rol concreto, y contrasta opciones en nuestra guía de carrera universitaria de ciberseguridad.
¿Necesito certificaciones antes de buscar trabajo?
No necesariamente. Algunas ayudan en procesos de selección o permiten estructurar conocimientos, pero no existe una certificación obligatoria para toda la industria. Elige una cuando resuelva un problema concreto de tu perfil.
¿Cuántos proyectos necesito?
No existe un número oficial. Es preferible tener pocos proyectos relacionados con tu objetivo que puedas explicar en profundidad, que una colección enorme de ejercicios superficiales.
¿Necesito saber Python?
Depende del trabajo. Para muchos roles técnicos aprender scripting resulta valioso, pero no todos requieren el mismo nivel. Empieza usándolo para resolver tareas reales en lugar de intentar dominar todo el lenguaje antes de practicar seguridad. Tienes una guía de Python para ciberseguridad.
¿Pentesting es una buena primera especialización?
Puede serlo si construyes los fundamentos y encuentras puestos genuinamente junior, pero no es la única ruta. SOC, vulnerabilidades, IAM, GRC, sistemas, cloud y otras áreas ofrecen distintas puertas de entrada.
¿Cuándo estoy preparado para empezar a enviar CV?
Cuando puedas defender los fundamentos centrales del puesto, mostrar alguna evidencia relacionada y mantener una conversación honesta sobre lo que sabes y lo que todavía no sabes. Esperar a cumplir cada elemento de una lista ideal puede convertir la preparación en una excusa permanente.
Conclusión: tu primer trabajo empieza antes del primer contrato #
Nadie puede garantizarte cuándo llegará tu primera oportunidad: influyen el mercado, el país, el idioma, la experiencia previa, la formación, el rol, las ofertas disponibles, la calidad de tu candidatura y la competencia. Pero hay una parte que sí puedes controlar. No esperes a que una empresa te contrate para empezar a comportarte como alguien que resuelve problemas.
Tu primera empresa debería darte experiencia profesional. No debería ser necesariamente el primer lugar donde analizas un log, escribes un script, documentas un hallazgo o intentas resolver un problema de seguridad. Y recuerda: no necesitas inventar experiencia, necesitas construir evidencia. Después tendrás que conseguir que esa evidencia llegue a la persona correcta y saber defenderla cuando llegue la entrevista.
¿No tienes claro cuál es tu siguiente paso concreto? Responde unas pocas preguntas en el orientador de Achirou y encuentra la formación que encaja con el rol que quieres conseguir.