Session 4: Governance, Risk and Compliance — In Depth

Overview

This classroom session developed the concepts introduced in Session 3: Governance, Risk and Compliance. It explored how governance, risk management, compliance, maturity, data protection and security frameworks work together in practice.

The recurring theme was that security needs accountability, measurement and enforcement. Technical controls alone are not sufficient. This entry records taught concepts and reflection; the scenarios are learning examples, not professional assessments, audits or consultancy work I have completed.

The Three GRC Pillars

GRC connects cybersecurity to wider business management. Its three pillars are related but distinct:

For governance, a useful summary is: “Who is in charge, and what have they decided?” Policies need named owners and a way to put decisions into practice.

Siloing: Where Boundaries Hide Risks

To silo something means to isolate a person, department, data or project so that communication, cooperation or information-sharing with others is limited, restricted or fragmented. This is not specific to IT.

Traditional or physical security may focus on premises, access and physical controls. Information security considers where information is stored, transferred, processed and accessed. Information can exist on devices and paper, inside and outside offices, and in transit. These responsibilities overlap: a printed customer record left in an unsecured office involves both areas.

Siloed teams may miss risks that cross those boundaries. A policy can have senior leadership support while older working practices continue in isolated departments.

A policy existing does not automatically mean it has become embedded in everyday practice.

Policies, Training and Accountability

Employees may acknowledge organisational policies as part of their employment, but acknowledgement alone is not enough. Staff need clear communication, appropriate training and support to follow the rules in their actual work.

If training has not been provided properly, accountability may also sit with those responsible for communicating, implementing and enforcing the policy. Governance should examine those responsibilities as well as an individual’s actions.

Compliance ≠ Security

An organisation can hold ISO/IEC 27001 certification, operate a 24/7 Security Operations Centre (SOC) and meet recognised standards, yet still suffer a breach. Certification and monitoring provide assurance and capability; they cannot guarantee that every attack will be prevented.

The Ryan Ackroyd / LulzSec discussion illustrated a lesson about assumptions: defenders often work within defined frameworks, processes and expected behaviours, while attackers look for ways around them. This is a reflection on the classroom discussion, not a claim about a particular organisation’s controls or breach.

Effective defenders need to think creatively about bypasses, unexpected interactions and gaps between teams, while continuing to work within their authorisation.

Defenders follow defined structures; attackers look for the gaps between them.

Compliance as a Baseline

Compliance should be a baseline, not the final goal. Security maturity means processes become more structured, repeatable and effective, with evidence showing whether they work.

Optimisation includes using knowledge from across the business to anticipate problems. A mature organisation can become more proactive and increasingly predictive, while recognising that uncertainty remains. It also uses security resources intelligently, removing unnecessary duplication or spend without weakening necessary protection.

ISO/IEC 27001 and Continual Improvement

ISO/IEC 27001 specifies requirements for an Information Security Management System (ISMS). It treats information security as a structured, repeatable management process, not a one-off implementation. Certification relates to the management system within its defined scope. See ISO’s overview.

Senior leaders, including a CIO or CISO where those roles exist, may lead implementation and governance. Top management retains responsibility for leadership, resources and accountability; security is not simply delegated to a technical team and forgotten.

Plan–Do–Check–Act

PDCA is a useful model for understanding continual improvement: establish an approach, implement it, check its effectiveness and use the findings to improve the next cycle.

Why Consultants Need Business Context

A cybersecurity consultant needs to understand what an organisation actually does, its business drivers and how it creates value. That includes its policies and policy gaps, where technology sits, how information flows, who is accountable, and its current and upcoming regulatory obligations.

This wider understanding can reveal risks that a purely technical assessment misses. It also helps turn findings into proportionate recommendations that the organisation can act on.

CVSS in Context

CVSS means Common Vulnerability Scoring System. It describes technical vulnerability severity; particularly, a base score is not a complete business-risk assessment. FIRST’s CVSS guidance explains this distinction.

A penetration test might identify a vulnerability with CVSS 9.8, a critical severity score. The consultant still needs to explain what that means for this organisation. Business impact, system criticality, exposure, compensating controls, risk appetite, risk tolerance, cost and available resources all affect the response.

