Skip to content

46 β€” Risk, Governance and Compliance

Level: Intermediate Β· Time: ~22 min Β· Prerequisites: Lesson 45 β€” Incident Response Playbooks for Small Teams


Why this matters

Everything in this course so far has been technical, and the people who approve your budget do not speak that language. Ask for money for "an EDR agent, a SIEM and MFA everywhere" and you will get a patient nod and no decision; describe the invoice-fraud incident that would cost the business its quarter, name the control that prevents it, and you get a decision. The gap is not intelligence on either side β€” it is vocabulary, and this lesson builds the bridge. It also covers the part of security that outlives any tool: who owns what, what has been decided, and what happens when the same question is asked again in a year. Governance is the cheapest control you will ever buy, because a decision made once prevents an incident repeatedly.


The mental model: findings, decisions and consequences

Technical work produces findings. Business decisions need risk. The translation is mechanical once you see the shape of it:

What you observed (technical) What the business hears What it needs instead
"port 3389 is exposed to the internet" nothing actionable "this is how ransomware gets in; closing it removes one route and breaks two off-site workflows we can replace"
"we have no MFA on the finance mailbox" an acronym "one stolen password becomes a fraudulent payment; the invoice-fraud playbook assumes this control exists"
"the backup has not been restore-tested" an administrivia item "if ransomware lands tonight, we either lose a day or we lose the last four years of accounts; the test takes four hours"

A finding becomes a risk statement when it has four parts: the asset, the event, the consequence, and the reason it is plausible. "The finance mailbox (asset) could be taken over by a phishing password (event), which would let an attacker send and intercept invoices (consequence), because there is no second factor and staff handle payment changes by email (plausible)." That sentence can be approved, funded, scheduled or accepted β€” and it survives the departure of the person who wrote it.

[!IMPORTANT] Two rules make everything else in this lesson work. One owner per risk, named as a person rather than a team β€” a risk owned by "IT" is owned by nobody. And a review date on every entry, because an accepted risk is a decision with an expiry, not a permanent state of the world.


The vocabulary, in one table

Term What it means A small example
Asset anything worth protecting: data, systems, money, reputation, the ability to keep trading the customer database, the accounting system, the company's name
Threat who or what could cause harm a criminal group running ransomware, a careless insider, a flood
Vulnerability the weakness the threat exploits an unpatched server, no second factor, a process nobody reviews
Likelihood how plausible it is in your organisation, in a stated period "likely within twelve months", rated on your five-point scale
Impact what it costs if it happens: money, downtime, obligation, trust a week of lost invoicing, a reportable breach, a lost contract
Inherent risk the level before any control is applied an exposed remote-desktop service with no protection
Residual risk the level after your controls, which is the number you actually decide about the same service behind a VPN with a second factor
Risk appetite how much risk the organisation is willing to carry, stated in words by leadership "we do not accept any risk of unauthorised payments; we accept short email outages"
Risk register the list of risks, each with owner, treatment, date and status a spreadsheet with ten rows is enough to start
Control the thing that changes likelihood or impact a second factor, a backup, a policy with a consequence, a training habit

The four ways to treat a risk

Treatment What it means A real decision for a small organisation
Avoid stop doing the risky thing entirely stop accepting card payments on your own site and use a hosted checkout, so the card data never touches you
Reduce keep doing it, with controls that lower likelihood or impact keep remote access, but require a second factor and a managed device
Transfer move the financial consequence to somebody else cyber insurance for the recovery cost; a contract that puts breach costs on the supplier who lost the data
Accept decide consciously to live with it, with an owner and a review date keep an old internal reporting server that holds no personal data and cannot reach anything else

"Accept" is a legitimate answer, and documenting it is what distinguishes a professional organisation from a hopeful one. What is not legitimate is accepting a risk by never having considered it.


How to run a risk assessment without a consultancy

Five steps, an afternoon, a spreadsheet and the right four people in the room (someone who knows the money, someone who knows the systems, someone who owns operations, and whoever can authorise spending).

  1. List the assets and what hurts if each is lost. Not every laptop β€” the categories: email, finance system, customer records, the website, the file share, the phones. For each, write one line on the harm: cannot invoice, cannot deliver, must notify customers, lose the ability to trade.
  2. Identify the threats that plausibly apply. Use the ten risks below as a starter list, then delete what genuinely does not apply and add what the local context brings β€” a cash-handling shop, a workshop with physical risk, a business with one key supplier.
  3. Rate likelihood and impact on a simple five-by-five scale. Write the scale down and use the same words every time: likelihood from rare to almost certain, impact from minor to severe. The exact numbers matter far less than everyone using the same ruler, and the exercise of arguing about the rating is where most of the value sits.
  4. Decide the treatment, and name who pays for it. Avoid, reduce, transfer or accept, with the cost and effort written down. Sequence by risk level and by how long the fix takes: the second factor and the backup test are usually the first two rows.
  5. Record an owner and a review date. One person, one date, one status. Then put the register on the agenda of the quarterly meeting, or it becomes an artefact nobody opens β€” which is how most risk registers die.

