MODUL HUKUM DAN KEBIJAKAN TEKNOLOGI INFORMASI

Mata Kuliah: Hukum dan Kebijakan Teknologi Informasi
Kode MK: INF2505
SKS: 2 (Teori)
Semester: 2
Program Studi: Informatika
Fakultas: Ekonomi dan Bisnis Islam
Universitas: UIN K.H. Abdurrahman Wahid Pekalongan

Dosen Pengampu: Mohammad Reza Maulana, M.Kom
NIP: 199110082025051002

Pertemuan: 7 dari 16
Durasi: 100 menit (2 × 50 menit)

Panduan Penggunaan Modul

Modul ini mencakup Pertemuan 7 (Privasi Digital & Studi Kasus Kebocoran Data), yang merupakan pertemuan terakhir sebelum UTS. Di sini, "teks hukum" UU PDP yang dipelajari di Pertemuan 6 bertemu dengan realita — bagaimana kebocoran data terjadi, siapa yang bertanggung jawab, dan bagaimana pengembang sistem seharusnya mendesain produk sejak awal agar pelanggaran tidak pernah terjadi.

Catatan Penting:

• Deadline Tugas 3 (Analisis Kasus UU ITE) adalah hari ini — pastikan sudah dikumpulkan di awal pertemuan.
• Tugas 4 (Audit PDP) diumumkan resmi pada pertemuan ini.
• Pertemuan ini adalah pertemuan terakhir sebelum UTS — seluruh materi P1–P7 akan diujikan pada Pertemuan 8.

PERTEMUAN 7

Privasi Digital & Studi Kasus Kebocoran Data

Sub-CPMK: Sub-CPMK02.1.2
Bobot: 7% dari Nilai Akhir
→ PENGUMPULAN TUGAS 3 | PENGUMUMAN TUGAS 4

JEMBATAN DARI PERTEMUAN 6

PERTEMUAN 6                              PERTEMUAN 7
"Inilah teks hukum UU PDP:              "Inilah realitasnya —
9 hak subjek data,                       ketika UU PDP diabaikan
7 prinsip pemrosesan,                    atau belum ada, apa yang
kewajiban pengendali data,               terjadi kepada jutaan
dan ancaman sanksinya"                   warga Indonesia?"

     ↓                                         ↓
Setelah memahami "apa yang seharusnya", kini kita tanya:
"Apa yang SEBENARNYA terjadi? Bagaimana pengembang
sistem SEHARUSNYA membangun sistem sejak awal agar
pelanggaran tidak pernah terjadi?"

Pertanyaan jembatan dari P6: Di Pertemuan 6, kita belajar bahwa pengendali data wajib memberikan notifikasi pelanggaran dalam 14 hari kerja, wajib melakukan DPIA untuk data berisiko tinggi, dan wajib menerapkan prinsip data minimization. Pertemuan 7 akan memperlihatkan betapa banyak organisasi Indonesia yang gagal memenuhi kewajiban-kewajiban dasar ini — bahkan lembaga negara sekalipun. Mengapa ini bisa terjadi? Dan sebagai calon pengembang sistem, apa yang bisa Anda lakukan agar tidak menjadi pelakunya?

CAPAIAN PEMBELAJARAN

Sub-CPMK yang Dituju

Indikator Ketercapaian

Setelah pertemuan ini, mahasiswa mampu:

1. Menjelaskan landasan konstitusional hak privasi di Indonesia (C2).
2. Mendeskripsikan 7 prinsip privacy by design dan mengaitkannya dengan kewajiban UU PDP (C2).
3. Menganalisis kasus kebocoran data nyata menggunakan kerangka hukum UU PDP — mengidentifikasi kewajiban yang dilanggar, pihak yang bertanggung jawab, dan sanksi yang seharusnya dijatuhkan (C4).
4. Mengevaluasi mekanisme notifikasi pelanggaran data dan implikasi hukumnya bagi pengendali data (C5).
5. Merancang rekomendasi kepatuhan data bagi sebuah aplikasi/platform berdasarkan celah yang teridentifikasi (C6 — sesuai Tugas 4).

BAGIAN 7.1 — HAK PRIVASI DALAM HUKUM INDONESIA

7.1.1 Privasi sebagai Hak Konstitusional

Sebelum masuk ke UU PDP atau kasus kebocoran data, penting untuk memahami mengapa privasi itu penting secara hukum — bukan hanya sebagai kebijakan kenyamanan, melainkan sebagai hak asasi manusia yang dilindungi konstitusi.

HIERARKI PERLINDUNGAN PRIVASI DI INDONESIA

UUD 1945 (Tertinggi)
│
├── Pasal 28G ayat (1): Setiap orang berhak atas
│   perlindungan diri pribadi, keluarga, kehormatan,
│   martabat, dan harta benda.
│
├── Pasal 28H ayat (4): Hak milik pribadi tidak boleh
│   diambil alih sewenang-wenang oleh siapa pun.
│
└── Pasal 28F: Hak untuk berkomunikasi dan memperoleh
    informasi — hak ini juga mencakup dimensi
    kerahasiaan komunikasi.

         ↓ Diimplementasikan melalui

UU PDP No. 27/2022 — Implementasi legislatif
         ↓

UU ITE No. 1/2024 (Pasal 26) — Hak atas privasi informasi
         ↓

PP PSTE No. 71/2019 — Kewajiban teknis PSE

Implikasi konstitusional yang krusial: Karena privasi adalah hak konstitusional, pembatasan terhadap hak ini hanya boleh dilakukan melalui undang-undang dan harus memenuhi syarat proporsionalitas. Tidak ada instansi atau perusahaan yang boleh membatasi atau melanggar privasi seseorang berdasarkan kebijakan internal semata.

7.1.2 Mengapa Privasi Rentan di Era Digital?

Sebelum era digital, melanggar privasi seseorang membutuhkan upaya fisik yang signifikan — membuka surat, mengikuti orang, menyusup ke rumah. Di era digital, skala dan kemudahan pelanggaran berubah drastis:

ERA ANALOG                    ERA DIGITAL
Privasi dilanggar:            Privasi dilanggar:
• Satu per satu               • Jutaan sekaligus
• Perlu kehadiran fisik       • Dari jarak jauh
• Meninggalkan jejak          • Sering tanpa jejak
• Biaya tinggi                • Biaya sangat rendah
• Sulit disembunyikan         • Mudah disamarkan

Tiga faktor yang membuat privasi digital sangat rentan:

Faktor 1 — Jejak Data yang Tak Terlihat (Invisible Data Trail): Setiap aktivitas digital meninggalkan jejak: klik, lokasi GPS, waktu akses, perangkat yang digunakan, pola penelusuran. Pengguna sering tidak menyadari seberapa banyak data tentang dirinya yang tersimpan oleh berbagai layanan.

