SOC 2 לחברות ישראליות: למה כל לקוח אמריקאי מבקש את זה

השיחה נראית מבטיחה. אנשי הפיתוח העסקי סגרו פגישה עם לקוח אנטרפרייז אמריקאי, ההדגמה עברה מצוין, והצד השני מדבר על פיילוט. ואז מגיע המייל מצוות הרכש או ה-Security של הלקוח, בשורה אחת: ״Please send over your SOC 2 report״. פתאום העסקה לא תלויה ביכולות המוצר אלא במסמך שאין לכם — ואף אחד בחברה לא בטוח מה בדיוק מבקשים. אם אתם חברת SaaS ישראלית שמוכרת (או רוצה למכור) לשוק האמריקאי, זה לא תרחיש נדיר — זו נקודת המפנה שכמעט כל חברה ישראלית מגיעה אליה. במאמר הזה נסביר מה זה SOC 2 באמת, במה הוא שונה מ-ISO 27001, איך נראה התהליך לחברה ישראלית, ואילו טעויות עולות זמן וכסף.

חמשת קריטריוני האמון (Trust Services Criteria)

SOC 2 בנוי על מסגרת שנקראת Trust Services Criteria (TSC) — קריטריוני אמון שה-AICPA הגדיר. יש חמישה, אבל הם לא שווים במעמדם:

• Security (אבטחה) — חובה. זהו הקריטריון היחיד שנכלל בכל דוח SOC 2 ללא יוצא מן הכלל. הוא מכיל את ה-Common Criteria (CC1–CC9): ניהול סיכונים, בקרת גישה, הגנה על מערכות, תגובה לאירועים ועוד. אם עושים SOC 2 — עושים אותו מול Security.
• Availability (זמינות) — אופציונלי. האם המערכת זמינה לשימוש כפי שהתחייבתם (SLA, מוכנות להתאוששות מאסון). רלוונטי במיוחד למוצרי SaaS שמוכרים זמינות גבוהה.
• Confidentiality (סודיות) — אופציונלי. האם מידע שסווג כסודי מוגן מפני חשיפה לא מורשית. שימו לב: זה שונה מ-Privacy — סודיות חלה על כל מידע רגיש עסקית, לא רק על מידע אישי.
• Processing Integrity (שלמות עיבוד) — אופציונלי. האם עיבוד הנתונים במערכת שלם, תקף, מדויק, בזמן ומורשה. רלוונטי למוצרים שמבצעים חישובים או עסקאות קריטיות (fintech, billing).
• Privacy (פרטיות) — אופציונלי. האם מידע אישי נאסף, נשמר ונמחק בהתאם למחויבויות שלכם. שימו לב שזה קריטריון אמריקאי — הוא לא מחליף עמידה בתיקון 13 הישראלי או ב-GDPR.

בפועל, רוב חברות ה-SaaS הישראליות מתחילות עם Security בלבד, ומוסיפות Availability ו-Confidentiality כשהלקוחות מבקשים. אין טעם לכלול את כל החמישה ״ליתר ביטחון״ — כל קריטריון שמוסיפים מרחיב את היקף הביקורת, את הראיות שצריך לאסוף ואת העלות.

Type I מול Type II — ולמה הלקוחות רוצים דווקא את השני

כשמדברים על SOC 2 חשוב להבחין בין שני סוגי דוחות, וההבדל ביניהם מהותי:

• Type I מעיד על תכנון הבקרות בנקודת זמן אחת. רואה החשבון בוחן האם הבקרות מתוכננות נכון ליום מסוים — האם קיים נוהל בקרת גישה, האם הוגדרה מדיניות, וכן הלאה. זה צילום מצב: ״ביום X, הבקרות שלכם נראות תקינות״.
• Type II מעיד על אפקטיביות הבקרות לאורך תקופה. רואה החשבון בוחן לא רק שהבקרה קיימת, אלא שהיא פעלה בפועל לאורך תקופת התצפית — לרוב בין 3 ל-12 חודשים (מינימום שלושה חודשים, נפוץ 6–12). הוא אוסף ראיות: לוגים, סקירות הרשאות תקופתיות, תיעוד הדרכות, כרטיסי אירוע.

