5-Step urgent incident response protocol between enterprises and MSP partners

These five steps are not completely separate phases. In a real incident, investigation and containment often happen in parallel, while a compromised account may need to be disabled as soon as there is sufficient evidence.

The most important principle is simple: the enterprise and its service provider should know who is authorized to do what before an incident occurs.

Enterprises developing their own internal playbooks can also refer to IPSIP Vietnam’s Incident Response Guide for Enterprises.

1.How Should an Enterprise and MSP Coordinate During a Cybersecurity Incident?

When a breach or ransomware incident occurs, coordination can be structured into five core steps:

This is an operational framework, not a fixed timeline. Enterprises should not invent rules such as “contain everything within 15 minutes” or “restore within 30 minutes” unless the SLA, system architecture, and incident severity genuinely support those targets.

1.1 Step 1: Validate and declare the cybersecurity urgent incident response protocol 

The first task is not to delete malware. It is to determine whether the alert is serious enough to activate the incident response process.

Signals that may justify rapid escalation include:

• a ransomware note appearing on a system;

• multiple files being encrypted or renamed;

• EDR detecting a malicious process;

• abnormal privileged-account logins;

• service accounts performing unusual activity;

• evidence of credential compromise;

• suspicious PowerShell or script execution;

• lateral movement between systems;

• privilege escalation;

• unusual outbound traffic;

• backup or security tools being disabled.

An alert does not automatically mean a confirmed incident. However, an organization should not wait for absolute certainty before escalating when the available evidence suggests potentially serious impact.

Once the response process is activated, the enterprise should record at least:

• detection time;

• the person or system that detected the issue;

• affected assets;

• related accounts;

• observed symptoms;

• impacted business services;

• actions already taken;

• available logs and alerts;

• the person currently coordinating the response.

Who should coordinate the incident?

A serious iurgent incident response protocol should have one primary incident coordinator, often referred to as an Incident Commander.

This person does not have to be the organization’s best malware analyst. Their more important responsibility is keeping the response structured:

who investigates → who isolates → who approves → who updates management → who coordinates with the MSP/MSSP → who records key decisions.

Without a clear coordinator, several engineers may spend time analyzing the same malware sample while nobody disables the compromised account that the attacker is still using.

1.2 Step 2: Activate the emergency hotline and escalation process with the MSP/MSSP

An effective emergency incident hotline is more than a phone number saved in a contact list.

It should be part of an escalation process that has already been agreed upon and tested.

The enterprise and MSP/MSSP should prepare:

• a primary contact;

• a backup contact;

• after-hours coverage;

• an emergency email or ticketing path;

• customer or contract identification information;

• incident severity definitions;

• personnel authorized to request isolation;

• personnel authorized to modify firewall or network configurations;

• personnel authorized to disable accounts;

• a backup communication channel.

What information should be provided when contacting the MSP/MSSP?

The initial notification should answer:

1. Which organization or system is affected?

2. Who is the primary incident contact?

3. When was the incident detected?

4. Which systems or accounts are affected?

5. What symptoms have been observed?

6. How is the incident affecting business operations?

7. Are there signs of ransomware, credential theft, or lateral movement?

8. What actions has the internal team already taken?

9. What logs or alerts are currently available?

10. What immediate support does the enterprise need from the provider?

A message such as “the server was hacked, please check” is rarely enough for an effective emergency response.

MSP and MSSP responsibilities are not automatically the same

If an MSP manages servers, backups, and networks, that does not automatically mean it is contracted to perform malware analysis, digital forensics, or specialist cybersecurity incident response.

Conversely, an MSSP or SOC may detect and analyze threats but lack authorization to reboot a production server or modify network routing.

The enterprise should establish in advance:

For environments that require continuous security monitoring, IPSIP Vietnam’s SOC 24/7 can provide an additional layer of monitoring, alert analysis, and coordinated response within an agreed service scope.

1.3 Step 3: Isolate Compromised Systems Without Destroying Evidence

Once there are credible signs of compromise, the objective of containment is to limit the scope of impact.

In practical terms, the organization needs to prevent an attacker from using one compromised device to access additional systems.

How to isolate a compromised device

Depending on the architecture and tools available, containment measures may include:

• using EDR network isolation;

• disconnecting the device from the network;

• disabling Wi-Fi or wired connectivity;

• blocking communication with confirmed malicious infrastructure;

• disabling a compromised account;

• revoking active sessions or tokens;

• temporarily reducing access privileges;

• restricting traffic between network segments;

• applying controlled firewall rules.

Isolation does not automatically mean shutdown

This is one of the easiest parts of incident response to mishandle.

Organizations should not assume that the correct response to ransomware is to immediately power off every server.

A shutdown can destroy volatile information in memory, active process data, network connection details, and other evidence that may be valuable during an investigation.

CISA also notes that powering systems down may result in the loss of volatile evidence. It is generally more appropriate when the organization cannot otherwise disconnect the affected system from the network and needs to prevent further ransomware propagation.

A safer general principle is:

isolate where feasible → preserve evidence → investigate → make irreversible changes only when there is a clear reason.

