A SOC analyst interview hands you an alert and watches how you think. A GRC analyst interview hands you a control and checks whether you can explain it to someone who does not care about security. Both are performance tests disguised as knowledge tests, and both are failed far more often by people who know the material than by people who do not.
That is the thing worth internalising before you prepare. You are not being asked whether you know what MITRE ATT&CK is. You are being asked to reason out loud, in order, under mild interruption, about something ambiguous. Flashcards do not build that. Being asked "and then what?" four times in a row does.
This guide covers what each interview actually contains, the scenarios that come up most, and how to practise the specific skill each one is testing.
Key takeaways
- SOC interviews are scenario walk-throughs. Expect "an alert fires, what do you do", and expect the interviewer to keep asking what happens next until you either escalate correctly or run out of road.
- GRC interviews are translation tests. Knowing that ISO 27001 Annex A has controls is table stakes. Explaining to a sceptical engineering manager why a control exists, without reading the clause aloud, is the job.
- Say your reasoning, not your conclusion. "I'd check the logs" is a non-answer. Which logs, what you expect to see, and what each outcome would make you do next is the answer.
- Prepare for the "you were wrong" follow-up. Both disciplines interview heavily on false positives, missed detections and audit findings. Candidates who cannot describe getting something wrong read as either inexperienced or unsafe.
- Practise out loud against interruption. The failure mode in both interviews is a candidate who knows the answer and delivers it as an unstructured four-minute monologue.
SOC analyst interviews
The scenario walk-through
This is the core of the interview and often most of it. Some version of:
- "An EDR alert fires for a suspicious PowerShell process on a finance workstation. Walk me through what you do."
- "A user reports a phishing email. Take me from there."
- "You see repeated failed logins from one IP across forty accounts, then one success. What now?"
They are not looking for a memorised playbook. They are checking whether you triage in a sensible order and know when you are out of your depth. A strong answer has a visible spine:
- Validate. Is this a true positive? What in the alert makes you think so, and what would make you think it is noise?
- Scope. What else did this host, user or IP touch? Is it one machine or forty?
- Contain, if it is yours to contain. Isolate the host, disable the account, block the indicator. Say explicitly what authority you have at your tier.
- Escalate. To whom, with what, at what point. Naming when you would hand off is a strength, not an admission.
- Document and close the loop. What goes in the ticket, and what would you want tuned so this alert is better next time.
That last step is the one that separates a candidate from a good candidate. Detection engineering feedback ("this rule fires forty times a week and thirty-nine are the backup service, I'd suppress on that parent process") is the answer that gets people hired into tier 2.
Tooling questions
Expect to be asked about a SIEM (Splunk, Microsoft Sentinel, Elastic), an EDR (CrowdStrike, Defender), and often a ticketing or SOAR layer. Be specific about which you have actually used and honest about which you have only read about. Security teams check, and being caught inflating a tool on your resume is worse in this field than in most, because the whole job is trustworthiness.
Where you have gaps, say what you know transfers. Query logic is query logic; someone who is fluent in SPL learns KQL quickly and can say why.
Fundamentals, asked quickly
TCP handshakes, DNS, what a proxy sees that a firewall does not, common ports, how Kerberos works well enough to explain pass-the-hash. These come fast and are usually a filter rather than the substance. Know them cold so they cost you no time.
GRC analyst interviews
The frameworks
You will be expected to know ISO 27001, SOC 2, NIST 800-53 and the NIST CSF, plus whichever of PCI DSS, HIPAA or FedRAMP the employer's industry demands. Knowing them means knowing what each is for and how they differ, not reciting control numbers.
The distinction interviewers probe most often: SOC 2 is an attestation about a service organisation's controls over a period, ISO 27001 is a certification of a management system. Candidates who blur those two mark themselves immediately.
The translation test
This is the real interview. Some version of:
- "An engineering lead says an access review is bureaucratic nonsense that slows his team down. What do you say?"
- "Explain to a non-technical executive why we need this control."
- "The auditor raised a finding. The business disagrees. How do you handle it?"
They are testing whether you can hold a position without either capitulating or reading policy at someone. The strong answer connects the control to a consequence the other person actually cares about: a customer contract that requires it, a deal that stalls in security review without it, the specific incident it would have caught.
Evidence and audit reality
Expect practical questions about gathering evidence, mapping one control set to another so you test once and satisfy three frameworks, third-party and vendor risk, and what you do when the evidence does not exist. "I would document the gap, rate the risk and put it in front of the owner with a remediation date" is a much better answer than pretending every control is met.
Risk assessment
Be ready to talk through how you actually rate a risk: likelihood and impact, why qualitative scales get gamed, and how you avoid a register where everything is amber. Concrete beats theoretical here.
How to practise either one
Build the spine, not the script. For SOC, drill the five-step triage order until it is automatic, then apply it to unfamiliar scenarios. For GRC, drill the translation move: control, why it exists, what it prevents, what it costs the other person, what you can flex. Memorised answers break the moment the scenario shifts; a spine survives.
Say it out loud and get interrupted. Both interviews escalate through follow-ups. The skill is holding structure while someone pokes at step three. You cannot rehearse that silently, and a question list cannot give it to you.
Prepare the failure stories. One missed detection or one audit finding you owned, with what you changed afterwards. Both fields interview hard on this and both are suspicious of candidates who have never been wrong. Use STAR; our worked examples cover the structure.
Fill gaps deliberately rather than broadly. If the posting names Sentinel and you have only used Splunk, spend the week on KQL specifically, not on a general security course. Our guide to learning a skill for a specific interview covers doing this under time pressure.
Read the posting like an auditor. Security job descriptions are unusually literal. If it lists ISO 27001 and vendor risk twice, those are your first two hours of preparation.
Where Round Zero fits
We build interview practice, so treat this as a stated interest.
Round Zero has prepared interviews for SOC analysts, GRC analysts and security architects, and you can paste any posting to get an interview built from it. It runs by voice or text, keeps asking follow-ups when an answer is thin, which is exactly the pressure a triage walk-through applies, and scores against a rubric that quotes your own words back with the specific answer that cost you points.
Security is one of the fields we cover best, partly because most interview tools are built around software engineering loops and generate something vaguely security-shaped for everyone else. Free is 3 complete scored interviews, no card, nothing blurred.
What we do not do is replace a technical deep-dive with a practitioner. If you can get a mock with someone who runs a SOC, take it. Software is for the volume; a person is for the judgment.
FAQ
What questions are asked in a SOC analyst interview?
Mostly scenario walk-throughs: an alert fires and you are asked what you do next, repeatedly, until you escalate or run out of road. Alongside those, tooling questions about your SIEM and EDR experience, networking and identity fundamentals asked quickly, and at least one question about a detection you got wrong. Tier 1 roles weight fundamentals and triage order; tier 2 and above weight scoping, tuning and detection engineering.
What questions are asked in a GRC analyst interview?
Framework questions covering ISO 27001, SOC 2, NIST 800-53 and the NIST CSF, plus PCI DSS, HIPAA or FedRAMP depending on the industry. Then practical questions on evidence gathering, control mapping, third-party risk and risk rating. The questions that actually decide it are the translation ones: explaining a control to a sceptical engineer or an executive, and handling a finding the business disputes.
How do I prepare for a cybersecurity interview with no experience?
Lead with the reasoning rather than the resume. Home lab work, a SIEM you have actually queried, CTF write-ups and a documented detection you built all count as evidence if you can walk through your thinking. Learn the triage spine and apply it to scenarios out loud. Entry-level interviewers expect thin experience; what they will not forgive is inflating a tool you have not touched.
Is a certification enough to pass a SOC interview?
No. Security+, CySA+ or equivalent gets you past the resume screen and signals baseline knowledge. The interview then tests whether you can reason through an ambiguous alert while someone asks "and then what?", which is a distinct skill from passing a multiple-choice exam. Candidates with certifications and no practice at reasoning aloud fail these interviews routinely.
Can AI mock interviews help with security interviews?
For the specific skill these interviews test, yes: reasoning under repeated follow-ups is hard to rehearse alone and is exactly where candidates falter. The caveat is coverage, since most tools are built for software engineering and will generate generic questions from a security job title. Test any tool by pasting a real posting and checking whether the scenarios resemble triage work you recognise.