Session 3: Governance, Risk and Compliance

Overview

This taught session introduced Governance, Risk and Compliance (GRC) as a top-down, strategic approach to cybersecurity, building on Session 2: Cyber Fundamentals Part 2.

Cybersecurity is not only technical. Organisations need clear accountability, risk assessment, documented decisions and evidence that requirements are being followed.

• Governance — who makes security decisions and who is accountable.
• Risk — what could go wrong, its likelihood and impact, and how to respond.
• Compliance — obligations arising from law, regulation, contracts or applicable standards.

This entry records taught material and reflection, rather than completed assessments or practical work.

Governance and Accountability

Governance establishes responsibility and ownership for security decisions. When something fails, including through human error, the organisation needs to know who owns the issue and who is responsible for remediation.

Cybersecurity was presented within a wider structure involving information governance, risk management and information security. This connects with the need to coordinate people, processes and technology, rather than treating security as the responsibility of a technical team alone.

Risk and Measurement

Risk management involves identifying what could go wrong, assessing likelihood and impact, and deciding what to do. The session used a simple assessment model:

Risk = Impact × Likelihood

The coat-and-rain analogy made this relatable: whether I take a coat depends on the chance of rain, the consequence of getting wet and the context of the journey. The same event can justify different decisions in different circumstances.

What gets measured gets managed.

I took this as a reminder to identify and measure risks so they can be prioritised and managed. A score supports judgement; it does not remove uncertainty.

Risk Management Lifecycle

The four stages discussed were:

1. Identify — recognise risks to the organisation.
2. Assess — consider their likelihood and impact.
3. Treat — choose an appropriate response.
4. Monitor — review the risk and whether the response remains effective.

This is continuous because threats, systems and business priorities change.

Risk Treatment

The live session used Treat, Transfer, Tolerate and Terminate. The handbook terminology recorded in my notes was Mitigate, Transfer, Accept and Avoid. These broadly describe the same four risk treatment approaches:

• Treat / Mitigate — reduce the risk using controls.
• Transfer — pass some financial consequence to a third party, for example through insurance.
• Tolerate / Accept — formally live with the risk.
• Terminate / Avoid — stop the activity creating the risk.

Here, “treat” means reducing risk; in the lifecycle it is the broader step of choosing a response. Transferring financial consequences does not remove the organisation’s accountability.

Compliance Is Not the Same as Security

An organisation can be compliant and still be breached. One example discussed was completing a Cyber Essentials self-assessment while malware remains undetected.

The MOT analogy helped explain the distinction: passing an MOT means a car met the required standard at the time, but does not guarantee it can never develop a fault.

My takeaway was that compliance provides a baseline and evidence of required controls. It does not guarantee security or replace continuous monitoring and improvement.

Risk Appetite vs Risk Tolerance

• Risk appetite — how much risk an organisation is willing to accept in pursuit of its objectives.
• Risk tolerance — the threshold beyond which action or escalation becomes necessary.

The session’s learning aid was:

• Risk appetite: “How much do I want?”
• Risk tolerance: “How much can I handle?”

These questions help me remember the distinction, but do not replace the formal definitions or measurable organisational thresholds.

CVSS and Business Risk

We discussed a CVSS score of 9.8, within the critical severity range. A technically severe finding does not automatically determine when it will be fixed. Exposure, potential business impact, existing controls, risk appetite and the organisation’s risk-management process all matter.

Technical severity and business risk are different. A CVSS base score describes vulnerability severity; it is not a complete assessment of organisational risk. FIRST’s CVSS guidance makes this distinction explicit.

For report writing, the security professional should accurately document the finding, explain severity and potential impact, and recommend remediation. The role is to provide evidence and context for an authorised decision, rather than override it. Decisions still need an owner, documentation and any required escalation; risk acceptance does not cancel legal obligations.

Why Frameworks Exist

Security frameworks and standards offer structured, recognised approaches, so organisations do not have to invent a security programme from scratch. They also provide benchmarks for assessing controls and maturity.

They help turn intentions into repeatable processes supported by security documentation, assessment and review.

ISO/IEC 27001 and 27002

ISO/IEC 27001 is a certifiable international standard for establishing, implementing, operating and continually improving an Information Security Management System (ISMS). Certification concerns the management system within its defined scope.

ISO/IEC 27002 provides guidance on information security controls that can support that system. The Statement of Applicability records necessary controls, why they are included, whether they are implemented, and justification for excluding Annex A controls. See the ISO 27001 overview and ISO 27002 description.

