Almost every sovereignty conversation I have had this year has been a conversation about geography. Which region, whose data centre, which jurisdiction, what the contract says about location. Those are real questions. They are also the easy ones, because they can be answered by a procurement decision and then filed. The harder question surfaces the moment something goes wrong: who answers for it. Not who operates the platform, not who holds the encryption keys, not whose engineers get paged. Who stands in front of the regulator, the customer, the employee whose data it was, and the board, and explains the decision to hold that information in that place under those terms. That person works for you. There is no clause that moves them.
Three things that do not transfer
Outsourcing moves work. It does not move answerability, and three components of it in particular stay where they are no matter how the contract is drafted. The purpose. Why this data exists in your organisation at all, what you intend to do with it, and whether that intention is proportionate. Your vendor did not decide to collect passport copies from every applicant. You did. The lawful basis. Whether you are entitled to hold and use the information, under whichever regime applies. A processor operating on your instructions has no view on this and no liability for getting it wrong. The duty to answer. When an individual asks what you hold, when a supervisor asks how you assessed a transfer, when a customer asks whether their contract data left the country, the response comes from you, in your name, within a deadline. A vendor can help you assemble it. A vendor cannot issue it. Everything else, storage, processing, availability, patching, monitoring, can be bought. These three cannot, and organisations that have not internalised the distinction tend to discover it in the week they can least afford to.
What you are actually buying
It clarifies the situation to name what a software-as-a-service contract genuinely delivers. Capacity, so you do not run infrastructure. Operations, so you do not staff the night shift. A control environment, generally better than yours, because the vendor's whole business depends on it. And evidence, which is the underrated one: certifications, audit reports, sub-processor disclosures, data location commitments, breach notification undertakings and transparency reporting. Evidence is what accountability consumes. The accountable organisation is not the one that inspects its vendor's data centre; it is the one that can produce, on request, a coherent account of why it chose that vendor, what assurance it obtained, when it last checked, and what it would do if the assurance failed. That is achievable for a mid-sized company. Auditing forty vendors is not.
The six artefacts that constitute accountability
In practice, being accountable means being able to produce six things about each significant system. A register entry naming the system, the categories of data, the purposes, the locations and the accountable business owner. A decision record from the point of purchase: what was assessed, what alternatives were considered, what risks were accepted, who approved, when. A contract with instructions, stating what the vendor may do, what it may not do, who its sub-processors are and what happens at termination. An assurance file, holding the certifications and reports you relied on, each with a date, because a certificate from three years ago is a historical document rather than an assurance. An incident path naming who the vendor contacts, who receives that contact inside your organisation out of hours, and who decides within the notification window. An exit position, meaning a factual statement of what it would take to leave: data formats, timelines, cost and the material you would need before the account closed. Six artefacts, most of them a page. The reason so few organisations have them is not difficulty; it is that nobody was ever assigned to produce them.
The single most effective intervention
Name a business owner for every system that holds personal or commercially sensitive data, and make it someone outside the technology function. Technology owns the platform. The business owns the purpose. When the accountable owner for the recruitment system is the head of human resources rather than an infrastructure manager, the questions change: why do we keep rejected applicants for seven years, why does the agency have a login, why is the offer letter template asking for family details. Those are decisions nobody in a technology function is positioned to make, and they are exactly the decisions accountability is about. This also solves the shadow procurement problem more effectively than a policy does. Applications purchased on a departmental card, below whatever threshold triggers review, are not a governance failure by the buyer; they are a signal that the buyer had a need and the formal route was too slow. Give every system an owner, publish the list, and ask each owner annually to confirm what they use. The unregistered tools surface, usually in numbers that surprise the executive team.
Practical Guidance for an Accountability Framework Review
- Inventory the systems, not the servers. Every application holding personal or commercially sensitive data, including the ones bought on a card. Finance's supplier ledger finds more of these than any technology audit.
- Assign a named business owner to each. Outside technology, senior enough to decide, listed by name rather than by job title.
- Tier by consequence, then do the work at the top. Payroll, human resources, customer records and anything regulated get full artefacts. Low-consequence tools get a register line and an owner.
- Collect assurance with dates and set review reminders. Certification scope and validity period matter more than the logo. An expired report is not evidence.
- Write the decision record at purchase, not at audit. Ten minutes at the point of decision replaces a week of reconstruction two years later, usually badly.
- Name the out-of-hours incident path and test it once. Whom does the vendor call, who answers, who decides. A notification deadline is measured in hours, and hours are lost in switchboards.
- State the exit position in writing before signing. Export formats, timelines, deletion confirmation, cost. Ask during the sales process, when you still have leverage.
- Give the board one page per year. Which systems hold the sensitive data, who owns each, what assurance exists, what is unresolved. Governance that never reaches the board is documentation, not accountability.
The Regional Angle
Three structural features of how business is organised here make accountability harder to locate than it looks, and one of them is almost universal in regional groups. The contracting entity is frequently not the entity with the people. A group signs its enterprise agreements through a holding company or a free zone entity chosen for tax, licensing or convenience, while the employees and customers whose data is processed belong to operating companies in other emirates or other Gulf states. On paper the accountable party is an entity with three staff and no operations. When a regulator, a supervisor or a large customer asks who is responsible, the honest answer requires an internal allocation that has usually never been made. The fix is unglamorous and cheap: an intra-group arrangement stating which entity is accountable for which categories of data and which is acting on the other's instructions, signed once, kept with the register. Second, accountability here has to sit with someone the authorities will actually deal with. Regional regulators, licensing bodies and courts engage through the licensed entity's authorised signatory or general manager, someone resident, named on the licence and able to sign. A group privacy officer in London is useful for policy and useless when a local authority makes contact. Whatever the group structure says, there should be a resident, named individual in each licensed entity who is briefed, has the register, and knows to escalate. In most regional groups that person exists and has never been told this is part of the role. Third, assurance in this market frequently arrives as an assertion rather than a document. Local partners, integrators and resellers will say confidently that the platform is compliant, that the data stays in the country, that the hosting is certified. Ask for the report. Ask which entity holds the certification, what its scope covers, when it was issued and whether the specific service you are buying is inside that scope. The gap between the assertion and the document is, in my experience, the most common finding in a regional accountability review, and it is not usually dishonesty: the person making the claim genuinely believes it because their principal told them so. One encouraging note. The free zone data protection regimes in the Emirates and Qatar, and the direction of travel in Saudi Arabia, all place accountability on the controller in the same way the European regime does. An organisation that does this work now is not building for a hypothetical future obligation. It is building for a set of rules that already apply to part of the group and will shortly apply to the rest.
The objection worth taking seriously
The strongest objection is about power. Accountability language places the obligation on the customer while the practical control sits with the vendor. A mid-sized regional company cannot negotiate the terms of a hyperscaler contract, cannot audit it, cannot influence its sub-processor list and cannot meaningfully verify a single claim in its certification pack. Telling that company it remains accountable is a way of allocating blame downward: the party with no leverage carries the exposure, and the party with all the leverage publishes a report and moves on. There is something to this, and it is why the standard contract has become a document customers read rather than negotiate. The second objection is capacity. An organisation with sixty applications and a two-person technology team cannot produce six artefacts per system. Asked to try, it will produce them for the first five, abandon the exercise, and be left with a half-finished register that is worse than none because it implies coverage that does not exist. Both objections are why the tiering matters more than the framework. Accountability does not mean auditing your vendors; it means being able to explain your decisions and answer questions about them. That is achievable without leverage. You cannot make a global platform change its terms, but you can record that you assessed it, what you relied on, what you accepted and who approved, and that record is precisely what a supervisor is looking for. On capacity: six artefacts for the five systems that hold the material that would actually hurt, a register line and a named owner for the rest, and an annual confirmation. That is days of work, not a programme. What makes it worthwhile is not the documentation. It is that the exercise of naming an owner for every system reliably surfaces two or three arrangements nobody would defend once they are written down, and those are found before someone else finds them.
Common Questions
Does a data processing agreement transfer accountability?
No. It allocates obligations between the parties and gives you a remedy. The duty to determine purposes, establish a lawful basis and answer questions stays with you.
Who should own this, legally and practically?
Legally, the entity that determines the purposes. Practically, a named resident individual in each licensed entity, supported by business owners for each system and a single group view.
We use one hyperscaler for nearly everything. Does that simplify it?
It simplifies the assurance work and concentrates the risk. You still need the register, the owners, the incident path and, in that configuration especially, a realistic exit position.
What should we expect over the next twelve months?
Expect the pending European transfer judgment to make customer-side assessment and documentation the centre of the compliance conversation rather than the choice of instrument. Expect regional regimes to continue converging on controller accountability. Expect large customers to start asking suppliers for these artefacts during procurement rather than during audits. And expect the organisations that can answer in an afternoon to win work from those that need a month.
Accountability Framework Review — we find out who actually answers for each system, produce the six artefacts that matter for the handful that count, and leave you able to reply in an afternoon.