A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Most organisations hiring their first security person get somebody who produces documents, and then wonder why the security posture has not changed.
This is not incompetence. It is a category error in the job description. "Security" covers governance and compliance, application security, cloud and infrastructure security, and detection and response. Those are four different jobs with four different day-to-days. The market is heaviest at the compliance end, because that is where the audit deadlines are, so that is who applies when the ad says "security engineer".
An audit report tells you that controls existed and operated over a period. It does not tell you that an attacker could not get in, and the two are routinely confused by people signing the cheque.
The work that actually reduces risk is engineering: removing standing access, segmenting networks, fixing the classes of bug your code keeps producing, and being able to answer "are we affected" within a day when the next widely exploited vulnerability lands.
The screening question underneath all of these: what did you actually make harder to exploit?
Governance, application, infrastructure or detection. We establish this first, because the four are routinely sold as one.
How they triage thousands of findings. We listen for exploitability and exposure rather than sorting by severity rating.
Least privilege, short-lived credentials, and joiner-mover-leaver actually working. Unglamorous, and where most real risk lives.
Whether they have tuned alerting down to a volume a human can act on, and what they deliberately chose not to alert on.
Whether they have worked a real incident, what the timeline looked like, and what changed afterwards.
A live conversation in English, every time. Security work fails when engineers experience it as an obstacle rather than a collaboration.
The pattern we see most is a security function that generates work for everybody else without reducing anything.
A scanner gets deployed. It produces several thousand findings against every service, sorted by severity score alone, and the output is forwarded to engineering teams as a spreadsheet. Nothing in it distinguishes a critical-rated library flaw in code path nobody can reach from a medium-rated issue in your authentication flow that is trivially reachable from the internet. Engineers work through it in severity order because that is the only order available, burn a sprint, and the genuinely exploitable issue is still open at the bottom of the list.
The same failure shows up in detection. A monitoring platform is bought and configured with default rules, so it produces hundreds of alerts a day. Nobody can triage that volume, so triage stops. The alerts continue to fire into a channel people have muted, which is worse than no alerting at all — you now have evidence that will be found after the incident showing the platform detected it and nobody looked.
Meanwhile the unglamorous things stay undone. Access that was granted for a project two years ago is still active. Long-lived credentials sit in configuration. There is no inventory of what you run, so when a widely exploited vulnerability is announced, the honest answer to "are we affected" is that it will take a week to find out.
Security Engineer (3–5 years). Runs the tooling and works findings to resolution. Comfortable with scanning, patching and access reviews. Needs direction on what to prioritise and why.
Senior Security Engineer (5–8 years). Threat models a system before it is built, fixes classes of issue rather than instances, tunes detection so alerts mean something, and can argue a requirement down without losing the point of it.
Security Lead (8+ years). Owns the programme, decides what risk is accepted and documents why, runs incident response for real, and translates between engineering and the board without misleading either.
Application security. Secure development practice, code review, and reducing the categories of bug your team keeps shipping. Closest to engineering, and the most frequently under-hired.
Cloud security posture. Identity, least privilege, network segmentation and key management. Overlaps heavily with cloud architects and DevOps engineers.
Detection and response. Making alerts trustworthy, writing runbooks, and rehearsing incidents before you have one.
Audit readiness. Legitimate work with a real deadline. Be explicit that this is the requirement, because it is a different hire from the three above.
Remediation after a penetration test. Bounded, urgent, and a good first engagement because success is measurable.
Week one. They establish what you actually run and who can reach it. Expect an inventory attempt, a look at identity and standing privilege, and questions about what happens when somebody leaves. Expect them to ask what your last incident was and how you found out, because the answer to the second half is usually more revealing.
Weeks two to four. Two or three concrete reductions in exposure, not a roadmap. Dormant accounts removed. A long-lived credential replaced with something short-lived. One alert that fires rarely and means something when it does. Each of these should be describable in a sentence and verifiable by somebody else.
The warning sign is a policy document in week two. Policies matter, and they are the output of decisions somebody has already made. A security hire whose first deliverable is a document has usually not yet looked at your infrastructure, and is producing the artefact that is easiest to produce without having done so.
Hiring for "security" without naming which of the four jobs. Governance, application security, infrastructure security and detection attract different people with different skills. An unspecified brief reliably returns the compliance end of the market, because that is where the volume is.
Treating an audit as the goal. Certification is a business requirement and worth meeting. It is not a security outcome, and organisations that pass an audit and then stop are the ones surprised later. Fund the compliance work and the engineering work as separate things, so one cannot quietly consume the other.
Prioritising by severity score alone. A rating describes theoretical impact, not whether an issue is reachable in your environment or being exploited in the wild. Ask a candidate how they would triage two thousand findings. Strong answers reach for exploitability and exposure; weak ones sort the spreadsheet.
Buying tooling before hiring anybody to run it. A platform nobody has tuned produces noise, and noise trains people to ignore alerts. Tools are useful once somebody owns the output. Bought first, they mostly generate an expensive impression of coverage.
Rates depend on discipline, seniority, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.