Faktor 2 — Agregasi Data (Data Aggregation): Sebuah data tunggal mungkin tampak tidak berbahaya — nama lengkap, atau nomor telepon saja. Namun, ketika puluhan data berbeda tentang satu orang digabungkan, hasilnya adalah profil yang jauh lebih sensitif daripada jumlah bagian-bagiannya. Inilah yang disebut mosaic effect atau aggregation problem.

Ilustrasi Mosaic Effect: Data tunggal: nama, alamat rumah, nomor HP, nama majikan, jadwal kerja, nomor kendaraan. Semua data ini mungkin tersedia publik secara terpisah. Namun bila digabung, hasilnya adalah informasi yang cukup untuk seseorang melacak, mengikuti, atau mengancam target — sebuah risiko nyata bagi jurnalis, aktivis, atau korban kekerasan dalam rumah tangga.

Faktor 3 — Ketidakseimbangan Kuasa (Power Asymmetry): Perusahaan teknologi tahu sangat banyak tentang penggunanya, sedangkan pengguna tahu sangat sedikit tentang apa yang dilakukan perusahaan dengan data mereka. Terms of Service yang panjang dan sulit dipahami memperparah ketidakseimbangan ini.

7.1.3 Pasal 26 UU ITE: Hak Privasi dalam Informasi Elektronik

Sebelum UU PDP lahir, Pasal 26 UU ITE adalah satu-satunya payung hukum perlindungan privasi informasi digital di Indonesia:

"Kecuali ditentukan lain oleh peraturan perundang-undangan, penggunaan setiap informasi melalui media elektronik yang menyangkut data pribadi seseorang harus dilakukan atas persetujuan orang yang bersangkutan." — Pasal 26 ayat (1) UU ITE

Keterbatasan Pasal 26 UU ITE:

• Tidak mendefinisikan apa itu "data pribadi".
• Tidak mengatur hak-hak spesifik subjek data (hak akses, koreksi, hapus).
• Tidak ada kewajiban notifikasi pelanggaran.
• Sanksi tidak proporsional dengan skala pelanggaran.

Itulah mengapa UU PDP dibutuhkan — dan mengapa pemahaman P6 tentang UU PDP menjadi fondasi penting untuk menganalisis kasus-kasus di bagian selanjutnya.

BAGIAN 7.2 — PRIVACY BY DESIGN: MEMBANGUN PRIVASI KE DALAM SISTEM

7.2.1 Latar Belakang dan Asal-Usul

Privacy by Design (PbD) adalah pendekatan yang dikembangkan oleh Dr. Ann Cavoukian, mantan Komisioner Informasi dan Privasi Ontario, Kanada, pada tahun 1990-an. Pendekatan ini kemudian diadopsi secara global dan menjadi persyaratan wajib dalam GDPR (Article 25). UU PDP Indonesia, yang terinspirasi GDPR, mengangkat semangat yang sama melalui prinsip pertanggungjawaban dan kewajiban DPIA.

Inti dari PbD adalah satu kalimat sederhana:

"Privasi bukan fitur tambahan — privasi adalah arsitektur."

Artinya, perlindungan privasi tidak bisa "ditambahkan belakangan" setelah sistem dibangun. Privasi harus menjadi bagian integral dari desain sistem sejak hari pertama.

7.2.2 Tujuh Prinsip Privacy by Design

Prinsip 1: Proaktif, Bukan Reaktif — Mencegah, Bukan Memperbaiki

❌ PENDEKATAN REAKTIF (SALAH):
"Kami akan tangani masalah privasi jika ada keluhan atau insiden."

✓ PENDEKATAN PROAKTIF (BENAR):
"Kami mengidentifikasi dan mengeliminasi risiko privasi SEBELUM
sistem diluncurkan."

Dalam praktik pengembangan sistem: Lakukan Privacy Impact Assessment (PIA) / Data Protection Impact Assessment (DPIA) di fase perencanaan, bukan setelah deployment. UU PDP mewajibkan DPIA untuk pemrosesan data berisiko tinggi — mengabaikan ini bukan hanya praktik buruk, melainkan pelanggaran hukum.

Kegagalan prinsip ini dalam kasus nyata: PDN 2024 tidak memiliki backup data yang memadai — sebuah keputusan desain infrastruktur yang harusnya disadari risikonya jauh sebelum serangan ransomware terjadi.

Prinsip 2: Privasi sebagai Pengaturan Default (Privacy as Default)

Jika pengguna tidak melakukan tindakan apa pun, pengaturan privasi yang paling ketat harus yang berlaku secara otomatis.

Contoh penerapan yang benar:

• Formulir pendaftaran: kotak persetujuan berbagi data dengan mitra bisnis harus kosong secara default — bukan sudah dicentang.
• Fitur berbagi lokasi: harus dinonaktifkan secara default, baru aktif jika pengguna memilihnya secara eksplisit.
• Postingan media sosial: harus privat secara default, bukan publik.

Mengapa ini penting secara hukum? UU PDP Pasal 20 mensyaratkan persetujuan yang "diberikan secara eksplisit" (explicit consent). Pre-ticked boxes yang sudah dicentang sejak awal tidak memenuhi syarat persetujuan eksplisit ini.

Prinsip 3: Privasi Tertanam dalam Desain (Privacy Embedded into Design)

Privasi bukan add-on — ia adalah komponen inti arsitektur sistem:

SISTEM YANG SALAH                 SISTEM YANG BENAR
┌─────────────────────┐           ┌─────────────────────┐
│  CORE SYSTEM        │           │  CORE SYSTEM        │
│  (fungsional)       │           │  ┌───────────────┐  │
│                     │  +        │  │ PRIVASI       │  │
│                     │  🔒       │  │ (terintegrasi)│  │
│  [Privasi ditambah  │  (patch)  │  └───────────────┘  │
│   sebagai patch     │           │  (built-in)         │
│   setelah jadi)     │           │                     │
└─────────────────────┘           └─────────────────────┘

Implikasi bagi pengembang: Enkripsi data bukan tambahan opsional — ia adalah standar. Kontrol akses berbasis peran (RBAC) bukan nice to have — ia adalah persyaratan desain.

Prinsip 4: Fungsionalitas Penuh — Tidak Zero-Sum

Privasi yang baik tidak mengorbankan fungsionalitas, dan fungsionalitas yang baik tidak mengorbankan privasi.

Argumen "kami harus mengumpulkan semua data ini agar fitur bekerja dengan baik" sering digunakan untuk membenarkan pengumpulan data berlebihan. PbD menolak argumen ini:

Prinsip 5: Keamanan End-to-End — Perlindungan Sepanjang Siklus Hidup

Data harus dilindungi dari saat dikumpulkan hingga saat dihapus — bukan hanya saat disimpan atau dikirim:

SIKLUS HIDUP DATA & PERLINDUNGAN YANG DIPERLUKAN

[PENGUMPULAN]                 → Persetujuan eksplisit, form aman (HTTPS)
        ↓
[PENYIMPANAN]                 → Enkripsi at-rest, backup terenkripsi
        ↓
