How to screen 200 cyber applicants without reading 200 CVs
Two hundred applications, one vacancy, and no reliable way to rank them. The practical method: invert the funnel, test first, and read CVs last.
12 min read 
A single SOC analyst vacancy will pull 200 applications. For a remote-friendly role at a recognisable company, more. You have a shortlist to produce, your senior analysts have an alert queue, and almost nothing in front of you is evidence.
The instinct is to get faster at reading CVs. Better filters, tighter keyword scans, an ATS rule that drops anyone without the right certification. That instinct is the problem.
The short version: stop screening CVs first. Send every applicant the same short practical task, rank them on what they actually did, then read the CVs of the fifteen who scored highest. You are not trying to read 200 CVs faster. You are trying to make 185 of them irrelevant.
Why 200 CVs is not a volume problem
Volume is the symptom. The problem is that a CV is a claim, and you have no way to rank claims except by how well they are written.
Think about what you are actually doing when you sift. You are reading a document the candidate wrote about themselves, checking it for words you were hoping to see, and inferring capability from their presence. “SIEM experience.” “Familiar with KQL.” “Led incident response.” Every one of those is a sentence, not a demonstration. The strongest candidate and the weakest candidate can write the identical sentence, and frequently do.
This was always weak. Two things have made it worse.
The first is that CV writing is now free. Any applicant can paste a job advert and their own history into an LLM and get back a document tuned to that advert, with your keywords in it, in the right order, well written. The correlation between “reads well against this spec” and “can do this job” has never been high. It is now close to noise, and it is noise you are actively selecting on.
The second is that cyber attracts people for whom the salary is the whole thesis. They collect certifications, they present well, and they interview competently, because interviewing is a verbal skill and so is their preparation. We wrote about that pattern in paper tigers. CV screening does not catch them. It is the stage they are optimised for.
So the honest position is this: the CV sift feels like it is reducing risk, and it is mostly reducing your reading time. It is the least reliable step in the process and it is the one you spend the most hours on.
Invert the funnel: test first, read CVs last
The conventional funnel runs cheapest-signal-first: sift CVs, phone screen, technical interview, onsite. The logic is that each stage is more expensive than the last, so you filter hard at the top where filtering is cheap.
That logic only holds if the cheap filter is accurate. If your first filter is close to random, filtering hard at the top does not save you money. It throws away good candidates before anyone qualified has looked at them, and passes weak ones through to the stage where your senior engineers pay for the mistake in hours.
Invert it. Run the reliable filter first, even though it costs a little more, because everything downstream gets cheaper and better.
1. Do not sift. Invite everyone. All 200. This feels wrong and it is the most important step. Every applicant you drop at CV stage is a decision made on the weakest evidence you will ever hold. Sending an assessment costs you nothing per candidate beyond the licence you already have.
2. One short task, identical for everyone. Same environment, same questions, same time limit, same scoring. Identical conditions are what make the ranking mean something. The moment you tailor the task per candidate, you have reintroduced the variance you were trying to remove.
3. Rank on what they did. Not on what they claimed, not on how they described their approach. On the artefacts: did they find the account, did they write the query, did they read the log correctly.
4. Now read the CVs. The top fifteen, not the top two hundred. And read them differently, because you are no longer using them to guess at capability. You already know who can do the work. You are reading for context: why they moved, what they owned, whether the trajectory makes sense, what to ask about.
The order change is the whole method. Same steps, different sequence, and the expensive human judgement gets spent on a pool that has already been filtered by something more reliable than prose.
What the task should actually look like
This is where it usually falls apart. Teams accept the argument, then send out a multiple-choice quiz on port numbers and encryption standards, and conclude that testing does not work.
The test is: could a candidate answer this without doing the work? If the answer lives in their memory, or in a browser tab, or in an LLM, you have built a recall exercise. Recall is not the job. Nobody investigates an incident from memory.
The full method - what to test per role, how to calibrate difficulty, what to score and what to ignore - is in how to assess cybersecurity candidates. The short version follows.
Here is the difference in practice.
Instead of “do you have experience with KQL”, give them a workspace, a schema, and something to find.
Note what is not there. No multiple choice. No prompt telling them which table to look in. They have to understand what a password spray looks like in sign-in telemetry (one source address, many accounts, mostly failures) and then express that as a query. Someone who has genuinely hunted in a SIEM starts typing. Someone who listed KQL because the job advert asked for it stalls at the schema tree.
Instead of “explain what Kerberoasting is”, give them the logs and a decoy problem.
That question is the one I would point at if I had to defend this whole approach with a single example. “What is Kerberoasting” is a definition anyone can recite. This asks something harder and much closer to the job: multiple accounts in this environment legitimately request RC4-encrypted service tickets, because legacy systems do that, and one of them is an attacker. Tell me which, and by implication, tell me why the others are not.
That is a discrimination task. It is exactly what a Tier 2 analyst does on a shift, and it is precisely what a candidate cannot bluff, because the answer only exists inside the data in front of them. MITRE ATT&CK documents the technique and the encryption-type indicator; knowing the documentation does not tell you which account in this log set is the one.
This one is multiple choice, and it is worth being straight about that rather than pretending every question is free-text. Format matters less than whether the answer is discoverable without doing the work. Here the candidate is looking at a live terminal with real output in it, and the question is which command surfaces PowerShell script execution from the event log. The options are all plausible PowerShell, and three of them are wrong for reasons you only know if you have actually gone looking for script-block logging rather than read about it.
The wider point is the artefact underneath. That terminal contains an entire attack chain: an interactive logon, SeDebugPrivilege assigned, powershell.exe -ep bypass -WindowStyle Hidden, net user svc_update ... /add, the new account added to Administrators, a scheduled task named WindowsUpdate for persistence, then file access on HR_Employee_Data.xlsx and a backup.zip sitting in a public downloads folder. A good candidate reads that and narrates the intrusion. A weak one answers the question and misses the story. You learn something either way, and you learn it in minutes rather than in an interview slot.
How long should the assessment be?
Long enough to produce signal, short enough that people finish it.
There is a real trade-off here and anyone who tells you otherwise is selling something. Longer assessments discriminate better, because depth is where weak candidates come apart. Longer assessments also lose you strong candidates, who have other offers and less patience, and the ones you lose are disproportionately the ones you wanted.
For a first screen across a large pool, keep it tight. You are not trying to fully evaluate anyone at this stage. You are trying to establish who is worth an hour of a senior engineer’s time, which is a much lower bar than “should we hire this person”. Save the deep work for a second-stage exercise with the shortlist, where you can reasonably ask for more time because the candidate now knows they are a serious contender.
The thing to avoid is asking 200 people for three hours. You will not get 200 completions, you will get a self-selected sample of the least busy, and that is not the population you are hiring from.
What about candidates using AI?
They will. Some of them, anyway, and you should design on that assumption rather than hope.
You cannot fully prevent it, and any vendor claiming otherwise is overselling. What you can do is make it matter less. An LLM is very good at recalling what Kerberoasting is and quite poor at telling you which of six accounts in a specific log set is doing it, because that answer is not in its training data. It is in the artefact in front of the candidate. Tasks built on investigation rather than recall degrade gracefully under AI assistance, which is a design property, not a policy one.
The second layer is instrumentation: tracking tab switches, paste behaviour, whether the window left fullscreen, whether a second screen appeared. Those signals do not prove cheating and should never be treated as a verdict. What they are good for is context. A candidate who scored well with a clean session and a candidate who scored well while pasting from elsewhere are not the same result, and you want to know which one you are looking at before you book the interview.
Treat integrity signals as a reason to probe in interview, not as an automatic rejection. The failure mode of anti-cheat is false accusation, and that cost is real.
Reading the results without creating a second job
If the output is 200 scores, you have swapped one pile for another.
What you want is a ranked cohort with the reasoning attached: who scored what, on which skills, with the underlying answers available when you want to check them.
Then band it. The top group goes to interview. The bottom group is a clear no. The middle is where the actual judgement lives, and it is the group most teams handle worst.
Look at the shape of the distribution above, because it is typical. The top two are clear of the field. Then there is a cluster in the middle. Then five candidates land within eleven points of each other, all graded the same, all effectively tied. That bottom cluster is the trap: ranked output tempts you to treat position seven as meaningfully better than position ten, and at that spacing it is not. Read the band, not the row number.
The candidates worth a second look are the spiky ones. Someone excellent on log analysis and poor on cloud might be exactly right for a SOC role and wrong for a security engineering one. A flat, uniformly average candidate is usually just average. A single total will rank those two identically, which is why the per-skill breakdown matters more than the headline number, and why the profile behind the row matters more than the leaderboard. If you want to see the full output, we publish a sample report.
And this is where the CVs come back. You now have fifteen people you know can do the work, and their CVs stop being a filter and become interview preparation.
Where CV review still earns its place
None of this makes the CV worthless. It makes it the wrong instrument for the job it is usually given.
A CV is genuinely good evidence of things that are hard to test in forty minutes: how long someone stayed, what scale they operated at, whether they have worked an incident at 3am with a regulator waiting, whether the trajectory is upward. Those matter, and no practical assessment surfaces them.
Read it for that. Read it second, after you know what the person can actually do, when you can use it to decide what to ask rather than whether to ask anything at all.
The order is the argument. Test first, read second, interview the people who earned it.
The honest summary
Screening 200 cyber applicants is not a reading problem and it will not be solved by reading faster. It is a sequencing problem. Almost every team runs its least reliable filter first, at the widest point of the funnel, and then spends senior engineering hours correcting for it downstream.
Put the demonstration first and the paperwork second, and the pile stops being 200 CVs. It becomes fifteen people you have already watched do the work, and 185 you do not need to think about.
Ready to do this on your next hire?
Or let us do it for you.
You can run this process yourself. Or send CyberHire the job spec and the applicant pool, and get back a shortlist ranked on demonstrated ability.