Test your understanding of the GRC operating model, failure modes, organizational positioning, and regulatory drivers. These questions present governance scenarios that require you to apply the concepts from this module.
Module G1 — Knowledge Check
1. Your organization's risk register lists "ransomware" as a risk with likelihood "High" and impact "High." The treatment is "endpoint detection deployed." The compliance evidence is "Defender for Endpoint license purchased." An auditor reviews this entry. What is wrong?
Multiple problems. First, "ransomware" is too vague as a risk — it should specify the attack vector, target assets, and business impact scenario (e.g., "ransomware encryption of financial systems via phishing-delivered initial access, causing 5-10 day operational disruption and estimated $X recovery cost"). Second, the treatment "endpoint detection deployed" does not specify which detection capabilities, what coverage level, or what response process operates when a detection fires. Third, the evidence "license purchased" demonstrates procurement, not control effectiveness. A license proves the organization paid for the tool. It does not prove the tool is deployed to all endpoints, configured with appropriate detection policies, monitored by the SOC, or producing alerts that are triaged and responded to. The auditor needs evidence of deployment coverage, detection rates, and response effectiveness — not a purchase receipt.
The risk rating is too high — ransomware is unlikely if endpoint detection is deployed
Nothing is wrong — the risk is identified, treated, and evidenced
Correct. This entry illustrates three common risk register failures: vague risk descriptions that do not enable meaningful assessment, treatments described at a category level rather than a control level, and evidence that demonstrates procurement rather than effectiveness. An auditor seeing this entry would question whether the organization's risk management is operating at a meaningful level or producing entries that look complete without being useful. Module G3 builds the risk assessment methodology that prevents these failures.
2. The GRC function reports to the CISO, who reports to the CIO. The CIO has asked the CISO to delay the internal audit of the 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 — the migration is a higher priority and audit findings during a migration will be misleading
The CISO should push back. The cloud migration is exactly when the internal audit is most valuable — it identifies control gaps introduced by the migration before they become audit findings from the external auditor or, worse, before they are exploited by an attacker. The CIO's request reveals a common misunderstanding: audits are not punishment, they are risk identification. Delaying the audit does not remove the risk — it removes the organization's ability to detect the risk. The CISO should reframe the audit as a migration health check: "Let's audit the network segmentation controls specifically to verify that the migration is not introducing gaps that will become problems later." If the CIO still insists on delay, this should be escalated — the GRC function's independence is being compromised by operational convenience.
Conduct the audit without telling the CIO — the GRC function must be independent
Correct. This scenario tests the independence requirement from the organizational positioning discussion. The GRC function must be able to conduct assessments when they are needed, not when they are convenient. Conducting the audit secretly would be adversarial and damage the relationship. The correct approach is to reframe the audit's value, push back constructively, and escalate if necessary. The reporting structure matters here — if the CISO reports to the CIO, and the CIO says no, the CISO needs an escalation path (risk committee, CFO, board) that the GRC function can use to protect its independence.
3. A 200-person technology company currently has no formal GRC program. Their largest customer has informed them that ISO 27001 certification is required within 12 months for contract renewal. The contract is worth $1.8M annually. The CEO asks: "How much will this cost and how long will it take?" What information do you need before you can answer?
No additional information needed — ISO 27001 implementation for a 200-person company typically costs $30K-$80K and takes 6-9 months
Before answering, you need to understand the current state. Specifically: What security controls already exist (even if undocumented)? Many organizations have informal controls that satisfy ISO 27001 requirements — they just are not documented or evidenced. How mature is the existing IT and security management? Does the organization have any existing policies, risk assessments, or documented procedures? What is the scope — all business operations or a specific service/product? Scoping determines the size of the ISMS and therefore the implementation effort. What certif body will be used, and have they been contacted to confirm availability within the timeline? How much internal resource is available — will this be led internally, by a consultant, or a combination? Only after a gap analysis can you estimate cost and timeline. A 200-person company with mature IT practices and existing informal controls might need 4-6 months and $15K-$30K. The same size company with no existing controls might need 9-12 months and $40K-$80K. The range is too wide to answer without assessment.
Tell the CEO to hire an ISO 27001 consultant who can answer the question
Correct. The CEO wants a number. Giving a number without a gap analysis is irresponsible — underestimating creates delivery risk, overestimating may cause the CEO to decide the contract is not worth the investment. The professional answer is: "I can give you an estimate after a 2-week gap analysis that assesses what we already have versus what ISO 27001 requires. The gap analysis itself will cost approximately $X if done externally, or Y hours of internal effort." Module G6 covers the ISO 27001 gap analysis and implementation methodology in detail.
4. Your organization's Acceptable Use Policy was last reviewed 16 months ago. Since then, the organization has adopted Microsoft Copilot for all employees, migrated from on-premises file shares to SharePoint Online, and implemented a new BYOD program. The policy makes no mention of AI tools, cloud storage, or personal device usage. What is the governance implication?
The policy needs a scheduled annual review — it will be updated at the next review cycle
The policy is materially out of date and should be updated immediately, not at the next scheduled review. Three significant operational changes occurred without corresponding policy updates. This means: employees using Copilot have no governance guidance on acceptable AI use (what data can be input, what outputs can be relied on, what oversight is required). Employees using SharePoint Online have no guidance on cloud data classification and sharing permissions. Employees using personal devices have no governance on device security requirements, data handling, and access conditions. The policy gap creates three problems: compliance risk (auditor will flag the gap), security risk (employees operating without guidance may mishandle data), and liability risk (the organization cannot enforce rules it has not communicated). The root cause is that the policy review was calendar-driven rather than change-driven. A well-designed policy lifecycle triggers review when the process changes, not when the annual date arrives.
Create three new policies: AI Use Policy, Cloud Storage Policy, and BYOD Policy
Correct. This scenario illustrates the documentation trap in reverse — not too many documents, but documents that do not keep pace with operational change. Creating three new policies (option C) would be the documentation trap response — adding volume instead of maintaining what exists. The correct approach is to update the Acceptable Use Policy to cover AI, cloud storage, and BYOD as sections within the existing document. If the BYOD program is complex enough to warrant its own policy, that is a design decision — but the default should be to extend existing documents rather than create new ones. Module G2 covers change-driven policy review in detail.
5. A SOC analyst has deployed a new Sentinel analytics rule that detects impossible travel sign-ins. From a GRC perspective, trace the full mapping: which risks does this control address, which policies mandate it, and which compliance requirements does it satisfy?
Risk: compromised credentials. Policy: Access Control Policy. Compliance: ISO 27001. That is sufficient for the mapping.
Full mapping: Risk — the detection rule addresses the risk of "compromised credentials used from geographically inconsistent locations, indicating credential theft via phishing, credential stuffing, or token replay." The risk should be specific enough to distinguish this scenario from other credential compromise vectors. Policy — the Security Monitoring Policy mandates continuous monitoring of authentication events for anomalous patterns. The Access Control Policy mandates investigation of suspicious sign-in activity. The Incident Response Policy mandates response procedures when a compromised credential is detected. Compliance — ISO 27001 A.8.16 (Monitoring activities) and A.8.15 (Logging); NIST CSF DE.CM-01 (Networks and network services are monitored) and DE.AE-02 (Potentially adverse events are analyzed); SOC 2 CC7.2 (The entity monitors system components for anomalies). Evidence of effectiveness — the detection rule's alert volume, true positive rate, mean time from alert to investigation, and mean time to containment (session revocation). The mapping should be specific enough that any individual link can be audited independently.
The SOC analyst deployed a technical control — GRC mapping is the GRC team's responsibility, not the analyst's
Correct. This is the bidirectional traceability principle in action. The full mapping connects the technical control (detection rule) to the risk it mitigates, the policies that mandate it, the compliance requirements it satisfies, and the evidence that demonstrates it is working. Option A provides the mapping at too high a level — "ISO 27001" is not a compliance requirement, it is a framework containing 93 controls. Option C is organizationally incorrect — in an integrated GRC model, the SOC analyst should understand which risks their detection rules address, even if the formal mapping documentation is maintained by the GRC function. This dual fluency is the practitioner's advantage discussed throughout the course.
6. Your organization is evaluating whether to pursue ISO 27001 certification or SOC 2 attestation first. The organization is a 100-person B2B SaaS company with customers primarily in the US and UK. What factors determine the decision?
ISO 27001 first — it is the more comprehensive framework and SOC 2 maps to it
SOC 2 first — it is faster and US customers expect it
The decision depends on customer demand and revenue impact, not on which framework is "better." Determine: which certification are your current and target customers actually asking for? If your US enterprise customers are requesting SOC 2 reports during procurement, SOC 2 addresses the immediate revenue-protection need. If your UK enterprise customers require ISO 27001 as a contractual condition, ISO 27001 protects that revenue. If both are requested equally, ISO 27001 is typically the stronger starting point because the ISMS management system provides the organizational structure that SOC 2 also requires, and much of the control evidence overlaps. However, SOC 2 Type I can be achieved faster (3-4 months) than ISO 27001 certification (6-9 months) because SOC 2 Type I is a point-in-time assessment. The pragmatic approach for this company: implement the underlying controls once, cross-map to both frameworks, and pursue whichever certification the highest-value customer requires first. Module G8 (SOC 2) and Module G6 (ISO 27001) both address this sequencing question.
Correct. Framework selection is a business decision driven by customer requirements and revenue impact, not a technical decision about which framework is more comprehensive. The cross-mapping between ISO 27001 and SOC 2 means that roughly 60-70% of the control work overlaps — you are not building two separate programs. The decision is about which certification to pursue first, not which program to build. This is the commercial reality of GRC: frameworks exist to serve business objectives. Module G7 covers cross-framework mapping methodology.
7. The GRC analyst produces a quarterly risk report for the board. The report contains a 5x5 risk heat map showing 24 risks plotted by likelihood and impact, a table listing all 24 risks with their current ratings, and a section titled "Recommendations" listing 12 actions the board should approve. The board chair says the report is "not useful." Why?
The board chair does not understand risk management — the report format is standard
The report fails because it presents data instead of decisions. A board does not need to see all 24 risks — it needs to see the top 5 risks that require board-level attention, presented in business impact terms (revenue at risk, regulatory exposure, operational disruption), with trend direction (improving, stable, deteriorating), and a specific decision request per risk (approve treatment investment, accept residual risk, escalate to regulator). A 5x5 heat map with 24 dots is noise. Twelve recommendations is a wish list, not a decision framework. The board can realistically approve 2-3 significant decisions per meeting. Present the 2-3 decisions that require board authority, provide the risk context that supports each decision, and include a one-page summary of the overall risk posture for context. Module G13 covers board reporting in depth, including specific formats and templates.
The report needs more detail — add the control effectiveness data for each risk
Correct. Board reporting is one of the most common GRC failures. The GRC analyst produces a report that would be useful for the GRC team and presents it to the board as-is. Boards operate at a different altitude — they need risk intelligence that supports decisions, not risk data that requires interpretation. More detail makes the problem worse. The solution is less data, more context, and explicit decision requests. This is the governance function in action — translating risk management output into executive decision-making input.
8. An organization operates its GRC program using spreadsheets and shared drives. The GRC team consists of one full-time analyst. The analyst manages the risk register in Excel, stores policies in SharePoint, tracks audit findings in a separate spreadsheet, and produces board reports in PowerPoint. The program works — audits pass, risks are managed, reports are produced on time. A new CISO joins and immediately proposes purchasing a GRC platform for $120,000/year. Is this the right decision?
Yes — the organization has outgrown spreadsheets and needs to professionalize
Not yet, and possibly not at all. The current program works: audits pass, risks are managed, reports are delivered on time. A GRC platform solves problems that the current program does not appear to have. The CISO should first identify what specific operational pain the platform would solve: Is evidence collection taking too long? Is the risk register too large for a spreadsheet? Is multi-framework cross-mapping consuming excessive manual effort? Is concurrent access causing version conflicts? If the answer to all of these is "no," the platform adds cost and complexity without corresponding benefit. The $120,000/year would be better spent on an additional GRC analyst who can expand the program's coverage and depth. A platform purchase should be triggered by operational pain, not by an assumption that spreadsheets are unprofessional. Module G15 covers this evaluation in detail.
No — spreadsheets are always sufficient for GRC
Correct. This is the tool trap scenario from the case studies. A working program using simple tools is better than a broken program using expensive ones. The new CISO may be bringing assumptions from a previous organization where a platform was needed. The correct approach is to assess whether the current tools are causing operational problems, and if so, whether a platform is the most cost-effective solution. Sometimes the answer is hiring another person. Sometimes the answer is better-structured spreadsheets. Sometimes the answer is a platform. The assessment should precede the purchase.
9. Your organization processes personal data of UK residents and sells software to US enterprise customers. You have been asked to determine which frameworks and regulations apply. What is your assessment?
UK GDPR for the data processing, and SOC 2 for the US customers. That covers both requirements.
Start with the mandatory obligations: UK GDPR and the Data Protection Act 2018 apply because you process personal data of UK residents — this is non-negotiable and carries enforcement powers. Then assess customer-driven requirements: US enterprise customers will likely expect a SOC 2 Type II report. Some may require ISO 27001. Ask your sales team which certifications are being requested during procurement and which deals have been affected by their absence. Then consider sector-specific requirements: if you serve financial services customers, they may impose additional requirements (FCA outsourcing guidelines, DORA if they are EU-regulated). If you handle payment data, PCI DSS may apply. Then assess insurance requirements: your cyber insurance policy may require specific controls or certifications. Finally, consider competitive positioning: what do your competitors have? If they all have ISO 27001 and SOC 2, you need both to compete. The full assessment is: UK GDPR (mandatory), SOC 2 (customer-driven, likely mandatory for enterprise sales), ISO 27001 (competitive/customer-driven, assess demand), sector-specific regulations (assess based on customer industries), and Cyber Essentials (if selling to UK government supply chain).
You need ISO 27001 because it is the most comprehensive framework and covers everything else
Correct. Determining applicable frameworks is a multi-factor assessment, not a single-framework decision. The answer depends on legal obligations, customer requirements, sector-specific regulations, insurance conditions, and competitive positioning. ISO 27001 is comprehensive but does not satisfy GDPR-specific requirements (lawful basis, ROPA, DPIA, data subject rights) or SOC 2-specific requirements (system description, trust service criteria). Each framework addresses different stakeholder expectations. Module G6-G10 cover the specific frameworks, and Module G7 covers cross-framework mapping for organizations subject to multiple requirements.
10. After reading this module, a colleague says: "GRC is just bureaucracy that gets in the way of security work." How would you respond?
GRC is required by regulations and customers — it is not optional regardless of whether it adds value
Your colleague is wrong — GRC is essential and every security professional should embrace it
Your colleague may be describing their experience accurately. If the GRC program they have encountered is a documentation trap (policies nobody reads), a compliance trap (audits that do not improve security), or an audit-driven trap (annual panic that disrupts operational work), then they are right — that GRC program is bureaucracy. The problem is not the concept of governance, risk, and compliance. The problem is the implementation. A well-designed GRC program does the opposite of creating bureaucracy: it gets security projects funded (by connecting them to risk reduction and compliance requirements), it protects the security team from arbitrary decisions (by establishing governance authority), it produces evidence that the team's work is effective (which justifies continued investment), and it aligns security operations with business objectives (which gives the team strategic relevance). The goal is not to convince your colleague that GRC is important in the abstract. The goal is to build a GRC program that demonstrably helps them do their job better.
Correct. The instinct to defend GRC as a concept is natural but counterproductive. If a colleague's experience of GRC is negative, dismissing their experience will not change their mind. Validating their experience while pointing to a better model is more effective. The operational GRC philosophy taught in this course is specifically designed to produce programs that security practitioners recognize as helpful rather than obstructive. If your GRC program is creating work without reducing risk, the program needs redesigning — the colleague's criticism is the feedback mechanism.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
G0 oriented you to the discipline. G1 made the case that governance is an operating system, not a documentation exercise — the shift from "we wrote the policy" to "the policy operates every day." Now you build the operating system.
15 operational modules — policy framework, risk management, compliance operations, audit management, vendor risk, data governance, and sector-specific governance
External audit management playbook — the protocol for making audits a structured event instead of a firefight
Policy framework templates — every policy your organisation actually needs, with the structure that survives audit and operates in practice
Risk register operations — how to make the risk register a decision-making instrument instead of a spreadsheet
Sector governance (G16) — the specific compliance obligations for financial services, healthcare, public sector, and manufacturing