[PEMROSESAN/PENGGUNAAN]       → Akses berbasis peran (RBAC), audit log
        ↓
[BERBAGI/TRANSFER]            → Enkripsi in-transit (TLS), DPA dengan pihak ketiga
        ↓
[RETENSI]                     → Kebijakan retensi: hapus otomatis setelah batas waktu
        ↓
[PENGHAPUSAN]                 → Penghapusan aman (secure deletion), bukan sekadar
                                 "hapus dari database" yang masih bisa dipulihkan

Relevansi dengan UU PDP: Pasal 35 UU PDP mewajibkan pengendali data "menggunakan langkah-langkah keamanan yang sesuai" sepanjang siklus pemrosesan data.

Prinsip 6: Visibilitas & Transparansi

Pengguna berhak mengetahui dengan tepat apa yang Anda kumpulkan, mengapa, dan apa yang Anda lakukan dengannya.

Transparansi ini bukan sekadar "ada kebijakan privasi di website". Kebijakan privasi yang baik harus:

• Ditulis dalam bahasa yang dapat dipahami oleh pengguna awam (bukan legalese semata).
• Mudah diakses — tidak tersembunyi di balik 7 klik menu.
• Spesifik — bukan pernyataan umum seperti "kami dapat menggunakan data Anda untuk meningkatkan layanan" tanpa penjelasan lebih lanjut.
• Diperbarui setiap kali ada perubahan, dengan notifikasi kepada pengguna.

Kaitan dengan UU PDP: Pasal 30–32 UU PDP secara eksplisit mewajibkan pengendali data untuk memberikan informasi yang komprehensif dalam privasi notice sebelum atau pada saat pengumpulan data.

Prinsip 7: Menghormati Privasi Pengguna — User-Centric

Sistem harus dirancang untuk melayani kepentingan pengguna, bukan mengeksploitasinya.

Prinsip ini berhadapan langsung dengan praktik dark pattern yang dibahas di Pertemuan 5 — desain antarmuka yang sengaja dibuat untuk memanipulasi pengguna agar membagikan lebih banyak data daripada yang mereka inginkan.

7.2.3 PbD dalam Konteks UU PDP Indonesia

Meski UU PDP tidak menyebut "Privacy by Design" secara eksplisit, semangat PbD tersebar di seluruh pasal-pasal UU PDP:

7.2.4 Privacy Impact Assessment (PIA / DPIA) — Kewajiban Hukum

DPIA (Data Protection Impact Assessment) adalah proses sistematis untuk mengidentifikasi dan memitigasi risiko privasi sebelum pemrosesan data dimulai. UU PDP Pasal 34 mewajibkan DPIA untuk pemrosesan data yang:

• Menggunakan teknologi baru.
• Berpotensi menimbulkan risiko tinggi terhadap hak subjek data.
• Melibatkan data pribadi spesifik (data biometrik, kesehatan, orientasi seksual, dll.).
• Dilakukan dalam skala besar.

Komponen minimal sebuah DPIA:

DPIA TEMPLATE (Minimal)

1. DESKRIPSI PEMROSESAN
   - Tujuan pemrosesan
   - Jenis data yang terlibat
   - Siapa yang memiliki akses

2. PENILAIAN KEBUTUHAN & PROPORSIONALITAS
   - Apakah pemrosesan ini benar-benar diperlukan?
   - Apakah ada cara yang lebih privasi-preserving?

3. IDENTIFIKASI RISIKO
   - Risiko terhadap hak dan kebebasan subjek data
   - Kemungkinan dan keparahan setiap risiko

4. LANGKAH MITIGASI
   - Kontrol teknis (enkripsi, pseudonimisasi)
   - Kontrol organisasi (pelatihan, akses terbatas)
   - Residual risk setelah mitigasi

5. KONSULTASI (jika residual risk masih tinggi)
   - Konsultasi dengan DPO
   - Konsultasi dengan otoritas (jika diperlukan)

BAGIAN 7.3 — STUDI KASUS KEBOCORAN DATA DI INDONESIA

Cara membaca studi kasus ini: Gunakan framework 3 pertanyaan untuk setiap kasus:

1. Apa yang terjadi? (faktual)
2. Kewajiban apa yang dilanggar? (analisis hukum berdasarkan UU PDP dan UU ITE)
3. Bagaimana seharusnya? (rekomendasi berbasis PbD)

KASUS 1: Kebocoran Data BPJS Kesehatan (2021)

Kronologi Kejadian

Pada Mei 2021, seorang pengguna forum darkweb Raid Forum dengan nama Kotz menawarkan 279 juta data peserta BPJS Kesehatan — termasuk data almarhum — dengan harga 0,15 Bitcoin (sekitar Rp84 juta saat itu).

TIMELINE KEBOCORAN DATA BPJS 2021

Mei 2021
│
├── 12 Mei: Data ditawarkan di forum Raid Forum
│           279 juta record — nama, NIK, tanggal lahir,
│           alamat, nomor HP, data gaji
│
├── 20 Mei: Kominfo memblokir akun penjual dan tautan
│           ke file sample yang beredar
│
├── 21 Mei: BPJS Kesehatan merilis pernyataan awal —
│           "mendalami dugaan kebocoran data"
│           (tidak mengakui, tidak membantah sepenuhnya)
│
└── Mei–Juni: Investigasi oleh BSSN dan pihak ketiga
              Hasil tidak pernah diumumkan secara resmi

Data yang diduga bocor:

• Nomor Induk Kependudukan (NIK)
• Nama lengkap
• Tanggal lahir
• Alamat lengkap
• Nomor telepon
• Data gaji/penghasilan
• Jenis kelamin
• Data peserta meninggal

Analisis Hukum

Konteks penting: Kebocoran ini terjadi sebelum UU PDP disahkan (Oktober 2022). Saat kejadian, tidak ada regulasi komprehensif yang mengatur kewajiban notifikasi, DPIA, atau tanggung jawab hukum yang jelas bagi pengendali data.

Dasar hukum yang tersedia saat itu:

Analisis menggunakan framework UU PDP (jika berlaku):

Seandainya UU PDP sudah berlaku penuh saat insiden ini terjadi, kewajiban BPJS Kesehatan sebagai pengendali data meliputi:

KEWAJIBAN BPJS KESEHATAN BERDASARKAN UU PDP
(Simulasi — UU PDP belum berlaku saat kejadian)

1. KEWAJIBAN NOTIFIKASI (Pasal 46)
   → Memberitahu Kominfo DALAM 14 HARI KERJA sejak insiden diketahui
   → Memberitahu subjek data yang terdampak
   → Faktanya: BPJS tidak melaporkan secara proaktif; terungkap dari laporan
     pihak ketiga

