Does a managed SOC help a bank meet SEOJK 29/2022?

Yes, on the monitoring and incident-management side. SEOJK 29/2022 requires continuous monitoring of critical systems, log collection with retention of at least five years, and an incident response plan that is tested. A managed SOC provides the round-the-clock monitoring, the log pipeline that meets the retention rule, and the detection testing the regulation expects. It does not replace the bank's own governance, asset register, or third-party risk work, which are separate control domains.

What are the OJK incident-reporting deadlines the SOC has to support?

Under SEOJK 29/2022 a bank sends an initial incident notification to OJK within 1x24 hours of discovering a cyber incident, then a full report within 5 working days. Our SOC is built around those two clocks: detection and triage feed the initial notification, and the investigation record feeds the full report, so the reporting timeline is not being assembled from scratch while an incident is still active.

Can you monitor core banking and payment systems, not just endpoints?

Yes. We collect logs from core banking platforms, the SWIFT environment, ATM networks, internet and mobile banking channels, and the BI-FAST and QRIS payment rails, alongside endpoints, servers, and cloud. Correlating a suspicious core-banking transaction against authentication and network signals is where financial-sector detection differs from generic monitoring.

Do we still need our own incident response team if we use your SOC?

The SOC detects, triages, and contains. For a serious incident, deeper forensic investigation and recovery run through our incident response service, and the bank keeps ownership of the regulatory relationship with OJK and of business decisions such as invoking the business continuity plan. Many banks use the SOC as the always-on layer and call on incident response for the events that escalate.

Is a managed SOC only for tier-1 banks?

No. Rural banks (BPR/BPRS) and multi-finance companies face the same class of threats and their own OJK obligations, but rarely have the headcount to run a 24/7 SOC in-house. A managed model gives a smaller institution the same continuous coverage without hiring and retaining a full analyst rota.

Managed SOC for banks Indonesia

An Indonesian bank does not choose when it gets attacked. Core banking runs overnight, ATMs and QRIS never close, and OJK expects the bank to notice a cyber incident and start reporting it on a fixed clock. A security operations centre is the function that watches for those incidents around the clock. Most institutions below the largest tier-1 banks cannot staff one on their own, and that is where a managed SOC fits.

This page is about running that SOC for an Indonesian bank specifically: the threats that reach financial systems, the OJK and Bank Indonesia rules that set the pace, and what we actually monitor. For how a SOC works in general terms, see our SOC-as-a-Service service page.

Why banks need a managed SOC

Financial systems are attacked because that is where the money and the customer data sit. The threat profile that reaches an Indonesian bank is narrower and more specific than the generic list, and it shapes what the SOC has to watch for.

Ransomware on core banking

Ransomware groups target core banking systems, SWIFT infrastructure, and ATM networks. One successful attack can freeze billions in transactions, and the OJK reporting clock starts the moment the incident is discovered, so a slow response is doubly costly.

Credential and OTP theft

Banking trojans and mobile malware target Indonesian banking apps and internet banking, harvesting customer credentials, OTP codes, and session tokens to authorise fraudulent transactions in real time. Detecting this needs correlation across the application and authentication layers.

Open banking API abuse

The BI-SNAP open banking rollout connects core infrastructure to dozens of licensed fintech partners through APIs. Each connection widens the attack surface, and a weak or abused API is a route to data exfiltration, account takeover, and unauthorised payments.

Privileged insider abuse

Staff with access to customer data, transaction systems, and reporting platforms carry a large insider risk. Privileged access abuse drives a significant share of data breaches in Indonesian banking, which is why monitoring privileged sessions is a standing SOC use case.

On top of the threats, the regulator sets the pace. POJK 11/2022 treats cyber risk as one of eight risk categories a commercial bank must manage, and SEOJK 29/2022 turns that into specific obligations: continuous monitoring of critical systems, log collection with retention of at least five years, a tested incident response plan, and incident reporting to OJK on a tight timeline. On the payment side, PBI 23/6/2021 requires transaction monitoring and fraud detection across QRIS, BI-FAST, and electronic fund transfer. UU PDP adds a 72-hour breach-notification duty when customer personal data is involved. A managed SOC is the operational layer that makes the monitoring, detection, and reporting parts of those rules real rather than written policy.

