# स्थानीय निष्पादन रिकॉर्ड SOC 2 CC7 साक्ष्य दे सकते हैं

स्थानीय छेड़छाड़-स्पष्ट निष्पादन रिकॉर्ड SOC 2 CC7 साक्ष्य का समर्थन कर सकते हैं, लेकिन वे अकेले CC7.1 या CC7.2 की पूरी जिम्मेदारी नहीं उठा सकते। वे दिखा सकते हैं कि किस स्थानीय एजेंट प्रक्रिया ने सत्र शुरू किया, उसने क्रेडेंशियल वाले कौन से कॉल आजमाए, वे कॉल कैसे समाप्त हुए और संग्रहित इतिहास बदला गया या नहीं। वे यह नहीं दिखाते कि दायरे में आने वाले हर सिस्टम पर भेद्यता निगरानी हुई या किसी व्यक्ति ने तय समय पर विसंगतियों की जांच की।

यह सीमा मायने रखती है। मैंने टीमों को ऑडिटर के सामने सुंदर तरीके से हस्ताक्षरित लॉग एक्सपोर्ट रखकर उसे अपना निगरानी नियंत्रण कहते देखा है। एक्सपोर्ट ने घटनाओं का होना साबित किया। उसने कवरेज, पहचान तर्क, समीक्षा, एस्केलेशन या सुधार साबित नहीं किया। स्थानीय रिकॉर्ड को नियंत्रण व्यवस्था का एक साक्ष्य स्रोत मानें, तो वह उपयोगी है। उसे ही पूरा नियंत्रण मानें, तो सैंपलिंग के दौरान कमियां सामने आएंगी।

व्यावहारिक जांच सीधी है: हर दावे को एक फ़ील्ड, प्रक्रिया, मालिक और पुष्टिकारी साक्ष्य से जोड़ें। इनमें से कोई हिस्सा गायब हो, तो ऑडिटर से पहले उसकी सीमा लिख दें।

## CC7.1 और CC7.2 अलग प्रश्न पूछते हैं

CC7.1 पूछता है कि संस्था ऐसे कॉन्फ़िगरेशन बदलावों को पहचानने के लिए पहचान और निगरानी प्रक्रियाएं इस्तेमाल करती है या नहीं, जो नई कमजोरियां लाते हैं, और वह नई खोजी गई कमजोरियों के प्रति संवेदनशीलता पहचानती है या नहीं। CC7.2 पूछता है कि संस्था दुर्भावनापूर्ण काम, प्राकृतिक आपदा या त्रुटि से जुड़ी विसंगतियों के लिए सिस्टम घटकों और उनके संचालन की निगरानी करती है या नहीं, फिर यह तय करने के लिए उनका विश्लेषण करती है कि वे सुरक्षा घटनाएं हैं या नहीं। एजेंट की API या SSH कार्रवाई का रिकॉर्ड दोनों मानदंडों में मदद कर सकता है, लेकिन अलग तरीकों से।

CC7.1 के लिए निष्पादन रिकॉर्ड आम तौर पर बदलाव का साक्ष्य है। वह दिखा सकता है कि एजेंट ने फ़ायरवॉल नियम बदला, पैकेज तैनात किया, पहचान सेटिंग बदली या होस्ट पर कमांड चलाया। इससे समीक्षक पता लगाई गई कॉन्फ़िगरेशन ड्रिफ्ट या नए एक्सपोज़र को उस प्रक्रिया से जोड़ सकता है जिसने उसे पैदा किया। रिकॉर्ड किसी नई प्रकाशित कमजोरी को तब तक नहीं पहचानता, जब तक अलग स्कैनर, सलाह फ़ीड, इन्वेंटरी सेवा या समीक्षा प्रक्रिया तैनात घटकों की तुलना नई भेद्यता जानकारी से न करे।

CC7.2 के लिए वही रिकॉर्ड संचालन टेलीमेट्री है। अस्वीकृत कॉल, अनपेक्षित गंतव्य, बार-बार प्रमाणीकरण विफलता, असामान्य कमांड या स्वीकृत सत्र के बाहर की कार्रवाई विसंगति का इनपुट हो सकती है। फिर भी संग्रहित घटना निगरानी के बराबर नहीं है। संस्था को घटनाएं चुनने, संदिग्ध पैटर्न पहचानने, उन्हें समीक्षक तक पहुंचाने और निर्णय दर्ज करने का स्पष्ट तरीका चाहिए।

यह फर्क लॉगिंग को पहचान समझने की सामान्य गलती रोकता है। लॉग स्रोत अवलोकन दर्ज करता है। पहचान नियंत्रण उन अवलोकनों पर तर्क या मानवीय निर्णय लागू करता है। ऑडिटर अक्सर डिजाइन और संचालन दोनों की जांच करेगा, इसलिए केवल संग्रह साबित करने वाला साक्ष्य आधे प्रश्न का उत्तर देता है।

