NOTE: In this series of posts, we revisit recent presentations delivered at MU.SCL and provide additional context around the slide decks shared here. While a written post cannot fully reproduce the depth, examples, and discussion of a live session, it should help readers better understand the topic, the key messages, and the practical points behind the slides.

Cyber security does not fail because organisations lack frameworks, standards or good advice. In fact, the opposite is often true. There are more frameworks, control catalogues, maturity models, vendor recommendations, regulatory expectations and best-practice documents than most organisations can realistically absorb. The real problem is not the lack of guidance. The problem is deciding what matters most, in the context of a real organisation, with real constraints.

Most companies do not have unlimited budget, unlimited headcount, unlimited specialist skills or the luxury of stopping the business while security is being improved. They operate with legacy systems, cloud services, SaaS platforms, suppliers, remote access, business pressure and regulatory obligations. In that environment, the challenge is not to produce the longest possible security roadmap. The challenge is to identify the controls that can realistically be implemented, sustained and measured over time.

WHY ONLY 20 CONTROLS?

The proposed 20 control set is intentionally small enough to manage, but broad enough to reduce the main attack paths faced by many organisations.
We used four filters to decide what makes the list:

Is the risk likely?

Is the control affordable?

Is it operable by the team you actually have?

Can you measure whether it is working?

Indeed, a control that is technically correct but nobody can run month after month is not a control, it's a "tick in a box".

The starting point is simple: security should be customised to the organisation. This does not mean ignoring best practice or lowering standards. It means using established references such as CIS, NIST CSF, CISA or NCSC guidance, but adapting them to the organisation's risk profile, operating model and actual capacity to execute. A company that blindly copies a large-enterprise security programme may end up with a roadmap that looks impressive on paper but fails in practice:

Controls are assigned to nobody

Exceptions are not tracked

Backups are assumed to work but never restored

Suppliers are assessed once and then forgotten

Alerts are generated but not reviewed

MFA is enabled in some places but bypassed in others.

Over time, the control environment often decays.
How many of the issue raised above are true within your organisation?

The threat model also needs to remain grounded. For many organisations, the most likely attacks are not state sponsored or cutting edge, the attacker does not need to be highly sophisticated as most victim's organisation simply provides the opportunity through weak operating discipline: A dormant account, an exposed remote access service, an unpatched system, a supplier with excessive access, a missing backup restore test or a mailbox forwarding rule can be enough to create a serious incident.

As such, the first objective should be to reduce the most likely and most damaging attack paths. The goal does always have to be "perfect" security (although in an AI world there is an argument to be made... maybe a topic for a future post!). The goal is to make compromise harder, limit the blast radius when compromise happens, detect the signs that matter and recover before the incident becomes existential.

The 20 controls are grouped around four practical outcomes: Govern, Protect, Identify and Detect, then Response and Recover.

The Governance controls come first because security without ownership rarely works.

1. Own the risk
Someone needs to own cyber risk. It should be visible at management level, supported by a short risk register that records the top risks, the owner, the treatment decision and the review date. This does not need to be complicated, but it does need to exist.

2. Manage third-party security
Third-party security also needs to be treated as part of the organisation’s attack surface. Many businesses now depend heavily on IT providers, SaaS platforms, outsourced services, payment providers, cloud platforms and specialist suppliers. If those providers have access to systems or data, they are part of the risk picture.

3. Maintain an asset inventory
Asset inventory is another basic control that is often underestimated. An organisation cannot protect what it does not know exists. A useful inventory should identify users, devices, servers, cloud services, SaaS platforms, critical suppliers, unsupported systems and business-critical assets.

4. Identify critical data and business processes
Security decisions should be informed by what would actually hurt the business if lost, exposed or unavailable. For many organisations, this includes cash collection, finance, payroll, customer data, contracts, operational systems, core SaaS platforms and identity infrastructure.

The Protection controls then address the most common paths to compromise.

5. Enable multi-factor authentication
Multi-factor authentication remains one of the most important controls because it helps stop password compromise from becoming account takeover. It should cover email, administrator accounts, cloud platforms, VPN access and finance systems. Where possible, administrators and other high-risk users should use phishing-resistant MFA.

6. Apply least privilege
Compromise should not automatically become full control of the environment. Daily user accounts should be separated from administrator accounts. Local administrator rights should be removed from normal users where possible. Privileged accounts should be reviewed regularly, especially after staff changes, supplier changes or incidents.

