Governance, Risk and Compliance (GRC)

Governance can be summarised as “Who is in charge, and what have they decided?” Each pillar feeds the next, and the results come back to the people in charge:

Worked example: a fictional school

A fictional school wants supply teachers, who cover lessons for a day or a week, to be able to see pupil records for the classes they take. Follow the one proposal through the three questions.

1. Governance: who decides? The deputy head is named as the person responsible for pupil records. She decides who may approve access for a supply teacher (the head of department) and that access will be reviewed every half term. Without those decisions, each department would do something different.
2. Risk: what matters most? She lists what could go wrong: a supply teacher sees records for classes they do not teach; the account still works after they have left; records are shared by mistake. The middle one worries her most, because supply teachers come and go every week.
3. Risk: what will we do about it? Access limited to the classes being covered, and an end date set on every supply account so that it switches itself off.
4. Compliance: what must we meet? Data-protection law requires access to personal information to be limited to those who need it. The school’s contract with the supply agency says the same. The school must be able to show that it does this.
5. Evidence. The approval for each account is recorded, and the half-termly review lists every active supply account. A policy that says “access is restricted” would not be evidence. The list of real accounts is.
6. The loop closes. At the first review, one account belonging to a teacher who left three weeks ago is still active. It is removed, and the finding goes back to the deputy head. The cause turns out to be an end date that was never filled in, so the form is changed to make it compulsory.

What the example shows: all three questions were needed. Governance alone would have produced a decision that nobody checked. Compliance alone would have produced a policy. The fault was found, and its cause fixed, because an owner, an assessment and a check were connected. Buying a new tool would not have fixed a form that let the end date be left blank.

Risk and the lessons after it explain how risks are assessed and treated, and what is left afterwards, called residual risk. Assessing Risk explains why technical severity needs business context. Risk acceptance cannot set aside applicable obligations.

Oversight sets direction and checks outcomes. Operational implementation performs the work that puts decisions into practice. A senior leader need not configure every account, but still needs assurance that delegated responsibilities are fulfilled.

This is an introductory allocation, not a universal organisation chart. Roles may be combined, outsourced or named differently. CIO and CISO reporting lines and authority vary. A title does not automatically make its holder the owner of every risk or give them unlimited authority to accept it. Security Roles and Responsibilities looks more closely at the CIO, the CISO or CSO and the ISSO.

Define who performs each task, who approves the decision and where unresolved issues go. Security management cannot discover every operational dependency without cooperation from other departments. This is why people, processes and technology must be considered together.

Silos are boundaries that restrict communication and cooperation. Teams may each fulfil a local responsibility while a shared risk goes unmanaged. A department may optimise document sharing while IT assumes all documents remain in an existing approved service.

Worked example: proposing external document storage

Suppose a department adopts an external service for business documents. The following sequence works through that scenario:

1. State the need and ownership. Explain who needs to collaborate and why the existing service is insufficient. Governance identifies who can approve a supplier and which policies apply.
2. Assess risk before use. The information owner and security team examine information sensitivity, permissions, external sharing, supplier security and business dependency. Consider what happens if access fails or the supplier relationship ends.
3. Check requirements. Relevant specialists examine applicable contractual, organisational and legal requirements. A convenient service is not automatically an acceptable one.
4. Record a decision with conditions. Approval might depend on restricted sharing, controlled account creation and a named service owner. Record unresolved risks, actions, approval authority and review arrangements. If conditions cannot be met, escalate or choose another approach.
5. Communicate and implement. IT configures agreed settings. Staff learn which service is approved, how to invite collaborators, which sharing options to use and where to report a mistake. A policy acknowledgement does not demonstrate that these tasks are understood.
6. Check actual use. Review permissions, exceptions and staff feedback. If people use personal accounts to bypass a difficult process, investigate usability and training gaps as well as individual actions.

The six steps connect an approval made in a meeting to what staff actually do. Security Documentation explains how policy, procedure and evidence support the decision.

Accountability includes those responsible for communicating and implementing policy. If training or support is missing, blaming an individual alone can hide the process failure. Oversight examines both conduct and the system in which people work.

An organisation can pass Cyber Essentials, a UK government-backed scheme that checks five basic technical controls, while malicious software sits undetected on one of its computers. Neither a certificate nor a security operations centre (SOC), a team that watches for attacks around the clock, makes a breach impossible. That does not make assurance worthless: it means knowing what each kind does and does not show. Assurance and the Limits of Penetration Testing develops what different kinds of assurance can show.

The MOT analogy

Passing an MOT demonstrates that the applicable inspection standard was met at that time. It does not promise that no fault will develop later or remove the need for maintenance. Similarly, a security assessment provides assurance within its scope; monitoring and improvement remain necessary.

The coat-and-rain analogy

Deciding whether to take a coat depends on the chance of rain, the consequence of getting wet and the journey’s context. The point extends further: possessing a protective measure is not enough if it does not suit actual conditions. Controls should match the risks faced.

Where the comparisons stop. An MOT has one fixed checklist for every car. Organisations differ far more than cars do, so a security assessment has to say what it covered. And nobody decides about a coat by filling in a form: the analogy shows the kind of thinking, not a method.

The same idea is often shortened to four words, Ad hoc → Defined → Measured → Optimised, with “Defined” covering both the Documented and the Managed stage. Different frameworks use different names; the progression is what matters.

The school’s supply-teacher process shows the stages. Deciding each case as it arises is initial. Writing the approval procedure down is documented. Naming who approves and reviewing every half term is managed. Counting how many accounts the review finds still active after their owners have left is measured. Changing the form so that an end date cannot be missed is the start of optimised.

A high percentage of staff completing a training course is not, by itself, evidence of a mature process. What staff actually do is.

Improvement might simplify a confusing approval step while retaining necessary checks. More documents or tools do not automatically mean greater maturity. The PDCA explanation shows how evidence leads to corrective action and a revised plan.