Menguji penghapusan data di aplikasi, cadangan, dan vendor
Menghapus profil dari layar belum cukup. Periksa tiap salinan yang masuk lingkup permintaan, buktikan hasilnya, dan cegah data lama kembali aktif setelah cadangan dipulihkan.
Di halaman ini
Tentukan apa yang boleh dan harus dihapus
Uji penghapusan memeriksa hasil pada sistem dan salinan, bukan hanya pesan “akun berhasil ditutup”. Sebelum menguji, tetapkan data dan tindakan yang masuk lingkup, identitas permintaan yang sah, serta data yang masih perlu diperiksa karena kewajiban penyimpanan atau perkara hukum. Gunakan panduan retensi untuk keputusan masa simpan.
Pasal 40 mengatur penghentian ketika persetujuan ditarik; Pasal 42–45 mengatur pengakhiran, penghapusan, pemusnahan dan pemberitahuan. Jangan memakai tenggat satu tindakan sebagai tenggat universal semua penghapusan. Salinan cadangan juga bukan pengecualian otomatis.
Jalankan pemeriksaan di lingkungan terpisah dengan data buatan. Jangan mencoba prosedur baru pada data pelanggan atau cadangan produksi.
Petakan salinan dan bukti pemeriksaannya
| Lokasi | Pemeriksaan contoh |
|---|---|
| Database aplikasi | Cari profil melalui antarmuka dan pemeriksaan yang diizinkan pada data aktif; akun lain tetap ada |
| Cache, pencarian dan antrean | Cek profil yang tersimpan sementara, hasil pencarian serta pekerjaan terjadwal |
| Vendor dan ekspor | Periksa lingkup instruksi, hasil/penolakan, salinan ekspor dan konfirmasi yang dapat dibuktikan |
| Cadangan | Catat salinan yang masih memuat data, keterbatasan, akses dan tindak lanjut; uji agar restore tidak mengaktifkannya lagi |
| Arsip yang dipertahankan | Catat dasar, kategori, akses, penggunaan yang dibatasi dan kapan ditinjau ulang |
Catatan hasil tidak perlu menyalin profil yang dihapus. Gunakan referensi kasus, sistem, pemeriksa, hasil dan alasan pekerjaan terbuka. Referensi atau pengenal di catatan itu sendiri tetap perlu akses dan retensi yang sesuai.
Jalankan contoh lokal Kompli
Unduh contoh pemeriksaan penghapusan versi 1.0. Paket berisi kode Python, petunjuk dan hasil eksekusi; tanpa data nyata, kredensial atau database produksi. Jalankan python3 deletion-lab.py pada Python 3.9+ dengan SQLite.
Model membuat dua profil buatan, database aplikasi, cache dan antrean lokal, database yang mewakili vendor, serta snapshot sebelum penghapusan. Ada pula arsip terbatas yang sengaja dipertahankan. Keputusan arsip itu dibuat untuk contoh; tidak menetapkan dasar atau durasi retensi suatu bisnis.
Pada eksekusi Python 3.9.6 dan SQLite 3.51.0, versi awal hanya menghapus profil aktif. Versi perbaikan juga membersihkan salinan aktif, mencatat ID penghapusan, menerapkannya sebelum membuka hasil restore, dan menjaga kegagalan vendor sebagai pekerjaan tertunda.
Pada kolom hasil, sisi kiri adalah versi awal dan sisi kanan versi perbaikan.
| Pemeriksaan | Hasil uji |
|---|---|
| Profil aktif tidak ditemukan | Lulus → lulus |
| Profil hilang dari cache, antrean dan model vendor | 3 gagal → 3 lulus |
| Arsip terbatas dan profil orang lain dipertahankan | 2 lulus → 2 lulus |
| Restore tidak mengaktifkan profil yang dihapus | Gagal → lulus |
| Restore ditolak jika catatan penghapusan tidak tersedia | Gagal → lulus |
| Kegagalan vendor tetap tertunda sampai pemeriksaan ulang | Gagal → lulus |
| Batas cadangan dan kedaluwarsa berkas dicatat | Gagal → lulus |
Hasilnya 3 dari 10 pemeriksaan pada versi awal dan 10 dari 10 setelah perbaikan. Ini hasil model lokal yang disertakan dalam paket, bukan sertifikat kepatuhan.
Cadangan lama belum berarti bersih
Snapshot model masih memuat profil sebelum berkas cadangan dihapus. Menerapkan catatan penghapusan pada hasil restore mencegah profil kembali aktif, tetapi tidak menghapus isinya dari snapshot asli.
Penghapusan baris SQLite atau berkas juga tidak membuktikan seluruh byte pada media tidak dapat dipulihkan. Contoh tidak menguji WAL, replika, media fisik, ekspor petugas, API vendor nyata atau pekerjaan yang berjalan bersamaan. Nilai metode serta batas sistem nyata secara terpisah; jangan menganggap menunggu rotasi cadangan selalu memenuhi hukum.
Tutup pekerjaan berdasarkan hasil
Jika vendor tidak merespons, simpan status tertunda, pemilik dan tindak lanjut. Jangan menandai selesai hanya karena permintaan sudah dikirim. Perjanjian dan pembagian tanggung jawab dibahas pada pemeriksaan vendor pengolah data.
Laporan kepada pemohon perlu membedakan tindakan yang selesai, data yang dipertahankan beserta alasannya, dan hal yang masih ditangani. Pasal 45 mengatur pemberitahuan penghapusan dan/atau pemusnahan; ikuti alur permintaan hak serta batas verifikasi aturan pelaksanaan.
Sumber rujukan
- UU Nomor 27 Tahun 2022 — naskah dan penjelasan ↗Republik Indonesia; naskah melalui JDIH BPK · Pasal 8–9, 16, 35–45, 47 dan 51–52; contoh uji lokal merupakan model Kompli, bukan metode resmi pemusnahan
Baca naskah lengkap untuk melihat syarat dan pengecualiannya. Sesuaikan dengan layanan dan bidang usaha Anda.
Perlu membahas kebutuhan tim Anda?
Ceritakan bagaimana tim Anda menggunakan data pribadi dan bagian yang ingin dibahas.
Konsultasikan kebutuhan Anda