At two in the morning, a developer notices that a customer has been locked out of their account, then a second, then a dozen. Someone posts in the team chat. Nobody is sure who should decide what to do, whether to take the service offline, or who needs to be told. By the time the questions are answered, an hour has gone and the situation is worse. Almost every painful incident we see follows this shape, and almost all of the damage is decided in advance, by the preparation that was or was not done.
Most Malaysian SMEs and software teams do not have a security operations centre or an on-call security engineer. That is normal, and it is not an excuse to be unprepared. Readiness is not a team you hire. It is a short set of decisions you make while nothing is on fire.
Know what you would be protecting
You cannot protect what you have not listed. Start with a plain inventory of your important systems and the personal or business-critical data each one holds, then mark the few that would genuinely hurt if they were breached or lost. Most teams have a handful of these, such as the production database, the identity provider, the email domain, and the code repository.
The CIS Critical Security Controls (v8.1) are a sensible, prioritised baseline for a team without a security function, because they are ordered by impact rather than by how a standard is structured. You do not need all eighteen at once. You need the first few, applied honestly.
Decide who decides
During an incident, unclear ownership is as damaging as the attack itself. Even in a team of ten, write down who plays each role: an incident lead who makes the calls, someone technical who investigates and contains, someone who handles communication to customers and staff, and someone responsible for legal and regulatory duties. In a small team one person may hold two roles, which is fine, as long as it is decided beforehand.
Decide too where you will get help you do not have in-house. A named contact at your hosting provider, and a senior security adviser you can reach quickly, are worth arranging before the night you need them, not during it.
You cannot respond to what you cannot see
Detection is the part small teams most often skip, and the part that most determines how bad an incident becomes. If you have no logging on your identity provider, your email, and your cloud accounts, an intruder can operate for weeks unseen. Turn on the audit logs those platforms already provide, and set a small number of alerts that a human will actually read, such as new administrator accounts, mass data exports, and logins from unexpected locations.
The point is not to watch everything. It is to notice the few events that reliably signal trouble, and to make sure the alert reaches a person who can act.
Have a simple sequence to follow
Under pressure, people fall back on whatever process they have. Give them a simple one. The SANS incident handling process is a well-worn six-step sequence that a non-specialist can follow: preparation, identification, containment, eradication, recovery, and lessons learned. Containment before eradication matters most, because pulling a compromised system offline or isolating an account stops the bleeding while you work out the full extent.
For the wider framing, NIST’s Cybersecurity Framework 2.0 organises security around six functions, Govern, Identify, Protect, Detect, Respond, and Recover, and its SP 800-61 Revision 3 ties incident response to managing risk rather than treating it as a one-off drill. You do not need to adopt a framework to be ready, but they are useful checklists for what you might be missing.
Protect your ability to recover
The single most valuable preparation for the common case, ransomware, is backups you can actually restore. Keep at least one copy offline or immutable, so that an attacker who reaches your systems cannot encrypt or delete it too. Then test a restore. A backup that has never been restored is a hope, not a control, and teams routinely discover the gap at the worst possible moment.
Recovery planning also means knowing your order of operations: which system comes back first, what you verify before reconnecting it, and how you confirm the intruder is actually out before you reopen the doors.
Know who to call
In Malaysia, the national channel for reporting a cyber security incident is Cyber999, run by MyCERT under CyberSecurity Malaysia. You can reach it on 1-300-88-2999 or at [email protected], and it can provide guidance and coordination during an incident. At national level, the National Cyber Security Agency (NACSA) leads policy and coordination.
There is also a legal clock. If personal data is involved, Malaysia’s PDPA now requires you to notify the Commissioner of certain breaches within 72 hours, and sometimes the affected individuals shortly after. We cover what qualifies in our guide to the PDPA changes. Add these contacts, and your legal adviser, to the same page as your incident roles, so nobody is searching for a phone number mid-incident.
Practise once before you need it
You do not need a large exercise. Spend an hour walking the team through a realistic scenario: a leaked administrator password, a ransomware note, a laptop stolen with customer data on it. Ask who does what, where the logs are, how you would contain it, and who you would call. The gaps you find in that quiet hour are far cheaper to fix than the ones you find at two in the morning.
Readiness is not expensive. It is a document, a few switches turned on, a tested backup, and a short rehearsal. Set against the cost of a live incident handled from scratch, it is one of the best-value pieces of security work a small team can do.