Estonia’s Database Law in Practice

Estonia’s Public Information Act contains a sentence that most corporate data policies have tried at some point to write for themselves: “Establishment of separate databases for the collection of the same data is prohibited.” The same chapter requires three state authorities to approve a database’s technical documentation before anyone establishes it, and requires its entry in a national catalog of state information systems before it goes into use. In the country that serves as the standard reference case for digital government, these provisions look like the explanation for the result. An executive whose customer master lives in several systems, each copy with an owner and a defensible history and none of them authoritative, has reason for envy.

The Ministry of Justice and Digital Affairs gives a less flattering account of how that chapter works. In a legislative intent document dated January 29, 2026, the formal step before a bill, the ministry wrote that the approval and registration process does not function in practice, either at all or at least in the systematic and consistent way the law prescribes. Put plainly, the document says, approval often comes late or does not happen at all, and the process has never worked as designed. Of 409 central-government databases the ministry counted in the first half of 2024, 61 percent had a description of their data in the catalog, and more than 67 percent of those descriptions were over five years old, in many cases older than the latest change to the legal act behind the database. The ministry proposes to drop the approval of technical documentation, lean on the review that every legal act already receives, and monitor compliance after the fact.

So the model digital state has an architecture rule that builders work around, which is the ordinary condition of an enterprise architecture function. Yet Estonian agencies have exchanged data directly, with no central store in between, since national deployment of the country’s exchange layer began in December 2001. Something in the design has held for almost a quarter of a century beside an approval process that never took hold. Which rule held, and what set it apart, bears on a decision companies are making now, at the point of funding, about how software agents will reach their data.

Estonia’s Data Exchange Was a Retrofit

The usual account has Estonia designing its digital state on a blank page in the 1990s. The official history of X-Road, the country’s data exchange layer, describes something less tidy, in which the state databases came first. That history quotes Cybernetica, the Estonian firm that led X-Road’s development for years, recalling that “many legal entities were responsible for different registers and most of them were developed independently,” on “various database back ends,” with interfaces that “weren’t standardized.” A common key for people did exist. A World Bank case study dates the personal identification code to a 1990 standard, says every citizen received one from the middle of 1991, and calls it “the only unique identifier used in Estonia.”

X-Road entered that setting as a connector. A pilot linked three databases in 2000, and national deployment began on December 17, 2001. One motive was thrift, since building new connections between government systems was, in Cybernetica’s recollection, “time-consuming and expensive,” and those were “currencies Estonia could not really spare at the time.” The law on exchange followed the technology. A government regulation took effect in January 2004 and gave government agencies until January 1, 2005, to connect, and the statute chapter quoted above dates from 2008.

Rainer Kattel and Ines Mergel, whose study is the closest scholarly account of the case, describe all this through Albert Hirschman’s “hiding hand”: policymakers who committed to an ambitious course without foreseeing its difficulties and solved them as they arrived. They add that “the most influential design principles are not, however, codified in law or regulation,” and that people in leadership positions simply followed them. Estonia repaired an existing set of systems, early and at small scale, by laying a connector over databases that no agency had to replace. No established company gets to do anything else.

Enforcement by Review, Enforcement by Access

The approval requirement depends on review. Named authorities examine the documentation for a planned database and can withhold their agreement, and that examination is also where a reviewer would catch a duplicate. The duplication ban itself concerns collection, that is, which body gathers a given piece of data, and a version of it had been on the books since the Databases Act of 1997, more than four years before national deployment.

The ministry’s document explains why this review never worked, and the explanation will sound familiar to anyone who has sat on an architecture board. A legal act establishes a database. By the time its documentation reaches the reviewers, the government has often adopted the act and the agency has often built the system, and the ministry notes that it is not rare for an agency in that position to skip the approval altogether. Reviewers who object at that stage would be overriding a minister’s regulation or, where parliament passed the act, vetoing the legislature, which the ministry treats as a separation-of-powers problem. Nor can anyone compel compliance, since the supervisory authority’s list of grounds for binding orders omits this breach and penalty payments do not apply to state agencies. A count made for this article from the catalog’s public log found several hundred requests to establish a database or take one into use that closed with a negative decision, and dozens of the systems concerned that the catalog lists as in use with no later approval on record. The reviewers objected. They sat downstream of the decision with no sanction to hand, and the systems went live.

