Cyber Resilience and Recovery
Strengthen critical systems without pretending risk can be eliminated.
Harden servers, privileged access, remote connectivity, logging, segmentation and ransomware recovery readiness.
Discuss this requirement →Start with the environment, risk and required outcome.
Harden servers, privileged access, remote connectivity, logging, segmentation and ransomware recovery readiness. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
Why resilience is separate from security
Security work reduces the likelihood of an incident. Resilience work reduces the consequence of one. They use different controls, they are funded differently and an organisation can be strong in one and absent in the other.
The distinction becomes concrete during an event. Prevention has already done whatever it was going to do. What determines the outcome from that point is a different set of questions:
- Can you establish what happened, and from what evidence?
- Can you isolate part of the estate without stopping all of it?
- Do you have a restore point you can demonstrate is clean?
- Can you rebuild identity, which everything else authenticates against?
- Do you know who decides, who communicates and what the notification threshold is?
- Can you operate at a reduced level while recovery runs?
Most organisations have invested in prevention and can answer none of those. That gap is what this page addresses.
What resilience actually requires
An isolated recovery path
The core requirement. A restore path that does not depend on the environment being recovered.
Backup copies that cannot be altered or deleted within their retention period, including by an administrator. Immutable storage, object lock or an air-gapped copy. A repository reachable with credentials from the environment it protects shares that environment’s position.
Retention long enough to reach a clean point. This is the requirement most often set too short. If the only surviving copy is more recent than the point at which the environment was compromised, immutability did not help. Retention has to cover the gap between compromise and detection, which is generally longer than assumed.
A recovery environment that can be brought up separately from production, so that restoration and verification happen somewhere clean rather than back into an estate whose state is unknown.
Identity recovery
Almost everything authenticates against directory services. If identity is unavailable or untrusted, nothing else can be brought back meaningfully.
A documented and tested forest or directory recovery procedure is the least glamorous item on this page and it is the one that most often determines how long a full recovery takes. It needs to be written down, held offline and exercised, because it is a procedure nobody performs often enough to remember.
Segmentation as a containment tool
The segmentation described on network security has a second purpose here. A segmented network can be partially isolated. A flat one can only be switched off entirely.
The practical question is whether you can disconnect one segment, one site or one system group and keep the rest trading. On a flat network the answer is no, and the response to any incident becomes all or nothing.
Evidence and logging
Logs retained, and stored where the environment being investigated cannot delete them. Without them, establishing what was accessed is guesswork, and under POPIA section 22 the notification obligation depends on having reasonable grounds to believe personal information was accessed. Accurate notification requires evidence.
Decide retention and storage location in advance. Reconstructing an evidence position after an event is not possible.
Reduced-mode operation
What the business does while systems are unavailable. This is continuity work rather than security work and it comes from the impact analysis on business continuity planning, including the manual workarounds, who authorises them and how the data gets reconciled afterwards.
Decision and communication readiness
Who has authority to disconnect, to engage external help and to notify. Named, with deputies, decided in advance. Communication templates drafted for staff, customers, suppliers, insurers and the Information Regulator.
Deciding these while an incident runs produces slow and inconsistent decisions, and the people best placed to decide are usually the ones least available at that moment.
An untested capability is a set of assumptions
Clean-restore test. Restore a critical system into an isolated environment from an immutable copy and verify it functions. Annually per critical system, at minimum. This is the single most valuable exercise on the page because it tests the whole chain at once.
Identity recovery exercise. Rehearse the directory recovery procedure. Rare, disruptive to arrange and worth doing, because the procedure is long and unfamiliar by definition.
Isolation test. Confirm that you can actually disconnect a segment and that the rest keeps working. Frequently reveals a dependency nobody documented.
Tabletop exercise. Walk a scenario through with the decision-makers. Cheapest of the four and it consistently surfaces unclear authority and missing steps.
Every exercise produces findings with owners and dates. An exercise that produces none was not a real exercise.
Assess, close the gaps, prove it works
Resilience assessment. Backup immutability and retention against a realistic detection gap, recovery environment capability, identity recovery readiness, segmentation and containment capability, logging and evidence position and decision and communication readiness.
Design and implementation of the gaps, sequenced by consequence.
Clean-restore testing on a schedule, with measured recovery times recorded.
Identity recovery documentation and exercise facilitation.
Incident readiness. Response plan, roles and deputies, communication templates, evidence preservation steps and the POPIA notification path decided in advance.
Incident coordination if something happens, covered on critical incident recovery.
Remote delivery nationally. Onsite in Gauteng.
Common questions about Cyber Resilience
What is Cyber Security?
Cyber Security is a structured enterprise capability designed to improve reliability, control, security and operational continuity. The appropriate scope depends on the organisation’s systems, business impact, internal skills, service levels and risk requirements.
Why is Cyber Security important for businesses?
Organisations use cyber security to reduce operational risk, access scarce expertise, improve accountability and protect critical business services. A specialist partner should provide clear scope, evidence, reporting and escalation, not merely react to tickets.
What Cyber Security services should every business have?
Cyber Security should be evaluated against the organisation’s operational risk, systems, users, internal capability and required outcome. Namandla begins with evidence and recommends a proportionate service rather than a generic technology package.
What are the biggest Cyber Security threats facing businesses today?
Cyber Security is a structured enterprise capability designed to improve reliability, control, security and operational continuity. The appropriate scope depends on the organisation’s systems, business impact, internal skills, service levels and risk requirements.
How does Cyber Security protect against ransomware?
The process begins with discovery and a technical baseline, followed by prioritised remediation, controlled implementation, validation and operational handover. For cyber security, success should be measured against availability, recovery, performance, risk or service outcomes rather than activity alone.
What is a Cyber Security risk assessment?
Cyber Security is a structured enterprise capability designed to improve reliability, control, security and operational continuity. The appropriate scope depends on the organisation’s systems, business impact, internal skills, service levels and risk requirements.
What is cyber resilience?
Cyber resilience is the ability to keep operating through a security incident and recover from it cleanly. It is distinct from cyber security, which reduces the likelihood of an incident occurring.
The controls are different. Security is identity hardening, patching, endpoint control and detection. Resilience is immutable backup, a clean-restore path, identity recovery, containment capability, evidence retention and decided response authority. An organisation can be strong in one and have none of the other, and that is the common position.
How is this different from disaster recovery?
Disaster recovery assumes the infrastructure failed and the data is sound. Cyber resilience assumes the data or the systems may be compromised, so the restore point itself has to be established as trustworthy.
That changes the design. You need retention long enough to reach a point before the compromise, a way to verify a restore point is clean, and a recovery environment separate from the one being recovered. A traditional recovery plan restoring the most recent backup straight back into production does not meet that.
What does immutable backup mean?
A backup copy that cannot be altered or deleted within its retention period, including by an administrator. Object lock on cloud storage and hardened repositories on-premises both provide it.
It matters because a repository reachable with administrative credentials from the environment it protects shares that environment’s position. Immutability removes that dependency, and it is generally a configuration change on your existing platform rather than a new product.
How long should we retain backups for this?
Long enough to reach a point before a compromise would have occurred, which means covering the realistic gap between compromise and detection. That gap is usually longer than organisations assume.
This is the requirement most often set too short. Thirty days of operational retention is fine for accidental deletion and it may not reach far enough back for an incident that went unnoticed. A tiered schedule with short operational retention and longer immutable retention on critical systems is the usual answer.
Can you help us recover from ransomware?
Recovery depends almost entirely on what was in place beforehand: an immutable copy that could not be reached with compromised credentials, retention reaching a clean point and a tested restore path.
If those exist, recovery is a technical exercise with a measurable duration. If they do not, the options narrow considerably and none of them are good. That is the honest position and it is why the work described on this page is worth doing before it is needed rather than discussed afterwards.
Do we need a security operations centre?
Sometimes, and it is frequently bought before the foundations are in place.
Detection and response adds real value on an environment with identity hardened, patching under control, endpoints managed and logging retained. Bought before those, it produces alerts about an environment that cannot be remediated quickly, at significant recurring cost. Get the foundations right, then have the conversation with a clear view of what detection would add.
What does POPIA require after a security incident?
Section 22 requires notification to the Information Regulator and to affected data subjects where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person.
The practical consequence is that you need the evidence to establish what was accessed, which means logging and retention decided in advance rather than reconstructed afterwards. Whether a specific incident meets the threshold is a question for your information officer, and we make sure they have an accurate technical picture to decide from.
How do we test this without disrupting the business?
Clean-restore testing runs into an isolated environment and touches nothing in production. Tabletop exercises are a conversation. Only the identity recovery exercise and a full isolation test need planned windows.
The clean-restore test is the one to start with. It is non-disruptive, it tests the entire chain from immutable copy through to a functioning system, and it produces a measured recovery time that replaces an assumption with a number.
What is the first thing we should do?
Establish whether you have an immutable backup copy with retention long enough to reach a clean point, and whether a restore from it has ever been performed and verified.
If the answer to either is no, that is the highest-value work available and it is usually configuration on a platform you already own. Everything else on this page matters and none of it matters as much as having a restore point you can trust and have tested.
When is a full resilience programme more than we need?
On a small cloud-first environment with no on-premises servers, an immutable backup of your Microsoft 365 data, tested once, plus a documented list of who decides what, covers most of the realistic ground.
The programme scales with what you have to lose and what you have to evidence. Regulated data, contractual obligations to customers, operational technology or a large on-premises estate all raise the bar. If none of those apply to you we will say so.