# BAB 15 — Risiko, Keamanan, dan Tata Kelola SI


```
Bagian          : VI — Implementasi, Evaluasi & Risiko
Reader Outcome  : Pembaca mampu mengidentifikasi risiko SI utama, mengevaluasi
                  kematangan tata kelola SI organisasi, dan merancang respons
                  risiko berbasis perspektif manajerial.
Level           : Lanjutan–Mahir
Estimasi Halaman: 15–18
```

---

## 15.1 Pembuka

Bab 14 membekali Anda dengan kerangka evaluasi nilai bisnis SI — NPV, ROI, *Payback Period*, dan *Balanced Scorecard*. Template A.14 (*Business Case* Mini) memastikan setiap investasi SI dijustifikasi dengan data. Nilai sudah dibuktikan. Tetapi nilai itu bisa musnah dalam semalam.

13 Mei 2017, pukul 06.00 WIB. Petugas registrasi RS Kanker Dharmais Jakarta menyalakan komputer dan mendapati layar terkunci — pesan menuntut pembayaran Bitcoin untuk membuka *file*. Seluruh SIMRS tidak bisa diakses: registrasi pasien lumpuh, resep obat tidak bisa diproses via sistem, rekam medis elektronik terkunci. Di rumah sakit yang menangani pasien kanker kritis, kehilangan akses informasi bukan sekadar ketidaknyamanan — ia ancaman terhadap keselamatan pasien.

Penyebabnya: *ransomware* WannaCry. Bukan serangan yang ditargetkan ke RS Dharmais — *malware* ini menyebar otomatis ke komputer dengan Windows yang belum di-*patch*. Microsoft sudah merilis *patch* keamanan dua bulan sebelumnya. RS Dharmais belum menerapkannya. Satu *patch* yang tertunda — investasi miliaran rupiah di SIMRS kehilangan nilai dalam hitungan menit.

Mengapa risiko SI bukan hanya masalah teknis tetapi masalah manajerial — dan bagaimana tata kelola SI memastikan organisasi tahu risiko apa yang mereka ambil dan mengapa?

---

## 15.2 Model Utama

### Gambar 15.1 — Kerangka Tata Kelola & Risiko SI

```mermaid
graph TD
    RS["Risiko<br>Strategis"] --> ID["Identifikasi<br>Risiko"]
    RO["Risiko<br>Operasional"] --> ID
    RK["Risiko<br>Keamanan"] --> ID
    ID --> PA["Penilaian<br>Probabilitas × Dampak"]
    PA --> MIT["Mitigasi &<br>Respons"]
    MIT --> GOV["IT Governance<br>Framework"]
    GOV --> COBIT["COBIT 2019"]
    GOV --> ISO["ISO 27001"]
    GOV --> NIST["NIST CSF"]
    GOV --> POL["Kebijakan &<br>Kontrol Organisasi"]
    POL --> MON["Monitor &<br>Review Berkelanjutan"]
    MON -.-> ID
    style RS fill:#5c1a1a,stroke:#333,color:#fff
    style RO fill:#5c1a1a,stroke:#333,color:#fff
    style RK fill:#5c1a1a,stroke:#333,color:#fff
    style ID fill:#5c1a1a,stroke:#333,color:#fff
    style PA fill:#5c1a1a,stroke:#333,color:#fff
    style MIT fill:#5c1a1a,stroke:#333,color:#fff
    style GOV fill:#f5f5f5,stroke:#5c1a1a,color:#333
    style COBIT fill:#5c1a1a,stroke:#333,color:#fff
    style ISO fill:#5c1a1a,stroke:#333,color:#fff
    style NIST fill:#5c1a1a,stroke:#333,color:#fff
    style POL fill:#5c1a1a,stroke:#333,color:#fff
    style MON fill:#5c1a1a,stroke:#333,color:#fff
```

**Tiga Jenis Risiko SI** — risiko tidak monolitik. Risiko strategis: SI tidak *aligned* dengan strategi bisnis, investasi yang salah arah, disrupsi teknologi yang meninggalkan organisasi. Risiko operasional: *downtime*, *data loss*, *system failure*, *human error*, ketergantungan pada personel kunci. Risiko keamanan: *cyberattack* (*malware*, *ransomware*, *phishing*), *data breach*, *insider threat*, akses tidak sah.

**Identifikasi → Penilaian → Mitigasi** — siklus manajemen risiko klasik. Identifikasi: apa saja risiko yang dihadapi? Penilaian: seberapa besar probabilitas dan dampaknya? Mitigasi: apa yang dilakukan — *avoid*, *reduce*, *transfer* (asuransi), atau *accept*? Manajer harus terlibat di identifikasi dan penilaian; tim IT di mitigasi teknis.

**IT *Governance Framework*** — kerangka yang memastikan risiko dikelola secara terstruktur, bukan *ad hoc*. COBIT 2019 untuk tata kelola TI, ISO 27001 untuk manajemen keamanan informasi, NIST CSF untuk *cybersecurity*. Ketiganya saling melengkapi — bukan saling menggantikan.

**Kebijakan & Kontrol Organisasi** — *framework* tanpa kebijakan hanyalah dokumen di rak. Kebijakan organisasi menerjemahkan *framework* menjadi aturan yang *enforceable*: siapa bertanggung jawab atas apa, prosedur apa yang wajib diikuti, sanksi apa jika dilanggar.