2. KEWAJIBAN DPIA (Pasal 34)
   → Data 279 juta orang dengan kategori data pribadi umum dan spesifik
     JELAS masuk kategori "pemrosesan berisiko tinggi"
   → DPIA seharusnya sudah dilakukan jauh sebelumnya
   → Tidak ada informasi publik bahwa DPIA pernah dilakukan

3. KEWAJIBAN KEAMANAN (Pasal 35)
   → Enkripsi data sensitif di database
   → Pembatasan akses internal (RBAC)
   → Penetration testing berkala
   → Pertanyaan: apakah 279 juta record bisa keluar tanpa insider threat
     atau kelemahan akses yang signifikan?

4. KEWAJIBAN DATA MINIMIZATION (Pasal 16b)
   → Pertanyaan: apakah BPJS benar-benar memerlukan data gaji dalam database
     yang sama dan dengan tingkat aksesibilitas yang sama?

Siapa yang bertanggung jawab?

Dalam kerangka UU PDP: BPJS Kesehatan sebagai pengendali data (data controller) bertanggung jawab utama. Hal ini tidak berubah meskipun kebocoran disebabkan oleh serangan eksternal — pengendali data tetap bertanggung jawab atas kegagalan menjaga keamanan sistem.

Sanksi potensial jika UU PDP berlaku penuh:

• Sanksi administratif: teguran tertulis + denda hingga 2% dari pendapatan tahunan.
• Jika terbukti ada kelalaian dalam implementasi keamanan yang disengaja: sanksi pidana.

Pelajaran Bagi Pengembang

LESSON LEARNED — KASUS BPJS 2021

✓ Enkripsi seluruh data pribadi di database — terutama NIK, nomor HP,
  data keuangan (data at-rest encryption).

✓ Implementasi prinsip "least privilege" — tidak semua admin perlu akses
  ke seluruh 279 juta record sekaligus.

✓ Monitoring anomali akses — penarikan data dalam jumlah besar seharusnya
  memicu alert otomatis.

✓ Pisahkan data berdasarkan sensitivitas — jangan simpan NIK, nomor HP,
  dan data gaji dalam tabel yang sama dan dengan akses yang sama.

✓ Siapkan incident response plan — respons yang lambat dan tidak transparan
  memperparah dampak reputasi.

KASUS 2: Kebocoran Data MyPertamina (2022)

Kronologi Kejadian

Pada September 2022, seorang peretas dengan nama Bjorka — yang juga mengklaim bertanggung jawab atas beberapa kebocoran data Indonesia lainnya — menawarkan 44,2 juta data konsumen Pertamina di forum BreachForums.

DATA YANG BOCOR:
- Alamat email
- Nomor telepon
- Poin reward MyPertamina
- Riwayat transaksi BBM
- Jenis dan plat nomor kendaraan
- Tanggal lahir

Yang membedakan kasus ini dari BPJS:

Kebocoran MyPertamina diduga terjadi bukan karena serangan siber yang canggih, melainkan karena kerentanan teknis pada API atau sistem internal yang seharusnya bisa dicegah dengan praktik keamanan yang standar. Ini menjadikannya kasus pelanggaran kewajiban keamanan yang lebih jelas.

Analisis Hukum

Konteks hukum: Kebocoran ini terjadi setelah UU PDP disahkan (Oktober 2022) namun dalam masa transisi. UU PDP memberi waktu 2 tahun sejak pengesahan untuk kepatuhan penuh (Oktober 2024).

Pasal UU ITE yang relevan:

Analisis menggunakan UU PDP (masa transisi):

Meskipun dalam masa transisi, Pertamina sebagai penyelenggara infrastruktur vital memiliki kewajiban keamanan yang lebih tinggi dari entitas biasa:

KEWAJIBAN YANG DIDUGA DILANGGAR

Kewajiban Keamanan Teknis:
→ Jika kebocoran terjadi karena kerentanan API yang dapat dicegah,
  ini menunjukkan kegagalan dalam keamanan siklus pengembangan
  (Secure Development Lifecycle / SDLC)
→ Pelanggaran: Pasal 35 UU PDP (kewajiban keamanan pemrosesan)
  dan Pasal 14 PP PSTE 71/2019

Kewajiban Notifikasi:
→ Apakah Pertamina memberitahu 44,2 juta pengguna?
→ Tidak ada pernyataan resmi notifikasi publik yang dapat dikonfirmasi
→ Ini merupakan kegagalan kewajiban notifikasi (Pasal 46 UU PDP)

Kewajiban Transparansi:
→ Pernyataan Pertamina terkait insiden ini minimal dan defensif —
  tidak memenuhi standar transparansi yang diharapkan

Pertanyaan analitis untuk mahasiswa: Jika saat ini Anda adalah DPO (Data Protection Officer) Pertamina, langkah apa yang seharusnya Anda ambil dalam 14 hari pertama setelah mengetahui insiden ini?

Pelajaran Bagi Pengembang

LESSON LEARNED — KASUS MyPertamina 2022

✓ API Security Testing — setiap endpoint API yang mengakses data pengguna
  harus melalui pengujian keamanan (rate limiting, autentikasi yang kuat,
  authorization check di setiap layer).

✓ Pseudonimisasi — data seperti plat nomor dan riwayat transaksi tidak perlu
  disimpan bersama data identitas penuh dalam database yang sama.

✓ Breach Response Plan — organisasi harus memiliki prosedur respons insiden
  yang sudah diuji sebelum insiden terjadi, bukan disusun ketika panik.

✓ Vendor/Third-Party Assessment — jika MyPertamina menggunakan vendor
  atau kontraktor sistem, kewajiban keamanan harus dikontrakkan secara eksplisit.

KASUS 3: Serangan Ransomware pada PDN (Pusat Data Nasional) — 2024

Kronologi Kejadian

Ini adalah kasus paling signifikan dalam sejarah keamanan siber Indonesia — sebuah serangan yang melumpuhkan infrastruktur data pemerintah pusat dan daerah.

TIMELINE SERANGAN PDN 2024

20 Juni 2024 (Kamis dini hari)
│  → Serangan ransomware mulai
│  → Malware: Brain Cipher (varian baru LockBit 3.0)
│
20–24 Juni 2024
│  → Layanan imigrasi, paspor, dan banyak layanan
│    pemerintah lainnya terganggu atau lumpuh total
│  → 282 instansi pusat & daerah terdampak
│  → Pelaku meminta tebusan US$8 juta (~Rp131 miliar)
│
25 Juni 2024
│  → BSSN dan Kominfo mengkonfirmasi serangan
│  → Pemerintah menyatakan tidak akan membayar tebusan
│
Juli 2024
│  → Brain Cipher secara tiba-tiba merilis kunci dekripsi
│    secara gratis — motif tidak jelas
│
Temuan Pasca-Insiden:
   → Dari 1.649 database di PDN, hanya 2% yang memiliki backup
   → Tidak ada disaster recovery plan yang memadai
   → Data 210 juta+ NIK diduga terdampak

Mengapa Kasus Ini Sangat Serius

