Cybersecurity Career Paths: Which Role Fits You?

Security work is not one job. Some people spend their day reading alerts in a monitoring console. Others test web applications with permission, write the code that stops those bugs, or rebuild a compromised laptop from evidence. If you are starting out or changing careers, the fastest way to choose is to compare what the work looks like day to day, then try one or two roles with free practice before you pay for a course.

This article covers eight common roles: SOC analyst, incident responder, application security (AppSec) engineer, penetration tester, digital forensics and incident response (DFIR) analyst, vulnerability management analyst, governance, risk and compliance (GRC) analyst, and security engineer. For each one you get the daily work, the core skills, a first practice step that costs nothing, and the Field Manual articles that train those skills. The last section is a worksheet. Pick two roles, list three skills for each, and choose the article to read first.

Job titles vary by employer. Treat these descriptions as working pictures of the job, not as a guarantee of what any particular role includes.

#How the roles are organized

#What the NICE Framework is

NIST describes the NICE Framework as "a common language that describes cybersecurity work." The framework is documented in NIST Special Publication 800-181 Revision 1, finalized in November 2020. It groups work roles into categories and specialty areas, and each role is described by the tasks, knowledge and skills it needs. Employers, schools and training programs use this vocabulary, so a job posting that names a role is often using NICE language even when it adds its own wording.

The CISA Cyber Career Pathways Tool, published through the National Initiative for Cybersecurity Careers and Studies (NICCS), lets you select a work role, read its statements and compare two roles side by side. The tool states that it uses NICE Framework Components version 2.2.0. Each role below names the closest work role as the tool lists it. Framework role titles are broad (Defensive Cybersecurity, Digital Forensics) and differ from job titles, and the components have been revised since the 2020 publication, so look each one up in the tool before you quote it on a résumé.

#Why the role matters more than the tool

Beginners often start with a tool list: Nmap, Burp Suite, Wireshark, Splunk. A tool is an instrument, and the role decides which question you are trying to answer. A SOC analyst asks whether an alert describes a real event and what else that host did. A penetration tester asks what an attacker could reach inside an agreed scope. A GRC analyst asks whether the controls match the written risk. Pick the question first. The tools follow from it.

#The eight roles

#1. SOC analyst

Closest NICE work role: Defensive Cybersecurity.

Daily work. A security operations center (SOC) analyst works through an alert queue. Each alert gets triaged: is it a true positive, a false positive, or something that needs a closer look? Most of the day goes to reading log events, following one event to the events around it, checking whether a user or host behaved as expected, and writing short notes that another analyst can follow. Anything that looks like a real incident goes up to the responders.

Core skills. Reading logs, recognizing common Windows and Linux events, basic networking (DNS, HTTP, ports), writing search queries, documenting clearly and knowing when to escalate.

First free practice step. On your own Windows PC, open PowerShell as an administrator and read the last 20 failed logon events from the Security log. Event ID 4625 is the failed logon event. I have not run this command for this article, so you will see whatever your machine records:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 | Select-Object TimeCreated, Message

Write down what each event means and whether you recognize the account. If the list is empty, that is also a result. Do not read logs from machines you do not own.

Read first: What Is a SIEM? Logs, Queries and Alerting, How HTTP Works, Linux Files and Permissions.

#2. Incident responder

Closest NICE work role: Incident Response.

Daily work. Responders take over when an alert becomes an incident. They coordinate containment (isolating a host, disabling an account, blocking an address), eradication (removing the access path the attacker used) and recovery. They keep a timeline, update IT, legal and management, and decide when the incident is over. Much of the work is clear communication under time pressure.

Core skills. Triage, containment tradeoffs, timeline building, status writing, understanding how phishing and stolen credentials usually move through a network, and basic evidence handling so that later analysis is still possible.

First free practice step. Write an incident timeline for an invented case, in a plain text file. For example: "10:02 user opens an attachment; 10:04 a new scheduled task appears; 10:10 an outbound connection to an unknown address." Next to each line, write which log or artifact would confirm it. You need no tools for this. The skill is sequencing facts and separating what you know from what you suspect.

Read first: How to Write Your First Security Report, Threat Modeling with STRIDE, What Is a SIEM?.

#3. Application security (AppSec) engineer

Closest NICE work role: Software Security Assessment, often alongside Secure Software Development.