**Monitor & Review Berkelanjutan** — garis putus-putus dari *monitoring* kembali ke identifikasi menunjukkan bahwa risiko berevolusi. Ancaman baru muncul, teknologi berubah, regulasi diperbarui. Tata kelola bukan *one-time setup* — ia *continuous process*.

---

## 15.3 Definisi Kunci

📌 **Model CIA (*Confidentiality, Integrity, Availability*)**
Tiga pilar keamanan informasi: *Confidentiality* — hanya pihak yang berhak yang bisa mengakses informasi; *Integrity* — informasi tidak diubah tanpa otorisasi; *Availability* — informasi tersedia saat dibutuhkan. CIA memberikan bahasa yang dapat digunakan manajer tanpa jargon teknis: "Data gaji karyawan harus *confidential* (hanya HR yang akses). Laporan keuangan harus terjaga *integrity*-nya (tidak bisa diubah setelah *closing*). SIMRS harus *available* 24/7 — termasuk saat bencana" (Whitman & Mattord, 2022).

📌 **IT *Governance***
Kerangka tanggung jawab yang memastikan investasi TI menghasilkan nilai bisnis, mengelola risiko TI, dan memastikan kepatuhan terhadap regulasi. Perbedaan krusial: *governance* ≠ *management*. *Governance* menentukan "apa yang harus dicapai" — tanggung jawab *board* dan *C-suite*. *Management* menentukan "bagaimana mencapainya" — tanggung jawab tim IT dan operasional. ISACA (2024) melaporkan bahwa organisasi dengan IT *governance* formal memiliki *incident rate* 40% lebih rendah dan efisiensi belanja IT 25% lebih tinggi.

📌 **UU PDP (Undang-Undang Pelindungan Data Pribadi)**
UU No. 27 Tahun 2022 yang mengatur pengumpulan, pemrosesan, dan penyimpanan data pribadi di Indonesia — berlaku penuh Oktober 2024. Setiap SI yang memproses data pribadi (nama, NIK, alamat, data kesehatan, data finansial) harus *compliant*. Kewajiban utama: persetujuan (*consent*), minimisasi data, pembatasan tujuan, notifikasi *breach* dalam 72 jam. Sanksi pelanggaran: hingga Rp 70 miliar atau 2% pendapatan tahunan — mana yang lebih besar.

---

## 15.4 Konsep Inti

### 15.4.1 Tipologi Risiko SI: Bukan Hanya Soal *Hacker*

Risiko SI mencakup spektrum yang jauh lebih luas dari serangan siber. Manajer yang hanya memikirkan "bagaimana jika di-*hack*" melewatkan risiko lain yang probabilitasnya lebih tinggi dan dampaknya sama besarnya:

### Tabel 15.2 — Tipologi Risiko SI

| Jenis Risiko | Contoh | Dampak | Penanggung Jawab |
|-------------|--------|--------|-----------------|
| Teknis | *Server crash*, *bug* kritis, *database corruption* | *Downtime*, kehilangan data | Tim IT |
| Operasional | *Human error*, proses gagal, *key person dependency* | Inefisiensi, *error* berulang | Manajer operasional |
| Keamanan | *Ransomware*, *data breach*, *phishing*, *insider threat* | Kebocoran data, kerugian finansial | CISO + *Board* |
| Strategis | SI tidak *aligned*, teknologi usang, investasi salah arah | Investasi gagal, tertinggal kompetitor | *C-suite* |
| Reputasional | Kebocoran data pelanggan, *service outage* publik | Kepercayaan hancur, pelanggan pergi | *Board* + Humas |

Setiap jenis risiko memerlukan penanggung jawab yang berbeda — dan inilah mengapa risiko SI bukan "urusan IT saja." Risiko strategis berada di ranah *C-suite*. Risiko reputasional memerlukan respons dari *board* dan komunikasi publik. Risiko operasional melibatkan manajer di setiap unit bisnis.

### 15.4.2 Model CIA: Keamanan dalam Bahasa Bisnis

CIA bukan sekadar akronim teknis — ia *framework* yang membantu manajer mengartikulasikan kebutuhan keamanan dalam bahasa yang dipahami seluruh organisasi:

***Confidentiality*** — siapa yang boleh melihat informasi ini? Data medis pasien hanya boleh diakses dokter dan perawat yang merawat — bukan seluruh staf RS. Data gaji hanya boleh diakses HR dan karyawan yang bersangkutan. Pelanggaran *confidentiality* di era UU PDP bisa berujung sanksi miliaran Rupiah.

***Integrity*** — apakah informasi ini bisa dipercaya keakuratannya? Laporan keuangan yang sudah di-*audit* tidak boleh diubah. Rekam medis tidak boleh dimodifikasi tanpa jejak. Skor kredit nasabah harus mencerminkan data sebenarnya. Jika *integrity* data diragukan, seluruh keputusan yang didasarkan pada data tersebut ikut diragukan.

***Availability*** — apakah informasi ini tersedia saat dibutuhkan? SIMRS harus *available* 24/7 — dokter di UGD tidak bisa menunggu "sistem sedang *maintenance*." Sistem perbankan harus *available* selama jam operasional — *downtime* 1 jam berarti jutaan transaksi tertunda.