1. Skala yang Belum Pernah Terjadi: 282 instansi pemerintah terdampak sekaligus. Layanan publik yang terganggu termasuk:

• Layanan imigrasi (paspor, visa) — lumpuh berminggu-minggu.
• Layanan beasiswa pemerintah.
• Sistem pendaftaran mahasiswa baru di beberapa PTN.
• Layanan administrasi daerah.

2. Kegagalan Backup yang Fundamental: Dari seluruh database yang disimpan di PDN, hanya 2% yang memiliki backup. Ini adalah kegagalan basic hygiene keamanan data yang seharusnya tidak pernah terjadi pada infrastruktur nasional. Ini bukan kegagalan teknis — ini kegagalan tata kelola (governance failure).

PERBANDINGAN: STANDAR BACKUP vs REALITA PDN

Standar internasional (3-2-1 Rule):
3 salinan data
2 media penyimpanan berbeda
1 di lokasi berbeda (offsite/cloud)

Realita PDN 2024:
Hanya 2% database yang punya backup
Tidak ada offsite backup yang memadai
Tidak ada disaster recovery plan yang diuji

3. Menyerang Infrastruktur Kritis Pemerintah: PDN bukan sembarang sistem — ini adalah infrastruktur kritis yang menyimpan data warga negara dalam skala masif. Serangan terhadapnya menyentuh kepentingan publik dan kedaulatan data nasional.

Analisis Hukum

Dari sisi pelaku serangan (Brain Cipher):

Dari sisi pengelola PDN (pemerintah/Kominfo):

Pertanyaan yang jauh lebih penting dan kritis: Apakah pemerintah juga melanggar kewajibannya sebagai pengendali data?

ANALISIS KEWAJIBAN PEMERINTAH SEBAGAI PENGENDALI DATA

Kewajiban Keamanan (Pasal 35 UU PDP):
→ "menggunakan langkah-langkah keamanan yang sesuai"
→ Tidak memiliki backup untuk 98% data = kegagalan keamanan yang
  tidak dapat dibenarkan

Kewajiban sebagai PSE (Pasal 14 PP PSTE 71/2019):
→ PSE wajib "menjamin keamanan, keandalan, serta kemudahan
  dan kelancaran sistem elektronik"
→ Keandalan minimal mencakup availability dan disaster recovery

Kewajiban Notifikasi (Pasal 46 UU PDP):
→ Apakah pemerintah memberitahu 210 juta warga yang datanya
  terdampak? Tidak ada mekanisme notifikasi massal yang dilakukan.
→ Ini adalah kegagalan notifikasi yang sangat serius.

Akuntabilitas Publik:
→ Siapa yang bertanggung jawab atas keputusan tidak menganggarkan
  backup yang memadai?
→ Pertanggungjawaban publik atas kegagalan ini masih belum jelas.

Implikasi terhadap "kedaulatan data":

Kasus PDN memunculkan pertanyaan yang lebih besar tentang konsep kedaulatan data nasional (data sovereignty). Apakah menyimpan semua data di server nasional otomatis lebih aman? Kasus ini menunjukkan bahwa lokalisasi fisik data tanpa tata kelola yang kuat justru bisa lebih rentan daripada menggunakan cloud internasional yang tersertifikasi.

Pelajaran Bagi Pengembang dan Pembuat Kebijakan

LESSON LEARNED — KASUS PDN 2024

Untuk Pengembang & Arsitektur Sistem:
✓ 3-2-1 Backup Rule bukan opsional — ia adalah standar minimum.
✓ Disaster Recovery Plan (DRP) harus DIUJI secara berkala, bukan
  hanya ditulis di atas kertas.
✓ Zero-Trust Architecture — asumsikan setiap bagian sistem dapat
  dikompromikan; desain pertahanan berlapis.
✓ Segmentasi jaringan — jika satu sistem dikompromikan, jangan biarkan
  ia merembet ke semua 282 instansi lainnya.

Untuk Pembuat Kebijakan & Tata Kelola:
✓ Anggaran keamanan siber harus diperlakukan sebagai investasi
  infrastruktur kritis, bukan pengeluaran opsional.
✓ Audit keamanan independen secara berkala oleh pihak ketiga.
✓ Kewajiban pelaporan insiden yang jelas dan dapat ditegakkan.
✓ Pertanggungjawaban yang nyata — jika kegagalan tata kelola yang
  menyebabkan insiden, harus ada akuntabilitas yang jelas.

MATRIKS PERBANDINGAN KETIGA KASUS

BAGIAN 7.4 — TANGGUNG JAWAB HUKUM PENGELOLA SISTEM PASCA-UU PDP

7.4.1 Tiga Jenis Tanggung Jawab Hukum

Dalam kerangka UU PDP, pengendali data dapat menghadapi tiga lapisan tanggung jawab hukum yang dapat berlaku bersamaan:

TIGA LAPISAN TANGGUNG JAWAB HUKUM PENGENDALI DATA

┌────────────────────────────────────────────────────────┐
│ 1. TANGGUNG JAWAB ADMINISTRATIF                        │
│    (Pasal 57 UU PDP)                                   │
│    • Teguran tertulis                                  │
│    • Penghentian sementara pemrosesan                  │
│    • Penghapusan atau pemusnahan data                  │
│    • Denda administratif: maks. 2% pendapatan tahunan  │
│    Dikenakan oleh: Kominfo/lembaga pengawas            │
└──────────────────────┬─────────────────────────────────┘
                       │
┌──────────────────────▼─────────────────────────────────┐
│ 2. TANGGUNG JAWAB PIDANA                               │
│    (Pasal 67–73 UU PDP)                                │
│    • Pidana penjara 4–6 tahun + denda Rp4–6 miliar     │
│      (pemrosesan data ilegal)                          │
│    • Pidana penjara 5–6 tahun + denda Rp5–6 miliar     │
│      (pemalsuan data)                                  │
│    Dikenakan oleh: pengadilan pidana                   │
└──────────────────────┬─────────────────────────────────┘
                       │
┌──────────────────────▼─────────────────────────────────┐
│ 3. TANGGUNG JAWAB PERDATA                              │
│    (Pasal 62 UU PDP + hukum perdata umum)              │
│    • Ganti kerugian kepada subjek data yang dirugikan  │
│    • Gugatan class action oleh kelompok subjek data    │
│    Dikenakan oleh: pengadilan perdata                  │
└────────────────────────────────────────────────────────┘

7.4.2 Kewajiban Notifikasi Pelanggaran Data

Ini adalah kewajiban baru yang paling operasional dari UU PDP dan sering terabaikan. Pasal 46 UU PDP mewajibkan pengendali data yang mengalami pelanggaran data untuk:

1. Memberitahu lembaga pengawas (Kominfo):

• Dalam waktu 14 hari kerja sejak pelanggaran diketahui.
• Memuat: deskripsi pelanggaran, estimasi jumlah subjek data terdampak, jenis data yang terdampak, dampak yang mungkin terjadi, dan langkah penanganan yang diambil.

