Data residency and sovereignty for board records
Board records are among the most sensitive data an organisation holds. Where they physically sit, and whose law reaches them there, is a board decision rather than an IT one.
Why does data residency matter for board software?
Because a board pack routinely contains unannounced financial results, personnel and disciplinary matters, legal advice, and commercially sensitive negotiations. The jurisdiction the data physically sits in determines which authorities can compel access to it, and that is a governance exposure the board owns, not the IT department.
- Three different things people mean by sovereignty
- Questions worth putting in the RFP
- The trade you are actually making
- How Mithaq handles it
Three different things people mean by sovereignty
Data residency is the narrowest: the bytes are stored in a named country. It is easy to verify and it is often all a vendor is offering.
Data sovereignty adds the legal question: which country's law governs access to that data, including compelled access. A dataset stored in country A, operated by a company incorporated in country B, may be reachable under country B's law regardless of where the disk is.
Operational sovereignty is the strictest: who can technically read it. A hosted service where the vendor holds the keys and administers the machines is a different risk from software running on hardware your own staff control, whatever the contract says about confidentiality.
Buyers frequently ask for the first, believe they have bought the third, and never test the second.
Questions worth putting in the RFP
Name the country and the city of the primary and the backup facility, and say whether we can choose. A region name is not an answer.
Name the legal entity that operates the service and its country of incorporation, and state which courts the contract submits to.
State who holds the encryption keys, and whether the vendor can technically decrypt customer content without the customer's participation.
State whether an on-premise or air-gapped deployment is offered, and if so what functionality is lost in that mode.
State the export format and how a full export is obtained at the end of the contract, including the audit log.
State the sub-processor list and how changes to it are notified.
The trade you are actually making
On-premise is not automatically safer. It moves the patching, the backups, the access control and the physical security onto your team, and a neglected server in your own building is a worse outcome than a well-run hosted service. The right question is not which is safer in the abstract but which risk your organisation is actually equipped to carry.
For a sovereign entity, a regulator, or a board handling state information, the answer is often on-premise regardless, because the exposure being managed is jurisdictional rather than technical. For a mid-size private board, hosted with a clear residency answer and a clean export path is usually the better trade.
How Mithaq handles it
Mithaq has hosted, custom-domain and single-tenant on-premise paths. The on-premise installer uses Docker on customer-controlled hardware. Offline operation and data boundaries depend on the final identity, notification, integration, backup, support and update design, so those requirements must be verified before deployment.