Setiap keputusan keamanan SI bisa dievaluasi melalui lensa CIA: tindakan apa yang meningkatkan C, I, atau A — dan tindakan apa yang mengorbankan salah satunya (misalnya: *encryption* yang terlalu ketat bisa menurunkan A karena memperlambat akses).

### 15.4.3 Tata Kelola SI vs Manajemen SI: Perbedaan Kritis

Banyak organisasi menyamakan tata kelola (*governance*) dengan manajemen (*management*). Keduanya penting tetapi berbeda secara hakiki:

***Governance*** bertanya: "Apakah organisasi melakukan hal yang benar?" Apakah investasi SI selaras dengan strategi? Apakah risiko berada di level yang bisa diterima? Apakah regulasi dipatuhi? *Governance* menentukan arah dan melakukan *oversight* — ini tanggung jawab *board* dan *C-suite*.

***Management*** bertanya: "Apakah organisasi melakukannya dengan benar?" Apakah *server* di-*maintain* dengan baik? Apakah *backup* berjalan rutin? Apakah *help desk* responsif? *Management* mengeksekusi dan mengoperasionalkan — ini tanggung jawab CIO, CTO, dan tim IT.

Organisasi yang memiliki manajemen IT tanpa *governance* ibarat kapal yang berlayar dengan baik — tetapi tidak tahu apakah arahnya benar. Schinagl dan Shahim (2022) menemukan bahwa organisasi dengan pemisahan jelas antara *governance* dan *management* memiliki insiden keamanan 35% lebih sedikit dibandingkan yang mencampurnya.

### 15.4.4 *Framework Governance*: COBIT 2019, ISO 27001, NIST CSF

Manajer tidak perlu menguasai detail teknis setiap *framework* — tetapi perlu memahami kegunaan dan cakupan masing-masing:

**COBIT 2019** — *framework* tata kelola dan manajemen TI dari ISACA. Mencakup 40 proses dalam 5 domain. Yang perlu dipahami manajer: prinsip *governance* EDM (*Evaluate, Direct, Monitor*). *Evaluate*: apakah kebutuhan *stakeholder* terpenuhi? *Direct*: arahkan sumber daya TI. *Monitor*: pantau kinerja dan kepatuhan. COBIT cocok untuk organisasi yang ingin membangun *IT governance* komprehensif.

**ISO 27001:2022** — standar internasional untuk *Information Security Management System* (ISMS). Berbasis kepatuhan: organisasi harus memenuhi persyaratan (*requirements*) dan bisa disertifikasi melalui audit eksternal. Yang perlu dipahami manajer: sertifikasi ISO 27001 memberikan jaminan kepada pelanggan dan regulator bahwa keamanan informasi dikelola secara sistematis — bukan reaktif.

**NIST *Cybersecurity Framework* 2.0** — *framework* dari NIST (AS) dengan 6 fungsi: *Govern, Identify, Protect, Detect, Respond, Recover*. Paling intuitif untuk manajer karena mengikuti alur logis: ketahui aset dan risiko (*Identify*), lindungi (*Protect*), deteksi ancaman (*Detect*), respons jika terjadi insiden (*Respond*), pulihkan (*Recover*), dan kelola secara berkelanjutan (*Govern*). NIST CSF cocok untuk organisasi yang ingin memulai dari *cybersecurity* dan berkembang ke *governance* lebih luas.

### 15.4.5 *Compliance* dan Regulasi Data: UU PDP dan Implikasinya

Pasca UU PDP (UU No. 27 Tahun 2022), *compliance* data di Indonesia bukan lagi opsional. Setiap SI yang memproses data pribadi harus memenuhi ketentuan:

1. ***Consent*** — data pribadi hanya boleh dikumpulkan dan diproses dengan persetujuan eksplisit dari pemilik data. "Dengan mengklik tombol ini, Anda menyetujui..." harus jelas dan spesifik.
2. **Minimisasi data** — hanya kumpulkan data yang benar-benar diperlukan. SI yang meminta NIK, nama ibu kandung, dan golongan darah untuk mendaftar *newsletter* melanggar prinsip minimisasi.
3. **Pembatasan tujuan** — data yang dikumpulkan untuk tujuan A tidak boleh digunakan untuk tujuan B tanpa persetujuan baru.
4. **Notifikasi *breach*** — jika terjadi kebocoran data, organisasi wajib memberitahu pemilik data dan otoritas dalam 72 jam.
5. **Hak hapus** — pemilik data berhak meminta seluruh datanya dihapus (*right to erasure*).

Implikasi teknis untuk SI: *database* harus mendukung *data deletion* (bukan hanya *soft delete*), *encryption at rest* dan *in transit* menjadi standar minimal, *audit trail* yang mencatat siapa mengakses data apa dan kapan harus tersedia, dan mekanisme *consent management* harus dibangun ke dalam SI.

UU PDP Indonesia terinspirasi dari GDPR (*General Data Protection Regulation*) Eropa. Perbedaan utama: GDPR sudah memiliki rekam jejak penegakan (denda €1,2 miliar terhadap Meta pada 2023), sementara penegakan UU PDP Indonesia masih dalam tahap awal. Tetapi menunggu sampai ada penegakan untuk baru *comply* adalah strategi yang berisiko tinggi.

