A monitoring alert shows a server talking to an unfamiliar IP address at 3 a.m., the EDR quarantines a suspicious program, or a partner calls to say your domain has turned up on a blocklist. The instinctive reactions are "reimage it now" and "reset every password". Both tend to destroy the evidence you need to scope the incident, or warn an attacker who is still inside and simply switches routes. This article sets out priorities for the first 24 hours after a suspected intrusion. It is written for front-line IT staff and for the managers who may have to decide in the middle of the night whether to take systems offline. Ideally, read it together before anything happens and turn it into your own procedure.

The structure follows NIST SP 800-61 Rev. 3, published in April 2025. It supersedes Rev. 2 from 2012 and describes incident response through the six CSF 2.0 Functions (Govern, Identify, Protect, Detect, Respond, Recover): Detect, Respond and Recover are the incident response itself, while the first three are the preparation done in normal times[1]. The practical steps also draw on joint guidance from CISA and the national cyber security agencies of Australia, Canada, New Zealand and the United Kingdom[2], and on CISA's ransomware response checklist[3]. Real-world cases are collected under Incidents.

Step one: confirm, assign a lead, move communications out of band

Confirm that it is really an incident

An alert is not an intrusion. Answer three questions first: what exactly did you see (which host, which account, what behaviour), when did it start, and is it still happening? Do not scope only the machine that raised the alarm: NIST recommends looking for indicators of compromise (IOCs), signs of persistence and other evidence on both the assets known to be targeted and other potential targets, because a superficial look tends to underestimate the incident's size[1]. If the lead came from IOCs in an advisory, see How to check your environment against advisory IOCs.

Assign an incident lead and a team

Name one incident lead who makes decisions, assigns work and speaks for the response internally and externally. Besides the technical handlers, NIST's list of response roles includes leadership with the authority to shut down or rebuild critical services, legal, public affairs, human resources, physical security and asset owners[1]. A small company does not need a dedicated person for every role, but every role needs an owner, and it must be clear in advance who can authorise taking systems offline.

Communicate out of band

Assume the attacker can read your corporate email and internal chat. CISA and its partners recommend holding all response communications out of band[2], for example by phone or through accounts and groups prepared in advance that do not depend on the corporate domain. Coordinate isolation the same way, so you do not tip off the attacker[3].

When to call in outside help

Consider bringing in an external incident response team if nobody in-house has done memory forensics or Active Directory investigations, if there are signs the attacker has domain admin rights or has moved laterally to several hosts, if extortion or data theft means you will have to explain the incident publicly, or if the incident is larger than your staff can cover in shifts. CISA and its partners suggest considering third-party incident response support to make sure the attacker is fully eradicated and to avoid follow-on compromises[2]. NIST notes that many organisations handle basic response themselves and bring in outside resources for certain incidents, and that responsibilities, information flows and authority to act should be written into the contract beforehand[1]. If you have cyber insurance, check whether the policy names approved responders or sets notification deadlines. If you need help, contact us.

Preserve evidence: collect first, then act

CISA and its partners list "mitigating the affected systems before responders can protect and recover data" as a common mistake, because it can destroy volatile data such as memory and may prompt the attacker to change tactics[2]. Even when prosecution is not on the table, NIST notes that collected incident data is still evidence, and its integrity and provenance should be preserved[1].

  • Do not reimage or restore yet: reimaging wipes the traces of how the attacker got in and stays in. It belongs to eradication, not the first hour.
  • Capture volatile data: take memory captures and system images of a sample of affected devices[3], and preserve running processes, network connections and event logs[2].
  • Secure the logs: firewall, VPN, proxy, DNS, Active Directory and cloud audit logs usually rotate. Export copies now so they are not overwritten during the investigation. CISA and its partners recommend retaining log data for at least one year[2]; if your environment keeps only a few days, fix that once the incident is over.
  • Keep a timeline: from the first minute, record who did what and when, and what they saw, and check whether system clocks and time zones agree. NIST recommends recording the actions taken during an investigation, protecting the integrity of those records, and using them to reconstruct the sequence of events and the assets involved[1].

Containment: pull the network or pull the plug?

Containment stops the spread, but how you do it decides whether the investigation can continue.

  • Disconnect from the network first: disable switch ports, use the EDR's network isolation, or move the host to a quarantine segment. Keeping the machine powered on preserves the evidence in memory. If several systems or subnets appear affected, CISA recommends taking the network offline at the switch level[3].
  • Power off only as a last resort: shutting down loses the evidence held in memory, and CISA recommends powering devices down only if you cannot disconnect them from the network[3]. The exception is active mass encryption that you cannot cut off quickly; protecting the data then comes first.
  • Do it in one coordinated move: isolating hosts piecemeal tells the attacker to relocate. Scope first, then isolate in a coordinated way[3].
  • Leave the attacker's infrastructure alone: do not ping, run nslookup against, or browse to the attacker's IPs and domains, which can reveal that you have spotted them. Do not rush to block a single IP either; replacing infrastructure costs the attacker little, and you lose visibility[2].

