Critical Incident Recovery Support
Bring structure and senior expertise to a critical technology incident.
Triage, stabilisation, recovery, root-cause analysis and recurrence reduction for selected enterprise environments.
Discuss this requirement →Start with the environment, risk and required outcome.
Triage, stabilisation, recovery, root-cause analysis and recurrence reduction for selected enterprise environments. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Stabilise first. Recover safely. Reduce recurrence.
Managed IT Services 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.
Clear steps. Visible decisions.
If you have an incident right now
Call 087 188 3388
Existing clients reach the standby escalation. If you are not a client, say so on the call and we will tell you honestly and immediately whether we can help within a useful timeframe.
What we will ask for
What is unavailable and since when. What changed recently. What you have already tried. Who is currently working on it. Whether personal information may be involved. Whether you have backups and when they last ran.
What we will do first
Establish what is actually affected rather than what is being reported, put one person in charge of coordination, stop uncoordinated remedial actions, and start a written timeline.
One thing worth doing before you call
Stop making changes. Uncoordinated attempts to fix a major incident destroy evidence, complicate diagnosis and occasionally make recovery harder. Note what has already been done and by whom.
What coordinated recovery means
Most major incidents are made longer by their own response rather than by their technical difficulty. Four failures account for most of it.
Nobody is in charge. Several capable people work in parallel on overlapping theories, two areas get looked at three times and one is not looked at all.
The people fixing it are also fielding calls. Every executive wants a status. The person best placed to solve the problem spends half the event explaining that they do not yet have an answer.
Actions are not recorded. Nobody can say what has been tried, so things get tried twice. Afterwards there is no timeline, which matters for the review, for insurers and for any regulatory notification.
Recovery runs in the wrong order. Systems come back before what they depend on, and fail again. Identity before applications. Database before application tier. Network before all of it.
The structure we bring
One incident commander who coordinates and does not do the technical work. That separation is the single most effective thing available and the first to collapse under pressure.
A single bridge. One call or channel where the work happens.
A written timeline, captured live rather than reconstructed. It is what the review works from and what an insurer or the Information Regulator will ask for.
Scheduled communication. Updates at fixed intervals to a defined stakeholder list, including when there is nothing new. Silence generates more calls than a holding update, and those calls land on the people trying to fix things.
A recovery sequence respecting dependencies, with verification at each stage before the next begins.
A decision log. What was decided, by whom, on what information. Decisions made under pressure with incomplete information are defensible. Undocumented ones are harder to explain later.
Recovery sequence
The order is not a preference. Systems fail again if brought up before their dependencies.
1. Contain
Stop it spreading or worsening. Isolate affected segments where the network allows it, which is what the segmentation on network security buys you.
2. Assess
Establish scope accurately. What is affected, what is not, what evidence exists. Resist the pressure to start restoring before this is done, because restoring into an unknown state can undo itself.
3. Preserve evidence
Before rebuilding, capture what will be needed for the review, for insurers and for any POPIA notification. Rebuilding destroys evidence and it cannot be recovered afterwards.
4. Restore infrastructure
Network, then identity and directory services, then storage. Nothing above this layer works properly until it is sound.
5. Restore data and applications
In dependency order, verifying each before proceeding.
6. Verify
Confirm systems function rather than that they started. Check integrations, scheduled jobs and interfaces, which are where partial recovery hides.
7. Return to normal operation, including reconciling anything captured manually during the outage. This step is routinely the longest and it is the one least often planned for.
8. Review. Within five business days, blameless and factual, with actions that have owners and dates.
Readiness, which decides the outcome
Almost everything that determines how a recovery goes is settled beforehand.
A restore point you can trust and have tested. Covered on backup and recovery and, for compromise scenarios, on cyber resilience.
A documented recovery sequence with dependencies mapped. The dependency nobody knew about is discovered during recovery, at the worst possible cost.
Identity recovery documented and held offline
Long, unfamiliar and required early.
Decision authority named, with deputies
Who can authorise disconnection, external help and notification.
Contact details that work without the network
Printed, held by named people, verified quarterly. A contact list on the file server is not a contact list.
Communication templates drafted in advance
Nobody writes well under pressure.
Segmentation, so containment is possible without stopping everything.
Half a day of readiness work changes a recovery more than any amount of effort during one.
What Namandla delivers
Incident coordination. Commander, bridge, timeline, communication and recovery sequencing.
Technical recovery across infrastructure, identity, data and applications, within the scope we can access.
Third-party coordination. Vendors, carriers, insurers and specialist responders, so you are not making those calls.
Evidence preservation to support the review, an insurance claim and any regulatory notification.
Post-incident review within five business days, with actions tracked to closure.
Readiness work, which is the part we would rather sell you: documented sequences, tested restores, named authority and drafted communications.
Remote coordination nationally, onsite in Gauteng.
We are not an emergency service. Our response commitments are P1 in 30 minutes for clients under agreement, including after hours through the standby rota. For organisations without an agreement, we will tell you on the call whether we can help in a useful timeframe rather than accepting the work and arriving late.
Common questions about Critical Incident Recovery
Can you help if we are not already a client?
Sometimes, and we will tell you on the call rather than after. Capacity, the nature of the incident and whether we can get useful access all determine it.
Where we cannot help within a useful timeframe we will say so immediately, because a provider who accepts the work and arrives too late has made the situation worse. Where we can, we will be clear about what we can and cannot commit to without prior knowledge of your environment.
What are your response times during a major incident?
For clients under agreement, P1 is 30 minutes, including after hours through the standby escalation, with continuous work until service is restored.
Response means an engineer who can work the problem has made contact and started, not an automated acknowledgement. Business hours are 08:00 to 17:00 Monday to Friday, and the standby rota carries severity 1 outside them.
What should we do before calling?
Stop making changes and note what has already been tried, by whom and when. Uncoordinated remedial attempts destroy evidence, complicate diagnosis and occasionally make recovery harder.
Also useful: when the problem started, what changed recently, whether backups have been running and whether personal information may be involved. Those four answers shape the first half hour more than anything else.
Why does having one person in charge matter so much?
Because without it, capable people work in parallel on overlapping theories. Some areas get investigated three times and one gets missed entirely, and nobody can say what has been tried.
The commander coordinates and does not do the technical work. That separation is the first thing to collapse under pressure and it is the single most effective structural intervention available during an incident.
How long does recovery take?
It depends on what is affected and on what was in place beforehand. Restoring from a tested backup with a documented sequence is measured in hours. The same restore without either is measured in days.
The variables that matter are whether you have a restore point you trust, whether it has been tested, whether the recovery sequence is documented and whether identity can be recovered. Those four are decided long before the incident and they set the range.
What about evidence and POPIA notification?
Preserve evidence before rebuilding, because rebuilding destroys it permanently. Under POPIA section 22, notification to the Information Regulator and affected data subjects is required where there are reasonable grounds to believe personal information was accessed without authorisation.
Establishing what was accessed requires logs that were retained and stored where the affected environment could not delete them. That is a decision made in advance. We capture what exists and give your information officer an accurate technical picture to decide from.
Do you do post-incident reviews?
Yes, within five business days, blameless and factual, working from the timeline captured during the incident rather than from memory.
The five-day window matters because detail is lost quickly and the urgency to act on findings fades. Blameless is a practical requirement rather than a courtesy: reviews that assign fault produce defensive accounts, and defensive accounts are inaccurate.
What readiness work has the biggest effect?
A restore point you have actually tested, a documented recovery sequence with dependencies mapped, and named decision authority with deputies.
Those three change more than anything done during an incident. If you do nothing else from this page, verify that a restore works, write down the order systems come back in, and decide who has authority to disconnect and to notify.
Can you work alongside our existing provider during an incident?
Yes, and coordination between multiple parties is often exactly what is missing. We can hold the timeline, the bridge and the communication while your provider does the technical work in their area.
We do not use an incident to compete for the account. During an event the objective is restoration, and afterwards the review is factual about what happened rather than an argument about who was responsible.