Worked example: the finance mailbox

Step Before treatment After treatment
Asset and harm the finance mailbox; fraudulent payments and intercepted invoices unchanged
Threat phishing for the password, then a mailbox rule to hide the replies unchanged, and it still applies
Vulnerability password only; bank-detail changes confirmed by email reply; no review of mailbox rules second factor, callback rule for bank changes, mailbox rules checked monthly
Likelihood high β€” invoices and payment changes arrive by email every week low β€” the password alone is no longer usable by the attacker
Impact severe β€” an average invoice is recoverable rarely, and reputation suffers moderate β€” an attempt may still arrive, but it needs a telephone call to succeed
Inherent risk high β€”
Residual risk β€” low, and accepted by the managing director
Treatment β€” reduce (second factor and callback rule); transfer (cyber insurance for the residual)
Owner and review β€” finance director; review in six months, or immediately after any attempt

That single table is the whole discipline: a technical control, an operational rule, a business decision, a named owner and a date. Nothing in it needed a consultant or a framework.

The ten risks almost every small organisation carries

Risk Suggested treatment
Email account compromise and invoice fraud second factor on every mailbox, the callback rule for bank-detail changes, mailbox-rule checks
Ransomware tested backups that are offline or immutable, patch cadence, allowlisting, an isolation procedure from Lesson 45
Lost or stolen laptop or phone enforced full-disk encryption, screen lock, remote wipe, nothing sensitive outside the vault
Compromised or reused credentials a password manager, second factors, no local admin reuse, breach-password screening
Unpatched internet-facing service a list of everything reachable from outside, patching within a stated window, remove what is not needed
Insider or departing-employee data theft least privilege, joiner-mover-leaver process, logging, DLP where it is proportionate, preserve before confronting
Backup failure discovered at the wrong moment restore tests on a schedule, monitoring that alerts on a missed backup, a copy offline and out of reach
Third-party provider breach a supplier questionnaire and contract clauses before the incident, least privilege for integrations, exit plan
Accidental exposure of personal data a data-handling rule, restricted sharing defaults, and a short procedure for what to do when somebody gets it wrong
Service unavailability know your recovery time and recovery point, agree provider expectations in writing, rehearse the outage

For each row, the honest question is not "do we have the control?" but "who would notice if it stopped working?" β€” because that is the difference between a control and a belief.


Frameworks, and when each is worth the effort

Frameworks are mostly shared vocabulary and a checklist you did not have to invent. None of them stops an attack; they help you organise the work, and they let you answer a customer or an insurer who asks "what are you doing about security?".

Framework What it is Who actually needs it Realistic effort for a small organisation
NIST Cybersecurity Framework (CSF) a plain structure in five functions β€” Identify, Protect, Detect, Respond, Recover (the 2024 revision adds Govern as a sixth) anyone who wants a programme structure without a certificate low to start; use it as an agenda and a gap list, no auditor involved
CIS Critical Security Controls a prioritised list of 18 control groups; Implementation Group 1 is the roughly 56 safeguards that apply to almost everybody the best fit for what this course taught, and for a first plan low; read IG1, tick what you have, plan what you do not
ISO/IEC 27001 a certifiable management system for information security, with an Annex A of controls (93 controls in four themes in the 2022 revision) organisations whose customers or tenders demand it high β€” policy, internal audit, evidence, an accredited certification body, stage 1 and stage 2 audits, annual surveillance and recertification every three years
SOC 2 an attestation report against the AICPA Trust Services Criteria, produced by an independent auditor; Type I covers a point in time, Type II a period, commonly six to twelve months service providers whose customers ask them for it high β€” the cost is in the evidence and the observation window, not the audit day
PCI DSS the card-payment obligation, at version 4.x, applying to any organisation that stores, processes or transmits cardholder data anyone handling card data directly; the simplest way to shrink the obligation is to let a hosted provider handle it moderate to high; the self-assessment questionnaire you use depends on how you handle cards
European regulation data-protection obligations for personal data, plus sector rules for critical and regulated operators almost everyone holds personal data; the sector rules apply if you are in scope ongoing β€” obligations, not a project

On the European landscape, described generally and not as legal advice. Data-protection law governs personal data: the GDPR has applied since May 2018, requires you to know what you hold and why, imposes notification duties with short deadlines on breaches that risk individuals, and in some cases requires a data-protection officer and a formal impact assessment. Alongside it, the NIS2 Directive raises obligations β€” including management accountability, supply-chain security and rapid incident reporting with deadlines measured in hours and days β€” for organisations in its listed sectors, as transposed into national law. Sector regimes exist as well, such as the resilience rules for financial entities. Whether any of this binds your organisation depends on your sector, your size and your customers: take advice rather than interpreting a paragraph in a course.

