On 23 September 2026, Coordinating Minister for Law, Human Rights, Immigration and Corrections Yusril Ihza Mahendra stressed that government digital transformation must rest on systems with high security and reliability. The same day, his ministry signed a memorandum of understanding with Indonesia National Cyber and Crypto Agency (BSSN) to strengthen electronic-system security, incident mitigation, and protection of government digital assets for 2026–2031—as reported by ANTARA.
The message reaches far beyond one ministry. For operations leaders in local government, regional SOEs, healthcare, local finance, and firms that serve the public sector, the practical question is the same: how do you bake security into the system lifecycle—not treat it as an end-of-project audit? BSSN Head Nugroho Sulistyo Budi said security must be part of planning, building, and further development. That matches the security by design principle BSSN has long promoted for Indonesia electronic-based government systems (SPBE).
Do not leave security to a final check (security at the end); design it in from the start (security by design).
This article summarises five operational steps you can take before go-live, drawing on public reporting and BSSN statements, then places them in MarkasDev Diagnose, Deliver, and Operate model. It is not legal advice, and it does not claim your organisation is bound by that MoU; it is a way to read the policy signal so technology decisions hold up under scrutiny.
Why security by design is urgent now
The ransomware incident against Indonesia Temporary National Data Centre (PDNS) in June 2024 was a costly reminder: disruption of shared infrastructure can cascade into immigration services, scholarship registration, and government records systems. According to GovInsider, citing BSSN Deputy Sulistyo, PDNS supported more than 228 ministries, agencies, and local governments. When one shared point fails, the blast radius is systemic.
BSSN also notes that government administration ranks among the three sectors with the highest traffic anomalies over the past three years; roughly 60–80 percent relate to malware. Recurring gaps are often mundane: pirated or expired licensed software, missing antivirus, and failed patching. Much risk falls with lifecycle discipline—not only with buying another security tool.
On the policy side, Presidential Regulation No. 132/2022 on SPBE Architecture already lists security as a domain. A draft Presidential Regulation on Digital Government is under discussion as a reflection on SPBE implementation. CSIRT coverage has risen sharply: Sulistyo said about 97 percent of ministries, agencies, and local governments had a cyber incident response team in 2025, up from about 42 percent the year before, with remaining gaps addressed in 2026. Response capacity is improving; what still lags is security design before systems are procured.
Five steps before go-live
1. Lock security criteria in Diagnose before the budget hardens
Security by design starts while scope is still cheap to change. In Diagnose, write down data classification (including personal and strategic data), threat assumptions, certification or security-testing requirements for products, access logging needs, and integration boundaries. Sulistyo stresses that security criteria should enter at procurement—not after a vendor is selected and the contract is hard to reopen.
When you work with external partners, Diagnose also prevents features first, security later. If you are still unsure whether the problem is process, architecture, or tooling, when a paid Diagnose makes sense is a cheaper starting point than a retrofit after go-live.
2. Make security acceptance criteria in every Deliver milestone
In Deliver, security needs written acceptance criteria per milestone: authentication and authorisation, secrets management, auditable logging, encryption at rest and in transit matched to classification, and vulnerability testing before release. Without that, done only means the UI works—not that the system is ready for real threats.
API integration is a frequent weak spot. When a new system connects to civil registries, ERPs, or third-party services, treat trust boundaries as design, not a footnote. See also system & API integration so interface contracts and access controls are tested—not only the happy path.
3. Plan patching and lifecycle as Operate, not an afterthought
BSSN warns that systems running for years without technology and security updates accumulate exposure. CVEs help only if patches are applied. That is why reactive maintenance versus Operate matters for critical systems: Operate implies a service owner, patch windows, monitoring, and controlled change—not waiting for breakage.
In every Deliver SOW, ask for an Operate draft early: who is on-call, response SLAs, licence policy, asset inventory, and decommissioning steps. Security does not end at the ribbon-cutting; risk often rises once the system becomes business as usual.
4. Stand up CSIRT capacity and runbooks before the first incident
No system is fully immune. BSSN pushes CSIRTs in ministries, agencies, and local governments—not only during attacks, but for procedures, drills, and early detection (defacement, data leaks, ransomware). If you lack an equivalent structure, at least define escalation paths, legal and communications contacts, backups with tested restores, and a runbook aligned with personal-data breach timelines (see our note on the PP 33/2026 countdown).
5. Match protection to impact, not to a polished demo
Sulistyo emphasises that critical information infrastructure and services touching human safety need stricter vulnerability management, testing, and maintenance. Manipulated medical records, or obsolete navigation systems, carry different consequences from a static info portal. Use impact classification to allocate security budget—rather than spreading thin protection evenly across every app.
A short checklist for operations leaders
- Are security criteria in the procurement or Diagnose pack before the RFP closes?
- Does every Deliver milestone have testable security acceptance criteria?
- Do patching, licences, and asset inventory have an owner under Operate?
- Does the CSIRT or equivalent have runbooks and drills—not only a decree on paper?
- Do high-impact systems get stricter testing and monitoring?
How MarkasDev places this in Diagnose–Deliver–Operate
MarkasDev is a Technology Partner, not a certified security auditor or a law firm. We help clarify risk and options in Diagnose, build with written acceptance criteria in Deliver—including custom software and servers and environments—then keep systems healthy with SLAs, monitoring, and controlled change in Operate. For readers in government and regional SOEs, see Government and regional SOEs.
If you are designing local SPBE capabilities, modernising a service, or integrating systems that touch citizen data, start from the asset list and security criteria—not from a feature catalogue. To discuss scope without a large upfront commitment, visit the contact page.
Sources