The table below maps the monitoring-related obligations to what the SOC actually does. Governance, the asset register, and third-party risk are separate control domains covered by our GRC and compliance work, not the SOC.

Regulatory obligation	Where it comes from	How the managed SOC meets it
Continuous monitoring of critical systems	SEOJK 29/2022	24/7 log collection, correlation, and analyst triage across core banking, channels, and payment rails
Log retention of at least five years	SEOJK 29/2022	Log pipeline sized for 5-year retention (online plus archive) with integrity controls
Tested detection and incident response plan	SEOJK 29/2022	Documented playbooks, periodic detection testing, and tabletop support
Initial incident notification within 1x24 hours	SEOJK 29/2022	Detection and triage feed the initial notification to OJK
Full incident report within 5 working days	SEOJK 29/2022	Investigation record and timeline assembled into the full report
Transaction and fraud monitoring	PBI 23/6/2021	Fraud and anomaly use cases across QRIS, BI-FAST, and EFT
Breach notification within 72 hours	UU PDP	Incident record supports the personal-data breach notification

How we deliver it for banks

A financial SOC is defined by what it can see. Endpoint telemetry alone is not enough when the value sits in the transaction systems, so we collect and correlate logs from across the banking estate rather than a single layer.

Core banking platforms (Temenos, Silverlake, Sunline)SWIFT messaging environmentATM networkInternet and mobile banking channelsBI-FAST, QRIS, and EFT payment railsOpen banking API gatewaysEndpoints, servers, and cloud workloadsIdentity and privileged access systems

The point of pulling these together is correlation. A single suspicious transaction in the core banking log may look routine on its own, but read alongside an unusual privileged login and outbound traffic to an unfamiliar destination, it becomes an incident worth escalating. Our analysts are based in Indonesia and work banking use cases, so triage is tuned to financial-sector patterns rather than a generic ruleset. The service runs in four continuous phases.

Onboard log sources and set banking baselines→Monitor and correlate 24/7→Triage, contain, and escalate per playbook→Feed the OJK reporting clock and tune detection

The reporting clock is the part that is hardest to improvise, so the SOC is built around it. SEOJK 29/2022 runs two windows from the moment an incident is discovered: a short one for the initial notification and a second for the full report. Detection and triage have to be fast enough to start the first window, and the investigation record has to be complete enough to fill the second.

Stage	Deadline under SEOJK 29/2022	What the SOC does
Incident discovered	Clock starts	Detection fires, analyst confirms and classifies the incident
Initial notification to OJK	Within 1x24 hours	Triage output provides the facts for the written notification
Containment	As fast as the incident allows	Analysts contain per playbook and preserve evidence
Full incident report to OJK	Within 5 working days	Investigation timeline, impact, and root cause assembled into the report

When an incident escalates beyond containment, our incident response service takes over the deeper forensic investigation and recovery, while the bank keeps ownership of the OJK relationship and business-continuity decisions. For the full picture of what commercial banks must satisfy under both regulations, see our page on commercial bank cybersecurity compliance under POJK 11/2022 and SEOJK 29/2022. Rural banks work to a separate framework covered in our BPR compliance page under POJK 34/2025.

What the numbers say about the sector

US$20M

Ransom demanded in the 2023 Bank Syariah Indonesia attack, which disrupted services for 13 days (The Jakarta Post)

US$3.33M

Average data breach cost in ASEAN in 2024 (IBM, Cost of a Data Breach 2024)

12%

Of Indonesian organisations rated mature on cyber readiness in 2024 (Cisco Cybersecurity Readiness Index 2024)

The Bank Syariah Indonesia case is the reference point most Indonesian banks use internally: a single ransomware attack that disrupted services for roughly two weeks and pushed OJK to tighten incident-reporting guidance across the sector. The ASEAN breach cost and the low cyber-readiness rate explain why continuous monitoring is now treated as a baseline control rather than an upgrade. For a deeper read of the OJK requirements behind all of this, see our article on OJK cybersecurity requirements for Indonesian banks.

If you want to understand what a managed SOC would cover for your institution and how it maps to your OJK obligations, our team can set out a concrete first step.

References

Managed SOC for Indonesian banks and financial services

Why banks need a managed SOC

How we deliver it for banks

What the numbers say about the sector

Frequently asked questions

Related

Our services

Ready to strengthen your security posture?