AICPA Trust Services Criteria किसी एक अनिवार्य टूल सूची के बजाय ध्यान देने के बिंदु देते हैं। इससे कंपनी अपने जोखिम के अनुसार नियंत्रण बना सकती है, लेकिन कोई जादुई रिटेंशन अवधि या अनिवार्य उत्पाद श्रेणी नहीं मिलती। आपका सिस्टम विवरण, जोखिम आकलन, नियंत्रण का शब्दांकन और वास्तविक प्रक्रिया तय करते हैं कि स्थानीय निष्पादन डेटा प्रासंगिक है या नहीं।

एक सीमित और बचाव योग्य नियंत्रण कथन ऐसा हो सकता है: "सुरक्षा टीम हर कारोबारी दिन एजेंट के जरिए की गई उत्पादन कार्रवाइयों में अस्वीकृत कॉल, विफल कॉल, नए गंतव्य और विशेषाधिकार प्राप्त SSH कमांड की समीक्षा करती है; समीक्षक निपटान दर्ज करता है और संदिग्ध घटनाओं को घटना प्रक्रिया के तहत आगे बढ़ाता है।" यह कथन जनसंख्या, संकेत, समय, मालिक और अगली कार्रवाई बताता है। "हम छेड़छाड़-स्पष्ट लॉग रखते हैं" केवल संग्रह की एक विशेषता बताता है।

## सत्र पहचान प्रक्रिया बताए, व्यक्ति का संकेत न दे

उपयोगी सत्र रिकॉर्ड एजेंट प्रक्रिया को इतनी मजबूती से पहचानता है कि एक रन दूसरे से अलग हो सके। कम से कम अद्वितीय सत्र पहचानकर्ता, प्रक्रिया शुरू और समाप्त होने का समय, निष्पादन योग्य फ़ाइल का पथ, कोड-हस्ताक्षर पहचान या बाइनरी डाइजेस्ट, मूल प्रक्रिया, होस्ट पहचानकर्ता, स्थानीय खाता, अनुमति निर्णय, अनुमति देने वाला और निरस्तीकरण स्थिति दर्ज करें। हर फ़ील्ड कैसे मिला, यह भी रखें, क्योंकि एजेंट द्वारा बताया गया मान निष्पादन गेटवे या ऑपरेटिंग सिस्टम द्वारा देखे गए मान से कम भरोसेमंद है।

प्रक्रिया पहचान को चुपचाप इंसानी पहचान में न बदलें। कोड-हस्ताक्षर प्राधिकारी बता सकता है कि बाइनरी पर किसने हस्ताक्षर किए। स्थानीय खाता बता सकता है कि वह किस ऑपरेटिंग सिस्टम संदर्भ में चला। इनमें से कोई यह साबित नहीं करता कि किस कर्मचारी ने प्रॉम्प्ट लिखा, हर कार्रवाई स्वीकृत की या किसी खास कमांड का इरादा रखा। यदि नियंत्रण को मानवीय उत्तरदायित्व चाहिए, तो सत्र को पहचान प्रदाता के लॉगिन रिकॉर्ड, डिवाइस प्रबंधन डेटा, स्वीकृति रिकॉर्ड, टिकट मालिक या नियंत्रित वर्कस्टेशन आवंटन से जोड़ें।

मूल और बाल प्रक्रिया संबंधों पर भी यही सावधानी लागू होती है। shell एजेंट शुरू कर सकता है, एजेंट सहायक शुरू कर सकता है और सहायक SSH कार्रवाई मांग सकता है। देखी गई श्रृंखला दर्ज करें, लेकिन तय करें कि नियंत्रण का विषय कौन सी प्रक्रिया है। वरना एक टीम शीर्ष-स्तरीय एजेंट के आधार पर समूह बनाएगी, दूसरी सहायक के आधार पर, और ऑडिट के बीच सैंपल जनसंख्या बदल जाएगी।

एक छोटा सत्र ऑब्जेक्ट साक्ष्य अनुबंध साफ कर सकता है:

```json
{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}
```

ऊपर के तीन बिंदु संक्षिप्त उदाहरण दिखाते हैं, स्वीकार्य संग्रहित पहचानकर्ता नहीं। उत्पादन साक्ष्य में पूरा मान और दस्तावेज़ित अद्वितीयता नियम चाहिए। घड़ी समकालिक होने का साक्ष्य भी चाहिए। यदि एंडपॉइंट, गेटवे, पहचान और टिकट के टाइमस्टैम्प अलग चलें, तो हर स्रोत के भीतर संगति होने पर भी ऑडिटर क्रम को भरोसे से दोबारा नहीं बना सकता।

Sallyport में Sessions journal एजेंट रन दर्ज करता है, जबकि पहले कॉल की स्वीकृति प्रक्रिया के कोड-हस्ताक्षर प्राधिकारी को पहले दिखाती है और प्रक्रिया बंद होने तक चलती है। यह अच्छा स्थानीय सत्र साक्ष्य है, लेकिन जब नियंत्रण किसी नामित कर्मचारी, प्रबंधित डिवाइस, स्वीकृत बदलाव या कॉर्पोरेट लॉगिन का दावा करे, तब टीम को बाहरी रिकॉर्ड भी चाहिए।

