Backup and ransomware readiness: can you restore the work?

Start with the business operation, not a green backup dashboard

Name the activity that must resume: processing an order, accessing a customer record or producing an agreed operational report. Then identify the systems, data, permissions and people needed to perform it. Recovering a file is not the same as recovering that entire activity.

For a Kenyan business with several locations or cloud and on-premises systems, the useful questions are practical: which site or service can work, who can authorise restoration, which dependency must return first and how the team operates while recovery is in progress. These are requirements to establish, not assumptions about Foxbyte’s capacity or your current setup.

Backups are not the whole ransomware defence

Backups support recovery; they do not prevent every intrusion, credential misuse or data disclosure. Protective controls, patch/configuration work, account security and alert handling remain necessary discussions. A recovery copy also does not reverse information that has already been exposed.

CISA recommends offline, encrypted copies and regular backup testing as part of ransomware resilience, alongside updating systems. Apply that principle to your actual technology and authorisation model rather than interpreting it as a universal product prescription. CISA: Stop Ransomware guidance.

Foxbyte’s Managed Cybersecurity service concerns agreed preventative and management responsibilities. Data Recovery concerns assessment of lost data. Those are related but different services; neither is a guarantee of ransomware decryption.

Define recovery objectives in business language

A recovery point objective describes the point in time to which information needs to be recovered. A recovery time objective describes the tolerated recovery period in relation to the business’s needs. NIST publishes these terms with their source context. Recovery point objective; recovery time objective.

Translate them into a decision: how much recent work could the business reconstruct, and how long could the required operation be unavailable? Different systems may have different answers. These are targets to design and test, not commitments established by choosing a number in a settings panel.

An illustrative ordering system might need a more recent recovery point than a rarely changed reference library. The restore sequence could still depend on shared identity, networking and an application database. Map those relationships before buying capacity.

Know what is copied, and what is missing

List data, applications, configurations and credentials required for recovery. Check the scope of laptops, servers, cloud storage, business applications and databases. Decide how consistent application/database state will be captured; a collection of files may not be sufficient for a working application.

Record exclusions openly. A backup report should not imply complete coverage while unmanaged devices or a third-party service sit outside the plan. Agree how new systems enter the inventory and how someone notices when a source stops being copied.

Separate recovery access from ordinary access

Ask who can change retention, delete copies, retrieve encryption material or restore data. A copy that every compromised administrator can erase may not provide the intended isolation. Evaluate offline, separately administered or retention-protected approaches for the actual platform.

Do not put recovery secrets into public forms, ordinary email or shared documents with broad access. A named recovery owner needs controlled access, with a safe alternative if that individual is unavailable. Account lockout and supplier availability belong in the dependency plan.

A useful restore test produces evidence

Test in a manner that does not overwrite working production information or disrupt customers without explicit approval. Select a representative object or isolated recovery target. Record what was restored, the recovery point, duration, integrity checks, access used and the application or business validation performed.

For files, ask whether the intended user can open the restored material. For an application, test whether the required operation actually works with the recovered database and configuration. Record failures and retest the corrected process. A screenshot saying a backup job completed is not equivalent evidence.

Repeat testing when relevant systems, permissions or recovery procedures change and at the agreed operational interval. This guide does not prescribe destructive tests on a live business system or claim that a previous test guarantees every future recovery.

Plan the first decisions during disruption

Maintain approved internal contacts, supplier contacts, decision authority and a communication route that does not depend entirely on the affected system. Agree who can isolate systems, commission specialist assistance and approve restoration. Keep the plan accessible to authorised people when the normal network is unavailable.

Preserve relevant evidence and avoid improvised actions that could destroy recoverable data. An active incident needs the organisation’s response procedure and appropriate qualified assistance, not an assumption that a normal support enquiry is an emergency-response contract. Foxbyte’s published support hours and separately agreed service scope still apply.

Use a short readiness record

Mark unknown answers as unknown. A short truthful exception list is more useful than a completed questionnaire unsupported by evidence. Do not label this worksheet a compliance attestation.

Agree the next practical step

Start with one important business operation and its dependencies. Review current copies and permissions, then scope a safe restore exercise and the gaps it should answer. Use the managed-security comparison to place recovery within wider responsibilities.

Discuss backup and recovery readiness