When a Vulnerability Is Being Actively Exploited: How to Make the Right Decisions in the First 48 Hours

Not theoretically. Not as a distant risk. Attacks are already happening in the wild, and you do not yet know whether your environment has been affected.

What now? Patch, investigate a potential compromise, isolate the system, or temporarily take it offline?

The instinctive reaction is to patch as quickly as possible. But when a vulnerability is already being actively exploited, the first question is not whether a patch exists.

The first question is whether you are still dealing with a vulnerability, or already dealing with an incident.

That distinction determines whether the team should continue with vulnerability management or initiate incident response. The following framework is designed to help CISOs, IT managers and security teams make decisions under pressure between patching, isolation, monitoring and escalation.

The first question is not “Do we have a patch?” but “Have we already been affected?”

Before an organisation starts planning the patching process, it needs to establish three things quickly.

Do we actually have the affected product and vulnerable version deployed, not only in production, but also in staging, test environments, subsidiaries or shadow IT?

Is the affected instance exposed to the internet, or is it located inside a segmented internal network?

And who is the technical and business owner of the system with the authority to decide whether access should be restricted or the system taken offline?

These questions sound simple, but in practice they are often the first weak point. Organisations with incomplete asset visibility, CMDBs or asset inventories can spend the first hours simply trying to determine whether the problem applies to them at all.

If you cannot confirm or rule out within an hour whether the affected product is present and exposed, that is a finding in itself. One of the lessons should therefore be to invest in asset management and external attack surface monitoring.

The first call or ticket should therefore not be limited to scheduling a patch window. It should involve both the infrastructure owner and the security team and answer one question:

Can we confirm or rule out the presence, exposure and business context of the affected system?

Two different signals, two different responses

Information that a vulnerability is being widely exploited in the wild is a signal for vulnerability management.

It means the risk has increased significantly and that patching or compensating controls should be prioritised.

It does not automatically mean that your organisation has already been compromised.

A different type of signal is specific evidence of attempted or successful exploitation in your own environment: a match with an indicator of compromise (IOC) in the logs, an anomalous process, an unexpected outbound connection, a newly created account, or a scheduled task that nobody legitimately created.

At that point, you are no longer dealing only with vulnerability management. You are dealing with incident response.

This distinction is critical.

A patch can close the door, but it cannot remove an attacker who may already be inside or have established persistence.

If the system was vulnerable during a period when the vulnerability was already being actively exploited in the wild, patching alone is not enough. You need to verify, rather than assume, that exploitation did not occur.

Silence in monitoring is not proof of safety

If your SOC or internal monitoring does not report an alert, that does not automatically mean the organisation is safe.

Monitoring is only as good as the depth and retention of the available logs and the detection rules that existed before the vulnerability became known.

The problem becomes particularly significant where organisations do not log command-line activity, process creation or application-level network connections, or where log retention is shorter than the period between the beginning of active exploitation and patch deployment.

So it is not enough to ask:

“Did we see anything suspicious?”

The next question should be:

“Did we even have a chance to see it?”

If the answer is unclear, the system should be treated more cautiously because you still do not know enough about its actual state.

The First 48 Hours: A Practical Decision Timeline

1. Triage

The purpose of triage is not to solve everything. It is to collect enough information, quickly enough, to make the right next decision.

The team should:

• confirm the presence of the vulnerable product and all affected instances,
• determine the level of exposure,
• establish the business context,
• review available IOCs and detection signatures,
• identify the decision owner,
• open an internal ticket and record when the issue was identified.

2. Decision and First Action

Based on the findings, the team decides on a combination of actions:

• patching,
• isolation,
• compensating controls,
• escalation to incident response.

These options are not mutually exclusive. In a real incident, they are often combined.

If there is any indication of compromise, escalation to incident response should happen immediately.

Preserving evidence, logs, snapshots and memory should take priority over quickly cleaning up the environment.

Management and business owners should be informed in parallel, because taking a production system offline is both a security and an operational decision.

If the situation may involve personal data or regulatory notification requirements, the DPO or legal team should not be brought in only at the end. They should be involved alongside the technical response.

3. Execution, Verification and Communication

Once the selected measure has been implemented, it is not enough to state that the patch has been installed.

