IT insights for
Kenyan businesses.

The 10-Point Cybersecurity Checklist Every Kenyan Business Needs

Ransomware and business email compromise are no longer problems that happen somewhere else. The Communications Authority of Kenya, through the Kenya National Computer Incident Response Team (KE-CIRT), publishes incident advisories every quarter — and the trend line points one way: attacks on small and mid-sized businesses are rising because attackers know SMEs spend less on defence.

The good news: you do not need an enterprise budget to block the majority of attacks. You need discipline on ten basics. This is the exact checklist we use when auditing a new client's environment.

1. Keep a live asset register

You cannot protect what you have not written down. Every laptop, phone, server and cloud account should be on one list, with an owner against each. Most breaches we investigate start on a machine nobody remembered existed.

2. Turn on multi-factor authentication everywhere

Email first, banking second, then everything else. MFA stops the majority of password-based attacks outright, and it is free on Microsoft 365 and Google Workspace. If a supplier refuses to support MFA, treat that as a risk on its own.

3. Patch on a schedule, not on a mood

Attackers weaponise new vulnerabilities within days. The CISA Known Exploited Vulnerabilities Catalog is the public list of the flaws criminals are actively using — your IT team should be clearing items from it weekly, not "when there's time".

4. Replace antivirus with EDR

Traditional antivirus matches known signatures. Endpoint Detection and Response watches behaviour, so it catches brand-new malware. Licences cost a few dollars per machine per month — a fraction of one day of downtime.

5. Lock down email

Business email compromise — a fake "invoice, please pay" from what looks like your MD — is now the most expensive attack category for Kenyan SMEs. SPF, DKIM and DMARC records stop most spoofing, and a good spam filter catches the rest.

6. Back up on the 3-2-1 rule

Three copies of your data, on two different media, with one copy offline or immutable. Ransomware specifically hunts for connected backups, so an offline copy is what turns an attack from a crisis into an inconvenience. Test a restore every quarter.

7. Give people the least access they need

An accountant does not need domain admin. When staff share passwords "because it's faster", one compromised account becomes a company-wide breach. Review permissions every six months and the day anyone leaves.

8. Segment the network

Guest Wi-Fi on the same network as your accounting server means one infected phone reaches everything. Separate VLANs for guests, staff and servers cost almost nothing to set up and limit how far an intruder can move.

9. Write a one-page incident response plan

Who do you call in the first hour? Who can authorise taking systems offline? Which clients must be notified? A single page, printed and signed, removes the panic decisions that make breaches worse.

10. Train the humans, twice a year

Most attacks arrive by phishing. A 30-minute session every six months — showing real Kenyan examples, not generic slides — cuts click rates dramatically. Make it easy to report a suspicious email without blame.

The three things most businesses get wrong

• Backups that have never been tested. A backup you cannot restore is a rumour, not a plan.
• MFA on email but not on the finance portal. Attackers go where the money moves.
• No named owner for security. "The IT guy handles that" means nobody handles it.

For wider context on how these attacks evolve, the security teams at PCWorld and PCMag publish ongoing coverage of ransomware and endpoint threats worth following.

Moving Your ERP to the Cloud: A Practical Guide for Nairobi Businesses

Every ERP owner eventually faces the same decision: keep the server humming in the back room, or move to the cloud. For most Nairobi businesses the triggers look alike — ageing hardware, a new branch that needs access, month-end reports that only work in the office, or an IT person who is the only human who knows how the thing is backed up.

We have guided more than 30 ERP migrations. Here is what actually matters, stripped of vendor jargon.

When migration makes sense — and when it doesn't

Migrate if your team works from multiple locations, your hardware is past warranty, or growth keeps outrunning your infrastructure. Hold off if your ERP version is ancient and unsupported by the vendor — migrate the application first, then the hosting, in that order. Doing both at once is how projects double in scope.

Choose the hosting model before the provider

Three realistic options for Kenyan businesses:

• Public cloud (Microsoft Azure, AWS): best resilience and global reach; billed monthly per usage. Runs well when paired with good local fibre. Microsoft Azure remains the default for Microsoft-stack ERPs.
• Managed private cloud with a Kenyan provider: predictable monthly cost, local support, and in-country data residency.
• Hybrid: sensitive payroll data stays in-country while heavier workloads run in the cloud. Common compromise, slightly more moving parts.

