Questions to Ask in a Cyber Security Interview
For candidates interviewing for a security job, whether SOC analyst, security engineer, GRC or penetration tester, who want to know what the security program is really like before they join it. The questions follow the order the conversation usually takes: the program and where it reports, the daily work and tooling, on-call and incidents, how much authority and budget security has, training and growth, and a few to close on. Each has a note on what a good or a worrying answer sounds like and what to do with it.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Program
How big is the security team, and how is the work divided among them?
Why ask it
A headcount means little until you set it against the size of the company and everything the team is supposed to cover. Listen for whether detection, engineering, compliance and application security are separate people or one person doing all four. A small team can still be a good one, and the thing to find out is what it leaves undone.
Is there a CISO or head of security, and who do they report to?
Why ask it
The reporting line shows whose priorities win a tie. A security lead who sits under the head of IT or engineering is often reviewing the work of their own boss, while a line to the chief executive, legal or risk tends to leave more room to disagree. If nobody holds the title, find out who signs off on security decisions today.
What are the biggest security risks the company is worried about right now?
Why ask it
A good answer belongs to this business: a particular kind of data, an old system nobody dares touch, heavy dependence on one supplier. Interviewers may hold back detail from a candidate, which is fair. 'The usual, phishing and ransomware' with nothing behind it suggests nobody has ranked the risks, and whatever they do name is probably where your first year goes.
Is this a new seat on the team or a replacement, and what prompted the hire?
Why ask it
New headcount that followed an audit finding or a breach comes with attention and a deadline. If you would be replacing someone, how long they lasted and where they went next says a good deal about the seat. Several departures from the same job in a short time is the answer to be wary of.
What would you want me to have taken over by the end of my first three months?
Why ask it
The answers to hope for are concrete: a detection you own, a control you run, an audit area with your name on it. 'Learning the environment' on its own means no plan has been made for you. Find out too who would walk you through the network and the tooling in week one.
How mature would you say the security program is, and is it measured against a framework?
Why ask it
An honest 'we are early, and here is what is missing' is a better sign than 'we are in great shape' with nothing to show for it. A recent outside assessment, or a named framework the team scores itself against, means the answer rests on more than a feeling. Decide beforehand whether you want to build a program or work inside a finished one.
What is on the security roadmap for the next year, and what did not make the cut?
Why ask it
Three or four named projects show where the money and your time would go. What was cut is the more revealing half, because it is the risk the company has decided to live with for now. No roadmap at all usually means the year is set by whatever breaks and whatever the auditor asks for.
Which regulations, standards or customer requirements does the team have to meet?
Why ask it
The answer turns on the industry and on where the company and its customers are, so let them list it. Then listen for whether the audit drives the program or falls out of work the team would do anyway. A calendar ruled by audit dates leaves little time for anything else in the weeks before each one.
Which parts of security are handled in house, and which go to an outside provider?
Why ask it
Outsourced monitoring, outsourced testing and a part-time security chief can all work well. What matters for you is which side of the line your job sits on: doing the work, or managing a vendor who does it. If monitoring is outsourced, ask who answers when the provider escalates overnight.
Who owns security in the cloud accounts and in the product itself: this team or engineering?
Why ask it
Split ownership is normal, and fuzzy ownership is where things get missed. A clear answer names who can change a setting, who reviews it and who gets called when it is wrong. 'We all own it' tends to mean nobody does, and the story of the last misconfiguration and who fixed it will show you.
Daily work
How would a typical week in this job split between alerts, project work and meetings?
Why ask it
Postings for security jobs often describe building and hunting when the week is mostly triage and tickets. Ask for last week, not an ideal one. If the split is far from what you want, say which part you hoped to do more of and see whether there is any give.
Which tools would I be in every day, and who keeps them running?
Why ask it
Get the names: the log platform, the endpoint agent, the ticket system, the scanner. Then ask who maintains them, because on a small team the analyst is often the administrator too. That is good experience if you want it and a second job if you do not.
Roughly how many alerts reach an analyst in a shift, and how many turn out to be nothing?
Why ask it
Nobody needs to quote an exact figure. Someone who knows roughly how noisy the queue is has been tuning it, and someone who has no idea has not. A queue that is never empty by the end of a shift usually means alerts are being closed unread or left to age.
Who writes and tunes the detection rules: the analysts or a separate group?
Why ask it
Where analysts can fix a noisy rule themselves, the job gets better over time. Where every change goes into another team's backlog, the same false alarm can greet you each morning for months. How long the last tuning request took is the number to get.
What log sources or parts of the environment can the team not see into today?
Why ask it
Blind spots are ordinary: a subsidiary, a legacy network, cloud accounts opened without anyone telling security. Knowing where they are is the reassuring part. A claim of full visibility is hard to believe at a company of any size unless they can say how they checked.
How does the team keep up with new threats and vulnerabilities, and who decides which ones matter here?
Why ask it
Feeds and newsletters are easy to subscribe to. The harder part is someone deciding that this week's headline does or does not apply to this environment, and saying so in writing. Where that job belongs to nobody, it tends to arrive as a news story forwarded by an executive who wants to know if the company is affected.
After a scan produces a list of vulnerabilities, who fixes them and who chases?
Why ask it
Security usually finds the problem and another team has to patch it, which makes this a question about leverage. Agreed deadlines by severity, and a consequence when one is missed, are the signs that security has some. If the team sends reminders and hopes, the backlog will be long and some of it will be yours to nag about.
What is still done by hand here that ought to be automated?
Why ask it
Here is the dull part of the job, named for you: copying indicators between tools, resetting passwords, gathering screenshots. It is also a list of projects if you like scripting. The catch is whether time is set aside to automate or it has to be squeezed between tickets.
At what point does security get involved in a new system or feature: design, code review or just before launch?
Why ask it
Early involvement means your advice can still change something. A review the week before release leaves two choices, block the launch or sign off on a risk, and neither wins friends. Ask for the last project where security was in the room from the start.
Who sets the scope of a penetration test here, and is anything off limits?
Why ask it
Worth asking only if the job is penetration testing or red team work. A scope that leaves out the systems that matter makes for tidy reports and little else, so listen for what is excluded and who decided. The follow-up is whether fixes get retested or the same report is simply filed again next year.
How is audit evidence collected, and how much of it means chasing people?
Why ask it
This one is for governance, risk and compliance roles. Evidence pulled straight from systems leaves time for judging risk, which is the interesting part of the work. If collection means emailing colleagues for screenshots every quarter, that is the job, whatever the title says.
Incidents
Is there an on-call rotation for security, and how many people are on it?
Why ask it
Divide the weeks in a year by the number of people and you have your share. With two or three on the rotation you are seldom really off, and one vacation doubles the load on someone. Two more things to settle: how soon a new hire joins it, and whether the first call goes to security or to an IT help desk that escalates.
How many times was the person on call woken up last month, and by what?
Why ask it
A count from last month beats 'not often'. What woke them matters as much: a real intrusion attempt is the job, while a full disk on the log server or a scanner tripping its own alarm is noise somebody should have fixed. A team that reviews its noisy pages can tell you which ones it has retired.
Is the SOC staffed around the clock, and which shift would I be on?
Why ask it
Shift patterns in a security operations center vary a great deal, from weekday hours with an outside provider overnight to rotating nights. Get the pattern, how far ahead the schedule is published and how people move off nights. If the posting was vague about this, pin it down before an offer and not after.
What was the last real incident here, and what did the team change afterwards?
Why ask it
Details may be off limits to a candidate, and an outline will do: how it was found, how long it ran, what was different a month later. A control added or a process rewritten is the answer you hope for. 'We have never had one' deserves a gentle question about how they would know.
During an incident, who is in charge, and can they take a system offline without asking permission?
Why ask it
Containment sometimes means switching off something that earns money, and the time to settle who may do that is before it is needed. A named role with written authority is the good answer. Where it takes a call to an executive in the middle of the night, the intruder gets however long that call takes.
Is there a written incident response plan, and when was it last rehearsed?
Why ask it
A plan nobody has practiced is only a document. A tabletop exercise in the past year, with people from outside security in the room, means legal, communications and leadership have at least met the problem once. The useful detail is what the last rehearsal showed was missing.
After an incident, is there a written review, and who reads it?
Why ask it
Reviews that look for the gap in the system get honest timelines. Reviews that look for the person who slipped get careful, incomplete ones. Either kind counts for little unless someone checks that its action items were finished.
When an employee reports that they clicked on a phishing link, what happens to them?
Why ask it
This is the quickest read on the security culture you would inherit. Thanks and a fast reset teach people to report. Public shaming or a mark on their record teaches them to stay quiet, and then your team finds out days later from the logs.
Is on-call paid, and do people get time back after a long night on an incident?
Why ask it
Extra pay, time off the next day, or nothing: it varies by employer and by place, so get this team's answer and check that the offer letter agrees. A manager who sends people home after a long night has thought about keeping them. A long pause before the answer suggests nobody has decided.
Who is allowed to accept a risk, and is the decision recorded with a name on it?
Why ask it
A risk that a senior owner signs for, with a date to revisit it, is a decision. A risk that sits unanswered in a ticket has been accepted by default, and if something goes wrong the security team tends to wear it. How the last exception was approved will show which kind this company has.
Do executives or other senior staff get exceptions to security policy?
Why ask it
Many places have a few, and the people who get them are often the most attractive targets. Knowing how many exceptions exist and when each one expires is what being in control of them looks like. A laugh and 'you know how it is' tells you how much weight the team carries upstairs.
How is the security budget decided, and did it grow, shrink or hold steady this year?
Why ask it
You do not need the figure, only the direction and who argues for it. A budget carved out of IT's has to compete with laptops and licenses. Money that appeared only after a scare can leave once the scare is forgotten, so listen for whether it is in next year's plan too.
Does security have a say in which AI tools staff use, and is there a policy yet?
Why ask it
Staff pasting customer data or source code into an outside tool is a newer kind of leak, and plenty of companies are still deciding who owns it. A short written policy and a list of approved tools is a solid answer. If security learns about new tools from the expense reports, you have heard how early it gets consulted on anything.
When did the team last buy, replace or drop a tool, and who made the decision?
Why ask it
It shows whether the people who run the tools have a say in choosing them. Ask what the team pays for and does not use, since a product chosen by someone who has since left often sits on the shelf. If you would be expected to evaluate products, find out whether that comes on top of the queue or in place of it.
How often does security report to executives or the board, and what do they ask about?
Why ask it
Regular time with leadership means security has a voice before something goes wrong. The questions leaders ask are the tell: whether they want to understand risk or only to hear that the audit passed. For a junior role this still matters, because it decides whether your manager's requests get funded.
Which team does security find hardest to work with, and what is being done about it?
Why ask it
Most security teams have one: the developers who ship around the review, the sales group that wants an exception for each deal, the office that still shares passwords. An honest manager names it and says what has been tried. That relationship is where the hard conversations in the job would be, and it may be part of why the job exists.
Which findings from the last audit or penetration test are still open, and why?
Why ask it
A few open findings with owners and dates is what a working program looks like. The same items carried from one report to the next means findings are being written down and not fixed. If the reason is always another team's priorities, you have learned how far security's word goes.
Growth
Is there a budget for certifications and courses, and does it cover exam fees and study time?
Why ask it
Some employers pay for the course and the exam, some only for a pass, and some want it repaid if you leave soon afterwards, so get this employer's terms. Who approves the spend, and what the last person on the team used it for, shows whether the budget is real.
Which certifications does this role require, and how long would I have to earn one I lack?
Why ask it
Some employers need named credentials on certain roles, often because a customer or a contract says so, and whether that applies here is for them to tell you. If one is required, settle who pays for it as well as the deadline. If none is, the ones the team respects and the ones it shrugs at make a good second question.
Do people get time during work hours for labs, research or capture the flag events?
Why ask it
Attack techniques and tools keep moving, and a team with no room to practice ends up knowing only its own environment. A standing half day, a lab budget or a team entry in a competition are all real answers. 'On your own time' is an answer too, and you should weigh it.
Do people move between specialties here, say from the SOC into engineering or testing?
Why ask it
A monitoring job is a common way into the field for people who hope to specialize later. The name of someone who made the move, and how long it took them, is better evidence than 'we encourage it'. Where the teams sit under different managers with separate headcount, a move can depend on a vacancy opening up, so find out how often one does.
Who would review my work, whether that is an investigation, a detection rule or a report?
Why ask it
Being the only security person, or the most senior one, means nobody checks your work and nobody teaches you. That can suit a veteran and stall someone early in their career. Where there is a strong senior, find out whether they have time to read what you write or are buried in their own queue.
How do you judge performance in a job where a good year is one in which nothing happens?
Why ask it
Counting closed tickets rewards speed over care, and blaming the team for every incident punishes the people who found it. Better measures sound like coverage added, time to detect, findings closed, or the quality of a written investigation. If the manager has not thought about it, your rating may hang on whether there was a breach.
How long do people on this team tend to stay, and what do you do about burnout?
Why ask it
Ask for tenure first, since that part can be answered with facts. Then listen to whether burnout is treated as a workload problem, with rotations off the queue and real days off after incidents, or as a personal weakness. Short tenures on a round-the-clock team are worth a direct question about why.
Closing
Is the job on site, hybrid or remote, and does that change during an incident?
Why ask it
Some security work is tied to a room: a monitoring floor, a restricted network, hardware you have to touch. Other teams are remote until something serious happens and then want everyone reachable or in the building. Get both the ordinary week and the incident week before you plan a commute around the answer.
Does this role need a background check or a clearance, and how long does that usually take?
Why ask it
What is required depends on the employer, the sector and the country, so have them spell out what applies and what it involves. The timing matters for a practical reason: you may want to hold off giving notice at your current job until it is done, and to know whether the start date waits on the result.
Is there a tool, a domain or a kind of incident you would want me stronger in before I start?
Why ask it
Better to hear the doubt now than to have it raised after you have left the room. If they name something you have not worked with, answer with how you learned the last unfamiliar one. Whatever they pick is also a reading list for the weeks before day one.
Is there a practical exercise or technical round still to come, and what should I expect from it?
Why ask it
Security hiring often includes a hands-on stage: a log to investigate, a lab to break into, a policy to critique. Length, time limits and whether you may use your own tools are all fair things to settle in advance. An exercise built on the team's own kind of work is also a free look at the job.
Could I talk to someone on the team who does this work day to day?
Why ask it
Managers describe the program, and analysts and engineers describe the queue. Ask that person about the last bad week and what the manager did during it. A refusal is unusual enough to weigh, though a very small team may simply have nobody to spare.
How to interview a security team before you join it
Practical guidance for the conversation itself
Before the interview
Start from the job you are going for
A SOC analyst needs the answers under Daily work and Incidents most: alert volume, who tunes the rules, the shift and the on-call load. A security engineer should lean on tooling ownership, the vulnerability handoff and when security joins a project. For a GRC role, take the questions on regulations, evidence, risk acceptance and open audit findings. A penetration tester wants scope, retests and everything under Authority, because a report nobody has to act on is the main frustration of that job. Whichever it is, mark the five you most need, since your turn to ask is often a few minutes at the end.
Know who can answer what
A recruiter can usually answer on shifts, background checks and the training policy, and may not know much beyond that. Save the reporting line, the budget and what happens when security says no for the person you would report to. A future teammate is the best source on the queue, the tools and the last bad night. If one person is doing all three interviews, start with Program and leave the logistics for the end.
Read what the company has made public
Look at the company's security or trust page if it has one, its other open security postings and anything it has published about past incidents. Three analyst roles open at once says something, and so does a posting for a first security hire. Then build on what you found: 'I saw you are hiring a second detection engineer. Who tunes the rules today?' gets further than starting cold.
Decide what you can say about your last employer
Your questions will draw questions back: how noisy your last queue was, how an incident you worked on unfolded. Work out beforehand how to describe that without naming a customer, a vulnerability or anything a confidentiality agreement covers. A security team is listening for exactly this, and a candidate who is loose with a former employer's details has shown how they would treat the next one's.
In the room
Ask about last month, not the runbook
'What is your incident process?' gets the document read back to you. 'What happened the last time someone was paged at night?' gets a time, a person and an outcome. Most questions under Incidents and Authority work better pointed at one recent occasion.
Expect some answers to be off limits
A team that will not describe an open vulnerability or the details of a breach to a stranger is doing its job. Say so before they have to: 'I do not need specifics, only how it was found and what changed.' You are judging how they think about the problem, and the outline of an answer is enough for that.
Put one question to both the manager and an analyst
Choose something countable, such as how noisy the queue is or how often on-call gets paged. A manager sees the monthly summary and an analyst sees every shift. When the two accounts match, you can trust the rest of what the manager told you a good deal more.
Write down the names
Note each product, framework and regulation they mention. Afterwards the list shows what you would be learning for the next couple of years, how much of it would carry over to another employer, and what to read up on before a second round. If most of the names are new to you, say so and see how they propose to get you up to speed.
Reading the answers
A named gap beats a clean bill of health
No security program is finished, so a manager who lists what is missing, in order, with a rough plan, is describing a team that knows itself. 'We are in a really strong place' with no detail is either guarded or unexamined. One follow-up will usually show which.
Listen to how they talk about everyone else
Security depends on other people doing things: patching, reporting, asking early. A team that calls users careless and developers lazy has stopped trying to make the safe way the easy way, and its requests are probably ignored in return. Respect in both directions is one of the better signs you can hear.
Separate what is fixed from what can move
The reporting line, the shift pattern and the regulations the company answers to will not change because you joined. Training money, which tools you work in, and when you go onto the rotation often can. Spend your judgment on the first kind and your negotiating on the second.
Hold it against what you want from the job
A young program with one generalist and no roadmap is a mess to someone who wants to specialize and a rare chance to someone who wants to build. A mature team with narrow roles is the reverse. Decide which you are after before the interview, so that a likeable manager does not decide it for you.
Mistakes to avoid
Turning your questions into an audit
Working through controls one by one, or correcting the interviewer's choice of tools, shows knowledge and loses the room. The blunt questions, on executive exceptions or findings left open, land better with a sentence of context: 'In my last job security could advise but not decide, and I would like to know how it is here.' Keep opinions on their architecture for after you have seen it.
Skipping on-call out of politeness
Candidates often leave out shifts, pages and time off after incidents for fear of seeming uncommitted. In security work those are the conditions of the job, and a manager who runs a decent rotation will be glad to describe it. Ask plainly, and ask early enough to get a full answer.
Treating a past breach as a verdict
An incident in a company's history does not make it a bad place to work. What they did afterwards is the thing to judge: whether money and authority followed, and whether the people who handled it are still there. A team that has been through one and changed can teach you more than one that has only read about them.
Taking the title at its word
'Security engineer' can mean building detection pipelines at one company and answering vendor questionnaires at another, and 'analyst' covers everything from triage to threat hunting. The typical-week question that opens Daily work is the check. If the week they describe does not match the title, believe the week.