Governance, Risk & Compliance (GRC)

Learning outcome: Explain GRC and assign clear responsibility for security decisions.

Governance sets direction and accountability. Risk management evaluates uncertainty that could affect business objectives. Compliance demonstrates how applicable requirements are addressed. These activities reinforce one another, but a completed checklist does not prove that every important risk is controlled.

For a fictional retailer, start with the objective: keep online orders available and protect customer information. Identify a business risk owner who can accept or escalate risk, a control owner who operates the safeguard, and an independent reviewer who checks evidence. The security analyst supports the decision; they do not silently accept risk on behalf of management.

A policy states expectations and ownership; a standard makes expectations measurable; a procedure explains the steps. For account access, the policy may require authorised access, the standard may define review frequency, and the procedure may describe how leavers are removed. Record an approver, version and review date.

Learning outcome: Write a risk scenario and choose a justified treatment.

Write risks as scenarios, not isolated words such as phishing. Example: an attacker obtains a support account through a deceptive message, then exports customer records because access is broader than necessary. Describe the asset, threat, weakness and business consequence. Separate facts from assumptions and identify missing evidence.

For this exercise only, use likelihood and impact scores of 1 to 3 and multiply them to prioritise discussion. Define the scales first: impact should reflect business effects such as service interruption and customer harm. A score is an aid to judgement, not a probability or a precise prediction of financial loss. Consider uncertainty and dependencies as well as the number.

Compare reducing, avoiding, sharing or accepting the risk. Sharing through insurance or a supplier does not remove accountability or every consequence. Record existing controls, the proposed change, owner, due date, expected residual risk and review trigger. Obtain evidence before assuming a planned control works.

Learning outcome: Map a risk to proportionate controls and evidence.

NIST CSF 2.0 organises cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond and Recover. Use these functions as a common language for discussing coverage. They are not a six-step project that ends permanently after recovery.

For the access scenario, consider authorised provisioning, least privilege, stronger authentication, access reviews and useful monitoring. Select safeguards that address the scenario and can be operated by the organisation. A single control may support several outcomes. A mapping is a reasoned relationship, not proof of compliance or certification.

Distinguish control design from operation. A documented monthly access review describes the design. A dated review, relevant account population, recorded decisions and evidence of removals help show operation. Ask whether the evidence covers the intended period and scope. Document gaps rather than quietly marking the control complete.

Learning outcome: Build an evidence request and distinguish a finding from an assumption.

Create an obligations register before claiming compliance. Record the requirement source, applicability rationale, owner, evidence and review date. Sources may include contracts, internal policy, legislation and chosen standards. Applicability depends on the organisation and jurisdiction; seek qualified advice where interpretation is needed. This lesson does not determine legal obligations.

An assurance test should state the control objective, scope, period, method, sample rationale and expected evidence. For example, inspect a defined sample of leavers and compare the approved departure dates with recorded access removal. A small sample does not justify a claim about every transaction without explaining its limitations.

A useful finding separates the expected condition from what was observed, describes the risk and proposes an action. Record evidence references without copying sensitive personal data into a learning portfolio. Set an action owner and due date, then retest before closing. A management assertion and an independent audit opinion are different types of assurance.

Learning outcome: Assess a supplier in context and prepare escalation decisions.

A supplier questionnaire is a starting point, not a guarantee. Identify the service provided, information accessed, dependencies, business criticality and possible exit routes. The depth of review should reflect exposure. A low-impact tool and a supplier running order processing need different levels of scrutiny.

Request evidence proportionate to the relationship: relevant assurance scope and dates, access arrangements, recovery testing and incident communication. Check which service, locations and subcontractors the evidence covers. Record unanswered questions and contractual dependencies rather than assuming a certificate covers every product.

Prepare an incident decision plan before an event: who coordinates, who assesses business impact, who communicates with the supplier and who obtains specialist advice. Confirm notification commitments from applicable contracts and requirements rather than inventing one deadline for every incident. Exercise a supplier outage using fictional information and record improvements.

Learning outcome: Present an actionable GRC report using your practice artefacts.

A management report should support a decision. Explain the business objective, the most important scenarios, current controls, unresolved gaps and the decision required. Distinguish observed facts, assumptions and estimates. Avoid presenting a dashboard colour without explaining what it means.

Choose metrics that answer a question. For overdue high-priority actions, define priority, the measurement date and what counts as overdue. For access-review coverage, define the population and denominator. Improved reporting does not necessarily mean risk has fallen: changes may reflect better detection, a new scope or missing data.

Your capstone is a fictional retailer GRC pack: a scope and responsibility map, three risk records, a control matrix, an evidence request and finding, a supplier assessment and a one-page management brief. Explain trade-offs and uncertainties in your own words. Keep employer data, customer records, passwords and confidential audit reports out of the submission.