7. Use password management
Password management is another example of a control that must be realistic. Telling users to create strong, unique passwords everywhere without giving them a usable password manager is not a strategy. Shared secrets should not live in spreadsheets, emails or chat messages.

8. Define a device baseline
Every laptop and phone should have a minimum safe configuration: supported operating system, screen lock, encryption, automatic updates and a clear lost-device process.

9. Patch the obvious first
Internet-facing systems should be patched first, followed by endpoints, browsers and office applications. Known vulnerabilities remain one of the most avoidable paths into an organisation.

10. Use endpoint protection
Commodity malware and ransomware should not be easy to execute. Endpoint protection or EDR should be deployed, configured and monitored, not simply installed.

11. Protect email and web channels
Email remains one of the main attack surfaces. Filtering, domain protection, attachment controls, URL protection and clear reporting routes all help reduce the likelihood that a single malicious message becomes a business incident.

12. Train for practical scenarios
Awareness should not be generic. Staff should understand the situations they are likely to face: phishing, suspicious MFA prompts, payment fraud, invoice redirection, malicious attachments, lost devices and urgent requests that bypass normal process.

13. Protect backups
Backups deserve specific attention because many organisations only discover during an incident that their recovery assumptions were wrong. Backups should be protected, monitored and tested. A backup that has never been restored is not evidence of resilience. It is only an assumption.

14. Secure cloud and SaaS basics
Cloud and SaaS baselines are now essential because many organisations no longer operate from a traditional internal network perimeter. Identity settings, administrator roles, external sharing, logging, retention, recovery and conditional access settings should be reviewed for the platforms the business actually uses.

15. Establish a network baseline
Organisations should know what is exposed, what remote access exists, which services are reachable from the internet and where segmentation is required. This does not need to be over-engineered, but it does need to be understood.

Detection does not need to start with an overly complex SOC model. It should start with the signals that matter.

16. Configure logging and alerting
Many organisations should first focus on high-value alerts that indicate meaningful risk: suspicious sign-ins, MFA changes, administrator activity, mailbox forwarding rules, endpoint protection failures, backup failures, exposed services and security tool tampering.

17. Monitor external exposure
External exposure should be checked regularly because forgotten internet-facing systems remain a common source of avoidable compromise. Remote access, exposed services, expired certificates, misconfigured cloud assets and vulnerable systems should not be discovered by an attacker first.

Response and Recovery complete the control set.

18. Prepare incident response
Incident response should not be a large document that nobody uses. It should define who does what, who makes decisions, who contacts legal advisers, who speaks to regulators, who communicates with customers, who handles technical containment and how decisions are recorded.

19. Protect data
Data protection is not only a compliance issue. Organisations should understand where sensitive data is stored, who can access it, how long it is retained, how it is protected and what notification obligations may apply if it is exposed.

20. Measure and improve
Security must be measured and improved. This does not mean producing long technical reports. It means selecting a small number of indicators that management can understand and that the security team can evidence: MFA coverage, privileged accounts, unresolved critical vulnerabilities, backup restore tests, endpoint coverage, open high-risk supplier issues, incident response exercises and overdue risk treatments.

A ROADMAP TO SUCCESS

To implement those controls, a realistic roadmap is needed. It should start with the most urgent and achievable actions.
In the first 30 days, the organisation should assign a cyber risk owner, create a short risk register, enable MFA on the most important systems, identify critical assets and suppliers, confirm backup coverage and create a basic incident contact list.
This is not the full programme, but it establishes ownership and reduces obvious exposure.

Between 30 and 90 days, the focus should move to strengthening the operating baseline. This includes removing unnecessary admin rights, addressing dormant accounts, patching internet-facing systems, deploying or tuning endpoint protection, improving email protection, reviewing supplier access and testing a simple incident scenario such as ransomware or business email compromise.

Over the following months, the organisation should mature the controls into a repeatable operating model. That means monthly evidence, regular management review, tested recovery, improved data protection, better logging, clearer supplier obligations and more disciplined exception management. At that stage, the discussion can also become more strategic: whether the organisation needs managed detection and response, stronger privileged access management, enhanced cloud security, more formal governance or external assurance.

The key point is that good cyber security does not always start with expensive technology. It starts with ownership, prioritisation and discipline.
Most organisations do not need more complexity as their starting point. They need a small number of controls that are implemented properly, reviewed regularly and improved with evidence.

That is what "controls that matter" means in practice, and if your current security programme is a long document nobody operates against, it is worth asking what should be your twenty controls.