SOC 2 או ISO 27001: לקוח אמריקאי והתרחבות לאירופה דורשים הוכחות שונות

כשלקוח אמריקאי מבקש הוכחה לבקרות של שירות SaaS שהוא עומד לרכוש, דוח SOC 2 הוא המסלול הישיר לבחינה. מדריך AICPA ל־SOC 2 מתאר בדיקה של מערכת ארגון השירות ושל הבקרות הרלוונטיות, בין היתר לאבטחה, לזמינות ולסודיות. אם רוכש באירופה דורש תעודה למערכת ניהול אבטחת מידע, החברה צריכה לבחון את מסלול ההסמכה המבוקש בחוזה.

תקן ISO/IEC 27001 לפי ISO מגדיר דרישות להקמה, להפעלה ולשיפור מתמשך של מערכת ניהול אבטחת מידע המבוססת על ניהול סיכונים; ארגון יכול לבחור לעבור הסמכה כדי להוכיח התאמה. לכן סדר העבודה של חברת SaaS ישראלית נקבע קודם כול לפי הראיה שרוכש מסוים יקבל, ולא לפי המדינה שבה הוא יושב. כששני חוזים דורשים תוצרים שונים, אפשר לשתף חלק מעבודת הבקרה, אך יש לתכנן דוח והסמכה בנפרד.

מה כל מסמך מוכיח לרוכש

דוח SOC 2 עוסק במערכת השירות שהחברה מתארת לצורך הבדיקה. הוא מציג את גבולות המערכת, את הבקרות הרלוונטיות ואת חוות הדעת של המבקר על פי הקריטריונים שנבחרו. עבור רוכש תוכנה, הפרט המכריע הוא אם השירות שהוא קונה אכן כלול במערכת המתוארת. דוח של אותה חברה על שירות אחר אינו נותן בהכרח תשובה לשאלות האבטחה של העסקה.

תעודת ISO/IEC 27001 עוסקת במערכת ניהול אבטחת המידע ובהיקף שהוגדר להסמכה. ההיקף עשוי לכלול ארגון שלם או חלק מוגדר ממנו, והתקן חל על ארגונים מסוגים שונים. לכן תעודה יכולה להראות כיצד החברה מנהלת סיכוני מידע, אך אינה מפרטת לרוכש את בדיקות הבקרות של שירות מסוים באותה מתכונת של דוח SOC 2. גם בכיוון ההפוך, דוח על שירות מוגדר אינו מעיד שכל פעילות החברה נכללת במערכת ניהול מוסמכת.

איזו דרישה קובעת את סדר העבודה

המסמך שקובע את הבחירה הראשונה הוא דרישת הרכש, שאלון האבטחה או טיוטת החוזה של עסקה פעילה. מקום מושבו של הלקוח עשוי לרמוז איזה מסמך יהיה מוכר לו, אך אינו מחליף את נוסח הדרישה. רוכש אמריקאי יכול לבקש תעודת ISO/IEC 27001, ורוכש אירופי יכול לדרוש דוח SOC 2. כשנכתב רק ״הוכחת אבטחה״, יש לברר איזה תוצר יתקבל לפני שמזמינים ביקורת.

• אם תנאי העסקה מבקשים דוח SOC 2, יש להגדיר איזה שירות ייכלל בו, אילו התחייבויות ובקרות ייבדקו ואיזה סוג דוח נדרש.
• אם התנאי הוא הסמכת ISO/IEC 27001, יש לברר אילו פעילויות, ישויות ואתרים חייבים להופיע בהיקף מערכת הניהול המוסמכת.
• אם חוזים שונים דורשים את שני התוצרים, יש לתכנן מראש את שני היקפי הבדיקה ולזהות בקרות וראיות תפעוליות שיכולות לשרת את שניהם.

לחברה שטרם קיבלה דרישה מפורשת אין תשובה אוטומטית על סמך גודל השוק שאליו היא מתכננת להתרחב. הבחירה תלויה בעסקאות שאליהן היא מכוונת, במועד שבו הרוכשים דורשים ראיה ובשירות שיוצע להם. אם לקוח מוכן לקבל מסמך חלופי או ראיית ביניים, ההסכמה הזאת צריכה להיות ברורה לפני שהחברה משנה את סדר הבדיקות.

היכן עובר גבול הבדיקה

