Hak Subjek Data 3x24 Jam: Siapkan Website Sebelum Januari 2027

Pelanggan mengirim pesan singkat: "Tolong kirim salinan data saya, dan perbaiki alamat email yang salah." Di atas kertas, UU PDP memberi Anda 3x24 jam untuk memenuhi sebagian permintaan itu — bukan tiga hari kerja, bukan "minggu depan". Bagi pemilik toko online yang satu-satunya kanal pengaduan adalah DM Instagram dan email admin, tenggat hak subjek data 3x24 jam ini adalah risiko yang jarang disadari: aturannya sudah tertulis di undang-undang, dan alat penguatnya mulai berlaku penuh lewat PP 33/2026 pada 16 Januari 2027.

Kabar baiknya, memenuhi tenggat ini bukan soal biaya besar, melainkan soal mengukur — waktu penerimaan, waktu respons, dan bukti bahwa keduanya terjadi. Artikel ini membedah pasal mana yang menetapkan jam kerja, cara menghitungnya, dan bentuk sistem minimal yang bisa dibangun tim kecil dalam hitungan minggu.

1. Tiga Pasal yang Menetapkan Jam Kerja 3x24 Jam

UU 27/2022 tidak memberi tenggat seragam untuk semua hak subjek data. Tiga kewajiban secara eksplisit diikat jam 3x24 jam:

• Pasal 30 — perbaikan dan pembaruan data. Pengendali wajib memperbarui atau memperbaiki kesalahan dan ketidakakuratan data pribadi paling lambat 3x24 jam sejak menerima permintaan, lalu memberitahukan hasilnya kepada subjek data.
• Pasal 32 — akses dan salinan data. Pengendali wajib memberikan akses kepada data pribadi beserta rekam jejak pemrosesannya paling lambat 3x24 jam sejak permintaan akses diterima.
• Pasal 46 — notifikasi kegagalan pelindungan data. Jika terjadi insiden, pemberitahuan tertulis wajib keluar paling lambat 3x24 jam kepada dua pihak sekaligus: subjek data dan lembaga pengawas.

Dua catatan penting yang sering terlewat. Pertama, Pasal 33 memberi dasar untuk menolak akses atau perubahan — jika permintaan membahayakan keamanan subjek atau orang lain, mengungkap data milik orang lain, atau bertentangan dengan pertahanan dan keamanan nasional. Penolakan tetap harus terdokumentasi dan dapat dijelaskan. Kedua, Pasal 31 mewajibkan perekaman seluruh kegiatan pemrosesan — rekam jejak inilah yang harus Anda serahkan dalam 3x24 jam saat permintaan akses masuk, jadi tidak mungkin disiapkan di saat panik.

Hak lain seperti penghapusan dan portabilitas belum diikat tenggat eksplisit di UU PDP, tetapi tetap butuh prosedur terdokumentasi karena lembaga pengawas akan menilai kewajaran respons Anda.

2. Mengapa PP 33/2026 Membuat Tenggat Ini Tidak Bisa Diabaikan

Selama masa transisi, tenggat 3x24 jam ada di atas kertas tanpa alat penegakan yang rapi. PP 33/2026 — diundangkan 16 Juli 2026 dan berlaku 16 Januari 2027 — mengisi kekosongan itu: lembaga pelindungan data pribadi mulai mengawasi, sanksi administratif berbentuk peringatan tertulis, penghentian sementara pemrosesan, penghapusan data, dan denda hingga 2% pendapatan tahunan.

Tiga detail yang mengubah cara Anda sebaiknya membaca tenggat ini. Sanksi bisa dijatuhkan kumulatif dan tidak selalu didahului teguran. Besaran denda ditentukan oleh sepuluh variabel — termasuk skala usaha dan riwayat kepatuhan — jadi posisi "UMKM kecil" bukan imunitas, melainkan faktor peredam. Dan keputusan sanksi diumumkan ke publik; efek reputasinya sering bertahan lebih lama daripada dendanya.

