Understand cyber security roles
Compare security testing, incident response and intelligence work by tasks, outputs and evidence, with questions for your next career step.
Compare cyber security roles by the tasks you would perform and the decisions your work would support. A job title is a useful label, but it may conceal a wide mix of responsibilities. Ask what you will produce, who will use it and how your work will be reviewed.
NIST's NICE Framework describes work through tasks, knowledge and skills; its work roles do not correspond one-to-one with job titles. The UK Cyber Security Council also describes specialisms that can overlap within a job. The comparison below is our practical illustration of three areas closely connected to this site's conference archive.
Compare the work and its outputs
| Area | Typical question | Example work product | What good evidence shows |
|---|---|---|---|
| Security testing | Does a defined service meet its security expectations within the agreed scope? | Scoped assessment, reproducible finding and retest record | Permission, a clear method, reliable evidence and proportionate conclusions |
| Incident response | What might have happened, what is affected and what should we do next? | Triage note, event timeline, decision log and recovery checks | Facts separated from assumptions, careful handling and clear escalation |
| Threat intelligence | What threat information matters to a particular decision? | Requirement, source assessment and decision briefing | Traceable sources, local relevance and an explicit confidence judgement |
The Council describes testing in relation to requirements and vulnerabilities, response as preparation through follow-up, and intelligence as assessment and reporting of threat information. The sample outputs above are illustrative; an employer's responsibilities and procedures may differ.
Look at the less visible work
In testing, writing a finding so that an engineer can reproduce and fix it may take as much care as identifying it. A useful report also explains boundaries: what was excluded, what access was supplied and what the evidence does not establish. Read the report guide for an example.
In response, maintaining an accurate sequence of observations and decisions matters even when the cause remains uncertain. A responder may need to communicate with an operational manager who must keep a service available. The triage guide demonstrates that reasoning without pretending every suspicious event has a simple explanation.
In intelligence, narrowing a vague request can be more valuable than collecting another report. An analyst may spend time explaining why a claim does not apply locally or why the evidence is insufficient. Try the requirements guide to see whether that kind of work appeals to you.
A fictional career comparison
Fictional example. Sam maintains an internal application and is considering a security role. Sam has experience investigating failed deployments, explaining changes to colleagues and checking access requests, but has not conducted professional penetration tests.
| Existing experience | Possible connection | Small, authorised learning exercise |
|---|---|---|
| Explaining a reproducible application fault | Testing reports need clear evidence and remediation context | Document a deliberately introduced access-control error in a local training application |
| Reconstructing a failed deployment | Incident work involves observations, timelines and uncertainty | Create a timeline from a synthetic set of application and administrator events |
| Comparing supplier documentation | Intelligence requires source assessment and relevance | Compare an advisory with an invented asset inventory and explain applicability |
Sam can try each task and compare what felt engaging, difficult and worth practising. These exercises offer evidence for a conversation; they do not establish readiness to work unsupervised on a client's systems.
Questions to ask an employer or mentor
- Which tasks would I own in the first three months, and which would I observe?
- Who reviews technical conclusions and sensitive communications?
- What would a good first work product look like?
- What access, permission and escalation processes would I need to follow?
- Is there an on-call commitment, and what support accompanies it?
- How are learning time, feedback and progression handled?
- Which qualifications or professional recognition are actually required for this post, and why?
Avoid assuming that a certificate, job title or years of experience answers all of those questions. Examine the current role description and the organisation's expectations.
Build evidence for one task at a time
Choose a small activity that exposes your reasoning. Record what you intended to establish, what you did, what happened and what you would change. Someone reviewing your work should be able to see both your capability and your limits.
Use the portfolio guide to write that record. Link it to a task in an appropriate official framework if that helps explain the relevance, while making clear that your self-assessment is not a certification or endorsement by the framework's publisher.
Sources and further reading
- NIST: Getting Started with the NICE Framework — checked 2 November 2026
- UK Cyber Security Council: Security Testing — checked 2 November 2026
- UK Cyber Security Council: Incident Response — checked 2 November 2026
- UK Cyber Security Council: Cyber Threat Intelligence — checked 2 November 2026