Incident Response

When, Not If

Every organization will face an incident. Ransomware, credential theft, data exfiltration, insider threat, supply chain compromise. Singapore saw 21 million cyberattacks in 2024. Most were automated noise; some were serious. If you're not incident-ready, a serious one will damage your business, your reputation, and your compliance standing.

Incident response means having a plan, a team, evidence-preservation procedures, and the coordination to execute under pressure. The organizations that survive incidents with minimal damage are those that practiced before it happened.

The First Hour Decides Everything

When an attacker is inside your network, the clock is ticking. In the first hour, they try to establish persistence (install a backdoor, create a hidden admin account, plant malware that survives reboots). If they succeed, you own the problem for months. If you isolate them and remove access in the first hour, it was a break-in attempt that failed, not a breach.

Many organizations waste the first hour because they don't know who to call, what to do, or whether this is actually an incident. An incident response plan eliminates that confusion: these are the signs of an incident, here's who you call, here's the first thing we do (preserve evidence, contain the threat, notify leadership).

What an Incident Response Retainer Gives You

A retainer means we're on standby. When you detect something suspicious, you call us. We respond in minutes, not hours. We help you make the critical early decisions: is this actually an incident? Do we need to isolate systems? Do we need to notify customers or regulators?

We can also help before an incident happens: building your incident response plan, testing it with tabletop exercises, training your team, and doing threat modeling so you know what to watch for.

Detection and Triage

You might detect an incident through your SOC (suspicious activity flagged by alerts), through a user report (my computer is slow, everything's locked, or I see a ransom note), through a third party (your payment processor says your account is compromised), or through your cloud provider (AWS disables your account for suspicious activity).

The first step is triage: is this actually an incident or is it a false alarm? A SOC alert might be a misconfiguration. A user's computer being slow might be a legitimate backup. We help you determine: do we have evidence of compromise, unauthorized access, or malicious activity? If yes, we escalate to full incident response. If no, we provide guidance on what to monitor.

Containment — Stop the Bleeding

Once an incident is confirmed, containment is the priority: stop the attacker from causing more damage. This might involve: isolating infected machines from the network (so malware can't spread), revoking compromised credentials (so the attacker can't use stolen passwords), disabling compromised accounts, blocking malicious IP addresses, or taking affected systems offline.

Containment has trade-offs. If you isolate a critical system, production might go down. If you revoke all credentials, users can't work. Good incident response balances speed (contain now) with business continuity (maintain service where possible). The decision depends on the severity — ransomware spreading across your file servers requires immediate isolation; a single compromised employee account is lower urgency.

We help you make these decisions quickly and execute them correctly. We can directly isolate systems, revoke credentials, or guide your team through it.

Investigation and Forensics

Once containment is in place, investigation answers: how did they get in? What did they do? What systems were accessed? What data was exposed?

Forensics means preserving evidence. If you power off a compromised system without capturing memory, logs, and artifacts, you lose evidence. If you overwrite logs thinking you're cleaning up, you destroy your investigation. We use forensic tools and procedures to capture evidence safely: memory dumps (RAM), disk images (entire drive), log exports, and application data.

We then analyze the evidence: timeline of attacker activity, entry point (how did they get in — phishing email, stolen credentials, unpatched vulnerability), lateral movement (what systems did they move to), and impact (what data did they access or steal, what systems did they modify).

Eradication — Remove the Attacker Completely

Once we understand the attack, eradication removes the attacker's presence. This might involve: patching the vulnerability they exploited, removing malware, changing compromised passwords, disabling backdoor accounts, or rebuilding infected systems from clean backups.

Eradication is tricky because attackers often leave multiple backdoors. If you only remove the obvious one and miss a hidden one, they'll get back in. That's why forensics matter — you need to know the full scope of what they did so you can completely remove every trace.

Recovery and Validation

Once systems are clean, you need to restore them to normal operation. For some systems, that means bringing them back online (after rebuild or patch). For data, it means restoring from backups (after confirming the backups weren't compromised). For users, it means resetting passwords and restoring access.

Validation means confirming you actually removed the attacker. We perform post-incident scanning to verify: are there any remaining malware signatures? Are there any suspicious processes? Are there any unexpected user accounts? Is the timeline of activity consistent with recovery, or does it show the attacker is still there?

Evidence Preservation and Legal

If the incident might result in law enforcement involvement (ransomware, theft, corporate espionage), evidence must be preserved in a forensically sound way. That means chain of custody (documented handling of evidence), bit-for-bit copies (not copies of copies), and working on forensic images rather than original systems.

We coordinate with legal counsel and law enforcement. We provide evidence in formats they can use. We document our methodology so evidence will be admissible if the attacker is prosecuted.

Notification and Regulatory Reporting

If personal data was exposed, PDPA requires notification to affected individuals and to CSA within specific timeframes. If you're a financial institution, MAS has notification requirements. If you're ISO 27001 certified, incident notification is part of your control framework.

We help you draft notification communications: to customers (transparent, clear, what happened and what they should do), to regulators (factual, timeline, impact, actions taken), to business leadership and board (executive summary, business impact, recommendations).

Post-Incident Review and Learning

After containment and recovery, a post-incident review answers: what did we learn? What could we have done better? How do we prevent this from happening again?

The review covers prevention (what vulnerability or misconfiguration allowed this), detection (why did it take so long to find), and response (what slowed us down). It results in a lessons-learned report and action items: patch this vulnerability, add this monitoring, improve this process, train staff on this threat.

Organizations that don't do post-incident reviews will repeat the same incident. The ones that do learn and improve.

Building Your Incident Response Plan

A good incident response plan includes: roles and responsibilities (who is the incident commander, who owns communications, who makes escalation decisions), escalation procedures (when do you involve law enforcement, customers, regulators), evidence preservation (how to capture logs and artifacts without destroying them), containment procedures (how to isolate systems), communication templates (what to say to customers and regulators), and contact information (who to call in an emergency).

The plan should be tabletop-tested quarterly (sit down with the team and walk through a scenario) and fully tested annually (actually execute parts of the plan, capture evidence, run a cleanup). Real incidents will surprise you; regular testing reduces those surprises.

Who Needs Incident Response Retainers

Organizations handling sensitive data (PDPA personal data, financial records, healthcare). Organizations with critical uptime requirements (downtime costs you money). Organizations targeted by ransomware or espionage. Organizations in regulated industries. Organizations that've been breached before. In practice, most organizations should have incident response capability.

Small organizations might not afford a full retainer. In that case, build a basic incident response plan internally, train your team, and have a vendor on speed-dial. Medium and large organizations should have either internal incident response capability or a retainer with an external firm.