Test your understanding of the course foundations, the operational GRC philosophy, and the course structure. These questions assess whether you have the conceptual grounding to get maximum value from the subsequent modules.
Module G0 — Knowledge Check
1. Your organization's current GRC program consists of a policy library on SharePoint (last updated 14 months ago), a risk register in Excel (reviewed annually before the board meeting), and an external audit that happens every March. The CISO describes the program as "mature." What is the most accurate assessment?
This is an audit-driven GRC program, not a continuous one. The policies are likely out of date, the risk register reflects last year's risk landscape, and the program produces assurance only during the annual audit window. Between audits, there is no evidence that controls are operating effectively. This is compliance theater — it may satisfy the auditor once a year, but it does not reduce risk or inform decision-making continuously.
The program is mature — it has policies, a risk register, and regular audits, which covers the three pillars of GRC
The program just needs more frequent updates — change the risk register review to quarterly and it will be sufficient
Correct. Annual updates and audit-driven reviews are the hallmark of a compliance theater program. A working GRC program produces continuous evidence: the risk register reflects current risks because it is updated when risks change (not on a calendar cycle), policies are reviewed when the processes they govern change, and control effectiveness is monitored continuously through operational data — not validated once a year by an auditor. Module G1 examines this failure mode in detail.
2. A security engineer has just deployed a new conditional access policy in Entra ID that requires MFA for all users accessing Exchange Online. From a GRC perspective, what should happen next?
Nothing — the technical control is deployed, so the security work is done
The control needs to be mapped to the risks it mitigates, the compliance requirements it satisfies, the policy that mandates it, and the evidence that demonstrates it is working. Specifically: update the risk register to reflect the reduced likelihood of credential-based attacks, map the control to the relevant framework requirements (ISO 27001 A.8.5, NIST CSF PR.AA-03, SOC 2 CC6.1), ensure the Authentication Policy references this specific implementation, and establish monitoring that produces evidence the control is operating — for example, a query that shows MFA enforcement rate and identifies any exclusions or bypasses.
Update the policies to mention that MFA is now required — the auditor will need to see the policy
Correct. A technical control without governance mapping is invisible to the GRC program. The control may be reducing risk, but without the mapping, you cannot prove it to an auditor, report it to leadership, or track its continued effectiveness. The GRC mapping is not bureaucracy — it is what connects the engineer's work to the organization's risk posture, compliance status, and security reporting. This is the "GRC-mapped engineering" principle that runs through every module.
3. Your organization has been asked by a major customer to provide a SOC 2 Type II report. You have never been through a SOC 2 audit. What is the correct sequence of actions?
Immediately engage a CPA firm to conduct the audit
Purchase a GRC platform that supports SOC 2 and start documenting controls
Start with a gap analysis: determine which Trust Service Categories apply (Security is mandatory, the others depend on your services), identify what controls you already have in place, identify what gaps exist, build a remediation plan, allow sufficient time for the observation period (Type II requires controls operating effectively over a period — typically 6 to 12 months), then engage the CPA firm. The customer timeline determines whether you start with a Type I (point-in-time) to demonstrate progress while building toward Type II.
Correct. Engaging the auditor before you have controls in place wastes money and produces findings that damage your credibility. Buying a GRC platform before understanding your requirements creates tool debt. The correct approach is: understand the requirement, assess your current state, build what is missing, operate it for the observation period, then engage the auditor. Module G8 covers this complete process.
4. A GRC colleague says: "We need to implement all 93 Annex A controls for ISO 27001 certification." Is this correct?
Yes — ISO 27001 requires implementation of all Annex A controls
No. ISO 27001 requires you to determine which Annex A controls are applicable based on your risk assessment, not implement all of them. The Statement of Applicability (SoA) documents which controls apply, which do not, and the justification for exclusion. If a control is not relevant to your risk landscape — for example, A.7.7 (Clear desk and clear screen) may not apply to a fully remote organization with no physical offices — you can exclude it with documented justification. What the auditor checks is whether your risk assessment is sound and whether the SoA exclusions are justified, not whether you have implemented all 93 controls.
It depends on the size of the organization — large organizations need all controls, small ones can select a subset
Correct. This is one of the most common misconceptions about ISO 27001. The standard requires a risk-driven approach to control selection, not blanket implementation. Organizations that try to implement all 93 controls regardless of applicability create unnecessary compliance burden and dilute focus from the controls that actually matter for their risk profile. Module G6 covers the risk assessment to SoA pipeline in detail.
5. You have been asked to present the organization's security risk posture to the board. Which of the following approaches is most effective?
Present the full risk register with all identified risks, their likelihood and impact scores, and the current treatment status
Present a single "overall risk score" and a RAG dashboard showing control compliance status
Present the top 5 risks in business impact terms (not technical terms), the trend direction for each (increasing, stable, decreasing), the investment required to address them, and the residual risk the organization is accepting. Include one specific metric that connects security performance to business outcomes — for example, "mean time to detect a breach has decreased from 14 days to 6 hours, reducing average breach cost exposure by an estimated $X." Board members need enough information to make decisions, not enough information to understand the technical detail.
Correct. The full risk register overwhelms the board with detail they cannot assess. A single risk score and RAG dashboard oversimplifies to the point of uselessness — the board cannot make decisions based on "green." The correct approach presents risk in business terms, includes enough context for decision-making, and connects security investment to measurable business outcomes. Module G13 covers board reporting in depth.
6. Your organization is subject to both ISO 27001 and SOC 2 requirements. How should you approach implementing both?
Implement them separately — they are different frameworks with different requirements
Cross-map the controls. Many controls satisfy requirements in both frameworks simultaneously. For example, access control requirements in ISO 27001 Annex A.5.15-5.18 map closely to SOC 2 CC6.1-CC6.3. Build a unified control set that satisfies both, document the cross-mapping, and maintain a single evidence repository that serves both audits. The risk assessment methodology from G3 feeds both frameworks. The policy framework from G2 supports both. Duplicate effort is the enemy — identify overlaps early and build once.
Start with whichever framework the customer requires first, then add the second one later
Correct. Implementing frameworks separately creates duplicate documentation, duplicate evidence collection, and duplicate audit preparation — at roughly double the cost and effort. Cross-mapping identifies which controls satisfy both frameworks, which are unique to each, and where the requirements differ. Module G7 (NIST CSF) specifically covers cross-mapping methodology, and the principles apply to any multi-framework environment.
7. A vendor sends you a security questionnaire with 200 questions. Your organization has no formal GRC documentation. What is the most effective response strategy?
Answer the questionnaire honestly, noting gaps where they exist
Delay the response until you have built the documentation the questionnaire expects
Use the questionnaire as a gap analysis tool. Most vendor security questionnaires map to standard framework controls. Answering honestly identifies your gaps. Where you have controls in place but not documented, document them as you answer — this produces governance artifacts as a byproduct of the questionnaire response. Where you have genuine gaps, note them with a remediation timeline. The questionnaire response becomes the starting point for your GRC program, and the completed questionnaire becomes a reusable template for future vendor requests. This is pragmatic GRC — building governance capability from operational need, not from theoretical planning.
Correct. The vendor questionnaire is an audit in disguise — it tells you exactly what a customer expects your security posture to look like. Using it as a gap analysis tool converts a compliance burden into a program building exercise. Delaying loses the customer. Answering without documentation leaves you unable to demonstrate the controls you claim to have. Module G2 (policy framework) and G4 (controls mapping) directly address this scenario.
8. What distinguishes a working GRC program from compliance theater?
A working program has more documentation and more comprehensive policies
A working program uses a dedicated GRC platform rather than spreadsheets
A working program produces continuous evidence of control effectiveness, informs risk-based decision-making, adapts to organizational change without annual rebuild cycles, and connects governance requirements to operational reality. Compliance theater produces documentation that describes an idealised state, is updated on audit cycles rather than when things change, and exists to satisfy external requirements rather than to reduce risk. The distinguishing factor is not volume of documentation or sophistication of tooling — it is whether the program actively reduces risk and enables better decisions, or whether it exists solely to pass audits.
Correct. More documentation does not equal better governance — it often equals more unread, unmaintained documentation. GRC platforms do not create governance capability — they automate it, which only helps if the underlying program is sound. The test is operational: does the program continuously produce evidence, inform decisions, and adapt to change? Or does it exist only during audit season? This philosophy underpins every module in the course.
9. A security engineer tells you: "I just deployed 15 new Sentinel analytics rules. That should help with our ISO 27001 audit next month." What is missing from this statement?
Nothing — deploying detection rules directly improves the security posture and audit readiness
The rules themselves are technical controls. For the ISO 27001 audit, each rule needs to be mapped to the specific Annex A control it satisfies, documented in the Statement of Applicability, and supported by evidence that the rules are functioning — alert volumes, triage records, and resolution data over the observation period. Additionally, the rules need to be connected to the risks they mitigate in the risk register. Without this mapping, the auditor cannot trace from the control requirement to the technical implementation to the evidence of effectiveness. The engineer deployed the controls. The GRC mapping that makes them audit-ready is a separate step.
The rules need to be reviewed by the GRC team before deployment
Correct. Technical deployment and governance mapping are complementary activities. The detection rules reduce risk immediately — that value is real regardless of the audit. But for the rules to count as audit evidence, they must be connected to the framework: which control do they satisfy, which risk do they mitigate, and what evidence demonstrates they are operating effectively over time. This is the GRC-mapped engineering principle — the technical and governance work happen together, not sequentially.
10. Your organization uses spreadsheets for risk management and a shared drive for policy documents. A vendor proposes replacing everything with a GRC platform at $45,000 per year. When is the right time to make this investment?
Immediately — the platform will impose structure and discipline on the program
Never — spreadsheets are sufficient for any organization
When the current tools create operational pain that justifies the cost. Specific triggers: the risk register has grown beyond what a single spreadsheet can manage (200+ risks with cross-references), multiple people need concurrent edit access and version conflicts are frequent, evidence collection for audits takes weeks because artifacts are scattered across systems, or you are managing three or more frameworks and the cross-mapping overhead in spreadsheets is unsustainable. Until those triggers are hit, a well-structured spreadsheet and document repository is perfectly adequate. The platform automates execution of a program that already works — it does not create the program.
Correct. This is the tool trap avoidance pattern. A GRC platform is an automation layer, not a program design tool. Buying it before the program is designed means configuring the platform around the vendor's default workflow rather than your actual needs. Buying it after the program is running means you know exactly what you need automated, your selection criteria are based on operational experience, and the implementation has a clear target state. Module G15 covers this evaluation in detail.
11. You are building the GRC program for a 150-person technology company. The CEO asks: "How many policies do we need?" What is the correct answer?
ISO 27001 requires approximately 20-25 policies, so that is the target
The minimum viable set is typically 8-12 core policies for an organization of this size: Information Security Policy (overarching), Acceptable Use Policy, Access Control Policy, Data Classification and Handling Policy, Incident Response Policy, Business Continuity and Disaster Recovery Policy, Risk Management Policy, Supplier and Third-Party Security Policy, and potentially Data Protection/Privacy Policy, Change Management Policy, and Physical Security Policy depending on your environment. The correct number is determined by your risk assessment and your compliance requirements — not by a target count. Every policy must have a named owner, a defined review trigger, and a measurable compliance criterion. Five well-maintained, enforced policies are worth more than fifty unread ones.
As many as possible — comprehensive policy coverage demonstrates maturity
Correct. Policy count is not a maturity indicator. The documentation trap starts with the belief that more policies equal better governance. A 150-person company with 12 well-written, actively maintained, genuinely enforced policies has stronger governance than a 150-person company with 40 policies that nobody has read. Module G2 covers the minimum viable policy set and the criteria for determining which policies your organization actually needs.
💬
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