CVSS tells you technical severity; risk management decides what the organisation does about it.

Limited resources do not make a severe finding disappear. Reports should document the evidence, explain the implications and support an authorised decision, including escalation where necessary.

Business Impact Analysis

BIA — Business Impact Analysis helps establish how important a system, service or process is by examining the consequences of disruption or compromise. In continuity planning, it also helps identify dependencies and recovery priorities over time.

Its findings can be considered alongside risk appetite, risk tolerance and urgency when deciding remediation priorities, spending and resource allocation. BIA informs impact; it does not itself establish the likelihood of an attack.

Memory aid: BIA = “How important is this to the business?”

Assessing Risk

The session used a simple scoring model:

Risk = Impact × Likelihood

Impact means how serious the consequences would be. Likelihood means how likely the event is to occur over a defined period. High impact alone does not automatically mean high risk: the likelihood and context also matter.

This is a useful assessment aid, not a universally precise calculation. Security programmes should be evidence-based rather than fear-based, recording assumptions and uncertainty instead of treating a score as objective certainty.

Qualitative and Quantitative Assessment

Qualitative assessment uses descriptive ratings such as Low, Medium and High, often displayed in a risk matrix. Assigning numbers to those categories can support ranking, but does not turn them into measured probabilities or financial losses.

Quantitative assessment uses numerical estimates, including financial values and expected event frequency. SLE, ARO and ALE provide one way to estimate annual loss. The estimates still depend on the quality of the evidence and assumptions.

SLE, ARO and ALE

ALE = SLE × ARO

ARO expresses an expected frequency, rather than a guarantee: once per year = 1; twice per year = 2; once every two years = 0.5; once every five years = 0.2.

Worked classroom example

One ransomware incident would cost £20,000. It is expected once every four years.

SLE = £20,000; ARO = 0.25.

ALE = £20,000 × 0.25 = £5,000 per year.

This helped me distinguish the cost of one incident from the expected annual loss. An ALE of £5,000 does not mean that precisely £5,000 will be lost every year.

The calculation can help justify security spending by comparing a control’s cost with the expected reduction in loss. It is one input to a decision: legal duties, safety, uncertainty and wider consequences still matter.

Identifying and Managing Risk

A useful starting sequence is Assets → Vulnerabilities → Threats:

• An asset is something of value that needs protecting.
• A vulnerability is a weakness.
• A threat is a potential cause of an unwanted incident that may exploit a vulnerability.

The fuller relationship is Asset → Vulnerability → Threat → Incident → Impact. For example:

The Risk Management Lifecycle

Identify → Assess → Treat → Monitor / Review

Identify the risk, assess likelihood and impact, choose a response, then monitor whether that response remains effective. Revisit the assessment when systems, threats or business needs change.

The session used the 4 Ts for treatment, illustrated here with a vulnerable legacy server:

Here, “Treat” is the specific option of reducing risk; the lifecycle’s treatment stage covers all four options. Transfer does not remove organisational accountability, and acceptance cannot cancel legal obligations.

Inherent and Residual Risk

Inherent risk is the risk before controls. Residual risk is what remains after controls have been applied and their effectiveness considered.

Inherent Risk → Apply Controls → Reassess → Residual Risk

Residual risk is compared with the organisation’s risk tolerance. If it exceeds acceptable limits, further treatment or escalation is required. Controls should be reassessed rather than assumed to remove the risk completely.

Risk Appetite vs Risk Tolerance

A startup may accept more uncertainty when developing a new service, whereas a bank may have a lower appetite in many risk areas. These are illustrative comparisons: appetite depends on the objective and risk category, not simply the organisation’s label.

For example, a service might have a defined tolerance of no more than one hour of disruption before escalation. This makes a broad intention measurable. Risk capacity is a different idea: the maximum risk an organisation can withstand, rather than the limit it chooses to accept.

Recognising these distinctions helps consultants produce useful, proportionate reports that connect technical findings with the organisation’s decision thresholds.

Frameworks and Standards

Frameworks and standards give organisations structure, but differ in purpose and scope. They support risk management rather than replacing business judgement.

Cyber Essentials and IASME Cyber Assurance

