Cyber Security Job Description Templates: SOC, IAM, Cloud and GRC Roles

Security job adverts often ask for ten years of experience, five certifications and every tool on the market, then attract the wrong candidates and screen out people who could do the work. These templates give ready-to-edit job descriptions for four roles that most security teams hire: SOC analyst, IAM engineer, cloud security engineer and GRC analyst. Each one separates what the person will do from what they must bring on day one, maps the role to the NICE Framework and SFIA so levels are comparable, and includes the identity responsibilities that generic templates leave out, such as service accounts and API keys. They are for hiring managers, security leaders and HR partners. For the wider hiring strategy, see the Cybersecurity Skills Gap and Hiring Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [Team] and [hybrid, 2 days on site], with your own values.
• Start with section 2, which is shared by every role, then copy the role section you need. Delete any responsibility the person will not actually do in the first year.
• Keep "Essential" to what you will test at interview. Everything else goes under "Desirable" or "We will train you in".
• Set the level using section 7 before you set pay, so the description and the band agree.
• Have HR check the final text against section 8 and local employment law before it is published.

1. Purpose

This document sets out [Organisation]'s standard job descriptions for security roles. It exists so that roles are described consistently, levels are comparable across teams, candidates are assessed against stated criteria and adverts do not exclude people through requirements the job does not need.

2. Common sections for every security role

2.1 About the team

[Team] protects [Organisation]'s people, systems and data. We work with [IT operations, engineering, legal and the business] and report to [CISO / Head of Security]. [One sentence on what the team is changing this year.]

2.2 Working arrangements

• Location and pattern: [Location], [hybrid / remote / on site], [hours].
• On call: [None / rota of one week in [n], with allowance].
• Screening: this role requires [pre-employment checks / national security vetting level], completed before start. See the Personnel Security and Background Screening Guide.

2.3 Security responsibilities that apply to every holder

• Use privileged access only through [the PAM platform] and only for approved tasks.
• Keep credentials, API keys and tokens out of code, tickets and chat, and report any exposure immediately.
• Report suspected incidents, including your own mistakes, through [reporting route].

2.4 Adjustments and equality statement

[Organisation] welcomes applications from everyone. If you need an adjustment at any stage of the process, contact [recruitment contact]. We assess candidates only against the essential criteria below.

3. SOC Analyst

Purpose of the role: monitor, triage and investigate security alerts, escalate confirmed incidents and improve detections so that attacks are found and contained quickly.

3.1 Responsibilities

• Triage alerts from [SIEM, EDR, email security, identity provider] within agreed service levels and decide whether activity is benign or malicious.
• Investigate suspicious sign-ins, mailbox rules and OAuth consents, including activity by service accounts and other non-human identities.
• Document and escalate incidents under the incident response plan, and contain them using approved actions such as host isolation and session revocation.
• Handle staff phishing reports and give reporters feedback.
• Tune noisy rules and propose new detections from investigations.
• Write shift handovers and contribute to trend reporting.

3.2 Essential

• Working knowledge of networking (TCP/IP, DNS, HTTP) and one operating system in depth.
• Ability to read logs and explain what happened, tested with a practical exercise.
• Clear written communication for incident notes.

3.3 Desirable and trainable

• Desirable: query language experience ([KQL / SPL / SQL]), scripting, knowledge of MITRE ATT&CK.
• We will train you in: [our SIEM and EDR], our playbooks and our escalation paths.

Career context: SOC Analyst Career Guide. Interview bank: SOC Analyst Interview Questions and Answers.

4. IAM Engineer

Purpose of the role: design, run and improve the systems that control who and what can access [Organisation]'s applications and data, for people and for non-human identities.

4.1 Responsibilities

• Operate and improve [identity provider] including single sign-on, MFA and conditional access policies.
• Integrate applications using SAML, OpenID Connect and SCIM provisioning.
• Automate joiner, mover and leaver processes from [HR system] so access changes follow employment changes.
• Own the inventory, ownership and rotation of service accounts, application credentials, API keys and workload identities.
• Support access reviews and fix the findings, including removing standing privileged access.
• Investigate identity incidents with the SOC.

4.2 Essential

• Hands-on administration of at least one enterprise identity provider or directory.
• Understanding of authentication and federation protocols, shown by explaining a sign-in flow end to end.
• Scripting or infrastructure-as-code for routine identity tasks.

4.3 Desirable and trainable

• Desirable: identity governance or PAM platform experience, cloud IAM policy languages, secrets management.
• We will train you in: [our platforms], our role model and our access review process.

Career context: IAM Engineer Career Guide. Interview bank: IAM Engineer Interview Questions.

5. Cloud Security Engineer

