Prinsip Storage Limitation dalam UU PDP
Pasal 7 UU PDP menetapkan prinsip "pembatasan penyimpanan" (storage limitation principle) yang mengatur bahwa data pribadi hanya boleh disimpan selama periode yang diperlukan untuk mencapai tujuan pemrosesan, tidak lebih lama. Prinsip ini didasarkan pada konsep "necessity"—jika data sudah tidak diperlukan untuk tujuan yang dinyatakan, maka data harus segera dihapus atau dianonimasi. Organisasi tidak dapat menyimpan data "just in case" suatu hari nanti mungkin berguna, atau untuk spekulasi tentang use case masa depan.
Storage limitation memiliki dua komponen:
(1) temporal—berapa lama data boleh disimpan, dan
(2) functional—apakah data masih relevan untuk fungsi yang dinyatakan. Untuk komponen temporal, organisasi harus menetapkan periode retensi yang jelas per kategori data atau per purpose. Periode retensi harus:
(a) didasarkan pada tujuan pemrosesan—data yang disimpan untuk fulfill kontrak dapat dihapus setelah kontrak selesai plus periode untuk resolusi dispute (biasanya 30 hari),
(b) mempertimbangkan kewajiban hukum—jika ada regulasi yang mengharuskan retention untuk periode tertentu, organisasi dapat menyimpan selama periode itu, dan
(c) reasonable dalam konteks bisnis—jika data disimpan untuk customer relationship management, periode retensi harus cukup untuk maintain relationship tetapi tidak berlebihan (misalnya, 3-5 tahun untuk inactive customer).
Metodologi Penetapan Periode Retensi
Penetapan periode retensi harus dilakukan secara sistematis, bukan secara arbitrary. Metodologi yang recommended: (1) Purpose-based analysis—untuk setiap purpose pemrosesan (customer acquisition, fulfillment, service delivery, marketing, analytics), tentukan berapa lama data benar-benar diperlukan. (2) Regulatory scan—identify semua requirements regulasi yang relevan (Pajak, Ketenagakerjaan, Kesehatan, Keuangan, dll) yang mengatur minimum retention period untuk data tertentu. (3) Balancing—jika ada conflict antara purpose-based retention dan regulatory minimum, gunakan regulatory minimum (atau period yang lebih panjang jika ada legitimate reason), tetapi set expiration date yang jelas. (4) Documentation—catat untuk setiap kategori data atau setiap processing activity, berapa periode retensi dan mengapa periode itu dipilih.
Kewajiban Retensi Regulasi Berbagai Sektor
Indonesia memiliki berbagai undang-undang dan regulasi yang mengharuskan organisasi menyimpan data tertentu untuk periode minimum. Ini menciptakan complexity karena periode retensi regulasi sering lebih lama daripada periode retensi yang diperlukan untuk business purpose.
Sektor Pajak
Pasal 28 Undang-Undang No. 16 Tahun 2000 tentang Ketentuan Umum dan Tata Cara Perpajakan mengharuskan wajib pajak (termasuk perusahaan dan individu) menyimpan catatan pembukuan dan dokumen terkait selama 30 tahun untuk tax audit purposes. Ini termasuk catatan tentang customer transactions, supplier invoices, payroll records. Jika organisasi memiliki customer atau employee data yang digunakan untuk prepare tax records, maka harus menyimpan paling tidak selama 30 tahun.
Sektor Perbankan dan Keuangan
Undang-Undang No. 7 Tahun 1992 tentang Perbankan mengharuskan bank menyimpan data dan dokumen customer selama 5 tahun setelah akhir transaksi. OJK (Otoritas Jasa Keuangan) juga mengeluarkan regulasi tentang customer identification dan KYC (Know Your Customer) yang mengharuskan penyimpanan data customer untuk compliance. Untuk lembaga keuangan non-bank (FinTech, payment processor), regulasi mungkin berbeda-beda tergantung jenis layanan—organisasi harus review regulasi OJK yang relevan.
Sektor Kesehatan
Undang-Undang No. 36 Tahun 2009 tentang Kesehatan mengharuskan fasilitas layanan kesehatan (rumah sakit, klinik, praktek dokter) menyimpan rekam medis pasien selama minimum 5 tahun setelah tanggal akhir kunjungan atau pelayanan. Untuk anak-anak, beberapa interpretasi mengharuskan retention sampai anak mencapai usia 21 tahun (lebih lama dari 5 tahun). Untuk data vaksinasi, mungkin perlu disimpan lebih lama untuk record immunization lifetime.
Sektor Ketenagakerjaan
Undang-Undang No. 13 Tahun 2003 tentang Ketenagakerjaan mengharuskan employer menyimpan catatan employment (payroll, performance, leave records, termination records) selama minimum 3 tahun setelah employee meninggalkan. Regulasi tentang Kesehatan dan Keselamatan Kerja (K3) juga mengharuskan penyimpanan data terkait incident, injury, dan health data selama periode tertentu.
Sektor Telekomunikasi dan Elektronik
Undang-Undang No. 19 Tahun 2016 tentang Informasi dan Transaksi Elektronik (UU ITE) mengatur tentang penyimpanan log komunikasi elektronik untuk purposes law enforcement. Kominfo dan BRTI mungkin mengatur bahwa telco harus maintain call detail records (CDR) dan IP logs untuk retention period tertentu (biasanya 1-3 tahun).
Konflik antara Retensi Regulasi dan Kewajiban Penghapusan UU PDP
Situasi umum yang dihadapi organisasi adalah: peraturan memerlukan retention selama X tahun (misalnya, pajak 30 tahun), tetapi subjek data meminta penghapusan data mereka sebelum X tahun. Bagaimana menyelesaikan konflik ini? Jawaban: legal obligation untuk retention diakui sebagai exception dalam Pasal 8(4) dan 20 UU PDP.
Pasal 8(4) UU PDP memungkinkan pengendali data untuk tidak mematuhi permintaan penghapusan jika ada legal obligation untuk menyimpan data. Dengan kata lain, jika data harus disimpan karena Undang-Undang Pajak atau Undang-Undang Ketenagakerjaan, pengendali dapat menolak permintaan penghapusan dari subjek data dan terus menyimpan data sampai periode legal retention berakhir. Namun, pengendali masih harus:
(1) memberitahu subjek data bahwa data tidak dapat dihapus karena legal obligation,
(2) mendokumentasikan legal basis untuk retention (misalnya, reference ke Pasal 28 UU KUP), dan
(3) setelah legal obligation berakhir, hapus data dengan segera.
| KONSEP KUNCI | Legal obligation untuk retention adalah shield terhadap penghapusan request—tetapi shield ini hanya valid jika legal obligation itu benar-benar ada dan terdokumentasi dengan jelas. Organisasi tidak dapat mengklaim "legacy data yang mungkin berguna suatu hari" sebagai legal obligation. Organisasi harus mampu menunjukkan reference spesifik ke Undang-Undang atau Regulasi yang mengharuskan retention. |
Prosedur Penghapusan Data yang Aman dan Terdokumentasi
Ketika periode retensi berakhir, organisasi harus menghapus data dengan prosedur yang aman dan dapat dibuktikan. Penghapusan tidak berarti hanya "delete dari database"—database ini adalah temporary action dan data masih dapat recovered dari backup atau recovered partition. Penghapusan yang proper mencakup:
(1) Deletion dari live system—remove record dari production database.
(2) Deletion dari backup—ensure bahwa backup media yang berisi data lama juga dihapus atau overwritten setelah backup retention period ends.
(3) Secure wiping—jika media fisik (hard drive, tape) akan didaur ulang atau dibuang, harus di-securely wipe menggunakan tool yang mengoverwrite data multiple times (DOD 5220.22-M standard atau equivalent).
(4) Documentation—catat apa yang dihapus, kapan, bagaimana, dan siapa yang melakukan deletion. Audit log ini adalah bukti compliance bahwa data action sesuai dengan retensi schedule.
Untuk sensitive data atau large datasets, penghapusan dapat dilakukan in batches dengan approval dari Data Protection Officer atau authorized personnel. Untuk data tertentu yang memiliki legal importance (misalnya, employee records yang dapat digunakan untuk dispute), deletion harus dilakukan dengan care—mungkin data tidak sepenuhnya di-wipe tetapi di-archive ke cold storage yang tidak accessible untuk normal operations.
Data Retention Schedule dan Jadwal Retensi
Organisasi harus mengembangkan dan maintain formal Data Retention Schedule (Jadwal Retensi Data) yang mendokumentasikan, untuk setiap kategori data atau setiap processing activity:
(1) deskripsi data atau processing activity,
(2) purpose pemrosesan,
(3) retention period (berapa lama disimpan),
(4) legal basis untuk retention period jika terkait dengan regulatory requirement,
(5) deletion method, dan
(6) owner atau department yang bertanggung jawab untuk memastikan deletion terjadi tepat waktu.
Retention schedule ini harus:
(a) comprehensive—mencakup semua data pribadi yang diproses organisasi,
(b) specific—bukan general ("3-5 years") tetapi spesifik ("3 years from order completion for customer transaction data, 5 years from termination date for employee records"),
(c) accessible—diketahui oleh IT teams yang mengelola systems, sehingga mereka dapat implement deletion dengan akurat, dan
(d) regularly reviewed—minimal tahunan atau ketika ada perubahan regulasi atau business model.
Archiving vs. Deletion
Ada perbedaan penting antara archiving dan deletion. Archiving adalah memindahkan data dari active system ke archival storage (cold storage, offline tape) di mana data tidak diakses dalam normal operations tetapi masih tersimpan untuk potential audit atau legal discovery purposes. Deletion adalah menghapus data sepenuhnya sehingga tidak dapat diakses atau recovered.
Archiving dapat menjadi interim step—misalnya, employee data yang sudah berakhir employment dapat diarchive (tidak accessible untuk HR systems tetapi masih tersimpan untuk potential labor litigation) selama 3 tahun setelah termination, kemudian setelah 3 tahun di-delete sepenuhnya. Data yang di-archive harus tetap dilindungi dengan encryption dan access controls yang ketat—archived data tidak boleh lebih sedikit secure daripada active data.
Untuk some type of data, archiving mungkin lebih appropriate daripada immediate deletion—misalnya, financial transaction records yang disimpan untuk 10 tahun untuk potential dispute resolution, tetapi setelah 3 tahun tidak perlu accessible untuk daily operations sehingga dapat di-archive. Organisasi harus clearly indicate dalam retention schedule mana data yang langsung di-delete vs. mana yang di-archive terlebih dahulu baru kemudian di-delete.
| PENTING | Backup dan disaster recovery systems sering menjadi "hidden" source dari data yang seharusnya sudah dihapus. Jika organisasi mem-backup database daily dan menahan backup selama 6 bulan untuk disaster recovery purposes, maka data dalam backup ini juga subject to retention schedule. Jika retention period untuk certain data adalah 3 tahun, tetapi backup disimpan 6 bulan, maka data masih ada di backup medium 6 bulan lebih lama daripada expected. Organisasi harus include backup/disaster recovery systems dalam retention schedule dan planning. |
Retention Period Recommendations untuk Common Scenarios
Tabel berikut menunjukkan recommended retention periods untuk berbagai jenis data:
| Kategori Data | Business Purpose Retention | Regulatory Requirement | Recommended Total Retention |
|---|---|---|---|
| Customer transaction records | 1 year (for service) | Pajak 30 tahun | 30 years (tax requirement) |
| Customer contact/marketing | 3 years (inactive = delete) | None | 3 years + opt-out withdrawal |
| Employee payroll & benefits | 1 year post-termination | Ketenagakerjaan 3 years, Pajak 30 years | 30 years (tax requirement) |
| Medical records | During treatment + 1 year | Kesehatan 5 years | 5 years minimum (or until age 21 if child) |
| Payment card information | Transaction only | PCI-DSS (tokenize) | Do not store raw PAN; tokenize only |
| Website analytics & cookies | 3 months aggregated | None | 3 months (no personal data retention) |
| Security audit logs | 30 days (for monitoring) | Compliance 1 year | 1 year at minimum |
| Email backup/archive | 1 year active | eDiscovery 3-7 years | 3-7 years per industry/legal risk |
Automated Data Lifecycle Management
Organisasi dengan volume data besar harus mengimplementasikan automated data lifecycle management systems yang secara otomatis menghapus atau archive data ketika mencapai retention expiration date. Sistem ini harus:
(1) Be configured berdasarkan formal retention schedule,
(2) Have audit logging—record apa yang dihapus, kapan, dan hasil deletion (successful vs. failed),
(3) Have approval workflows—untuk sensitive data, deletion harus require approval dari DPO atau authorized personnel sebelum execution,
(4) Have rollback capability—dalam case deletion terjadi dengan error, sistem harus dapat restore dari backup untuk fix mistake,
(5) Be tested regularly—sebelum bulk deletion, sistem harus tested dalam staging environment untuk memastikan bahwa data yang benar dihapus dan tidak ada collateral damage.
Communication dan Compliance Checklist
Tabel berikut menunjukkan checklist untuk storage limitation compliance:
| Elemen Compliance | Requirement | Evidence/Implementation | Frequency |
|---|---|---|---|
| Retention Schedule | Documented untuk semua data categories | Formal schedule document + stakeholder approval | Annually review + update when regulation changes |
| Regulatory Compliance | Identify semua legal retention requirements | Scan undang-undang relevan + list regulations + reference to specific articles | Annually + when new regulation issued |
| Deletion Procedures | Aman dan terdokumentasi | Deletion SOP + technical procedures + secure wiping standards | Per deletion cycle + audit annually |
| Deletion Logs | Audit trail lengkap dari semua deletions | Automated logs atau manual sign-off sheets | Retain for legal defensibility |
| Backup/Archive Scope | Include dalam retention schedule | Backup retention policy + archive cold storage policy | Review when backup system changes |
| Data Subject Requests | Evaluate terhadap retention schedule | Procedure untuk handle delete requests vs. legal obligation | Per request + metrics tracking |
| DPO/Legal Review | Retention schedule reviewed oleh legal | Approval signature dari Legal Counsel + DPO | Annually + significant business changes |