## कॉल परिणाम में निर्णय लायक संदर्भ होना चाहिए

हर कॉल का रिकॉर्ड बताए कि प्रक्रिया ने क्या और कहां करने की कोशिश की, गेटवे ने कौन सा क्रेडेंशियल संदर्भ या कुंजी वर्ग इस्तेमाल किया, स्वीकृति जरूरी थी या नहीं, क्या निर्णय हुआ, निष्पादन शुरू हुआ या नहीं और अंत में क्या हुआ। टाइमस्टैम्प और अवधि, चैनल, सामान्यीकृत गंतव्य, कार्रवाई प्रकार, परिणाम वर्ग, त्रुटि वर्ग और स्थिर सहसंबंध पहचानकर्ता दर्ज करें। जांच के लिए पर्याप्त कमांड या अनुरोध विवरण रखें, लेकिन रहस्य या संवेदनशील प्रतिक्रिया बॉडी ऑडिट ट्रेल में न कॉपी करें।

परिणाम शब्दावली अनुशासित होनी चाहिए। "Denied" का अर्थ हो कि नियंत्रण ने बाहरी कार्रवाई से पहले निष्पादन रोका। "Failed" का अर्थ हो कि निष्पादन शुरू हुआ लेकिन त्रुटि मिली, समय समाप्त हुआ या ट्रांसपोर्ट खो गया। "Succeeded" का अर्थ हो कि दूरस्थ इंटरफ़ेस ने दस्तावेज़ित नियम के अनुसार सफलता बताई। "Unknown" उस कठिन स्थिति के लिए हो जिसमें क्लाइंट ने कार्रवाई भेजने के बाद पुष्टि खो दी। अस्वीकृत और विफल कॉल को एक त्रुटि समूह में मिला देने से नियंत्रण के चलने का साक्ष्य नष्ट हो जाता है।

केवल HTTP स्थिति पूरी कहानी बहुत कम बताती है। `200` प्रतिक्रिया में एप्लिकेशन त्रुटि हो सकती है। `202` का अर्थ केवल काम का कतार में लगना हो सकता है। शून्य SSH निकास कोड बताता है कि दूरस्थ shell कमांड ने सफलता बताई, यह नहीं कि अपेक्षित सिस्टम स्थिति बदल गई। हर कार्रवाई प्रकार के लिए परिणाम सामान्यीकरण तय करें और सामान्यीकृत परिणाम के साथ मूल स्थिति या निकास कोड रखें।

एक व्यावहारिक कॉल रिकॉर्ड ऐसा दिख सकता है:

```json
{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}
```

केवल साक्ष्य को पूरा दिखाने के लिए bearer token, निजी कुंजी, पूरा authorization header या कच्ची प्रतिक्रिया दर्ज न करें। रहस्य लीक करने वाला ऑडिट लॉग अलग नियंत्रण विफलता पैदा करता है। स्थिर क्रेडेंशियल संदर्भ इस्तेमाल करें और इंजेक्शन विधि दर्ज करें, जबकि गुप्त सामग्री एजेंट और निर्यातित साक्ष्य से बाहर रहे।

CC7.1 के लिए समीक्षक बदलाव कर सकने वाले कॉल को कॉन्फ़िगरेशन ड्रिफ्ट, तैनाती रिकॉर्ड और भेद्यता निष्कर्षों से जोड़ सकते हैं। CC7.2 के लिए वे अस्वीकृत, विफल, अज्ञात, असामान्य-गंतव्य या उच्च जोखिम कार्रवाइयां विश्लेषण के लिए चुन सकते हैं। कॉल रिकॉर्ड इन प्रक्रियाओं में तभी मदद करता है जब संस्था पूरी जनसंख्या गिन सके। पांच रोचक घटनाओं का स्क्रीनशॉट केवल पांच घटनाओं का होना साबित करता है, सभी प्रासंगिक घटनाओं पर विचार होना नहीं।

## अखंडता जांच इतिहास की संगति साबित करती है, घटना का सत्य नहीं

यदि सत्यापक भरोसेमंद फ़ॉर्मेट और एंकर से शुरू करे, तो हैश श्रृंखला रिकॉर्ड के श्रृंखला में आने के बाद हुए हटाव, जोड़, क्रम-परिवर्तन या संशोधन पहचान सकती है। वह यह साबित नहीं करती कि स्रोत ने हर कार्रवाई पकड़ी, हर फ़ील्ड लिखते समय सही था या हमलावर ने लॉगर को कभी नहीं छोड़ा। छेड़छाड़-स्पष्ट लॉगिंग में सबसे साफ फर्क यही है: रिकॉर्ड की अखंडता संग्रह की पूर्णता नहीं है।

