Would your company detect ransomware before its servers were encrypted? Find out

Do you know how quickly someone in your company would notice an attacker had compromised an employee account and was moving through the network? Minutes, hours, or only when users lost access to files?

This test helps assess whether the organisation can detect and respond to ransomware before servers are encrypted, or merely assumes its tools will work.

Useful insights

• Ransomware usually does not start with encryption. Earlier signs may include account compromise, reconnaissance, privilege escalation and lateral movement.
• An alert is not a handled incident. It must be noticed, connected with other events, assessed and passed into response.
• Monitoring restricted to office hours leaves the organisation without operational coverage at night, on weekends and on holidays.
• MTTD and MTTR matter when the organisation measures them, knows who can make decisions and can promptly activate incident response.
• The result is a simplified self-assessment. It does not replace an audit, exercises or technical validation of detection mechanisms.

Ransomware does not begin with encryption

A ransom note is an incident’s consequence, not its beginning. In a developed attack, the intruder first gains access, explores the environment, escalates privileges and compromises more assets, sometimes copying data. Encryption comes later.

Attacks vary, but the best opportunity to limit impact usually comes before widespread encryption. It requires connecting behaviours that individually may resemble user mistakes or routine administration.

Detecting a security incident therefore requires comprehensive data, detection rules, correlation, human analysis and a procedure for prompt containment.

Expert comment: ‘Server encryption makes an incident obvious to the whole organisation. Security maturity is shown by whether the team can connect earlier, less clear-cut signals and respond before the attack affects the business.’

The self-assessment has ten questions. Award one point for each ‘YES’, but only where the mechanism works, responsibility is assigned and the process has been tested in practice.

Test 1: does someone monitor the environment 24/7?

An overnight alert has value only if someone receives, assesses and can act on it. A notification inbox or dashboard opened in the morning records events but does not provide 24/7 protection.

Question 1. Are security alerts analysed around the clock?

Answer ‘YES’ if round-the-clock coverage includes deciding whether an alert is a false positive, an event to observe or an incident requiring response.

Question 2. Does monitoring include weekends and holidays?

‘YES’ means continuous coverage regardless of the calendar. Analysis that starts only when staff return gives attackers time to develop the attack.

Question 3. Are on-call coverage and escalation clearly defined?

An administrator on call does not by itself create a process. It must be clear who receives the alert, confirms the incident, escalates the case and may act without further approval. In its SOC 24/7 model, VigilHorizon combines monitoring with analysis and response under agreed playbooks.

‘NO’ or ‘DON’T KNOW’ means the signal may be recorded but left unhandled.

Test 2: would you detect lateral movement?

After gaining access, an attacker often expands their reach through further accounts, devices and servers. This stage is lateral movement. Its form varies, but it provides an important detection window before ransomware.

Question 4. Would you detect unusual sign-ins and account use?

‘YES’ requires detection of unusual timing, new devices, repeated failures, changed working patterns or account use across the environment.

Question 5. Would you notice privilege escalation or privileged account abuse?

‘YES’ is justified if permission changes, new administrators, unusual service account use and access to critical assets are logged and covered by detections.

Question 6. Can you connect activity on several devices into one incident?

Connecting a sign-in, an administration tool, a server connection and a privileged account can reveal the attack’s direction. This requires quality telemetry, SIEM/XDR correlation and SOC analysis.

Looking at devices separately provides fragments but may miss the campaign. Log collection alone therefore does not create detection and response capability, as explained in SIEM in the enterprise: why it fails in most cases.

Test 3: does anyone actually analyse the alerts?

If alerts enter one unprioritised queue, critical signals compete with routine events. The problem becomes an inability to distinguish incidents from noise.

Question 7. Are alerts prioritised and classified?

Answer ‘YES’ if priority considers asset significance, user privileges, attack stage and potential business impact.

Question 8. Do you know your MTTD and can you reconstruct the analysis?

MTTD, the average detection time, describes the interval from signals appearing to recognition of the incident. ‘YES’ requires recording alert, analysis, classification and escalation times to identify delays.

Decision quality also matters. VigilHorizon analyses signals from collection and correlation through impact assessment to a documented decision and handover into response.

Test 4: what happens after detection?

Detection does not stop ransomware. If an analyst recognises the threat but does not know who may disconnect a device or block an account, time still favours the attacker.

Question 9. Is it clear who decides on and performs isolation?

