Skip to content
Free consultation
Spiritus Systems
Back to Insights
Cybersecurity·8 min read·01 Sept,2026

Cybersecurity for Businesses: A Practical 2026 Playbook

8 min read·1,562 words·By Spiritus Systems

Updated 09 Sept,2026

Spiritus serves clients in Zimbabwe and beyond, combining local context with dependable digital systems built for growing organisations.

A cyber incident rarely arrives as a neatly labelled technical problem. It may begin with a convincing email, a reused password, an unpatched laptop, a compromised supplier account, or a backup that was never tested. The impact is commercial: payments are delayed, customer data is exposed, staff cannot work, and leaders have to make urgent decisions with incomplete information.

A practical security program begins with the systems, identities, and records your business depends on. Assign responsibility for access, updates, monitoring, and recovery. Spiritus helps scope these operating responsibilities around the applications a team actually uses.

Access Should Follow the Working Relationship

An employee, intern, or supplier may need access for a defined task. That access should have an owner, a purpose, and an end date. Shared accounts and untracked remote sessions make it harder to understand who performed an action or whether access is still needed.

Manage the Full Access Lifecycle

Temporary access should have an owner, an expiry date, and a written purpose. Before an intern, vendor, or contractor starts, define the systems they may use and the actions they may perform. During the engagement, review privileged access and remote sessions instead of assuming that a trusted person is a safe identity. At the end, disable accounts, revoke tokens, remove VPN and remote-support access, recover devices, rotate shared secrets, and confirm that forwarding rules or saved credentials are gone.

Keep an access register that a manager can understand without opening a technical console. It should show the person, organisation, role, device, systems, privilege level, approver, start date, and expiry date. A monthly review of this register is one of the least expensive ways to reduce the blast radius of a compromised account.

Remote-Access Tools Need Explicit Governance

Remote-support software can be legitimate and useful, but an unknown or hidden remote-access tool is a high-priority security event. Maintain an allow-list of approved tools, deploy them through managed software, require strong authentication, and log who initiated each session and what device was accessed. Endpoint controls should alert when an unapproved tool is installed, renamed, hidden, or launched outside an approved support window.

Do not rely on a tool name alone. Attackers can rename files or use legitimate administration software to blend into normal activity. Combine application inventory with process telemetry, network destinations, session times, and the identity of the person responsible for the device. When the business cannot explain a remote session, isolate the device and preserve the evidence before deleting anything.

Protect the Payment Path, Not Just the Login

Financial fraud often succeeds because several small weaknesses line up: one person can create and approve a transaction, alerts are not reviewed, reconciliations happen late, or a change request is accepted through an unverified channel. Map the payment journey from customer instruction to settlement and identify where a second person, an independent callback, or a system rule must intervene.

Use separate maker and checker roles for high-value or unusual transfers. Set velocity and amount thresholds, require step-up authentication for sensitive actions, reconcile outbound transactions against approved instructions, and alert on new beneficiaries, unusual destinations, after-hours activity, or bursts of small transfers. A dashboard that nobody owns is not a control; assign every alert a response time and an escalation path.

Logging That Helps Someone Act

Collect logs from identity providers, email, endpoints, firewalls, cloud services, payment systems, and critical applications in one protected location. At minimum, retain authentication events, privilege changes, software installs, remote sessions, mailbox rules, exports, configuration changes, and transaction approvals. Synchronise time across systems so investigators can reconstruct a sequence.

Log retention should match the time it may take to discover fraud. Protect logs from alteration, restrict who can delete them, and test that alerts actually reach a person. Review a small set of high-signal events every week instead of generating thousands of notifications that nobody can triage.

A Practical 30-Day Hardening Plan

In week one, inventory users, devices, applications, payment systems, data stores, remote-access tools, and backups. Mark anything that can move money, export customer data, or grant administrator access. In week two, remove dormant accounts, enforce multi-factor authentication, apply critical patches, and document the joiner-mover-leaver process.

In week three, implement maker-checker approval for sensitive transactions, configure alerts for new privileges and unusual transfers, and test a restore from backup. In week four, run a short incident exercise: isolate a device, disable an account, preserve logs, contact the right supplier, communicate internally, and recover a known-good service. Record the gaps and assign owners and dates.

Questions Leaders Should Ask

