Sistem informasi

NDA dan SoW dalam Kontrak Software House: Isi Penting dan Cara Menyusunnya

NDA menjaga kerahasiaan, SoW mengunci ruang lingkup. Keduanya mencegah sengketa paling umum dalam proyek aplikasi: pekerjaan yang tidak sesuai harapan.

R Tim Rajonet Diperbarui 12 November 2026 4 menit baca

NDA dan SoW adalah dua dokumen yang paling sering menentukan apakah proyek aplikasi berjalan mulus atau berakhir dengan sengketa. NDA (Non Disclosure Agreement) menjaga kerahasiaan informasi yang Anda bagikan kepada software house. SoW (Statement of Work) merinci pekerjaan yang akan dibuat, hasil yang diserahkan, jadwal, dan cara menilai bahwa pekerjaan sudah selesai.

Poin penting

  • NDA melindungi informasi; SoW melindungi hasil proyek dan anggaran.
  • SoW yang baik memuat ruang lingkup, hal yang tidak termasuk, hasil serahan, jadwal, dan kriteria penerimaan.
  • Cantumkan kepemilikan source code, garansi, dan prosedur perubahan ruang lingkup secara tertulis.
  • Bila sistem mengolah data pribadi, atur juga peran pengendali dan pemroses data sesuai UU PDP.

Mengapa dua dokumen ini penting

Sebagian besar perselisihan dalam proyek aplikasi bukan karena programmer tidak mampu, tetapi karena kedua pihak membayangkan hasil yang berbeda. Klien merasa fitur tertentu sudah termasuk, vendor merasa itu pekerjaan tambahan. SoW yang rinci mencegah hal ini sejak awal. Sementara itu, NDA memberi rasa aman bagi klien untuk membagikan alur internal, data contoh, atau rencana bisnis yang dibutuhkan agar analisis kebutuhan akurat.

Di Indonesia, perjanjian sah bila memenuhi syarat Pasal 1320 KUHPerdata: kesepakatan para pihak, kecakapan, objek tertentu, dan sebab yang halal. SoW yang jelas membantu memenuhi unsur objek tertentu, karena pekerjaan yang diperjanjikan menjadi terukur.

Isi NDA yang perlu ada

  • Definisi informasi rahasia: misalnya data, dokumen, alur kerja, kode, dan strategi, termasuk yang disampaikan secara lisan.
  • Pengecualian: informasi yang sudah publik atau sudah diketahui penerima sebelumnya.
  • Kewajiban penerima: hanya dipakai untuk proyek, dibatasi kepada personel yang perlu tahu.
  • Jangka waktu: berapa lama kewajiban kerahasiaan berlaku, termasuk setelah proyek selesai.
  • Pengembalian atau pemusnahan: apa yang terjadi pada data dan dokumen saat kerja sama berakhir.
  • Akibat pelanggaran: ganti rugi dan forum penyelesaian sengketa.

Isi SoW yang perlu ada

  1. Latar belakang dan tujuan: masalah yang ingin diselesaikan dan ukuran keberhasilannya.
  2. Ruang lingkup: daftar modul dan fitur, jumlah peran pengguna, integrasi, dan platform (web, Android, iOS).
  3. Di luar ruang lingkup: hal yang tegas tidak termasuk, misalnya input data massal, pengadaan server, atau konten tulisan.
  4. Hasil serahan: aplikasi, source code, dokumentasi teknis, panduan pengguna, akun admin, dan materi pelatihan.
  5. Jadwal dan tahapan: milestone yang dikaitkan dengan termin pembayaran.
  6. Kriteria penerimaan: skenario uji yang harus lulus saat user acceptance test.
  7. Garansi dan dukungan: lama garansi perbaikan bug dan apa yang termasuk di dalamnya.
  8. Prosedur perubahan: cara mengajukan, menghitung, dan menyetujui perubahan ruang lingkup.

Kepemilikan source code dan hak kekayaan intelektual

