Imagine your company uses a software platform to manage customer information. You pay for it, your employees use it every day, and it's become an important part of how your business operates. But you don't actually own the software. Another company built it, maintains it and decides how it works. Now imagine something goes wrong.
Maybe an employee accidentally gives someone access to information they shouldn't see. Or perhaps the software provider introduces an update that changes how customer data is handled. Who's responsible for fixing the problem?
Well, that depends on what went wrong and who had control over the decision that caused it. The software provider might be responsible for problems with the technology itself, while your company may be responsible for how employees use it. This is where enterprise technology responsibility gets complicated.
Businesses regularly use technology they don't own, and the companies that provide it don't control everything their customers do with it. So simply knowing who owns a piece of technology isn't enough to tell us who's responsible for what. We also need to look at who makes the decisions, who has control over how the technology is used and what each organisation is expected to do.
Why Ownership Is No Longer Enough To Define Responsibility
Ownership has always been an important part of managing business technology. If your company owns a system, it's usually easier to establish who pays for it, who maintains it and who makes decisions about how it's used.
These are all part of technology governance, which is essentially the rules and responsibilities a business puts in place to make sure its technology is managed properly. But owning something and being responsible for something aren't necessarily the same thing. Think about the customer information platform from our introduction.
The software provider owns the platform and is responsible for developing and maintaining it. Your company pays to use the software, decides which employees can access it and determines what information goes into it. If the provider releases an update that causes a technical problem, that's something the provider would generally need to address.
But if your company gives employees access to information they shouldn't have, that's a decision your business made. The two organisations have different responsibilities because they're making different decisions. This isn't a new idea.
The International Organization for Standardization's ISO/IEC 38500:2024 guidance on IT governance looks at how organisations use technology, not just what they own. In other words, managing technology responsibly includes thinking about what your business does with it. The difficulty is working out exactly where one company's responsibilities end and another company's start.
A contract might tell you what your software provider has promised to do. Your company's records might show which department is responsible for the platform. But neither necessarily tells you who's responsible for every decision made while using it. And when several organisations are involved in the same technology, those questions become even harder to answer.
One Technology System Can Involve Several Different Responsibilities
Let's use a company that introduces a new software platform to manage customer enquiries. The business chooses the software because it wants employees to handle customer requests more efficiently. It decides which teams will use the platform, what information they'll collect and how customer enquiries should be handled.
The software provider, meanwhile, decides how the platform is built, what features it offers and how those features work. Both companies play a part in making the system useful, but they don't have the same responsibilities. To understand why, we need to look at a few differences that are easy to overlook.
Ownership doesn't always mean operational control
Operational control simply means having the ability to decide how something works or is used. The software provider controls the technology behind the customer enquiry platform. It can develop new features, change how existing features work and release updates. Your company probably can't make those changes itself.
But it can decide how employees use the software, which features to enable and how the platform fits into its customer service process. For example, imagine the provider introduces a feature that automatically sorts customer enquiries into different categories. Your company didn't develop that feature.
But if the provider makes it optional, your business can decide whether to switch it on, how to set it up and whether employees need training before using it. Of course, not every change will be optional. Sometimes the provider will make changes your company has to accept, and other changes may require its help.
That's why it's important to understand what each organisation can actually control. You can't reasonably expect your company to fix a problem in software it has no ability to change. But you can expect it to make sensible decisions about the parts it does control.
Dependence can exist without ownership
Now imagine your company has been using that customer enquiry platform for five years. Your employees know how it works, your customer service processes have been built around it and replacing it would mean changing how an entire department operates. Your company still doesn't own the software.
But it's become dependent on it. This is what technology dependence means. Your business relies on something it doesn't necessarily own or control to get its work done. That creates a different set of questions:
- What happens if the provider changes a feature your employees rely on?
- What alternatives does your company have if the software no longer meets its needs?
- How much say does your company have in decisions that could affect its operations?
You can't stop the provider from making every change you disagree with. But your business can decide how much it relies on the platform, whether it needs alternatives and what it would do if the software stopped meeting its needs. Those decisions are your company's responsibility, even though the software itself belongs to someone else.
Different responsibilities can exist at the same time
Sometimes these responsibilities are more than just practical business decisions. They're also legal requirements. Financial services offer a good example. Under the EU's Digital Operational Resilience Act (DORA), certain financial organisations must meet specific requirements for managing technology risks, including when they use services provided by other companies.
So a regulated financial institution can't simply hand over its technology to a supplier and assume that the supplier is now responsible for everything. The institution still has its own legal obligations. The technology provider may also have obligations, including additional requirements if it's designated as a critical provider under DORA.
These aren't necessarily the same obligations, and DORA doesn't apply to every business. But the example shows something important. Two organisations can be responsible for different things involving the same technology. One company's responsibility doesn't automatically cancel out the other's.
Which brings us to the next question. How does a business work out which responsibilities are actually its own?
What Actually Determines An Enterprise's Responsibility?
The easiest way to approach this is to stop looking only at who owns the technology and start looking at how each organisation is involved. A company might own the software, use it, make decisions about it or depend on it to run an important part of the business. It might also benefit from technology that someone else developed.
These are all different relationships, and they can tell us something about the responsibilities a company may have. One way to bring them together is through a responsibility map. Think of it as a way of asking five questions about a piece of technology:
- Who owns it?
- Who controls it?
- Who depends on it?
- Who benefits from it?
And who could be affected by the decisions made about it? This doesn't mean every company involved automatically has a legal obligation. The answers simply help businesses understand where responsibilities might exist and what they need to look into more closely.
What does the organisation own or control?
Let's say your company stores customer information on an external software platform. Your business may have rights over that information, but the provider controls the technology used to store and process it. You can decide what information employees are allowed to collect and how they should use it.
But if you want to change something about the software itself, you might need the provider to do it. This is the difference between ownership and control. Having rights over something doesn't always mean you can change everything about how it works. There's also another important distinction: control versus influence.
You might not be able to tell a software provider how to build its product. But you can ask for improvements, negotiate requirements in your contract or choose a different provider when your agreement ends. That's influence. You can't make the decision yourself, but you may be able to encourage someone else to make it.
Knowing the difference helps businesses avoid assigning responsibilities to people or organisations that don't have the ability to carry them out. After all, there's little point telling an employee they're responsible for fixing a technical problem if only the software provider can access the systems needed to fix it.
What does the organisation depend on or benefit from?
We've already seen how a business can become dependent on technology it doesn't own. But there's another side to that relationship. What does the business gain from using the technology? A company might use an external platform because it helps employees work faster, improves customer service or allows the business to offer something it couldn't provide on its own.
The company benefits from the technology, even though someone else owns it. That gives the business a reason to care about how the platform is maintained, whether it continues to meet its needs and what might happen if something changes. But there's an important limit here.
Benefiting from technology doesn't automatically make a company legally responsible for everything connected to it. For example, paying to use a software platform doesn't make your business responsible for developing the software or maintaining the provider's systems. Your company has an interest in how the technology works because it relies on it.
Whether it has a specific legal responsibility is a separate question that depends on the circumstances.
How is the organisation connected to the consequences?
Another thing to consider is what actually happened and how the organisation was involved. Imagine your company uses a software platform to send messages to customers. If your employees choose to send information to the wrong people, that's a decision made by your business. But if the platform sends messages to the wrong recipients because of a software defect, the provider's role may be different.
And sometimes the situation isn't so clear. A problem could involve both the way the software was designed and the way your company decided to use it. The Organisation for Economic Co-operation and Development (OECD) explains a similar distinction in its Due Diligence Guidance for Responsible Business Conduct.
The guidance looks at whether a company caused a harmful outcome, contributed to it or was connected to it through a business relationship. It also considers how much influence the company has over another organisation involved. The OECD's guidance wasn't written specifically to explain enterprise technology responsibility.
But it offers a useful way to understand why different types of involvement can lead to different expectations. A company that directly causes a problem isn't necessarily in the same position as one that uses a supplier whose actions caused it. That doesn't automatically tell us who's legally liable.
Legal liability means being legally responsible for something, and determining it depends on the relevant laws and circumstances. It does show why we need to understand what each organisation actually did before deciding what it should be responsible for.
Why Existing Governance Boundaries Can Leave Gaps
Most businesses already have people responsible for different parts of their technology. IT teams manage systems and technical settings. Procurement teams deal with suppliers and contracts. Risk teams look at things that could go wrong. Business managers decide how their departments operate. On paper, that sounds fairly straightforward.
The trouble is that technology decisions don't always fit neatly into one department's responsibilities. Imagine your company introduces a new feature in its customer service platform. IT is responsible for setting it up. Procurement manages the relationship with the software provider.
The customer service manager decides how employees will use the feature. Each team knows what it's supposed to do. But who's responsible for making sure everyone understands how the change might affect customers? It's possible for every team to complete its assigned work while nobody has looked at the full picture.
This is one of the problems technology governance is supposed to address. It's not enough to know who manages the software. The business also needs to know who can approve changes, who should be consulted and who is responsible for decisions that affect more than one department.
The same problem can appear when technology comes from an outside supplier. In December 2025, the Basel Committee on Banking Supervision published its Principles for the Sound Management of Third-Party Risk, addressing how banks manage risks connected to external service providers.
The principles apply to banking, but they illustrate why organisations need to understand more than what's written in a supplier contract. A contract can tell you what the provider has agreed to deliver. It won't necessarily explain every decision your own employees make about using the technology.
Having one person responsible for a system is still useful. But that person may not control every decision affecting how the system is used. Businesses need to know where those decisions are being made and whether anyone is responsible for making sure the different pieces fit together.
How Enterprises Can Think Beyond The Ownership Map
The good news is that businesses don't necessarily need a completely new set of rules to start understanding these responsibilities. A useful starting point is to choose an important business process and look at the technology behind it. Take customer service, for example.
Your company might use an external platform to manage enquiries, store customer information and help employees respond to requests. Start by identifying the technology involved and the people or organisations making decisions about it. Then ask:
- Who owns the software or information involved?
- Who can make changes to how the technology works?
- Who decides how employees use it?
- Which business activities rely on it?
- Who benefits from using it?
- Who could be affected if something goes wrong?
These questions help you build a responsibility map that goes further than simply listing who owns each system. The next step is to look at what those answers mean. Some responsibilities may already be written into contracts or established by law. Others may be decisions your business needs to make about how it uses the technology or manages its dependence on a supplier.
For example, imagine your customer service team uses an external platform to communicate with customers. The provider is responsible for the software it develops and the services it has agreed to deliver. Your company decides which employees can access customer information, how the platform is configured and how staff should use it.
If an employee sends sensitive information to the wrong person because of a decision your company made about access, the fact that you don't own the software doesn't make that decision the provider's responsibility. Equally, your company shouldn't automatically be held responsible for technical decisions that only the provider could make.
This is why it's useful to look at each organisation's actual role rather than assuming that everyone involved has the same duties. A responsibility map won't settle every legal question or prevent every problem.
But it can help a business see which responsibilities are already clear, which decisions need more attention and where people may be assuming that someone else is taking care of something. And when the technology changes, those answers may need to change too.
Final Thoughts: Responsibility Must Reflect How Technology Actually Works
Owning technology is still an important part of deciding who's responsible for it. Ownership helps businesses work out who has authority over a system, who pays for it and who manages it. But ownership doesn't tell us everything. Businesses make decisions about software and services they don't own every day.
They choose how employees use those tools, what information goes into them and which parts of the business rely on them. The companies providing the technology make their own decisions, too. Understanding responsibility means looking at what each organisation actually controls, what decisions it makes and what obligations apply to its role.
It doesn't mean everyone involved is equally responsible for everything that happens. For enterprise leaders, the practical question is whether their existing processes make those responsibilities clear.
Knowing who owns a system is useful, but it's just as important to know who's making decisions about how it's used and whether those decisions are being managed properly. As businesses rely on more technology provided by other companies, understanding where those responsibilities begin and end will remain an important part of managing enterprise technology.
EM360Tech continues to cover these questions across technology strategy, infrastructure management and enterprise governance, bringing together perspectives that help businesses make more informed decisions about the technology they use.
Comments ( 0 )