כמעט תמיד, כשלקוח אמריקאי מבקש ״SOC 2״ הוא מתכוון ל-Type II. הסיבה פשוטה: Type I מוכיח שבניתם בקרה, אבל לא שהיא עובדת ביום-יום. Type II מוכיח שהבקרה חיה — שבכל חודש מישהו באמת סקר הרשאות, שהגיבויים באמת רצו, שאירועים באמת טופלו. זו בדיוק ההבטחה שלקוח אנטרפרייז צריך כדי לתת לכם את הדאטה שלו. Type I שימושי בעיקר כשלב ביניים: הוא מאפשר להראות התקדמות ללקוח בזמן שתקופת התצפית של Type II רצה.

SOC 2 מול ISO 27001 — האמת בלי שיווק

זו כנראה השאלה הנפוצה ביותר, וכבר נגענו בה במדריך ה-ISO 27001 שלנו. ההבדלים המבניים החשובים:

כלל האצבע מהשטח פשוט: הלקוחות שלכם קובעים. אם הצינור מכירות שלכם אמריקאי — SOC 2 Type II הוא מה שיבקשו. אם הוא אירופי, ישראלי או אסייתי — ISO 27001 הוא התקן שקל לצרף ל-RFP. חברות רבות שמוכרות לשני השווקים צריכות, בסופו של דבר, את שניהם.

התהליך לחברת SaaS ישראלית: ארבעה שלבים

מבחינה מעשית, הדרך ל-SOC 2 Type II עוברת בארבעה שלבים:

1. Readiness Assessment (הערכת מוכנות). בוחנים איפה אתם עומדים מול קריטריוני האמון שבחרתם, ומזהים פערים. זה המקום להחליט על ה-Scope — אילו מערכות ותהליכים הדוח יכסה — ועל אילו קריטריונים (Security בלבד? עם Availability?).
2. Gap Remediation (סגירת פערים). סוגרים את מה שחסר: כותבים מדיניות ונהלים, מטמיעים בקרות טכניות (MFA, ניהול הרשאות, ניטור), מסדירים ניהול ספקים. זה החלק שדורש הכי הרבה עבודה פנימית.
3. Observation Period (תקופת תצפית). לב הליבה של Type II. המערכת רצה בפועל ומייצרת ראיות לאורך התקופה שהוגדרה (לרוב 3–12 חודשים). כאן חשוב שהבקרות באמת יפעלו — לא רק שיהיו כתובות.
4. Audit (ביקורת). משרד רואי החשבון בוחן את הראיות, מראיין אנשים, ומפיק את הדוח. אם הכול תקין — יש בידכם דוח SOC 2 Type II להעביר ללקוחות.

מי יכול לבצע את הביקורת? והמקום של ״ישראל״ בתמונה

כאן נקודה שמבלבלת חברות ישראליות רבות. SOC 2 הוא תקן אמריקאי, וסמכות ה-AICPA קשורה לרישיון רואה חשבון (CPA). המשמעות: רק משרד רואי חשבון מוסמך יכול להפיק דוח SOC 2 תקף — לא חברת ייעוץ אבטחה, לא חברת תוכנה, ולא מבקר פנימי. חברת ייעוץ (כמונו) יכולה להכין אתכם, לבנות את הבקרות ולנהל את התהליך — אבל את חוות הדעת עצמה חותם רואה חשבון.

לחברה ישראלית יש בפועל כמה מסלולים: לעבוד ישירות עם משרד CPA אמריקאי (רבים מהם עובדים מרחוק עם לקוחות בכל העולם), או לעבוד עם משרד ישראלי המשויך לרשת רואי חשבון בינלאומית עם נוכחות בארה״ב. הנקודה החשובה: ודאו שהגורם שחותם על הדוח מוסמך להנפיק SOC 2 לפי תקני AICPA — זה מה שהלקוח האמריקאי יבדוק.

פלטפורמות אוטומציה של ציות: מה הן באמת עושות

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

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

מה יש בתוך הדוח — ולמה כדאי לקרוא את החריגים

