Diagnose

Security by design in SPBE: five steps before go-live

The Sep 2026 BSSN–Kemenko Kumham MoU stresses secure SPBE. Five security-by-design steps—from Diagnose to Operate—before a digital system goes live.

Tim MarkasDevTechnology Partner, Jakarta
30 September 2026 · 7 min read
Illustration of a blue shield between two digital system blocks, symbolising security by design across the SPBE lifecycle

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

Related questions

What is the difference between security by design and a late security audit?
Security by design embeds criteria from planning, procurement, and each build milestone. A late audit is useful for verification, but expensive when architecture is already locked. BSSN urges security as a mandatory lifecycle concern, not a final checkbox.
Does the BSSN–Kemenko Kumham MoU bind local governments?
That MoU is a specific partnership between two central institutions (2026–2031). Local governments are not automatically bound by its text, but the policy signal is clear: secure, reliable, integrated SPBE is a priority. Security by design and CSIRT readiness remain sound operating practice.
Where should we start if the security budget is tight?
Prioritise impact classification, patching for systems that still receive updates, access control, tested backups, and an incident runbook. Run a short Diagnose to map assets and the largest gaps before buying new tools.
How does MarkasDev help without replacing BSSN or auditors?
We help on the engineering and operations side: clarifying security requirements in Diagnose, writing acceptance criteria in Deliver, and running Operate with monitoring and controlled change. Formal audits, certification, and legal opinions stay with the competent authority or your advisers.