Tidak ada masa transisi tambahan setelah 16 Januari 2027. Jika Anda masih menumpuk fondasi, mulai dari panduan kepatuhan PP 33/2026 untuk website — lalu perlakukan tenggat 3x24 jam sebagai SLA yang harus terukur, bukan niat baik.

3. Menghitung 3x24 Jam: Kapan Jam Mulai Berjalan

Redaksi pasalnya tegas: "terhitung sejak Pengendali Data Pribadi menerima permintaan." Tiga konsekuensi praktis:

• Jam kalender, bukan jam kerja. Permintaan yang masuk Jumat sore memberi Anda tenggat Senin sore — akhir pekan tidak menghentikan hitungan. Tim CS dua orang tetap punya kewajiban yang sama dengan perusahaan besar.
• "Menerima" harus punya bukti waktu. Email yang terbaca oleh pemilik usaha pada Selasa padahal masuk Sabtu tetap dihitung dari Sabtu. Inilah alasan kanal penerimaan formal (formulir, bukan DM) bukan formalitas, melainkan perlindungan.
• Verifikasi identitas masuk dalam hitungan yang sama. Anda tidak wajib menyerahkan data ke orang yang salah, tetapi verifikasi harus cepat — tautan konfirmasi ke email terdaftar atau OTP ke nomor telepon yang sudah ada di database, bukan proses manual berhari-hari.

Praktik minimal: setiap permintaan mencatat received_at otomatis dari waktu submit formulir, dan sistem mengirim pengingat internal di T-12 jam sebelum tenggat. Selisih dua belas jam itu yang membedakan respons tertib dari laporan terlambat.

4. Membangun Kanal Permintaan Hak Subjek Data yang Terukur

Kanal hak subjek data yang layak punya tiga komponen: pintu masuk yang mencatat waktu, proses verifikasi, dan tiket yang bisa dilacak. Formulir penerimaan minimal memuat: jenis permintaan (akses, perbaikan, penghapusan, portabilitas), identitas yang bisa diverifikasi, dan deskripsi kasus. Di belakangnya, satu tabel tiket cukup untuk tim kecil mana pun:

CREATE TABLE dsr_tickets (
  id UUID PRIMARY KEY,
  requester_email TEXT NOT NULL,
  request_type VARCHAR(30) NOT NULL,  -- access | correction | deletion | portability
  status VARCHAR(20) NOT NULL,        -- received | verifying | fulfilled | refused
  received_at TIMESTAMPTZ NOT NULL,
  deadline_at TIMESTAMPTZ NOT NULL,
  responded_at TIMESTAMPTZ,
  refusal_reason TEXT,
  notes TEXT
);

deadline_at diisi langsung dari received_at + interval '72 hours'. Cron harian (atau pekerja latar) memeriksa tiket yang mendekati tenggat dan mengirim notifikasi ke penanggung jawab — satu nama yang jelas, bukan "siapa saja yang sempat". Setiap penolakan diisi refusal_reason merujuk Pasal 33, sehingga bukti kepatuhan tinggal satu query dari Anda saat ada pertanyaan lembaga.

5. Menjawab Akses dan Perbaikan dalam Hitungan Jam: Peta Data dan Query Ekspor

Tenggat 3x24 jam tidak bisa dipenuhi jika Anda sendiri tidak tahu di mana data pelanggan tersebar. Susun peta data sederhana: tabel utama (users, orders, addresses, consent_records), sistem pihak ketiga (payment gateway seperti Midtrans atau Xendit yang menyimpan data sebagai prosesor, vendor email, CRM), dan log aplikasi yang mungkin menyimpan PII.

Dari peta itu, siapkan satu script ekspor yang menghasilkan salinan data subjek dalam format yang terbaca — JSON per tabel sudah memadai — beserta rekam jejak pemrosesannya. Uji script itu sebelum Januari, bukan saat permintaan pertama masuk. Untuk permintaan perbaikan, koreksi harus merambat: cache, CRM, milis vendor email, dan salinan di data warehouse. Daftar tempat yang wajib disentuh lebih baik tersimpan sebagai konfigurasi daripada ingatan seseorang.

