The Systems Audit Specialist, WHO Africa Region, David Oviaesu is charting an enviable path in information technology. He emphasises the goal to design systems that are both trustworthy today and adaptable tomorrow in balancing compliance with the need for innovation.
As a system audit specialist, how do you ensure that system controls are designed for long-term resilience beyond immediate crises?
I try not to design controls for the last crisis, but for the conditions that cause systems to fail over time. In real environments, things break, connectivity drops, people are under pressure, and assumptions don’t hold. If controls only work in perfect conditions, they won’t work when they are needed most. So I focus on simplicity, redundancy, and clear ownership. Controls should be easy to understand, resilient to disruption, and embedded into daily operations rather than treated as emergency add-ons. When systems are designed to adapt and evolve, they are far more likely to hold up long after the crisis has passed.
What strategic factors would you say guide your assessment of legacy systems during periods of transition or crisis?
I look at legacy systems less in terms of age and more in terms of risk. The first question is always, “What breaks first under pressure or what is the weakest part of the system?” That usually comes down to dependencies which include connectivity, manual workarounds, undocumented processes. I also assess how adaptable the system is. Can it be stabilized and improved incrementally, or does it require a full overhaul to survive the next disruption? During transitions or crises, the goal is not perfection; it’s continuity. So I focus on protecting core functions, reducing failure points, and making sure any changes don’t introduce new fragility while trying to fix old ones.
Amid organizational unexpected change, how do you audit a newly implemented system?
When a system is new and the organization is in flux, I audit it with a strong bias toward reality. The first thing I look for is whether the system is actually being used as intended under current conditions not how it was designed to work on paper. I focus on a few core questions: Are critical functions still running? Do people understand their roles when something goes wrong? And are there hidden workarounds emerging because the system does not fully match operational needs? Those workarounds often reveal the real risks.
Also, I audit change tolerance. When there are unexpected changes, we constantly adjust systems, sometimes informally. What I do is to pay close attention to access controls, logging, and decision pathways to ensure flexibility does not turn into loss of accountability. The goal is not to slow things down, but to ensure the system remains trustworthy while the organization stabilizes.
Can you share with us some criteria you use to judge whether a system’s design will outlive current threats and challenges?
I look at whether the system can survive change, not just threats. That starts with asking how dependent it is on specific people, tools, or conditions. If the system only works when everything goes right, it won’t last. Also, I look at adaptability, whether the design allows for incremental change without breaking core functions. Systems that outlive challenges are usually modular, well-understood by their users, and supported by clear ownership and decision paths. Finally, I pay attention to how the system behaves under stress. If it degrades gracefully instead of failing completely, and if people know how to respond when something goes wrong, that’s usually a strong sign the design will hold up long after today’s challenges have passed.
What continuous monitoring tools do you recommend for sustaining system integrity through uncertain times?
I’m less focused on specific tools and more on what they make visible. The most useful monitoring is the kind that tells you early when something is drifting performance, access patterns, data quality, or unusual behavior before it turns into an incident. I usually recommend a mix of basic system health monitoring, access and audit logs, and simple operational indicators that teams can understand without needing a specialist. If only one person can interpret the dashboards, that’s already a risk. Most importantly, monitoring has to be tied to action. Alerts that no one owns or reviews don’t promote integrity. The best setups are lightweight, continuously reviewed, and embedded into routine decision-making so issues are spotted and addressed even when the organization is under pressure.
How do you incorporate lessons learned from previous crises into the audit of new systems designs?
I look at past crises as real-life tests of how systems behave under pressure. I don’t only focus on what failed. I pay attention to where assumptions broke down and where people had to improvise just to keep things running. Those moments usually show the real weaknesses in a system. When reviewing new system designs, I check whether they account for those realities. I ask if the system can still function when conditions are not ideal. when timelines are tight, staff are stretched, or normal processes are not available. If a system only works in perfect situations this means it has not truly learned from past crises.
How do you balance compliance with the need for innovative, future-proof solutions in system audits?
I don’t see compliance and innovation as opposites. Compliance sets the guardrails. This defines what must not fail and while innovation is how you design within those boundaries so systems can evolve. When it comes to audits, I first make sure the fundamentals are solid: security, access controls, data protection, and accountability. Once those are in place, I look at whether the system is flexible enough to adapt without constantly needing exceptions or workarounds. Future-proof solutions usually come from designs that meet compliance requirements by design, rather than bolting controls on later. The balance comes from being practical. Innovation that ignores compliance creates risk, but compliance that ignores how systems need to grow creates fragility. The goal is to design systems that are both trustworthy today and adaptable tomorrow.
What role does documentation play in designing audits for system longevity?
Documentation plays a bigger role than people often realize. It’s not just about records or compliance. It’s about making sure knowledge doesn’t live in one person’s head. Systems last longer when others can understand how they work, why decisions were made, and what to do when something changes. From an audit perspective, good documentation supports continuity. It helps new teams step in, supports consistent decision-making, and makes it easier to adapt systems over time without introducing unnecessary risk. When documentation is clear and practical, it becomes part of the system’s resilience, not just a formality.
How would you evaluate if system controls are robust enough to handle unforeseen scenarios, such as cyber threats or sudden operational changes?
I assume that unforeseen scenarios will happen and look at how the system behaves when things do not go as planned. The key question is whether controls still hold when normal processes are disrupted for example, when access needs to change quickly or when systems are under unusual load. I also look for how well the system detects and responds to problems. Robust controls don’t just block threats; they make issues visible early and guide people on what to do next. If a system can limit damage, alert the right people, and recover without losing trust or data, that’s usually a good sign it’s prepared to handle unexpected cyber or operational challenges.
How do you audit emerging technologies like AI, cloud, SaaS to ensure their frameworks survive future regulatory and business environments?
When auditing emerging technologies, I focus less on the technology itself and more on how decisions are made around it. Regulations and business needs will change, so I look at whether the framework is flexible enough to adapt without needing to be rebuilt from scratch. For AI, cloud, and SaaS, that means checking things like data ownership, access controls, audit trails, and exit options. I ask whether the organization can explain how decisions are made, how risks are monitored, and how the system would respond if rules or priorities shift. Technologies that survive future environments are usually the ones built with transparency, clear governance, and the ability to evolve not just the latest features.
Is there anything else you would like to add?
Technology does not exist in isolation. The most durable systems are built with an understanding of people, processes, and context. Not just technical requirements. When audits take that broader view, they don’t just protect systems in the short term; they help organizations make better decisions over time, even as conditions change.For me, that’s ultimately the goal: designing and auditing systems that remain useful, trusted, and resilient long after the immediate challenge has passed.