Daily work. AppSec engineers help development teams avoid vulnerabilities before release. They review designs and code, provide secure patterns and shared libraries, set up automated checks in build pipelines, and go through findings with the developers who own the code. A good day often ends with a fixed bug rather than a long report.

Core skills. Web fundamentals (HTTP, cookies, sessions, same-origin rules), at least one programming language, the categories in the OWASP Top 10, input validation and output encoding, and reading code you did not write.

First free practice step. Run OWASP Juice Shop, a deliberately vulnerable web application, on your own machine. Bind it to localhost so only your computer can reach it. Docker must be installed. I have not run this command for this article, so the output is whatever your environment prints:

docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Open http://localhost:3000 in your browser, pick one beginner challenge, and write down the root cause and the fix a developer would apply. Stop the container when you are done.

Read first: OWASP Top 10 for Developers, SQL Injection Explained with Juice Shop, What Is CSRF and How SameSite Cookies Help.

#4. Penetration tester

Closest NICE work role: none by that title. The tool has no penetration tester role, so read Vulnerability Analysis and Threat Analysis for the nearest tasks.

Daily work. Penetration testers assess systems that the owner has agreed to test, inside a written scope and rules of engagement. They map the target, look for weaknesses, confirm impact without causing damage, and write findings that a developer or administrator can act on. Much of the professional value sits in the report and in judgment about what matters. A scanner output alone is not a finding.

Core skills. Networking, web and directory basics, scripting, scope discipline, risk rating with CVSS, report writing, and a firm understanding of authorization.