केवल-लिखने योग्य एन्क्रिप्टेड संग्रह से किसी पाठक या संक्रमित विश्लेषण पथ द्वारा पुराने रिकॉर्ड दोबारा लिखे जाने का खतरा घटता है। एन्क्रिप्शन गोपनीयता बचाता है। श्रृंखला पता लग सकने वाली निरंतरता बचाती है। हार्डवेयर-समर्थित कुंजियां पहुंच नियंत्रण मजबूत कर सकती हैं। ये तंत्र अलग ऑडिट प्रश्नों का उत्तर देते हैं, इसलिए पूरे डिजाइन को "अपरिवर्तनीय" कहने के बजाय उन्हें अलग दर्ज करें।

अखंडता प्रक्रिया में दोहराए जा सकने वाले इनपुट और सुरक्षित परिणाम होने चाहिए। Sallyport के साथ समीक्षक बिना कुंजी के एन्क्रिप्टेड श्रृंखला ऑफ़लाइन जांच सकता है:

```text
$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid
```

सटीक आउटपुट इंस्टॉल किए गए रिलीज़ से आना चाहिए। ऊपर का आकार बताता है कि साक्ष्य पैकेट में क्या रहे: कमांड, टूल संस्करण, फ़ाइल पहचानकर्ता या डाइजेस्ट, रिकॉर्ड संख्या, समय सीमा, परिणाम, निष्पादन समय और ऑपरेटर। असली कमांड अलग लेबल दे, तो उदाहरण से मिलाने के लिए दोबारा लिखने के बजाय उसका मूल आउटपुट रखें।

प्रक्रिया पर निर्भर होने से पहले नकारात्मक परीक्षण चलाएं। गैर-उत्पादन एक्सपोर्ट कॉपी करें, इंजीनियरिंग टीम द्वारा समर्थित परीक्षण फ़िक्स्चर से एक रिकॉर्ड बदलें या हटाएं, फिर पुष्टि करें कि सत्यापन विफल होता है। परीक्षण विधि, अपेक्षित विफलता, वास्तविक आउटपुट, टूल संस्करण और समीक्षक की मंजूरी रखें। सफल सत्यापन बताता है कि एक फ़ाइल पास हुई; नियंत्रित नकारात्मक परीक्षण बताता है कि जांचकर्ता दावा किया गया बदलाव पहचानता है।

सीमाओं का भी मिलान करें। एक एक्सपोर्ट की अंतिम रिकॉर्ड संख्या और श्रृंखला एंकर की तुलना अगले की अपेक्षित पहली स्थिति से करें। अंतराल, रीसेट, दोबारा इंस्टॉल, घड़ी के उछाल और होस्ट बदलाव की जांच करें। यदि स्थानीय प्रशासक पूरा लॉग और एंकर मिटा सकते हैं, तो श्रृंखला केवल बदले हुए इतिहास को ईमानदारी से सत्यापित कर सकती है। जोखिम के अनुसार पर्याप्त अंतराल पर एंकर, डाइजेस्ट या हस्ताक्षरित एक्सपोर्ट रसीद अलग नियंत्रित स्थान पर भेजें।

NIST Special Publication 800-92 संग्रहित लॉग की अखंडता बचाने और स्थानांतरित लॉग जांचने की सलाह देता है, आम तौर पर संदेश डाइजेस्ट की तुलना से। वह सलाह सही है, लेकिन डाइजेस्ट या श्रृंखला स्रोत कवरेज की निगरानी को नहीं बदलती। उससे स्थानांतरण और रिटेंशन की विफलता दिखाएं, फिर जांचें कि दायरे के सभी स्रोत वास्तव में रिपोर्ट करते हैं।

## रिटेंशन नियंत्रण अवधि और जांच की जरूरत से शुरू होता है

SOC 2, CC7.1 या CC7.2 साक्ष्य के लिए कोई एक सार्वभौमिक दिनों की संख्या नहीं देता। ऑडिट अवधि, संविदात्मक और कानूनी कर्तव्य, घटना जांच जरूरत, पहचान में देरी, संग्रह संवेदनशीलता और सैंपल बनाने के समय से रिटेंशन तय करें। नीति में रखी जाने वाली घटना श्रेणियां, स्थान, मालिक, पहुंच प्रतिबंध, निपटान विधि और अपवाद प्रक्रिया लिखें।

Type 2 जांच में ऑडिटर एक अवधि के संचालन को जांचता है। यदि टीम केवल सबसे हाल की स्थानीय अवधि रखती है, तो वह शुरुआती अवधि के सैंपल या निरंतरता का समर्थन नहीं कर पाएगी। साक्ष्य को पूरी जांच अवधि, तैयारी, फील्डवर्क और बाद के सवालों के लिए उचित अतिरिक्त समय तक रखें। किसी दूसरी कंपनी की रिपोर्ट से अवधि कॉपी करने के बजाय कानूनी सलाहकार या अनुपालन मालिक से लंबे कानूनी या संविदात्मक कर्तव्य तय कराएं।

केवल स्थानीय रिटेंशन में अनुमानित विफलता आती है। अप्रैल में लैपटॉप बदला, उसका journal चला गया और अक्टूबर के ऑडिट सैंपल में फरवरी आया। अब टीम के पास बदले डिवाइस की सही श्रृंखला है, चुनी तारीख का साक्ष्य नहीं। तय समय पर रिकॉर्ड और सत्यापन एंकर संस्था-नियंत्रित संग्रह में भेजें और निर्धारित एक्सपोर्ट चलने का प्रमाण रखें।

