ऑडिट के लिए तैयार होना: ISO 27001, SOC 2, Cyber Essentials
ISO 27001, SOC 2, और Cyber Essentials के लिए ऑडिटर वास्तव में क्या जांचते हैं, इसका व्यावहारिक मार्गदर्शन और बिना घबराहट के तैयारी कैसे करें।
अधिकांश टीमें एक compliance audit को एक fire drill की तरह देखती हैं जो साल में एक बार आता है। इसे इस तरह नहीं होना चाहिए, और frameworks स्वयं उतने रहस्यमय नहीं हैं जितना विक्रेता उन्हें प्रस्तुत करते हैं। यहाँ वह है जो वास्तव में मायने रखता है जब आप ISO 27001, SOC 2, या Cyber Essentials के लिए तैयारी कर रहे हों।
जानें कि आपसे वास्तव में किस framework की मांग की जा रही है
ये तीनों एक साथ मिलाए जाते हैं लेकिन ये अलग-अलग समस्याओं को हल कर रहे हैं। ISO 27001 एक management system standard है — यह प्रमाणित करता है कि आपके पास एक कार्यशील Information Security Management System (ISMS) है जिसमें risk assessments, policies, और continuous improvement बनी हुई है। SOC 2 एक attestation report है, आमतौर पर Type II, जो एक समय अवधि (आमतौर पर 6-12 महीने) में Trust Services Criteria के विरुद्ध कवर करता है: security, availability, processing integrity, confidentiality, privacy। Cyber Essentials एक UK सरकार द्वारा समर्थित योजना है जो पाँच बुनियादी technical controls पर केंद्रित है: firewalls, secure configuration, access control, malware protection, और patch management।
अगर एक ग्राहक कहता है "हमें आपको SOC 2 compliant होना चाहिए," तो पूछें कि किस type और किन criteria की वास्तव में परवाह है। अधिकांश B2B SaaS deals को केवल Security और Availability की आवश्यकता है, पूरे पाँच criteria नहीं।
ऑडिटर पूछने से पहले evidence trail बनाएँ
ऑडिटर आपके शब्द पर भरोसा नहीं करते — उन्हें artifacts चाहिए। ISO 27001 के लिए इसका मतलब है एक Statement of Applicability जो Annex A (2022 revision) के सभी 93 controls को उस तक मैप करता है जो आपने implemented किया है या excluded किया है, justification के साथ। SOC 2 के लिए, इसका मतलब है screenshots, logs, और tickets जो साबित करते हैं कि controls audit window भर में consistently operate किए गए, न कि केवल उस दिन जब किसी को इसे configure करना याद आया।
Evidence collection को एक ongoing process के रूप में सेट अप करें, न कि एक scramble:
# Example: AWS CLI के माध्यम से मासिक IAM access review evidence खींचें
aws iam generate-credential-report
aws iam get-credential-report --output text --query 'Content' | base64 -d > access-report-$(date +%Y%m).csv
इन्हें timestamps के साथ एक dedicated evidence repo में store करें (Google Drive folder, Vanta, Drata — जो कुछ भी आप उपयोग करते हैं) control ID द्वारा organized, महीने द्वारा नहीं। Auditors अवधि भर में sample लेते हैं; आपको साबित करना चाहिए कि control मार्च और अक्टूबर में live था, न कि केवल जब आपको याद आया।
वे controls जो हर बार लोगों को परेशान करते हैं
Access reviews number one finding हैं। अगर आप quarterly review दिखा नहीं सकते कि production systems तक किसके पास access है, stale accounts को किसी ने actually remove किया इसके साक्ष्य के साथ, तो भले ही framework कोई भी हो, एक finding की उम्मीद करें। इसे एक recurring calendar task के रूप में चलाएँ, न कि एक ad hoc favor।
Vendor risk management दूसरा बड़ा gap है। ISO 27001 clause A.5.19-A.5.23 और SOC 2 की vendor management criteria दोनों ही उम्मीद करते हैं कि आप subprocessors को assess करें — cloud providers, payment processors, कुछ भी जो customer data को छूता है। प्रति critical vendor एक one-page vendor risk questionnaire, annually reviewed, इसके अधिकांश को कवर करता है।
Incident response plans जो केवल एक document के रूप में exist करती हैं जिसे किसी ने test नहीं किया, ये भी एक common finding हैं। अपने audit window बंद होने से पहले कम से कम एक बार एक tabletop exercise चलाएँ और meeting notes रखें। Auditors specifically पूछते हैं कि plan को exercise किया गया था इसके लिए evidence, न कि केवल written।
Cyber Essentials के लिए, technical scope questions लोगों की तुलना में अधिक मायने रखते हैं। आपको accurately describe करना चाहिए अपनी boundary — हर device, cloud service, और BYOD policy in scope — क्योंकि scope को misrepresent करना failing के लिए ground है भले ही technical controls ठीक हों। Patch management को literally check किया जाता है: critical और high-severity patches को release के 14 दिनों के भीतर internet-facing services के लिए apply किया जाना चाहिए।
एक realistic internal timeline चलाना
SOC 2 Type II के लिए, audit period शुरू होने से पहले भी 3-6 महीने के evidence collection के लिए budget करें, क्योंकि Type II को prove करना आवश्यक है कि controls observation window को operate किए गए, न कि केवल एक point in time पर। ISO 27001 certification आमतौर पर gap assessment से certificate तक 6-12 महीने चलता है, जिसमें एक Stage 1 documentation review और Stage 2 on-site (या remote) assessment certification body द्वारा शामिल हैं। Cyber Essentials तेज़ है — अगर आपकी बुनियादें पहले से ही सही हैं तो self-assessment questionnaires हफ्तों में turn around हो सकते हैं, Cyber Essentials Plus एक external technical verification जोड़ता है।
ऑडिट को अपने काम को check करने का एकमात्र समय न बनने दें
असली audit से 60-90 दिन पहले actual control list के विरुद्ध एक internal readiness assessment चलाएँ। उस internal pass से findings को वैसे ही treat करें जैसे आप auditor findings को treat करेंगे — remediate करें, fix को document करें, और paper trail रखें। वह internal pass आमतौर पर वह जगह है जहाँ टीमें access review gaps और stale vendor contracts को catch करती हैं कोई external करने से पहले, एक report के साथ attached एक customer contract renewal को riding करता है।
अगर आप इन frameworks के पीछे के technical controls पर deeper जाना चाहते हैं — access control design, logging, incident response — तो Korra Studio पर Blue Team और Certifications tracks को check करें।
AI सहायता से लिखा गया, माइकल पिल्च (CISSP), Korra Studio द्वारा समीक्षित और प्रकाशित।
यह Korra Studio के ज्ञान आधार से एक नोट है — प्लेटफ़ॉर्म हर विषय को 1-टू-1 मेंटरिंग के साथ जोड़ता है।
मुफ़्त शुरू करेंarrow_forward