2. Memberitahu subjek data yang terdampak:

• Jika pelanggaran berpotensi menimbulkan risiko tinggi terhadap hak-hak subjek data.
• Dalam bahasa yang mudah dipahami.

FLOWCHART KEWAJIBAN NOTIFIKASI

Insiden Diketahui
       │
       ▼
Apakah data pribadi terlibat?
  Tidak → Tidak perlu notifikasi UU PDP
  Ya    → Lanjut
       │
       ▼
Apakah berpotensi menimbulkan risiko bagi subjek data?
  Tidak → Tetap catat secara internal
  Ya    → Wajib notifikasi
       │
       ▼
Dalam 14 Hari Kerja:
  → Laporkan ke Kominfo (detail teknis)
  → Notifikasi subjek data terdampak (bahasa sederhana)
       │
       ▼
Dokumentasikan seluruh proses
(untuk membuktikan kepatuhan jika diaudit)

Risiko keterlambatan notifikasi: Keterlambatan bukan hanya melanggar UU PDP — ia juga memberikan waktu lebih lama bagi pihak yang mendapatkan data untuk menyalahgunakannya (penipuan identitas, phishing yang lebih terarah, dll.). Inilah mengapa batas waktu 14 hari kerja perlu dipahami sebagai batas maksimum, bukan target.

7.4.3 Tanggung Jawab Pemroses Data vs. Pengendali Data

Perbedaan tanggung jawab antara pengendali data dan pemroses data penting untuk dipahami dalam konteks pengembangan sistem yang melibatkan pihak ketiga:

Implikasi bagi pengembang software: Jika Anda membangun aplikasi untuk klien yang mengumpulkan data pengguna, Anda kemungkinan berposisi sebagai pemroses data. Ini berarti Anda wajib:

• Menandatangani DPA (Data Processing Agreement) yang jelas.
• Tidak memproses data di luar instruksi pengendali.
• Melaporkan insiden kepada pengendali tanpa penundaan yang tidak perlu.
• Menghapus atau mengembalikan data setelah kontrak berakhir.

7.4.4 Data Protection Officer (DPO)

UU PDP mewajibkan beberapa kategori organisasi untuk menunjuk DPO (Pejabat Pelindungan Data Pribadi):

Organisasi yang wajib memiliki DPO:

• Pengendali data yang secara inti melakukan pemantauan sistematis subjek data berskala besar.
• Pengendali data yang secara inti memproses data pribadi spesifik berskala besar.
• Lembaga publik/instansi pemerintah (dengan pengecualian tertentu).

Fungsi DPO dalam organisasi:

PERAN DPO DALAM EKOSISTEM DATA

             Lembaga Pengawas
             (Kominfo)
                   ↑
                   │ Titik kontak regulasi
                   │
    ┌──────── DPO ────────┐
    │         │           │
    │    Independen       │
    │    dari manajemen   │
    │    operasional      │
    │                     │
    ↓         ↓           ↓
Manajemen  Tim TI    Tim Legal/Compliance
    │         │
    └─────────┘
         ↓
    Seluruh Organisasi
         ↓
    Subjek Data (pengguna/pelanggan)

DPO bukan sekadar posisi administratif — ia adalah gatekeeper yang memastikan organisasi beroperasi sesuai UU PDP. DPO yang efektif harus memiliki akses langsung ke manajemen puncak dan perlindungan dari tekanan yang menghalangi tugasnya.

BAGIAN 7.5 — PERSPEKTIF ISLAMI: PRIVASI, KEHORMATAN, DAN AMANAH DATA

Bagian ini menghubungkan materi hukum dengan nilai-nilai Islam sebagai identitas kelembagaan UIN K.H. Abdurrahman Wahid Pekalongan.

Privasi dalam Perspektif Islam

Islam telah menempatkan penghormatan terhadap privasi sebagai nilai fundamental jauh sebelum era digital. Beberapa landasan nilai dalam Islam yang berkorespondensi dengan prinsip perlindungan data modern:

1. Larangan Tajassus (Memata-matai):

"Wa lā tajassasū" — "Dan janganlah kamu mencari-cari kesalahan orang lain" (QS. Al-Hujurat: 12)

Pengumpulan data secara diam-diam (covert data collection) tanpa sepengetahuan pengguna adalah ekspresi digital dari tajassus yang dilarang. Consent yang disyaratkan UU PDP sejalan langsung dengan larangan ini.

2. Konsep Amanah dalam Pengelolaan Data:

"Sesungguhnya Allah memerintahkan kamu menyampaikan amanah kepada yang berhak menerimanya" (QS. An-Nisa: 58)

Ketika pengguna mempercayakan datanya kepada sebuah platform, mereka menempatkan amanah. Pengendali data yang menyalahgunakan, menjual, atau lalai menjaga data tersebut telah mengkhianati amanah — sebuah dosa yang dalam Islam ditempatkan pada derajat yang sangat serius.

