Security Data Scientist Career Guide: Skills and Routes

Security teams have more telemetry than analysts can read, and the security data scientist is the person who turns it into models, baselines and measurements that actually find attackers without drowning the SOC in false positives. The role sits between data science and detection engineering: statistics and machine learning applied to logs, identity events, network flows and fraud signals, plus a growing duty to assess the security of machine learning systems themselves. This guide covers what the role does, the skills interviewers test, the routes in from either side, the certifications that help and where the career leads. It is for data scientists moving into security, security analysts adding data skills, and managers deciding whether they need the role at all. Broader career routes are in the Cybersecurity Careers Guide.

Key takeaways

Security data is a hard data problem. Attacks are rare, labels are scarce and adversaries adapt, so the base-rate problem and drift dominate the job far more than model choice does.
The output is a working detection or a decision, not a notebook. A model that never reaches the SIEM, the fraud engine or a dashboard a manager uses has no security value.
Domain knowledge decides who gets hired. Knowing what a password spray (T1110.003) or a domain generation algorithm (T1568.002) looks like in the logs matters more than the newest model architecture.
NICE files the work under data analysis. The NICE Framework has no data scientist role; IO-WRL-001 Data Analysis lists tasks such as hypothesis testing and knowledge of machine learning and statistical processes.
Securing ML is now part of the remit. Poisoning, evasion and model theft are catalogued in MITRE ATLAS and NIST AI 100-2 E2025, and the data scientist is often the person best placed to test for them.

What the role does

In the NICE Framework (components v2.2.0) the closest work role is IO-WRL-001 Data Analysis, which analyses data from multiple sources to provide cybersecurity and privacy insight. The NICCS page for the role lists tasks including T1445 Conduct hypothesis testing, T0383 Program custom algorithms and T1440 Assess the validity of source data, knowledge statements including K0904 machine learning principles and practices and K1219 statistical processes, and skills such as creating statistical models and performing regression analysis. The work also overlaps PD-WRL-001 Defensive Cybersecurity, PD-WRL-005 Insider Threat Analysis and PD-WRL-006 Threat Analysis. Titles vary: security data scientist, security analytics engineer, detection data scientist, fraud data scientist and ML security engineer.

Problem area	Typical data	Example work	Where it lands
Identity anomaly detection	IdP sign-ins, Kerberos and cloud audit logs, service account activity	Baselines for rare logon locations and hosts; spray and credential stuffing scoring; misuse of valid accounts (T1078)	UEBA rules, risk scores fed to Conditional Access. See the UEBA Guide
Network and C2 analytics	DNS, proxy and flow records	DGA domain classifiers (T1568.002), beaconing detection over web protocols (T1071.001), exfiltration volume outliers (T1048)	SIEM detections, threat hunting leads
Alert triage and prioritisation	SIEM alerts with analyst dispositions	Models that rank alerts by likelihood of being true positive; duplicate clustering	SOC queue ordering, tuning backlog
Phishing and email	Message metadata, URLs, user reports	Classifiers for reported phishing (T1566), URL reputation features	Mail filtering, automated report triage
Fraud and abuse	Transactions, sessions, device signals	Account takeover and mule scoring, bot detection	Fraud engine rules and models. See the Fraud Metrics and KPIs Guide
Security measurement	Ticketing, vulnerability and asset data	Mean time to remediate distributions, coverage of ATT&CK techniques, risk forecasting	Board metrics. See the Security Metrics and KPIs Programme Guide
ML system security	Training data, model endpoints	Testing for poisoning (ATLAS AML.T0020 Poison Training Data) and evasion (AML.T0015 Evade AI Model)	AI risk assessments, model release gates

In control terms the work supports NIST SP 800-53 SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting and RA-10 Threat Hunting, and the NIST CSF 2.0 Detect function (DE.CM Continuous Monitoring, DE.AE Adverse Event Analysis).

Core skills and tools

Skill	What good looks like in security	How to practise
Statistics	Understands base rates: a detector with 99% specificity on a million events a day still produces about 10,000 false positives; chooses precision and recall targets with the SOC	Re-run a public detection dataset and report alert volume per day, not just accuracy
Machine learning	Picks simple, explainable models first; handles extreme class imbalance, time-based splits and leakage from labels	Build an unsupervised baseline and a supervised model for the same problem and compare
Query and data engineering	Fluent in KQL, SPL or SQL and a dataframe library; knows schemas such as OCSF	See the KQL for Threat Hunting Guide and OCSF Guide
Security domain knowledge	Knows Windows and identity events, network protocols and ATT&CK techniques well enough to engineer features from them	Generate attacks in a lab and inspect the telemetry they leave
Detection engineering	Ships models as rules or scored signals with tests, thresholds, owners and runbooks	See the Detection Engineering Guide
Communication	Explains why an alert fired in terms an analyst can act on; presents uncertainty honestly	Write one-page model cards for everything you build. See the Model Card and System Card Template
Data protection	Minimises personal data in features, documents lawful basis with privacy teams, secures notebooks and data stores	See the Jupyter Server Security Guide

Choosing an approach

