The question that has an answer
"Are we protected against ransomware" cannot be answered, because nothing observable corresponds to it. The version that can be answered is: which step of the attack does each of our controls deny, and has anyone verified that it holds under test?
That distinction is the whole article. A control that exists in a policy and a control that has been exercised against a real attempt are different objects. Multi-factor authentication is the clearest case. It is declared everywhere. It is bypassed routinely — not by defeating the second factor, but by stealing what the second factor produced.
How they get in
Four useful paths to examine are identity compromise, exploitation of exposed services, supplier access and phishing. They overlap; this is an assessment structure, not a statistical ranking.
Identities and sessions. A working password or reusable session token can give an attacker access without exploiting the target application. MFA is valuable, but phishing resistance and protection of an already issued session are different properties. Check MFA, token replay and consent against the applications you use.
Exposed services. Keep an inventory of public-facing remote-access gateways and applications, their owners, versions and emergency patch process. A public VPN gateway and its administrative interface are different surfaces: protect management access separately. Prioritise remediation using exposure, exploitation evidence and business impact.
Supplier access. Review standing support accounts, remote assistance tools and integrations. They may already be inside your identity policy, or may be exceptions; establish which. Require named ownership, appropriate privileges and a tested way to revoke access. The supplier-to-a-bank article explains the other side of those expectations.
Phishing. Lures can target credentials, application consent and recovery procedures as well as malicious attachments. Endpoint and email protection can prevent parts of this chain, but cannot be assumed to cover every identity path. Domain authentication is one complementary measure.
ENISA’s Threat Landscape 2025 covers a broad incident dataset, not just ransomware. Its findings should not be presented as ransomware-only percentages. Our 2024 research publication on ransomware vectors is a separate research source; a local assessment still needs evidence from your environment.
Double and multi-extortion: what a payment buys
Attackers may combine encryption, data theft, publication threats and pressure on customers. Restoration can reduce the impact of encryption while leaving the disclosure problem unresolved.
Payment guarantees neither a usable decryption tool nor deletion of stolen copies. It does not automatically remove reporting or contractual duties. Assess the GDPR risk threshold, NIS2 significance and DORA major-incident criteria separately; the incident reporting guide includes the different deadlines and exceptions.
The ICO and NCSC’s July 2022 letter states the UK position that payment is not a data-protection obligation and is not treated as mitigation in enforcement. Do not turn that into a claim about every EU authority. Any payment decision also needs case-specific legal and sanctions analysis.
A promise from an extortionist is not verifiable assurance about every copy of the data. Build recovery, communications and evidence preservation around that uncertainty.
Five controls, ranked by what they break
Prioritise these areas against your architecture and business dependencies. None is a universal barrier.
| Control area | What it can reduce | What still needs attention |
|---|---|---|
| Phishing-resistant authentication and session controls | Credential relay and supported token replay paths | Endpoint compromise, unsupported sessions, consent and recovery |
| Protected management access and timely patching | Exposure of administrative services and known vulnerabilities | Public gateway risk, stolen authorised access and new flaws |
| Separate administrative identities and limited privileges | Escalation and the spread of compromise | Data already accessible to the first compromised account |
| Isolated or immutable backups and tested restoration | Operational impact of destruction or encryption | Exfiltrated data, identity dependencies and untested services |
| Owned and scoped supplier access | Unnecessary access and prolonged third-party exposure | Compromise inside a trusted product or an authorised session |
A restore test establishes a capability within its tested scope. A file restore does not prove recovery after losing the identity platform and production estate together. Use the ransomware recovery-readiness guide to define the scenario, dependencies and acceptance criteria.
Endpoint prevention, detection, monitoring and training complement these measures. Some can prevent an attack step; others shorten discovery or response. Evaluate the actual configuration and evidence rather than assigning an entire product category to prevention or detection.
What to do first
- Inventory internet entry points and supplier access, with an owner for each.
- Review standing administrative rights. Investigate unowned accounts, then agree remediation after checking dependencies and recovery.
- Test session revocation with an authorised test account and an agreed scope. Measure access across relevant applications.
- Run a restore drill that includes identity and service dependencies. Record time to a usable business service, not only completion of a copy job.
- Record regulatory and contractual reporting routes, decision-makers and deputies.
Choose the next improvement from the largest demonstrated exposure. A successful test is evidence of that scenario, not a guarantee against every ransomware operator.
The boundary
This does not tell you whether paying would be lawful in your case. Sanctions screening of the recipient and the legal analysis belong with counsel, not with an engineer. It also does not address industrial control environments, where restore assumptions differ in kind.
Whether you are in scope at all, and under which regime, is a separate question with a real answer: start with the difference between DORA and NIS2. If you need the controls above written up as evidence a supervisor or a client can read, that is what an evidence pack is for.
A small cloud-only organisation may have a simpler recovery scope, but still needs to verify identities, retained data and provider dependencies.
If you want these five controls implemented and verified in your environment rather than described, that is the practical improvements engagement.
Note. General information, not legal advice. What applies depends on the specific entity, its activity, licence, size, group structure and the national implementation.