CV Keywords for Cybersecurity Engineers and SOC Analysts (2026)

Cybersecurity is the field where the job title tells you the least. "Security Engineer" is used for monitoring alerts in a SOC, for writing detection rules, for running a vulnerability management programme, for administering identity systems, for cloud security architecture, and for compliance work that involves no technical tooling at all. Those are close to six different professions sharing one word, and they are hired by different people asking different questions.

The result is a specific failure mode for security CVs. A document that lists every security domain reads as unfocused to all six hiring managers. A document written tightly for one of them is invisible to the other five. Since most people in this field have genuinely touched several domains, the instinct is to list them all, and that instinct is what costs the interview.

There is a second complication that does not exist in the other roles in this series: much of the work cannot be described. Incidents are confidential, clients are under NDA, and the natural response is to write in abstractions that carry no keywords and no evidence.

This guide lists the term families that recur in security postings, explains which part of the work is systematically under-sold, and shows how to be specific about work you are not allowed to describe. Everything below applies to a CV and a resume alike, since the screening works the same way.

Decide which of the six jobs you are applying for

Read the posting for who the role reports to and what it is measured on. A SOC role is measured on alerts handled and time to triage. A detection engineering role is measured on the rules and the noise. Vulnerability management is measured on coverage and remediation time. Identity work is measured on access reviews and joiner-mover-leaver processes. Cloud security is measured on posture and misconfiguration. Governance, risk and compliance is measured on audits passed and frameworks maintained.

You can hold experience in several of these and should still lead with one. Put the domain the posting describes in your summary and your first two roles, and let the rest live further down. This is the single highest-return edit on most security CVs, and it costs nothing but ordering.

Name the platform, not the function

Recruiters search the applicant tracking system literally, and "SIEM" does not match a search for "Microsoft Sentinel". This is the most common way an experienced security CV becomes invisible, and it is covered in more depth in our guide on how ATS systems read your CV.

So write the platform name and let the category follow it:

• "Splunk" or "Microsoft Sentinel" rather than "SIEM platforms"
• "CrowdStrike Falcon" or "Microsoft Defender for Endpoint" rather than "EDR solutions"
• "Tenable Nessus" or "Qualys" rather than "vulnerability scanning tools"
• "Okta" or "Entra ID" rather than "identity and access management"

The category words still matter, because some postings use only those, but they belong alongside the product names rather than in place of them.

The families that recur

Ordered roughly by how often they appear in postings under these titles.

SIEM and detection. Splunk, Microsoft Sentinel, QRadar, Elastic Security, Wazuh. Alongside the platform, the verbs matter: writing correlation rules, tuning them, and reducing false positives. A candidate who has written detections is a different hire from one who has only worked the queue, and the CV should make clear which one you are.

Identity and access. Entra ID and Active Directory, Okta, single sign-on, multi-factor authentication, privileged access management, joiner-mover-leaver processes and access reviews. This family has moved to the centre of the field and remains under-represented on CVs written a few years ago.

Endpoint and email. EDR and XDR platforms, email security gateways, phishing triage. Phishing analysis is the most common real task in a first SOC job and the most commonly omitted line on a junior security CV.

Vulnerability management. Scanning platforms, CVSS, patch cycles, asset inventory, exceptions and risk acceptance. The part worth writing is not the scan, it is what happened to the findings afterwards.

Cloud security. AWS and Azure security services, CSPM tooling, IAM policy, network segmentation in the cloud, container and Kubernetes security. If your background is more platform than security, our DevOps keyword guide covers the neighbouring roles.

Network security. Firewalls with vendor names, IDS and IPS, VPN, zero trust and segmentation, packet analysis.

Incident response. Triage, containment, forensics, chain of custody, post-incident reporting, tabletop exercises. See below.

Frameworks and threat intelligence. MITRE ATT&CK is the one that appears most often and the one most worth using explicitly, because it lets you describe your detection work in a vocabulary the reader already shares. NIST CSF, the CIS Controls, threat intelligence feeds and IOCs follow.

Compliance. ISO 27001, SOC 2, NIS2, DORA, GDPR and PCI DSS. Even in technical roles these appear constantly in European postings, because the technical work is being driven by an audit deadline.

Scripting and automation. Python and PowerShell, SOAR platforms and playbooks, KQL and SPL for querying. Query languages are worth naming individually: they are the daily tool of the job and they filter well.

What security CVs under-sell

The first is writing. A large part of senior security work is a report someone else has to act on, a playbook a tired analyst follows at two in the morning, or an explanation that convinces an engineering team to change something it did not want to change. Employers ask for "communication skills" and candidates skip it as filler. It is not filler in this field. A line about the incident reports you wrote, the runbooks you own, or the security training you delivered answers a real requirement.