3. Perlindungan Kehormatan (Hifzh al-'Ird):

Dalam maqashid syariah (tujuan-tujuan syariat), perlindungan kehormatan (hifzh al-'ird) adalah salah satu dari lima perlindungan fundamental. Kebocoran data yang mengungkap informasi sensitif tentang seseorang — kesehatan, orientasi seksual, kondisi keuangan — secara langsung mengancam kehormatan ('ird) yang wajib dilindungi.

Implikasi bagi Pengembang Muslim:

Sebagai pengembang sistem yang beriman, membangun sistem yang menghormati privasi pengguna bukan sekadar kewajiban hukum — ia adalah kewajiban moral dan spiritual. Membangun dark pattern yang memanipulasi pengguna untuk berbagi lebih banyak data adalah bertentangan dengan nilai-nilai amanah dan ihsan dalam Islam.

AKTIVITAS PEMBELAJARAN PERTEMUAN 7

Jadwal Sesi (100 Menit)

Instruksi Analisis Kelompok (45 Menit)

Pembagian: Setiap kelompok mendapat satu kasus (dibagi merata oleh dosen).

Tugas: Analisis kasus yang diberikan menggunakan framework 4 pertanyaan:

Kelompok Kasus BPJS 2021: Asumsikan UU PDP sudah berlaku penuh saat kejadian ini terjadi.

1. Kewajiban UU PDP apa saja yang dilanggar BPJS Kesehatan? Sebutkan pasal spesifiknya.
2. Siapa yang harus bertanggung jawab — Direksi BPJS? Tim IT? Keduanya? Jelaskan.
3. Jika Anda adalah Kominfo, sanksi administratif apa yang Anda rekomendasikan?
4. Jika Anda adalah DPO BPJS yang baru diangkat setelah insiden, apa 3 langkah pertama yang akan Anda ambil?

Kelompok Kasus MyPertamina 2022:

1. Kewajiban teknis apa yang seharusnya mencegah kebocoran ini?
2. Bagaimana seharusnya Pertamina merespons dalam 14 hari pertama pascainsiden? Buat draft singkat notifikasi kepada pengguna yang terdampak.
3. Sebagai pengembang sistem, apa 3 kontrol teknis yang bisa mencegah kebocoran melalui kerentanan API?
4. Siapa yang lebih bertanggung jawab: pengembang aplikasi MyPertamina, atau manajemen Pertamina yang mengambil keputusan anggaran keamanan?

Kelompok Kasus PDN 2024:

1. Identifikasi minimal 3 kegagalan tata kelola (governance failures) dalam kasus ini, bukan hanya kegagalan teknis.
2. Apakah warga negara yang datanya terdampak dapat mengajukan gugatan perdata terhadap pemerintah berdasarkan UU PDP? Apa argumen hukumnya?
3. Buat rekomendasi kebijakan: apa 3 perubahan yang harus dilakukan pemerintah untuk mencegah insiden serupa?
4. Kasus ini menimbulkan pertanyaan: apakah kebijakan "data sovereignty" (menyimpan semua data di server nasional) efektif tanpa diikuti tata kelola yang kuat? Argumentasikan pendapat Anda.

Format Output (untuk dipresentasikan):

• Lembar kerja singkat (bisa di kertas atau slide sederhana)
• Minimal 1 perwakilan kelompok yang memaparkan dalam 3 menit

EVALUASI PERTEMUAN 7

Jenis Evaluasi: Tugas (Pengumuman) + Penilaian Partisipasi Presentasi Kelompok

A. Penilaian Partisipasi Presentasi Kelompok

Observasi dosen terhadap kedalaman analisis kelompok, kualitas argumentasi hukum, dan kemampuan menghubungkan prinsip UU PDP dengan kasus nyata.

B. TUGAS 4 — Audit Perlindungan Data Pribadi (Individu)

Tenggat: 1 hari sebelum Pertemuan 10 Format pengumpulan: Via Ngaji UIN Gusdur (opens in a new tab) dalam format PDF

Deskripsi Tugas

Pilih satu aplikasi mobile atau website yang sering Anda gunakan (misalnya: marketplace, media sosial, aplikasi kesehatan, e-learning, fintech/dompet digital). Lakukan audit kepatuhan terhadap UU PDP No. 27/2022.

Pedoman Pemilihan Aplikasi

Pilihlah aplikasi yang:

• Anda benar-benar menggunakannya (agar Anda bisa menguji fitur-fiturnya).
• Mengumpulkan data pribadi yang signifikan.
• Memiliki kebijakan privasi yang dapat diakses publik.

Hindari memilih aplikasi yang terlalu sederhana (kalkulator, timer) atau yang tidak mengumpulkan data pengguna sama sekali.

Struktur Laporan Audit (Maks. 2.000 Kata)

Bagian 1 — Profil Aplikasi (10 poin):

• Nama aplikasi, pengembang/perusahaan, tanggal peluncuran
• Jumlah pengguna aktif (cari data terbaru)
• Jenis data yang dikumpulkan (buat daftar berdasarkan kebijakan privasi + izin yang diminta)
• Kategori data berdasarkan UU PDP: mana yang termasuk data umum, mana yang spesifik?

Bagian 2 — Analisis Kebijakan Privasi (30 poin): Evaluasi kebijakan privasi aplikasi menggunakan checklist berikut:

Bagian 3 — Audit Hak Subjek Data (30 poin): Lakukan uji coba nyata terhadap implementasi hak-hak subjek data. Dokumentasikan dengan screenshot untuk setiap pengujian:

Bagian 4 — Temuan & Gap Analysis (20 poin): Buat daftar ketidakpatuhan yang Anda temukan. Untuk setiap gap:

• Uraikan gap yang ditemukan
• Sebutkan pasal UU PDP yang dilanggar
• Nilai risiko: rendah / sedang / tinggi (untuk subjek data)

Bagian 5 — Rekomendasi (10 poin): Untuk setiap gap yang ditemukan, berikan rekomendasi spesifik:

• Apa yang harus diubah (perubahan kebijakan atau teknis)?
• Berapa estimasi waktu implementasi?
• Prioritas: wajib segera / penting / dapat ditunda?

Rubrik Penilaian Tugas 4

KONEKSI KE PERTEMUAN 8 (UTS)

Pertemuan 7 sebagai Penutup Pra-UTS

Pertemuan 7 adalah pertemuan terakhir sebelum UTS. Artinya, seluruh materi P1–P7 akan diujikan pada Pertemuan 8. Berikut adalah cara Pertemuan 7 menjadi "titik kulminasi" dari rangkaian pertemuan sebelumnya:

BENANG MERAH P1–P7 MENUJU UTS

P1: Apa itu cyberlaw & mengapa dibutuhkan?
          ↓
P2: Bagaimana sistem hukum Indonesia mengatur TI?
          ↓
P3: UU ITE: apa yang boleh dan tidak boleh dilakukan?
          ↓
P4: Apa konsekuensi pidana melanggar UU ITE?
          ↓
P5: Bagaimana transaksi digital diatur, dan apa hak konsumen?
          ↓
P6: Data pribadi apa yang dilindungi? Apa hak subjek data?
          ↓
P7: Ketika perlindungan gagal — siapa bertanggung jawab,
    bagaimana seharusnya sistem dibangun dari awal?
          ↓
P8: UTS — menguji kemampuan menganalisis skenario nyata
    menggunakan semua kerangka hukum dari P1–P7

Kisi-Kisi UTS dari Materi Pertemuan 6 & 7

Prediksi Soal UTS yang Mengintegrasikan Materi P1–P7

Soal UTS tipe esai analitik kemungkinan besar menggabungkan beberapa pertemuan:

Contoh Soal Esai Integratif: "Sebuah startup healthtech mengumpulkan data biometrik (detak jantung, kadar oksigen darah) dari pengguna aplikasi pemantau kesehatan mereka. Data ini disimpan di server cloud pihak ketiga. Pada suatu hari, startup ini menemukan ada pihak tidak dikenal yang mengakses database mereka. Analisis: (a) Regulasi apa saja yang relevan (sebutkan minimal 3 dengan pasal spesifik)? (b) Kewajiban apa yang harus dipenuhi startup ini dalam 14 hari ke depan? (c) Siapa saja pihak yang berpotensi bertanggung jawab secara hukum? (d) Jika Anda adalah pengembang sistem startup ini, prinsip Privacy by Design mana yang harusnya sudah mencegah insiden ini?"

REFLEKSI INTEGRASI: BENANG MERAH PERTEMUAN 6 & 7

PERTEMUAN 6                          PERTEMUAN 7
"Teks Hukum"                         "Realita Lapangan"

UU PDP Pasal 35:                     Kasus PDN 2024:
"Wajib menjaga keamanan"      →      98% database tidak punya backup

UU PDP Pasal 46:                     Kasus BPJS 2021:
"Wajib notifikasi 14 hari"    →      Tidak ada notifikasi sistematis
                                      kepada 279 juta subjek data

UU PDP Pasal 34:                     Kasus MyPertamina 2022:
"Wajib DPIA untuk risiko tinggi" →   Tidak ada informasi DPIA yang
                                      dilakukan sebelum insiden

7 Prinsip Pemrosesan (P6):
Data Minimization                →   Mengapa data gaji disimpan bersama
Purpose Limitation                    NIK dan nomor HP dengan akses luas?
Accountability

Kesimpulan benang merah: Bukan berarti UU PDP tidak berguna. Justru sebaliknya — kasus-kasus ini menunjukkan mengapa UU PDP dibutuhkan, mengapa penegakannya harus serius, dan mengapa Anda sebagai pengembang perlu memahami UU PDP bukan sebagai hambatan, melainkan sebagai panduan untuk membangun sistem yang lebih baik dan bertanggung jawab.

KONEKSI KE PERTEMUAN-PERTEMUAN BERIKUTNYA

Ke Pertemuan 9 — Cybercrime

Kasus-kasus kebocoran data di P7 adalah contoh nyata dari cybercrime. Di P9, kita akan mengklasifikasikan jenis-jenis kejahatan siber secara sistematis — termasuk di mana kasus seperti BPJS, MyPertamina, dan PDN masuk dalam tipologi.

Ke Pertemuan 10 — Penegakan Hukum Siber

Di P7, kita bertanya "siapa yang bertanggung jawab?" Namun di P10, kita akan bertanya "bagaimana mekanisme penegakannya?" — bagaimana Bareskrim Polri menyidik, apa itu digital forensics, dan bagaimana bukti elektronik dikumpulkan dalam kasus seperti ini.

Ke Pertemuan 12 — Regulasi AI & Fintech

Hak ke-9 subjek data (keberatan terhadap keputusan otomatis) yang dipelajari di P6 dan ketimpangan kuasa data yang dibahas di P7 akan sangat relevan di P12 ketika kita membahas bagaimana EU AI Act mengatur sistem AI yang membuat keputusan berdampak tinggi (high-risk AI) — seperti credit scoring atau rekrutmen.

Ke Pertemuan 15 — Etika Profesi TI

Privacy by Design yang dipelajari di P7 adalah prinsip etika profesi sekaligus kewajiban hukum. Di P15, kita akan membahas bagaimana kode etik ACM, IEEE, dan APTIKOM menempatkan tanggung jawab pengembang terhadap privasi pengguna.

RANGKUMAN MATERI PERTEMUAN 7

DAFTAR REFERENSI

Format APA edisi ke-7

Peraturan Perundang-Undangan

Undang-Undang Nomor 27 Tahun 2022 tentang Perlindungan Data Pribadi. Lembaran Negara Republik Indonesia Tahun 2022 Nomor 196.

Undang-Undang Nomor 1 Tahun 2024 tentang Perubahan Kedua atas Undang-Undang Nomor 11 Tahun 2008 tentang Informasi dan Transaksi Elektronik. Lembaran Negara Republik Indonesia Tahun 2024 Nomor 1.

Undang-Undang Dasar Negara Republik Indonesia Tahun 1945. Pasal 28G ayat (1), Pasal 28H ayat (4), Pasal 28F.

Peraturan Pemerintah Nomor 71 Tahun 2019 tentang Penyelenggaraan Sistem dan Transaksi Elektronik. Lembaran Negara Republik Indonesia Tahun 2019 Nomor 185.

Buku

Cavoukian, A. (2009). Privacy by design: The 7 foundational principles. Office of the Information and Privacy Commissioner of Ontario. https://www.ipc.on.ca/wp-content/uploads/resources/7foundationalprinciples.pdf (opens in a new tab)

Makarim, E. (2005). Pengantar hukum telematika: Suatu kompilasi kajian. PT RajaGrafindo Persada.

Solove, D. J. (2013). Nothing to hide: The false tradeoff between privacy and security. Yale University Press. (Chapter 1–3)

(Mengapa privasi penting bahkan jika "Anda tidak punya yang disembunyikan")

Zuboff, S. (2019). The age of surveillance capitalism. Public Affairs. (Chapter 1)

(Bagaimana data perilaku pengguna menjadi komoditas ekonomi — "surveillance capitalism")

Spinello, R. A. (2011). Cyberethics: Morality and law in cyberspace (4th ed.). Jones & Bartlett Learning. (Chapter 4 — Privacy in Cyberspace)

Artikel Jurnal

Wahyudi, A. (2020). Perlindungan data pribadi dalam perspektif hukum Indonesia. Jurnal Hukum IUS QUIA IUSTUM, 27(1), 92–115.

Rosadi, S. D., & Pratama, G. G. (2018). Perlindungan privasi dan data pribadi dalam era ekonomi digital di Indonesia. Veritas et Justitia, 4(1), 88–110. https://doi.org/10.25123/vej.2916 (opens in a new tab)

Laporan & Dokumen Resmi

BSSN. (2024). Laporan keamanan siber nasional 2024. Badan Siber dan Sandi Negara. https://bssn.go.id (opens in a new tab)

ELSAM. (2022). Laporan situasi hak atas privasi di Indonesia 2021–2022. Lembaga Studi dan Advokasi Masyarakat. https://elsam.or.id (opens in a new tab)

SAFENet. (2023). Laporan keamanan data dan privasi digital Indonesia. Southeast Asia Freedom of Expression Network. https://safenet.or.id (opens in a new tab)

Kominfo. (2022). Naskah Akademik Rancangan Undang-Undang Perlindungan Data Pribadi. Kementerian Komunikasi dan Informatika.

Referensi Internasional

European Parliament. (2016). Regulation (EU) 2016/679 of the European Parliament and of the Council (General Data Protection Regulation). Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj (opens in a new tab)

Cavoukian, A. (2012). Privacy by design: Origins, meaning, and prospects for assuring privacy and trust in the information era. In G. Yee (Ed.), Privacy protection measures and technologies in business organizations: Aspects and standards (pp. 170–208). IGI Global.

Sumber Daring

Kementerian Komunikasi dan Informatika. Portal pengaduan data pribadi. https://aduan.komdigi.go.id (opens in a new tab)

JDIHN. Jaringan dokumentasi dan informasi hukum nasional. https://jdih.go.id (opens in a new tab)

BSSN. Panduan penanganan insiden siber. https://bssn.go.id (opens in a new tab)

Modul ini adalah bagian dari seri materi kuliah INF2505 — Hukum dan Kebijakan Teknologi Informasi. Materi akan diperbarui setiap semester menyesuaikan perkembangan regulasi.

Dosen Pengampu: Mohammad Reza Maulana, M.Kom — Program Studi Informatika, Fakultas Ekonomi dan Bisnis Islam, UIN K.H. Abdurrahman Wahid Pekalongan