בשני המסלולים, שם החברה לבדו אינו מגדיר מה נבדק. בדוח SOC 2 צריך לזהות את השירות ואת מערכת השירות המתוארת, לרבות רכיבים או ספקי משנה שמשפיעים על הבקרות שנכללו בבדיקה. בהסמכת ISO/IEC 27001 צריך לזהות את גבולות מערכת הניהול: הפעילויות, היחידות הארגוניות והממשקים הרלוונטיים. הגבולות האלה עשויים להיות שונים גם אם אותם עובדים מפעילים חלק מן הבקרות בשני המסלולים.

הבהרת קבוצת נוהלי הביקורת ל־ISO/IEC 27001 מסבירה שמערכת הניהול יכולה לחול רק על חלק מישות גדולה יותר, ושמסמך תחולת הבקרות מתעד את הבקרות הנחוצות ואת ההצדקה לבחירתן. לחברת SaaS עם כמה מוצרים או חברה קשורה, ההבחנה הזאת מעשית: תעודה שהיקפה מוגבל לפעילות אחת אינה מעידה כשלעצמה על כיסוי של הפעילות האחרת. לפני שמציגים תעודה לרוכש, צריך לוודא שההיקף המופיע בה תואם לשירות ולישות שבחוזה.

מה משתנה בין סוגי דוחות SOC 2

בקשה לדוח SOC 2 עדיין משאירה שאלה לגבי סוג הדוח. ההשוואה של EnterpriseDB מבחינה בין Type 1, שבוחן את תכנון הבקרות בנקודת זמן מוגדרת, לבין Type 2, שבוחן גם את יעילות הפעלתן לאורך התקופה המצוינת בדוח. לכן רוכש שדורש Type 2 לא קיבל את אותה ראיה אם החברה מציגה לו Type 1 בלבד.

ההבדל משפיע על התכנון התפעולי: לצורך בדיקה לאורך תקופה, בקרות צריכות לפעול ויש לשמור ראיות מתוארכות להפעלתן. כתיבת מדיניות סמוך למועד הביקורת אינה מתעדת בדיעבד את פעולת הבקרות. יש לקבוע עם הרוכש והמבקר מהי התקופה המצופה, אילו שירותים ייכללו בדוח והאם מסמך מוקדם יותר יתקבל בינתיים; תנאים אלה תלויים בעסקה ולא בשם המסגרת בלבד.

מתי צריך את שתיהן ומה אפשר לשתף

שני המסלולים נחוצים כאשר רוכש אחד דורש במפורש גם דוח וגם תעודה, או כאשר עסקאות שונות מתנות את ההתקשרות בתוצרים שונים. החברה אינה חייבת להפעיל שתי תוכניות אבטחה נפרדות: תיעוד הרשאות, שינויים, תקריות וסיכוני ספקים יכול לסייע בשתי הבדיקות, כל עוד הוא שייך להיקפים ולתקופות המתאימים. הערך של השיתוף נקבע לפי הבקרות שנבדקות בפועל, ולא לפי שיעור חפיפה כללי בין שמות המסגרות.

לצד הראיות המשותפות, כל מסלול דורש עבודה ייחודית. דוח SOC 2 נשען על תיאור מערכת השירות ועל בדיקה של הבקרות בה; הסמכת ISO/IEC 27001 נשענת על מערכת ניהול מוגדרת, על הערכת סיכונים ועל החלטות מנומקות לגבי בקרות. המבקר של דוח השירות וגוף ההתעדה של מערכת הניהול אחראים כל אחד לתוצר שלו. שימוש באותו רישום תפעולי עשוי לצמצם איסוף כפול, אך אינו מחליף אף אחת מהבדיקות.

אם דוח השירות דרוש לעסקה הקרובה, אפשר לקדם את הגדרת מערכת השירות ולהפעיל את הבקרות לתקופת הדוח, ובמקביל לבנות את תהליכי ניהול הסיכונים הדרושים להסמכה. אם התעודה נדרשת קודם, כדאי להגדיר במדויק את היקף מערכת הניהול ולשמור ראיות תפעוליות שעשויות להידרש לדוח עתידי. בהצעה משולבת לביקורת, יש להפריד בין הגופים המנפיקים, התוצרים, ההיקפים, התקופות והעבודה שאפשר לשתף.

כאשר דרישת לקוח נשענת על סעיף חוזי או על חובה משפטית מסוימת, הפרשנות של אותו סעיף דורשת בדיקה מקצועית של אנשי ביקורת וייעוץ משפטי מתאימים. הבחירה המסחרית מתחילה במסמך שהרוכש ביקש; תוכנית הבקרות הרחבה יותר צריכה להתאים גם לשירותים שהחברה מתכוונת לכלול בבדיקות הבאות.

קראו גם:

• 90% רוצים IT אוטונומי — 77% עדיין דורשים אישור אנושי