Terakhir, pisahkan data yang memang tidak bisa dihapus — bukti transaksi untuk kewajiban pajak, misalnya — dan dokumentasikan bahwa Anda menganonimisasinya alih-alih menghapusnya. Jawaban itu jauh lebih meyakinkan daripada keheningan saat ditanya.

6. Runbook Insiden 3x24 Jam untuk Tim Kecil

Notifikasi kegagalan pelindungan data dalam 3x24 jam terasa mustahil bagi tim yang belum pernah latihan, dan terasa masuk akal bagi tim yang sudah. Runbook minimal:

1. Deteksi — alert anomali login admin, query database tidak wajar, atau laporan pelanggan masuk ke satu kanal yang dipantau.
2. Isolasi — rotasi kredensial, cabut session aktif, blokir akses yang dicurigai.
3. Inventarisasi — data apa yang terpapar, berapa subjek, sejak kapan.
4. Pemberitahuan — kirim pemberitahuan tertulis ke subjek data dan lembaga. Isi minimal sesuai Pasal 46: data pribadi yang terungkap, kapan dan bagaimana terungkap, serta upaya penanganan dan pemulihan.
5. Dokumentasi — lini masa insiden untuk audit berikutnya.

Simpan template pemberitahuan dan daftar kontak (termasuk kanal lembaga) di tempat yang bisa diakses saat server utama bermasalah — bukan hanya di wiki internal yang ikut terdampak. Latih sekali secara simulasi: jalankan dari deteksi sampai draf pemberitahuan jadi, ukur waktunya, perbaiki langkah yang macet. Jika fondasi keamanan website Anda masih longgar, checklist keamanan website 2026 adalah titik mulai yang lebih dulu.

7. Tabel: Jenis Permintaan vs Tenggat vs Yang Harus Siap

Baca tabelnya sebagai diagnosis: baris yang kolom kanannya masih kosong adalah pekerjaan minggu ini, bukan pekerjaan Desember.

8. Checklist 11 Minggu Menuju 16 Januari 2027

Dari hari ini, ada sebelas minggu. Rencana yang realistis untuk tim kecil:

• Minggu 1–2 — peta data dan tabel tiket DSR dengan deadline_at.
• Minggu 3–4 — script ekspor akses, diuji dengan data sungguhan di staging.
• Minggu 5–6 — propagasi koreksi ke cache, CRM, dan vendor; dokumentasi dasar penolakan Pasal 33.
• Minggu 7 — runbook insiden, template pemberitahuan, dan satu simulasi terukur.
• Minggu 8–9 — audit vendor: DPA, region data, dukungan penghapusan. Region GCP asia-southeast2 (Jakarta) mengurangi kerumitan transfer lintas negara.
• Minggu 10 — rekam jejak pemrosesan (Pasal 31) diperiksa; kanal permintaan dipasang di halaman publik.
• Minggu 11 — uji akhir end-to-end, lalu bekukan perubahan sampai 16 Januari.

Jika Anda butuh dasar konseptualnya dulu, panduan praktis UU PDP untuk website dan aplikasi menjelaskan hak subjek data dari sisi produk; artikel ini adalah lapisan operasionalnya.

Kesimpulan

Tenggat hak subjek data 3x24 jam sudah tertulis sejak UU PDP berlaku, dan PP 33/2026 yang efektif 16 Januari 2027 memberinya penegak: lembaga pengawas, sanksi hingga 2% pendapatan tahunan, dan pengumuman publik. Yang membedakan bisnis yang tenang dan yang panik bukan anggaran hukum, melainkan tiga artefak engineering: kanal permintaan yang mencatat waktu, script ekspor yang pernah diuji, dan runbook insiden dengan template siap kirim.

Di Zero Args Technology, kami membantu UMKM dan tim produk di Indonesia membangun website dengan kepatuhan data yang terukur sejak awal — bukan ditambal menjelang deadline. Mulai percakapan jika Anda ingin kanal hak subjek data dan runbook 3x24 jam Anda siap sebelum Januari.