How can organisations decide how much coding skill to expect from different cyber security roles?

Why This Matters for Security Teams

Expectations for coding skill shape who can do the work, how fast they can investigate issues, and where security becomes dependent on engineering. If the bar is too low, practitioners miss misuse patterns in scripts, pipelines, and configuration. If it is too high, teams exclude strong analysts who can still manage risk, triage alerts, and improve controls with low-code or no-code tooling. The right answer depends on the role, but it should always be tied to the actual tasks the role performs, not a generic idea of what a “technical” security person should know.

This matters because many security functions now touch automation, APIs, and AI-assisted tooling even when they are not expected to build software from scratch. A SOC analyst may need to inspect a Python snippet in a phishing payload or interpret a PowerShell command, while a GRC lead may only need enough fluency to understand evidence from scripts and pipelines. Current guidance suggests organisations should define coding expectations as an operating requirement, then validate them against role outcomes and the tools in use. That approach aligns with operational resilience thinking in CISA cyber threat advisories, which consistently show that real incidents move through logs, scripts, and automation as much as through dashboards.

In practice, many security teams encounter coding gaps only after an analyst cannot explain an alert, a control test, or an exploit path in a form engineering can act on.

How It Works in Practice

A practical model is to split coding expectations into three bands: literacy, fluency, and authoring. Literacy means reading code, identifying risky patterns, and understanding what a script or query is doing. Fluency means modifying queries, automating recurring tasks, and validating outputs. Authoring means building and maintaining tooling, detections, and integrations. Not every role needs the same band, and the same role may need different levels depending on the environment.

For example, GRC and awareness roles usually need literacy so they can understand evidence and control design. SOC and threat hunting roles often need fluency with query languages, endpoint triage scripts, and detection logic. AppSec, DevSecOps, malware analysis, and red team roles usually need authoring skills in at least one general-purpose language plus shell, because they are closer to code, testing, and exploitation. In AI-heavy environments, the bar should also include the ability to inspect prompts, automation flows, and model-connected tooling, especially where agentic systems can execute actions.

• Define each role by the decisions it must make, not by job title alone.
• Map those decisions to the minimum coding actions required in production.
• Set separate expectations for reading code, writing scripts, and reviewing peer work.
• Validate with practical exercises using the team’s actual tooling and data.
• Reassess when automation, cloud services, or AI tools change the work.

For AI-enabled security work, the question is not whether every analyst can code a model, but whether they can evaluate Anthropic — first AI-orchestrated cyber espionage campaign report style risks, spot unsafe automation, and understand where model outputs may be acting as inputs to security decisions. Teams should also track threat patterns in the MITRE ATLAS adversarial AI threat matrix when roles touch AI security testing or defensive engineering. These controls tend to break down when a small platform team is expected to cover both deep engineering and broad operational security across legacy systems and fast-moving cloud services.

Common Variations and Edge Cases

Tighter coding expectations often increase hiring friction and training cost, requiring organisations to balance immediate role coverage against long-term technical depth.

There is no universal standard for this yet, and best practice is evolving as security work becomes more automated. A junior analyst in a highly scripted SOC may need more code fluency than a senior GRC lead in a manual control environment. Conversely, a senior security architect may need strong reading and review skills even if they rarely write production code. The right threshold depends on whether the role primarily consumes code, changes code, or governs systems that are driven by code.

Edge cases usually appear in hybrid roles. Security champions, platform security engineers, and AI governance leads often sit between policy and implementation, so they need enough coding skill to challenge design choices and verify controls without necessarily being full-time developers. In regulated environments, that expectation should be documented clearly, especially when the role supports evidence collection, secure-by-design reviews, or control testing. In AI and automation-heavy environments, coding skill should also include safe use of orchestration tools, because an apparently simple workflow can trigger real-world changes.

For organisations building role profiles, the most useful question is whether the person must understand, modify, or create the code that affects security outcomes. If the answer is only understand, literacy may be enough. If the answer is modify, fluency is usually required. If the answer is create, the role should be treated as an engineering-capable security function, not just an analyst role.

Related resources from NHI Mgmt Group

• How should security teams benchmark employee cyber risk across different roles?
• How do organisations decide where AI data security controls should sit?
• How should organisations decide whether to buy AI security tools through procurement channels?
• How should organisations decide where CASB fits in the security stack?