Exchange through X-Road depends on access, which makes the rule and the way to the data the same thing. An agency that needs a resident’s address gets an answer to that question and nothing more. Its system sends a request through a gateway that each organization runs, called a security server, which authenticates both organizations by certificate, signs the message, and logs it. No architecture board sits between the request and the answer. The owner of the data decides which organizations may call its service, and an agency with no agreement gets no answer. As of 2016, according to Helen Margetts and Andre Naumann, X-Road connected more than 1,700 services and 900 organizations, registries, and databases, and processed more than 500 million transactions a year. Kattel and Mergel record the phrase “It’s the x-road or no road” as a warning about dependency. The dependency is also the enforcement.

Both kinds of rule need a consequence, and what separates them is who has to deliver it. A review rule needs a reviewer to impose the consequence on a project that already holds its mandate. George Baker, Robert Gibbons, and Kevin Murphy made the general point about hierarchies in 1999: decision rights inside an organization are “loaned, not owned,” since the top can always overturn them, and a rule that rests on review is a loan of that kind. An access rule enforces itself: it delivers its own consequence, which is no data, and it leaves nobody to petition for a way around. This is close to what Lawrence Lessig, writing about the internet, described as architecture doing the work of law. Deadlines mattered at the start, and the 2004 regulation set one. What has kept the rule in force since, on this reading, is that an agency wanting an exception would have to rebuild the pair-by-pair connections the country had already judged too expensive.

Taavi Kotka, Estonia’s former government chief information officer, told Kattel and Mergel that interoperability is “a principle. There’s no legally binding regulation.” The 2004 regulation makes that imprecise as law, yet it describes how the rule worked once agencies had connected: the state had to impose little, since the exchange layer and the shared key did the binding, with the small informal network that is Kattel and Mergel’s subject keeping both in order.

Limits of the Exchange Layer

The National Audit Office’s figures mark where the access rule stops. In 2017 it counted at least 925 municipal databases, of which 175 had passed the compulsory inspection in the catalog and 54 connected to X-Road. An access rule reaches only as far as the need for what lies on the other side of it.

The exchange layer also secured a narrow thing, and its limits follow from its design. A layer that carries requests standardizes identity and transport and stops there. Its architecture documentation states that “X-Road core does not perform protocol and data conversion,” so the meaning of a field stays with each database’s owner, and what agencies do before and after a request stays with them too. Kattel and Mergel found the services themselves “remarkably unchanged.” Each database keeps its own access logs, and the National Audit Office found in 2023, across five state databases, that those logs went unanalyzed in any systematic or regular way.

The layer governed data as it moved between agencies and left alone what each agency chose to build. In July 2026 the government approved a consolidation of its IT agencies from ten to six, with a new chief architect, which a deputy secretary general said would “reduce duplicate development and increase the use of shared data.” The value of what the layer did deliver remains unmeasured. The official factsheet’s figure for working years saved rests on an assumed fifteen minutes per citizen request, and the factsheet adds: “There are no estimates on the rest of the queries.”

Access Rules Inside Companies

Companies run both kinds of rule and seldom notice the difference. The general ledger takes no petitions, since a transaction posts or does not exist for the close, and a cloud platform that rejects a deployment for breaking policy holds no review meeting. A much-cited corporate case of architecture discipline, Amazon’s service mandate, was an access rule too. In Steve Yegge’s 2011 recollection, the best-known public account of the mandate, Jeff Bezos instructed around 2002 that all teams expose their data and functionality through service interfaces, with “no other form of interprocess communication allowed,” on pain of dismissal. Werner Vogels, Amazon’s chief technology officer, noted in 2006 that the company had “started 10 years ago as a monolithic application,” which makes the mandate a retrofit as well.

The threat of dismissal got the interfaces built. What kept the rule in force is visible in how Vogels described the architecture four years on. “No direct database access is allowed from outside the service,” he said. By then the path enforced what the memo had ordered. That sequence answers the obvious objection to learning anything from a state, which is that an executive can impose a rule faster than any parliament. The executive can, and a successor can withdraw it as fast. A company’s difficulty is commitment that survives a change of executive or a budget cycle, and a memo does not supply it. Estonia’s exchange layer has outlasted nearly a quarter century of coalition governments.