NIST stresses that every response strategy involves trade-offs: observing the attacker for a more thorough investigation can conflict with the need to restore operations quickly[1]. If data is being encrypted or exfiltrated, stop the damage first. If you have only found suspicious signs, collecting evidence and scoping before acting in one coordinated step is usually better. The incident lead should make this call and record the reasoning.

Credentials: timing and order matter more than speed

CISA and its partners point out that attackers usually hold more than one set of credentials, and that early or piecemeal resets just push them to use other credentials, create new ones or forge tickets[2]. A safer sequence:

  1. Establish which accounts the attacker has used and whether they obtained domain or cloud admin rights. If you need to avoid alerting them, temporarily reduce the privileges of affected accounts first, then carry out targeted resets[2].
  2. Tighten remote entry points. Breaches often involve mass credential theft, so CISA's checklist recommends disabling VPNs, remote access servers and single sign-on resources[3], or at least restricting them to essential staff.
  3. Once the environment has been cleaned and rebuilt, reset passwords for all affected systems[3], starting with domain admins, cloud admins and service accounts before ordinary users, and work from a clean administrative device.
  4. If Active Directory was compromised, reset the KRBTGT account password twice, because the account keeps a two-password history. Let the first reset replicate before the second; CISA suggests waiting at least 10 hours between them[4].
  5. For cloud and SaaS services, revoke existing sessions and tokens and review newly registered MFA devices and third-party app consents. See multi-factor authentication (MFA) for the settings involved.

Who needs to know: reporting channels in Taiwan

What follows is general guidance, not legal advice; confirm your actual obligations with counsel. NIST also recommends making notifications in line with the current laws that apply to your sector, your locations and your customers' locations, since these rules change often[1].

Organisations covered by the Cyber Security Management Act

Under the Cyber Security Management Act, "specific non-government agencies" are critical infrastructure providers, state-owned enterprises, certain foundations, and businesses, groups or institutions controlled by the government[5]. The incident reporting regulations require a specific non-government agency to report a cyber security incident within one hour of becoming aware of it, using the method specified by its central industry regulator[6]. See Taiwan's Cyber Security Management Act for details.

Other companies

Companies outside the Act's scope can report incidents to TWCERT/CC through its general reporting form or by email to int_report@cert.org.tw[7].

Listed companies

If the incident could materially affect operations or finances, a listed company must also assess whether it has to publish a material information announcement; see Cyber incidents and material information disclosure. Bring the CFO and the company spokesperson in early.

Personal data

Article 12 of the Personal Data Protection Act as currently in force requires that, when personal data is stolen, leaked, altered or otherwise infringed, the data subjects be notified in an appropriate manner after the facts have been investigated[8]. Amendments made in November 2025 require notifying data subjects upon becoming aware of the breach, and require non-government agencies to also report breaches that meet a defined threshold to the Personal Data Protection Commission. The Executive Yuan sets the effective date of these amendments, and at the time of writing the official law database still lists it as "undetermined"[9]. Some industry regulators may have their own notification rules, so check those too.

Customers, partners and law enforcement

NIST recommends notifying affected third parties in line with regulatory, legal and contractual requirements, and deciding whether to notify law enforcement and regulators based on the response plan and management approval[1].

Common mistakes

  • Reimaging or restoring immediately, without keeping memory and logs[2].
  • Discussing the response over corporate email or chat that may itself be compromised[2].
  • Connecting to or looking up the attacker's IPs and domains yourself[2].
  • Blocking one IP and declaring victory without finding the malware and the way in, which leaves the attacker with access[2].
  • Resetting passwords piecemeal, which alerts the attacker and sends them to other accounts[2].
  • Restoring from backups nobody has checked; NIST recommends checking restoration assets for indicators of compromise and corruption before use[1]. See also the 3-2-1 backup rule.
  • Keeping no records, so the timeline and the reasons for each decision cannot be reconstructed afterwards.

Action checklist

  1. Write down when the issue was found, who found it and what they saw, and start the timeline.
  2. Appoint an incident lead and set up an out-of-band channel (phone, or accounts that do not depend on the corporate domain).
  3. Export and back up firewall, VPN, proxy, DNS, Active Directory and cloud audit logs, and pause rotation that would overwrite them.
  4. Capture memory and system images from affected hosts, then isolate them; disconnect from the network first and power off only if you cannot.
  5. Do not reimage, do not restore from unchecked backups, and do not connect to the attacker's IPs or domains.
  6. Inventory the accounts and privileges the attacker used; after cleanup and rebuild, reset privileged accounts, then service accounts, then ordinary users, and reset KRBTGT twice if Active Directory was compromised.
  7. Confirm reporting duties and deadlines with counsel: the Cyber Security Management Act regulator, TWCERT/CC, material information disclosure, data subjects, customer contracts and your insurer.
  8. Decide whether you need outside incident response help, and if so contact us or your retained responder.
  9. Once things settle, review the process, close the gaps in logging, contacts and access this incident exposed, and subscribe to advisories to follow related threats.