Pastikan kontrak menyebutkan siapa pemilik source code setelah proyek selesai. Untuk proyek kustom, praktik yang sehat adalah source code dan aset diserahkan kepada klien setelah pelunasan, kecuali komponen pihak ketiga yang memiliki lisensinya sendiri. Minta juga daftar pustaka atau komponen pihak ketiga yang dipakai beserta lisensinya, agar tidak ada biaya tersembunyi di kemudian hari.

Perlindungan data pribadi

Bila aplikasi mengolah data pribadi, misalnya data pegawai, mahasiswa, atau pasien, kontrak perlu mengatur siapa pengendali data dan siapa pemroses data. Biasanya klien adalah pengendali dan software house adalah pemroses yang hanya boleh mengolah data sesuai instruksi. Atur juga keamanan data uji, akses ke server produksi, dan pemberitahuan bila terjadi insiden. Penjelasan lebih lengkap ada di artikel UU PDP untuk sistem informasi.

Kesalahan umum yang perlu dihindari

  • SoW hanya berisi daftar judul modul tanpa rincian fitur dan aturan bisnis.
  • Tidak ada bagian di luar ruang lingkup, sehingga semua hal dianggap termasuk.
  • Kriteria penerimaan tidak tertulis, sehingga proyek tidak pernah dianggap selesai.
  • Termin pembayaran tidak dikaitkan dengan hasil yang bisa diperiksa.
  • NDA disalin dari templat tanpa menyesuaikan jenis informasi yang benar benar dibagikan.

Untuk instansi pemerintah

Pada pengadaan instansi, dokumen setara SoW biasanya berupa Kerangka Acuan Kerja (KAK) dan spesifikasi teknis, sedangkan kontrak mengikuti ketentuan pengadaan barang dan jasa yang berlaku. Prinsipnya tetap sama: ruang lingkup, hasil serahan, dan kriteria penerimaan harus terukur. Lihat panduan pengadaan aplikasi pemerintah.

Langkah praktis sebelum tanda tangan

Mintalah draf SoW dari calon vendor setelah analisis kebutuhan, lalu baca bersama pengguna kunci, bukan hanya bagian pengadaan. Tandai setiap kalimat yang bisa ditafsirkan berbeda dan minta diperjelas. Bila perlu, libatkan penasihat hukum untuk klausul kerahasiaan dan ganti rugi. Rajonet menuangkan ruang lingkup, jadwal, dan termin dalam Surat Perjanjian Kerja setelah analisis kebutuhan yang tidak dipungut biaya; ceritakan kebutuhan Anda melalui halaman kontak.

Pertanyaan yang sering diajukan

Apa beda NDA dan SoW?

NDA (perjanjian kerahasiaan) mengatur informasi apa yang wajib dirahasiakan dan berapa lama. SoW (pernyataan lingkup kerja) mengatur apa yang dikerjakan, hasil yang diserahkan, jadwal, dan kriteria penerimaan. NDA melindungi informasi, SoW melindungi hasil proyek.

Kapan NDA sebaiknya ditandatangani?

Sebelum Anda membagikan informasi sensitif, misalnya data contoh, alur internal, atau dokumen strategi. Untuk analisis kebutuhan awal yang bersifat umum, NDA biasanya belum diperlukan.

Apakah SoW sama dengan SPK atau kontrak?

Tidak persis. SPK atau kontrak adalah dokumen hukum utama yang memuat para pihak, nilai, dan pembayaran. SoW biasanya menjadi lampiran yang merinci pekerjaan teknisnya. Keduanya saling melengkapi.

Bagaimana jika ada permintaan fitur di luar SoW?

Gunakan prosedur permintaan perubahan: fitur baru dicatat, dihitung dampaknya terhadap biaya dan jadwal, lalu disetujui tertulis sebelum dikerjakan. Cara ini menjaga hubungan baik dan anggaran tetap terkendali.

Bermanfaat? Bagikan ke rekan yang membutuhkan