The honest guidance. Start with CIS Implementation Group 1 as your work list and NIST CSF as your reporting structure. Reach for ISO 27001 or SOC 2 when a customer, a tender or a regulator requires it β€” not before, because the effort is real and it competes with the patching you have not finished. Being genuinely good at the controls beats being certified at them, and a certificate without the controls is the most expensive kind of theatre.


Governance that actually works in a small organisation

A policy is not a document; it is a decision with a name on it. One page that people follow beats thirty pages that nobody has opened, and the difference is almost always three things: it is short, it has an owner, and it has a consequence.

The policy set worth having β€” nine documents, each one or two pages:

Policy The one thing it settles
Acceptable use what work devices and accounts may be used for, and that monitoring may occur
Access and second factors who gets access, how it is requested, how it is removed, and that a second factor is required
Incident response the playbooks, the roles, the decision authority and the reporting route
Backup and restore what is backed up, how often, where the copy lives, who tests the restore and how often
Remote access how staff and suppliers connect, with which device and which factor
Joining and leaving the checklist for day one and the last day, including what is revoked and in what order
Supplier access what a third party may hold, how it is authenticated, and what happens at the end of the contract
Data handling what may be stored where, what may leave the building, and what needs care
Exceptions how someone asks for a deviation, and who may approve it β€” the pressure valve that keeps the rest honest

Who approves and how often: the person who carries the business consequence β€” the managing director, the finance director β€” not the IT provider, and not the security lead alone. Review annually at minimum, and immediately when a system, a supplier or a named owner changes. Record the approval: date, approver, version. That record is what turns a document into a decision.

Awareness that changes behaviour

  • Short and frequent beats annual and long. A five-minute item each month, with a real example from your own inbox, outperforms a one-hour module every February.
  • Role-specific beats generic. Finance needs the callback rule and invoice fraud; operations needs the USB and physical rules; everyone needs how to report.
  • Report fast, report safe, and never punished. The metric to celebrate is the number of suspicious messages reported, not the number of failures. A blamed reporter becomes a silent one.
  • Run simulations to learn, not to catch people. Say what the exercise is for, avoid selecting repeat offenders, and never publish names. If the simulation produces embarrassment, you have bought a year of unreported incidents.
  • Measure reporting rate, not click rate. Click rate tells you what the phishing looked like; reporting rate tells you whether your culture works.

Supplier governance

Ask every supplier who holds access or data, in writing, before the contract, and again at renewal:

  1. What access do you hold to our systems, and what data do you hold about us?
  2. How is that access authenticated β€” named accounts, second factors, no shared logins?
  3. Will you share the relevant logs, or tell us what happened in our environment?
  4. How would you tell us about a breach, to whom, and within what time?
  5. Who are your own sub-processors, and where is our data stored?
  6. What happens at the end of the contract β€” what is deleted, when, and can you prove it?

Contract clauses to ask for: a breach notification deadline shorter than your own regulatory clock, the right to audit or receive an audit report, a named security contact, deletion of your data at termination, and clarity on who pays what after an incident. Review cadence: a light annual review of the critical few, a full questionnaire at contract signature and at renewal, and an immediate review after any incident or ownership change.


Metrics a decision-maker cares about, and the ones to avoid

Metric What good looks like How to collect it
Patch coverage a stated percentage of critical and high-severity fixes applied inside your patching window vulnerability scans and management reports, by severity, over time
Second-factor coverage every account that can send mail, move money, or administer something identity provider report of accounts without a second factor
Backup restore test recency a documented successful restore within the last quarter the test record: date, what was restored, how long it took
Mean time to remediate, by severity critical fixes in days, not months; the trend falling ticket timestamps from detection to verified fix
Number of unowned accounts near zero: every account has a named human owner and a purpose access review, run quarterly and taken seriously
Mean time to detect and respond known and improving, measured on real incidents and exercises incident log timestamps, including the rehearsals from Lesson 45

Anti-metrics to avoid: raw vulnerability counts (they measure scanning activity, not risk), "percentage secure" (it means nothing and invites argument), anything nobody can act on, and anything that rewards hiding problems. A metric that punishes honesty stops being reported within one cycle.

On MTTR, be precise in writing: mean time to repair, to respond and to remediate are three different numbers. Define which one you mean on the report itself, or the trend line will be argued about instead of acted on.


