Ringkasan singkat
- Keamanan aplikasi internal berarti tiga hal yang bisa diperiksa pemilik bisnis tanpa latar teknis: hanya orang yang berhak yang bisa melihat dan mengubah data, setiap perubahan penting tercatat, dan data bisa dipulihkan bila terjadi masalah.
- Risiko terbesar aplikasi internal jarang berasal dari peretas canggih. Yang lebih sering terjadi: akun mantan karyawan masih aktif, kata sandi dipakai bersama, semua orang diberi akses admin, dan backup tidak pernah diuji.
- Tanyakan delapan area ke vendor sebelum proyek dimulai: login, hak akses pengguna, enkripsi, backup dan pemulihan, audit log, pembaruan keamanan, kepemilikan akun dan server, serta penanganan data pribadi.
- Jawaban lisan tidak cukup. Kerahasiaan, akses vendor ke data asli, kepemilikan akun, cara melapor insiden, dan nasib data saat kerja sama berakhir sebaiknya tertulis.
- Sebelum data asli dimasukkan, verifikasi sendiri lewat checklist serah terima: coba login dengan peran berbeda, minta bukti uji pemulihan backup, dan lihat audit log bekerja.
Keamanan aplikasi internal perusahaan berarti memastikan hanya orang yang berhak yang bisa melihat dan mengubah data, setiap perubahan penting tercatat, dan data bisa dipulihkan bila terjadi masalah. Sebelum mempercayakan data keuangan, pelanggan, atau karyawan ke aplikasi buatan vendor, pemilik bisnis cukup memeriksa delapan area, meminta beberapa hal tertulis, dan menguji sendiri saat serah terima. Semua itu bisa dilakukan tanpa latar belakang teknis.
Artikel ini ditulis oleh Digipro, agensi digital di Malang yang membuat aplikasi custom untuk perusahaan. Pertanyaan soal keamanan sering baru muncul setelah aplikasi dipakai, padahal paling murah dijawab sebelum aplikasi dibangun. Kami menyusunnya sebagai checklist untuk pemilik dan manajer: risiko yang paling sering terjadi, pertanyaan untuk vendor, hal yang harus tertulis, kaitannya dengan UU Pelindungan Data Pribadi, langkah verifikasi saat serah terima, dan contoh ilustrasi pengaturan hak akses.
Kenapa aplikasi yang hanya dipakai tim sendiri tetap perlu aman
Banyak pemilik bisnis menganggap aplikasi internal tidak menarik bagi pihak luar karena hanya dipakai karyawan. Anggapan ini wajar, tetapi melewatkan hal penting: aplikasi internal justru menyimpan data paling berharga perusahaan dalam satu tempat. Daftar pelanggan, harga beli, tagihan, gaji, dan catatan pasien yang dulu tersebar di banyak file kini bisa dibuka dari satu halaman login. Bila halaman itu lemah, seluruh isinya ikut terbuka.
Selain itu, aplikasi web internal umumnya bisa diakses dari internet supaya tim bisa bekerja dari kantor, gudang, atau rumah. Artinya ia sama-sama terlihat dari luar seperti situs lain, walaupun alamatnya tidak dibagikan. Risiko yang paling sering terjadi pun tidak dramatis:
- Akun karyawan yang sudah keluar masih aktif berbulan-bulan, karena tidak ada yang bertugas menonaktifkannya.
- Satu akun dipakai bersama oleh beberapa orang, sehingga tidak ada yang bisa memastikan siapa mengubah apa.
- Semua pengguna diberi akses admin supaya 'tidak repot', sehingga staf baru bisa menghapus data penting tanpa sengaja.
- Kata sandi yang lemah atau sama dengan akun lain, lalu bocor dari layanan yang tidak berhubungan.
- Laptop atau ponsel yang masih login hilang atau dipinjam orang lain.
- Backup ada, tetapi tidak pernah diuji, sehingga baru ketahuan tidak lengkap saat dibutuhkan.
- Vendor atau mantan developer masih memegang akses ke server dan data asli tanpa ada yang mencatat.
Hampir semua risiko di atas bisa dicegah dengan desain aplikasi yang benar dan kebiasaan kerja yang sederhana. Karena itu keamanan aplikasi bukan urusan tim IT semata. Ia keputusan bisnis: data apa yang dilindungi, siapa yang boleh melihatnya, dan seberapa cepat perusahaan harus pulih bila terjadi masalah.
Delapan area keamanan aplikasi yang perlu ditanyakan ke vendor
Tabel berikut bisa dibawa ke rapat dengan calon vendor. Anda tidak perlu memahami detail teknisnya. Yang perlu dinilai adalah apakah vendor menjawab dengan jelas, konkret, dan bersedia menuliskannya, atau justru mengelak dengan 'tenang saja, aman'.
| Area | Artinya bagi Anda | Pertanyaan untuk vendor | Tanda jawaban yang baik |
|---|---|---|---|
| Login dan akun | Hanya pemilik akun yang bisa masuk | Bagaimana aturan kata sandi, batas percobaan login, dan sesi yang berakhir otomatis? Apakah ada verifikasi dua langkah untuk admin? | Ada aturan yang jelas, akun admin dilindungi lebih ketat, dan setiap orang punya akun sendiri |
| Hak akses pengguna | Tiap orang hanya melihat dan mengubah yang sesuai tugasnya | Peran apa saja yang ada, dan siapa yang bisa mengatur hak akses setelah aplikasi dipakai? | Peran dirancang dari alur kerja Anda, dan admin di pihak Anda bisa menambah atau menonaktifkan pengguna sendiri |
| Enkripsi | Data tidak bisa dibaca orang yang menyadap atau mencuri salinannya | Apakah koneksi memakai HTTPS? Bagaimana kata sandi disimpan? Data apa yang dienkripsi saat disimpan? | Seluruh koneksi HTTPS, kata sandi tidak disimpan dalam bentuk yang bisa dibaca, dan data sensitif mendapat perlindungan tambahan |
| Backup dan pemulihan | Data bisa dikembalikan bila terhapus atau server bermasalah | Seberapa sering backup, disimpan di mana, berapa lama disimpan, dan kapan terakhir diuji dipulihkan? | Backup otomatis, disimpan terpisah dari server utama, dan ada catatan uji pemulihan |
| Audit log | Setiap perubahan penting bisa ditelusuri | Aktivitas apa yang tercatat, siapa yang bisa melihat catatannya, dan apakah catatan bisa diubah? | Tercatat siapa, kapan, dan apa yang berubah; catatan tidak bisa diedit pengguna biasa |
| Pembaruan keamanan | Celah yang ditemukan di kemudian hari ditutup | Bagaimana komponen aplikasi dan server diperbarui, dan siapa yang bertanggung jawab setelah serah terima? | Ada jadwal pembaruan dan penanggung jawab yang jelas, bukan 'kalau ada masalah saja' |
| Kepemilikan akun dan server | Perusahaan Anda yang memegang kunci, bukan pihak lain | Atas nama siapa server, domain, database, dan akun layanan pihak ketiga? Siapa saja yang memegang aksesnya? | Atas nama perusahaan Anda, dengan daftar orang yang memegang akses |
| Data pribadi | Data pelanggan, pasien, dan karyawan diperlakukan sesuai aturan | Data pribadi apa yang disimpan, apakah semuanya perlu, dan bagaimana menghapusnya bila diminta? | Hanya data yang diperlukan yang dikumpulkan, dan ada cara menghapus atau mengekspornya |
Hak akses pengguna: mulai dari peran, bukan dari nama orang
Hak akses yang baik dirancang dari peran pekerjaan, misalnya kasir gudang, staf keuangan, manajer cabang, dan pemilik. Tiap peran diberi izin seperlunya: melihat, menambah, mengubah, menghapus, atau mengekspor data. Orang baru cukup diberi peran yang sesuai, tanpa mengatur ulang izin satu per satu. Prinsip yang dipakai sederhana: setiap orang mendapat akses sekecil mungkin yang masih cukup untuk bekerja. Dua izin yang sering diremehkan adalah menghapus dan mengekspor. Menghapus sebaiknya terbatas, dan untuk data penting lebih aman dibuat sebagai 'arsipkan' yang masih bisa dikembalikan. Ekspor ke spreadsheet sebaiknya hanya untuk peran tertentu, karena file hasil ekspor keluar dari perlindungan aplikasi. Rancangan peran ini paling mudah disusun saat menulis brief, seperti dijelaskan di artikel cara menyusun kebutuhan aplikasi.
Enkripsi, backup, dan audit log dalam bahasa sehari-hari
Enkripsi mengubah data menjadi bentuk yang tidak bisa dibaca tanpa kunci. Ada dua tempat yang perlu dilindungi. Pertama, saat data berjalan antara browser dan server, yang ditandai alamat berawalan https dan ikon gembok di browser. Kedua, saat data disimpan di server atau di file backup. Untuk kata sandi, praktik yang benar adalah menyimpannya dalam bentuk acak satu arah (hash), sehingga developer pun tidak bisa melihat kata sandi asli pengguna. Bila vendor bisa memberi tahu kata sandi Anda yang lama, itu tanda penyimpanannya keliru.
Backup adalah salinan data yang disimpan terpisah. Yang menentukan kualitasnya bukan sekadar ada atau tidak, tetapi dua pertanyaan bisnis: berapa banyak pekerjaan yang boleh hilang bila harus kembali ke backup terakhir, dan berapa lama aplikasi boleh berhenti sampai pulih. Jawaban Anda menentukan seberapa sering backup dibuat. Audit log adalah buku catatan aktivitas: siapa login, siapa mengubah harga, siapa menghapus transaksi, kapan, dan nilai sebelum serta sesudahnya. Audit log tidak mencegah kesalahan, tetapi membuat kesalahan bisa ditelusuri dan diperbaiki, serta membuat orang lebih berhati-hati karena tahu tindakannya tercatat.
Yang harus tertulis sebelum data dipercayakan
Jawaban lisan di rapat mudah berbeda ingatan setelah beberapa bulan. Hal-hal berikut sebaiknya masuk ke proposal, kontrak, atau lampirannya. Ini melengkapi isi kesepakatan perawatan yang dibahas di artikel maintenance aplikasi, dengan fokus khusus pada data.
- Kerahasiaan. Vendor dan seluruh orang yang terlibat wajib menjaga kerahasiaan data, dokumen, dan akses selama dan setelah proyek.
- Akses vendor ke data asli. Siapa di pihak vendor yang boleh membuka data asli, untuk keperluan apa, dan apakah akses itu dicabut setelah serah terima atau diatur lewat kesepakatan perawatan.
- Data uji. Selama pengembangan dipakai data contoh, bukan salinan data pelanggan asli. Bila data asli terpaksa dipakai untuk migrasi, caranya disepakati lebih dulu.
- Kepemilikan akun. Server, domain, database, dan akun layanan pihak ketiga terdaftar atas nama perusahaan Anda, dengan daftar orang yang memegang aksesnya.
- Pihak lain yang terlibat. Bila vendor memakai subkontraktor atau layanan pihak ketiga yang ikut memproses data, hal itu disampaikan dan disetujui Anda lebih dulu.
- Pelaporan insiden. Bila vendor menemukan kebocoran, akses mencurigakan, atau kehilangan data, mereka memberi tahu Anda segera lewat saluran yang disepakati, beserta apa yang terjadi dan langkah penanganannya.
- Akhir kerja sama. Bagaimana data, kode, dan akses diserahkan bila kerja sama berakhir, dan kapan salinan data di pihak vendor dihapus.
Poin kepemilikan dan ketergantungan pada satu orang dibahas lebih panjang di artikel software house vs freelancer. Bila aplikasi akan terhubung dengan WhatsApp untuk notifikasi atau penagihan, kunci akses layanan pesan juga termasuk aset yang harus atas nama perusahaan dan disimpan di server, bukan di dalam pesan chat. Pertimbangannya dijelaskan di artikel integrasi WhatsApp dengan aplikasi internal.
Kaitannya dengan UU Pelindungan Data Pribadi
Bila aplikasi menyimpan data pribadi pelanggan, pasien, atau karyawan, Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP) ikut relevan. Dalam istilah undang-undang itu, perusahaan yang menentukan tujuan pemrosesan data biasanya berperan sebagai pengendali data pribadi, sedangkan vendor yang memproses data atas perintah perusahaan dapat berperan sebagai prosesor. Beberapa ketentuan yang paling dekat dengan isi artikel ini, dicek ke teks resmi undang-undang pada 1 November 2026:
- Pengendali data wajib melindungi dan memastikan keamanan data pribadi yang diprosesnya, antara lain dengan menyusun dan menerapkan langkah teknis operasional (Pasal 35), serta mencegah data diakses secara tidak sah (Pasal 39).
- Pengendali data wajib mengawasi setiap pihak yang terlibat dalam pemrosesan data di bawah kendalinya (Pasal 37). Vendor aplikasi termasuk pihak yang perlu diawasi.
- Prosesor memproses data berdasarkan perintah pengendali, dan pemrosesan itu tetap termasuk tanggung jawab pengendali. Prosesor perlu persetujuan tertulis pengendali sebelum melibatkan prosesor lain (Pasal 51).
- Bila terjadi kegagalan pelindungan data pribadi, pengendali wajib menyampaikan pemberitahuan tertulis paling lambat 3 x 24 jam kepada subjek data dan lembaga yang berwenang (Pasal 46).
Konsekuensi praktisnya untuk pemilik bisnis: tanggung jawab atas data tidak berpindah ke vendor hanya karena aplikasinya dibuat pihak lain. Karena itu poin pelaporan insiden dan persetujuan atas pihak lain di bagian sebelumnya bukan formalitas. Tanpa pelaporan cepat dari vendor, perusahaan sulit memenuhi batas waktu pemberitahuan. Isi bagian ini bersifat informasi umum, bukan nasihat hukum. Untuk kepatuhan yang spesifik, terutama bila Anda mengelola data kesehatan atau data dalam jumlah besar, konsultasikan dengan penasihat hukum.
Checklist serah terima sebelum data asli dimasukkan
Saat aplikasi siap dipakai, jangan langsung memindahkan seluruh data asli. Sisihkan satu sesi, sebaiknya bersamaan dengan uji penerimaan pengguna, untuk memeriksa keamanan dengan tangan Anda sendiri. Urutan peran klien selama proyek, termasuk uji penerimaan, ada di artikel peran klien dalam proyek aplikasi.
- 1
Login dengan setiap peran
Minta akun uji untuk tiap peran. Masuk sebagai staf biasa dan coba buka halaman yang seharusnya tidak boleh, misalnya laporan keuangan atau pengaturan pengguna. Coba juga menyalin alamat halaman admin ke browser saat login sebagai staf. Yang benar: akses ditolak.
- 2
Uji menonaktifkan pengguna
Nonaktifkan satu akun uji, lalu coba login dengannya. Pastikan akun yang dinonaktifkan langsung tidak bisa masuk, termasuk di perangkat yang sebelumnya masih login.
- 3
Periksa aturan login
Coba kata sandi yang terlalu pendek, coba salah kata sandi beberapa kali, dan biarkan aplikasi tidak disentuh beberapa saat. Lihat apakah aturan yang dijanjikan benar berjalan.
- 4
Cek audit log
Ubah satu data uji, misalnya harga atau status transaksi, lalu minta ditunjukkan catatannya. Harus terlihat siapa, kapan, dan nilai sebelum serta sesudahnya.
- 5
Minta bukti uji pemulihan backup
Minta vendor memulihkan backup ke lingkungan uji dan menunjukkan datanya lengkap. Backup yang belum pernah dipulihkan belum terbukti bisa dipakai.
- 6
Terima daftar akses dan akun
Minta daftar tertulis semua akun penting: server, domain, database, layanan pihak ketiga, dan akun admin aplikasi, beserta pemiliknya. Ganti kata sandi akun yang selama pengembangan dipegang vendor bila memang tidak diperlukan lagi.
- 7
Pastikan data uji sudah dibersihkan
Akun uji, data contoh, dan akses sementara dihapus atau dinonaktifkan sebelum aplikasi dipakai dengan data asli.
- 8
Tetapkan admin di pihak Anda
Tunjuk satu atau dua orang di perusahaan yang memegang akses admin aplikasi dan bertugas menambah serta menonaktifkan pengguna. Jangan biarkan tugas ini hanya ada di vendor.
Checklist ini sengaja dibuat bisa dikerjakan orang non-teknis dalam satu sesi. Ia tidak menggantikan pengujian keamanan oleh tenaga ahli, tetapi menangkap kesalahan yang paling sering dan paling mahal: hak akses yang bocor, akun yang tidak bisa dicabut, dan backup yang hanya ada di atas kertas. Urutan tahap proyek secara keseluruhan bisa dilihat di artikel tahapan pembuatan aplikasi custom.
Contoh ilustrasi: mengatur hak akses di perusahaan distribusi
Contoh berikut adalah ilustrasi dengan perusahaan fiktif, bukan klien Digipro. PT Sumber Rejeki (fiktif) adalah distributor dengan satu gudang dan dua cabang penjualan. Mereka beralih dari spreadsheet bersama ke aplikasi internal untuk stok, pesanan, dan tagihan. Saat menyusun kebutuhan, pemilik menuliskan siapa mengerjakan apa, lalu vendor menerjemahkannya menjadi peran berikut.
| Peran (ilustrasi) | Melihat | Mengubah | Menghapus atau mengarsipkan | Ekspor data |
|---|---|---|---|---|
| Staf gudang | Stok dan pesanan yang harus dikirim | Jumlah stok masuk dan keluar | Tidak | Tidak |
| Staf penjualan cabang | Pelanggan dan pesanan cabangnya sendiri | Pesanan baru dan status pesanan | Tidak | Tidak |
| Staf keuangan | Tagihan dan pembayaran semua cabang | Status pembayaran dan tagihan | Mengarsipkan tagihan batal | Laporan tagihan |
| Manajer cabang | Semua data cabangnya | Harga khusus pelanggan cabangnya | Mengarsipkan pesanan cabangnya | Laporan cabangnya |
| Pemilik (admin) | Semua data | Semua data dan pengaturan pengguna | Ya, dengan konfirmasi | Semua laporan |
Dalam ilustrasi ini, tiga keputusan kecil berdampak besar. Staf cabang hanya melihat pelanggan cabangnya sendiri, sehingga daftar pelanggan lengkap tidak bisa dibawa satu orang. Hanya keuangan, manajer, dan pemilik yang bisa mengekspor laporan. Dan tidak ada yang benar-benar menghapus transaksi kecuali pemilik; yang lain hanya mengarsipkan, sehingga data masih bisa dikembalikan. Beberapa bulan kemudian, seorang staf penjualan mengundurkan diri. Manajer cabang menonaktifkan akunnya hari itu juga dari halaman pengguna, tanpa menunggu vendor. Saat ada selisih harga pada beberapa pesanan, audit log menunjukkan perubahan itu terjadi dari akun mana dan kapan, sehingga koreksinya selesai tanpa saling tuduh.
Kebiasaan di pihak perusahaan yang sama pentingnya
Aplikasi yang dirancang aman tetap bisa bocor bila kebiasaan pemakaiannya longgar. Bagian ini sepenuhnya ada di tangan Anda, bukan vendor.
- Satu orang, satu akun. Larang pemakaian akun bersama, termasuk untuk shift atau staf magang. Tanpa itu, audit log kehilangan artinya.
- Prosedur karyawan keluar. Masukkan penonaktifan akun aplikasi ke daftar serah terima karyawan yang keluar, bersama pengembalian kunci dan perangkat kantor.
- Tinjau hak akses berkala. Setiap beberapa bulan, minta admin memeriksa daftar pengguna dan perannya. Orang yang pindah tugas sering membawa hak akses lama.
- Aktifkan verifikasi dua langkah untuk akun penting, terutama admin dan keuangan, bila aplikasi menyediakannya.
- Jaga perangkat. Kunci layar ponsel dan laptop yang dipakai untuk aplikasi, dan logout dari perangkat bersama.
- Jangan kirim kata sandi atau file ekspor lewat grup chat. File hasil ekspor berisi data yang sama berharganya dengan isi aplikasi.
- Laporkan hal yang janggal. Login dari perangkat tak dikenal atau data yang berubah tanpa sebab sebaiknya segera dilaporkan ke admin dan vendor.
Cara Digipro membahas keamanan aplikasi dengan klien
Digipro adalah agensi digital berbasis di Malang, aktif sejak 2023, dan melayani perusahaan di seluruh Indonesia secara online. Kami membuat aplikasi web internal seperti sistem keuangan, katalog, manajemen klinik, dan otomasi alur kerja. Keamanan kami perlakukan sebagai bagian dari kebutuhan, bukan tambahan di akhir.
- Peran pengguna dan hak aksesnya kami susun bersama Anda dari alur kerja nyata saat merumuskan kebutuhan, sebelum aplikasi dibangun.
- Ruang lingkup, timeline, dan biaya ditulis dalam proposal sebelum pekerjaan dimulai, sehingga hal yang Anda minta soal data bisa diperiksa dan dibandingkan.
- Aplikasi dibangun bertahap dengan demo rutin. Versi pertama yang bisa dipakai tim umumnya 2–3 minggu, tergantung fitur, sehingga hak akses bisa dicoba sejak awal.
- Konsultasi pertama gratis dan tanpa kewajiban. Anda bisa membawa checklist di artikel ini dan menanyakannya langsung.
Langkah berikutnya
Bila aplikasi internal Anda sudah berjalan, mulailah dari tiga pemeriksaan hari ini: apakah masih ada akun mantan karyawan yang aktif, atas nama siapa server dan domain aplikasi, dan kapan backup terakhir diuji dipulihkan. Bila Anda sedang merencanakan aplikasi baru, bawa delapan area di atas ke rapat pertama dengan vendor dan minta jawabannya tertulis. Gambaran jalur dan cara memilih penyedia ada di artikel jasa pembuatan aplikasi untuk perusahaan, dan layanan kami dijelaskan di halaman jasa pembuatan aplikasi Digipro. Bila ingin membahas kebutuhan dan rancangan hak akses untuk perusahaan Anda, konsultasi gratis adalah cara paling ringan untuk memulai.
Pertanyaan yang sering diajukan
Apa yang dimaksud keamanan aplikasi internal perusahaan?
Keamanan aplikasi internal adalah upaya memastikan hanya orang yang berhak yang bisa melihat dan mengubah data di aplikasi perusahaan, setiap perubahan penting tercatat, dan data bisa dipulihkan bila terjadi masalah. Wujudnya antara lain aturan login, hak akses per peran, enkripsi koneksi dan data, backup yang diuji, audit log, pembaruan keamanan rutin, dan kepemilikan akun serta server atas nama perusahaan.
Apa saja yang perlu ditanyakan ke vendor soal keamanan data perusahaan?
Tanyakan delapan hal: aturan login dan verifikasi untuk admin, peran dan hak akses pengguna, penggunaan HTTPS dan cara kata sandi disimpan, jadwal backup serta kapan terakhir diuji dipulihkan, apa yang dicatat di audit log, siapa yang memperbarui keamanan setelah serah terima, atas nama siapa server dan akun, serta bagaimana data pribadi dikumpulkan dan dihapus. Minta jawabannya tertulis di proposal atau kontrak.
Apakah aplikasi internal kecil juga perlu backup dan audit log?
Ya. Backup melindungi dari hal yang sangat biasa, seperti data terhapus tanpa sengaja atau server bermasalah, dan itu bisa terjadi pada aplikasi sekecil apa pun. Audit log membantu menelusuri siapa mengubah apa saat ada selisih data, sehingga koreksi bisa dilakukan tanpa menebak. Untuk aplikasi kecil, cakupannya bisa disederhanakan, tetapi keduanya sebaiknya tetap ada sejak awal.
Apakah perusahaan tetap bertanggung jawab atas data walaupun aplikasinya dibuat vendor?
Umumnya ya. Dalam UU Pelindungan Data Pribadi, perusahaan yang menentukan tujuan pemrosesan data berperan sebagai pengendali data, dan pemrosesan oleh prosesor seperti vendor tetap termasuk tanggung jawab pengendali. Karena itu kesepakatan dengan vendor sebaiknya memuat kerahasiaan, batas akses ke data asli, dan kewajiban melapor bila terjadi insiden. Untuk kepastian hukum yang spesifik, konsultasikan dengan penasihat hukum.
Apa yang harus dilakukan saat karyawan yang memegang akses aplikasi keluar?
Nonaktifkan akunnya pada hari terakhir bekerja, sebaiknya oleh admin di pihak perusahaan tanpa menunggu vendor. Bila ia memegang akses penting seperti akun admin, server, atau layanan pihak ketiga, ganti kata sandinya dan perbarui daftar pemegang akses. Masukkan langkah ini ke prosedur serah terima karyawan keluar supaya tidak bergantung pada ingatan.
Bagikan artikel ini
Kirim ke rekan atau tim yang membutuhkannya.