Start with the business, not the threat list
Cybersecurity risk becomes useful when it is connected to an operating consequence. Begin by identifying the services that must stay available, the information that must remain confidential and the records whose integrity supports payments, contracts or regulated decisions. A distributor and a legal practice may use similar technology, but interruption affects them differently. That context determines which controls deserve priority and which improvements can wait.
The aim is not to predict every attack. It is to understand plausible paths to material harm and make deliberate choices about them. Describe scenarios in plain language: an administrator account is taken over, a supplier mailbox redirects a payment, a cloud workload becomes unavailable, or sensitive information leaves through an unmanaged device. Each scenario should have an owner, existing safeguards and a decision about further treatment.
Map identities, information and dependencies
An asset list should extend beyond laptops and servers. Include cloud tenants, business applications, privileged identities, shared mailboxes, service accounts, domains, backup platforms and the suppliers that can access them. Record who owns each service, what information it handles and what other systems it depends on. A short, maintained map is more useful than a comprehensive inventory that becomes stale.
Identity and email deserve particular attention because they connect people to almost every modern service. Review how accounts are created and removed, how administrators are protected, where multi-factor authentication is enforced and whether emergency access is possible. Then trace critical information: where it enters, who can change it, where copies accumulate and how it is recovered.
Treat suppliers and remote work as part of the system
Risk does not stop at the organisation’s network boundary. Managed service providers, payroll platforms, accountants, cloud vendors and contractors may hold information or possess access that can affect operations. Record the purpose and duration of that access, require named ownership and remove it when the relationship changes. Contract language matters, but technical controls and periodic review are what make the intent observable.
Remote and hybrid work also change the control environment. A practical baseline covers managed devices, supported operating systems, encrypted storage, secure remote access, timely patching and a clear process for lost equipment. Controls should be usable enough that people do not create workarounds simply to complete ordinary work.
Build recovery as a business capability
Prevention reduces likelihood; it does not remove the need to recover. Define acceptable disruption and data loss for important services, then test whether backups, alternative processes and responsible people can meet those expectations. A successful backup notification is not the same as a successful restoration. Exercises should include unavailable email, compromised administrator accounts and decisions about when a rebuilt system is trustworthy enough to return to service.
Incident preparation also needs communication paths that do not depend on the affected environment. Maintain current contact details for decision-makers, technical specialists, legal advisers and critical suppliers. Establish who may isolate systems, approve expenditure, communicate with customers and make notification decisions. These are governance questions as much as technical ones.
Make governance visible and repeatable
South African organisations should consider legal and contractual duties, including obligations related to personal information, with advice from qualified counsel. Security teams support that work by documenting information flows, access decisions, safeguards, incidents and corrective actions. They should not turn a framework into a claim of compliance that has not been independently established.
Use a regular review cycle: confirm critical services, reassess material changes, test a small number of important controls and report unresolved decisions to the right level of leadership. NIST Cybersecurity Framework 2.0 provides a useful common language through Govern, Identify, Protect, Detect, Respond and Recover. The framework structures discussion; management remains responsible for priorities and risk acceptance.
What to do next.
- ✓Name the owner of each critical business service.
- ✓Protect privileged and remote access with strong multi-factor authentication.
- ✓Document supplier access and remove it when no longer needed.
- ✓Test restoration of critical data and systems, not only backup completion.
- ✓Create an incident contact list that works when normal email is unavailable.
- ✓Review material risks, owners and due dates with leadership.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.