केवल सेटिंग नहीं, पुनर्प्राप्ति जांचें। अवधि की शुरुआती तारीख चुनें, सत्र जनसंख्या खोजें, कॉल रिकॉर्ड निकालें, अखंडता जांचें और एक घटना को उसके समीक्षा निपटान से जोड़ें। लगा समय और विफलताएं दर्ज करें। रिटेंशन सेटिंग का स्क्रीनशॉट डिजाइन दिखाता है। पुरानी अवधि से सफल पुनर्प्राप्ति संचालन दिखाती है।

गोपनीयता और सुरक्षा तब भी लागू हैं। कमांड, गंतव्य, स्थानीय खाते और त्रुटि बॉडी में निजी डेटा या संवेदनशील ढांचा विवरण हो सकता है। साक्ष्य पहुंच सीमित करें, दस्तावेज़ित नियम से निर्यातित कॉपी संपादित करें और केवल अनुमति होने पर बिना संपादित स्रोत रखें। अलग से सत्यापित हो सकने वाला मूल बचाए बिना संपादन को रिकॉर्ड क्रम बदलने या सत्यापन पथ तोड़ने न दें।

## समीक्षा की आवृत्ति संकेत से मेल खाए और प्रमाण छोड़े

समीक्षा नियंत्रण तब चलता है जब नामित भूमिका तय आवृत्ति पर परिभाषित जनसंख्या देखती है, लिखित निर्णय मानदंड लागू करती है और निपटान दर्ज करती है। "लॉग नियमित रूप से देखे जाते हैं" भरोसे से सैंपल नहीं हो सकता, क्योंकि कोई नहीं जानता नियमित का अर्थ क्या है या कौन से लॉग शामिल हैं। उत्पादन पर एजेंट कार्रवाई के लिए हर कारोबारी दिन समीक्षा ठीक हो सकती है। कुछ शक्तिशाली कुंजियों के लिए हर कॉल पर स्वीकृति ठीक हो सकती है। कम जोखिम विकास गंतव्यों के लिए साप्ताहिक रुझान समीक्षा ठीक हो सकती है। जोखिम आकलन इस चुनाव का कारण बताए।

रोकथाम की स्वीकृति को जांच वाली समीक्षा से अलग रखें। स्वीकृति तय करती है कि कार्रवाई आगे बढ़ सकती है या नहीं। समीक्षा पूछती है कि अनुमत, अस्वीकृत, विफल और छोड़ी गई कार्रवाइयां किसी विसंगति या नियंत्रण समस्या का संकेत हैं या नहीं। किसी व्यक्ति का जोखिम भरा कॉल स्वीकार करना यह साबित नहीं करता कि बाद में किसी ने परिणाम देखा, संबंधित कॉल जोड़े या संक्रमित सत्र पहचाना।

टूल चुनने से पहले सरल भाषा में समीक्षा चयन नियम तय करें। उपयोगी प्रक्रिया `result` में `failed` या `unknown` वाले सभी कॉल, सभी अस्वीकृत स्वीकृतियां, हर नया गंतव्य, नामित उत्पादन क्रेडेंशियल के सभी उपयोग, अनजाने हस्ताक्षर प्राधिकारी से शुरू सत्र और हर अखंडता विफलता चुन सकती है। समीक्षक हर मद को अपेक्षित, संचालन समस्या, नीति उल्लंघन या संदिग्ध सुरक्षा घटना चिह्नित करे। संदिग्ध घटना को घटना पहचानकर्ता और एस्केलेशन टाइमस्टैम्प मिले।

शून्य-परिणाम साक्ष्य रखें। शांत दिन पर सुरक्षित क्वेरी, शामिल समय अवधि, निष्पादन टाइमस्टैम्प, समीक्षक पहचान और शून्य संख्या साबित करते हैं कि प्रक्रिया चली। केवल सकारात्मक निष्कर्षों वाले टिकटों का महीना, बिना टिकट वाले दिनों पर सवाल उठाता है। ऑडिटर नियंत्रण प्रदर्शन का सैंपल लेता है, केवल रोचक मामलों का नहीं।

समीक्षा साक्ष्य में ये शामिल हों:

- जनसंख्या क्वेरी या एक्सपोर्ट मानदंड और उसका संस्करण।
- शामिल प्रारंभ और अंत समय, समय क्षेत्र और रिकॉर्ड संख्या।
- समीक्षक पहचान, पूरा होने का समय और देर का कोई स्पष्टीकरण।
- हर चुनी विसंगति, निपटान और समर्थन कारण।
- एस्केलेशन होने पर घटना, बदलाव या समस्या टिकट संदर्भ।

