Almost everyone who runs systems in Indonesian local government has lived through this: another agency asks for data, the request sits for weeks waiting for a memorandum of understanding, and the spreadsheet that finally arrives uses different region codes and unit names. The numbers don't match, the coordination meeting is repeated, and decisions slip.
On Tuesday, 6 October 2026, Indonesia's House of Representatives (DPR) approved the One Data Indonesia (Satu Data Indonesia, SDI) bill to be enacted as law. For leaders and operations managers in local governments, regional state-owned enterprises (BUMD), regional hospitals, and any organisation that exchanges data with government, the real question is no longer whether this rule is coming, but what technical work comes with it.
What the DPR approved
The decision was taken at the 9th Plenary Session of the 2026-2027 sitting year, with every faction in favour. According to the report of working committee chair Sturman Panjaitan, the bill, which was initiated by the DPR, has 20 chapters and 141 articles. The government submitted 1,338 problem inventory items (DIM) on the body of the bill and 829 on its elucidation.
Points read out in the committee report, as summarised by detikcom and ANTARA, include:
- National Base Data (Data Dasar Nasional, DDN) is controlled by the state and becomes the main reference for development planning, fiscal policy and budgeting, and social assistance distribution. DDN is grouped into six clusters and classified as open, restricted, or closed.
- Data standards, metadata, reference codes and/or master data, and a national data catalogue system must be applied by every data producer and data custodian.
- Interoperability is carried out without physically centralising databases and without moving ownership or management responsibility away from the data producer.
- An SDI operator reporting to the President is to be formed within one year at the latest, with coordinating, standard-setting, and facilitating functions.
- Security: data security standards from the national cyber and cryptography agency, cryptographic infrastructure and digital certificates, security audits and data sovereignty audits, and incident reporting within 1 x 24 hours.
- Access: access to restricted data may be charged as non-tax state revenue, and transfers of closed data outside Indonesian jurisdiction require DPR approval.
- Technology: use of digital technology, blockchain, and artificial intelligence that safeguards data sovereignty, traceability, and human oversight.
One more provision deserves attention. In the legislation committee meeting on 5 October, deputy chair Martin Manurung explained that disseminating and using data within the SDI framework would not require a memorandum of understanding, cooperation agreement, or statement document, as reported by Kompas.com.
"One data" is not one database
The most expensive misreading is to assume One Data means moving all data onto one big server. Sturman answered that firmly in the plenary: "Must all data be centralised in one place? The answer is no, no and no," as quoted by Liputan6. What gets standardised is the language: metadata, reference codes, and master data, so that different systems can understand each other.
That means the biggest job is not a migration project or a new dashboard. The biggest job is integration: making sure every system already running can present its data with the same codes, clear descriptions, and controlled access. We covered this pattern in our lessons on data integration before AI: without clean, connected data, the technology on top only speeds up the mess.
What changes for people who run systems
Reference codes and master data become routine work. Many regional applications keep their own version of region codes, work units, or service types. Once national standards apply, every system needs a mapping table that is maintained, not fixed once and forgotten.
Catalogues and metadata have to stay alive. A national data catalogue is only useful if metadata is updated whenever a data structure changes. That needs a clear owner and a release process, not a document attachment.
"We don't have an agreement yet" stops being an excuse. If sharing within the SDI framework no longer waits for an MoU, the bottleneck moves to the technical side: a secure API, authentication, access limits by classification, and a log of who pulled what.
Incidents must be reported within 24 hours. That duty can only be met if incidents are detected first. Organisations without monitoring, runbooks, and a clear owner will struggle to meet the deadline.
Classification shapes architecture. Open, restricted, and closed data need different access paths, storage locations, and controls. Where the data is also personal data, the Personal Data Protection Law and Government Regulation 33/2026 still apply alongside it.
What is still unclear
At the time of writing we had not found an officially published final text. The summary above comes from the committee report read in the plenary and from media coverage. The report also mentions tiered data custodians down to village level and corporations, but the specific duties for BUMD or companies, the fees for restricted data access, and who the operator will be still depend on the official text and implementing regulations. So the best move now is preparation that stays useful whatever the final details turn out to be.
Practical steps for the next 90 days
- Inventory datasets and systems. Record who produces each dataset, who is its custodian, which system holds it, which format it uses, and which reference codes it relies on.
- Start with the most requested datasets. Pick the few datasets most often sent to other agencies and clean up their metadata and codes first.
- Offer a sharing interface, not copies. Provide an API with authentication, access control, and logging, so the data stays in its source system.
- Classify your data. Mark what is open, restricted, and closed, and map where it overlaps with personal data.
- Test the 24-hour incident flow. Run a drill: who detects, who decides, who reports, and how long it actually takes.
Where MarkasDev can help
This work is safest when done in stages. In the Diagnose phase, we map datasets, systems, reference codes, and security gaps before the budget is locked. In the Deliver phase, we build sharing APIs, mapping tables, and access controls in milestones with written acceptance criteria, as part of our systems & API integration service. In the Operate phase, we keep monitoring, metadata updates, and incident-reporting readiness running under an SLA.
If your organisation exchanges data with government and wants to know how ready its current systems are, request a Diagnose through our contact page. We start with the data you send most often today.
Sources