Firewall, Antivirus and Backup Are Necessary.
They Are Not Enough.

“We have a firewall, antivirus and backups” is a reasonable starting point for a cybersecurity discussion. Those investments help reduce exposure, prevent and detect threats, and restore affected systems. They remain essential when your organisation prepares for ransomware or another serious intrusion.

The statement becomes less useful when it is offered as the complete answer. It does not tell the executive team which connections an attacker could use after compromising an account, what an endpoint tool would stop, or whether an essential service could be restored from the available copies.

Each of those questions needs evidence about coverage, configuration and the result of a defined test. A list of installed controls describes your investment; the next step is to establish the capabilities that investment has delivered.

Firewall, antivirus and backup gave boards and IT teams a practical way to organise security spending: restrict access, prevent harmful activity and retain a way to restore what was lost. They also provided visible evidence that important responsibilities had been addressed.

The problem arises when the existence of those provisions ends the enquiry. A deployed firewall may have broad exceptions for administrators or suppliers. An endpoint tool may cover most workstations but have different capabilities on servers. A backup service may report successful jobs without a recent restoration of the business service that depends on them.

Those are questions about the way your environment is operated. Answering them can confirm that existing measures work, expose a configuration gap or identify a capability that needs to be added. The purpose is to find the actual boundary of protection.

The practical question is what your current measures would do with that access. An accepted login might still be constrained by internal network rules, limited permissions or endpoint protection. Where those safeguards are missing, bypassed or excluded, the same account may be able to reach additional servers or sensitive repositories.

Your review therefore needs to follow the permitted action far enough to identify where it would be blocked, detected or interrupted. Successful authentication alone cannot answer that question.

A firewall can enforce rules about traffic entering, leaving or moving between parts of your environment. Depending on its deployment and configuration, it can inspect internal traffic and help limit movement between systems as well as protect the external boundary.

The presence of a firewall does not establish which of those functions is being applied to a particular connection. An administrative or supplier route may be deliberately allowed because an important service depends on it. If the account using that route is compromised, the incident team needs to know which restrictions still apply and which further destinations remain reachable.

The useful evidence is the relevant rule, the systems it covers and an observed result. For example, can a compromised support account connect from its approved server to a backup management console? If the answer is no, the test should show the restriction working. If the answer is yes, your team can examine whether that access is required and how it is constrained.

Antivirus and endpoint detection and response tools can do more than recognise known malicious files. Depending on the product, supported system and configuration, they can detect suspicious behaviour, block execution, quarantine files or isolate devices. Existing endpoint response capability deserves to be established as part of the assessment of your environment.

A licence or deployment record, however, does not show that every relevant server is covered, that the right response is enabled or that it can operate through the access path used in a particular attack. The misuse of a legitimate remote-access tool or script also needs to be evaluated in context.

Ask your team to distinguish what was detected from what was stopped. A test record should identify the activity, the affected system, the response and whether that response was automatic or required a person. Where approval was needed, the elapsed time and the available permissions are part of the result.

The question is how the deployed capability behaves in the scenario your organisation needs to handle. The detailed design of an alert-to-action response is a separate enquiry.

A completed backup job is evidence that a defined copying process ran. A successful restoration demonstrates more, but only for the data, infrastructure and dependencies included in that exercise. Neither result should be extended beyond its tested scope.

For an essential service, your recovery team needs to establish whether the copies are usable, whether the required accounts and management systems remain available, and whether restoration can meet the operational requirement. An attacker’s access to backup administration is a further condition to examine.

The next security discussion can start with the three pillars and then ask for a result. A compact evidence review makes the distinction practical:

Every result needs a date, a defined scope and an owner for any unresolved finding. Changes to access, infrastructure or response settings may also change what the earlier test establishes. A useful assurance programme keeps that evidence current enough to support the next decision.

The same discipline applies to broader questions about lateral movement, data theft and continuity. Select the capability to be examined and agree a suitable validation method. A file-encryption test cannot demonstrate all of them.

Our contribution is to add specific containment capabilities alongside your existing measures. Ransomware Containment is our platform: it agentlessly monitors file activity in the protected data environment and isolates the responsible user, session or device when illegitimate encryption begins.

Additional Server Intrusion Protection (SIP) and Virtual Server Protection (VSP) features run on the platform. SIP detects and contains compromised server access, while VSP protects supported hypervisor environments against attacks directed at that layer. Their relevance depends on the systems and attack activity your organisation needs to address.

For your team, the decision starts with the requirement and the evidence already available. Where active encryption remains a concern, the assessment can show the effect of RC within an agreed test scope. Server intrusion, virtual infrastructure, data-exfiltration risks and recovery dependencies need their own technical discussion and appropriately scoped validation.

Our remote ransomware resilience assessment examines one defined capability. In an agreed, isolated test environment, we run controlled file-encryption scenarios with your existing security controls left active, first without Ransomware Containment enabled and then with it enabled.

The comparison provides an observable result for active encryption within that scope. During the session, we can explain the additional features like lateral-movement interruption, data-exfiltration prevention, and discuss broader requirements separately.

Firewall, antivirus and backup belong in the security model. The assurance you draw from them should be matched to what they have actually demonstrated.

For each capability on which an essential service depends, can your team show the scope, the observed outcome and the action required where the evidence is still missing?