Do Not Destroy Evidence Before Understanding What Happened

During a serious incident, organizations should be cautious before:

• formatting disks;

• immediately reinstalling the operating system;

• wiping devices;

• deleting logs;

• deleting suspicious files without recording them;

• resetting accounts in bulk without documenting the actions;

• deleting virtual machines before collecting required evidence.

Not every system requires a full forensic image.

However, the organization should identify which systems contain important evidence before carrying out irreversible actions.

1.4 Step 4: Investigate the Scope, Eradicate the Cause, and Recover in a Controlled Manner

Containment only limits further damage. It does not prove that the attacker has been removed from the environment.

Determine the scope of compromise

The enterprise and its MSP/MSSP should work together to answer:

• What was the initial entry point?

• Which system was compromised first?

• Which accounts were stolen?

• Did the attacker escalate privileges?

• Was there lateral movement?

• Which systems contain persistence mechanisms?

• Is there evidence of data exfiltration?

• Was the backup environment accessed?

• Were Cloud sessions compromised?

• Are there affected systems that have not yet been identified?

Useful sources of investigation data may include:

• EDR/XDR;

• SIEM;

• firewall logs;

• identity systems;

• email security;

• Cloud audit logs;

• VPN logs;

• proxy logs;

• WAF logs;

• endpoint logs;

• network telemetry.

Changing the password may not be enough

If an attacker has stolen a session or token, changing the password alone may not immediately terminate the attacker’s access.

Identity containment may therefore require a combination of:

password reset + session revocation + token revocation + MFA review + privileged-account review, depending on the platform and available evidence.

Eradication must address the cause, not only the symptom

Removing a ransomware executable does not solve the problem if the exploited vulnerability remains open.

Remediation may include:

• removing persistence mechanisms;

• removing malicious artifacts;

• patching exploited vulnerabilities;

• rotating compromised credentials and secrets;

• deleting unauthorized accounts;

• correcting insecure configurations;

• reviewing remote access;

• hardening related systems.

When can the enterprise restore from backup?

Not simply when the server appears “clean.”

Before recovery, the organization should determine:

• Is the backup intact?

• Was the backup created before or after compromise?

• Could malware or persistence be present in the backup?

• Were backup-system credentials compromised?

• Has the initial access vector been remediated?

• Is the restored network appropriately segmented?

• Has monitoring been re-enabled?

What should enterprises consider when the incident is ransomware?

Modern ransomware is not always simply:

malware executes → data is encrypted → restore backup.

An attack may already have progressed through several stages:

initial access → credential theft → privilege escalation → lateral movement → data exfiltration → ransomware deployment.

The ransom note is often only the most visible part of a much larger incident.

The enterprise should assess:

• the scope of encryption;

• compromised accounts;

• lateral movement;

• privileged access;

• evidence of data exfiltration;

• remote access;

• backup integrity;

• persistence mechanisms;

• systems that were not encrypted but may still have been compromised.

CISA also notes that a ransomware incident can indicate an earlier compromise. Reviewing EDR, IDS/IPS, antivirus, and log data may help identify activities that occurred before the ransomware payload was deployed.

Enterprises can also refer to IPSIP Vietnam’s Ransomware Incident Response Handbook when developing their internal response procedures.

Do not rtore too early

If the attacker still has access or persistence within the environment, a newly restored server may quickly become compromised again.

Do not treat ransom payment as a default technical step

Decisions involving ransom demands should involve appropriate management, legal, compliance, and incident response stakeholders.

Payment should not be treated as a default technical step in the ransomware response process.

1.5 Step 5: Monitor after recovery and conduct a post-incident review

A server returning online does not mean the incident is over.

After recovery, the SOC/MSP/MSSP should increase monitoring for:

• known indicators reappearing;

• abnormal authentication;

• new remote access;

• privilege escalation;

• suspicious outbound traffic;

• remaining persistence mechanisms;

• similar behavior on other assets.

What should the post-incident review answer?

At minimum:

• How did the attacker gain access?

• When did the initial compromise occur?

• When did the first alert appear?

• Was the alert escalated correctly?

• How long did containment actually take?

• Who had authority to isolate systems?

• Were any actions delayed by approval requirements?

• Did the provider have enough telemetry?

• Were logs retained for long enough?

• Were backups usable?

• Did internal IT and the MSP/MSSP coordinate effectively?

• Did the emergency communication channel work?

• What needs to change in the response process or SLA?

Root-cause analysis should not simply look for someone to blame.

Its purpose is to determine which controls or processes need to change so that the next incident can be detected and handled more effectively.

2.How should responsibilities be divided between the MSP, MSSP, and internal IT team?

There is no single responsibility matrix that works for every enterprise, but each party’s role should be defined in advance.

The key point is that the contract scope must match expectations during a real incident.

The worst time to discover that an MSP is contracted only to “monitor and notify,” rather than isolate assets or participate in investigation, is after ransomware has already started encrypting servers.

3.The Emergency Communication Channel May Also Be Compromised

If the organization suspects the attacker has control over:

• corporate email;

• Microsoft 365;

• Active Directory;