घटना बनाने वाले को अपने इतिहास का अकेला समीक्षक न बनाएं। छोटी टीम में पूरा विभाजन संभव न हो, लेकिन दूसरा जिम्मेदार व्यक्ति प्रतिपूरक समीक्षा कर सकता है, प्रबंधन समय-समय पर जांच कर सकता है और अलग नियंत्रित एक्सपोर्ट इस्तेमाल हो सकते हैं। वास्तविक व्यवस्था लिखें। झूठा विभाजन दावा ईमानदार सीमा और समझदार प्रतिपूरक नियंत्रण से खराब है।

नियंत्रण के स्वास्थ्य पर भी आवृत्ति लागू होती है। तय अंतराल पर पुष्टि करें कि अपेक्षित होस्ट ने रिकॉर्ड बनाए, एक्सपोर्ट पूरे हुए, घड़ियां समकालिक रहीं, अखंडता जांच पास हुई, पहचान चयनकर्ता अभी स्कीमा से मेल खाते हैं और समीक्षकों ने कतार बंद की। स्कीमा बदलाव स्वस्थ दिखने वाली क्वेरी को चुपचाप तोड़ सकता है। ज्ञात परीक्षण घटना या निगरानी वाली संख्या सीमा जोड़ें, ताकि पाइपलाइन कुछ भी चुनना बंद करे तो टीम को पता चले।

CC7.2 में यह तय करने के लिए विश्लेषण जरूरी है कि विसंगति सुरक्षा घटना है या नहीं। बिना कारण टिकट को "गलत संकेत" कहकर बंद करना विश्लेषण नहीं दिखाता। रिकॉर्ड बताए कि क्या हुआ, उसने उद्देश्यों को खतरा क्यों दिया या नहीं दिया, निर्णय के समर्थन में क्या था, निर्णय किसने किया और बाद में पहचान नियम या प्रक्रिया बदली या नहीं।

## ऑडिटर पैकेट दावों और सैंपल के आसपास बनाएं

ऑडिटर आम तौर पर पहले डिजाइन साक्ष्य, फिर चुनी तारीख या घटना से संचालन साक्ष्य मांगता है। स्थानीय निष्पादन रिकॉर्ड ऐसे पैक करें कि हर सामग्री एक नियंत्रण दावे का उत्तर दे। कच्चा संग्रह देकर ऑडिटर से उसमें नियंत्रण खोजने की उम्मीद न करें।

इस मैपिंग को कार्यशील साक्ष्य सूचकांक बनाएं:

| ऑडिटर का अनुरोध | सहायक स्थानीय साक्ष्य | आम तौर पर जरूरी पुष्टि |
| --- | --- | --- |
| दिखाएं कार्रवाई किसने या किस चीज ने शुरू की | सत्र ID, देखा गया निष्पादन योग्य, हस्ताक्षर प्राधिकारी, होस्ट और स्थानीय खाता | पहचान-प्रदाता लॉगिन, डिवाइस इन्वेंटरी, कर्मचारी आवंटन |
| कॉन्फ़िगरेशन बदलने वाली गतिविधि दिखाएं | गंतव्य, कमांड या अनुरोध, क्रेडेंशियल संदर्भ, टाइमस्टैम्प, परिणाम | बदलाव टिकट, रिपॉजिटरी इतिहास, क्लाउड या होस्ट कॉन्फ़िगरेशन स्थिति |
| असामान्य एजेंट व्यवहार की निगरानी दिखाएं | पूरी कॉल जनसंख्या, चयनकर्ता, अस्वीकृत और विफल परिणाम | पहचान कॉन्फ़िगरेशन, अलर्ट रूटिंग, समीक्षा और घटना टिकट |
| दिखाएं रिकॉर्ड नहीं बदले | श्रृंखला सत्यापन आउटपुट, संस्करण, डाइजेस्ट, एंकर और नकारात्मक परीक्षण | एक्सपोर्ट नियंत्रण सेटिंग, अलग संग्रह पहुंच, स्रोत-कवरेज परीक्षण |
| दिखाएं साक्ष्य रखा गया | प्राप्त हो सकने वाले सबसे पुराने और नए रिकॉर्ड, एक्सपोर्ट इतिहास | रिटेंशन नीति, संग्रह कॉन्फ़िगरेशन, हटाव और अपवाद रिकॉर्ड |
| दिखाएं विसंगतियों का विश्लेषण हुआ | समीक्षा वर्कशीट, निपटान, कारण, एस्केलेशन संदर्भ | घटना प्रक्रिया, उत्तरदाता साक्ष्य, सुधारात्मक कार्रवाई ट्रैकिंग |

हर नियंत्रण के लिए एक-पृष्ठ साक्ष्य परिभाषा रखें, जिसमें नियंत्रण शब्द, मालिक, आवृत्ति, सिस्टम जनसंख्या, घटना जनसंख्या, प्रक्रिया, अपेक्षित सामग्री, संग्रह स्थान और अपवाद संभालना हो। हर निर्यातित कॉलम के लिए फ़ील्ड शब्दकोश जोड़ें। ऑडिटर को यह अनुमान न लगाना पड़े कि `actor` कर्मचारी, स्थानीय खाता, प्रक्रिया या हस्ताक्षर प्राधिकारी है।

