GRC interviews are lost by candidates who can recite a framework but cannot say how they would test a control, score a risk or push back on an owner. This guide gives the questions hiring panels ask governance, risk and compliance analysts, with model answers at junior and senior level, a set of scenario exercises, the framework facts candidates are expected to know without notes, and a scoring rubric for interviewers. Answers are framework-led and vendor-neutral: they describe how a good analyst reasons, not which GRC tool screen to open. It is written for people applying for GRC, risk, compliance and IT audit analyst roles, and for managers who want a consistent interview. What the role involves and how to get into it is covered in the GRC Analyst Career Guide; CVs, interview formats and offers in the Cyber Security Interview Preparation Guide.
Key takeaways
- Evidence answers win. Panels want to hear population, sample, test, exception and retest, not "I would check the policy exists".
- Know the structure of the main frameworks cold. ISO/IEC 27001:2022 clauses 4 to 10 and Annex A, the six NIST CSF 2.0 functions, the SOC 2 trust services categories and the NIST risk management framework come up in almost every technical round.
- Risk statements are a test in themselves. Expect to rewrite a vague risk as cause, event and consequence, then score it and propose a treatment an owner would accept.
- Identity is where most findings live. Access reviews, leavers, privileged accounts and service accounts or API keys are the standard scenario, so prepare an access control test end to end.
- Judgement beats compliance. Senior answers explain when a finding matters, when an exception is acceptable and how to tell a board something it does not want to hear.
What panels test at each level
| Level | Typical titles | What the panel tests | Usual format | Answers that lose marks |
|---|---|---|---|---|
| Junior (0 to 2 years) | GRC analyst, compliance analyst, IT audit associate | Framework structure, evidence quality, writing a clear finding, organisation and follow-up | Technical questions, a short evidence review exercise, behavioural round | Treating a screenshot or a policy as proof the control works; reciting control lists |
| Mid (2 to 5 years) | Senior GRC analyst, risk analyst, IT auditor | Control testing design, risk scoring, framework mapping, third-party assessments, owner challenge | Case study with an evidence pack, risk register critique, panel with a control owner | Scoring risks without stating assumptions; accepting management's word; no sampling logic |
| Lead (5 years and over) | GRC lead, risk manager, audit manager | Programme design, risk appetite, regulator and auditor relationships, board reporting, prioritisation | Presentation to a mixed panel, programme design exercise, stakeholder role play | Framework for its own sake; no view on what to stop doing; reports with no decision for the reader |
Framework and standards questions
1. Explain the structure of ISO/IEC 27001:2022.
Model answer: "Clauses 4 to 10 are the management system requirements: context, leadership, planning, support, operation, performance evaluation and improvement. Those are mandatory for certification. Annex A is a reference list of 93 controls in four themes: organisational, people, physical and technological. You select controls through risk assessment and justify inclusions and exclusions in the statement of applicability. ISO/IEC 27002 gives the implementation guidance for those controls, but you certify against 27001, not 27002." A strong candidate adds that auditors look as hard at clause 9 (internal audit and management review) as at Annex A. See the ISO 27001 Certification Guide.
2. What is the statement of applicability, and what goes wrong with it?
Model answer: "It lists every Annex A control, whether it is included, the justification, and whether it is implemented. It goes wrong when it is written once for the certification audit and never touched again, when exclusions are justified with 'not applicable' and no reason, or when it says a control is implemented and nobody can show evidence. I would trace a few included controls back to a risk in the register and forward to evidence of operation."
3. Walk me through NIST CSF 2.0.
Model answer: "Six functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern was added in 2.0 and covers context, risk management strategy, roles, policy, oversight and supply chain risk. Under the functions are categories and subcategories, for example PR.AA-05, which covers access permissions managed with least privilege and separation of duties. Organisations use profiles: a current profile and a target profile, and the gap between them becomes the plan. CSF is a framework, not a certifiable standard." See the NIST CSF 2.0 Guide.
4. What is the difference between a SOC 2 Type 1 and Type 2 report?
Model answer: "Both are attestation reports by an independent CPA firm against the AICPA trust services criteria: security, which is always in scope, plus availability, processing integrity, confidentiality and privacy where chosen. Type 1 covers the design of controls at a point in time. Type 2 covers design and operating effectiveness over a period, commonly six to twelve months, so it is the one that tells you whether controls worked. When I review a supplier's report I read the scope and system description, the period, exceptions in the testing section, the auditor's opinion, and the complementary user entity controls we are expected to run ourselves." See the SOC 2 Guide.
5. What is the NIST risk management framework, and who uses it?
Model answer: "SP 800-37 Rev. 2 describes it: prepare, categorise the system, select controls, implement, assess, authorise and monitor. It is mandatory for US federal systems and used by contractors and some regulated firms. The output is an authorisation decision by an accountable official based on the residual risk, supported by a plan of action and milestones (SP 800-53 CA-5) for open weaknesses. Assessment uses the procedures in SP 800-53A."
6. How would you map one control to several frameworks?
Model answer: "Start from a control written in our own words with an owner, frequency and evidence, then map it outward, not the other way round. A quarterly privileged access review maps to ISO 27001 Annex A 5.18 and 8.2, NIST SP 800-53 AC-2 and AC-6(7), CSF PR.AA-05 and the SOC 2 logical access criteria. One test, one evidence set, many frameworks. Mapping the other way creates duplicate controls and duplicate evidence requests to the same owner." See the Control Mapping Guide.
Risk questions
7. Rewrite this risk: "Cyber attack".
Model answer: "As cause, event and consequence: 'Because leavers' SaaS accounts are removed manually and late (cause), a former employee or an attacker using their credentials could access customer data after departure (event), leading to a reportable data breach, regulatory action and customer loss (consequence).' Now it has an owner (whoever runs leaver processing), a control to test and a measurable indicator: leaver accounts still active after the agreed service level." See the Risk Register Template.
8. How do you score likelihood and impact without inventing numbers?
Model answer: "Use the organisation's defined scale and write the assumptions next to the score: the threat source, existing controls and the evidence for them. NIST SP 800-30 Rev. 1 frames risk assessment around threat sources and events, vulnerabilities, likelihood and impact. Where data exists, such as incident history or the number of exposed accounts, use it. For material risks, quantified methods that express loss as a range give the board something better than a red cell, but only if the inputs are honest." See the Cyber Risk Quantification Guide.
9. What is the difference between inherent and residual risk, and appetite and tolerance?
Model answer: "Inherent risk is the exposure before controls are taken into account; residual is what remains with controls as they actually operate, which is why control testing feeds the risk register. Risk appetite is the amount and type of risk the organisation is willing to pursue or accept; tolerance is the acceptable variation around it, often expressed as a threshold on an indicator. CSF 2.0 GV.RM-02 expects both statements to be established, communicated and maintained." See the Cyber Risk Appetite Statement Template.
10. A risk owner wants to accept a high risk. What do you do?
Model answer: "Acceptance is a legitimate treatment if the person accepting has the authority for that level of risk under the appetite statement. I make sure the decision is documented with the rationale, any compensating controls, an expiry date and a review trigger, and that a high risk outside appetite is escalated to the level that can accept it. My job is to make the decision informed and visible, not to block it."
11. How does ISO 31000 differ from ISO 27001?
Model answer: "ISO 31000:2018 gives guidelines on risk management for any type of risk: principles, a framework and a process. It is not certifiable. ISO 27001 is a certifiable requirements standard for an information security management system, and its risk assessment clauses are consistent with ISO 31000 thinking. Many organisations use ISO 31000 at enterprise level and 27001 for information security." See the ISO 31000 Risk Management Guide.
Audit and control testing questions
12. How do you test whether a control operates effectively?
Model answer: "First test design: would the control, as described, address the risk if it ran? Then operation over the period. Get a complete population from the system, not a list someone typed, select a sample sized for the control frequency, test each item against the control description, and record exceptions with the owner's explanation. NIST SP 800-53A describes three assessment methods: examine (review documents and artefacts), interview (discuss with personnel) and test (exercise the mechanism and compare actual to expected behaviour). Interview alone never proves operation."
13. Walk me through testing a quarterly user access review.
Model answer: "I check the review population was complete: every account in the system, including service accounts and API clients, reconciled to the system export at the review date. I check the reviewer was the right person and independent of the access they reviewed. I check decisions were made, not bulk-approved in seconds; the revoke rate and decision timestamps tell you a lot. Then I take a sample of revocations and confirm the access was actually removed in the target system. A review with 100% completion and nothing removed is a finding until proven otherwise." See the Access Reviews Guide.
14. Management says the control works but cannot produce evidence. What do you do?
Model answer: "No evidence, no assurance. I record it as not evidenced, ask whether system logs or reports could reconstruct operation for the period, and if not, rate it as a deficiency and agree how evidence will be produced going forward. Retrospective documents created for the audit are a red flag, and I would note their creation date." See the Audit Evidence and Continuous Controls Monitoring Guide.
15. Explain the three lines model.
Model answer: "The IIA's Three Lines Model, updated from the old three lines of defence in 2020, separates management that owns and manages risk in the first line, specialist functions such as risk and compliance that provide expertise, support and challenge in the second, and internal audit that gives independent assurance in the third, all accountable to the governing body. GRC analysts usually sit in the second line, which is why independence from the controls you assess matters."
Third-party and regulatory questions
16. How do you assess a new SaaS supplier?
Model answer: "Tier it first by the data and access it will have, so effort matches risk. For a high tier: the SOC 2 Type 2 report or ISO 27001 certificate with its scope, a questionnaire only where the report leaves gaps, the supplier's own access to our data and systems including integration accounts and API tokens, subprocessors, breach notification terms and right to audit. The output is a risk rating, conditions to fix before go-live and a reassessment date." See the Third-Party Risk Management Guide and the Security Questionnaires Guide.
17. A new regulation applies to us. How do you start?
Model answer: "Read the official text and confirm the dates and scope that apply to our entity. Break it into obligations, map each to existing controls and owners, and find the gaps. Record it in an obligations register with the source article, owner, evidence and status. Then brief leadership on the gaps that need budget or decisions, with the deadlines. I avoid relying on summaries for dates, because implementation dates and national transposition change." See the Compliance Obligations Register Template and, for financial entities in the EU, the DORA Guide.
Senior and lead questions
18. How would you report cyber risk to the board?
Model answer: "A short narrative on the top risks against appetite, what changed since last time and why, the decisions needed from the board, and a handful of indicators with trend and threshold. CSF 2.0 GV.OV-03 expects risk management performance to be evaluated and adjusted, so each indicator should drive a decision or it should go. I would never send a heat map without saying what we are doing about the red cells." See the Board Cyber Risk Reporting Guide.
19. You inherit 400 open audit findings. What do you do in the first 90 days?
Model answer: "Triage by risk, not age: group duplicates and findings with a shared root cause, such as manual leaver processing behind a dozen access findings, then fix root causes rather than closing items one by one. Confirm owners and realistic dates, close anything already fixed with evidence, and agree with internal audit how retesting will work. Report the trend and the top root causes, not just the count."
20. How would you bring non-human identities into the control framework?
Model answer: "Service accounts, API keys, OAuth apps and AI agent credentials often sit outside the access review population. I would add them to the account inventory scope, require a named human owner for each, include them in access reviews and leaver processing when the owner leaves, and set rotation or expiry requirements. Then test it like any other control: population, sample, evidence." See the NHI Ownership Guide.
Scenario exercises panels use
| Scenario | What a strong answer covers | Common weak answer |
|---|---|---|
| Evidence pack: an access review export, an HR leavers list and a policy | Spots leavers with active accounts, checks review dates against the policy, asks about service accounts missing from the export | Confirms the policy exists and the review was signed |
| Risk register with ten vague entries | Rewrites as cause, event and consequence, merges duplicates, assigns owners, flags risks with no linked control | Re-scores the entries without changing the wording |
| A supplier's SOC 2 Type 2 report with two exceptions | Checks scope covers the service bought, weighs the exceptions, lists complementary user entity controls we must run | Reports "SOC 2 received, supplier approved" |
| Control owner refuses to fix a finding | Understands the constraint, offers compensating control or time-bound exception, escalates through governance if needed | Either drops the finding or escalates immediately |
| Board asks "are we compliant?" | Answers with scope, the material gaps, their risk and the plan, and separates compliance from security | "Yes, we passed the audit" |
Behavioural questions
- Tell me about a finding you raised that an owner disputed. Show you listened, re-checked the evidence and either changed the rating for a reason or held it with escalation.
- Tell me about a mistake in your work. Name it, what it affected, how you corrected the record and what you changed so it does not recur.
- How do you manage twenty overdue actions across ten owners? Prioritise by risk, agree dates in writing, report status at a set rhythm and escalate on a rule, not on mood.
- Explain a technical control to a non-technical manager. Use an example from their own process and say what happens to the business if it fails.
How to prepare
- Read the job description against the three levels above. Note which frameworks and regulations are named, and whether the role leans to risk, audit or certification.
- Build one control test end to end. Pick access reviews or leaver processing and write the control, population, sample, test steps, exceptions and rating. Use it as your worked example.
- Rewrite five risks. Practise cause, event and consequence, score with stated assumptions and propose a treatment.
- Read one real SOC 2 report or ISO 27001 statement of applicability if you can access one through work, and practise the "what do you read first" answer.
- Prepare three stories for conflict with an owner, a mistake and a process you improved, each with a measurable result.
Certifications help shortlisting more than interviews: CRISC suits risk roles and CISA suits audit roles. See the CRISC Certification Guide and the CISA Certification Guide.
For hiring managers: a scoring rubric
| Dimension | 1: below bar | 3: meets bar | 5: strong |
|---|---|---|---|
| Evidence and testing | Accepts documents and assertions | Uses population, sample and exceptions | Tests design and operation, spots incomplete populations and retrospective evidence |
| Risk reasoning | Vague risks and unexplained scores | Cause, event and consequence with stated assumptions | Links risks to appetite, controls and indicators |
| Framework fluency | Recites names | Explains structure and purpose of the main frameworks | Maps once and tests once across frameworks |
| Stakeholder judgement | Avoids conflict or escalates everything | Negotiates dates and exceptions | Changes owner behaviour and knows when to escalate |
| Communication | Long, jargon-heavy findings | Clear finding with criteria, condition and recommendation | Writes for the decision the reader must make |
Give every candidate at a level the same case material, score independently before discussion, and do not reward memorised control numbers over reasoning.
Framework mapping
| Interview area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Governance, policy and oversight | GV.PO-01, GV.OV-03 | PM-9 |
| Risk assessment and appetite | GV.RM-02, GV.RM-03, ID.RA-05 | RA-3 |
| Control testing and remediation | ID.IM-01 | CA-2, CA-5, CA-7 |
| Access control scenarios | PR.AA-01, PR.AA-05 | AC-2, AC-5, AC-6(7) |
| Legal and regulatory obligations | GV.OC-03 | PM-9 |
| Performance measurement | GV.OV-03 | PM-6 |
Common failure patterns
- Policy as proof: answering "how do you know it works?" with "there is a policy". Always move to evidence of operation.
- Incomplete populations: testing a sample from a list someone gave you, without checking it matches the system, which is how service accounts and contractors drop out of reviews.
- Scores without assumptions: a risk rated "high" with no stated threat, control or evidence cannot be challenged or improved.
- Compliance as the goal: saying "we passed the audit" when asked about security. Panels for senior roles mark this down hard.
- No position on exceptions: either refusing all exceptions or accepting them without expiry, owner and compensating control.
- Framework trivia: memorising control numbers instead of practising one complete control test and one risk rewrite.
Practitioner checklist
- Explain ISO/IEC 27001:2022 clauses versus Annex A and the statement of applicability in under two minutes.
- Name the six CSF 2.0 functions and say what Govern covers.
- Describe SOC 2 Type 1 versus Type 2 and what you read first in a report.
- Walk through one control test with population, sample, exceptions, rating and retest.
- Rewrite a vague risk as cause, event and consequence with an owner and indicator.
- Explain inherent versus residual risk and appetite versus tolerance.
- Prepare a third-party assessment answer that starts with tiering.
- Include service accounts and API keys in your access review example.
- Prepare three behavioural stories with measurable outcomes.
Standards and references
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53A Rev. 5 Assessing Security and Privacy Controls in Information Systems and Organizations
- NIST: SP 800-37 Rev. 2 Risk Management Framework for Information Systems and Organizations
- NIST: SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
- ISO: ISO 31000:2018 Risk management, Guidelines
- AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
- The IIA: The IIA's Three Lines Model
- ISACA: CRISC certification
Related NHI Mgmt Group resources: GRC Analyst Career Guide · SOC Analyst Interview Questions and Answers · IAM Engineer Interview Questions · GRC Maturity Model