### 15.4.6 Peran *Board* dan Manajemen Senior dalam *Oversight* SI

IT *governance* bukan tanggung jawab CIO atau CTO saja — ia tanggung jawab *board of directors*. *Board* harus mampu menjawab empat pertanyaan:

1. **Risiko SI apa yang dihadapi organisasi?** — bukan detail teknis, tetapi risiko bisnis yang bersumber dari SI.
2. **Berapa *risk appetite* organisasi?** — organisasi tidak bisa mengeliminasi semua risiko; pertanyaannya adalah risiko mana yang diterima dan mana yang dimitigasi.
3. **Apakah kontrol yang ada memadai?** — apakah ada *gap* antara risiko yang diidentifikasi dan kontrol yang diterapkan?
4. **Apakah belanja IT *aligned* dengan strategi?** — apakah investasi SI menghasilkan nilai yang diharapkan (Bab 14)?

Spencer Stuart (2024) mencatat bahwa 78% *board* Fortune 500 memiliki setidaknya satu anggota dengan keahlian IT. Di Indonesia, angka ini masih di bawah 20% (Rahardjo & Susanto, 2022). Ketimpangan ini berarti *board* di banyak organisasi Indonesia tidak memiliki kapasitas untuk melakukan *oversight* SI secara efektif — menjadikan risiko SI sebagai *blind spot* di level tertinggi.

---

## 15.5 Komparasi

### Tabel 15.1 — Tipologi Risiko SI: Probabilitas × Dampak × Strategi Mitigasi (8 Skenario)

| No | Skenario Risiko | Probabilitas | Dampak | Strategi Mitigasi |
|----|----------------|-------------|--------|------------------|
| 1 | *Ransomware attack* | Tinggi | Kritis (operasi lumpuh) | *Backup* 3-2-1, *patch management*, *security awareness* |
| 2 | *Data breach* (*insider*) | Menengah | Tinggi (reputasi + legal) | *Access control*, monitoring, *compliance* UU PDP |
| 3 | *Server failure* | Menengah | Tinggi (*downtime*) | Redundansi, *failover*, SLA *cloud provider* |
| 4 | *Key person dependency* | Tinggi | Menengah (*knowledge loss*) | Dokumentasi, *cross-training*, *succession plan* |
| 5 | Vendor *discontinue* produk | Rendah | Tinggi (migrasi paksa) | *Multi-vendor strategy*, *data portability* (Bab 12) |
| 6 | Pelanggaran *compliance* | Menengah | Tinggi (sanksi hukum) | *Compliance officer*, audit berkala, pelatihan |
| 7 | *Shadow IT* tidak terkendali | Tinggi | Menengah (*data silos*) | Kebijakan *governance*, daftar *tool* terotorisasi |
| 8 | *Strategic misalignment* | Menengah | Kritis (investasi sia-sia) | *Review* strategi IT tahunan, BSC (Bab 14) |

💡 **Insight:** Enam dari delapan skenario di atas bisa dimitigasi dengan kebijakan dan proses (*governance*) — bukan dengan teknologi. *Ransomware* dicegah oleh disiplin *patching* dan *backup*, bukan oleh *firewall* mahal. *Insider threat* dicegah oleh *access control* dan kultur keamanan, bukan oleh *software* pemantauan. Ini menegaskan bahwa risiko SI adalah masalah manajerial, bukan semata-mata masalah teknis.

---

## 15.6 Realitas Lapangan

### Fenomena 1: RS Kanker Dharmais — *Ransomware* WannaCry

13 Mei 2017: *ransomware* WannaCry menyerang lebih dari 200.000 komputer di 150 negara. RS Kanker Dharmais Jakarta termasuk di antaranya. Seluruh terminal SIMRS terkunci — registrasi manual dengan kertas, resep obat ditulis tangan, rekam medis tidak bisa diakses. Tim IT tidak memiliki *incident response plan*, *backup* terakhir berumur satu bulan (artinya satu bulan data potensial hilang), dan komunikasi krisis ke pasien dan media tidak terkoordinasi.

Akar masalahnya sederhana namun serius: sistem operasi Windows di komputer RS belum di-*patch*. Microsoft sudah merilis *patch* MS17-010 pada 14 Maret 2017 — dua bulan sebelum WannaCry menyebar. *Patch* ini menutup persis celah yang dieksploitasi WannaCry. Menerapkan *patch* memerlukan waktu beberapa jam dan tidak memerlukan investasi tambahan. Tetapi tanpa kebijakan *patch management* yang terstruktur, *patch* ini tertunda — dan satu penundaan itu menghancurkan akses informasi seluruh RS.

💡 **Insight:** RS Dharmais bukan korban serangan yang ditargetkan — ia korban kelalaian *basic hygiene*. Studi industri menunjukkan bahwa 80% *breach* bisa dicegah dengan kontrol dasar: *patch* tepat waktu, *strong password*, *backup* rutin, dan *access control* yang ketat. Investasi miliaran di SIMRS kehilangan nilai bukan karena serangan canggih, tetapi karena satu *patch* yang tertunda.

### Fenomena 2: Equifax 2017 — Kegagalan *Governance* yang Mengorbankan 148 Juta Orang