‘YES’ means assigned roles, contacts, permissions and approved emergency actions: endpoint isolation, account blocking, connection restrictions and evidence preservation.

Question 10. Is there a practised incident response process?

‘YES’ is justified when the organisation has rehearsed its ransomware playbook, can convene the right people, knows its emergency communication channel and records decisions. The process covers analysis, containment, eradication, recovery and lessons learned.

The complete process is described in Incident Response — responding to a cyberattack step by step. The SOC must work with people able to carry out actions within the organisation.

How should you calculate and interpret the score?

Count ‘YES’ answers. Do not award a point for something planned, incomplete or dependent on one person. Treat ‘DON’T KNOW’ as ‘NO’—uncertainty about the process is itself a risk.

Number of ‘YES’ answers	Interpretation	What it means in practice
0–3	High risk of late detection	The organisation relies mainly on tools, the availability of individual staff members or a response after damage has occurred. An attack may go unnoticed until encryption or a service outage.
4–7	Moderate readiness	Some controls work, but gaps remain in the detection and response chain. The weakest link may be overnight coverage, correlation, escalation or containment.
8–10	Good operational readiness	The organisation has most key elements in place, but should verify them through exercises, detection tests and playbook reviews. A high score does not guarantee that every attack will be stopped.

This is a simplified self-assessment, not a formal audit. It does not test rule quality, log completeness or how procedures work under pressure. An “I DON’T KNOW” answer about overnight analysis, isolation or incident response warrants a full organisational security assessment covering data, detections, roles and decision paths.

Attack stages and detection checkpoints

The map below presents an illustrative, extended scenario. The earlier a signal is interpreted, the smaller the part of the environment that needs to be isolated and recovered.

Stage	Example signals	Who or what should detect them?	Organisational checkpoint
Access	unusual login, malicious process, suspicious remote access	EDR/XDR, identity systems, firewall, SIEM and an analyst	Is telemetry analysed outside business hours?
Privilege escalation	new account, group membership changes, service account use	identity monitoring, EDR, directory logs, SOC	Do privilege changes have an owner and the right priority?
Discovery	host scanning, domain queries, searching for backups	EDR/NDR, SIEM/XDR, behavioural rules	Are events correlated into a single sequence of activity?
Lateral movement	logins on additional hosts, remote commands	EDR/XDR, authentication logs, network, SOC	Can the team establish the scope and isolate devices?
Preparation and possible exfiltration	bulk access, archiving, unusual transfers, backup interference	DLP/NDR, EDR, backup monitoring, SIEM/SOC	Will the organisation protect backups and initiate incident response?
Encryption	mass file changes, service shutdowns, ransom demands	EDR/XDR, file and service monitoring, SOC	Will the response contain the incident and initiate recovery?

EDR may stop some activity, SIEM can correlate data, and backups can support recovery. Someone still needs to assess the context and activate the right playbook.

Two scenarios: the same attack, different outcomes

The scenarios below are hypothetical. They illustrate the impact of monitoring and response without promising a particular outcome.

Scenario A: the incident is discovered after encryption

Overnight, alerts flag an unusual login, an administrative account and connections to servers. They reach the IT team’s inbox, but nobody is actively on duty.

By morning, servers are unavailable and users see encrypted files. No single person is leading the incident, so administrators investigate the cause while trying to determine who may disconnect further segments. The consequences include downtime, uncertainty about the extent of the compromise, backup verification and the risk of earlier data theft. Signals existed, but they never became a managed incident. A similar escalation is illustrated in An incident without a SOC: a realistic attack scenario.

Scenario B: a response during lateral movement

At the second organisation, telemetry is analysed 24/7. An unusual login receives high priority, and a server connection is correlated with the use of an administration tool.

An analyst activates the agreed escalation path. The account is blocked, devices are isolated, and the team establishes the scope and preserves evidence. It still needs to identify the cause and examine the environment, but it responds before mass encryption.

Visibility, context, analyst availability, authority and prepared incident response make the difference. VigilHorizon builds monitoring around these principles: tools provide signals, while people and processes turn them into controlled action.

What most often fails before servers are encrypted?

Gaps usually appear between functions. Individual components exist, but the full chain does not work.

Monitoring has gaps

Alerts are collected around the clock but analysed during business hours. The organisation confuses system availability with staff availability.

Data is incomplete or lacks context