दो सैंपल पथ तैयार करें। पहला यादृच्छिक चुनी तारीख से शुरू हो और साबित करे कि पूरी समीक्षा समय पर चली। दूसरा चुने गए उच्च जोखिम कॉल से शुरू हो, पीछे सत्र स्वीकृति तक और आगे दूरस्थ परिणाम, समीक्षा निपटान तथा बदलाव या घटना टिकट तक जाए। ये पथ अलग दावे जांचते हैं। तारीख सैंपल बार-बार संचालन जांचता है, घटना सैंपल पता लगाने की क्षमता।

हर हस्तांतरण पर कुल मिलाएं। दस्तावेज़ित फ़िल्टर के तहत Sessions journal की संख्या सत्र एक्सपोर्ट से मेल खाए। स्थानांतरण के पहले और बाद कॉल संख्या मिले। समीक्षा इनपुट संख्या चुनी, छोड़ी और लंबित मदों से मेल खाए। परीक्षण वातावरण, स्वीकृत बहिष्कार, दोहराई कोशिश या नियंत्रण समय से बाहर रिकॉर्ड जैसे सही अंतर समझाएं।

Type 1 रिपोर्ट एक समय बिंदु पर नियंत्रण डिजाइन देखती है। Type 2 रिपोर्ट यह भी देखती है कि नियंत्रण बताई अवधि में चला या नहीं। वर्तमान स्क्रीनशॉट, नया अखंडता परीक्षण या हाल में लिखी प्रक्रिया Type 1 डिजाइन में मदद कर सकती है, लेकिन कई महीनों का गायब Type 2 संचालन नहीं बना सकती। इतिहास न हो तो कमी बताएं और पिछली तारीख के हस्ताक्षर बनाने के बजाय तैयारी समय दोबारा तय करें।

फील्डवर्क से पहले ऑडिटर से पूछें कि एन्क्रिप्टेड या संवेदनशील साक्ष्य कैसे चाहिए, सैंपल में कौन से गुण चाहिए और वे तारीख, सत्र, कॉल या अलर्ट में से क्या चुनेंगे। यह बातचीत पैकेजिंग बदलती है, नियंत्रण नहीं। सैंपल आने से पहले नियंत्रण लगातार चलना चाहिए।

## कवरेज और प्रतिक्रिया साक्ष्य दूसरी जगह से लें

स्थानीय निष्पादन रिकॉर्ड केवल स्थानीय निष्पादन पथ से गुजरने वाली कार्रवाइयां देखते हैं। वे यह साबित नहीं करते कि हर उत्पादन बदलाव उसी पथ से हुआ। प्रशासक क्लाउड कंसोल, सीधा SSH, CI/CD क्रेडेंशियल, प्रदाता सहायता चैनल, आपात खाते, निर्धारित काम या दूसरा वर्कस्टेशन इस्तेमाल कर सकते हैं। बदलाव और पहुंच पथों की सूची बनाएं, फिर उन्हें नियंत्रण में लाएं या उनके लॉग अलग लें।

CC7.1 को निष्पादन इतिहास के बाहर ये साक्ष्य चाहिए:

- ऑडिट दायरे से जुड़ी मौजूदा संपत्ति और सॉफ़्टवेयर सूची।
- कॉन्फ़िगरेशन मानक और स्वीकृत बेसलाइन संस्करण।
- भेद्यता स्कैन कॉन्फ़िगरेशन, कवरेज, परिणाम और स्कैन स्वास्थ्य।
- नई घोषित कमजोरियों और प्रभावित घटकों के मिलान की प्रक्रिया।
- सुधार टिकट, जोखिम स्वीकृति, समय सीमा, दोबारा परीक्षण और अपवाद।

पैकेज संस्करण X इंस्टॉल करने वाला एजेंट कॉल उपयोगी बदलाव साक्ष्य है। वह नहीं बताता कि तीन हफ्ते बाद संस्करण X कमजोर घोषित हुआ। भेद्यता प्रबंधन सिस्टम, सलाह प्राप्ति, सॉफ़्टवेयर सूची और सुधार रिकॉर्ड को यह कहानी पूरी करनी होगी।

CC7.2 को भी विस्तृत स्रोत चाहिए। दायरे के जोखिम के अनुसार एंडपॉइंट, पहचान, नेटवर्क, क्लाउड नियंत्रण स्तर, एप्लिकेशन, डेटाबेस और उपलब्धता टेलीमेट्री लें। पहचान नियम, सक्रिय-स्रोत सूची, अलर्ट रूटिंग परीक्षण, ऑन-कॉल या समीक्षक आवंटन, अलर्ट इतिहास, निपटान, घटना रिकॉर्ड और घटना के बाद की कार्रवाई रखें। प्राकृतिक आपदा और संचालन त्रुटि कवरेज के लिए उपलब्धता अलार्म और निरंतरता प्रक्रिया चाहिए हो सकती है, जिसे कार्रवाई गेटवे नहीं देखता।