The organisation needs to verify that the attack path has actually been closed.

This should also include:

• enhanced and targeted monitoring of the affected system over the following days or weeks,
• a decision on external communication where relevant,
• a short timeline of key decisions for subsequent lessons learned.

Decision Matrix: Patch, Isolate, Monitor or Escalate

Under pressure, clear criteria help. The following table can serve as a quick decision framework, not as an automatic risk calculation.

These factors lead to several typical scenarios.

Patching may be sufficient for a segmented system with no indicators of compromise if a patch can be deployed within a reasonable timeframe.

Patching combined with temporary isolation or access restrictions makes sense for an exposed system where the patch cannot be deployed immediately.

Monitoring should be a supporting measure, never the only response, and only where meaningful telemetry actually exists.

Immediate escalation to incident response is appropriate when there is a confirmed IOC match, anomalous system behaviour, or when the system was demonstrably exposed during active exploitation and there are insufficient logs to rule out compromise.

At this stage, the absence of evidence should not automatically be treated as evidence that everything is fine.

When the Patch Cannot Be Deployed Immediately

There may be legitimate reasons why a patch cannot be deployed immediately: a legacy system, dependency on another application, required testing, or an operational maintenance window.

In those situations, temporary compensating controls become necessary:

• virtual patching through a WAF, NGFW or EDR where an applicable signature exists,
• temporary ACL or firewall rules, or moving access behind a VPN,
• restricting or disabling the vulnerable module if it is not essential to system operation,
• strengthening application isolation or Mandatory Access Control mechanisms where supported,
• adding MFA or reducing service account privileges according to the principle of least privilege,
• implementing targeted additional logging and detection rules for the specific vulnerability,
• taking a backup or snapshot before making changes so that pre-change and post-change states can later be compared forensically.

Every temporary measure should have an owner and a review date.

Otherwise, a temporary exception can easily become permanent and be forgotten a few months later.

The Role of the SOC or MDR Team in the First 48 Hours

At this stage, the job is not simply to watch alerts.

An internal SOC or external SOC/MDR partner helps the organisation determine whether it has enough evidence to make a safe decision.

In practice, this primarily means:

• rapidly deploying or validating detection rules for the specific vulnerability,
• retrospectively searching logs covering the period when the system may have been vulnerable and exposed,
• correlating data from EDR, firewalls, authentication logs and DNS,
• ensuring escalation capacity outside normal working hours,
• providing an independent second assessment when the internal team is operating under time pressure.

The greatest practical value of SOC/MDR support often appears when an organisation does not have its own 24/7 capacity, or when it needs to retrospectively determine whether exploitation occurred before the patch was deployed.

Practical Checklist for the First 48 Hours

1. Triage

✓ Confirm or rule out the affected product and vulnerable version, including staging, shadow IT and IT/OT environments.

✓ Determine exposure: internet-facing or segmented internal network.

✓ Review available IOCs and detection signatures.

✓ Identify the decision owner and confirm their authority to act.

✓ Open an internal ticket and record when the issue was identified.

2. Decision and First Action

✓ Assess the situation using the decision matrix: patching, isolation, compensating controls or escalation.

✓ Escalate to incident response and preserve evidence if there is any indication of compromise.

✓ Inform management and business owners of the affected systems.

✓ Where relevant, involve the DPO or legal team alongside the technical response.

3. Execution and Verification

✓ Implement the selected measure.

✓ Verify that the attack path has actually been closed.

✓ Introduce enhanced monitoring for the following days or weeks.

✓ Decide on external communication if the situation constitutes an incident and communication is required or appropriate.

✓ Record a short timeline of key decisions for lessons learned.

Conclusion

The first 48 hours are not a race to deploy a patch.

They are a sequence of decisions made with incomplete information.

The most expensive mistake may not be patching too slowly, but asking the wrong question.

Organisations that handle this phase well have already defined the difference between “we are dealing with a vulnerability” and “we are dealing with a potential incident” in their processes and escalation matrices.

They do not start improvising once the clock is already running.

This is where the practical value of SOC/MDR cooperation becomes clear: building and testing this level of readiness, providing 24/7 capacity for retrospective verification, and supporting escalation for organisations that do not have that capability internally