In this section
Check My Knowledge
Check My Knowledge
Test your understanding of the GRC operating model, failure modes, organizational positioning, and regulatory drivers. These scenarios present governance decisions that require you to apply the concepts from this module.
Scenario 1. Your organization's risk register lists "ransomware" at High likelihood, High impact. The treatment is "endpoint detection deployed." The compliance evidence is "Defender for Endpoint license purchased." An auditor reviews this entry. What is the most significant problem?
The risk rating is too high — ransomware likelihood should decrease once endpoint detection is deployedIncorrect
Deploying endpoint detection reduces residual risk but doesn't change the inherent likelihood of ransomware attacks targeting the organization. The problem is elsewhere in the entry.
Nothing is wrong — the risk is identified, treated, and evidenced according to the standard formatIncorrect
The entry looks complete structurally but fails on substance. The risk description is vague, the treatment is unspecific, and the evidence demonstrates procurement rather than effectiveness.
The evidence demonstrates procurement, not control effectiveness — a license purchase proves the organization paid for the tool, not that it's deployed, configured, monitored, or producing triaged alertsCorrect
This is the compliance trap from Section 1.2. Evidence of purchase satisfies a checkbox but tells the auditor nothing about whether the control is working. Effective evidence would show deployment coverage percentage, detection policy configuration, alert triage records, and response times. Section 1.1 covered the feedback loop where compliance evidence must assess actual control effectiveness.
The treatment should specify budget allocated rather than the tool deployedIncorrect
Budget allocation is a governance input, not a risk treatment. The treatment should describe what the control does, what coverage it provides, and what response process operates when a detection fires.
Scenario 2. The CIO asks the CISO to delay an internal audit of network segmentation controls because the infrastructure team is in the middle of a cloud migration and "does not have time to deal with audit findings right now." How should the CISO respond?
Delay the audit — migration is higher priority and findings during transition will be misleadingIncorrect
The migration is exactly when the audit is most valuable. Architectural changes introduce control gaps. Delaying the audit doesn't remove the risk — it removes the ability to detect it before an external auditor or an attacker does.
Reframe the audit as a migration health check that identifies control gaps introduced by the migration before they become external audit findings or exploitable vulnerabilitiesCorrect
Section 1.3 established that independence means conducting assessments when they're needed, not when they're convenient. The correct response preserves the relationship (reframing rather than confronting) while protecting the function's independence. If the CIO insists, escalation to the risk committee is appropriate.
Conduct the audit without informing the CIO — the GRC function must maintain independenceIncorrect
Independence doesn't mean operating covertly. Conducting audits secretly damages the trust that makes governance effective. The correct approach uses influence, not stealth. Section 1.3 covered this distinction between authority through enforcement and authority through relationship.
Agree to delay but document the CIO's request as a risk acceptanceIncorrect
Documenting the delay is better than silently accepting it, but the correct first response is to push back constructively. Risk acceptance should be the last resort when the risk owner has been fully informed, not a passive response to operational pressure.
Scenario 3. A 500-person firm has 104 governance documents. The helpdesk technician who received a reported phishing email found three documents with contradicting response instructions. Which failure mode does this represent, and what is the structural fix?
Compliance trap — the policies exist but controls aren't being monitored for effectivenessIncorrect
The compliance trap is about measuring documentation existence rather than control effectiveness. This scenario is about documentation volume and contradiction, which is a different failure mode.
Tool trap — the organization needs a GRC platform to manage the document libraryIncorrect
A platform would organize the 104 documents more efficiently but wouldn't resolve the contradictions between them. The problem is program design, not tooling. Case study 3 in Section 1.2 showed that platforms automate broken processes.
Audit-driven trap — the documents were created retroactively before auditsIncorrect
The audit-driven trap is about programs that activate before audits and go dormant after. This scenario describes documents accumulated over time through accretion, not retroactive creation.
Documentation trap — volume replaced usability, and the fix is consolidating to 8-12 core policies with procedures under their parent documents rather than scattered across a separate libraryCorrect
Case study 2 in Section 1.2 described this exact pattern. The structural fix is a minimum viable document set where the first question for any new requirement is "which existing document does this belong in?" rather than "what new document do we need?" Module G2 builds this framework.
Scenario 4. The GRC function reports to the CISO. The annual board risk report shows 24 risks on a 5x5 heat map with 12 recommended actions. The board chair says the report is "not useful." What is the core problem?
The report needs more detail — add control effectiveness data for each risk to give the board full visibilityIncorrect
More detail makes the problem worse. Boards don't need risk data that requires interpretation. They need risk intelligence that supports decisions. Adding detail moves further from what the board actually needs.
The heat map should use a 3x3 matrix instead — 5x5 creates too many possible positionsIncorrect
Simplifying the visualization doesn't solve the underlying problem. Whether 3x3 or 5x5, presenting all 24 risks without prioritization or decision context gives the board data rather than intelligence.
The report presents data instead of decisions — the board needs the top 3-5 risks requiring board-level attention, presented in business impact terms, with trend direction and a specific decision request per riskCorrect
Boards can realistically approve 2-3 significant decisions per meeting. Presenting 24 risks with 12 recommendations is a wish list, not a governance instrument. The GRC function must translate risk management output into executive decision-making input. Module G13 covers board reporting formats in depth.
The problem is the reporting line — the CISO is filtering the GRC assessment before it reaches the boardIncorrect
While independence filtering is a real concern from Section 1.3, the scenario describes a report that is "not useful" because of its format and content, not because it was editorially filtered. The report was presented — it just didn't serve the board's decision-making needs.
Scenario 5. A 200-person company's working GRC program uses Excel for the risk register, SharePoint for policies, and PowerPoint for board reports. Audits pass, risks are managed, reports are delivered on time. A new CISO proposes purchasing a $120K/year GRC platform. Is this the right decision?
Yes — spreadsheets are unprofessional and the organization needs to modernize its GRC toolingIncorrect
Professionalism is not a valid purchase criterion. The current program works: audits pass, risks are managed, deliverables are on time. Case study 3 in Section 1.2 showed a $540K platform that increased workload by 30% because it automated broken processes.
Not yet — the platform should be triggered by specific operational pain (evidence collection bottleneck, scale limitations, cross-framework mapping burden), not by an assumption that spreadsheets are inadequateCorrect
This is the tool trap from Section 1.2. A working program using simple tools is better than a broken program using expensive ones. The $120K/year might deliver more value as an additional GRC analyst who expands program coverage. Module G15 positions tool evaluation after the program has operated manually long enough to know what actually needs automating.
No — spreadsheets are always sufficient for GRC regardless of organization sizeIncorrect
"Always" is incorrect. Organizations with multiple frameworks, hundreds of controls, and distributed teams will eventually outgrow spreadsheets. The question is whether this organization has reached that point, and the evidence suggests it hasn't.
Yes — but only if the CISO negotiates the price below $80K/yearIncorrect
The price isn't the issue. Even a free platform would add complexity and transition cost to a working program. The decision should be driven by operational need, not price optimization.
Scenario 6. Your organization processes UK resident personal data and sells to US enterprise customers. You need to determine which frameworks apply. Which assessment approach is correct?
Start with mandatory obligations (UK GDPR), then assess customer-driven requirements (SOC 2, ISO 27001 based on sales team feedback), then sector-specific, then insurance, then competitive positioningCorrect
Section 1.4 established that driver analysis starts with mandatory obligations (non-negotiable), then layers customer-driven, insurance, competitive, and risk reduction drivers. Each requires different frameworks and has different consequences for non-compliance. The combination determines the program design.
ISO 27001 covers everything — implement it and both UK and US requirements are satisfiedIncorrect
ISO 27001 is comprehensive for information security management but doesn't satisfy GDPR-specific requirements (lawful basis, ROPA, DPIA, data subject rights) or SOC 2's trust service criteria. Each framework addresses different stakeholder expectations.
UK GDPR for data processing and SOC 2 for US customers — that covers both requirementsIncorrect
This captures two drivers but misses others: sector-specific requirements if serving regulated industries, insurance conditions that may mandate specific controls, competitive positioning relative to competitors, and Cyber Essentials if selling to UK government supply chain.
Hire a consultant to determine which frameworks apply — this assessment is too complex for internal staffIncorrect
The driver analysis methodology from Section 1.4 is designed for internal execution. A consultant can help, but the GRC lead should own the assessment because they understand the business context, customer requirements, and competitive landscape better than any external party.
Scenario 7. The SOC handled a BEC attempt last month — the detection rule fired, the analyst contained it, the incident was closed. The GRC analyst discovers that nobody connected the incident to the risk register. The risk register still shows "email-based threats: Medium likelihood." What does this reveal about the GRC program?
The SOC failed by not updating the risk register after the incidentIncorrect
Updating the risk register is a GRC function, not a SOC function. The SOC's job was to detect and contain the threat, which they did successfully. The failure is structural, not individual.
The risk register is fine — one incident doesn't change the likelihood ratingIncorrect
The incident provides sector-specific evidence that the threat is active and targeting the organization, which is exactly the data that should update a likelihood assessment. Dismissing operational evidence keeps the risk register based on assumptions rather than reality.
The incident response process needs improvement — it should include a risk register update stepIncorrect
Adding a step to the IR process helps but treats the symptom. The underlying problem is that the feedback loop between compliance/operations and risk management (Loop 3 from Section 1.1) doesn't exist.
The feedback loop from operational evidence back to risk assessment is broken — the GRC program is running open-loop, meaning the risk register never receives correction signals from actual incidentsCorrect
Section 1.1 identified three feedback loops in the GRC operating system. Loop 3 (compliance evidence reassesses risk) is missing. The BEC attempt is operational evidence that the threat is real and targeting this organization, which should update the risk score. Without this loop, the risk register degrades because it never receives correction signals. This was the Scenario that opened Section 1.1.
Scenario 8. Your organization scored 6 on the maturity self-assessment from Section 1.1 (Structured level). Components exist but aren't integrated. The CISO wants to pursue ISO 27001 certification immediately. Is this the right sequencing?
Yes — ISO 27001 certification will force the integration that the program currently lacksIncorrect
Certification forces documentation and audit readiness but doesn't guarantee integration. Case study 1 in Section 1.2 showed a certified organization whose controls had five undocumented MFA exclusions. The certification process can produce a compliant but disconnected program.
Build the integration first — connect the risk register to policy decisions and compliance evidence to risk scores (G2-G5), then pursue certification (G6) with a program that's already operating as a systemCorrect
Section 1.1 established that moving from Structured to Integrated means connecting the existing components: ensuring the risk register drives policy decisions, policies reference specific controls, and compliance evidence traces back to risk scores. The framework selection diagram in Section 1.4 showed that all certification paths require the risk management foundation (G3-G5) first. Building the foundation before pursuing certification produces a program that maintains itself between audits rather than requiring annual panic.
No — at a score of 6, the organization should focus on reaching score 10 before any certificationIncorrect
Waiting for a specific maturity score before pursuing certification creates indefinite delay. The correct sequencing is to build the foundations (which increases maturity) and then pursue certification. The two activities are complementary, not sequential to a threshold.
It depends on whether a customer or regulator is requiring the certificationIncorrect
The external driver affects the urgency timeline but not the optimal sequencing. Even under deadline pressure, building the risk management foundation first produces a more sustainable certification. Rushing to certification without foundations creates Case Study 1.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.