Purpose of the role: make [AWS / Azure / Google Cloud] environments secure by default through guardrails, identity design, monitoring and engineering support to delivery teams.

5.1 Responsibilities

• Design and maintain organisation-level guardrails such as policies, account or subscription structure and logging baselines.
• Review and improve cloud IAM: roles, workload identity federation, cross-account trust and removal of long-lived access keys.
• Run posture management, triage findings and drive fixes with owning teams.
• Build security checks into infrastructure-as-code pipelines.
• Support incident response in cloud environments, including evidence collection.

5.2 Essential

• Hands-on experience building or operating workloads in at least one major cloud provider.
• Ability to read an IAM policy and explain its effective permissions and risks.
• Infrastructure-as-code experience ([Terraform / CloudFormation / Bicep]).

5.3 Desirable and trainable

• Desirable: Kubernetes security, container image scanning, a second cloud provider.
• We will train you in: our landing zone, our tooling and our exception process.

Career context: Cloud Security Engineer Career Guide. Interview bank: Cloud Security Engineer Interview Questions.

6. GRC Analyst

Purpose of the role: keep [Organisation]'s security policies, risks and control evidence accurate and audit-ready, and turn requirements from [ISO/IEC 27001 / SOC 2 / sector regulation] into practical controls.

6.1 Responsibilities

• Maintain the policy set and control library, and map controls to [frameworks].
• Run risk assessments, keep the risk register current and track treatment actions.
• Collect and check control evidence, and coordinate internal and external audits.
• Assess suppliers and answer customer security questionnaires.
• Report compliance status and key risks to [risk committee].

6.2 Essential

• Working knowledge of at least one control framework, shown by mapping a control to evidence.
• Clear writing for policies and findings.
• Ability to explain a technical control to a non-technical owner.

6.3 Desirable and trainable

• Desirable: audit or assessment experience, GRC platform use, privacy regulation knowledge.
• We will train you in: our risk method, our evidence standards and our audit calendar.

Career context: GRC Analyst Career Guide. Interview bank: GRC Analyst Interview Questions.

7. Framework mapping and levels

The NICE Framework (NIST SP 800-181 Rev. 1) describes work roles, not job titles, and NIST lists creating job descriptions and assessing candidate skills among its uses. NICE Framework Components v2.0.0 (March 2025) reduced the work roles from 52 to 41; check the current components before publishing. SFIA defines skills at levels of responsibility.

Use SFIA levels of responsibility to set grade. SFIA defines both SCAD and IAMT from level 1 to level 6.

8. Wording and fairness rules

1. Every essential criterion must be tested at interview or in an exercise. If you will not test it, move it to desirable.
2. Do not use years of experience as a proxy for skill. UK government guidance warns that phrases such as "recent graduate" or "highly experienced" should be used only where they are genuine job requirements, because they can exclude younger or older people.
3. Do not require a degree where demonstrable skill will do; state "or equivalent experience".
4. List no more than [two] certifications, and only as desirable unless a contract or regulation requires them.
5. Do not ask about protected characteristics in the application; use a separate equality monitoring form that selectors do not see.
6. Name the tools you use, but treat them as trainable unless the role starts on day one without support.

9. Review and approval

[HR Business Partner] and [Head of Security] must approve each published description. Descriptions must be reviewed [annually] and when the role changes. The current version is held in [HR system], version [x.y], approved [date].

Implementation guidance

• Build the assessment with the description: for every essential line, write the exercise or question that tests it. The interview banks linked in each section help.
• Protect the hiring process itself: remote technical roles attract fake candidates and proxy interviewees. Verify identity at offer and again on the first day, and give new starters least-privilege access. See the Hiring Fraud and Candidate Identity Verification Guide.
• Connect to joiner processes: access for the role should come from a role definition, not a copy of a colleague's account. See the Joiner-Mover-Leaver Guide.
• Small teams: one person often covers two templates, such as IAM and cloud. Merge the responsibilities, keep essentials to what you will test, and be honest about breadth in the purpose line.
• Large teams: keep the four templates as a family, with one description per grade, and publish the levels table internally so staff can see the route to promotion.

Common failure patterns

• Wish-list essentials: every tool and certification listed as essential, so strong applicants self-select out.
• Title inflation: an "engineer" title on a monitoring role, which produces early attrition.
• No non-human identity ownership: nobody's description includes service accounts or API keys, so nobody owns them.
• Levels set by pay, not scope: the description says level 3 work while the band is level 5, or the reverse.
• Stale descriptions: a description written for an on-premises SIEM still used after a move to cloud.

Related NHI Mgmt Group resources: Cybersecurity Skills Gap and Hiring Guide · Cybersecurity Careers Guide · Hiring Fraud and Candidate Identity Verification Guide · Personnel Security and Background Screening Guide