Enterprise dapat membangun security control internal yang kuat tetapi tetap mempunyai cyber risk yang besar jika critical business process bergantung pada pihak ketiga. Cloud provider menjalankan infrastructure, SaaS menyimpan data pelanggan, payment gateway memproses transaksi, logistics partner menerima data order, managed service provider mempunyai privileged access, sementara berbagai API menghubungkan system internal dengan platform di luar boundary perusahaan. Semakin terhubung operating model sebuah enterprise, semakin sulit pula menganggap cybersecurity sebagai sesuatu yang berhenti di infrastructure milik sendiri.<\/p>\n\n\n\n
Problemnya bukan bahwa menggunakan vendor atau SaaS merupakan keputusan yang salah. Sebaliknya, third-party technology memungkinkan perusahaan memperoleh capability lebih cepat, mengurangi operational burden, dan memanfaatkan specialization yang mungkin mahal jika dibangun sendiri. Risiko muncul ketika business dependency tumbuh lebih cepat daripada visibility dan governance terhadap pihak yang menerima akses, data, atau peran penting dalam business process<\/strong>.<\/p>\n\n\n\n NIST melalui Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations<\/a> menempatkan supply-chain cybersecurity sebagai bagian dari enterprise risk management. Guidance tersebut menyoroti bahwa organisasi sering memiliki visibility dan control yang lebih rendah terhadap bagaimana technology yang mereka beli dikembangkan, diintegrasikan, dioperasikan, dan diamankan sepanjang supply chain. NIST<\/a><\/p>\n\n\n\n Ini mengubah pertanyaan yang perlu diajukan management. Bukan hanya \u201capakah vendor ini secure?\u201d<\/strong>, tetapi \u201cbusiness process apa yang bergantung pada vendor ini, akses apa yang kita berikan, data apa yang berpindah, apa yang terjadi jika vendor compromised atau unavailable, dan seberapa cepat kita dapat membatasi dampaknya?\u201d<\/strong><\/p>\n\n\n\n Third-party cyber risk sering diasosiasikan dengan satu scenario: vendor terkena data breach kemudian data pelanggan perusahaan ikut terekspos. Scenario tersebut memang penting, tetapi cakupan risikonya jauh lebih luas.<\/p>\n\n\n\n SaaS provider dapat unavailable sehingga operation berhenti. API partner dapat compromised dan digunakan sebagai jalur masuk ke system internal. Managed service provider dapat mempunyai credential dengan privilege terlalu besar. Software component dari supply chain dapat membawa vulnerability ke application. Vendor dapat mempunyai subcontractor yang juga memperoleh akses terhadap data perusahaan. Bahkan tanpa serangan siber, perubahan konfigurasi atau kegagalan service pihak ketiga dapat menghentikan critical process jika enterprise tidak mempunyai alternative path.<\/p>\n\n\n\n NIST SP 800-161 memperluas supply-chain risk hingga product dan service yang digunakan organization sepanjang lifecycle, termasuk risiko dari development practice, supplier, component, integration, dan service dependency. Pendekatan tersebut penting karena modern enterprise tidak benar-benar memiliki security perimeter yang sederhana; sebagian capability bisnis selalu bergantung pada entity di luar direct control. NIST<\/a><\/p>\n\n\n\n Karena itu, third-party risk bukan sekadar vendor problem<\/strong>. Ia adalah risk yang muncul ketika business outcome perusahaan bergantung pada capability, security, availability, data handling, atau response capability dari pihak lain.<\/p>\n\n\n\n Banyak perusahaan mempunyai vendor list, tetapi tidak semuanya mempunyai dependency map<\/strong>. Procurement mengetahui siapa vendor-nya, finance mengetahui nilai kontrak, IT mengetahui aplikasi yang digunakan, dan security mengetahui beberapa external access. Informasi tersebut sering berada di tempat berbeda dan belum membentuk satu picture mengenai vendor mana yang benar-benar kritis bagi bisnis.<\/p>\n\n\n\n Dua vendor dengan contract value yang sama dapat mempunyai cyber-risk profile yang sangat berbeda. Vendor pertama menyediakan software training internal tanpa sensitive data. Vendor kedua menyediakan identity service yang digunakan ribuan user untuk mengakses core applications. Contract value tidak cukup menjelaskan criticality.<\/p>\n\n\n\n Hal yang sama berlaku pada ukuran vendor. Provider besar belum tentu selalu lebih critical daripada vendor kecil. Sebuah niche provider dapat menjalankan satu integration yang tanpanya invoice tidak dapat diproses. Dari procurement perspective nilainya mungkin kecil, tetapi dari business continuity perspective dependency-nya tinggi.<\/p>\n\n\n\n NIST Cybersecurity Framework 2.0 secara eksplisit meminta organisasi mengetahui supplier dan memprioritaskannya berdasarkan criticality<\/strong>, melakukan due diligence sebelum relationship dimulai, memahami dan memonitor risk selama relationship berjalan, serta memasukkan relevant third parties ke incident response dan recovery planning. NIST CSF 2.0 C-SCRM Quick-Start Guide<\/a> memberikan panduan khusus untuk membangun capability tersebut. NIST<\/a><\/p>\n\n\n\n Karena itu, vendor inventory sebaiknya dikembangkan menjadi:<\/p>\n\n\n\n Business Process \u2192 Third-Party Dependency \u2192 Service \/ Data \/ Access \u2192 Criticality \u2192 Failure Impact<\/strong><\/p>\n\n\n\n Barulah security priority menjadi lebih jelas.<\/p>\n\n\n\n Dalam working framework Crocodic, third-party cyber risk dapat dianalisis melalui chain berikut:<\/p>\n\n\n\n Critical Business Process \u2192 Third-Party Dependency \u2192 Access \/ Data \/ Integration Exposure \u2192 Failure or Compromise Scenario \u2192 Business Impact \u2192 Existing Control \u2192 Residual Risk \u2192 Treatment \u2192 Continuous Monitoring \u2192 Exit & Recovery<\/strong><\/p>\n\n\n\n Framework dimulai dari Critical Business Process<\/strong>. Apa yang perusahaan harus tetap mampu lakukan: menerima order, melakukan pembayaran, menjalankan production, melayani customer, memproses claim, mengakses employee data, atau menjalankan financial closing?<\/p>\n\n\n\n Berikutnya, petakan Third-Party Dependency<\/strong>. Siapa pihak eksternal yang memungkinkan process tersebut berjalan? SaaS, cloud provider, payment provider, API partner, software vendor, outsourced development team, managed infrastructure, logistics platform, atau service provider lainnya.<\/p>\n\n\n\n Kemudian lihat Access \/ Data \/ Integration Exposure<\/strong>. Vendor yang hanya menerima public information mempunyai exposure berbeda dari vendor yang memperoleh administrator access, menyimpan personal data, atau mempunyai persistent API connection ke core system.<\/p>\n\n\n\n Setelah itu, enterprise membuat Failure or Compromise Scenario<\/strong> dan menerjemahkannya menjadi Business Impact<\/strong>. Barulah Existing Control dan Residual Risk dievaluasi sebelum Treatment ditentukan. Karena relationship terus berubah, risk kemudian masuk ke Continuous Monitoring dan akhirnya Exit & Recovery.<\/p>\n\n\n\n Framework ini sengaja dimulai dari bisnis.<\/p>\n\n\n\n Vendor tidak menjadi high risk hanya karena ia vendor teknologi. Vendor menjadi high risk ketika kegagalan atau compromise-nya dapat menghasilkan business impact yang besar.<\/strong><\/p>\n\n\n\n Salah satu indikator third-party risk yang paling penting adalah apa yang dapat dilakukan vendor di environment perusahaan<\/strong>.<\/p>\n\n\n\n Sebagian third party hanya menggunakan portal yang disediakan company. Sebagian mendapat API credential. Sebagian memiliki remote access untuk maintenance. Sebagian bahkan mempunyai privileged administrator account karena bertanggung jawab menjaga infrastructure atau application.<\/p>\n\n\n\n Semakin besar privilege, semakin besar potential blast radius jika credential vendor dicuri atau account disalahgunakan.<\/p>\n\n\n\n Karena itu, assessment sebaiknya tidak berhenti pada pertanyaan apakah vendor mempunyai ISO certification, penetration-test report, atau security policy. Enterprise juga perlu mengevaluasi access architecture di sisi sendiri.<\/p>\n\n\n\n Apakah vendor menggunakan shared account? Apakah MFA diwajibkan? Apakah access hanya aktif ketika dibutuhkan? Apakah privilege dibatasi berdasarkan task? Apakah activity tercatat? Apakah credential dapat segera dicabut ketika contract selesai? Apakah vendor dapat mengakses production dan backup environment sekaligus?<\/p>\n\n\n\n Prinsip ini berkaitan dengan Zero Trust untuk sistem enterprise<\/a>. Trust terhadap partner bisnis tidak seharusnya otomatis diterjemahkan menjadi unrestricted technical trust. Access tetap perlu mengikuti identity, authorization, context, dan least-privilege principle.<\/p>\n\n\n\n Dalam third-party risk, pertanyaannya bukan hanya \u201capakah kita percaya vendornya?\u201d<\/strong>, tetapi \u201cseberapa besar damage yang mungkin terjadi jika trust tersebut suatu hari tidak dapat digunakan sebagai assumption?\u201d<\/strong><\/p>\n\n\n\n SaaS mengurangi banyak responsibility yang sebelumnya berada di internal IT. Perusahaan tidak perlu mengelola seluruh application infrastructure, patch operating system, atau membangun setiap capability sendiri. Namun responsibility tidak hilang seluruhnya; sebagian berubah bentuk.<\/p>\n\n\n\n Enterprise tetap bertanggung jawab menentukan siapa yang boleh mengakses SaaS, bagaimana identity dikelola, data apa yang diunggah, integration apa yang diaktifkan, configuration apa yang digunakan, dan apa yang dilakukan jika service tidak tersedia atau vendor mengalami incident.<\/p>\n\n\n\n Risiko juga meningkat ketika SaaS berubah dari supporting tool menjadi bagian dari core operation.<\/p>\n\n\n\n CRM dapat menjadi source utama customer activity. HR platform menyimpan employee information. Collaboration platform menyimpan confidential document. Procurement platform terhubung dengan supplier dan finance. Ketika SaaS menjadi bagian dari end-to-end process, availability dan security provider berubah menjadi business dependency.<\/p>\n\n\n\n Karena itu, SaaS assessment sebaiknya menjawab setidaknya empat hal: data exposure, access exposure, operational dependency, dan exit capability<\/strong>.<\/p>\n\n\n\n Data exposure melihat apa yang disimpan provider. Access exposure melihat integration dan privileges. Operational dependency melihat consequence jika service unavailable. Exit capability melihat apakah company dapat mengambil data dan menjalankan transition tanpa kehilangan business continuity.<\/p>\n\n\n\n Pembahasan ini juga berhubungan dengan SaaS Sprawl: Saat Terlalu Banyak Tools Menghambat Bisnis<\/a>. Semakin banyak SaaS masuk tanpa portfolio governance, semakin besar jumlah identity, integration, data copy, contract, dan vendor relationship yang harus diawasi.<\/p>\n\n\n\n API memungkinkan system enterprise terhubung dengan partner secara cepat. Namun setiap connection juga menciptakan trust relationship baru.<\/p>\n\n\n\n Sebuah partner mungkin membutuhkan akses untuk membaca order status. Payment provider menerima transaction data. Logistics service menerima shipping information. Analytics platform memperoleh data untuk reporting. AI service mungkin memperoleh context dari internal systems.<\/p>\n\n\n\n Risk tidak hanya berasal dari apakah API technically secure. Enterprise juga perlu memahami apa yang berada di balik API tersebut.<\/p>\n\n\n\n Jika credential partner compromised, seberapa banyak data dapat diambil? Jika API mengizinkan write operation, apa yang dapat dimodifikasi? Apakah rate dan scope dibatasi? Bagaimana credential rotation dilakukan? Apakah access dapat dihentikan tanpa mengganggu seluruh operation? Apakah downstream system dapat membedakan legitimate activity dari abnormal behavior?<\/p>\n\n\n\n Itulah sebabnya integration dengan pihak ketiga<\/a> sebaiknya tidak hanya dinilai dari connectivity dan reliability. Security boundary, permission, observability, failure isolation, dan revocation perlu menjadi bagian dari architecture.<\/p>\n\n\n\n Semakin banyak business process berjalan melalui API, semakin penting enterprise mempunyai dependency-aware integration architecture<\/strong>, bukan hanya banyak connection yang technically berhasil.<\/p>\n\n\n\n Ketika vendor menerima data perusahaan, risk berpindah dari internal environment ke data lifecycle yang lebih panjang.<\/p>\n\n\n\n Pertanyaan pertama tentu jenis datanya: apakah personal data, financial data, credential, business secret, intellectual property, atau hanya operational metadata? Namun data sensitivity saja belum cukup.<\/p>\n\n\n\n Enterprise juga perlu mengetahui untuk apa data digunakan, di mana disimpan, berapa lama dipertahankan, siapa subcontractor yang dapat mengaksesnya, bagaimana deletion dilakukan, apakah data dapat digunakan untuk purpose lain, serta apa yang terjadi ketika contract berakhir.<\/p>\n\n\n\n Data juga dapat menyebar melalui integration tanpa management menyadarinya. Satu SaaS memperoleh data dari ERP, kemudian SaaS tersebut terhubung dengan marketing platform atau analytics service. Akibatnya, original data mempunyai dependency chain yang lebih panjang dari yang terlihat pada architecture diagram awal.<\/p>\n\n\n\n Untuk perusahaan yang memproses personal data, third-party relationship juga perlu dibaca bersama governance dan compliance. Namun compliance sebaiknya menjadi baseline, bukan endpoint. Vendor bisa memenuhi contractual requirement tetapi tetap mempunyai operational risk tinggi jika incident response lambat atau service sangat sulit digantikan.<\/p>\n\n\n\n Business question-nya adalah:<\/p>\n\n\n\n Jika data pada vendor ini terekspos, corrupted, tidak dapat diakses, atau tidak dapat dipindahkan, business consequence apa yang akan muncul?<\/strong><\/p>\n\n\n\n Salah satu tantangan supply-chain cybersecurity adalah perusahaan biasanya memiliki visibility terhadap vendor langsung, tetapi jauh lebih rendah terhadap supplier atau component di belakang vendor tersebut.<\/p>\n\n\n\n SaaS provider menggunakan cloud provider lain. Software vendor menggunakan open-source library. Managed service provider menggunakan subcontractor. Development partner menggunakan third-party tool untuk code repository atau monitoring. Satu service dapat bergantung pada banyak layer sebelum capability akhirnya sampai ke company.<\/p>\n\n\n\n NIST SP 800-161 menekankan risiko yang berasal dari product, component, service, supplier, serta supply chain yang lebih luas\u2014bukan hanya entity yang menandatangani kontrak langsung dengan organization. NIST<\/a><\/p>\n\n\n\n Pada 2026, NIST juga menerbitkan SP 1326 Cybersecurity Supply Chain Management: Due Diligence Assessment Quick-Start Guide<\/a>. Guidance tersebut menempatkan supplier due diligence sebagai investigative process untuk memperoleh informasi yang cukup agar acquisition decision dibuat secara informed, dengan perhatian antara lain pada resilience, foundational cyber practices, provenance, dan supply-chain tiers. NIST<\/a><\/p>\n\n\n\n Enterprise tidak perlu memiliki visibility sempurna terhadap seluruh chain. Itu sering tidak realistis. Namun visibility requirement seharusnya meningkat seiring criticality.<\/p>\n\n\n\n Vendor untuk non-critical service mungkin cukup melalui basic assessment.<\/p>\n\n\n\n Vendor yang memperoleh privileged access, memegang sensitive data, atau menjadi single point of failure untuk critical operation membutuhkan scrutiny yang lebih dalam.<\/p>\n\n\n\n Salah satu kesalahan third-party risk management adalah memberikan questionnaire security yang sama kepada seluruh vendor.<\/p>\n\n\n\n Vendor catering menerima puluhan pertanyaan cybersecurity. SaaS yang menyimpan critical business data menerima questionnaire yang sama. Managed infrastructure provider dengan privileged access juga menerima dokumen serupa. Secara administratif process terlihat konsisten, tetapi dari risk perspective belum tentu efektif.<\/p>\n\n\n\n Assessment seharusnya risk-tiered<\/strong>.<\/p>\n\n\n\nThird-Party Cyber Risk Bukan Hanya Risiko Vendor Diretas<\/strong><\/h2>\n\n\n\n
Mulai dari Business Dependency, Bukan Daftar Vendor<\/strong><\/h2>\n\n\n\n
Crocodic Third-Party Cyber Risk Framework<\/strong><\/h2>\n\n\n\n
Akses Vendor Sering Lebih Penting daripada Ukuran Vendornya<\/strong><\/h2>\n\n\n\n
SaaS Mengubah Risk dari Infrastructure Ownership Menjadi Dependency Management<\/strong><\/h2>\n\n\n\n
API Membuat Boundary Perusahaan Semakin Tipis<\/strong><\/h2>\n\n\n\n
Data Sharing Harus Dilihat sebagai Business-Risk Decision<\/strong><\/h2>\n\n\n\n
Third-Party Risk Tidak Berhenti pada Vendor Tier Pertama<\/strong><\/h2>\n\n\n\n
Vendor Assessment Harus Proporsional terhadap Business Criticality<\/strong><\/h2>\n\n\n\n