The second is noise reduction. Every SOC has too many alerts and every hiring manager knows it. "Tuned the detection set and cut false positives by 60%, taking the daily alert volume from 400 to 160" describes a capability most candidates have and almost none write down.

Certifications matter more here than in neighbouring fields

This is where security breaks from the pattern in the rest of this series. In infrastructure roles certifications are a tiebreaker. In security they appear in postings as stated requirements often enough that leaving yours out has a real cost, and some employers filter on them directly.

CISSP and CISM turn up in senior and management postings, Security+ in entry-level and in roles with a public-sector or defence flavour, OSCP where offensive work is genuinely part of the job, and the cloud security certifications follow the platform the employer runs. Put what you hold in its own short section, and put the one the posting names in your summary line as well.

The caveat is unchanged from the architect guide: a certification list is not a substitute for describing what you have done. It gets you past a filter, and then the document has to hold up.

Writing about work you cannot disclose

You are allowed to describe shape without disclosing substance. Anonymise the client, keep the scale, keep the technology, keep the outcome.

Instead of "handled security incidents for various clients", write "triaged and contained incidents for a manufacturing client with 4,000 endpoints, including a ransomware attempt stopped at the staging phase". No names, no dates, no detail that identifies anyone, and the line now carries a sector, a scale, a technology context and a result.

If even that is too much, describe the process rather than the event: the playbooks you built, the tooling you deployed, the volumes you worked at. Vagueness is a choice, and it reads to a hiring manager as inexperience rather than discretion.

Where the terms go

1. Title line, under your name: the security domain you are targeting, next to your real job title.
2. Summary, two or three lines: the environment, the domain, the platforms. "SOC analyst, 24/7 team of nine, Microsoft Sentinel and Defender across roughly 6,000 endpoints."
3. Experience bullets: the terms live here, attached to a volume or a result.
4. Certifications: a short dedicated section, and the relevant one repeated in the summary.
5. Skills section: the remainder, grouped by family.

What a rewrite looks like

Before:

Security analyst with experience in SIEM, incident response, vulnerability management and compliance. Responsible for monitoring security alerts and escalating incidents according to procedures.

After:

SOC analyst in a nine-person 24/7 team, running Microsoft Sentinel and Defender for Endpoint across roughly 6,000 endpoints for a manufacturing group. Triaged around 50 alerts per shift and led containment on 14 confirmed incidents, including a ransomware attempt stopped before encryption. Wrote 20 KQL detection rules mapped to MITRE ATT&CK and cut false positives by 60%. Ran the monthly vulnerability cycle with Qualys and brought critical remediation from 45 days to 12.

Same job. The second version names the platforms a recruiter searches for, attaches each to a number, and makes clear which of the six security jobs this candidate does.

Mistakes specific to security CVs

Listing all six domains equally. It reads as a course syllabus rather than a career. Lead with one and let the others support it.

Home labs and CTFs presented as operational experience. They are worth including, especially early on, and they belong in their own section. Mixed into the experience section they invite a question you do not want asked in an interview.

Writing the compliance CV for a technical role, or the reverse. ISO 27001 experience is an asset in a detection engineering application and it is not the headline. Match the emphasis to the posting.

Leaving out the query languages. KQL, SPL and the equivalents are daily tools, they filter well in an applicant tracking system, and they are omitted from a surprising share of otherwise strong CVs.

Once your terms are in place, the next step is adjusting them per posting rather than sending the same document everywhere. Our 10-minute tailoring routine is the short version of how to do that without rewriting your CV each time.

FAQ

Should my headline say blue team, red team or just security engineer?

Use the title from the posting, next to your official one if they differ. "Blue team" and "red team" are internal vocabulary and rarely what an applicant tracking system is filtering on, so put the searchable title first and let the specialisation come through in the summary and the experience bullets.

Do I need a CISSP?

Not for most technical roles, and not at all early in a career, since it requires five years of experience before it can be awarded. It appears most often in senior, architecture and management postings, and in organisations that sell to regulated customers. If the posting names it, say where you stand, including that you are working towards it. If it does not, the space is better spent on what you have operated.

How do I write about incidents covered by an NDA?

Anonymise the organisation and keep everything else: the sector, the scale, the platforms, what you did and what changed as a result. "A manufacturing client with 4,000 endpoints" identifies nobody and tells a hiring manager considerably more than "various clients". If a detail would still identify the customer, drop that detail rather than the whole line.

Is Security+ enough to get into a SOC?

It is often enough to pass the filter for an entry-level role, and it is a common requirement in public-sector and defence-adjacent postings. What decides the outcome after that is evidence you can work a queue: phishing analysis, log review, a home lab with a SIEM you actually query, and the ability to explain your reasoning about one alert clearly. The certificate opens the door and the reasoning gets you through it.