Cybersecurity Risk, Resilience & Operational Protection · Data Sheet
Cybersecurity Assessment & Control Findings
Evidence-led assessment outputs, risk implications and control priorities — reported as findings, with nothing presented as an achieved outcome.
Evidence status
This publication reports assessment findings, existing controls and recommended priorities.
It does not present unverified savings or post-remediation outcomes as achieved results.
Assessment snapshot
Each finding, and why it matters
Scroll table sideways →
| Area | Evidence | Why it matters |
|---|---|---|
| Central monitoring | No SIEM or equivalent central security-event capability identified. | Without consolidated logs and alerts, suspicious activity stays fragmented across systems and becomes harder to detect and investigate. |
| Threat, intrusion and vulnerability detection | Dedicated detection capability was not evidenced. | Preventive tools alone cannot provide assurance that hostile activity, misconfiguration or exploitable exposure will be found. |
| Critical financial system exposure | Publicly reachable ports and services around a critical finance platform, flagged for specialist validation. | An open port is not automatically a vulnerability — but unnecessary or weakly protected exposure increases attack surface and must be justified, restricted and monitored. |
| Endpoint protection | Antivirus present, but managed per device rather than through a central operational view. | Central management improves configuration consistency, health visibility, remote response, and evidence that protection is active and current. |
| Cloud backup and recovery | Independent backup coverage and recovery assurance not clearly evidenced. | Cloud service availability does not by itself prove recoverability from deletion, ransomware, account compromise or provider-side incidents. |
| Critical application recovery | Third-party support in place, but backup reporting, ownership of recovery assurance and interpretation of backup status required scrutiny. | Outsourced support does not remove the organisation's need to understand recovery evidence, responsibilities and restoration readiness. |
| Phishing awareness | A phishing-simulation and awareness capability existed. | Awareness is useful, and does not replace MFA, mail security, identity controls, logging, verification procedures and incident response. |
Control priorities
Seven responses, all recommended rather than implemented
Scroll table sideways →
| Priority area | Practical response |
|---|---|
| Central visibility | Right-sized central logging and security monitoring. Depending on scale, that may be SIEM, managed detection and response, or a managed service — not necessarily an enterprise platform. |
| Vulnerability management | Authenticated and external assessment of critical systems; validate exposed services; document remediation ownership; retest material findings. |
| Endpoint governance | Move endpoint security into centrally managed policy, health monitoring, alerting and remote response, with defined coverage and exception reporting. |
| Backup and restore | Define independent backup requirements for critical cloud and server workloads; monitor success; protect backup administration; and test restoration rather than relying on job status. |
| Identity and email | MFA, privileged-access control, secure mail configuration, anti-phishing controls, and out-of-band verification for sensitive payment or account-change requests. |
| Critical application assurance | Map ownership, hosting, public exposure, administrator access, vendor responsibilities, backup evidence, recovery dependencies and escalation. |
| Incident readiness | Practical escalation, containment, evidence preservation, communication and recovery procedures — including POPIA security-compromise notification where applicable. |
What should be measured
Eight measures, each with the evidence expected
Scroll table sideways →
| Measure | Evidence expected |
|---|---|
| Endpoint coverage | Percentage of in-scope devices enrolled in central security management, current, and reporting without unresolved critical alerts. |
| Identity protection | MFA and conditional-access coverage for privileged, remote and high-risk accounts; periodic privileged-access review. |
| Logging coverage | Critical systems and identity sources forwarding security-relevant logs to a central monitoring capability. |
| Vulnerability ageing | Critical and high-risk findings by age, business owner, remediation status and accepted exception. |
| Backup assurance | Backup success evidence, plus periodic restoration tests for critical information and systems. |
| Email control posture | Authentication and anti-spoofing controls, high-risk mailbox protection, malicious-message detection, sensitive-request verification. |
| Response readiness | Current incident contacts, a tested escalation path, evidence-preservation process, and post-incident lessons tracked to closure. |
| Third-party assurance | Critical suppliers with defined security responsibilities, breach-notification obligations, recovery expectations and evidence reviews. |
Measures should be selected to match the organisation's risk profile and technology estate, rather than reported as activity for its own sake. Cybersecurity becomes governable when management can see whether controls are actually operating.
Reference basis
The legal and technical frame
Scroll table sideways →
| Reference | Relevance |
|---|---|
| POPIA sections 19–22 | Security safeguards, operator responsibilities and security-compromise notification obligations. |
| Information Regulator guidance | Practical breach-handling steps and the eServices reporting route for security compromises. |
| Cybercrimes Act 19 of 2020 | Criminal-law framework for unlawful access, interception, interference and related conduct. |
| NIST Cybersecurity Framework 2.0 | Lifecycle model: Govern, Identify, Protect, Detect, Respond and Recover. |
| ISO/IEC 27001:2022 | Information security management system requirements and a risk-based governance reference point. |
Neither framework requires every organisation to deploy the same technology stack. The relevant question is whether the controls are proportionate, implemented and evidenced.