Apa yang Harus Ada dalam Kontrak Pemeliharaan Aplikasi Setelah Go-Live?
Pemeliharaan aplikasi adalah pekerjaan menjaga aplikasi tetap berjalan, aman, dan relevan setelah aplikasi itu diserahkan dan dipakai pengguna. Sederhananya, go-live adalah hari pertama aplikasi hidup, sedangkan pemeliharaan adalah semua hari sesudahnya. Tulisan ini membahas arti pemeliharaan, beda garansi dan pengembangan fitur, tingkat layanan, pengaturan patching, penanganan insiden, pencadangan dan pemulihan, komponen biaya, hingga cara memeriksa vendor sebelum kontrak ditandatangani.
TLDR
Apa yang Dimaksud Pemeliharaan Aplikasi dan Mengapa Tidak Berhenti di Hari Go-Live?
Pemeliharaan adalah pekerjaan rutin yang menjaga aplikasi tetap aman, stabil, dan cocok dengan kebutuhan bisnis, dan kontraknya harus ditulis sejak awal proyek.
Apa Bedanya Garansi, Pemeliharaan Korektif, dan Pengembangan Fitur Baru?
Garansi memperbaiki cacat pada pekerjaan awal, pemeliharaan menjaga aplikasi berjalan, dan fitur baru adalah pekerjaan terpisah yang dihitung sendiri.
Berapa Tingkat Layanan yang Layak Ditulis dalam SLA?
SLA yang baik memisahkan waktu respons dari waktu penyelesaian, membagi tingkat keparahan, dan menyebut cara mengukur ketersediaan.
Bagaimana Patching dan Pemeriksaan Kerentanan Diatur dalam Kontrak?
Kontrak perlu menyebut siapa memeriksa kerentanan, seberapa sering, dan seberapa cepat celah kritis ditutup.
Siapa yang Menangani Insiden dan Seberapa Cepat?
Pembagian peran saat insiden, jalur eskalasi, dan kewajiban melapor harus tertulis sebelum insiden terjadi.
Bagaimana Pencadangan, RTO, dan RPO Ditulis agar Bisa Diuji?
Angka target pemulihan hanya berguna kalau diuji berkala dan hasilnya dilaporkan ke pemilik aplikasi.
Apa Saja Komponen Biaya Pemeliharaan Tahunan?
Biaya pemeliharaan terdiri atas jam kerja tim, infrastruktur, lisensi, dan cadangan waktu untuk pekerjaan tak terduga.
Bagaimana Memeriksa Vendor Sebelum Menandatangani Kontrak Pemeliharaan?
Periksa rekam jejak, kesiapan tim, dokumentasi, dan jalur keluar kalau hubungan dengan vendor berakhir.
Kesimpulan
Kontrak pemeliharaan yang rinci lebih murah daripada satu insiden yang tidak punya penanggung jawab.
Banyak perusahaan menghabiskan berbulan-bulan memilih vendor dan menegosiasikan harga pembuatan aplikasi, lalu menandatangani kontrak pemeliharaan dalam satu rapat singkat. Padahal aplikasi baru benar-benar diuji setelah dipakai ratusan karyawan, terhubung ke sistem lain, dan menjadi sasaran pemindaian celah keamanan dari luar. Tulisan ini menjawab kebingungan yang sering muncul pada saat itu: apa saja yang pantas ditulis dalam kontrak pemeliharaan supaya aplikasi tetap sehat, dan siapa yang bertanggung jawab ketika ada yang salah.
Apa yang Dimaksud Pemeliharaan Aplikasi dan Mengapa Tidak Berhenti di Hari Go-Live?
Pemeliharaan aplikasi adalah seluruh pekerjaan yang menjaga aplikasi tetap berjalan benar, aman, dan sesuai kebutuhan bisnis setelah diserahkan kepada pengguna. Isinya mencakup perbaikan kesalahan, pembaruan komponen, pemantauan, pencadangan, dan penanganan insiden. Pemeliharaan bukan pekerjaan tambahan yang boleh dilewati, melainkan bagian dari umur hidup aplikasi.
Ada tiga alasan pemeliharaan tidak bisa berhenti pada hari go-live. Pertama, perangkat lunak yang dipakai aplikasi, seperti sistem operasi, basis data, dan pustaka pihak ketiga, terus menerbitkan pembaruan. Aplikasi yang tidak ikut diperbarui lama-lama membawa celah yang sudah dikenal publik. Kedua, kebutuhan pengguna berubah sehingga bagian yang dulu cukup menjadi tidak cukup. Ketiga, lingkungan di sekitar aplikasi berubah: server dimigrasi, sistem lain diganti, atau jumlah pengguna naik.
Peristiwa terbaru menunjukkan mengapa pemeliharaan menjadi urusan serius. Pada 9 November 2026, Direktorat Jenderal Teknologi Pemerintah Digital Komdigi menerbitkan tiga surat imbauan sebagai tindak lanjut Security Advisory BSSN tertanggal 8 November 2026. Surat itu ditujukan kepada pengguna Pusat Data Nasional 1 (PDN-1) dan Government Cloud, pejabat pengelola nama domain instansi, serta penyelenggara sistem elektronik (PSE). Isinya meminta penguatan keamanan sistem, pemantauan aktivitas jaringan, pemeriksaan kerentanan, dan kesiapan penanganan insiden, menurut laporan Okezone dan Fortune Indonesia.
Imbauan itu ditujukan kepada instansi pemerintah dan PSE, tetapi logikanya berlaku bagi perusahaan swasta dan BUMN mana pun. Pemantauan, pemeriksaan kerentanan, dan kesiapan menangani insiden adalah pekerjaan pemeliharaan. Perusahaan yang tidak menulisnya di kontrak harus mengerjakannya sendiri atau berharap vendor mengerjakannya tanpa diminta.
Karena itu, pertanyaan pertama untuk kontrak pemeliharaan bukan soal harga, tetapi soal lingkup. Apa yang termasuk, apa yang tidak, dan siapa yang memutuskan ketika sebuah masalah berada di perbatasan antara keduanya. Bagian berikutnya membahas pembagian itu, mulai dari beda garansi dan pemeliharaan.
Satu pertanyaan sederhana membantu menguji kesiapan: kalau vendor hari ini berhenti bekerja, apakah perusahaan masih bisa menjalankan dan memperbaiki aplikasinya? Jika jawabannya tidak, pemeliharaan belum dirancang dengan benar. Pertanyaan itu mendorong perusahaan meminta dokumentasi, akses, dan serah terima pengetahuan sebagai bagian dari kontrak, bukan sebagai permintaan darurat di hari hubungan memburuk.
Apa Bedanya Garansi, Pemeliharaan Korektif, dan Pengembangan Fitur Baru?
Garansi memperbaiki cacat pada pekerjaan awal secara gratis selama periode tertentu, pemeliharaan menjaga aplikasi tetap berjalan sepanjang umur pakainya, dan pengembangan fitur baru adalah pekerjaan terpisah yang dihitung sendiri. Mencampur ketiganya adalah sumber sengketa paling sering antara perusahaan dan vendor.
Garansi biasanya berlaku untuk kesalahan yang sudah ada sejak serah terima, misalnya perhitungan yang salah atau fitur yang tidak sesuai dokumen kebutuhan. Kontrak perlu menyebut berapa lama garansi berlaku, mulai dari tanggal apa, dan apa yang membuatnya gugur. Contoh pemicu gugur yang wajar adalah perubahan kode oleh pihak lain tanpa persetujuan vendor. Contoh yang tidak wajar adalah klausul yang membatalkan garansi hanya karena perusahaan memperbarui sistem operasi server.
Pemeliharaan dibagi lagi menjadi beberapa jenis yang sebaiknya muncul sebagai butir terpisah di kontrak. Pemeliharaan korektif memperbaiki kesalahan yang muncul saat aplikasi dipakai. Pemeliharaan preventif mencegah masalah, misalnya membersihkan data lama dan menyesuaikan kapasitas. Pemeliharaan adaptif menyesuaikan aplikasi dengan perubahan lingkungan, seperti versi basis data baru atau aturan baru. Pemeliharaan perfektif menyempurnakan kinerja dan kemudahan pakai tanpa menambah fungsi besar.
Pengembangan fitur baru berbeda karena menambah kemampuan yang belum pernah ada. Pekerjaan ini idealnya memakai mekanisme permintaan perubahan dengan estimasi jam dan persetujuan tertulis. Banyak sengketa berawal dari permintaan kecil yang dianggap perusahaan sebagai perbaikan, sementara vendor menganggapnya fitur baru.
Diagram perbedaan garansi, pemeliharaan, dan fitur baru. Diolah Burung Hantu Infratek dari isi artikel ini.
Untuk menghindarinya, tulis daftar contoh di lampiran kontrak. Misalnya, perubahan label tombol masuk pemeliharaan, sedangkan penambahan modul laporan baru masuk fitur baru. Contoh konkret seperti ini lebih berguna daripada definisi abstrak, karena bisa dirujuk ketika terjadi perbedaan pendapat. Pembahasan tentang cara menilai rincian anggaran proyek ada di artikel Berapa Biaya Membangun Aplikasi Perusahaan dan Apa Saja yang Masuk Anggarannya?
Ada satu hal lagi yang layak dipikirkan sejak awal, yaitu siapa pemilik aplikasi di mata organisasi. Aplikasi yang tidak punya pemilik bisnis sering terbengkalai karena semua pihak mengira pihak lain yang mengurus. Tunjuk satu penanggung jawab dari sisi perusahaan yang menerima laporan, menyetujui permintaan perubahan, dan menandatangani hasil pekerjaan. Dengan begitu vendor punya satu pintu komunikasi, dan keputusan tidak menggantung di antara beberapa divisi yang saling menunggu.
Berapa Tingkat Layanan yang Layak Ditulis dalam SLA?
Tingkat layanan yang layak ditulis bergantung pada dampak bisnis aplikasi, bukan pada angka yang terdengar bagus. SLA yang baik memisahkan waktu respons dari waktu penyelesaian, membagi masalah menurut tingkat keparahan, dan menjelaskan cara mengukur ketersediaan serta siapa yang mengukurnya.
Perbedaan waktu respons dan waktu penyelesaian sering luput. Waktu respons adalah jarak antara laporan masuk dan vendor mulai menangani. Waktu penyelesaian adalah jarak antara laporan masuk dan masalah benar-benar beres. Vendor bisa memenuhi target respons dengan membalas pesan dalam lima menit, sementara masalahnya baru selesai tiga hari kemudian. Kedua angka harus tertulis.
Tingkat keparahan membantu menetapkan target yang masuk akal. Contoh pembagiannya adalah kritis, tinggi, sedang, dan rendah. Aplikasi yang berhenti total masuk kritis dan butuh respons paling cepat, termasuk di luar jam kerja. Tampilan yang bergeser sedikit masuk rendah dan boleh menunggu jadwal rutin. Kontrak sebaiknya memuat definisi tiap tingkat dengan contoh, serta siapa yang berhak menentukannya. Jika vendor yang menentukan sendiri, ada godaan untuk menurunkan tingkat supaya target mudah dipenuhi.
Ketersediaan biasanya dinyatakan dalam persentase waktu aplikasi dapat dipakai. Hitungannya sederhana: ketersediaan 99,9 persen sepanjang tahun berarti toleransi henti sekitar 8,76 jam, sedangkan 99 persen berarti sekitar 3,65 hari. Selisih satu angka di belakang koma itu besar. Karena itu, kontrak perlu menyebut periode pengukuran (bulanan atau tahunan), apakah pemeliharaan terjadwal dikecualikan, dan alat ukur yang dipakai.
Terakhir, SLA tanpa konsekuensi hanya menjadi dokumen niat baik. Tulis kompensasi yang proporsional bila target tidak terpenuhi, misalnya potongan biaya pemeliharaan bulan berjalan, dan tulis juga batas atasnya supaya vendor tetap sehat secara keuangan. Hak perusahaan untuk mengakhiri kontrak kalau pelanggaran berulang perlu ditulis eksplisit.
Satu pertimbangan praktis lain adalah kemampuan perusahaan sendiri. Memesan kontrak dengan pemeliharaan sepanjang waktu padahal tim internal hanya siaga pada jam kerja akan menghasilkan biaya tinggi tanpa manfaat nyata. Sebaliknya, aplikasi yang melayani pelanggan tengah malam tidak cocok dengan dukungan yang berhenti pukul lima sore. Samakan pola dukungan dengan pola pemakaian aplikasi, lalu tinjau ulang setiap tahun mengikuti perubahan jumlah pengguna dan nilai transaksinya.
Bagaimana Patching dan Pemeriksaan Kerentanan Diatur dalam Kontrak?
Kontrak perlu menyebut siapa yang memeriksa kerentanan, seberapa sering, dan seberapa cepat celah yang ditemukan ditutup. Pembaruan perangkat lunak dan pemeriksaan kerentanan berkala adalah dua pekerjaan yang paling sering dijanjikan secara lisan dan paling jarang tertulis rinci.
Dalam surat imbauan 9 November 2026, Komdigi menyebut pemeriksaan kerentanan dan peningkatan pemantauan jaringan sebagai langkah yang diminta. Katadata juga mencatat permintaan memperbarui perangkat lunak dan memperkuat autentikasi akun administrator. Sebagai konteks, Fortune Indonesia melaporkan sekitar 1,6 juta aktivitas ancaman siber tercatat di Indonesia dalam 24 jam pada 9 November 2026, dengan sektor perbankan, keuangan, dan asuransi paling banyak disasar, sekitar 761 ribu aktivitas.
Angka itu tidak berarti setiap aplikasi akan diserang hari ini, tetapi menunjukkan bahwa pemindaian dan percobaan masuk berlangsung terus-menerus. Aplikasi yang membiarkan celah lama terbuka menjadi target paling mudah. Karena itu, kontrak sebaiknya memuat jadwal pemeriksaan, misalnya pemindaian kerentanan terotomasi secara berkala dan uji penetrasi pada interval yang disepakati, lengkap dengan format laporan dan penerimanya.
Poin penting lainnya adalah tenggat penutupan celah menurut tingkat keparahan. Celah kritis, seperti yang memungkinkan pihak luar menjalankan kode di server, sepatutnya ditangani dalam hitungan hari, sedangkan celah rendah boleh masuk siklus pembaruan bulanan. Tulis juga proses uji sebelum patch dipasang di produksi, karena pembaruan yang tergesa-gesa bisa merusak fungsi yang sudah berjalan.
Perhatikan pula komponen pihak ketiga. Aplikasi modern memakai banyak pustaka sumber terbuka. Minta vendor memelihara daftar komponen yang dipakai dan memantau pengumuman celah untuk komponen itu. Ketika celah baru diumumkan, perusahaan berhak tahu apakah aplikasinya terkena, bukan menunggu kabar dari media. Bahasan kewajiban vendor di sisi keamanan siber ada di Apa yang Perlu Dipenuhi Vendor IT soal Keamanan Siber Saat RUU KKS Dibahas DPR?
Satu catatan terakhir menyangkut bukti. Laporan pemeriksaan sebaiknya memuat tanggal, cakupan sistem yang diperiksa, temuan menurut tingkat keparahan, status perbaikan, dan siapa yang menyetujui penutupan temuan. Dokumen seperti ini berguna ketika perusahaan perlu menunjukkan ketekunan kepada auditor, regulator, atau mitra bisnis yang menanyakan bagaimana keamanan aplikasi dijaga. Tanpa catatan tertulis, semua upaya itu sulit dibuktikan meski sebenarnya sudah dikerjakan.
Siapa yang Menangani Insiden dan Seberapa Cepat?
Insiden ditangani oleh tim yang namanya, peran, dan nomor kontaknya sudah tertulis sebelum insiden terjadi. Kontrak pemeliharaan perlu menjawab siapa yang pertama menerima laporan, siapa yang memutuskan mematikan layanan, siapa yang berbicara kepada pihak luar, dan dalam berapa jam insiden harus dilaporkan kepada pemilik aplikasi.
Direktur Strategi dan Kebijakan Teknologi Pemerintah Digital Kemkomdigi, Aries Kusdaryono, menyatakan, "Kita tidak boleh mengabaikan potensi risiko ancaman serangan tersebut. Karena itu, kami meminta seluruh instansi meningkatkan pengamanan sistem, memperkuat pemantauan, dan memastikan kesiapan penanganan apabila ditemukan indikasi serangan." Pernyataan itu dikutip ANTARA pada 10 November 2026 dan disampaikan untuk instansi pemerintah. Bagi perusahaan, intinya sama: kesiapan penanganan harus ada sebelum indikasi serangan muncul.
Di tingkat nasional, penanganan insiden siber punya penanggung jawab yang jelas. Peraturan BSSN Nomor 6 Tahun 2026 tentang Organisasi dan Tata Kerja BSSN, ditetapkan di Jakarta pada 5 Agustus 2026, memuat Direktorat Penanganan Insiden Siber yang bertugas di bidang operasi penanganan insiden siber, pemantauan insiden keamanan siber nasional, dan pengelolaan krisis siber nasional. Aturan itu mengatur organisasi lembaga, bukan kewajiban perusahaan, tetapi ia memperlihatkan bahwa penanganan insiden dipandang sebagai fungsi tersendiri dengan tim khusus.
Perusahaan bisa meniru pemisahan itu dalam kontrak. Tentukan pihak yang bertugas mendeteksi, pihak yang menahan dampak, pihak yang memulihkan, dan pihak yang mengomunikasikan. Pada kontrak dengan vendor, tulis kewajiban vendor menyediakan kontak darurat di luar jam kerja, jalur eskalasi bertingkat, dan laporan pascainsiden berisi kronologi, akar masalah, serta perbaikan yang dijanjikan.
Jangan lupa sisi data pribadi. Jika insiden menyangkut data pribadi, kewajiban melapor dan pembagian tanggung jawab antara pengendali dan pemroses data menjadi penting. Artikel Siapa yang Bertanggung Jawab atas Data Pribadi Saat Proyek IT Dikerjakan Vendor? membahas pembagian itu lebih jauh. Bagi perusahaan yang ingin menyiapkan tim sendiri, lihat juga Komdigi Minta Perusahaan Siapkan Tim Tanggap Insiden Usai Ancaman Agentic AI.
Latihan simulasi membantu menguji pembagian peran itu. Fortune Indonesia mencatat bahwa BSSN sendiri tengah melakukan antisipasi hingga simulasi untuk memperkuat infrastruktur digital nasional. Perusahaan bisa melakukan versi sederhananya: kumpulkan perwakilan bisnis, tim internal, dan vendor, lalu jalankan skenario seperti situs yang tampilannya berubah atau akun administrator yang dikuasai pihak luar. Catat siapa yang bingung, nomor mana yang tidak tersambung, dan perbaiki sebelum kejadian sungguhan.
Bagaimana Pencadangan, RTO, dan RPO Ditulis agar Bisa Diuji?
Pencadangan ditulis lengkap dengan dua angka target, yaitu RTO (recovery time objective, berapa lama layanan boleh mati) dan RPO (recovery point objective, berapa banyak data terakhir yang boleh hilang), lalu diuji berkala. Cadangan yang tidak pernah dicoba dipulihkan hanya asumsi.
Komdigi, menurut Katadata, menyebut pencadangan data dan mekanisme pemulihan layanan sebagai hal yang harus berjalan. Untuk perusahaan, kalimat itu perlu diterjemahkan menjadi butir kontrak yang bisa diperiksa. Apa yang dicadangkan, seberapa sering, disimpan di mana, dienkripsi atau tidak, dan siapa yang boleh mengakses salinannya.
RPO menentukan frekuensi cadangan. Jika perusahaan hanya sanggup kehilangan data satu jam terakhir, cadangan harian tidak cukup. RTO menentukan desain pemulihan. Jika layanan tidak boleh mati lebih dari empat jam, perlu server pengganti yang siap dan prosedur yang sudah dilatih. Dua angka ini harus diturunkan dari dampak bisnis, bukan dari kenyamanan teknis vendor.
Aturan praktis yang dipakai banyak tim adalah menyimpan salinan di lebih dari satu lokasi, dengan sedikitnya satu salinan terpisah dari lingkungan produksi. Alasannya sederhana: serangan yang menembus server produksi sering ikut menghapus cadangan yang tersimpan di jaringan yang sama. Kontrak boleh meminta vendor menjelaskan bagaimana salinan dipisahkan dan bagaimana akses ke sana dibatasi.
Uji pemulihan adalah bagian yang paling sering dilewati. Tulis jadwalnya, misalnya sekali dalam periode yang disepakati, dan minta laporan hasil: berapa lama pemulihan sebenarnya, data apa yang hilang, dan apa yang diperbaiki. Bila hasil uji lebih buruk daripada RTO dan RPO di kontrak, vendor perlu menyelesaikan selisihnya dalam jangka waktu tertentu. Tanpa uji, angka RTO dan RPO hanya kalimat yang menenangkan.
Keamanan cadangan sendiri patut diperhatikan. Cadangan sering berisi data lengkap, termasuk data pribadi pelanggan, sehingga perlindungannya setara dengan basis data produksi. Kontrak perlu menyebut enkripsi, pembatasan akses, dan masa simpan. Cadangan yang disimpan tanpa batas waktu menambah risiko kebocoran dan bisa bertentangan dengan kewajiban menghapus data yang sudah tidak diperlukan.
Apa Saja Komponen Biaya Pemeliharaan Tahunan?
Biaya pemeliharaan tahunan terdiri atas jam kerja tim, infrastruktur, lisensi pihak ketiga, dan cadangan waktu untuk pekerjaan tak terduga. Cara menghitung yang paling jujur adalah menguraikan keempatnya, bukan memakai satu persentase dari nilai proyek tanpa penjelasan.
Komponen pertama adalah jam kerja. Vendor menyiapkan tim yang siaga, melakukan pemantauan, menerapkan patch, dan menjawab permintaan. Skema yang umum adalah paket tetap bulanan untuk kegiatan rutin ditambah tarif per jam untuk pekerjaan di luar paket. Tanyakan berapa jam yang sudah termasuk dalam paket, bagaimana sisa jam diperlakukan, dan apakah ada batas atas biaya tambahan.
Komponen kedua adalah infrastruktur. Server, basis data, penyimpanan cadangan, dan layanan awan punya biaya berulang yang kadang terpisah dari kontrak pemeliharaan. Pastikan jelas siapa membayar apa, atas nama siapa langganannya terdaftar, dan apa yang terjadi bila kontrak berakhir. Langganan yang terdaftar atas nama vendor bisa menyulitkan perpindahan di kemudian hari.
Komponen ketiga adalah lisensi dan layanan pihak ketiga: basis data berlisensi, pengiriman pesan, peta, pembayaran, dan alat pemantauan. Harganya bisa naik di tengah jalan mengikuti kebijakan penyedia. Minta vendor mencantumkan daftar komponen berbayar beserta pemilik langganannya, dan sepakati siapa menanggung kenaikan harga.
Komponen keempat adalah cadangan untuk hal tak terduga, misalnya perbaikan mendesak, migrasi karena penyedia menghentikan layanan, atau penyesuaian karena aturan baru. Menyisihkan cadangan sejak awal mencegah perdebatan ketika kebutuhan muncul. Pembahasan struktur anggaran di sisi pembuatan aplikasi tersedia di artikel Burhan tentang biaya membangun aplikasi perusahaan, dan bisa dipakai sebagai pasangan bagi perhitungan pemeliharaan ini.
Tetapkan juga bagaimana biaya ditinjau. Kontrak jangka panjang sebaiknya punya titik evaluasi tahunan untuk menyesuaikan harga dengan perubahan beban kerja, jumlah pengguna, dan kondisi pasar, sehingga kenaikan tidak datang sebagai kejutan di akhir periode. Minta rincian tertulis setiap kali vendor mengajukan perubahan tarif.
Satu hal lagi yang kerap terlupa adalah bahwa biaya paling tidak terlihat justru berasal dari pekerjaan yang tidak disebut kontrak. Misalnya waktu staf internal untuk menguji pembaruan, menyiapkan data uji, atau menjawab pertanyaan vendor. Perkirakan beban itu sejak awal dan alokasikan orangnya. Pemeliharaan yang berjalan baik selalu melibatkan dua pihak yang sama-sama bekerja, bukan hanya vendor yang dibayar.
Bagaimana Memeriksa Vendor Sebelum Menandatangani Kontrak Pemeliharaan?
Periksa rekam jejak pemeliharaan, kesiapan tim, kualitas dokumentasi, dan jalur keluar jika hubungan berakhir. Kontrak yang rapi tidak menolong bila vendor tidak punya orang yang mampu menjalankannya, dan tidak menolong pula bila perusahaan terkunci pada vendor yang tidak mau menyerahkan apa pun.
Mulai dari rekam jejak. Minta contoh klien yang aplikasinya dipelihara vendor selama beberapa tahun, bukan hanya proyek yang baru selesai. Tanyakan bagaimana vendor menangani insiden terakhir dan apa yang berubah sesudahnya. Jawaban yang spesifik, termasuk kegagalan, biasanya lebih meyakinkan daripada jawaban yang selalu sempurna. Panduan menyeleksi vendor secara umum ada di Bagaimana Perusahaan dan BUMN Memilih Software House yang Tepat?
Berikut daftar pemeriksaan yang bisa dipakai sebelum tanda tangan:
Ketergantungan pada satu orang. Tanyakan apakah ada lebih dari satu engineer yang memahami aplikasi, dan bagaimana pengetahuan itu didokumentasikan.
Dokumentasi dan akses. Pastikan perusahaan menerima dokumentasi arsitektur, daftar akun, dan akses ke repositori kode, bukan hanya berkas aplikasi jadi.
Kepemilikan kode dan data. Tulis bahwa data milik perusahaan dan kode kustom diserahkan sesuai kesepakatan lisensi.
Rencana keluar. Sepakati bantuan peralihan ke vendor lain: waktu, format data, dan biaya bila perusahaan memutus kontrak.
Keamanan vendor sendiri. Tanyakan cara vendor mengamankan laptop, akun, dan akses jarak jauh ke sistem perusahaan.
Terakhir, pertimbangkan masa percobaan. Banyak perusahaan memulai kontrak pemeliharaan dengan periode pendek, misalnya beberapa bulan, sebelum memperpanjangnya untuk jangka lebih panjang. Periode itu memberi kesempatan menilai kecepatan respons dan kualitas laporan dengan data nyata, bukan janji presentasi.
Bagi aplikasi lama yang pemeliharaannya makin mahal, pertimbangkan juga apakah modernisasi lebih masuk akal daripada tambal sulam. Pembahasan lengkapnya ada di Panduan Modernisasi Aplikasi untuk Perusahaan dan BUMN di Indonesia, dan sisi pondasi server serta jaringannya ada di Panduan Infrastruktur IT untuk Perusahaan dan BUMN di Indonesia.
Pertanyaan terakhir sebelum menandatangani adalah apakah perusahaan sanggup memantau vendor. Kontrak sebaik apa pun butuh laporan bulanan yang dibaca, rapat tinjauan yang benar-benar dilaksanakan, dan orang internal yang berani mempertanyakan angka. Tanpa itu, pemeliharaan menjadi rutinitas pembayaran, bukan jaminan kualitas. Jadwalkan tinjauan berkala sejak bulan pertama supaya kebiasaan memeriksa terbentuk sebelum ada masalah.
Pertanyaan yang Sering Diajukan
Apa isi minimal kontrak pemeliharaan aplikasi perusahaan?
Isi minimalnya adalah lingkup pekerjaan, daftar yang dikecualikan, SLA dengan waktu respons dan penyelesaian, jadwal patching dan pemeriksaan kerentanan, prosedur insiden, target RTO dan RPO, struktur biaya, serta ketentuan serah terima jika kontrak berakhir.
Apakah garansi sudah termasuk pemeliharaan?
Tidak otomatis. Garansi memperbaiki cacat pada pekerjaan awal selama periode tertentu, sedangkan pemeliharaan menjaga aplikasi berjalan sepanjang umur pakainya. Periksa dokumen kontrak untuk memastikan batas kedua layanan itu tertulis jelas, termasuk tanggal mulai dan berakhirnya.
Seberapa sering aplikasi perlu diperiksa kerentanannya?
Frekuensinya bergantung pada risiko aplikasi. Pemindaian terotomasi bisa berjalan berkala, sedangkan uji penetrasi biasanya dilakukan pada interval yang disepakati dan setelah perubahan besar. Komdigi pada 9 November 2026 meminta pemeriksaan kerentanan sebagai bagian dari penguatan keamanan.
Siapa yang bertanggung jawab jika aplikasi diretas setelah go-live?
Tanggung jawab ditentukan oleh kontrak dan sebab insiden. Bila celah berasal dari pekerjaan vendor yang masih dijamin, vendor memperbaikinya. Bila berasal dari akun perusahaan yang lalai, tanggung jawabnya bergeser. Karena itu, pembagian peran dan batas tanggung jawab perlu ditulis sebelum insiden.
Apakah perusahaan boleh pindah vendor pemeliharaan di tengah jalan?
Boleh, selama kontrak mengatur jalur keluarnya. Pastikan ada klausul pemberitahuan, serah terima dokumentasi dan akses, serta bantuan peralihan. Tanpa itu, perusahaan bisa terkunci pada vendor lama karena tidak memegang kode, akun, atau data yang diperlukan.
Kesimpulan
Pemeliharaan aplikasi adalah bagian dari harga sebuah aplikasi, bukan biaya tambahan yang muncul belakangan. Kontrak yang baik memisahkan garansi, pemeliharaan, dan fitur baru, menuliskan SLA yang bisa diukur, mengatur patching dan pemeriksaan kerentanan, menetapkan peran saat insiden, dan menguji pemulihan secara berkala. Imbauan Komdigi pada 9 November 2026 hanyalah pengingat terbaru bahwa pekerjaan itu perlu dilakukan terus, bukan sekali.
Langkah yang bisa diambil minggu ini cukup sederhana: ambil kontrak pemeliharaan yang sedang berjalan, lalu periksa apakah delapan hal di atas sudah tertulis. Untuk setiap yang belum ada, jadwalkan pembahasan dengan vendor sebelum insiden berikutnya memaksa percakapan itu terjadi dalam kondisi darurat.
(Burung Hantu Infratek / Berbagai Sumber)
⚠️ Artikel ini seluruhnya diriset, ditulis, dan dikembangkan oleh AI internal Burung Hantu Infratek.
🦉 Burung Hantu Infratek adalah software house dan system integrator yang sudah berpengalaman lebih dari 5 tahun dalam pengembangan dan implementasi generative AI pada berbagai perusahaan dan institusi.
Sumber dan Referensi
[2] Komdigi dan BSSN Siapkan Langkah Atasi Lonjakan Serangan Siber - Fortune Indonesia
[3] Kemkomdigi mitigasi ancaman serangan siber dengan perkuat DPI - ANTARA News
[4] Komdigi Terbitkan Tiga Surat Imbauan Antisipasi Serangan Hacker ke Pemerintah - Katadata
[5] Peraturan BSSN Nomor 6 Tahun 2026 tentang Organisasi dan Tata Kerja BSSN - JDIH BPK