דוח SOC 2 טיפוסי מכיל כמה חלקים: חוות דעת רואה החשבון (opinion), תיאור המערכת (System Description) — שאתם כותבים ומתאר מה המוצר עושה ואיך, הבקרות שהוגדרו, ותוצאות הבדיקה — מה רואה החשבון בדק ומה מצא. החלק הזה כולל גם חריגים (exceptions): מקרים שבהם בקרה לא פעלה כמצופה לאורך תקופת התצפית.

טיפ מהשטח: כשלקוח אנטרפרייז מקבל דוח SOC 2, אנשי ה-Security שלו קופצים ישר לחריגים. דוח בלי חריגים כלל אינו בהכרח סימן טוב — לפעמים הוא מעיד על Scope צר מדי או תקופת תצפית קצרה. דוח עם חריגים בודדים, שלכל אחד מהם יש הסבר של החברה על אופן הטיפול, לרוב אמין יותר. אל תיבהלו מחריג — נהלו אותו.

ריקוד ה-NDA: SOC 2 מול SOC 3

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

טעויות נפוצות של סטארטאפים ישראליים

• לחשוב שקניית הכלי = ציות. Vanta או Drata מאיצים את התהליך, לא מבצעים אותו. אחרי ההתקנה עדיין צריך לסגור פערים, לתפעל בקרות ולעבור ביקורת של CPA.
• להכניס ל-Scope את כל החברה במקום את המוצר. אין צורך לכלול מערכות שיווק פנימיות או מוצרים משניים. Scope רחב מדי מנפח את העבודה ואת העלות ללא ערך ללקוח.
• להתייחס לזה כאירוע חד-פעמי. SOC 2 הוא מחזורי — לרוב מתחדש שנתית. הבקרות צריכות להמשיך לפעול, כי תקופת התצפית של הדוח הבא כבר רצה. חברה שמרפה אחרי הדוח הראשון מגלה בשנה הבאה שהיא מתחילה כמעט מאפס.
• לדלג על תקופת התצפית. כפי שראינו — Type II דורש זמן אמת. אי אפשר לקצר אותו כשהעסקה בוערת.
• לבלבל בין SOC 2 ל-Privacy הישראלי. קריטריון ה-Privacy של SOC 2 הוא אמריקאי ואינו מכסה את חובות תיקון 13 או את ה-GDPR. אלו מסלולים נפרדים.

אז מתי SOC 2 ומתי ISO 27001?

כלל אצבע פשוט לפי שוק היעד:

• לקוחות בעיקר בארה״ב → התחילו ב-SOC 2 Type II (Security, ולפי הצורך Availability/Confidentiality).
• לקוחות בעיקר באירופה, ישראל או אסיה → התחילו ב-ISO 27001, תקן בינלאומי עם תעודה רשמית.
• שני השווקים → בנו תשתית בקרות אחת ממופה לשתי המסגרות, ותעדפו לפי מאיפה מגיעה העסקה הגדולה הבאה.

צ׳קליסט הכנה — מה לעשות השבוע

1. מפו מאיפה מגיעים הלקוחות שלכם (ארה״ב / אירופה / ישראל) — זה קובע SOC 2 מול ISO.
2. הגדירו Scope ראשוני: המוצר וסביבת הייצור בלבד, לא כל החברה.
3. החליטו על קריטריוני האמון: התחילו מ-Security, הוסיפו רק מה שלקוחות מבקשים.
4. בצעו Gap Assessment ראשוני — איפה אתם עומדים מול הבקרות הנדרשות.
5. אם אתם עתידים לצרוך גם ISO 27001 — מפו את הבקרות לשתי המסגרות עכשיו, לפני שאתם כותבים תיעוד.
6. תכננו את תקופת התצפית של Type II מראש — היא לא ניתנת לקיצור בדיעבד.
7. בחרו משרד CPA מוסמך להנפקת SOC 2 (אמריקאי או רשת בינלאומית עם נוכחות בארה״ב).
8. אם אתם שוקלים פלטפורמת אוטומציה — זכרו שהיא מאיצה, לא מחליפה את הביקורת או את סגירת הפערים.

השורה התחתונה

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

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