

Keep ISO 27001 Stage 2 interview answers focused by following three rules: answer only the question you are asked, ask the auditor to clarify before you elaborate, and follow the auditor's lead in technical discussions. Control owners should explain their own controls in plain language and point to documentation rather than guessing. Talking too widely opens scope the auditor did not plan to examine and eats into the time left for the remaining audit items.
This advice came out of a live Q&A where one compliance lead asked for last-minute input exactly one hour before briefing their own team for Stage 2.
Because an auditor follows what you say. Every unprompted detail is a new thread they can reasonably pull, and each thread costs time the audit plan did not budget for. The interview is there to confirm that the ISMS is lived, not to test whether your team can recite clauses.
The single most useful instruction you can give a control owner is this: only answer the questions you're asked. Don't talk too much or too wide, there is a lot to cover in Stage 2. People who volunteer context they were not asked for usually do it out of nerves, and it almost always lengthens the conversation.
Auditors interview people for a reason. Verizon's 2025 Data Breach Investigations Report found that 60% of breaches involved human involvement (Verizon), so the people side of your ISMS is exactly what a certification body wants to test. The ISO Survey counted 83,016 valid ISO/IEC 27001 certifications globally in 2023, across 165 countries (International Organization for Standardization).
Time pressure is the real risk here. If three interviews run long, the remaining control owners get rushed, evidence gets presented badly, and avoidable findings start to appear. Teams that treat interview discipline as a control in itself tend to share the same habits of successfully certified companies.
Brief every interviewee on these three behaviors. They take five minutes to explain and they protect the whole audit schedule.
Respond to the specific question, give the evidence that backs it, then stop talking. Answering briefly never means hiding relevant facts or known gaps. Silence after an answer feels uncomfortable, but it is the auditor's job to fill it with the next question.
A good example: if the auditor asks how a developer gets access to production, the answer is the request, the approval, and who grants it. It is not a tour of your entire cloud architecture. Over-explaining is one of the most common ISO 27001 mistakes in otherwise well-prepared companies.
If the question is ambiguous, do not guess. Ask the auditor: "Can you give me an example of the evidence you'd like to see?" instead of going wide and overcomplicating it.
This single question saves more audit time than any amount of rehearsal. It turns a vague prompt into a specific evidence request, which your control owner can usually satisfy with one screenshot, one ticket, or one log export. Guessing, by contrast, produces three pieces of the wrong evidence and a follow-up question about why the right one is missing.
Engineers want to show depth. Auditors want to see a control operating as documented. Those two instincts pull in opposite directions, and the technical interview is where it shows.
Technical conversations can go sideways, lose a lot of time and build pressure for the rest of the audit. Keep the answer inside the boundary of the question, ask follow-up questions to confirm what the auditor actually needs, and let them decide how deep to go. Understanding what an ISO 27001 auditor is looking for helps your technical staff resist the urge to perform.
Assign every in-scope control to a named person who can explain it in their own words. A single spokesperson answering for the whole company reads as a rehearsed script, and auditors treat that as weak awareness evidence.
The control owners present their own controls. A typical split looks like this:
Engineering lead or CTO: development, cloud and IT controls
A leadership person: policies, risk management and GRC
Whoever leads hiring: HR controls, onboarding and offboarding
In Secfix, the compliance automation platform, every control has a named owner, so it is clear before the audit who presents what. Then block their calendars. Control owners who get pulled into a customer call mid-audit are a scheduling problem, not a security one, and the auditor may note it.
Named ownership is rarer than it should be. In the UK government's 2025 to 2026 survey, only 39% of businesses had assigned incident roles or responsibilities to specific individuals (UK Department for Science, Innovation and Technology). If your ISMS says a role exists, somebody in the room needs to answer for it.
Everyone else needs far less. They need to know where the policies live, how to report an incident, and that "I don't know, but I can show you where it's documented" is a correct answer. Broad awareness is thin in most organizations: only 19% of UK businesses had provided staff with cyber-security training or awareness raising in the previous 12 months, while 76% of large businesses had done so, according to the same survey program (UK Department for Science, Innovation and Technology). A short refresher the week before the audit helps close that gap for your own team.
Brief every control owner on one behavior before the audit starts: answer the question, then wait.
Teach the fallback phrase "I don't know, but I can show you where it's documented." It is a valid answer and far better than guessing.
Assign each in-scope control to a named owner who can explain it without reading from a script, and block their time for the audit window.
Run a 15-minute dry run per interviewee focused on scope discipline, not on memorizing policy text.
Give your team a single question to ask whenever a request is unclear: what evidence would you like to see?
Most questions probe awareness rather than knowledge. Expect: where do you find the information security policy, how would you report a suspected incident, what training have you completed, and what is your part in a specific control? For technical staff, expect a walkthrough instead, such as a ticket showing one developer wrote the code, another performed QA, and how the change reached production.
One incorrect answer rarely triggers a nonconformity on its own. Auditors sample, and they weigh patterns more than individual slips. What does cause findings is confident guessing that contradicts your documentation, because it suggests the written process and the real process have drifted apart. Admitting uncertainty and pointing to the documented procedure is usually the safer answer.
They look for operational proof that controls run the way your documents claim: access review records, leaver removals, change tickets, training completion logs, vulnerability scan output, and the incident register. Incident handling gets particular attention, and for good reason. Only 25% of UK businesses had a formal incident response plan in place in the 2025 to 2026 Cyber Security Breaches Survey (UK Department for Science, Innovation and Technology).
No. Auditors are checking that people know the policies exist, know where to find them, and follow them day to day. Memorization sounds rehearsed and tells the auditor nothing about whether the ISMS is actually operating.
Stage 2 preparation is about clarity of role, not volume of knowledge. When each control owner knows which control is theirs, answers only what is asked, and points to evidence instead of improvising, the audit runs to plan and the findings reflect your real control environment. Carry the same discipline into surveillance visits and maintaining your ISO 27001 certification gets considerably easier.
Free SaaS webinar now open for all our visitors