Ask who can access production systems today, how quickly access is removed when someone leaves, which remote tools are approved, who reviews privileged sessions, and how the business would detect a new administrator or unusual transaction. Ask when the last backup restore was tested, where the logs are stored, how long they are retained, and who has authority to isolate a device or pause payments.

These questions turn cybersecurity from a vague technology concern into an operating responsibility. The answers should be written, reviewed, and rehearsed with the people who would act during a real incident.

Start With Govern and Identify

The NIST Cybersecurity Framework provides a structure for organizing security work. Begin by identifying critical systems and assigning responsibility. Then connect protective measures with monitoring, response, and recovery activities appropriate to your environment.

Create a current inventory of users, laptops, phones, cloud accounts, domains, applications, databases, payment tools, and backups. Record who is responsible for each item and when access should be removed. You cannot protect an account nobody knows exists, and you cannot recover a system whose data location is unclear.

Protect Identity Before Everything Else

Identity is now the boundary around most business systems. Require unique passwords, multi-factor authentication wherever it is available, and separate administrator accounts for privileged work. Review forwarding rules and delegated access in email. Remove dormant accounts promptly when staff or contractors leave.

Keep permissions aligned with the job. A person who needs to view invoices does not automatically need to export the customer database or change payment settings. Least privilege reduces the damage a compromised account can cause and makes unusual access easier to spot.

Make Backups Recoverable

A backup is only useful if the business can restore from it. Keep more than one copy, separate at least one copy from the systems it protects, and protect backup access with strong authentication. Test a restore on a schedule that matches the importance of the data. Document how to recover the customer records, finance data, documents, and configuration needed to operate.

Define two simple targets: recovery time objective, how quickly the service must return, and recovery point objective, how much recent data the business can afford to lose. These targets help determine the right backup frequency and hosting design instead of leaving recovery to guesswork during an incident.

Secure Devices and Everyday Work

Laptops and phones are part of the production environment. Turn on automatic updates, disk encryption, screen locks, endpoint protection, and remote wipe where practical. Do not allow shared administrator passwords or unapproved software on devices that access customer or financial records.

Staff awareness is equally important. Teach people how to verify payment changes, recognise urgent impersonation, report a suspicious message, and use approved storage and collaboration tools. Training works best when it is short, repeated, and connected to real scenarios your team sees rather than presented as a once-a-year compliance exercise.

Detect, Respond, Recover

Decide what signals matter before there is an incident. Examples include repeated failed logins, a new administrator, a mailbox forwarding rule, an unusual export, a disabled security control, or a backup job that stops running. Alerts do not need to be sophisticated to be useful; they need an owner and a response path.

Write a one-page incident plan with emergency contacts, the person who can disable an account, the person who can isolate a device, the backup location, the customer communication owner, and the steps for preserving evidence. During an incident, clarity is more valuable than a long document nobody can find.

After recovery, review what happened without turning the exercise into blame. Which control failed? Which assumption was wrong? Which process should be changed? Feed those findings back into the system, the staff training, and the next access or backup review.

Third Parties and Cloud Services

Your security posture includes the suppliers who handle email, hosting, payments, accounting, support, and documents. Check how they protect accounts, notify customers, recover data, and handle access for their own staff. Keep a record of critical dependencies and a fallback contact for each one.

For smaller teams, a managed IT partner can provide the consistency that is difficult to maintain internally: device and account reviews, patching, backup checks, security monitoring, and a documented response process. The aim is not perfect prevention. It is to reduce exposure, detect problems earlier, and recover with confidence.

Cybersecurity is an operating discipline, not a once-off purchase. Start with identity, asset visibility, tested backups, device hygiene, and a response plan. Then improve the controls as the organisation, its systems, and its risks change. Spiritus Systems helps Zimbabwean businesses assess their environment and build practical security, support, and continuity workflows around the systems they rely on.

Explore Spiritus’s relevant services and contact our team to discuss the workflow described in this article.

Share
SS

Spiritus Systems

Software engineering consultancy based in Harare, Zimbabwe. Spiritus serves clients in Zimbabwe and beyond with custom ERP, CRM, mobile apps, and automation systems.

Plan your system support with Spiritus

Describe your critical applications and current support arrangements. We can discuss access, maintenance, backup, and recovery priorities.

Discuss system support