How to write a CV for a cyber security analyst role

What this CV has to prove, before anything else

A hiring manager for a cyber security analyst role is usually a SOC lead, a security operations manager, or a CISO's delegate who has read a stack of CVs that all say "proactive team player with strong analytical skills." None of that tells them what they need to know, which is: can this person work an alert queue without drowning in false positives, do they understand the difference between detection and response, and have they touched the tools this specific team runs.

The first third of the page has to answer three questions a recruiter in this field asks in order: what tier of SOC work have you done (L1 triage, L2 investigation, L3 threat hunting or incident response), what platforms have you actually used, and do you hold — or are you working towards — the certification the job advert named. If the advert says Security+ or SC-200, that phrase needs to appear on your CV in the same words, not paraphrased as "security certified." Applicant tracking systems and human reviewers both search on exact terms.

Don't open with a summary that could describe an IT support technician. "Cyber security analyst with experience in threat detection" is a job title, not evidence. Open instead with what you actually did: the SIEM you worked in, the incident types you handled, the scale of the environment (number of endpoints, whether it was a single site or a managed security service provider covering multiple clients).

Certifications, and how to list them so they're checked

This field has a genuine certification hierarchy, and hiring managers read it. Roughly, in order most SOC job adverts reference them:

• CompTIA Security+ — the baseline most L1 analyst roles ask for, sometimes as a stated requirement for a DoD 8570-aligned US government contract.
• CompTIA CySA+ — aimed specifically at analyst-level detection and response work, more relevant to this role than Security+ alone.
• GIAC certifications (GCIH, GCFA, GCFE, GNFA) — SANS-backed, common on job adverts for incident response and forensics-leaning analyst roles, and taken seriously because they're proctored and expensive to sit.
• CEH (Certified Ethical Hacker) — widely listed but treated with more scepticism by some hiring managers than GIAC or OSCP, because it's assessed as multiple choice rather than practical; still worth including if you hold it, but don't expect it to carry the same weight.
• OSCP (Offensive Security Certified Professional) — practical and respected, more common on threat-hunting or red-team-adjacent analyst roles than pure SOC triage ones.
• CISSP — usually a signal of seniority or a move toward management rather than hands-on analyst work; listing it for a first analyst role can read as overqualified or as if you're job-hopping upward, so use judgement.
• Vendor certifications — Microsoft SC-200 (Security Operations Analyst), Splunk Core Certified Power User, CrowdStrike Certified Falcon Responder. These matter disproportionately when the employer's stack is named in the advert, because they prove tool fluency, not just theory.

List the certification name in full with the awarding body, the year gained, and whether it's current — several of these (GIAC, CISSP) require renewal or continuing education, and letting one lapse silently and still listing it is the kind of thing that gets caught in a reference check or a technical interview.

If you're studying for one, say "in progress, expected [month/year]" rather than omitting it. A partially completed CySA+ still tells the reader you're moving in the right direction.

How experience is actually evidenced in this field

Generic CV advice says "use metrics." In this field, the metrics that mean something to a reviewer are specific to SOC and incident-handling work, and they only count if they're real numbers you can stand behind in an interview — don't invent a percentage to satisfy a template.

Things worth quantifying, if you genuinely have the figures:

• Alert volume and triage ratio — daily or weekly alert counts, and how you prioritised (e.g. by MITRE ATT&CK technique, by asset criticality, by SIEM correlation rule).
• Mean time to detect / mean time to respond — if your SOC tracked these and you improved them, say by how much and over what period, and be ready to explain what changed.
• Escalation accuracy — how often your L1 escalations to L2/L3 were confirmed as true positives, if that was measured. This is a stronger signal than raw alert count, because it shows judgement, not just throughput.
• Incident scope — number of hosts or accounts involved in incidents you worked, not to sound dramatic but because it tells the reader what scale of environment you're used to.