September 2017: data pribadi 148 juta orang bocor dari Equifax, salah satu biro kredit terbesar di AS. Data yang bocor: nama, SSN (*Social Security Number*), tanggal lahir, alamat, dan sebagian nomor kartu kredit. Dampak: *settlement* $700 juta, CEO/CIO/CISO *resign*, reputasi hancur, dan regulasi baru dipicu oleh insiden ini.

Penyebab langsung: *vulnerability* di Apache Struts yang sudah dipublikasikan dan di-*patch* oleh vendor pada 8 Maret 2017. US-CERT mengirimkan *advisory* pada 10 Maret. Equifax melakukan *scan* pada 15 Maret — tetapi *scan* gagal mendeteksi server yang *vulnerable*. *Attacker* mulai mengeksfiltrasi data pada 13 Mei dan baru terdeteksi pada 29 Juli — 77 hari kemudian.

Tetapi akar masalah sebenarnya ada di *governance*: CISO Equifax berlatar belakang musik, bukan keamanan informasi. *Board* tidak memiliki komite keamanan IT. *Vulnerability management* tidak memiliki *accountability* yang jelas. Audit internal tidak efektif. Equifax memiliki sertifikasi PCI-DSS (*Payment Card Industry Data Security Standard*) — *compliant*, tetapi tidak *secure*.

💡 **Insight:** Equifax membuktikan bahwa *compliance* ≠ keamanan. Sertifikasi dan *checklist* regulasi memastikan standar minimum terpenuhi — bukan bahwa organisasi benar-benar aman. *Governance* yang gagal — *board* tanpa *oversight*, CISO tanpa kompetensi, *vulnerability management* tanpa akuntabilitas — membuat *compliance* menjadi formalitas tanpa substansi.

### Fenomena 3: *Shadow IT* di Indonesia — Ketika Karyawan Membangun "Sistem Sendiri"

Penggunaan aplikasi tidak resmi (*shadow IT*) menjadi tantangan nyata di banyak organisasi Indonesia — karyawan menggunakan WhatsApp untuk berbagi data keuangan klien, Google *Sheets* personal untuk menyimpan data pelanggan, atau Dropbox pribadi untuk *backup* dokumen kerja, seringkali tanpa menyadari risiko keamanan dan kepatuhan yang menyertainya.

Alasan yang diberikan karyawan konsisten: "Aplikasi resmi terlalu sulit digunakan." "IT terlalu lama menyetujui permintaan *software* baru." "WhatsApp lebih cepat daripada *email* kantor." Dari perspektif karyawan, *shadow IT* adalah solusi pragmatis untuk masalah nyata.

Dari perspektif keamanan dan *compliance*, *shadow IT* adalah bom waktu: data pelanggan tersebar di *platform* yang tidak terkontrol organisasi, tidak ada *backup* terpusat, *access control* tidak berlaku (siapa saja di grup WhatsApp bisa melihat data), dan *compliance* UU PDP terancam karena data pribadi diproses di luar persetujuan dan tanpa *audit trail*.

💡 **Insight:** *Shadow IT* bukan musuh yang harus dibasmi — ia sinyal bahwa SI resmi tidak memenuhi kebutuhan pengguna. Respons yang tepat bukan "larang semuanya" — yang hanya mendorong perilaku *underground*. Respons yang efektif: (1) dengarkan mengapa pengguna menggunakan *shadow IT*, (2) perbaiki SI resmi berdasarkan *feedback* tersebut, (3) sediakan alternatif terotorisasi yang sama mudahnya, (4) edukasi risiko tanpa menghakimi.

---

## 15.7 Salah Kaprah

⚠️ ***"Keamanan SI itu urusan tim IT dan cybersecurity, bukan manajer umum"***

> Manajer menentukan data apa yang dikumpulkan, siapa yang boleh mengakses, dan bagaimana data digunakan — semua ini adalah keputusan keamanan yang dimulai dari bisnis, bukan dari IT. Manajer unit yang memutuskan "seluruh staf boleh akses data pelanggan" telah membuat keputusan keamanan — meskipun tidak menyadarinya. Ketika data bocor, pertanyaan pertama regulator adalah: "Siapa yang memutuskan *access control*-nya?"
>
> **Koreksi:** Setiap manajer harus mengetahui minimal tiga hal tentang unit kerjanya: data sensitif apa yang dimiliki (*inventory*), siapa yang boleh mengaksesnya (*access control*), dan apa yang terjadi jika data tersebut bocor (*impact assessment*). Model CIA membantu mengartikulasikan ini tanpa jargon teknis.

⚠️ ***"Sudah pasang antivirus, berarti aman"***

> *Antivirus* hanyalah satu lapisan dari *defense-in-depth*. Sebagian besar *breach* terjadi bukan karena *malware* menembus *antivirus*, tetapi karena: *phishing* (*social engineering* yang menipu pengguna), kata sandi lemah atau dipakai ulang, *software* yang belum di-*patch*, *insider threat* (karyawan yang lalai atau berniat jahat), dan konfigurasi akses yang salah.
>
> **Koreksi:** Keamanan adalah kombinasi tiga elemen: teknologi (*antivirus*, *firewall*, *encryption*) + proses (*patch management*, *access review*, *backup*) + manusia (*security awareness training*, kultur keamanan). Mengandalkan hanya satu elemen — teknologi — ibarat mengunci pintu depan tetapi membuka seluruh jendela.