Logs from key systems or context about the user and asset are missing. The analyst sees a symptom but cannot assess its significance.

The team is overwhelmed by alerts

Without detection tuning, classification and correlation, a real threat gets lost among alerts with similar priorities.

Nobody owns the response

If no one has defined who leads an incident and who may take emergency action, responsibility becomes dispersed across the SOC, IT, suppliers and management.

The playbook has not been rehearsed

A procedure may contain outdated contacts, inaccessible emergency accounts or decisions that cannot be implemented. An exercise reveals these issues before a real attack.

Nobody measures time or quality

Without MTTD, escalation time and MTTR, the organisation does not know where it loses time. Metrics do not replace analysis, but they show how the process is developing.

How can you improve your chances of stopping ransomware?

Readiness should be built as a single process.

1. Map critical assets and data. Check whether servers, accounts, applications and backups provide useful telemetry.
2. Provide 24/7 analysis. Define who receives and classifies alerts at any time of day.
3. Build behavioural detections. Cover logins, privileges, reconnaissance, lateral movement, backups and bulk data operations.
4. Add business context. Priority depends on the asset, account and potential impact.
5. Agree escalation paths. The team must know when to isolate a device, block an account and initiate communications.
6. Prepare a ransomware playbook. Define roles, channels, evidence preservation, containment and recovery.
7. Practise. A tabletop exercise tests decisions; a technical test checks signal visibility and whether actions can be carried out.
8. Measure the process. Analyse MTTD and the time taken to classify, escalate and contain incidents.
9. Verify backups. Check separation, identity protection and recoverability. Backups do not replace detection.
10. Assign end-to-end responsibility. One role should oversee the process from the first signal to a safe return to operation.

In the VigilHorizon model, monitoring connects detection tuning, alert analysis, escalation, playbooks and cooperation with the client’s team. The organisation can then assess its ability to contain an incident, rather than simply counting alerts.

Summary

Organisations lose to ransomware not only because they lack tools, but above all when they fail to turn early signals into analysis, decisions and a response before encryption.

If you do not know who analyses alerts overnight, detects lateral movement, isolates a server and initiates incident response, you do not know your readiness. The test highlights gaps, but an answer requires verification of telemetry, rules, responsibilities and performance under pressure.

VigilHorizon can assess readiness and the detection process, and help build SOC 24/7 connected to response. The aim is continuity from signal to controlled action, before ransomware affects the business.

Frequently asked questions (FAQ)

How can ransomware be detected before files are encrypted?​

Unusual logins, privilege escalation, reconnaissance, lateral movement, backup interference and bulk data access must be correlated, followed by a prompt response.

Is EDR enough to protect against ransomware?​

EDR can detect and block some endpoint activity, but it does not provide a complete view of identities, networks, cloud environments and systems. It requires configuration, analysis and response.

Will SIEM automatically detect ransomware?​

SIEM correlates data, but needs the right logs, tuned detections, context and people to analyse the results. It does not guarantee detection of every attack.

Does security monitoring work overnight?​

24/7 protection requires a system, an analyst, escalation and the ability to act. Recording an alert overnight does not mean it has been handled.

Does a 24/7 SOC stop every ransomware attack?​

No. A 24/7 SOC improves the chances of early detection and containment, but requires the right data and cooperation with the organisation.

What is MTTD?​

MTTD is the average time from the first signals to incident detection. It should be analysed alongside classification quality, escalation and response.

How does MTTD differ from MTTR?​

MTTD concerns detection, while MTTR concerns incident resolution or service recovery. The organisation should clearly define both metrics.

How often should ransomware readiness be tested?​

Regularly and after significant changes. Exercises should test decisions and the technical feasibility of detection, isolation and recovery.

Are backups enough if a company is attacked?​

Backups support recovery, but do not stop account compromise, data theft or an attacker’s movement. Backups need protection and testing, and the company still needs detection and incident response.

How can you check whether an organisation is ready?​

Review data, detections, 24/7 monitoring, roles, escalation, permissions, playbooks, backups and exercises. A full assessment tests stated capabilities in practice.

Learn more:

• Incident Response — responding to a cyberattack step by step
• A day in the life of a SOC analyst: inside 24/7 security monitoring
• SIEM in your company — why deployment alone does not improve security
• What is SOC 24/7? How a Security Operations Center works and why monitoring is not enough