Scenario & Behavioural interview questions

Structure a 60–90 second answer: present → past → future.

• Present: your current role, scope and environment (e.g. cyber risk governance in a healthcare technology company; frameworks such as ISO 27001, NIST, SOC 2, HIPAA).
• Past: 2–3 achievements with measurable outcomes (e.g. led a certification, built a risk register, reduced overdue findings, improved vendor assessment turnaround).
• Future: why this role — e.g. bringing regulated-industry GRC experience to a growing team and learning new frameworks.

Keep it relevant to the job description; avoid reciting your CV line by line.

Tailor this to your own motivation. Good themes:

• Rapid digital transformation and a strong focus on cyber security and data protection, creating demand for experienced GRC professionals.
• The chance to apply framework experience (ISO 27001, NIST, SOC 2, HIPAA) while learning new regulations relevant to the employer.
• Interest in a specific sector, e.g. healthcare, government or financial services.
• Long-term commitment to the field and the role.

Avoid answers focused only on salary or job title.

STAR stands for Situation, Task, Action, Result:

• Situation: brief context, such as the organisation, team, and what was happening.
• Task: your responsibility or the goal.
• Action: what you did, specifically. Use 'I', not just 'we'. This should be the longest part.
• Result: the outcome, with numbers if possible, and what you learned.

Prepare 6–8 stories in advance that cover common themes: audit, risk, conflict, failure, influence, deadlines, learning.

• Choose a real but manageable mistake, not a disaster and not a fake 'weakness'.
• Explain the situation briefly and take ownership. Do not blame others.
• Focus on how you noticed it, what you did to fix it and who you told.
• End with what you changed so it would not happen again (process, checklist, habit).

Interviewers want honesty, accountability and learning.

• Connect your experience directly to their needs: regulated healthcare data, audit and certification, risk governance and vendor risk.
• Mention your credentials briefly (for example CISA and ISO 27001 Lead Auditor) and what you have done with them.
• Show awareness of the rules that apply to them: the local data protection law, health regulator requirements and data localisation.
• Give one or two short results with numbers.
• End with enthusiasm for their mission.

• Days 1–30 (understand): meet stakeholders, learn business objectives, regulatory and contractual obligations, existing policies, past audits and incidents; identify crown-jewel assets and key vendors.
• Days 31–60 (assess): run a high-level gap assessment against a chosen framework (e.g. ISO 27001 or NIST CSF 2.0), stand up an initial risk register with the top risks and owners, and agree a risk methodology.
• Days 61–90 (plan): propose governance (committee, policy framework, RACI), a prioritised roadmap with quick wins, metrics and resource needs; get leadership sign-off.

Throughout: build relationships and deliver a few visible quick wins (e.g. MFA gaps, an exception process).

• Start with the business impact: 'If this happens, we could be unable to process customer orders for several days and may have to notify regulators.'
• Explain likelihood simply and honestly, with evidence (e.g. similar incidents in the sector, exposure findings).
• Avoid jargon; use analogies if helpful.
• Present options with cost, effort and risk reduction, and a recommendation.
• Be clear about the decision you need and by when.

Use STAR. A strong example covers:

• Situation/Task: e.g. a business leader wanted to launch a system or onboard a vendor that had unresolved high risks.
• Action: you listened to their goals, quantified or clearly described the risk, proposed alternatives (phased launch, compensating controls) and, where needed, used the formal risk acceptance/escalation route.
• Result: a decision was made with the risk understood and documented; ideally the project still delivered with reduced risk, and the relationship stayed positive.

Emphasise collaboration and process rather than 'winning' the argument.

• Rate each finding by risk (impact and likelihood), regulatory or contractual exposure, and whether it is a repeat finding.
• Group findings by root cause — fixing one systemic issue (e.g. no joiner-mover-leaver process) may close several findings.
• Identify quick wins that reduce risk with little effort.
• Agree a realistic plan with owners and dates; get leadership support for the high-risk items.
• Communicate transparently with auditors about the plan and track progress through governance.

1. Read the official text and guidance; confirm applicability and effective dates (involve legal).
2. Break it into specific requirements and map them to existing controls and policies.
3. Identify gaps and estimate effort and cost.
4. Assign owners and build a compliance roadmap with milestones before the effective date.
5. Brief leadership on impact, risk of non-compliance and resource needs.
6. Implement, collect evidence and monitor for further guidance or amendments.

• Stay calm and focus on facts. Walk through the criteria, the evidence and the condition together.
• Listen. They may have evidence you have not seen, or the finding may be worded unfairly.
• If you are wrong, correct the finding. If you are right, explain the risk in their terms and how it affects them.
• Work on the remediation together and agree realistic dates.
• If disagreement continues, record management's response and escalate through the agreed audit process.