Rules or statistics first: when the behaviour is well understood and labelled examples are few; thresholds and baselines are easier to explain and maintain.
Supervised models: when analysts already label outcomes at volume, as in phishing reports or fraud chargebacks.
Unsupervised or anomaly methods: for hunting leads and baselining, accepting that anomalies are not the same as attacks and need triage capacity.
LLM-based tooling: useful for summarising alerts or drafting queries, with evaluation and guardrails. See the LLMs for Detection Engineering Guide.

Where identity fits

Identity telemetry is the richest and most abused data set in most organisations. Service accounts, API keys and workload identities behave far more regularly than people, which makes them good candidates for baselining and makes deviations meaningful. See the Detection Engineering for Non-Human Identities Guide.

Routes into the role

Starting point	What transfers	What to add
Data scientist or analyst outside security	Statistics, modelling, Python, experiment design	Operating system, identity and network fundamentals; ATT&CK; time in a SOC or alongside one
SOC analyst or threat hunter	Telemetry knowledge, triage judgement, query fluency	Statistics and ML foundations, reproducible code. See the SOC Analyst Career Guide
Detection engineer	Rule lifecycle, testing, SIEM platforms	Modelling and evaluation methods. See the Detection Engineer Career Guide
Fraud analyst	Labelled outcomes, loss measurement, rule tuning	Cyber telemetry and wider attack techniques
Academic research	Method rigour, publication	Production engineering and working to operational deadlines

The US Bureau of Labor Statistics describes a bachelor's degree in mathematics, statistics, computer science or a related field as the typical entry level for data scientists generally, with some employers preferring a master's or doctorate, and projects employment of data scientists to grow 35% from 2025 to 2035. These figures cover all data scientists, not the security specialism. In the UK, DSIT's Cyber security skills in the UK labour market 2026 found AI skills were requested in 9% of core cyber job postings in 2025, up from 4% in 2024.

A portfolio that gets interviews

One end-to-end project on public security data: problem statement, features, model, evaluation with alert volume per day, and a written limitation section.
The same problem solved with a simple rule or threshold, and an honest comparison.
A detection written in a SIEM query language from your model's logic.
A short robustness test: how the model behaves when an adversary changes one feature.

Certifications that help

Certifications matter less here than a portfolio, but a few are directly relevant (checked 27 October 2026 on the issuers' pages where stated).

Certification	What it shows	Notes
GIAC Machine Learning Engineer (GMLE)	Applied ML for security practitioners	GIAC lists 82 questions, 3 hours and a 65% pass mark; areas include anomaly detection, deep learning, inferential statistics and Python
Blue team certifications	Security operations grounding for people coming from data science	See the Blue Team Certifications Guide
AI security certifications	Security of ML and generative AI systems	See the AI Security Certifications Compared
Cloud provider security certifications	Working with cloud-native security data platforms	See the AWS Certified Security Specialty Guide

Progression

Stage	Typical responsibility
Security data analyst	Queries, dashboards, metrics, feature exploration under guidance
Security data scientist	Owns models end to end with a detection or fraud team as customer
Senior or lead	Sets evaluation standards, reviews models, chooses platform and data architecture
Principal or head of security analytics	Owns the analytics strategy, data platform and measurement for the security function

Side moves include detection engineering leadership, AI security engineering (see the AI Security Engineer Career Guide), threat hunting and fraud analytics leadership. People in the role increasingly contribute to AI risk work under the NIST AI Risk Management Framework (AI RMF 1.0, January 2023, with the Generative AI Profile NIST AI 600-1 from July 2024), because they understand model behaviour.

How the work is measured

Precision at operating threshold: the share of model alerts analysts confirm as true positive.
Alert volume per day: what the SOC actually receives, against agreed capacity.
Incremental detections: confirmed incidents found by the model that rules did not catch.
Drift checks passed: scheduled performance reviews on fresh data, with retraining dates.
Time to production: days from idea to a monitored detection.

Common failure patterns

Accuracy theatre: reporting 99% accuracy on data where 99.9% of events are benign.
Random train and test splits: leaking future information; security data should be split by time.
Anomaly equals attack: shipping an outlier detector without triage capacity, then the SOC switches it off.
No feedback loop: analyst dispositions never flow back as labels, so the model cannot improve.
Ignoring the adversary: features that an attacker controls cheaply, with no robustness testing. See the Adversarial Examples and Evasion Attacks Guide.
Unsecured data science estate: notebooks and data lakes full of sensitive logs with broad access and long-lived keys. See the Security Data Lake Guide.

Practitioner checklist

Learn the telemetry first: Windows and identity events, DNS, proxy and cloud audit logs.
Map each project to ATT&CK techniques and a named detection or fraud customer.
Report alert volume per day and precision at threshold, never accuracy alone.
Split data by time and test on a later period than you trained on.
Build a rule or threshold baseline before any model and keep it if it wins.
Document every model with a card: data, features, limits, owner, review date.
Test robustness against an adaptive adversary using ATLAS and NIST AI 100-2 categories.
Secure notebooks and data stores and minimise personal data in features.

Standards and references

Related NHI Mgmt Group resources: Cybersecurity Careers Guide · Detection Engineer Career Guide · UEBA Guide · MITRE ATLAS Guide

Security Data Scientist Career Guide: Skills, Routes and Progression in Security Analytics