--- title: "Berapa Sering Website Bisnis Perlu Dipentest?" description: "Patokan frekuensi pentest website bisnis berdasarkan risiko, perubahan sistem, dan standar seperti PCI DSS, serta peran scan rutin di antara dua pentest." url: "https://nivelva.com/insight/sering-website-bisnis-perlu-dipentest" category: "Keamanan/Cyber Security" tags: ["pentest","keamanan website","pci dss","vulnerability scan","jadwal keamanan"] author: "Theresia Candiawan" published: "2026-11-07T08:57:00+07:00" updated: "2026-11-07T08:57:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Berapa Sering Website Bisnis Perlu Dipentest? > **Jawaban singkat:** Patokan umum adalah pentest minimal setahun sekali dan setiap kali ada perubahan besar, seperti yang disyaratkan PCI DSS untuk sistem pembayaran kartu. Website berisiko tinggi bisa dipentest lebih sering, sementara di antara dua pentest celah umum dipantau lewat vulnerability scan rutin. Website toko online kamu dipentest tahun lalu, temuannya sudah diperbaiki, dan laporannya tersimpan rapi. Sejak itu tim sudah menambah metode pembayaran baru, mengganti tema, memasang beberapa plugin, dan memindahkan server. Pertanyaannya: apakah hasil pentest tahun lalu masih menggambarkan website yang sekarang? Hampir pasti tidak. Pentest adalah potret keamanan pada satu waktu. Setiap perubahan kode, plugin, dan konfigurasi membuat potret itu makin usang. Karena itu frekuensi pentest sebaiknya ditentukan oleh dua hal: seberapa besar risiko website, dan seberapa sering website berubah. ## Patokan yang paling sering dipakai Bila mencari satu angka, patokan yang paling banyak dirujuk adalah **minimal sekali dalam 12 bulan, ditambah setiap kali ada perubahan signifikan**. Angka ini bukan karangan konsultan. Standar keamanan data kartu pembayaran PCI DSS versi 4 mensyaratkan pentest eksternal dan internal setidaknya sekali setiap 12 bulan dan setelah ada peningkatan atau perubahan signifikan pada infrastruktur maupun aplikasi. Standar yang sama mensyaratkan vulnerability scan internal dan eksternal setidaknya setiap tiga bulan. Kamu mungkin tidak wajib mematuhi PCI DSS, misalnya karena pembayaran kartu sepenuhnya ditangani payment gateway. Tetap saja, pola "tahunan plus setiap perubahan besar, dengan scan rutin di antaranya" adalah titik awal yang masuk akal untuk hampir semua website bisnis yang menyimpan data pelanggan. ## Menyesuaikan frekuensi dengan tingkat risiko Tidak semua website punya risiko yang sama. Profil perusahaan statis berbeda jauh dari portal pelanggan yang menyimpan data identitas. Tabel berikut bisa menjadi pegangan awal: | Profil website | Contoh | Pentest yang disarankan | Scan kerentanan | |:--|:--|:--|:--| | Informasi statis tanpa login | Profil perusahaan, landing page | Sesudah perubahan besar, atau cukup scan bila tidak ada data pengguna | Bulanan atau tiap tiga bulan | | Website dengan formulir dan CMS | Blog bisnis, website sekolah, katalog | Setahun sekali | Bulanan | | Toko online dan portal pelanggan | Checkout, akun pelanggan, riwayat pesanan | Setahun sekali dan setiap perubahan besar | Mingguan sampai bulanan | | Sistem berisiko tinggi | Pembayaran, data kesehatan, data keuangan, API untuk mitra | Dua kali setahun atau lebih, ditambah setiap perubahan besar | Mingguan, ditambah pemantauan terus-menerus | Tabel ini bukan aturan baku. Kontrak dengan klien, regulator sektor, atau standar yang kamu ikuti bisa menetapkan frekuensi sendiri, dan ketentuan tertulis itu yang harus didahulukan. Saat menentukan profil, jangan hanya melihat halaman depan. Website profil yang tampak sederhana bisa saja punya panel admin yang terbuka ke internet, formulir kontak yang menyimpan data ke database, atau subdomain lama berisi aplikasi uji coba. Daftar semua bagian yang bisa diakses dari luar, lalu tentukan profil berdasarkan bagian yang paling berisiko, bukan yang paling terlihat. Faktor lain yang menaikkan frekuensi adalah kecepatan rilis. Tim yang merilis fitur baru setiap minggu menumpuk perubahan jauh lebih cepat daripada tim yang hanya memperbarui website beberapa kali setahun. Untuk tim seperti ini, pentest terfokus beberapa kali setahun pada fitur yang baru dirilis sering lebih efektif daripada satu pentest besar di akhir tahun. ## Apa yang dihitung sebagai perubahan besar? Bagian "setiap perubahan besar" sering menjadi celah dalam jadwal karena tidak ada yang mendefinisikannya. Supaya tidak diperdebatkan setiap kali ada rilis, tetapkan daftarnya sejak awal. Contoh perubahan yang layak memicu pentest: - Menambah atau mengganti metode pembayaran, login, atau pendaftaran akun. - Membuka API baru untuk aplikasi mobile atau mitra. - Pindah platform, pindah server, atau migrasi ke cloud. - Menambah peran pengguna baru, misalnya akun reseller atau admin cabang. - Integrasi dengan sistem lain yang bertukar data pelanggan. - Desain ulang besar yang mengganti sebagian besar kode. Perubahan kecil seperti mengganti teks, gambar, atau menambah halaman artikel biasanya tidak perlu pentest penuh. Untuk perubahan menengah, pentest terbatas yang hanya menguji fitur baru sering cukup dan jauh lebih hemat daripada mengulang seluruh lingkup. ## Mengisi jeda di antara dua pentest Celah baru diumumkan hampir setiap hari, termasuk pada plugin dan CMS populer. Menunggu pentest berikutnya untuk mengetahui apakah websitemu terdampak terlalu lama. Di sinilah peran pemindaian rutin dan pemantauan. Vulnerability scan otomatis mendeteksi versi perangkat lunak yang rentan, konfigurasi yang lemah, dan celah umum. Kamu bisa memulai sendiri dengan alat terbuka, seperti dibahas di [cara scan kerentanan website dengan OWASP ZAP](https://nivelva.com/insight/cara-scan-kerentanan-website-owasp-zap). Pembaruan rutin CMS dan plugin, WAF, dan pemantauan log melengkapi lapisan berikutnya. Gambaran besarnya ada di [panduan lengkap keamanan website untuk bisnis](https://nivelva.com/insight/panduan-keamanan-website-bisnis). Pentest tetap dibutuhkan karena alat otomatis jarang menemukan celah logika, seperti pelanggan yang bisa mengubah harga di keranjang atau melihat pesanan orang lain. Dua cara ini saling melengkapi, bukan saling menggantikan. Agar jadwal ini tidak hanya rencana di atas kertas, tuliskan dalam satu dokumen sederhana: kapan pentest berikutnya, siapa penanggung jawabnya, daftar perubahan yang memicu pentest tambahan, dan frekuensi scan. Tinjau dokumen itu setiap kali ada perubahan besar di bisnis, misalnya membuka kanal penjualan baru. ## Tanda jadwal pentest perlu dipercepat Ada kondisi yang membuat jadwal tahunan sebaiknya tidak ditunggu. Misalnya ada insiden keamanan atau dugaan kebocoran data, ada laporan celah dari pengguna atau peneliti keamanan, hasil scan menunjukkan temuan kritis yang berulang, atau klien besar meminta bukti pengujian terbaru sebelum kerja sama. Pada kondisi ini, pentest terfokus pada area yang dicurigai biasanya lebih berguna daripada menunggu pengujian menyeluruh. Pentest ulang (retest) setelah perbaikan juga sebaiknya dijadwalkan langsung, bukan menunggu siklus berikutnya. Tanpa retest, kamu tidak benar-benar tahu apakah celah sudah tertutup. Retest biasanya jauh lebih singkat daripada pentest penuh karena hanya memeriksa temuan yang sudah diperbaiki, sehingga tidak ada alasan untuk menundanya. ## Ringkasan Untuk kebanyakan website bisnis, jadwal yang masuk akal adalah pentest setahun sekali, pentest tambahan setiap ada perubahan besar, dan vulnerability scan rutin di antaranya. Naikkan frekuensinya bila website menangani pembayaran atau data sensitif, dan ikuti ketentuan tertulis dari klien atau regulator bila ada. Yang terpenting, definisikan "perubahan besar" sejak awal supaya jadwal itu benar-benar dijalankan. ## Sumber - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/sering-website-bisnis-perlu-dipentest Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com