⚠️ ***"Risiko SI hanya berupa serangan hacker dari luar"***

> Lebih dari 60% insiden keamanan melibatkan *insider*: karyawan yang ceroboh mengklik tautan *phishing*, *ex-employee* yang masih memiliki akses aktif, *contractor* yang berbagi kredensial, atau staf yang meng-*copy* data pelanggan ke *flash drive* pribadi (Whitman & Mattord, 2022). Ancaman dari dalam sering lebih berbahaya karena *insider* sudah memiliki akses yang sah.
>
> **Koreksi:** Terapkan *principle of least privilege*: setiap orang hanya mendapatkan akses minimum yang diperlukan untuk pekerjaannya. *Review* hak akses secara berkala (minimal per kuartal). *Revoke* akses segera saat karyawan pindah divisi, *resign*, atau kontraknya berakhir.

⚠️ ***"Compliance = keamanan"***

> *Compliance* memastikan organisasi memenuhi standar minimum regulasi — bukan bahwa organisasi aman. Equifax memiliki sertifikasi PCI-DSS pada saat *data breach* 2017 terjadi. *Compliant* — tetapi 148 juta data bocor. Standar minimum yang ditetapkan regulasi mungkin tidak cukup untuk menghadapi ancaman spesifik yang dihadapi organisasi tertentu.
>
> **Koreksi:** Perlakukan *compliance* sebagai *baseline* — bukan *ceiling*. Regulasi (UU PDP, ISO 27001) menetapkan lantai minimum keamanan. Di atas lantai itu, organisasi perlu menyesuaikan *security posture* dengan *threat landscape* spesifiknya: industri apa, data apa yang dimiliki, siapa yang mungkin menyerang dan mengapa.

---

## 15.8 Studi Kasus

### 📊 Studi Kasus Dasar — RS Dharmais: Dampak *Ransomware* pada Layanan Kesehatan Kritis

**❌ Kondisi Awal:**
SIMRS RS Kanker Dharmais terinfeksi WannaCry pada 13 Mei 2017. Seluruh terminal registrasi, farmasi, dan rekam medis terkunci. Tim IT tidak memiliki: (a) *backup* *offline* terkini, (b) *incident response plan* tertulis, (c) prosedur komunikasi krisis.

**✅ Analisis dari Perspektif *Governance*:**

### Tabel 15.3 — Evaluasi *Governance* Keamanan RS Dharmais

| Dimensi *Governance* | Kondisi Aktual | Seharusnya |
|----------------------|---------------|-----------|
| *Patch management* | Tidak teratur, tertunda ≥ 2 bulan | *Patch* kritis ≤ 7 hari setelah *release* |
| *Backup policy* | Bulanan (1 bulan data hilang) | Harian + salinan *offline* (aturan 3-2-1) |
| *Incident response plan* | Tidak ada | IRP tertulis, diuji 2×/tahun |
| *Business continuity* | Manual *paper-based* (kacau) | BCP tertulis: SOP mode manual 48 jam |
| *Security awareness* | Tidak ada pelatihan | Pelatihan kuartalan + simulasi *phishing* |

Aturan *backup* 3-2-1: 3 salinan data, di 2 media berbeda, 1 salinan di lokasi terpisah (*offline* atau *off-site*). Jika RS Dharmais menerapkan aturan ini, *ransomware* hanya mengganggu — bukan melumpuhkan. Data bisa dipulihkan dari *backup offline* dalam hitungan jam.

💡 **Pelajaran:** RS Dharmais memiliki SIMRS yang canggih — tetapi tanpa *governance* keamanan yang memadai. *Governance* yang baik bukan tentang investasi teknologi mahal — ia tentang disiplin dalam hal-hal yang tampak sederhana: *patch* tepat waktu, *backup* rutin, dan *incident response plan* yang pernah diuji. Tidak ada satu pun dari tindakan ini yang memerlukan investasi besar.

### 📊 Studi Kasus Lanjutan — Equifax: Kegagalan *Governance* di Setiap Level

**❌ Kondisi Awal (2017):**
Equifax menyimpan data kredit 800+ juta orang. Memiliki sertifikasi PCI-DSS. Tetapi: CISO berlatar belakang non-teknis (musik), *board* tidak memiliki komite keamanan IT, dan proses *vulnerability management* tidak efektif.

**✅ *Timeline* Kegagalan:**

### Tabel 15.4 — *Timeline* *Breach* Equifax dan Respons yang Seharusnya

| Tanggal | *Event* | Respons yang Seharusnya |
|---------|---------|------------------------|
| 8 Mar 2017 | *Vulnerability* Apache Struts dipublikasikan | *Patch* dalam 48 jam (kritis) |
| 10 Mar 2017 | US-CERT mengirim *advisory* | Tim keamanan memprioritaskan |
| 15 Mar 2017 | *Scan* Equifax gagal mendeteksi | *Review* manual untuk aset kritis |
| 13 Mei 2017 | *Attacker* mulai mengeksfiltrasi data | IDS seharusnya mendeteksi *traffic anomaly* |
| 29 Jul 2017 | *Breach* terdeteksi (77 hari kemudian) | Deteksi seharusnya ≤ 48 jam |
| 7 Sep 2017 | Pengungkapan publik | Notifikasi dalam 72 jam (standar regulasi) |

