Cybersecurity includes many kinds of work. One person investigates suspicious activity, while another tests defenses, builds secure systems, reviews controls, or coordinates teams during an incident.
This eight-question quiz returns your two strongest matches. Pick the answer that sounds most satisfying, and do not overthink it. No email address or account is required.
Practical self-assessment
Find your cybersecurity career paths
Pick the answer that sounds most satisfying. Do not overthink it. The quiz returns your two strongest matches.
Progress and results are saved in this browser tab.
Your results
Your strongest technology career matches
Your answers suggest that you may enjoy...
These results are a starting point for exploration. Skills and interests can overlap across several paths.
Continue below to compare all six paths in more detail. Each section includes common roles, the kinds of problems you may handle, and a small project that can help you explore the work.
Defensive Security and Security Operations
Defensive security teams watch for suspicious activity, decide what deserves attention, and help contain threats before they cause more damage.
The work depends on visibility. Teams collect events from user accounts, endpoints, networks, applications, cloud services, and security tools. Analysts compare that activity with expected behavior, investigate unusual patterns, and improve detections when threats are missed or alerts are too noisy.
Common roles include:
- Security operations center (SOC) analyst
- Cybersecurity analyst
- Detection analyst
- Vulnerability management analyst
- Endpoint security analyst
- Defensive security analyst
A normal day may involve reviewing an unusual sign-in, investigating malware detected on a laptop, prioritizing exposed vulnerabilities, or deciding whether several low-level events belong to the same incident.
This direction may fit you if you enjoy recognizing patterns, making decisions with incomplete information, and separating routine activity from something that requires action. Technical curiosity matters, but so does judgment. Not every alert is an attack, and not every vulnerability presents the same risk.
Try a small defensive-security project
Use approved sample logs or events from a local lab. Identify:
- What appears normal
- What looks unusual
- Which activity needs more context
- What you would investigate next
- When the activity should be escalated
- Which control could reduce the risk
The goal is not to identify every possible threat. Practice explaining why one event matters more than another.
Incident Response, Forensics, and Threat Hunting
Incident responders investigate events that may already have affected systems, accounts, data, or business operations.
They work to establish what happened, determine what remains at risk, contain the incident, support recovery, and preserve enough evidence to reach defensible conclusions. Digital forensics focuses more heavily on collecting and examining evidence. Threat hunting searches available data for suspicious behavior that existing alerts may not have identified.
Common roles include:
- Incident response analyst
- Digital forensics analyst
- Threat hunter
- Security investigator
- Computer forensic examiner
- Malware analyst
The work often begins without a complete story. An organization may know that an account was misused or a system behaved strangely, but not how access was gained, what the intruder touched, or whether the activity continues.
This direction may fit you if you enjoy following evidence, building timelines, revising theories as new facts appear, and distinguishing what is known from what is only suspected.
Incident work also requires clear communication. Leaders may want an immediate answer while the evidence still supports several possibilities. A careful investigator explains what can be concluded, what remains uncertain, and what must happen next.
Try a small investigation project
Create a fictional incident timeline from ten or twelve sample events. For each event, record:
- The time
- The system or account involved
- What happened
- Why the event matters
- What remains uncertain
- What you would investigate next
Then write a short summary that separates confirmed facts from reasonable theories.
Offensive Security and Security Testing
Offensive security professionals examine systems from an attacker’s perspective. They look for weaknesses, test whether those weaknesses can be used, and explain how the organization can reduce the risk.
The purpose is not simply to break into technology. Useful testing stays within an authorized scope, avoids unnecessary damage, demonstrates realistic impact, and gives the system owner enough information to correct the problem.
Common roles include:
- Penetration tester
- Red-team operator
- Application security tester
- Security consultant
- Vulnerability researcher
- Offensive security engineer
Testing may focus on networks, web applications, application programming interfaces, cloud environments, identity systems, wireless networks, physical controls, or human behavior. Some engagements test a narrow target. Others examine how several small weaknesses could be combined.
This direction may fit you if you enjoy technical puzzles, experimentation, and challenging assumptions. Strong testers also communicate well. A clever demonstration is not useful if the report does not explain the evidence, impact, and practical correction.
Try a small security-testing project
Use an intentionally vulnerable application in an isolated, authorized lab. Choose one weakness and write a short finding that includes:
- The affected component
- The conditions required
- The reproduction steps
- The possible impact
- Supporting evidence
- A practical correction
Do not test systems you do not own or have permission to assess.
Security Engineering and Architecture
Security engineers build, maintain, and improve technical controls. Their work may involve identity, networks, endpoints, cloud services, applications, logging, encryption, secrets, automation, and recovery.
Some engineers specialize deeply in one system. Others connect several technologies so that controls work together. A security engineer might automate account reviews, improve endpoint protections, build a logging pipeline, secure a cloud environment, or help developers add safer defaults.
Security architecture takes a broader view. Architects examine how users, systems, data, trust boundaries, and controls fit together. Architecture is often a later-career responsibility because good designs depend on both technical depth and experience with organizational constraints.
Common roles include:
- Security engineer
- Cloud security engineer
- Identity and access management engineer
- Application security engineer
- DevSecOps engineer
- Detection engineer
- Security architect
This direction may fit you if your response to a recurring problem is, “How can we redesign this so it stops happening?” You may prefer building a lasting control over handling the same alert or exception repeatedly.
Try a small engineering project
Diagram a small application or home lab. Include:
- Users and administrative accounts
- Data
- Servers or cloud services
- Network connections
- Logs
- Backups
- External access
- Trust boundaries
Decide where preventive, detective, and recovery controls belong. Then choose one control and describe how you would verify that it works.
Governance, Risk, Compliance, and Assurance
Governance, risk, and compliance (GRC) professionals help organizations define security expectations, understand exposure, and make deliberate risk decisions. Assurance professionals examine whether required controls exist and work as intended.
Some roles focus on policies, frameworks, contracts, and regulatory obligations. Others are highly technical and involve configuration reviews, control testing, evidence collection, and detailed assessments.
Common roles include:
- GRC analyst
- Cybersecurity auditor
- Security controls assessor
- Risk analyst
- Compliance analyst
- Configuration compliance analyst
- Technical assurance analyst
The work may include interviewing system owners, reviewing policies, examining configurations, collecting evidence, documenting findings, tracking corrective actions, and deciding whether an exception is justified.
In government and defense environments, technical reviewers may analyze Security Technical Implementation Guides (STIGs). They determine whether each requirement is satisfied, not applicable, or covered by an approved exception. A checked box is not enough. The evidence must support the conclusion.
This direction may fit you if you enjoy structured investigation, standards, evidence, and careful documentation. Good reviewers do more than identify gaps. They explain why a finding matters, what would correct it, and what evidence would demonstrate closure.
Try a small assurance project
Create a short security baseline for one computer or virtual machine. Review:
- User and administrative accounts
- Authentication settings
- Software updates
- Firewall settings
- Installed software
- Logging
- Backups
- Screen locking
For each requirement, record the evidence and conclude whether it is met, not met, not applicable, or needs more information.
Security Leadership and Coordination
Security leaders and coordinators help people make decisions, organize work, and maintain direction across complicated technical and business problems.
The path includes several kinds of responsibility. A security project manager may focus on schedules, owners, dependencies, and delivery. A security manager may focus on people, operations, priorities, and resources. A program leader may coordinate several teams or long-running initiatives.
Incident coordination introduces another form of leadership. During a serious event, someone must establish priorities, bring in the right specialists, track decisions, communicate status, and prevent confusion from slowing the response.
Common roles include:
- Security project manager
- Security program manager
- Security operations manager
- Incident commander
- Governance manager
- Security team lead
- Chief information security officer (CISO)
This direction may fit you if you enjoy creating order from incomplete information, helping specialists work together, and translating between technical and business concerns.
Leadership does not require being the deepest expert in every room. It does require enough understanding to ask useful questions, recognize weak assumptions, and avoid promising outcomes the organization has not funded or staffed.
Try a small coordination project
Create a response plan for a fictional security incident. Include:
- The first decisions
- Required specialists
- Business owners
- Communication responsibilities
- Evidence that must be preserved
- Recovery priorities
- Risks leadership may need to accept
- A method for tracking actions and status
Then write a brief update for a nontechnical leader.
Where Purple-Team Work Fits
Purple-team work connects offensive and defensive security.
An offensive team may reproduce a realistic attack technique. The defensive team observes whether existing tools and processes detect it. Both sides compare what happened, identify gaps, improve visibility, and test the defenses again.
The work can include:
- Selecting realistic attack behaviors
- Running controlled tests
- Reviewing logs and alerts
- Identifying detection gaps
- Improving rules and telemetry
- Retesting the improved defenses
- Sharing what each side learned
Purple-team work is often a collaborative activity rather than a beginner job title. Someone may enter through offensive testing, defensive operations, detection engineering, incident response, or security engineering and later participate in purple-team exercises.
If your results include both Offensive Security and Defensive Security, this overlap may be especially interesting.
How Your Two Results May Work Together
Cybersecurity roles often form at the intersection of two interests.
Defensive Security and Incident Response overlap in alert investigation, containment, log analysis, and understanding attacker behavior.
Defensive Security and Security Engineering meet in detection engineering, endpoint protection, logging, identity controls, and security automation.
Offensive Security and Security Engineering overlap in application security, secure design reviews, threat modeling, and correcting weaknesses before release.
Offensive Security and Defensive Security can lead toward purple-team exercises, adversary simulation, and detection validation.
Incident Response and Security Engineering meet when teams improve isolation, evidence collection, recovery, and resilience after an incident.
Governance and Security Engineering overlap in technical assessments, configuration reviews, control design, cloud assurance, and architecture review.
Governance and Leadership often meet in security programs, risk decisions, audit coordination, policy ownership, and remediation planning.
Leadership paired with another result may point toward managing projects, incidents, teams, or programs within that specialty.
Job titles vary widely between employers. Read the responsibilities and repeated tasks rather than relying on the title alone.
Explore the Work Before Choosing a Path
Choose one or two small projects from the sections above and spend some time with each. Notice which tasks still hold your attention after the novelty wears off.
You may discover that you enjoy analyzing logs but dislike urgent incident response, or that reviewing evidence appeals to you more than testing systems directly. You may enjoy offensive testing but prefer building secure systems as your daily work.
Read several job descriptions related to your two results. Ignore the experience requirements during the first review and focus on the responsibilities that appear repeatedly. Consider whether you would enjoy performing those tasks several times each week.
A first security role provides a starting point, not a permanent boundary. Analysts move into engineering, testers move into application security, auditors specialize in technical assessments, and experienced specialists move into leadership.