Data Wajib Pajak di Tangan Pihak Ketiga: Klausul keamanan apa yang layak diminta?
Banyak organisasi membahas kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden ketika masalah sudah berada di meja CFO. Dalam review berkala, padahal sebagian besar risiko lahir dari pembagian peran dan data yang tidak pernah dibuat terang sejak awal.
Pada kondisi tersebut, bagi pembaca ePajak.or.id, isu ini perlu dibaca sebagai keputusan operasional pada area terkait. Data Wajib Pajak di Tangan Pihak Ketiga bukan sekadar istilah layanan atau dokumen. Dalam praktik, ia menentukan siapa yang mempunyai informasi, kapan risiko dinaikkan, dan apakah perusahaan atau orang pribadi masih mampu menjelaskan pilihannya beberapa bulan kemudian.
Tentukan pertanyaan sebelum membeli jawaban
Untuk kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, pertanyaan awal harus menyebut transaksi, periode, pihak, nilai, sistem, dan hasil yang ingin dicapai. Secara operasional, permintaan yang hanya berbunyi ‘tolong dicek’ menghasilkan scope kabur pada area terkait. Pada tahap ini, scope kabur membuat tim internal dan penasihat mengira pihak lain sudah mengerjakan area yang sebenarnya belum pernah disentuh pada area terkait.
Definisikan data dan tujuan
Definisikan data dan tujuan sebaiknya dimulai dari fakta yang lahir di proses bisnis, bukan dari jawaban yang sudah ingin dibenarkan. Untuk menguji definisikan data dan tujuan, pilih satu contoh aktual dan minta PIC menunjukkan jejaknya tanpa menyiapkan folder khusus lebih dulu. Data yang lengkap tidak otomatis menyelesaikan definisikan data dan tujuan bila data itu berasal dari cut-off, definisi, atau versi yang berbeda.
Perbaikan definisikan data dan tujuan dapat dimulai dengan menyusun matriks fakta, asumsi, pilihan, dan risiko yang berkaitan dengan definisikan data dan tujuan, disertai satu owner yang mampu meminta data lintas fungsi. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, setiap koreksi data harus meninggalkan bridge antara versi awal dan final beserta alasan perubahannya. Jika manajemen menerima risiko definisikan data dan tujuan, alasan dan masa berlakunya perlu dicatat agar penerimaan itu tidak menjadi izin permanen.
Least privilege menjadi kewajiban
Sebelum memilih langkah untuk least privilege menjadi kewajiban, wajib pajak perlu mengetahui hasil apa yang dibutuhkan dan batas apa yang tidak boleh dilewati. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, kalender kerja harus menampilkan tenggat resmi, tenggat internal, waktu review, serta ruang untuk memperbaiki data. Untuk kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, ketergantungan pada satu individu merupakan risiko kontinuitas sekalipun individu tersebut sangat kompeten.
Agar perubahan dapat diuji, tim perlu membandingkan kondisi saat ini dengan standar yang disepakati untuk least privilege menjadi kewajiban serta menetapkan kondisi PASS sebelum bukti hasil diperiksa. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, screenshot saja tidak cukup bila tidak terlihat identitas akun, waktu, objek tindakan, dan hasil sistem. Ukuran penutupan least privilege menjadi kewajiban adalah kemampuan tim menjelaskan tindakan dan buktinya, bukan hilangnya pertanyaan dari daftar rapat.
Lokasi dan masa simpan data
Lokasi dan masa simpan data perlu diperlakukan sebagai rangkaian keputusan, bukan tiket kerja yang selesai ketika file dikirim. Tim dapat mengubah lokasi dan masa simpan data menjadi decision table yang membandingkan pilihan, syarat, biaya internal, risiko, dan reversibilitas. Ketiadaan batas pada lokasi dan masa simpan data juga membuka ruang bagi pekerjaan di luar scope tanpa review, biaya, atau otorisasi yang jelas.
Pemilik proses sebaiknya menutup gap lokasi dan masa simpan data melalui tindakan berurutan yang dapat diverifikasi dan menjelaskan hambatan yang membuat kontrol lama tidak berjalan sebagaimana desainnya. Bukti operasi lokasi dan masa simpan data bukan keberadaan SOP, melainkan sampel yang menunjukkan langkah, review, dan eskalasi benar-benar terjadi. Jangan menutup lokasi dan masa simpan data hanya karena dokumen sudah dikirim; tutup setelah penerima memahami implikasi dan tindakan berikutnya.
Enkripsi dan kanal transfer
Pada enkripsi dan kanal transfer, pertanyaan ‘siapa yang mengerjakan’ belum cukup karena ownership data dan ownership risiko bisa berada pada orang berbeda. Dalam konteks kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, satu issue list bersama mencegah tim internal dan penasihat bekerja dengan versi masalah yang berbeda. Masalah enkripsi dan kanal transfer tidak selalu menghasilkan salah hitung, tetapi sering mengurangi kemampuan wajib pajak menjelaskan posisi secara konsisten.
Tim dapat membuat daftar bukti untuk enkripsi dan kanal transfer dan menguji satu sampel sebelum pekerjaan diperluas; hasilnya harus menunjukkan gap, dampak, dan tindakan koreksi, bukan hanya status lengkap atau belum lengkap. Dokumen final enkripsi dan kanal transfer harus dapat dibaca pengambil keputusan tanpa menghilangkan jalur menuju analisis yang lebih rinci. Hasil review enkripsi dan kanal transfer perlu berakhir pada keputusan, owner, tenggat, serta risiko tersisa yang secara sadar diterima.
Subprosesor perlu persetujuan
Ukuran sehat untuk subprosesor perlu persetujuan bukan banyaknya aktivitas, melainkan apakah risiko penting ditemukan pada waktu yang masih memungkinkan koreksi. Dokumen kerja untuk subprosesor perlu persetujuan sebaiknya menunjukkan sumber dan transformasi data agar reviewer dapat melakukan drill-down. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, keputusan yang tidak memiliki jejak akan sulit dibedakan dari pembenaran yang dibuat setelah hasil diketahui.
Perbaikan subprosesor perlu persetujuan dapat dimulai dengan menetapkan owner, reviewer, tenggat, serta keluaran minimum untuk subprosesor perlu persetujuan, disertai satu owner yang mampu meminta data lintas fungsi. Untuk kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, evidence index yang ringkas lebih berguna daripada folder besar tanpa penamaan, versi, dan hubungan antarberkas. Perbedaan pendapat atas subprosesor perlu persetujuan perlu diterjemahkan menjadi fakta tambahan atau keputusan risk appetite, bukan dibiarkan sebagai dua memo.
Notifikasi insiden memiliki batas waktu
Ketika membahas notifikasi insiden memiliki batas waktu, tim perlu memisahkan syarat formal, kebutuhan operasional, dan keputusan yang masih terbuka. Kronologi pada notifikasi insiden memiliki batas waktu perlu menghubungkan kejadian bisnis, dokumen, pencatatan, pembayaran, pelaporan, serta komunikasi penting. Risiko notifikasi insiden memiliki batas waktu membesar ketika akses, kewenangan, dan tanggung jawab diperlakukan sebagai satu hal yang sama.
Agar perubahan dapat diuji, tim perlu menyusun matriks fakta, asumsi, pilihan, dan risiko yang berkaitan dengan notifikasi insiden memiliki batas waktu serta menetapkan kondisi PASS sebelum bukti hasil diperiksa. Retensi bukti notifikasi insiden memiliki batas waktu perlu mengikuti kebutuhan hukum dan bisnis, bukan umur inbox orang yang kebetulan menjadi PIC. Keputusan mengenai notifikasi insiden memiliki batas waktu sebaiknya ditinjau ulang saat fakta, regulasi, sistem, pihak, atau tujuan bisnis berubah.
Hak audit dan bukti kontrol
Hak audit dan bukti kontrol bukan pekerjaan satu fungsi apabila sumber faktanya tersebar di finance, legal, operasi, atau pihak eksternal. Sebelum hak audit dan bukti kontrol ditutup, lakukan walk-through dari dokumen asal sampai keluaran akhir bersama orang yang tidak menyusun analisis. Kelemahan pada hak audit dan bukti kontrol biasanya baru terlihat ketika PIC berganti atau pihak luar meminta bukti yang tidak ada di memo final.
Pemilik proses sebaiknya membandingkan kondisi saat ini dengan standar yang disepakati untuk hak audit dan bukti kontrol dan menjelaskan hambatan yang membuat kontrol lama tidak berjalan sebagaimana desainnya. Dokumentasi hak audit dan bukti kontrol sebaiknya memuat bukti yang mendukung sekaligus fakta yang berpotensi melemahkan kesimpulan. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, keputusan final tetap berada pada wajib pajak meskipun analisis, administrasi, atau komunikasi dikerjakan pihak lain.
Pengembalian serta pemusnahan
Kualitas pengembalian serta pemusnahan bergantung pada hal yang sering tidak terlihat, yaitu versi data, urutan kejadian, dan alasan di balik persetujuan. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, dependency eksternal harus diberi nama karena kata ‘menunggu’ tidak menjelaskan siapa yang harus bergerak. Jika langkah tersebut dilewati, pengembalian serta pemusnahan dapat tampak selesai meskipun asumsi utama belum pernah diuji oleh pemilik fakta.
Tim dapat menutup gap pengembalian serta pemusnahan melalui tindakan berurutan yang dapat diverifikasi; hasilnya harus menunjukkan gap, dampak, dan tindakan koreksi, bukan hanya status lengkap atau belum lengkap. Jika dokumen pengembalian serta pemusnahan berasal dari pihak ketiga, simpan juga bukti penerimaan, pemeriksaan, dan tindak lanjut atas kekurangannya. Pada kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, keputusan yang baik boleh berbeda dari rekomendasi penasihat selama alasannya dipahami dan konsekuensinya disiapkan.
Tanggung jawab saat kontrak berakhir
Kesalahan membaca tanggung jawab saat kontrak berakhir biasanya dimulai ketika satu dokumen dianggap mewakili seluruh kronologi dan substansi transaksi. Untuk kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, buat peta singkat berisi pihak, periode, jenis tindakan, sumber angka, serta dependency sebelum analisis dimulai. Tanpa pemetaan itu, tanggung jawab saat kontrak berakhir mudah berubah menjadi pekerjaan reaktif yang hanya memindahkan pertanyaan dari satu meja ke meja lain.
Perbaikan tanggung jawab saat kontrak berakhir dapat dimulai dengan membuat daftar bukti untuk tanggung jawab saat kontrak berakhir dan menguji satu sampel sebelum pekerjaan diperluas, disertai satu owner yang mampu meminta data lintas fungsi. Bukti untuk tanggung jawab saat kontrak berakhir perlu memiliki tanggal, sumber, versi, pemilik, dan hubungan dengan keputusan yang diambil. Bila bukti belum memadai, status tanggung jawab saat kontrak berakhir seharusnya ‘belum dapat diputuskan’, bukan dipaksa menjadi aman atau tidak aman.
Bawa empat angka ke meja keputusan
Untuk kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, ringkas empat hal: nilai atau eksposur, jam kerja internal, tenggat yang tidak dapat dipulihkan, dan jumlah dependency terbuka. Dalam pengujian, empat angka ini membuat keputusan lebih konkret daripada label risiko tinggi atau rendah pada pekerjaan tersebut.
Tambahkan satu daftar unknowns pada definisikan data dan tujuan. Dari sisi tata kelola, unknown bukan kelemahan memo selama diberi owner dan cara memperoleh jawaban pada pekerjaan tersebut. Untuk pekerjaan ini, menyembunyikan unknown justru menciptakan kepastian palsu yang sulit dikoreksi setelah tindakan berjalan pada pekerjaan tersebut.
Review setelah tiga puluh hari
Tiga puluh hari setelah keputusan kontrol kontraktual dan operasional atas akses, penyimpanan, subprosesor, serta insiden, bandingkan asumsi awal dengan hasil aktual. Di tingkat pelaksana, periksa biaya internal, kualitas data, respons pihak luar, dan apakah kontrol tambahan benar-benar dipakai pada pekerjaan tersebut.
Bagi pengambil keputusan, jika hasil berbeda, revisi proses serta decision note pada pekerjaan tersebut. Tujuan review bukan mencari siapa yang salah, melainkan memperbaiki cara organisasi membaca tanggung jawab saat kontrak berakhir. Dalam review berkala, keputusan yang baik meninggalkan sistem belajar, bukan hanya file final pada pekerjaan tersebut.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Topik: Coretax DJP
- Indeks: Coretax
- Panduan: Panduan Coretax DJP
- Evidence: Administration Source Map
- Artikel terkait: Engagement Letter Pajak: Scope, limitation, dan tanggung jawab jangan cuma formalitas
