Most Cloud Security roles that sit open for six months aren't open because the talent isn't out there. They're open because the brief is hunting in the wrong pool. The role description filters for people who don't really exist in volume, and quietly filters out the people who would actually be productive in week three.
What "Wrong Pool" actually means
Wrong Pool is when the search is structurally aimed at a group of candidates who, taken together, can't fill the seat at the volume the market requires. It isn't a sourcing problem. It isn't a salary problem. It's a definition problem. The role description has already decided what shape of candidate counts, and that shape is rare or nonexistent.
The cleanest example is the Cloud Security Engineer brief that asks for five years of cloud-native security experience plus a CISSP plus deep IaC plus working knowledge of two CSPs plus detection engineering plus AppSec adjacency. Each line on its own is reasonable. Stacked together, the candidate the brief describes is a principal engineer five years into their career, which is a contradiction.
How to recognise it on a live brief
- The role has been open longer than ninety days and you've seen fewer than ten serious CVs, despite the salary being on-market.
- The hiring manager rejects in round one for "lack of depth in X", where X changes each time. They aren't being fussy. They've internalised a candidate who doesn't exist and are checking each applicant against it.
- When you read the JD aloud to a senior practitioner in the domain, they laugh, then say something like "I'd struggle to write that CV and I do the job".
- The strongest applicants you've found are sitting in roles whose titles don't match the search string, and the hiring manager dismisses them on title alone.
Why it happens
Wrong Pool briefs usually aren't written by hiring managers in one sitting. They're assembled. Someone copies the last open req for a similar role. Someone adds the cert their last hire happened to have. Someone adds a tool they bought a license for last quarter. By the time the JD reaches a recruiter, it describes a composite candidate nobody on the team would survive an interview against.
The second cause is more uncomfortable. Hiring managers anchor on the last great hire they made. If the last good Cloud Security Engineer came from a detection engineering background and had spent two years on AWS, those two facts become the silent acceptance criteria for the next hire. Everyone else is measured against an unrepeatable coincidence.
What happens if you ignore it
The role doesn't close. Not because the market is empty, but because the funnel has been pointed at a part of the market that's never going to deliver enough candidates to satisfy the bar. You will burn three or four rounds of sourcing, lose internal trust with the hiring manager, and end up either lowering the salary to justify reopening the brief or quietly cancelling the req.
The hidden cost is worse. The candidates the team actually needed were in scope the whole time and got rejected at the screen. Six months later you'll see one of them get hired at a competitor and ramp in eight weeks. That's the Wrong Pool tax.
What changes the outcome
Three things, in order of impact.
- Separate the must-have from the will-grow. Most Cloud Security briefs have three or four lines that genuinely have to be true on day one. Everything else is something a competent engineer picks up in the first quarter. Draw that line explicitly with the hiring manager before you reopen the search.
- Name the real feeder roles and search by those titles. For Cloud Security, the productive feeder pool is usually platform engineers who have owned production AWS or GCP and have done at least one security-adjacent project (an IAM cleanup, an SSO rollout, a detection-as-code experiment). They will almost never have "security" in their job title.
- Run a calibration round. Put two CVs in front of the hiring manager: the candidate they think they want, and a strong feeder. If they can't articulate, in one sentence, why the second one wouldn't be productive in ninety days, the brief is the problem, not the pool.
What good looks like
A Wrong Pool fix usually doesn't feel dramatic. The JD loses two bullet points. The cert requirement moves from "required" to "or equivalent demonstrable experience". The search opens up to platform engineering titles. Within three weeks you're seeing twice the CV volume, the hiring manager is engaged because the candidates are actually credible, and the offer goes out inside the next month. That's the entire shape of the fix. Quiet, structural, mostly about deletion.
Where this fits
Wrong Pool is the most common failure mode we see across Cloud Security and IAM hiring. It also routinely sits underneath the other six failure modes. Invisible Feeders is Wrong Pool by another name when the candidates exist but the search string can't find them. Tool Fetishism is Wrong Pool when the filter is a brand instead of a capability. The series treats them separately because the fix is different in each case, but the underlying pattern is the same: the brief decided who counted before the market got a vote.
If you have a role that's been open longer than it should be, the Hiring Reality Report gives you the specific failure mode, the feeder pool you should be searching, and the edits to the brief that would change the call. £49, turned around in three working days.