We also discussed professional training and certification for auditor and implementer roles. These were career examples, not qualifications I have gained.

Cyber Essentials

The session covered five control areas:

• Firewalls.
• Secure configuration.
• User access control.
• Malware protection.
• Patch management, described by the scheme as security update management.

Cyber Essentials uses a verified self-assessment. Cyber Essentials Plus adds independent technical verification of the same controls. The NCSC scheme overview explains the distinction.

Cyber Essentials Plus was described in the session as a common entry point for GRC consulting work in the UK. I have not carried out an assessment.

NIST Cybersecurity Framework

The session introduced the five-function sequence:

Identify → Protect → Detect → Respond → Recover

These describe a continuous security lifecycle. NIST CSF was presented as useful for gap assessments: “Where are we now?” compared with “Where should we be?” It was also described as mapping well to ISO 27001, although alignment is not the same as certification.

Version clarification: the five functions reflect the earlier framework. NIST CSF 2.0 adds Govern as a sixth function, making governance explicit across the lifecycle.

UK GDPR and Data Protection

The UK GDPR and Data Protection Act 2018, as amended, create legal obligations around personal data. These differ from adopting a voluntary framework or seeking certification against a standard: applicable legal duties are mandatory.

Data Classification

Data classification helps organisations understand how sensitive information is before choosing controls. Without classification, they may over-protect low-value data and waste resources, or under-protect sensitive data and create legal and security exposure.

The four tiers discussed were:

• Public.
• Internal.
• Confidential.
• Secret / Restricted.

These are an illustrative organisational scheme; labels and handling rules vary. Penetration-test reports were an example of Secret/Restricted information because they can expose detailed organisational weaknesses. Classification helps inform controls, including access restrictions that support confidentiality.

UK GDPR Lawful Bases

The session covered these six lawful bases:

• Consent.
• Contract.
• Legal Obligation.
• Vital Interests.
• Public Task.
• Legitimate Interests.

An appropriate lawful basis must be identified before personal data is processed.

Current-law clarification: the session’s six-item list is not exhaustive under current UK GDPR. The ICO now lists recognised legitimate interest as a seventh lawful basis for specified purposes, following the Data (Use and Access) Act 2025. See the ICO’s recognised legitimate interest guidance.

ICO and the 72-Hour Rule

Not every personal-data breach automatically requires ICO notification. A controller must notify the ICO unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Notification must be made without undue delay and, where feasible, within 72 hours of becoming aware. If reporting is delayed, reasons must be provided.

Examples discussed included unauthorised access, accidental disclosure, lost or stolen devices, ransomware affecting personal data, and sending data to the wrong recipient. Each requires assessment rather than an automatic assumption about reporting.

The ICO’s breach guidance also explains that organisations should record breaches and their reporting decisions.

My takeaway was that systems, processes and controls should prevent or detect mistakes early and support timely, defensible reporting when incidents occur.

PCI DSS

PCI DSS stands for Payment Card Industry Data Security Standard. It applies to organisations that store, process or transmit payment card data, and can also cover entities that affect the security of the cardholder data environment. The PCI Security Standards Council defines its scope.

What I Learned

• GRC connects technical security with organisational decision-making.
• A vulnerability needs ownership, assessment, treatment, documentation and evidence.
• Frameworks and standards help organisations manage security consistently.
• Compliance provides a baseline, not a guarantee of security.
• Legal requirements such as UK GDPR must be handled differently from voluntary standards.

Reflection

The strongest takeaway for me was the distinction between technical severity and business risk. The CVSS 9.8 example showed that identifying a serious vulnerability is only part of the process. The organisation still needs to assess it in context, choose a response, document the decision and assign responsibility.

I also found the distinction between compliance and security useful. Passing an assessment does not remove the need for active controls, continuous monitoring and improvement.

This session helped me see GRC as the layer connecting technical findings, business priorities, accountability and legal obligations.

Next Steps

I want to develop my understanding of:

• Risk registers and formal risk assessment.
• CVSS and the relationship between technical severity and business risk.
• Risk appetite and risk tolerance.
• ISO 27001 and the role of the ISMS.
• Statements of Applicability.
• Cyber Essentials Plus assessment.
• NIST CSF gap assessments.
• UK GDPR breach assessment and reporting.
• Data classification and handling.

Next entry: Session 4: Governance, Risk and Compliance — In Depth.