**Dampak:** *settlement* $700 juta, CEO/CIO/CISO *resign*, reputasi hancur, dan regulasi baru di AS dipicu oleh insiden ini.

💡 **Pelajaran:** Equifax gagal bukan di satu titik — ia gagal di setiap level *governance*. *Board* tanpa *oversight* IT tidak bisa mengevaluasi apakah risiko dikelola. CISO tanpa kompetensi keamanan tidak bisa memimpin pertahanan. *Vulnerability management* tanpa akuntabilitas membiarkan celah selama berbulan-bulan. Dan PCI-DSS *compliance* memberikan ilusi keamanan yang berbahaya. Pelajaran terbesarnya: *compliance checklist* tidak menggantikan *security culture* dan *governance* yang substantif.

---

## 15.9 Template Praktis

🔧 **Template A.15 — *Risk Register* SI**

```
TEMPLATE A.15 — RISK REGISTER SI

Tanggal         : ________________________________________
Organisasi/Unit : ________________________________________
Risk Owner      : ________________________________________

═══════════════════════════════════════════════════════════════

| No | Risiko       | Kategori    | Prob (1–5) | Dampak (1–5) | Skor | Pengendalian Saat Ini | Status   | Rekomendasi  |
|----|-------------|-------------|-----------|-------------|------|----------------------|----------|-------------|
| 1  | ___________ | [T/O/K/S/R] | ___       | ___         | ___  | ____________________ | [✅/⚠️/❌] | ___________ |
| 2  | ___________ | [T/O/K/S/R] | ___       | ___         | ___  | ____________________ | [✅/⚠️/❌] | ___________ |
| 3  | ___________ | [T/O/K/S/R] | ___       | ___         | ___  | ____________________ | [✅/⚠️/❌] | ___________ |
| 4  | ___________ | [T/O/K/S/R] | ___       | ___         | ___  | ____________________ | [✅/⚠️/❌] | ___________ |
| 5  | ___________ | [T/O/K/S/R] | ___       | ___         | ___  | ____________________ | [✅/⚠️/❌] | ___________ |

Keterangan Kategori:
  T = Teknis | O = Operasional | K = Keamanan | S = Strategis | R = Reputasional

Status Pengendalian:
  ✅ Memadai | ⚠️ Partial | ❌ Tidak ada

═══════════════════════════════════════════════════════════════

PENILAIAN RISIKO (Prob × Dampak):
  Skor 20–25 : KRITIS — mitigasi segera, eskalasi ke board
  Skor 12–19 : TINGGI — action plan dalam 30 hari
  Skor 6–11  : MENENGAH — monitoring rutin
  Skor 1–5   : RENDAH — accepted dengan awareness

TOP 3 PRIORITAS MITIGASI:
  1. ________________________________________________________
  2. ________________________________________________________
  3. ________________________________________________________

CATATAN:
________________________________________________________
________________________________________________________
```

---

## 15.10 Peta Konsep

### Gambar 15.2 — Peta Konsep Risiko, Keamanan & Tata Kelola SI

```mermaid
mindmap
  root((Risiko, Keamanan &<br>Tata Kelola SI))
    Tipologi Risiko
      Teknis — server, bug
      Operasional — human error
      Keamanan — breach, ransomware
      Strategis — misalignment
      Reputasional — trust hancur
    Model CIA
      Confidentiality
      Integrity
      Availability
    Governance Framework
      COBIT 2019 — EDM
      ISO 27001 — ISMS
      NIST CSF — 6 fungsi
    Compliance
      UU PDP Indonesia
      GDPR Eropa
      Baseline bukan ceiling
    Peran Board
      Risk appetite
      IT oversight
      Expertise gap Indonesia
```

---

## 15.11 Rangkuman

**Poin-poin Penting:**

1. Risiko SI bukan hanya soal serangan *hacker* — ia mencakup risiko teknis, operasional, keamanan, strategis, dan reputasional. Masing-masing memerlukan penanggung jawab yang berbeda, dan mayoritas memerlukan respons manajerial, bukan respons teknis.

2. Model CIA (*Confidentiality, Integrity, Availability*) memberikan bahasa bisnis untuk mengartikulasikan kebutuhan keamanan. Setiap keputusan keamanan SI bisa dievaluasi melalui lensa: apakah tindakan ini meningkatkan C, I, atau A — dan apa *trade-off*-nya?

3. IT *governance* ≠ IT *management*. *Governance* menentukan arah dan melakukan *oversight* (tanggung jawab *board*). *Management* mengeksekusi (tanggung jawab tim IT). Organisasi membutuhkan keduanya — dan pemisahan yang jelas antara keduanya.

4. Delapan puluh persen *breach* bisa dicegah dengan *basic hygiene*: *patch management*, *strong password*, *backup* rutin (aturan 3-2-1), dan *access control* yang ketat. Investasi keamanan yang paling efektif sering kali yang paling murah.

5. *Compliance* (UU PDP, ISO 27001) adalah *baseline* — bukan *ceiling*. Equifax membuktikan bahwa organisasi bisa *compliant* (PCI-DSS) tetapi tetap mengalami *breach* yang mengorbankan 148 juta orang.

