Most security CVs fail for an unglamorous reason: they describe a field, not a job. "Cybersecurity professional with experience across threat detection, compliance and risk" could be anyone, and the person reading it runs a team that does one specific thing all day. Pick the shape of the role first, then prove you have done that shape of work.
Four different jobs share one title
"Security analyst" on a job advert can mean at least four things, and the CV that wins one of them loses another.
- SOC analyst. Shift work in front of a SIEM and an EDR console. The job is triage: deciding quickly which alerts are noise, which need escalating, and writing notes the next shift can follow.
- Incident response. Fewer events, each one much deeper. Containment, forensics, timelines, and a report that a lawyer and a board member can both read.
- Vulnerability management. Scanning, prioritising, and then the hard part, which is persuading other teams to patch. It is closer to project management than most candidates admit.
- GRC. Governance, risk and compliance: policies, risk registers, audits, supplier questionnaires, control evidence.
Read the advert and decide which one it is. Titles are unreliable, so go by the verbs: "monitor, triage, escalate" is a SOC, while "assess, document, evidence" is GRC. Then order your bullets so the matching work comes first under every role, even where it was only a third of your week.
What a hiring manager scans for
A security lead reading a CV is usually trying to answer three questions, and none of them is "how many tools does this person know".
Which environment have you worked in? Name the scale and type without naming the client: a 24/7 SOC at a managed service provider, an in-house team at a mid-sized retailer, a cloud-first estate versus on-premise Windows domains. A level 1 analyst at a managed provider and one inside a bank have had very different days.
What did you personally decide? "Participated in incident response" hides whether you ran the investigation or followed instructions. Use verbs that carry a decision: triaged, escalated, contained, wrote the detection rule, tuned it, closed the finding, rejected the risk exception.
Can you write? Every one of the four shapes ends in a document somebody else has to act on. Clean, specific bullets are the first evidence. Mentioning that you wrote runbooks, post-incident reports or audit responses is the second.
Tools belong on the page, but tied to what you did with them. "Splunk" in a skills list is a claim. "Wrote and tuned correlation searches in Splunk to cut repeat false positives on VPN alerts" is experience. Name the category alongside the product (SIEM, EDR, vulnerability scanner), because the team you are applying to may use a different vendor and still want the skill.
Certifications are examples of evidence, not a shopping list
Certifications carry weight in this field, and adverts often name them. Which one a given employer wants varies by role, country and seniority, so read the advert instead of trusting any ranking, including this one. As a rough map only: Security+ is commonly seen on entry-level applications, CEH and OSCP sit on the offensive side with OSCP known for its hands-on exam, CISSP is a broad qualification that asks for several years of experience, and ISO 27001 Lead Auditor or Lead Implementer shows up in GRC.
Put the ones relevant to the role where they can be seen quickly, with the issuing body and the date, and mark anything in progress as in progress. The mechanics of formatting them are covered in our guide to certifications on a CV. One opinion: a certificate with no bullet anywhere showing the skill in use reads as exam preparation, and an experienced interviewer will test exactly that gap.
Evidence when you have no security job yet
Junior candidates have a real problem: the role asks for experience with tooling you cannot legally touch outside an employer. The answer is to build a small, documented version of the work and show it.
A homelab. A couple of virtual machines, a free or community SIEM, logs flowing in, and one detection you wrote yourself. "Built a three-VM lab with a Windows domain controller and an open-source SIEM; wrote detections for brute-force logons and tested them with my own simulated attacks" is a better bullet than most internship lines.
CTFs and training platforms. List them sparingly. A rank or a count of solved rooms means little to someone who does not know the platform, so name what the challenges covered (web exploitation, log analysis, memory forensics) and one thing you learned the hard way.
Write-ups. This is the strongest of the three, because it proves the skill every shape needs. A short blog post or repository walking through how you investigated a retired challenge or analysed a public malware sample shows method, not just a result.
Two cautions. Only write up challenges whose rules allow it, and never describe testing a system you had no permission to test. On a security CV that is a reason to stop reading. Coming from helpdesk, sysadmin or networking? Pull the security-flavoured parts forward: lockout investigations, patching cycles, phishing reports you handled.
Metrics that are honest
Security numbers are easy to inflate and easy to see through. "Prevented 10,000 attacks" usually means the firewall did its job. Use figures you could explain in an interview, and say what they measure.
Some formats that hold up, with invented figures that show the shape and nothing else:
- Volume and judgment (SOC): "Triaged around 40 alerts per shift in a team of six, escalating roughly one in ten to level 2."
- Speed (SOC, incident response): "Helped bring mean time to respond on high-severity alerts from about four hours to under one."
- Coverage (vulnerability management): "Extended authenticated scanning from 60 to 95 percent of servers over two quarters."
- Audit (GRC): "Closed 18 of 22 findings from an internal ISO 27001 audit before the surveillance visit."
Notice what each one includes: a baseline, a scope, and your part in it. "Helped" and "in a team of six" are not weakness. They are the reason the reader believes the rest. With no numbers at all, do not invent them: give scale instead, such as endpoints monitored or the size of the on-call rota.
A metric you cannot explain for two minutes in an interview does not belong on a security CV.
What must stay confidential
Here a security CV differs from every other technical CV. How you handle sensitive information on the page is itself a work sample, and hiring managers read it that way.
Leave out:
- Client names, if you worked for a consultancy or managed provider, unless the relationship is public and your contract allows it. "A European logistics group" is enough.
- Unpatched or recently fixed findings. Never describe a specific weakness in a named organisation's systems.
- Incident detail that could identify the victim, the attacker's route in, or anything not already in a public statement.
- Internal architecture: hostnames, IP ranges, the exact security stack of a named employer.
You can still describe the work. "Led containment of a ransomware incident affecting around 200 endpoints at a manufacturing client; operations restored in four days" (illustrative again) gives the shape, your role and the outcome without exposing anyone. Our post on NDA-covered figures goes further on turning restricted numbers into ranges, and security clearance has its own guide: state the level only if you are permitted to.
Before you send it
Take the advert, decide which of the four shapes it is, and rewrite your top five bullets so each has a decision you made, a scope and, where you have one, a number you can defend. Then read the whole page as an attacker would and remove anything that tells a stranger about a former employer's defences. If your work history lives on LinkedIn, a tool like Postulit can turn the profile into a CV layout quickly, which leaves your time for the part no tool can do: choosing what to say and what to keep quiet.