सुरक्षा मानक

ProcureLabs में security हमारे platform का मूलभूत हिस्सा है। यह page procurement data की सुरक्षा के लिए लागू measures और उनके coverage तथा limitations का वर्णन करता है।

Certifications Compliance

Data Encryption

Infrastructure Security

• Cloud Infrastructure: AWS पर होस्ट किया गया है, जिसके पास SOC 2, ISO 27001 और PCI DSS प्रमाणन हैं। ये AWS के प्रमाणन हैं, ProcureLabs के नहीं।
• Data Isolation: Customer data रखने वाली database tables पर row-level security enabled है, इसलिए signed-in user की queries केवल उसके अपने organization की rows return करती हैं। Elevated database access के साथ चलने वाले background jobs और administrative paths row-level security से होकर नहीं गुजरते; वे application code में tenant filter लागू करते हैं।
• Availability: एकल AWS क्षेत्र (सिंगापुर); क्रॉस-रीजन फ़ेलओवर नहीं
• Disaster Recovery: Point-in-time recovery वाले database backups, हमारे database host (Supabase) द्वारा प्रदान किए जाते हैं

Access Control

सुरक्षा निगरानी और प्रतिक्रिया

• कमज़ोरी प्रबंधन: हर मर्ज अनुरोध को कमिट किए गए सीक्रेट्स (Gitleaks) और ठीक की जा सकने वाली गंभीर निर्भरता-कमज़ोरियों (Trivy) के लिए स्कैन किया जाता है।
• घटना प्रतिक्रिया: घटनाओं को ProcureLabs के संस्थापक द्वारा प्लेटफ़ॉर्म की घटना-प्रतिक्रिया प्लेबुक का उपयोग करके संभाला जाता है और प्रभावित ग्राहकों को ईमेल द्वारा सूचित किया जाता है।
• सुरक्षा संबंधी समस्याओं की रिपोर्ट नीचे दिए गए हमारे सुरक्षा संपर्क को की जा सकती है।

AI डेटा प्रोसेसिंग सुरक्षा

हमारी AI सुविधाओं को सुरक्षा और निजता को ध्यान में रखकर बनाया गया है:

• OpenAI द्वारा प्रसंस्करण OpenAI चैट, विश्लेषण और टूल चयन तथा खरीद साक्ष्य के लिए Decisions के सीमित आकलन का समर्थन करता है। ग्राहक की वर्तमान अनुमति और सहमत क्षेत्रीय कॉन्फ़िगरेशन के अधीन, Decisions को अनुमत उद्देश्य के लिए न्यूनतम और संवेदनशील जानकारी हटाए गए संदर्भ तथा प्रश्न मिलते हैं। स्पष्ट सहमति से शामिल होने पर ही OpenAI API डेटा मॉडल प्रशिक्षण के लिए उपयोग होता है। Decisions एन्क्रिप्टेड प्रॉम्प्ट-कैश स्थिति को 24 घंटे तक और सामान्य दुरुपयोग निगरानी लॉग को 30 दिन तक रख सकता है; लागू सुरक्षा, संरक्षण या कानूनी अपवाद इसके अधीन हैं।
• Decisions प्रसंस्करण की अनुमति Decisions प्रसंस्करण के लिए ग्राहक के वर्तमान निर्देश और विशिष्ट उद्देश्य, खाते, प्रसंस्करणकर्ता तथा अमेरिका में हस्तांतरण की अनुमति आवश्यक है। AI बंद करने या संबंधित अधिकार वापस लेने से नए Decisions अनुरोध रुक जाते हैं। परिणामकारी कार्रवाइयाँ आवश्यक सुरक्षा उपायों और स्वतंत्र समीक्षा के अधीन रहती हैं।
• डेटा रखने की अवधि संबंधित डेटा श्रेणी, ग्राहक के निर्देश, कानूनी संरक्षण आदेश और प्रदाता की शर्तों के अनुसार होती है। चैट इतिहास, व्युत्पन्न सामग्री, ऑडिट रिकॉर्ड और प्रदाता लॉग की अलग प्रतिधारण शर्तें हैं। हटाने के अनुरोध डेटा प्रसंस्करण समझौते और लागू कानून के तहत संभाले जाते हैं।
• वैकल्पिक AI सुविधाओं को प्रशासक द्वारा अक्षम किया जा सकता है
• AI सुविधाओं को प्रशासक द्वारा पूरे संगठन के लिए, या प्रत्येक उपयोगकर्ता द्वारा अपने लिए बंद किया जा सकता है
• AI द्वारा प्रस्तावित कार्रवाइयों पर लिए गए निर्णयों का ऑडिट लॉग