मिलान से पूर्णता साबित करें। प्रबंधित डिवाइस की तुलना स्थानीय रिकॉर्ड भेजने वाले डिवाइस से करें। उत्पादन क्रेडेंशियल की तुलना गेटवे से उपलब्ध क्रेडेंशियल से करें। क्लाउड बदलाव की तुलना गेटवे कॉल और स्वीकृत स्वचालन से करें। दोनों ओर के बेमेल रिकॉर्ड जांचें: स्थानीय कॉल के बिना क्लाउड बदलाव छोड़ा गया रास्ता दिखा सकता है, जबकि अपेक्षित दूरस्थ बदलाव के बिना सफल स्थानीय कॉल गलत परिणाम सामान्यीकरण या वापसी दिखा सकता है।

शासन साक्ष्य भी लें। जोखिम आकलन बताए कि एजेंट कार्रवाई CC7.1 और CC7.2 के लिए क्यों मायने रखती है। नीतियां लॉग, भेद्यता, निगरानी, समीक्षा, घटना और रिटेंशन की जिम्मेदारियां बांटें। प्रशिक्षण या प्रक्रिया स्वीकृति कार्रवाई स्वीकारने और समीक्षा करने वालों को शामिल करे। पहुंच समीक्षा दिखाए कि कौन साक्ष्य पढ़, निर्यात, प्रबंधित या हटा सकता है और पहचान तर्क कौन बदल सकता है।

NIST Special Publication 800-92 लॉग प्रबंधन को उत्पादन, स्थानांतरण, संग्रह, विश्लेषण और निपटान मानता है। यह जीवनचक्र केवल स्थानीय सोच को जांचने का अच्छा तरीका है। यदि साक्ष्य डिजाइन उत्पादन और संग्रह देखता है लेकिन स्थानांतरण, विश्लेषण और निपटान छोड़ता है, तो अच्छी क्रिप्टोग्राफी के बाद भी वह अधूरा है।

स्पष्ट साक्ष्य-अंतर रजिस्टर रखें, जिसमें बिना कवरेज वाला सिस्टम, गायब अवधि, प्रभावित नियंत्रण, जोखिम, अंतरिम प्रक्रिया, मालिक और लक्ष्य तारीख हो। ऑडिटर एक छोटे निष्पादन लॉग से पूरी कंपनी देखने की उम्मीद नहीं करते। वे उम्मीद करते हैं कि प्रबंधन अपना दायरा जानता हो और ऐसा दावा न करे जिसे साक्ष्य सहारा नहीं देता।

## स्थानीय रिकॉर्ड को सीमित, परीक्षण योग्य नियंत्रण हिस्सा बनाएं

जब नियंत्रण कथन उनके अवलोकन से मेल खाता है, तब स्थानीय छेड़छाड़-स्पष्ट रिकॉर्ड उपयोगी हैं। वे सत्र और कॉल के विस्तृत साक्ष्य देते हैं, दूरस्थ सिस्टम तक कभी न पहुंचने वाली अस्वीकृत कोशिशें रखते हैं और बाद के बदलाव पहचान योग्य बनाते हैं। AI एजेंट गतिविधि में ये खास उपयोगी हैं, क्योंकि दूरस्थ API अक्सर केवल साझा सेवा पहचान देखती है और स्थानीय प्रक्रिया संदर्भ खो देती है।

जब टीम पहचान बढ़ा-चढ़ाकर बताती है, छोड़े गए रास्ते अनदेखे करती है, डेटा केवल बदले जा सकने वाले एंडपॉइंट पर रखती है या सही श्रृंखला को पूरी निगरानी मानती है, तब साक्ष्य कमजोर होता है। इलाज कोई नया क्रिप्टोग्राफ़िक विशेषण नहीं है। दावा छोटा करें, जनसंख्या लिखें, आवर्ती समीक्षा करें, सत्यापन परिणाम अलग रखें और प्रामाणिक सिस्टम से जोड़ें।

रिकॉर्ड पर निर्भर होने से पहले बीज वाली घटना से पूरा नियंत्रण परीक्षण चलाएं। पहचाने जा सकने वाला परीक्षण सत्र शुरू करें, एक स्वीकृत और एक अस्वीकृत कार्रवाई आजमाएं, दोनों परिणाम जांचें, अवधि निर्यात करें, श्रृंखला सत्यापित करें, समीक्षा चयनकर्ता चलाएं, निपटान दर्ज करें और दूरस्थ सिस्टम की संबंधित घटना मिलाएं। फिर पुरानी अवधि के लिए पुनर्प्राप्ति दोहराएं। इस क्रम का हर टूटाव असली साक्ष्य अंतर है।

ऑडिटर को श्रृंखला परिणाम के साथ स्रोत सूची, चयनकर्ता, समीक्षा प्रमाण, अपवाद ट्रेल और बाहरी पुष्टि भी दें। ऐसा पैकेट बचाव योग्य CC7.1 या CC7.2 नियंत्रण का समर्थन करता है। अकेली श्रृंखला केवल सीमित दावा सहारा देती है कि दी गई स्थानीय हिस्ट्री में अब भी सत्यापक की अपेक्षित संरचना है।