• Acknowledge the gap honestly to your manager and set realistic expectations.
• Learn the basics quickly: key standards (for OT, IEC 62443 and NIST SP 800-82), the main risks and terminology.
• Find internal experts and involve them early. Engineers know their systems better than you do.
• Apply your transferable GRC skills: risk assessment, control frameworks, interviews and evidence.
• Validate your conclusions with subject matter experts before reporting.

• Clarify why: is there a deadline such as a board meeting or a go-live?
• Propose a reduced scope: focus on the highest-risk areas, use existing evidence (SOC 2, previous assessments) and hold one workshop with key people.
• Be clear about limitations in the output ('rapid assessment, based on X, not including Y').
• Agree a follow-up to complete the full assessment later if needed.
• Deliver on time with transparent assumptions.

• Listen first and get specifics: which process, which delay, what impact?
• Often the problem is fixable: unclear requirements, slow approvals or a missing self-service option.
• Offer solutions: pre-approved patterns, risk-based fast tracks for low-risk changes, clear timelines for reviews.
• Explain the risks of skipping controls in their terms, without lecturing.
• Measure and share improvements, such as review turnaround time.

• Understand the business priorities: customers and contracts that need certifications, upcoming audits, regulatory deadlines.
• Address the highest risks and must-haves first, such as MFA, backups, access reviews and incident response basics.
• Build lightweight foundations: a risk register, a policy set and an obligations register.
• Use automation and existing tools rather than building heavy processes.
• Report simply to leadership and agree priorities, so trade-offs are their decisions.
• Build champions in each team to extend your reach.

• Make sure the incident response plan is activated with the right people (IR, IT, legal, privacy, communications, leadership).
• Support impact assessment: which data and processes are affected, whether personal or health data may be involved.
• Track regulatory, contractual and insurer notification timelines (e.g. HIPAA, GDPR, national requirements, customer contracts) and support legal in decision-making.
• Keep a clear decision and evidence log.
• Coordinate continuity: check BCP and DR activation against RTO/RPO.
• Afterwards: lead lessons learned, update the risk register, track remediation and report to leadership and the board.

Decisions on ransom payment are for senior leadership with legal advice; GRC helps make sure they are informed and documented.

• Inventory AI use cases, including third-party tools and features embedded in existing software.
• Classify use cases by risk (e.g. use of personal or health data, automated decisions affecting people, customer-facing outputs).
• Set an AI acceptable-use policy and approval process; involve privacy, legal, security and business owners.
• Assess risks such as data leakage, accuracy and bias, explainability, security of models and vendor terms.
• Use recognised references: ISO/IEC 42001 (AI management system), the NIST AI Risk Management Framework, and regulations relevant to your markets, such as the EU AI Act.
• Monitor, review and report AI risks through existing governance rather than creating a separate silo.

• Gather facts quietly and carefully: logs, tickets, approvals. Do not accuse anyone based on suspicion alone.
• Check whether there is a legitimate explanation, such as an emergency change process.
• If the concern stands, report it through the right channel: your manager, internal audit, compliance or the whistleblowing line, depending on seriousness and policy.
• Keep the matter confidential and avoid investigating beyond your role.
• Recommend a technical fix that prevents self-approval regardless of the person.

1. Month 1: agree scope, get a sponsor, run a gap assessment and set the project plan.
2. Months 1–2: define the risk methodology, run the risk assessment, and draft the SoA and core policies.
3. Months 2–4: implement and evidence controls, run awareness, and start collecting operating evidence.
4. Month 4: run the internal audit across all clauses and key controls.
5. Month 5: hold the management review, fix findings, and run Stage 1.
6. Month 6: close Stage 1 observations, then Stage 2.

Throughout: keep leadership engaged and choose a certification body early, because their availability can drive the dates.

• Inform leadership, legal and the relevant owners immediately, and confirm who will host the inspectors.
• Confirm the scope and the inspector's likely focus if known.
• Prepare a room, a single point of contact, an attendance and request log, and a briefing for staff who may be interviewed (be honest, answer what is asked, do not guess).
• Gather key documents: policies, risk assessments, recent audit reports, incident logs and evidence of key controls.
• Do not create or change documents to make them look better. Present what exists.

• Confirm the facts quickly: what was reported, what is the actual status, since when, and why.
• Inform your manager, legal and the account owner. Correcting it is not optional.
• Agree on a correction with legal, describing the actual status, impact and remediation plan.
• Fix the underlying control or gap and the reporting process (who approves customer statements and what evidence they rely on).
• Record it and learn from it. This is a trust issue as much as a compliance one.

• Continuous assurance: automated evidence and control monitoring replacing point-in-time audits.
• AI governance: ISO/IEC 42001, the EU AI Act and national AI policies creating new GRC responsibilities.
• Quantified risk: more financial expression of cyber risk for boards.
• Regulatory growth and convergence: privacy laws (GDPR, India DPDP), resilience rules (DORA, NIS2) and third-party oversight.
• Preparation: certifications and learning (for example AI governance), hands-on GRC automation skills, and building strong communication with business leaders.