October can bring people into a conversation they might usually leave to the IT team. There are talks, training sessions and reminders to pay attention. Then November arrives, the calendar fills up again and everyone returns to the work waiting on their desk.
That is when the useful part begins. Can the people responsible for an essential service explain what keeps it running, who makes decisions if it is disrupted and which known weaknesses still need fixing?
Key takeaways
- Choose the services that matter most to customers, employees or the public, and give each one a business owner.
- Bring business, technical and supplier teams together to identify what those services depend on.
- Agree who makes decisions during disruption and who communicates with employees, customers and providers.
- Exercise the plan with the right people, then check that the weaknesses it reveals have actually been fixed.
- Keep the work on the management calendar throughout the year, especially when systems or suppliers change.
What should organisations take from October?
Ghana’s National Cyber Security Awareness Month programme has focused this year on securing the country’s digital finance ecosystem through collaboration and cyber resilience. Its final week includes the National Cyber Drill, scheduled for 26–30 October. A cyber drill gives participants a chance to work through a simulated disruption and see how their decisions, communications and coordination hold up.
It is a useful idea to carry beyond the event. The Cyber Security Authority has called for cooperation across financial institutions, telecommunications companies, technology providers and public bodies to become part of daily operations. The Ministry of Communication, Digital Technology and Innovations has also drawn attention to the systems and operational processes behind essential services, which extend beyond conventional IT.
Awareness campaigns give people time to learn and to talk across departments. Their value grows when an organisation takes what surfaced in October and gives someone the job of doing something about it.
Start with a service someone would miss
It is tempting to begin a resilience discussion with a list of servers, applications and suppliers. Those details matter, but they make more sense once the organisation has named the service they support.
For a payment provider, that could be a merchant’s ability to accept and reconcile payments. For a hospital, it could be staff access to the information needed to treat a patient. For a public agency, it might be an application process that people rely on every day. Each example gives the people around the table a clear task to follow from beginning to end.
Give that service an owner from the business. They should be able to explain who relies on it, what happens when it stops and what choices the organisation would face. IT and security colleagues can then identify the technology involved. Leadership should agree which services need attention first, based on their importance and any obligations that apply.
Follow the service across teams and suppliers
Once the service has an owner, trace what it takes to deliver it. Include the application, usable data, staff access, connectivity, cloud services and physical infrastructure. Add the external suppliers and the people who can authorise a change.
An online ordering system illustrates why this matters. The application may be running while employees cannot sign in, see a new order or confirm a payment. Perhaps a supplier has to act before normal work can resume. A map of the service brings those handovers into view before people have to deal with them under pressure.
Make the map useful rather than impressive. Who contacts each provider? How will they do it if the usual channel is unavailable? Which responsibility still needs to be agreed? Revisit the answers when a system, supplier or process changes.
Decide who can act and who needs to hear from you
A contact list helps people find one another. It cannot tell them who has authority to make a difficult decision.
For each important service, agree who can declare an incident, call in a provider, approve a temporary way of working and decide when the service is safe to use again. Operations may need to tell employees what they can continue doing. Communications may need to update customers. Risk and compliance colleagues may need to assess requirements that apply to the organisation.
These conversations can expose choices that are easy to overlook. Would a limited service help customers, or could it leave them with incorrect records? Who is authorised to make that call? Agreeing the roles in advance gives employees clearer instructions and gives leaders a better basis for decisions.
Exercise the plan, then return to what you found
Plans age. People move roles, suppliers change and a phone number that worked last year may no longer reach anyone. An exercise brings the business owner, relevant teams and providers together to find out whether the plan still makes sense.
The exercise should fit the service. It could be a discussion around a table, a check of contacts or a technical rehearsal. Afterwards, record what worked, what remains uncertain and who will fix each problem. Set a date to check the correction. Otherwise, the same gap can quietly survive until the next exercise.
There is no single testing timetable for every organisation. The service’s importance, its architecture, the rate of change and any applicable requirements should determine the schedule. For a closer look at the evidence a recovery exercise can provide, read “Your Disaster-Recovery Test Passed. What Did It Actually Prove?”.
Make room for the work after October
A routine keeps resilience work from depending on the next campaign or the memory of one diligent colleague. A monthly check could cover contact details, open actions and important changes. A quarterly discussion could revisit critical services and the systems and suppliers behind them.
Exercise dates should reflect the needs of each service. A major change of provider, application or process may deserve a review sooner. Management should be able to see unresolved risks and overdue actions, especially when nobody is quite sure which organisation owns the next step.
Those intervals are a practical starting point, not a rule for every business. Regulated organisations must also establish their own obligations, including any requirements relevant to them under the Bank of Ghana’s Cyber and Information Security Directive 2026.
Where does Onix fit?
Resilience planning often reveals a practical question: are your critical systems operating in the right place, with the connectivity and infrastructure they need? Onix operates a data-centre facility in Accra, Ghana. As a carrier-neutral colocation provider, Onix offers access to multiple networks and internet exchanges.
A data centre is one part of the plan. Your organisation still needs to understand its applications, data, access arrangements, suppliers and the decisions people must make when something goes wrong.
Frequently asked questions
When does Ghana’s National Cyber Security Awareness Month end?
The 2026 campaign ends on 31 October. The Cyber Security Authority’s programme schedules the National Cyber Drill for 26–30 October.
What should an organisation do after Cyber Security Awareness Month?
Start with its most important services. Give them business owners, identify their dependencies, agree who makes decisions during disruption and put reviews and suitable exercises into the calendar.
Who is responsible for cyber resilience?
Leadership, business-service owners, IT, security, operations, risk, compliance, communications and employees all have roles. External providers are responsible for their agreed parts of a service. The organisation needs to understand how those parts work together.
Which dependencies should a resilience plan include?
Include the applications, data, identity and access arrangements, networks, cloud services, physical infrastructure, suppliers and people needed to deliver each important service. The detail will differ from one service to another.
