TL;DR
Kebijakan retensi data adalah aturan tertulis soal berapa lama tiap jenis data disimpan, kapan diarsipkan, dan kapan dihapus permanen. Di Indonesia, dokumen keuangan perusahaan wajib disimpan 10 tahun (UU 8/1997), sementara UU PDP 27/2022 mewajibkan penghapusan data pribadi begitu masa retensinya habis. Praktik amannya: bikin tabel retensi per dataset, pisahkan data pribadi dari data agregat, lalu jalankan job arsip terjadwal biar penghapusan gak bergantung ingatan orang.
Kebijakan retensi data adalah aturan tertulis yang nentuin berapa lama tiap jenis data disimpan, kapan dipindah ke arsip, dan kapan dihapus permanen.
Tanpa aturan itu, jawaban default tiap tim data selalu sama: simpan aja semua, siapa tahu butuh.
Masalahnya, "siapa tahu butuh" itu punya harga. Bukan cuma biaya storage, tapi juga risiko kalau data pribadi yang harusnya udah hilang tiga tahun lalu masih nangkring di tabel produksi.
Aku bakal bahas gimana nentuin durasi simpan per jenis data, apa dasar hukumnya di Indonesia, dan gimana bikin proses arsipnya jalan otomatis lewat SQL.
Kebijakan retensi data adalah dokumen yang mencantumkan tiap dataset di perusahaan, berapa lama data itu disimpan dalam kondisi aktif, kapan diarsipkan, dan kapan dihapus. Isinya juga nyebut siapa yang bertanggung jawab dan apa dasar keputusannya, entah aturan hukum, kebutuhan analisis, atau perjanjian dengan pelanggan.
Bentuknya gak harus tebal. Satu spreadsheet dengan lima kolom udah lebih baik daripada kebijakan 40 halaman yang gak pernah dijalankan.
Yang bikin dokumen ini beda dari sekadar niat baik: ada tanggal, ada nama orang, ada job yang jalan otomatis.
Alasan pertama paling gampang diukur: biaya. Tabel transaksi yang tumbuh 8 juta baris per tahun bakal bikin query harian makin lambat, dan tim biasanya baru sadar pas dashboard yang dulu 3 detik sekarang 40 detik.
Alasan kedua lebih serius. Tiap baris data pribadi yang kamu simpan tanpa alasan jelas adalah tanggungan kalau terjadi kebocoran.
Alasan ketiga jarang dibahas: data lama bikin analisis jadi keliru. Definisi kolom berubah, sistem kasir ganti, kode produk dipakai ulang. Data 2019 yang dicampur begitu aja sama data 2025 sering menghasilkan angka yang salah tapi kelihatan meyakinkan. Ini bagian dari isu data quality yang paling susah dideteksi.
Alasan keempat: makin banyak tabel, makin ribet urusan ETL kamu. Tiap tabel yang gak pernah dibersihkan tetap ikut proses harian dan makan slot komputasi.
Gak ada satu angka yang berlaku untuk semua. Cara paling praktis: kelompokkan data ke beberapa kelas, lalu tetapkan durasi per kelas.
Ini tabel yang aku pakai sebagai titik awal waktu bantu UMKM dan tim data kecil nyusun kebijakan pertama mereka.
| Kelas data | Contoh | Aktif | Arsip | Dasar |
|---|---|---|---|---|
| Transaksi keuangan | Faktur, nota, jurnal | 24 bulan | sampai 10 tahun | Kewajiban dokumen perusahaan |
| Data pribadi pelanggan | Nama, email, no HP, alamat | selama akun aktif | maks 36 bulan setelah transaksi terakhir | Persetujuan + kebutuhan layanan |
| Log aktivitas aplikasi | Login, klik, error log | 90 hari | 12 bulan | Kebutuhan investigasi |
| Data agregat | Penjualan harian per cabang | selamanya | - | Gak mengandung data pribadi |
| Data karyawan | Kontrak, absensi, payroll | selama bekerja | sesuai kewajiban ketenagakerjaan | Kewajiban administrasi |
| Backup database | Snapshot harian | 30 hari | 90 hari rolling | Kebutuhan pemulihan |
Perhatikan baris "data agregat". Itu kuncinya.
Kamu boleh hapus 4 juta baris transaksi detail tahun 2021 asal ringkasan hariannya udah kamu simpan duluan. Tren lima tahun tetap kebaca, ukuran tabel turun drastis.
Dua yang paling sering kepakai buat tim data.
UU No. 8 Tahun 1997 tentang Dokumen Perusahaan. Pasal 11 mewajibkan catatan, bukti pembukuan, dan data pendukung administrasi keuangan disimpan selama 10 tahun terhitung dari akhir tahun buku perusahaan. Ini yang bikin data transaksi gak bisa kamu hapus semudah log aplikasi.
UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi. Pasal 43 mewajibkan pengendali data pribadi menghentikan pemrosesan dan menghapus data pribadi kalau masa retensinya udah berakhir, tujuan pemrosesannya udah tercapai, atau pemiliknya menarik persetujuan. Naskah lengkapnya bisa kamu baca di basis data peraturan BPK.
Dua aturan ini kadang kelihatan bentrok. Faktur wajib disimpan 10 tahun, tapi faktur juga memuat nama dan alamat pelanggan.
Jalan tengah yang lazim: simpan dokumen keuangannya, tapi kolom identitas yang gak diperlukan untuk audit diminimalkan atau dipisah ke tabel terkunci dengan akses terbatas.
Kalau kasusnya rumit, tanya legal. Aku bukan pengacara dan artikel ini bukan nasihat hukum.
Pola yang paling sering aku pakai: pindah dulu, baru hapus. Jangan pernah DELETE tanpa tabel tujuan.
-- Langkah 1: pindahkan transaksi lebih tua dari 24 bulan
INSERT INTO transaksi_arsip
SELECT * FROM transaksi
WHERE tanggal < CURRENT_DATE - INTERVAL '24 months';
-- Langkah 2: hapus dari tabel aktif
DELETE FROM transaksi
WHERE tanggal < CURRENT_DATE - INTERVAL '24 months';Untuk data pribadi, penghapusan total sering bikin laporan historis rusak. Gantinya, anonimkan.
UPDATE pelanggan
SET nama = 'REDACTED',
email = NULL,
no_hp = NULL,
alamat = NULL,
status_retensi = 'anonim'
WHERE tanggal_transaksi_terakhir < CURRENT_DATE - INTERVAL '36 months'
AND status_retensi = 'aktif';Baris pelanggan tetap ada, jadi total penjualan 2022 gak berubah. Yang hilang cuma identitasnya.
Sebelum job-nya jalan, aku selalu bikin view pengecekan supaya tahu berapa banyak yang bakal kena.
SELECT nama_tabel, kelas_data, umur_bulan, jumlah_baris
FROM v_audit_retensi
WHERE umur_bulan > batas_retensi_bulan
ORDER BY umur_bulan DESC;Kalau angkanya kelihatan aneh, berhenti. Jangan jalanin DELETE-nya hari itu juga.
toko_berkah adalah dataset latihan ngulikdata, replika toko kelontong grosir dengan 3 cabang di Semarang.
Kondisi awalnya: tabel transaksi nyimpen 6 tahun data mentah, 11,4 juta baris, ukuran 4,2 GB. Query rekap bulanan butuh 38 detik.
Yang aku lakukan cuma tiga hal.
Pertama, bikin tabel penjualan_harian yang meringkas per tanggal, cabang, dan kode produk. Hasilnya 412 ribu baris, 96% lebih kecil dari data mentah.
Kedua, arsipkan transaksi di atas 24 bulan ke transaksi_arsip. Sisa di tabel aktif: 3,1 juta baris.
Ketiga, anonimkan 8.740 pelanggan yang gak transaksi lagi sejak lebih dari 36 bulan.
Angka yang paling bikin kaget bukan soal ukuran. Waktu query rekap bulanan turun dari 38 detik ke 2,4 detik. Dan dari 8.740 pelanggan yang dianonimkan, cuma 61 yang pernah muncul di laporan mana pun dalam 12 bulan terakhir.
Jadi 8.679 baris data pribadi disimpan bertahun-tahun tanpa sekali pun dipakai.
Itu pola yang aku lihat berulang di tim kecil. Data yang paling lama disimpan biasanya justru data yang paling jarang dibuka.
Bikin aturan tapi gak ada yang jalanin. Kebijakan yang cuma jadi PDF di folder bersama sama nilainya dengan gak punya kebijakan. Kalau belum ada job terjadwal, itu masih niat.
Hapus data mentah sebelum bikin agregat. Ini kesalahan yang gak bisa diperbaiki. Selalu bikin ringkasan dulu, verifikasi angkanya cocok, baru hapus.
Lupa backup. Kamu hapus di produksi, tapi snapshot 6 bulan lalu masih utuh. Batasi umur backup dan tulis batas itu di kebijakan.
Nyamain semua tabel. Log aplikasi dan faktur pajak gak mungkin punya aturan yang sama. Kelompokkan dulu.
Gak nyimpen bukti penghapusan. Auditor gak nanya "datanya mana", mereka nanya "buktinya mana kalau kamu hapus sesuai aturan". Catat tanggal eksekusi, jumlah baris, dan siapa yang menjalankan.
Nentuin durasi sendirian. Tim data gak tahu kewajiban pajak, finance gak tahu struktur tabel. Keputusan retensi selalu keputusan bersama.
Arsip artinya data dipindah ke penyimpanan yang lebih murah dan jarang diakses, tapi masih bisa dipanggil kalau ada audit. Hapus artinya data hilang permanen. Sebagian besar kebijakan punya dua tahap: aktif 12-24 bulan, arsip sampai batas wajib hukum, baru dihapus. Data pribadi biasanya lompat lebih cepat ke tahap hapus atau anonimisasi.
UU PDP No. 27 Tahun 2022 gak nyebut angka bulan yang seragam. Pasal 43 mewajibkan pengendali data menghentikan pemrosesan dan menghapus data pribadi begitu masa retensi berakhir atau saat pemiliknya menarik persetujuan. Angkanya kamu yang tetapkan, tapi harus tertulis, punya alasan bisnis, dan diberitahukan ke pemilik data.
Iya, dan ini yang paling sering kelewat. Kamu udah hapus baris di database produksi, tapi backup tiga bulan ke belakang masih nyimpen data yang sama. Batasi umur backup, misalnya 90 hari rolling, catat siklusnya di dokumen kebijakan, dan pastikan permintaan penghapusan tercatat supaya gak balik lagi saat restore.
Pakai pertanyaan analisis: laporan terjauh yang pernah kamu bikin butuh data sampai kapan? Kalau tim cuma pernah banding tahun ini lawan tahun lalu, 24 bulan udah cukup buat tabel detail. Sisanya simpan sebagai agregat harian. Agregat jauh lebih kecil, gak mengandung data pribadi, dan tetap cukup buat tren panjang.
Minimal tiga pihak: pemilik proses bisnis yang tahu data itu dipakai untuk apa, tim legal atau finance yang tahu kewajiban simpan dokumen, dan tim teknis yang bakal jalanin job penghapusan. Tanpa persetujuan pemilik proses, penghapusan pertama hampir selalu berujung panik gara-gara ada laporan yang tiba-tiba kosong.
Tiga hal yang perlu kamu bawa dari sini.
Satu, kebijakan retensi itu tabel kecil berisi kelas data, durasi, dan penanggung jawab. Bukan dokumen tebal.
Dua, bikin agregat sebelum hapus apa pun. Ini langkah yang gak bisa diulang kalau kelewat.
Tiga, penghapusan harus jalan otomatis dan tercatat. Kalau bergantung ingatan orang, dia gak akan pernah jalan.
Coba mulai dari satu tabel log yang paling gemuk minggu ini. Hitung berapa baris yang umurnya di atas 12 bulan, terus tanya ke tim kapan terakhir data itu dibuka.
Mau latihan query arsip dan agregasinya langsung di browser? Kulik dataset toko_berkah di NgulikSQL, dan lanjut baca soal dashboard real-time kalau kamu lagi mikirin trade-off antara data segar dan data lama.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.