Women in Security Engineering

Security engineering sits closer to building than to responding: writing automation, hardening infrastructure, and designing controls before an incident happens rather than after. It is a natural next step for many analysts, and one where visibility and scope have to be actively managed rather than assumed. This article covers both the technical path in and the practical, less-discussed skill of shaping your role once you are there.

8 min read · Women in Cybersecurity

What security engineering actually involves

Day to day work varies by organisation, but commonly includes hardening systems, building automation for repetitive security tasks, integrating security tooling into development pipelines, and designing controls that reduce the number of incidents a SOC ever has to see. It is a role that rewards comfort with scripting, cloud platforms, and reading other people's code as much as classic security knowledge.

A realistic path in

1Start from either a SOC or a general IT or software background, whichever is closer to where you are now
2Build scripting comfort, since automation is central to the role
3Contribute to one internal security tool or process improvement, even a small one, to build a track record
4Learn one cloud platform in depth, since a large amount of modern security engineering happens there
5Ask directly for engineering-adjacent tasks in your current role as a bridge into the specialism

Negotiating scope, not just salary

In technical teams, scope, the actual projects and decisions you get to own, matters as much as title or pay. It is easy to end up doing valuable but invisible maintenance work while others take on the projects that get noticed. Ask directly for ownership of a defined piece of work, and put that ask in writing where possible, such as in a one-on-one follow-up email, so it becomes part of the record.

I would like to take ownership of the vulnerability scanning automation project this quarter. Can we agree on that as one of my goals?

Making your work visible

Write short internal updates summarising what you shipped and its impact, even informally
Present your work in team meetings rather than letting a manager summarise it secondhand
Document decisions and trade-offs, not just final outcomes, so your reasoning is visible too
Ask a manager or mentor to review your update before an important review cycle

Visibility is a skill, not vanity

Quietly doing excellent work rarely gets you promoted on its own in a technical field. Describing your impact clearly and regularly is part of the job, not separate from it.

Growing further

From security engineering, common next steps include specialising in cloud security, moving into architecture, or taking on technical leadership of a security engineering team. Each of these builds directly on the automation and systems thinking developed in the role.

Frequently asked questions

Do I need a software engineering background to become a security engineer?

It helps but is not required. Many security engineers build scripting and automation skills on the job, starting from a SOC or IT background.

How is security engineering different from a SOC role?

SOC work is largely reactive, responding to alerts as they happen. Security engineering is largely proactive, building the systems and automation that reduce how many alerts occur in the first place.

How do I ask for more ownership without seeming pushy?

Frame it around a specific project and a business outcome, in a scheduled conversation like a one-on-one, rather than as an open-ended request. Specificity reads as initiative, not overreach.