First free practice step. Write a scope document for your own lab before you touch anything. Use the Juice Shop container from the AppSec step or a virtual machine you own. List what is in scope (this container on localhost port 3000), what is out of scope (everything else, including your router, your neighbors' networks and any site you do not own), who authorized the work, and the start and end times. The document is the practice. Testing begins only after it exists.

Read first: What Is a Vulnerability?, What Is CVSS?, OSINT Ethics and Privacy, How to Create an Isolated Docker Network for Labs.

#5. DFIR analyst

Closest NICE work role: Digital Forensics.

Daily work. A DFIR analyst examines evidence from systems that may be compromised: disk images, memory captures, event logs, browser and file artifacts. The goal is to reconstruct what happened, record how each conclusion was reached, and keep the evidence unchanged. Incident responders decide what to do next; DFIR analysts explain what happened, with proof.

Core skills. File systems, file hashes, Windows and Linux artifacts, disk and memory analysis tools, chain of custody, careful note-taking, and enough malware knowledge to describe behavior without running samples on a normal machine.

First free practice step. Compute a SHA-256 hash of a file you downloaded from a trusted source. Hashes are the basic tool for showing that evidence has not changed. In Git Bash, on a file you choose:

sha256sum ~/Downloads/example.pdf

Record the output next to the file name and the date. If the publisher lists a hash for the download, compare the two values. Hash checks read the file and never run it. Do not open or run unknown files to see what they do.

Read first: File Hashes and VirusTotal: Ethics, Linux Files and Permissions, What Is Bash? Shell Basics for Security Students.

#6. Vulnerability management analyst

Closest NICE work role: Vulnerability Analysis.

Daily work. Vulnerability managers keep an inventory of assets and their known weaknesses, decide which fixes come first, track owners and deadlines, and report progress. The hard part is prioritization. A scanner can produce thousands of findings, and the job is to decide which ones matter for this organization this week, given what is exposed to the internet and what the business depends on.

Core skills. Asset inventory, reading CVE and CVSS records, understanding patch cycles, risk-based prioritization, working with system owners, and ticket-based workflows.

First free practice step. Open a recent CVE on the public NVD website (nvd.nist.gov). Read its description and its CVSS vector. Then write three sentences: what the flaw is, what conditions an attacker would need, and what a responsible owner would do on a system they run. Public lookups like this are harmless. Do not query or test any system you do not own.

Read first: What Is a Vulnerability?, What Is CVSS?.

#7. GRC analyst

Closest NICE work role: Security Control Assessment, with overlap into Cybersecurity Policy and Planning.

Daily work. GRC (governance, risk and compliance) analysts turn security requirements into policies, controls and evidence. They maintain risk registers, gather evidence for audits, check whether vendors meet contract terms, and help leaders decide which risks to accept, reduce or transfer. Little of this work touches a terminal. Much of it is careful reading and checking written claims against what the systems actually do.

Core skills. Policy writing, risk assessment, common frameworks such as the NIST Cybersecurity Framework and ISO/IEC 27001, evidence collection, stakeholder interviews, and plain writing.

First free practice step. Write a one-page risk register for your own laptop. Use five rows: lost device, weak password, outdated operating system, phishing, and backup failure. For each row, write the likelihood and impact in plain words, the control you use today, and one next step. Keep it in a text file. If you can explain why a control matters in one sentence, you are doing the job.

Read first: Threat Modeling with STRIDE, What Is HTTPS and TLS?, Encryption vs Encoding vs Hashing.

#8. Security engineer

Closest NICE work role: Cybersecurity Architecture and Secure Systems Development.

Daily work. Security engineers design and build protective systems: identity and access setup, single sign-on and multi-factor authentication, network segmentation, secrets management, secure configuration baselines and detection pipelines. They work between development and operations, and they measure whether a control works after it is deployed, not only whether it was installed.

Core skills. Operating systems administration (Linux or Windows), cryptography at the usage level (keys, hashing, TLS), identity and least privilege, infrastructure as code, scripting, and careful change control.

First free practice step. Create an SSH key pair on your own machine and learn which file is the public one. I have not run this command for this article, so the output depends on your setup. Choose a passphrase when prompted:

ssh-keygen -t ed25519 -f ~/.ssh/lab_ed25519 -C "lab key"

Then list ~/.ssh. The file ending in .pub is the one you can share. The file without an extension is the private key, and it never goes into chat, a commit or a screenshot.

Read first: Public and Private Keys Explained, What Is SSH and How Do SSH Keys Work?, How Password Hashing Works with Argon2id.

#Choose with the worksheet

This article has no lab that needs a server. The exercise is a self-assessment, and it takes about 30 minutes.

1. Pick two roles from the list that you find interesting, even if you are not sure you could do them.
2. For each role, write down three skills you already have and three you would need to build. Be honest. "Read logs" and "use Linux" are fine if you can do them today.
3. Choose one Field Manual article per role to start with, from the Read first list.
4. Do the first free practice step for each role. Note what took longer than you expected.
5. Look up both roles in the CISA Cyber Career Pathways Tool and compare their work role statements side by side.

Copy this template into a text file:

Role 1:
  Skills I have:
    1.
    2.
    3.
  Skills I need to build:
    1.
    2.
    3.
  Article to start with:
  First practice step done on (date):
  What surprised me:

Role 2:
  (same lines as above)

The worksheet is finished when you can say which role you would try first and why, in two sentences.

#Common mistakes

Choosing by title alone. Titles mean different things at different employers. Read the daily work and the skill list before you decide.

Starting with offensive tools. Knowing how to run a scanner does not teach you what the scanner's output means. Learn how networks, web requests and Linux permissions work first.

Skipping the scope. Any practice against a system you do not own is a legal and ethical problem, even when the target looks harmless. Your own container, your own machine and an explicit written scope are the only starting points in this article.

Treating a course completion as proof. A certificate shows that you studied. A timeline, a risk register, a scope document or a fixed bug shows what you can produce. Keep the artifacts from each practice step.

Running unknown files to see what they do. Use hashes, read the file in a text viewer, or read the documentation. Execution belongs in a controlled lab, and not on your everyday computer.

#How to go further

Once you have two roles on your worksheet, read the NICE work role statements for each one in the CISA tool. Some roles also link to TryCyber micro-challenges, which give small hands-on exercises for core tasks. Then work through the Field Manual articles in the order listed for your first role. Revisit the worksheet after a month and update it with what you actually did.

If you ask an AI assistant to explain a log line or a code snippet, check the answer against the official documentation for that event or language. An explanation is a starting point for your own reading, not a source.

NotHoly publishes this Field Manual. None of the steps above need a NotHoly account or any AI assistant.

#Sources

• NIST, NICE Framework Resource Center: https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center
• NIST, SP 800-181 Revision 1, Workforce Framework for Cybersecurity (NICE Framework): https://csrc.nist.gov/pubs/sp/800/181/r1/final
• CISA, NICCS Cyber Career Pathways Tool: https://niccs.cisa.gov/workforce-development/cyber-career-pathways-tool