6. *Shadow IT* adalah sinyal bahwa SI resmi tidak memenuhi kebutuhan pengguna. Respons yang efektif: dengarkan, perbaiki, sediakan alternatif terotorisasi — bukan sekadar melarang.

7. *Board* dan *C-suite* harus memiliki kapasitas *oversight* SI. Di Indonesia, kurang dari 20% *board* memiliki anggota dengan keahlian IT — ini *blind spot* yang harus diperbaiki.

---

**Menuju Bab 16:**

Bagian VI — Implementasi, Evaluasi & Risiko — selesai. SI sudah diimplementasikan (Bab 13), nilai bisnisnya sudah dievaluasi (Bab 14), dan risiko serta tata kelolanya sudah dibangun (Bab 15). Fondasi operasional lengkap. Tetapi dunia tidak berhenti di "SI yang aman dan well-governed." Bab 16 membuka Bagian VII — Transformasi Digital, AI & Masa Depan — dengan pertanyaan yang lebih besar: bagaimana organisasi tidak hanya "menggunakan SI," tetapi "bertransformasi melalui digital" — mengubah model bisnis, *customer experience*, dan cara kerja secara mendasar?

---

🔥 *"Tata kelola sistem informasi bukan tentang mencegah semua risiko — yang mustahil — melainkan tentang memastikan organisasi tahu risiko apa yang mereka ambil dan mengapa."*

---

## 15.12 Latihan & Refleksi

### Pertanyaan Diagnostik

Organisasi ingin mempercepat digitalisasi melalui pembukaan akses data lintas unit serta penggunaan layanan *cloud* dan AI pihak ketiga. Analisis *trade-off* antara kecepatan inovasi, keamanan, privasi, *compliance*, dan *governance*, termasuk prioritas risiko, kontrol yang relevan, dan pembagian akuntabilitas pada keputusan kritis.

### Pertanyaan Reflektif

1. Identifikasi tiga risiko SI teratas di organisasi yang Anda kenal. Apakah risiko-risiko tersebut dikelola secara formal — atau hanya "ditangani kalau terjadi"?

2. Jika data pelanggan di organisasi Anda bocor besok pagi, apakah ada *incident response plan* yang bisa diaktifkan? Siapa yang akan bertanggung jawab membuat keputusan? Apakah notifikasi kepada pemilik data bisa dilakukan dalam 72 jam sesuai UU PDP?

3. Berikan contoh *shadow IT* di organisasi yang Anda kenal. Mengapa karyawan menggunakannya — dan apa risiko spesifik yang ditimbulkan?

4. Apakah UU PDP Indonesia akan benar-benar ditegakkan secara konsisten, atau menjadi regulasi yang hanya ada di atas kertas? Terlepas dari jawaban Anda — apa strategi paling aman bagi organisasi?

### Latihan Artefak

**Latihan 15.1 — *Risk Register* SI (Template A.15)**

Gunakan Template A.15 untuk mengidentifikasi dan menilai 5 risiko SI di sebuah organisasi atau unit kerja yang Anda kenal.

Langkah:
1. Identifikasi 5 risiko dari minimal 3 kategori berbeda (Teknis, Operasional, Keamanan, Strategis, Reputasional)
2. Berikan skor Probabilitas (1–5) dan Dampak (1–5) untuk setiap risiko — disertai basis estimasi
3. Evaluasi pengendalian yang saat ini ada (✅ Memadai / ⚠️ Partial / ❌ Tidak ada)
4. Rumuskan rekomendasi mitigasi untuk 3 risiko dengan skor tertinggi

**Kriteria *output* yang baik:**
- Risiko bersifat spesifik dan kontekstual — bukan generik ("server down" terlalu umum; "*database* pasien RS X tidak di-*backup* harian" spesifik)
- Skor probabilitas dan dampak memiliki justifikasi — bukan angka acak
- Rekomendasi mitigasi bersifat *actionable* — menyebutkan tindakan, penanggung jawab, dan *timeline*
- Minimal mencakup 1 risiko non-teknis (strategis atau reputasional)

*Template A.15 menutup Bagian VI. Bab 16 memulai Bagian VII — di mana SI bukan lagi alat operasional, tetapi motor transformasi organisasi.*

---

## Referensi

ISACA. (2024). *COBIT 2019 framework* (Updated ed.). ISACA.

ISO/IEC 27001:2022. *Information security management systems — Requirements*. ISO.

Laudon, K. C., & Laudon, J. P. (2022). *Management information systems* (17th ed.). Pearson.

NIST. (2024). *Cybersecurity framework 2.0*. U.S. Department of Commerce.

Rahardjo, E., & Susanto, A. (2022). Analisis tata kelola data dalam era transformasi digital di Indonesia. *Jurnal Ilmu Administrasi*, *19*(2), 112–130.

Schinagl, S., & Shahim, A. (2022). What do we know about information security governance? *Information Security Journal*, *31*(2), 162–191.

Spencer Stuart. (2024). *Board index 2024: IT expertise on corporate boards*. Spencer Stuart.

UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi. Republik Indonesia.

Whitman, M. E., & Mattord, H. J. (2022). *Principles of information security* (7th ed.). Cengage Learning.