Kenya's Data Protection Act, 2019 gives you a legal reason to think about where data lives; the Office of the Data Protection Commissioner publishes guidance on cross-border transfers that is worth reading before you sign any hosting agreement.

Plan bandwidth like it is part of the project

A cloud ERP is only as good as the line it rides on. Budget for a primary fibre connection plus an LTE or 5G failover with automatic switchover. In our experience, "the cloud is slow" almost always turns out to be one office on a single congested link.

The four migration phases

• Assess (2–4 weeks): inventory integrations, customisations, reports and users. This list becomes your acceptance checklist.
• Pilot (2–3 weeks): replicate the ERP in the cloud and run one department on it in parallel. Measure real response times from the offices that will use it.
• Cut over (a weekend): final data sync, DNS and firewall changes, and a rollback point you have actually rehearsed.
• Stabilise (2–4 weeks): daily monitoring, performance tuning, and a freeze on new customisations until things settle.

The costs nobody quotes you

Licence-to-cloud pricing is the headline, but the line items that surprise businesses are data egress fees, the failover internet connection, post-migration tuning hours, and retraining for the two power users whose spreadsheets break. Ask for all four in writing before you approve the project.

Security moves with you — if you carry it

Cloud does not automatically mean secure. MFA on the ERP login, role-based access, encrypted backups in a separate region, and log monitoring are the minimum. Reviews from PCWorld and PCMag are useful shorthand when comparing cloud security tooling — but a configuration review by someone who knows your systems beats any review site.

How to Connect M-Pesa to Your Website or ERP (Without the Headaches)

M-Pesa moves a meaningful share of Kenya's economy every day, and customers expect it at checkout — on your website, in your app, and on your invoices. Connecting it properly is straightforward once you understand the moving parts. Connecting it carelessly is how you end up reconciling payments by hand every Friday.

Here is how we approach M-Pesa integrations, and the mistakes we most often have to undo.

Start on the Daraja portal

Safaricom's Daraja developer platform is the official gateway to M-Pesa APIs. You will create an app, get a consumer key and secret, and request the products you need. For most businesses that is STK Push (Lipa na M-Pesa Online) to trigger a payment prompt on the customer's phone, plus Transaction Status and B2C if you pay people out.

STK Push: what actually happens

Your server asks M-Pesa to prompt the customer; the customer enters their PIN; M-Pesa posts a confirmation to your callback URL. Two details decide whether this feels magical or broken:

• The callback URL must be publicly reachable and HTTPS. A URL that works in development but not in production is the single most common cause of "payments succeed but nothing updates".
• Never treat the prompt as the payment. Only the callback confirms money moved. Update your order status from the callback payload, not from the user closing the dialog.

Idempotency and reconciliation: the unglamorous 80%

Networks retry. Users double-tap. Callbacks arrive twice. Your integration must treat a repeated transaction reference as the same payment, not two. Keep a permanent ledger of every request and callback — when finance asks about the KES 47,000 that shows in the till but not in the ERP, that ledger answers in minutes instead of hours.

Reconcile daily against the M-Pesa statement, not weekly. Discrepancies are easy to fix on day one and painful on day thirty.

The mistakes that cause payment failures

• Hardcoded test credentials in production. Sandbox keys behave differently; ship production keys from a config, not from the code.
• No timeout handling. If the customer does not enter a PIN, the request expires — show that state honestly and let them retry, rather than spinning forever.
• Storing raw phone numbers in five formats. Normalise to 2547XXXXXXXX once, at intake.
• Ignoring till vs paybill differences. Settlement times and statement formats differ; your reconciliation code must know which is which.

Then connect it to the ERP

Once payments flow reliably, the last mile is posting each confirmed transaction into your ERP — sales invoice, payment, customer ledger — automatically. That is the step that turns M-Pesa from a payment button into real time saved for your finance team. Newsletters and reviews from outlets like PCWorld and PCMag cover payment technology trends broadly, but for Kenya the rule is simpler: integrate to Daraja directly, keep the ledger, reconcile daily.