Cyber Essentials is a UK baseline cybersecurity scheme covering five technical control areas:

• Firewalls.
• Secure configuration.
• Security update management.
• User access control.
• Malware protection.

Cyber Essentials Plus includes independent technical verification of the same control areas. See the NCSC’s Cyber Essentials resources.

IASME Cyber Assurance is broader, considering how cybersecurity is managed alongside technical protection. It covers organisational processes and assurance beyond the basic technical controls. IASME’s resources provide the scheme detail.

NIST Cybersecurity Framework 2.0

The current six-function model is:

Govern · Identify · Protect · Detect · Respond · Recover

It provides a flexible structure for organising cybersecurity risk management. Govern addresses direction, oversight and risk decisions across the other functions. These are related activities, not a rigid one-pass sequence. The NIST CSF 2.0 overview is the reference here, rather than the older five-function model.

PCI DSS

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

UK GDPR and Data Protection

The UK GDPR and Data Protection Act 2018, as amended, form part of the UK’s legal baseline for protecting personal data. Organisations need to consider collection, processing, storage, sharing, protection and disposal throughout the information lifecycle.

The Six Lawful Bases Covered in Class

The visual below records the six bases discussed in the session. It is not an exhaustive list under current UK law: the update immediately below explains the additional basis.

Current-law clarification: the ICO now lists seven lawful bases. The Data (Use and Access) Act 2025 added recognised legitimate interest for specified purposes. This differs from the general legitimate interests basis. See the ICO’s lawful-basis guide and recognised legitimate interest guidance.

Identify and document an appropriate basis before processing. Consent is one option, not a universal solution. Special category data can require an additional condition; a lawful basis alone does not satisfy every data protection requirement.

ICO and Breach Notification

ICO means Information Commissioner’s Office, the UK data protection regulator. A controller must report a personal data breach unless it is unlikely to result in a risk to people’s rights and freedoms. Notification is required without undue delay and, where feasible, within 72 hours of becoming aware of the breach.

Not every breach requires ICO notification. Assess the consequences and document the breach and reporting decision, including the reasons for not reporting. If notification is late, provide reasons for the delay.

Where a breach is likely to result in a high risk to individuals, they must also be informed without undue delay, subject to the applicable exceptions. The ICO’s breach guidance distinguishes these reporting thresholds.

Data Classification and Handling

The four-tier organisational model discussed was:

Public → Internal → Confidential → Secret / Restricted

Labels vary between organisations. Increasing sensitivity generally calls for stronger controls, affecting access, storage, sharing, encryption and disposal. The label should lead to clear handling rules.

UK Government classifications belong to a different scheme. OFFICIAL-SENSITIVE is an additional marking within OFFICIAL, not a direct synonym for an organisation’s “Confidential” label. See the Government Security Classifications Policy.

Classification only helps if the handling controls are actually applied. These responsibilities overlap: stored information still needs access controls, and encryption is only effective when its keys are protected.

Classify the data, then protect it appropriately wherever it is stored, transferred, accessed or destroyed.

IACS and Operational Technology

IACS — Industrial Automation and Control Systems monitor or control physical processes. They are associated with Operational Technology (OT) environments such as transport, manufacturing, utilities and critical infrastructure.

Transport for London is an example of the kind of organisation that may operate large operational and control environments; this is not a claim about any specific TfL system.

IT supports information and business systems. OT/IACS can directly control physical equipment and processes. The distinction matters because security decisions may affect physical operations and safety as well as information.

Key Learning and Reflection

This session reinforced that cybersecurity is not only technical. GRC connects technology to business risk, accountability, law, compliance and decision-making.

The most useful distinctions for me were technical severity versus business priority, and broad risk appetite versus specific risk tolerance. The ransomware calculation also made the relationship between one incident’s cost and annualised loss clearer.

Compliance provides a baseline, not guaranteed security. Mature security programmes continually improve, and risk decisions should be evidence-based. A consultant needs to understand both a technical finding and the business context to explain it usefully.

This was classroom learning that developed my understanding; it does not represent completed professional risk assessments, audits, consultancy engagements or ISO implementation work.

Next entry: Session 5: Networking Fundamentals — Part 1.