APAC एंटरप्राइज के लिए थर्ड-पार्टी रिस्क मैनेजमेंट

Modern organisation single company नहीं है; वह vendors, SaaS platforms, cloud providers और integrators का web है, और हर एक आपके data और reputation का एक thread hold करता है। इनमें से कोई fail होता है तो उसकी failure आप inherit करते हैं: regulator आपसे पूछता है कि vendor vetted क्यों था, और customer आपसे पूछता है कि उसका data आपके chosen supplier से leak क्यों हुआ।

Third-party risk management (TPRM) उस web को legible बनाने का discipline है: यह जानना कि किसे किस चीज़ तक access है, आप उन पर कितना depend करते हैं, और उनके controls actually hold up करते हैं या नहीं।

Questionnaire का trap #

ज़्यादातर TPRM programmes 200-500 questions की spreadsheet होती हैं जो हर vendor को भेजी जाती है, file कर दी जाती है और annually भूला दी जाती है। इससे paperwork produce होता है पर risk reduction बहुत कम, two reasons:

1. यह हर vendor को equally treat करता है। Coffee supplier और payments processor को same questionnaire मिलती है, जबकि exposure wildly different है।
2. यह self-attestation trust करता है। “Yes, we encrypt data” कहने वाला vendor वह नहीं है जो यह दिखा सके। Questionnaires confidence measure करते हैं, controls नहीं।

Fix proportionality और verification है। Vendors को actual access के हिसाब से categorise करें, फिर deep-dive effort वहां spend करें जहां exposure real है।

Actual exposure से tiering #

Workable model vendors को उसके हिसाब से tier करता है कि वे क्या touch करते हैं:

• Tier 1, critical: cardholder या personal data hold करते हैं, आपके systems से deeply integrate होते हैं, या single point of failure हैं। इन्हें technical assessment, audit rights और contractual security schedules मिलती हैं।
• Tier 2, significant: business data process करते हैं या privileged access रखते हैं। इन्हें lighter technical review और periodic re-validation मिलती है।
• Tier 3, transactional: limited या no data access। इन्हें baseline due diligence मिलती है, उससे ज्यादा कुछ नहीं।

Point more process नहीं है; proportionate process है। Tier 1 payment gateway fail हुई तो incident है। Tier 3 stationery vendor fail हुआ तो inconvenience है। दोनों को same treat करना wrong risk पर effort waste कराता है।

Questionnaire के beyond: technical verification #

उन vendors के लिए जो matter करते हैं, self-attestation enough नहीं है। Technical verification का मतलब है evidence मांगना, और जहां relationship justify करे तो testing:

• Evidence review: SOC 2 reports, ISO 27001 certificates, PCI DSS AOCs, और critically उन reports का scope, सिर्फ logo नहीं।
• Architecture review: vendor अपने environment में आपका data actually कैसे handle करता है, marketing page कैसे describe नहीं करता।
• Contractual teeth: enforceable security schedules, breach-notification timelines, और audit rights जो renegotiation survive करें।

Frameworks इस पर agree करते हैं। NIST SP 800-161 supply chain risk पर, और ISO 27001 के supplier security clauses (2022 edition mapping में A.15), दोनों blanket questionnaires की जगह proportionate, evidence-based vendor assurance push करते हैं। Bank of Thailand outsourcing guidance financial institutions और उनके critical vendors पर same logic apply करती है।

Continuous, one-off नहीं #

Vendor risk static नहीं रहता। पिछले साल review pass करने वाला vendor इस साल acquired, breached, या quietly sub-processors change कर सकता है। Mature model risk-based cycle पर re-validate करता है, signals monitor करता है (data breaches, ownership changes, certificate lapses), और offboarding path रखता है जो access actually revoke करता है, invoice cancel करना सिर्फ नहीं।

हमारा Third-Party Risk Management tiering model build करता है, deep-dive reviews run करता है, और contractual security schedules draft करता है जो आपकी legal team needs। इसे Regulatory Compliance के साथ pair करें vendor obligations को BOT और ISO 27001 requirements map करने के लिए।