Architecture Review Sits Downstream of Funding

Enterprise architecture governance mostly runs on the other kind of rule. A review board usually meets a project after the budget has cleared and the delivery date is public, and by then the only thing left to negotiate is the exception. Many of those exceptions are the right call, and that follows from position, since review sits downstream of funding in the way Estonia’s reviewers sat downstream of the legal act. In a survey that drew 293 valid responses, Ralph Foorthuis and colleagues found three techniques most strongly associated with projects conforming to the architecture: compliance assessments, management backing for the architecture, and hands-on assistance to the projects themselves. The first of the three is itself a review, which places the weakness in when a review arrives. All three reach a project while its builders are still at work, and a board that meets after funding does not.

Banking supplies a large test of a review-type mandate. In January 2013 the Basel Committee required global systemically important banks to be able to aggregate their risk data by January 2016, striving “towards a single authoritative source for risk data per each type of risk.” Its progress report of November 2023 is blunt: “Of the 31 banks assessed, only two banks are fully compliant with all the Principles.” The Committee attributes the delay to “lack of prioritisation” and “insufficient ownership by the board and senior management,” alongside the difficulty of changing data architecture. The diagnosis is accurate and incomplete. The Principles ask banks to consider aggregation in any new initiative, but they set an outcome and leave the gate to each bank, so compliance competes for priority with everything else, every year.

Regulators do eventually put a price on data that goes around a control. In March 2024 the Office of the Comptroller of the Currency fined JPMorgan Chase Bank $250 million over a trade surveillance program that, in the agency’s words, “failed to surveil billions of instances of trading activity on at least 30 global trading venues.” The surveillance control existed, and trading on those venues never passed through it.

Funding explains why the path between systems goes ungoverned. A system arrives with a business case, an owner, and a go-live date. The path between two systems arrives with none of them, so leftover budget pays for it and whoever inherits it governs it. This is the Undesigned Layer in its data form: the structure nobody designed and everybody inherited.

A Charter Condition for Agent Access

Companies deploying software agents are now deciding how those agents will reach enterprise data, and that decision creates a new path with a single place where a company can enforce admission. Estonia has reached the same point. On June 17, 2026, the government announced that an advisory board had agreed to create digital identities for agents. In the words of its statement, “it must be possible to specify whether an AI agent may only view data, prepare a document, draw up a payment or act solely within a specific financial limit.” The statement announces a decision to proceed and cites no legislation, and it puts the rule where the access rule has always sat, in the identity and the exchange.

A program charter can carry the same rule as a condition of funding. Under it, each agent holds its own identity with bounded permissions and borrows no employee’s credentials, and every request for enterprise data passes through one governed interface that authenticates the agent and logs the exchange. The interface resolves each request to the one system the company designates as authoritative for that kind of data, which presupposes a common key and a named owner for each kind. Estonia had both before its exchange layer existed. A company that lacks them meets the question at the moment of funding, which is the cheapest moment to meet it.

Enforcement sits in the credential and the automated release process, and in the release of funds: no production credential, and no further funding installment, until the agent and the data it reaches appear in an inventory with an owner and a classification. That turns registration, the rule Estonia never managed to enforce by review, into something the path checks for itself. The power to refuse belongs to whoever owns the interface, and it lasts only as long as that role does. A transformation program can charter the rule, but the program dissolves at close, and a rule left with a steering committee that no longer meets has gone back to depending on review. Exceptions carry a time limit and go to internal audit, so that a waiver has a cost and an expiry date.

The condition has edges. The first team through pays for the interface and delivers later than it promised, while software bought outside the technology function goes around it, as do vendor platforms that ship with their own data model. The interface records who asked for what and does nothing to settle what “customer” means, and the duplication ban stays a review rule everywhere except where the interface declines to serve a second source. Each rule in such a charter falls to one enforcer or the other, the path or a meeting, and the budget approval is the last point at which a director can still see which.

Estonia is now making the same move with its own review rules. All four options in the ministry’s January document retire the approval process, and the one its authors provisionally prefer keeps registration and recasts it as a filing in the state’s data portal, which the ministry intends to automate. The reform approved in July comes with an overhaul of how the state budgets for IT services and a statement that the state will no longer allow new systems that duplicate existing central ones. Each change takes a rule away from a reviewer and hands it to the budget or to the path.