डेटा रेज़िडेंसी

सभी ग्राहक डेटा एक ही क्षेत्र में संग्रहीत किया जाता है। AI सुविधाएं आवश्यक डेटा को United States में स्थित AI प्रदाताओं के साथ प्रोसेस करती हैं। अतिरिक्त स्टोरेज क्षेत्र आज उपलब्ध नहीं हैं।

शासन

• हम एक लिखित सूचना सुरक्षा नीति रखते हैं, जिसमें हमारी नीतियों और प्रक्रियाओं की सूची शामिल है और जिसकी समीक्षा कम से कम वार्षिक रूप से की जाती है।
• हम ईमानदारी, गोपनीयता और हितों के टकराव को शामिल करने वाली एक लिखित आचार संहिता रखते हैं।
• ProcureLabs के तीन संस्थापक हैं। David Hodge, CEO और Director, सुरक्षा और डेटा संरक्षण के लिए उत्तरदायी हैं। सह-संस्थापक समीक्षा और स्वतंत्र रिकवरी व्यवस्थाओं का दस्तावेज़ीकरण और सत्यापन किया जा रहा है।
• हम एक लिखित जोखिम रजिस्टर रखते हैं, जिसकी समीक्षा कम से कम वार्षिक रूप से और महत्वपूर्ण बदलावों से पहले की जाती है।
• हम अपने सब-प्रोसेसरों की जांच और समीक्षा के लिए एक लिखित प्रक्रिया रखते हैं। ProcureLabs चलाने वाले सर्वरों की भौतिक सुरक्षा AWS और Supabase द्वारा प्रदान की जाती है; हमारा अपना कोई डेटा सेंटर नहीं है।
• हम एक लिखित व्यवसाय निरंतरता योजना रखते हैं, जिसकी समीक्षा कम से कम वार्षिक रूप से की जाती है।
• हमारे पास बैकअप से डेटाबेस को परीक्षण के रूप में पुनर्स्थापित करने की एक लिखित प्रक्रिया है। केवल डेटाबेस की पुनर्स्थापना का एक अभ्यास पूरा किया जा चुका है और अस्थायी कॉपी हटा दी गई है। पूर्ण एप्लिकेशन, प्रमाणीकरण और ऑब्जेक्ट-स्टोरेज रिकवरी तथा स्वतंत्र वैकल्पिक-ऑपरेटर पहुंच का सत्यापन अभी बाकी है।

बदलाव प्रबंधन और प्रोसेसिंग अखंडता

• कोड बदलाव मर्ज अनुरोधों के माध्यम से हमारी मुख्य शाखा तक पहुंचते हैं, जिन्हें सीक्रेट स्कैनिंग, डेटाबेस-माइग्रेशन जांच और यह जांच सहित आवश्यक पाइपलाइन जांच पास करनी होती है कि इस साइट पर दिए गए सुरक्षा और निजता संबंधी कथन अभी भी कोड से मेल खाते हैं। प्रोडक्शन रिलीज़ केवल इसी शाखा से की जाती है। यदि कोई आवश्यक जांच हटा दी जाती है या उसे विफल होने की अनुमति दी जाती है, तो एक स्वचालित परीक्षण विफल हो जाता है।
• कोड में ज्ञात कमज़ोरियों को बेसलाइन और हमारे अनुपालन साक्ष्य रजिस्टर में दर्ज किया जाता है। ऐसी नई कमज़ोरी जोड़ने वाला बदलाव—जैसे ऐसा एरर हैंडलर जो किसी त्रुटि को चुपचाप छोड़ देता है, या ऐसा प्रकाशित कथन जिसके सहायक कोड में बदलाव हो गया है—उसे ठीक या दर्ज किए जाने तक रोक दिया जाता है।
• हमारे API के अधिकांश write endpoints प्रत्येक अनुरोध के बॉडी की घोषित schema के विरुद्ध जांच करते हैं और मेल न खाने वाले अनुरोध को 400 error के साथ अस्वीकार कर देते हैं।
• हमारे detection engines का प्रत्येक रन, प्रत्येक detector के लिए यह दर्ज करता है कि वह पूरा हुआ या नहीं और उसने कितने परिणाम लौटाए, अथवा वह विफल हुआ। विफलता को विफलता के रूप में दर्ज किया जाता है, कभी भी “no findings” के रूप में नहीं।