• internal collaboration platforms;

then discussing the entire response plan through those same systems may reveal the containment strategy to the attacker.

An incident response plan should therefore include a pre-established and verified backup communication method.

That backup channel should also not be used carelessly to transmit passwords, private keys, or other sensitive credentials.

4.What Compliance Requirements Should Vietnamese Enterprises Consider During Incident Response in 2026?

As of September 2026, Vietnam’s cybersecurity regulatory framework has undergone several significant changes that enterprises should consider when developing their incident response processes.

Cybersecurity Law No. 116/2025/QH15

Cybersecurity Law No. 116/2025/QH15 – Government of Vietnam was passed on December 10, 2025, and took effect on July 1, 2026.

Incident response should therefore not be treated solely as an informal process where “IT handles the problem when a system gets hacked.” For organizations and systems falling within applicable requirements, the response process should align with broader governance, responsibilities, monitoring, evidence handling, and compliance obligations.

Decree No. 331/2026/ND-CP

Decree No. 331/2026/ND-CP – Cybersecurity Protection Measures for Information Systems addresses information-system security levels together with corresponding cybersecurity protection measures and responsibilities.

For enterprises, this reinforces the need to clearly understand:

which systems are critical → who owns them → who may isolate them → who may restore them → which provider is responsible.

Decree No. 332/2026/ND-CP

When selecting an MSSP or incident response provider, Decree No. 332/2026/ND-CP on the business of cybersecurity products and services is particularly relevant.

The regulation covers cybersecurity service categories such as:

• cybersecurity monitoring;

• incident response;

• security testing and assessment;

• consulting;

• data recovery;

• prevention and protection against cyberattacks.

Enterprises should therefore ask more than:

They should assess the provider’s actual service scope, capabilities, and applicable legal eligibility for the services being purchased.

Decree No. 333/2026/ND-CP

Decree No. 333/2026/ND-CP provides detailed implementation measures for the Cybersecurity Law, including matters related to cybersecurity monitoring, incident response, and remediation.

Some specific requirements apply only to organizations falling within the corresponding regulatory scope. Therefore, enterprises should not assume that one detailed requirement automatically applies in exactly the same way to every company in every industry.

If the Incident Involves Personal Data

Enterprises should also assess obligations under Personal Data Protection Law No. 91/2025/QH15 – Government of Vietnam, which took effect on January 1, 2026, together with any applicable sector-specific requirements.

Organizations should not assume there is one universal notification deadline for every cybersecurity incident before determining:

• the type of data involved;

• the organization’s role;

• the scope of impact;

• the industry;

• the affected systems;

• applicable sector-specific regulations.

5.IPSIP Vietnam: supporting enterprise incident response through Managed Services

An effective cybersecurity incident response process does not begin when ransomware appears.

It begins earlier, when the enterprise and its service provider have already agreed on monitoring, responsibilities, escalation procedures, communication channels, and response authority.

Within a Managed Services model, the provider’s role should go beyond receiving tickets when systems fail. The broader value comes from connecting infrastructure operations with cybersecurity monitoring and incident response coordination.

Through SOC 24/7 and related Managed Services capabilities, IPSIP Vietnam can work alongside internal IT teams under a model in which:

• Internal IT retains system knowledge, business context, and decision-making authority.

• Managed Services adds operational capacity and infrastructure context.

• SOC/MSSP capabilities add cybersecurity monitoring and threat analysis.

The incident response process connects those functions during containment, investigation, recovery, and post-incident review.

This does not mean the enterprise gives complete control of its environment to an external provider.

Internal IT should continue to retain:

• system ownership;

• business priorities;

• governance;

• decision authority;

• provider oversight.

Meanwhile, the Managed Services partner can add:

• monitoring capability;

• operational resources;

• specialized technical expertise;

• cybersecurity analysis;

• escalation support;

• incident response assistance within the agreed service scope.

A practical way to test readiness is to run a tabletop exercise involving the enterprise and its provider:

If the answer is still “we will figure it out when it happens,” the process is not truly ready.

👉 Enterprises can contact IPSIP Vietnam to discuss collaboration opportunities and develop a Managed Services, SOC, and incident response coordination model aligned with their infrastructure, internal IT capabilities, and risk profile.

🎉 To assist enterprises in optimizing risk management costs, IPSIP Vietnam is currently rolling out a special promotional program: Get an immediate 15% discount on the total contract value for all new clients signing up for Pentest services or other solution suites. Sign up for IPSIP Vietnam's Pentest services today to undergo structured testing, analysis, and comprehensive security vulnerability remediation support, maximizing the protection of your digital assets!

References

NIST SP 800-61 Rev.3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management

Cybersecurity Law No. 116/2025/QH15 – Government of Vietnam

Decree No. 331/2026/ND-CP – Cybersecurity Protection Measures for Information Systems

Decree No. 332/2026/ND-CP – Requirements for Cybersecurity Product and Service Providers

Decree No. 333/2026/ND-CP – Cybersecurity Requirements for Enterprises

Personal Data Protection Law No. 91/2025/QH15 – Government of Vietnam