If your organisation lost access to its most important system tomorrow, what would happen to the services people rely on?
Would staff still know which appointments were scheduled? Could they access the information needed to support clients? Could teams communicate across locations, coordinate urgent requests and make informed decisions?
For a not-for-profit, a technology outage can quickly become a service-delivery problem. The impact extends beyond unavailable applications to the people waiting for support, the employees trying to provide it and the trust placed in the organisation.
Cybersecurity helps reduce the likelihood of disruption. Cyber resilience also considers how your organisation would respond, maintain essential activities and recover. That makes it a shared concern for IT teams, operational leaders and executives.
1. Start with the services people depend on
A useful resilience discussion begins with the work your organisation needs to keep doing. Which services are time-sensitive? Which activities could pause briefly? Where would an interruption create the greatest consequences for clients, employees or community partners?
Consider a housing organisation coordinating urgent assistance, a disability-services provider managing scheduled support or a community organisation responding to requests for help. Each may depend on different systems, but all need a clear understanding of what must continue when technology becomes unavailable.
Start by asking:
- Which activities must continue during a disruption?
- What information do staff need to deliver those services safely and effectively?
- How long could each activity be interrupted before the consequences become significant?
- Which services could operate temporarily using an alternative process?
These conversations help establish recovery priorities. They also give IT teams something more useful than a general expectation that everything needs to be restored immediately.
2. Understand what those services rely on
Once critical activities are identified, connect them to the technology and external services that support them. A client-management application might be the obvious dependency, but staff may also need internet connectivity, working devices, an identity service to sign in and access to supporting documents.
This matters because restoring one application may not be enough to get people working again. A system can be available while employees remain unable to access it or complete the process it supports.
For example, a team coordinating community visits might need scheduling software, contact details, relevant service records and a way to communicate changes. A recovery plan that considers only the scheduling application could leave important gaps.
Include external providers in this review. Establish who to contact during an outage, what support arrangements apply and which recovery activities remain your organisation’s responsibility. For cloud applications, ask what happens if the service is unavailable or your organisation’s data needs restoring.
The aim is to understand the dependencies behind each essential service well enough to plan a workable response.
3. Agree on what recovery needs to achieve
“Get everything back as quickly as possible” is an understandable reaction to an outage. It provides little guidance, however, when people need to choose what to restore first or decide how much to invest in recovery capability.
Two practical questions can make the discussion more specific:
- How long can we manage without this system or service?
- How much recently created or updated information could we afford to lose?
IT teams may describe these as recovery time and recovery point objectives. For organisational leaders, their value is in making expectations explicit.
A system used for urgent service coordination may need a different recovery approach from an archive of older project documents. Likewise, losing a day of changes to active client records may have very different consequences from losing a day of edits to an internal presentation.
These priorities should be agreed between IT and the people responsible for delivering services. They should then be checked against what the current technology, supplier arrangements and recovery processes can realistically achieve.
Where expectations and capability differ, the organisation has a clear issue to address before an incident forces the decision.
4. Check that backups translate into usable recovery
Backups are an essential part of recovery, but a successful backup notification does not demonstrate that a service can be restored within the required timeframe.
A useful review asks whether the right information is protected, whether backup copies are protected from unauthorised alteration or deletion, and whether staff can carry out the restoration process. Australian Signals Directorate guidance emphasises testing restoration as part of disaster recovery exercises, including identifying and managing dependencies.
The practical questions include:
- Does backup coverage include the information and systems needed for critical services?
- Could compromised accounts also affect the backups?
- When was a representative recovery last tested?
- How long did it take, and what remained unavailable?
- Did the relevant operational staff confirm that the restored information was usable?
For Microsoft 365 and other cloud applications, establish exactly what recovery arrangements are in place, what they cover and where their limitations sit. Ask your IT team or provider to explain how those arrangements meet your organisation’s requirements.
Testing should connect technical restoration to the work people need to perform. Recovering a set of files is useful; confirming that staff can locate the right records and resume an essential activity provides stronger evidence of readiness.
5. Plan how people will work during the interruption
While IT staff investigate and recover systems, other employees still need direction. They need to know which activities can continue, what alternative processes are approved and when to escalate a situation that cannot safely wait.
Temporary arrangements need careful thought. Asking staff to improvise with personal email, unmanaged devices or ad hoc copies of sensitive records could create additional problems during an already difficult situation.
For each critical service, consider what a practical temporary operating process would involve. Who can authorise it? What information is required? How will that information be protected? How will work completed during the outage be recorded and reconciled afterwards?
Communication also deserves its own plan. If normal email or collaboration tools are unavailable, staff need an agreed alternative and access to current contact details. ASD’s incident-response planning guidance specifically includes backup communication channels and communication that supports business continuity.
Responsibilities should be clear before an incident occurs. Identify who coordinates the response, who makes service-priority decisions, who liaises with technology providers and who approves updates to affected stakeholders. Make sure essential instructions can be accessed if the systems that normally hold them are unavailable.
6. Keep prevention and recovery connected
Planning for disruption sits alongside the everyday work of protecting the organisation. Maintaining systems, securing access, reviewing permissions and helping employees recognise and report suspicious activity remain part of that work.
Recovery planning adds another set of questions: if those protections are bypassed, how will the organisation limit the consequences and restore services safely?
Following a cyber incident, restoring systems may require investigation, containment and checks that the environment is safe to use. Bringing services back prematurely can expose them to further compromise. ASD guidance recognises the need to coordinate remediation while balancing operational risk and business continuity.
This is where leadership and IT need a shared understanding. Pressure to resume services is entirely understandable, especially when people depend on them. Agreeing on decision-making responsibilities and temporary operating arrangements in advance helps the organisation manage that pressure.
Recovery also does not resolve every consequence of an incident. Restoring access to information, for example, does not undo any unauthorised disclosure that may have occurred. The wider response needs to account for the nature and impact of the incident.
A practical starting point: walk through one service
A manageable first step is to choose one important service and bring together the people responsible for its delivery, technology support and operational decisions.
Ask a simple question: “If the system supporting this service became unavailable tomorrow morning, what would we do?”
Walk through the first hour, the rest of the day and a longer interruption. Identify what staff would need, who they would contact, what could continue and where assumptions begin to replace clear answers.
Record the gaps and assign responsibility for the next actions. Those might include checking a supplier’s recovery arrangements, testing a restoration process, updating contact details or documenting a temporary way of working. A discussion exercise can reveal uncertainty; technical testing is then needed to validate the recovery capabilities it depends on.
For a not-for-profit, cyber resilience supports the organisation’s ability to fulfil its commitments when circumstances become difficult. It helps protect the people relying on services and gives employees clearer direction when their usual tools are unavailable.
The aim is to know what must continue, how recovery will work and who will make the decisions that keep your organisation moving.
Comments