Where you don't have a number — many analysts never get given the underlying metrics by their employer — describe the mechanism instead: "Investigated SIEM-correlated alerts across [platform], distinguishing true positives from noise using [log sources: EDR telemetry, firewall logs, DNS logs, authentication logs] before escalating confirmed incidents to the IR team." That's more useful to a technical reader than a fabricated figure, and it survives being asked follow-up questions.

Name the actual tools, not categories. "SIEM experience" is weak. "Splunk Enterprise Security, six months hands-on writing and tuning correlation searches" or "Microsoft Sentinel, built KQL detection rules for lateral movement" is what gets you shortlisted, because it tells the reader you can start without three months of tool onboarding.

Frameworks belong on the CV too, used correctly: MITRE ATT&CK (mapped incidents or detections to specific tactics/techniques, not just "used MITRE ATT&CK"), NIST CSF or NIST 800-61 (if you followed an incident response lifecycle structured around it), ISO 27001 (if you supported audit evidence or control implementation), and any compliance regime the employer's sector cares about — PCI DSS for retail or payments, HIPAA for US healthcare, GDPR for anything handling EU personal data.

What a hiring manager scans for first

In rough order, based on how SOC hiring works in practice:

1. Tool overlap with their stack. If they run CrowdStrike and Splunk and you list Defender for Endpoint and QRadar, that's not disqualifying, but make the transferable skill explicit — "platform-agnostic EDR triage experience" — rather than assuming the overlap is obvious.
2. Shift and coverage experience. Many SOC roles run 24/7 rotations. If you've worked shift patterns, night cover, or on-call incident response, say so explicitly — it answers a practical staffing question before it's asked.
3. Clearance status, if the role needs one. UK government or defence-adjacent roles often require SC (Security Check) clearance or eligibility; US federal or contractor roles reference Public Trust or Secret clearance. State your current status plainly — "SC cleared, active" or "eligible for SC, not yet vetted" — because an advert requiring active clearance will filter out anyone who doesn't state it, even if they'd qualify.
4. Ticketing and documentation discipline. ServiceNow, Jira, or an internal case management system — analysts who can point to structured incident documentation are trusted more with escalation authority.
5. Certification currency, as above.

What they scan for that isn't on this list: soft skill adjectives. "Excellent communicator" and "detail-oriented" get skimmed past. If communication mattered in your role — writing incident reports for non-technical stakeholders, briefing leadership during an active incident — describe the situation, not the trait.

What analysts routinely leave off, and shouldn't

A few things that come up repeatedly as gaps on cyber security analyst CVs:

• Playbook and runbook authorship. If you wrote or updated SOC playbooks, that's evidence of maturity beyond following instructions, and it's frequently omitted because it feels like admin rather than "security work."
• False positive tuning. Reducing noise from a specific detection rule is a real, checkable achievement and rarely makes it onto CVs, possibly because it sounds unglamorous next to "stopped a breach."
• Threat intelligence consumption. If you used feeds — commercial, ISAC, or open source — to inform triage or hunting, name the source. "Applied threat intel" without naming what intel is vague enough to be ignored.
• Cross-team handoffs. Analysts who worked with IT operations, legal, or a third-party IR retainer during an incident often don't mention it, but it's exactly the kind of coordination a hiring manager wants reassurance you can do under pressure.
• Negative results. Investigations that concluded "no compromise found" are still evidence of sound triage judgement, not something to hide because they didn't end in a dramatic finding.

What to do next

Pull the actual job advert and mark every named tool, framework, and certification. Check your CV contains each one in the same wording, in the first half of the page, attached to something you did rather than a skills list. If a certification is in progress, state that explicitly rather than leaving a gap. Where you have real numbers — alert volume, MTTD improvement, escalation accuracy — use them; where you don't, describe the mechanism instead of inventing a figure you can't defend in an interview.

jobmarket.pro reads the advert in full, matches it against your actual experience, and drafts the application from a single profile it can't invent detail into — worth knowing about if the sticking point is matching your CV to what each specific advert is asking for, application after application.