There are plenty of ways to decide whether technology is working.
- Did the platform stay online?
- Was the transaction processed?
- Is the data secure?
- Did the system make something faster, cheaper or more accurate?
- And, eventually, did the organisation get enough value back to justify what it spent?
These are sensible questions. Enterprise technology needs measurable outcomes, and CIOs, CTOs and CISOs can't run complex organisations on good intentions. But most of those measures start with the system or the organisation. They also assume that quite a lot of the world around the technology is behaving normally.
There is electricity. The network works. People have devices. Supporting services are available. If something breaks, somebody can usually reach the people and tools needed to fix it. Humanitarian environments don't offer the same certainty. Conflict, displacement and disasters can remove several of those assumptions at once.
Infrastructure can be damaged or unavailable. Connectivity can disappear. People can lose devices and identification documents. Demand can increase precisely when capacity is falling. Information collected to help someone can become dangerous if circumstances change or the wrong person gains access to it.
Yet technology doesn't become less important under those conditions. It can become part of how people access the services they need most. World Humanitarian Day gives us a reason to look at enterprise technology through that much harder version of the problem.
Not because humanitarian organisations exist to teach enterprises how to design systems, and certainly not because real crises should be turned into convenient business case studies. Rather, these environments make something unusually easy to see: technology can meet its technical requirements while producing a very different outcome for the person depending on it.
Which raises a bigger question. What would organisations build, secure and govern differently if human consequence became one of the measures of whether technology works?
When Digital Infrastructure Becomes Essential Infrastructure
Digital infrastructure is easy to think of as something happening behind whatever service we're actually trying to use. Networks connect us. Cloud platforms process and store information. Databases hold records. Identity systems decide whether we're allowed through the digital door.
Usually, if those components are doing their jobs, we don't need to think too much about them. That relationship changes when access to the technology becomes part of access to the service itself.
The International Committee of the Red Cross (ICRC) said in a July 2026 working paper that reliable information and communication technologies are critical in conflict-affected countries for civilians accessing essential goods and services, governments delivering them and humanitarian organisations carrying out their work.
The organisation has observed digital disruption affecting energy, communications, transport, banking, water supplies, food systems and public services. Importantly, those consequences don't require physical infrastructure to be destroyed. Disabling the digital systems underneath it can be enough.
Connectivity makes the relationship particularly easy to see. When disasters damage normal communications networks, the International Telecommunication Union (ITU) can deploy satellite phones, terminals and other emergency telecommunications equipment within the first 24 to 48 hours after receiving a request from an affected country.
The purpose isn't simply to get the network back online. Those communications links support coordination between governments and humanitarian organisations involved in rescue and relief work. The ITU's Disaster Connectivity Map takes a similar approach from the monitoring side.
It identifies communications outages in near real time so governments, telecommunications providers and first responders can understand where connectivity has been lost and prioritise restoration. By January 2026, the system had been activated across more than 80 countries or disaster situations.
But even a functioning network doesn't automatically make a digital service accessible. The ITU estimates that six billion people were online in 2025, while another 2.2 billion remained offline. It also warns that the remaining digital divide isn't only about coverage. Quality, affordability and skills continue to shape whether people can actually benefit from digital services.
A person might technically have mobile coverage but no affordable data. They might have a connection that isn't reliable enough for the service they're trying to use, or a device that's old, shared or damaged. And sometimes the difficulty is simply that the system assumes a level of digital confidence the user doesn't have.
That's the gap between technical availability and human availability. For enterprise infrastructure leaders, it's a useful distinction. A platform being operational tells you something important about infrastructure health. It doesn't necessarily tell you whether the service is still usable from the other end.
Once people become dependent on digital systems to reach something important, the obvious next question is what happens when the environment those systems rely on stops behaving normally.
What Humanitarian Technology Reveals About Real Resilience
Most enterprise systems are built with assumptions. Usually they're reasonable ones. There will be electricity. Some form of connectivity will exist. Cloud services will remain reachable. Employees will be available. Users will have their devices. Data will be current enough to work with. Third-party services will respond when called.
Then resilience engineering tries to protect the organisation when some of those assumptions fail. Humanitarian technology may have to begin somewhere else entirely. A system could need to operate with unreliable electricity, intermittent connectivity, damaged infrastructure and lost or shared devices.
Staff may have been displaced. Information may be incomplete or changing quickly. Demand can rise sharply. Security conditions may change by the hour. And because humanitarian resources are finite, the answer can't always be another redundant platform sitting behind the first one.
OCHA reported in March 2026 that more than 240 million people worldwide needed humanitarian assistance and protection. Organisations working across that scale are making technology decisions alongside severe operational and funding constraints. This is where graceful degradation becomes useful.
The phrase sounds technical, but the idea is straightforward. When a system can't offer everything it normally does, the most important functions keep working in a reduced form instead of the entire service becoming useless. The International Federation of Red Cross and Red Crescent Societies (IFRC) is applying that kind of thinking to its Red Cross and Red Crescent Health Information System.
Its 2025 annual report describes an emergency-ready digital solution that can operate online, offline or in hybrid configurations, allowing care and data collection to continue in low-connectivity and fragile environments. The important part isn't simply that the system has an offline mode. It's the assumption behind the design.
Unreliable connectivity isn't treated as an unusual failure to recover from later. It's part of the environment the technology is expected to work within from the beginning. That can change how organisations think about resilience more broadly. Sometimes simplicity, interoperability and local capability are more useful than adding another layer of complexity.
Sometimes the most resilient system isn't the one that keeps every feature alive. It's the one that knows which functions people can't afford to lose.
What does your technology assume will always work?
Choose one genuinely important digital service in your organisation and start removing assumptions.
- What happens if internet access becomes unreliable?
- If one cloud region disappears?
- If the identity provider is unavailable?
- If a third-party API stops responding?
- If information isn't completely current?
- If specialist staff can't be reached?
Then move beyond the architecture.
- What if the user loses their normal device?
- What if demand doubles?
- What if the service assumes somebody can receive an email or text message to authenticate?
- What if a person doesn't understand the interface well enough to complete an important process without help?
Technology teams already map dependencies for disaster recovery and business continuity. The more interesting question here is slightly different: Which dependency has to disappear before the service stops being useful to the person who needs it?
Traditional resilience asks what can break the system. Human-centred resilience also asks what can break the outcome. And availability is only one way that outcome can fail. Sometimes the technology keeps running while something much more serious happens to the information moving through it.
When Cybersecurity Becomes About Protecting People
Cybersecurity has always had a language for consequence. There are compromised accounts, stolen records, system downtime, regulatory exposure, financial loss and operational disruption. Security teams use those consequences to decide which systems deserve the strongest protection and which incidents require the fastest response.
Humanitarian environments simply make it easier to follow the chain all the way to the person at the end of it. In January 2022, the ICRC discovered that attackers had compromised servers containing personal data belonging to more than 515,000 people.
The records included names, locations and contact information relating to missing people and their families, detainees and people receiving humanitarian support after conflict, migration and natural disasters. The breach also forced systems supporting the Red Cross and Red Crescent Movement's Restoring Family Links work offline.
That affected the network's ability to reconnect people separated from their families, with teams falling back to lower-tech solutions while the compromised systems were rebuilt and secured. That's a cybersecurity incident. But describing it only as a breach misses most of what happened.
The familiar cybersecurity principles of confidentiality, integrity and availability help explain why. If confidentiality fails, information about someone's identity, location or circumstances may reach people who shouldn't have it. If integrity fails, records used to identify people or support decisions can no longer be trusted.
And if availability fails, someone may lose access to the service those systems were supporting. The ICRC's July 2026 working paper says humanitarian organisations are frequently targeted or affected by malicious ICT activity including distributed denial-of-service attacks, system intrusions, sensitive-data theft and attempts to disable computer systems.
It explicitly connects those attacks to the safety and dignity of the people humanitarian organisations serve. None of this makes normal cybersecurity measures less useful. It extends where the analysis ends. The same applies to recovery. A server can be restored. An application can be accessible again.
Security teams can close the incident and still discover that another dependency means users can't actually complete the process they need. System recovery and service recovery aren't always the same thing.
That gives CISOs another useful question to sit alongside financial, operational, compliance and reputational impact: who experiences the consequence if this system becomes unavailable, unreliable or compromised? Cybersecurity shows us what can happen when somebody attacks technology or the information inside it.
Responsible technology becomes harder when nobody attacks anything at all. What if the system is working exactly as intended?
Responsible Technology Gets Harder When the System Works
A digital identity system can correctly identify someone. A biometric system can match the right person. A database can combine information exactly as designed. An automated model can produce the output its developers expected. None of those outcomes tells us whether the consequence for the person affected was acceptable.
Humanitarian organisations have legitimate reasons to collect information most companies would consider extremely sensitive. Identity, family relationships, locations, health information and biometrics can all support real humanitarian purposes.
UNHCR, the UN Refugee Agency, supported the individual registration of 1.9 million people through its proGres system in 2025. It also worked with host governments on registration and documentation, including biometric registration in Bangladesh, Ethiopia and Sudan, to establish identity and legal status.
This is the trade-off at the centre of responsible technology. The same information that helps someone prove who they are and access support becomes highly consequential if it's inaccurate, exposed, combined with other information or used for a different purpose later.
The IFRC doesn't treat data protection as a box-ticking privacy requirement for exactly this reason. It describes safeguarding personal data as part of protecting the life, integrity and dignity of the people it supports. It also points out that during a crisis, people are likely to be focused on urgent needs relating to survival and safety rather than carefully evaluating the future risks attached to information they give an aid organisation.
That makes consent more complicated than whether somebody clicked "agree". There is a meaningful difference between deciding whether an online retailer can personalise your recommendations and providing sensitive information while trying to access healthcare, protection, identification or humanitarian assistance.
Both might involve a choice on paper. They don't necessarily involve the same freedom to say no. AI and automated decision-making can make that imbalance harder to manage. The ICRC introduced an organisation-wide AI policy. in 2024 to support responsible, safe, coherent and human-centred use of AI in humanitarian work.
That approach recognises the potential benefits without pretending every use carries the same level of risk. A wrong classification, prioritisation or recommendation is very different when the affected person doesn't understand what happened, can't challenge the result or has no realistic alternative.
The technology may still be functioning perfectly. The problem is the relationship around it.
What changes when the user can't simply walk away?
The less freedom somebody has to refuse, challenge or leave a digital system, the more carefully organisations need to think about what that system can do to them. That begins with the information itself.
- Do you actually need everything you're collecting?
- What happens if the information is wrong?
- What could happen if it becomes public?
- Could a person refuse to provide it without losing access to something important?
Then there are questions about decisions.
- Can someone understand why an outcome occurred?
- Can they challenge it?
- Is there another route available when automation gets something wrong?
And finally, there is time.
- How easily can incorrect information be fixed?
- How long does the organisation need to retain it?
- Could data collected safely today become dangerous if circumstances change?
Humanitarian environments make these questions unusually stark, but the principle travels much further. Employees can't always walk away from workplace systems that evaluate them. Patients may have little choice about the digital systems used in their care.
People applying for credit, insurance or government services can be deeply affected by decisions made through technology they didn't choose and may barely understand. Those environments aren't equivalent to humanitarian crises. The comparison would be careless.
What they share is power asymmetry. One party controls a system that can significantly affect another person's options. And even then, the organisation interacting with that person rarely owns everything underneath the service. Modern technology is built across cloud providers, networks, applications, AI models, security platforms and other suppliers.
So if consequences can travel through the technology stack, responsibility becomes harder to keep inside one organisational boundary.
Where Does a Technology Company's Responsibility End?
This is where simple answers stop being particularly useful. Technology companies can't reasonably be held responsible for every way somebody might use a general-purpose product. Developers can't predict every future customer, every political change or every harmful decision made years after a product leaves their hands.
But "we only provide the technology" has limits too. Cloud providers, telecommunications companies, satellite operators, cybersecurity vendors and AI developers increasingly provide capabilities used across commercial, civilian, government and humanitarian environments. Some technologies can also serve civilian and military purposes at the same time.
That's what dual-use technology means in practice. The capability itself may be perfectly legitimate. What changes is who uses it, where they use it and what they use it to do. The ICRC's July 2026 work highlights why this is becoming complicated. Technology companies operate and maintain large parts of global communications infrastructure and data centres while serving many different customers, including armed forces.
When the same infrastructure is relied on by civilians, military use can create wider risks for the people and services sharing it. The ICRC has suggested physically or technically separating infrastructure, services and products used in military operations from those serving civilian purposes where feasible.
The point isn't that separation is always possible. It's an example of architecture changing because a foreseeable consequence changes the design problem. The broader principle isn't limited to conflict.
The UN Guiding Principles on Business and Human Rights say human rights due diligence should start as early as possible when developing a new activity or business relationship because decisions taken at that stage can influence whether later harm can be prevented or reduced. Still, design has limits.
Research published through the ICRC in May 2026 makes exactly that point in the context of military AI. Technology suppliers can influence decisions such as training data, autonomy, testing and classification thresholds, but legal compliance also depends on how a system is used and the circumstances surrounding that use. You can't engineer every future decision into the product.
That leaves a much more useful question than whether providers are responsible or not.
Responsibility grows where foreseeability and control overlap
There are two things worth looking at. The first is foreseeability. Could the organisation reasonably anticipate the use, misuse or consequence? The second is control. What meaningful ability does the organisation still have to change the technology, deployment, access or customer relationship?
If a harmful use is highly unusual, almost impossible to predict and completely outside the provider's influence, there may be very little the organisation could reasonably have done. The calculation changes as both factors increase. A provider might be able to change access controls or architecture.
It may be able to conduct additional customer and end-use checks, create contractual restrictions, technically separate services, monitor specific risks or document limitations customers need to understand. It might need an escalation path for situations that cross an agreed line.
In extreme circumstances, suspension or withdrawal may also become part of the decision. But even that isn't simple. Cutting off a service can create consequences of its own when legitimate users depend on the same infrastructure. So technology governance isn't about inventing a universal line where provider responsibility always ends.
It's about recognising when the line has moved. The question isn't whether a company is responsible for every downstream consequence of something it builds. It's whether "we only built the technology" is still enough once a serious consequence has become reasonably foreseeable and the organisation retains practical ways to reduce it.
By then, infrastructure, resilience, cybersecurity, data protection and provider responsibility stop looking like separate conversations. For the person depending on the system, they never really were.
Final Thoughts: Technology Works When People Can Depend On the Outcome
Enterprise technology is usually judged by what a system does. Humanitarian environments force us to also look at what happens because it does it. That distinction changes the definition of success. A platform can be technically available, secure and accurate while still producing an outcome that fails the person depending on it.
Once technology sits between people and something important, performance can’t be separated quite so neatly from consequence. That may be the more useful lesson to take from World Humanitarian Day. Not that enterprises should design technology as though every environment is a humanitarian crisis, but that extreme conditions expose assumptions ordinary operations allow us to ignore.
They show us where resilience depends on everything else continuing to work, where choice is more limited than it appears and where responsibility stretches further than the system boundary. The familiar measures of good technology still count. The difference is that they become part of a bigger test: did the technology create an outcome people could actually depend on?
As digital systems take on more authority across infrastructure, identity, healthcare, finance and other essential services, that question is only going to become harder to separate from technology leadership itself. EM360Tech will keep following that shift as the boundaries between technical performance, operational responsibility and human consequence continue to narrow.
Comments ( 0 )