The honest economics

  • Downtime has a price you can estimate. Take a day of revenue, add the staff hours, add the customer goodwill, add any penalty in a contract. A small business is usually surprised by the number, and that number is what turns "we cannot afford the second factor" into "we cannot afford another day of this".
  • Insurance transfers a risk; it does not remove it. It pays defined costs after a defined event, within limits and after an excess, and it does not restore reputations, customers or data. Read it as a financial backstop for the worst case, not as a control.
  • Insurers now ask for the basics before they will cover you. Second factors on remote access and privileged accounts, endpoint detection, working and tested backups, patch management, an incident response capability β€” often with specific requirements about how quickly an incident is reported to them and which vendors may be used. Cyber insurance is therefore a governance instrument: it forces the same priorities this course teaches.
  • Governance is the cheapest control available. A one-page decision, approved once, with a named owner, prevents an incident repeatedly at near-zero marginal cost. Compare that with an incident: the engineering hours, the lost trading days, the customer conversation, the regulatory analysis and the premium increase afterwards.
  • Do not let compliance define your ceiling. Being compliant is a floor set by somebody else's rulebook. The invoice-fraud attempt that arrives on Thursday does not check your certificate status.

A starter governance package for a twenty-person company

Six documents, no more:

  1. One-page acceptable use and monitoring notice β€” signed at joining, referenced in the contract.
  2. Access and second-factor policy with the joiner-mover-leaver checklist attached.
  3. Incident response playbooks β€” the three most likely: ransomware, business email compromise, lost device.
  4. Backup and restore policy with the restore-test record behind it.
  5. Supplier register β€” who holds access or data, the questionnaire answers, the contract renewal date.
  6. Risk register β€” ten rows, each with an owner, a treatment and a review date.

Quarterly review agenda, one hour: the risk register (five minutes per changed row), the metrics table above, incidents and near misses since the last meeting including phishing reports, supplier changes, and the single control that is behind schedule. End with dated actions and names.

One-page risk decision record β€” five fields, filled in whenever something material is decided:

Field What goes in it
Risk asset, event, consequence, why it is plausible
Rating likelihood and impact on your five-point scale, with inherent and residual
Treatment avoid, reduce, transfer or accept, with the cost and what it breaks
Owner one named person, plus the decision authority who approved it
Review date when this is looked at again, and what would trigger an earlier review

That template is the whole governance apparatus in miniature. A four-person company with these six documents and one hour a quarter is, in practice, better governed than many larger organisations β€” because the decisions are written down, owned and revisited.


Attack it / Defend it

The attack How it works The control that stops it
Budget denial security asks for tools in technical language and gets no decision risk statements with asset, event, consequence and owner
Compliance theatre the certificate is bought, the patching is not done CIS IG1 as the work list, and metrics that measure the controls
Unowned risk a register row owned by "IT" that nobody ever revisits one named owner and a review date on every entry
Ignored policy a long document nobody reads and nobody enforces one-page policies with a named approver and a consequence
Punished reporting a user who reports a mistake is blamed, so the next one stays silent report fast and safe, celebrate reporting, measure reporting rate
Weaponised awareness simulations used to shame staff, producing silence simulations run to learn, with no names published
Silent supplier a third party is breached and tells you late or never notification deadline in the contract, a named contact, an exit plan
Metric gaming "percentage secure" improves while the real risk grows a small set of actionable metrics with a defined collection method
Insurance surprise a claim is refused because the required controls were never in place read the policy conditions as a control list, before the incident
Register rot the risk register is written once and never reviewed a quarterly agenda item, with five minutes per changed row

Key takeaways

  • Translate every finding into an asset, an event, a consequence and a reason it is plausible. That sentence is what gets a decision, a budget and a date.
  • Run the assessment yourself: list assets, name threats, rate likelihood and impact, choose a treatment, record an owner and a review date. Five steps and an afternoon, no consultancy required.
  • Start with CIS Implementation Group 1 as the work list and NIST CSF as the reporting structure. Chase ISO 27001 or SOC 2 when a customer or a regulator requires it, not before.
  • Governance is the cheapest control you own. A one-page policy with a named owner and a consequence prevents an incident repeatedly; a thirty-page template prevents nothing.
  • Insurance is risk transfer, not risk removal, and it now requires the basics β€” second factors, endpoint detection, tested backups, patch management β€” as a condition of cover.

Check yourself

  1. Turn "we have an unpatched VPN appliance facing the internet" into a risk statement with all four parts, in one sentence a managing director would accept.
  2. Name the four treatment options and give a real decision for each from your own organisation or a fictional twenty-person one.
  3. What is the difference between inherent and residual risk, and which one is the decision actually about?
  4. A customer asks whether you are ISO 27001 certified. What do you say, and what do you do next?
  5. Write two metrics you would put in front of a decision-maker and one anti-metric you would remove from the report, with the reason.

Next

Lesson 47 β€” Your Career Path β€” From Zero to Hired