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

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

מהו Security Questionnaire?

Security Questionnaire הוא שאלון שנועד לאסוף מידע על רמת אבטחת המידע, הפרטיות והחוסן של ספק או נותן שירות חיצוני.

הוא יכול לכלול שאלות על:

• מדיניות אבטחת מידע.
• הרשאות וזהויות.
• MFA.
• הצפנה.
• Logging.
• Vulnerability Management.
• Incident Response.
• פרטיות.
• גיבויים והתאוששות.
• BCP.
• ספקי משנה.
• מחיקת מידע.
• הסמכות ותקנים.

המטרה אינה לקבל מהספק תשובה של "כן" או "לא".

המטרה היא להבין האם קיימים פערים שמשנים את רמת הסיכון של ההתקשרות.

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

שאלון אבטחת מידע הוא חלק מ-TPRM, לא התהליך כולו

אחת הטעויות הנפוצות היא לחשוב שברגע שספק מילא שאלון, ה-Vendor Assessment הסתיים.

בפועל, שאלון הוא רק מקור מידע אחד בתוך תהליך רחב יותר של Third-Party Risk Management – TPRM.

התהליך המלא כולל בדרך כלל:

• Classification– להבין את רמת הסיכון של הספק.
• Due Diligence– לאסוף ולבדוק מידע נוסף.
• Security Questionnaire– לקבל מידע ישירות מהספק.
• Evidence Review– לבחון מסמכים, הסמכות או ראיות מתאימות.
• Risk Assessment– להבין את המשמעות לארגון.
• Contracting– להכניס דרישות מתאימות להסכם.
• Monitoring– לעקוב אחרי הסיכון במהלך ההתקשרות.
• Offboarding– לסגור גישה ולהסדיר את המידע בסיום.

NIST SP 1326, שפורסם ביולי 2026, מחזק בדיוק את הנקודה הזו: Due Diligence הוא תהליך חקירתי של איסוף ובחינת מידע רלוונטי על ספק או מוצר כדי לאפשר החלטה מושכלת. כלומר, אין להסתמך רק על מה שהספק מספר על עצמו.

NIST SP 1326: כך מבצעים Due Diligence לספקי טכנולוגיה לפני ההתקשרות.

לא כל ספק צריך לקבל את אותו שאלון

זה אולי העיקרון החשוב ביותר.

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

לכן לפני ששולחים שאלון צריך לבצע Risk Classification.

כדאי להבין:

• איזה מידע הספק יקבל?
  מידע ציבורי, עסקי, אישי, פיננסי או רגיש?
• איזו גישה תהיה לו?
  גישה למערכת בודדת, API, SSO, חשבון Admin או גישה לתשתיות?
• כמה השירות קריטי?
  מה קורה אם הוא מושבת לשעה, ליום או לשבוע?
• האם הוא מעבד מידע אישי?
• האם קיימים ספקי משנה?
• האם הספק יכול להשפיע על הפעילות העסקית במקרה של Incident?
• על בסיס התשובות אפשר לבחור שאלון קצר, בינוני או מעמיק יותר.

מה צריך לכלול שאלון אבטחת מידע טוב?

Governance ומדיניות

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

לדוגמה:

• האם קיימת מדיניות אבטחת מידע?
  מי אחראי על הסייבר?
• האם מתקיימות ביקורות תקופתיות?
• האם קיימים תקנים או Attestations רלוונטיים?

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

Identity & Access Management

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

כדאי לבחון:

• האם קיים MFA.
• כיצד מנוהלות הרשאות Administrator.
• האם קיימת הפרדת תפקידים.
• כיצד מבוטלות הרשאות של עובדים שעוזבים.
• האם ניתן להתחבר באמצעות SSO.
• כיצד מנוהלות הרשאות Privileged.

בספק SaaS, שאלות אלה עשויות להיות משמעותיות לא פחות מהשאלה היכן המידע מאוחסן.

Data Security ופרטיות

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

כדאי לשאול:

• איזה מידע נשמר?
• האם המידע מוצפן?
• מהי מדיניות Retention?
• כיצד מתבצעת מחיקה?
• היכן נשמר המידע?
• האם נעשה שימוש במידע למטרות נוספות?
• האם קיימים Subprocessors?
• ומה קורה עם המידע לאחר סיום ההתקשרות?

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

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

תקנה 15 לתקנות הגנת הפרטיות: מה ארגונים חייבים לבדוק מול ספקים חיצוניים.

Vulnerability Management ואבטחת המערכת

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

לדוגמה:

• האם מתבצעות סריקות חולשות.
• כיצד מטופלות חולשות קריטיות.
• האם מתקיימים Penetration Tests.
• האם קיימת מדיניות Patch Management.
• כיצד מנוהלות חולשות ברכיבי צד שלישי.
• האם קיים Secure Development Lifecycle, כאשר מדובר בספק תוכנה.

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

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

Incident Response: מה יקרה אם הספק ייפגע?

זו אחת השאלות החשובות ביותר.

ספק יכול להציג מצב אבטחה מצוין ביום הבדיקה — ועדיין לחוות Incident בעתיד.

לכן כדאי לבחון:

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

CISA כוללת בתבניות שלה שאלות מפורשות על Incident Detection ועל תהליכים לפעולה במקרה של אירוע אבטחה.
מידע נוסף במאמר Cyber Incident Response: האם הארגון שלכם באמת מוכן לאירוע הסייבר הבא?

BCP ו-Recovery: מה יקרה אם השירות פשוט לא יעבוד?

Security Questionnaire לא צריך להתרכז רק בסודיות המידע.

עבור ספק קריטי, זמינות יכולה להיות הסיכון המרכזי.

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

לכן כדאי לשאול:

• האם לספק קיים BCP?
• האם קיימת תוכנית Disaster Recovery?
• האם Recovery נבדק בפועל?
• מהם יעדי ההתאוששות?
• כיצד הספק מתמודד עם אובדן תשתית או ספק מרכזי?

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

מידע נוסף במאמר BCP או DRP? מה נכון לארגון שלכם.

ספקי משנה: מי עוד נמצא מאחורי השירות?

בסביבת SaaS, ספק יחיד יכול להסתמך על שורה של שירותים נוספים:

• Cloud Provider
• Authentication Service
• Email Provider
• Payment Processor
• Analytics
• Support
• ספקי AI

לכן כדאי לשאול:

• מי הם ה־Subprocessors?
• אילו מהם מקבלים גישה למידע?
• האם הספק מודיע על שינוי?
• כיצד הוא בוחן אותם?
• מה קורה כאשר אחד מהם חווה Incident?

הספק שאנחנו מתקשרים איתו הוא לפעמים רק השכבה הראשונה.

ISO 27001 או SOC 2 אינם סוף הבדיקה

הסמכות ו-Attestations הן מקור מידע חשוב, אבל הן אינן מחליפות Risk Assessment.

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

לדוגמה:

• הוא יכול לאחסן מידע באזור גיאוגרפי שאינו מתאים לנו
• להשתמש בספק משנה שאינו מקובל
• לא להציע זמן Notification שתואם את הדרישות שלנו
• או לאפשר מודל הרשאות שאינו מתאים לרגישות המידע

לכן צריך להבחין בין:

"האם לספק יש בקרות?"

לבין:

"האם הבקרות שלו מספיקות ביחס לסיכון שהוא יוצר עבורנו?"

בקשו Evidence, לא רק תשובות

אחד השיפורים החשובים ביותר שניתן לבצע בשאלון ספקים הוא להפסיק להסתפק ב-Yes/No.

כאשר הדבר מוצדק לפי הסיכון, אפשר לבקש ראיות.

לדוגמה:

• תעודת ISO בתוקף
• SOC 2 Report
• תקציר Penetration Test
• מדיניות Incident Response
• מסמך BCP
• רשימת Subprocessors
• Data Processing Agreement
• מסמכים נוספים המתאימים לאופי השירות

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

שאלון אבטחת מידע לא צריך להיות מבחן שבו כולם מקבלים 100

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

תהליך Assessment צריך להיות מסוגל להפיק ממצאים.

למשל:

• Low Risk-הספק מאושר.
• Conditional Approval– נדרש תיקון או Mitigating Control.
• Risk Acceptance– הארגון מודע לפער ומקבל אותו.
• Further Assessment– נדרש בירור נוסף.
• Rejected– רמת הסיכון אינה מקובלת.

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

ומה עושים כאשר הספק עונה "לא"?

תשובת "לא" אינה בהכרח סיבה לפסול ספק, המשמעות בעיקר תלויה בסיכון.

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

לעומת זאת, אם ספק קריטי אינו מפעיל MFA למשתמשים בעלי הרשאות גבוהות, מדובר בפער מהותי יותר.

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

• דרישה לתיקון
• הגבלת הרשאות
• צמצום מידע
• בקרות מפצות
• סעיף חוזי
• Monitoring מוגבר
• או Risk Acceptance פורמלי

זו בדיוק הסיבה ששאלון צריך להיות מחובר ל-Risk Management.

גם השאלון עצמו צריך להשתנות לאורך זמן

• איום הסייבר משתנה
• שירותי SaaS משתנים
• רגולציה משתנה
• טכנולוגיות חדשות נכנסות לשימוש

לדוגמה, שאלון ספקים שלא מתייחס כיום ל־AI עשוי לפספס שאלות חשובות:

• האם הספק משתמש במידע שלנו לצורך Training?
• האם משתמשים ב-Generative AI במסגרת השירות?
• האם מידע נשלח לשירות AI חיצוני?
• מי הם ספקי המשנה בתחום הזה?

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

מה ההבדל בין Security Questionnaire ל-Due Diligence?

קל לבלבל בין שני המושגים.

• Security Questionnaire הוא כלי שבאמצעותו מבקשים מהספק מידע מובנה.
• Due Diligence הוא תהליך רחב יותר של איסוף, אימות והערכת מידע על הספק.

NIST SP 1326 מדגיש ש-Due Diligence צריך לכלול מחקר על מידע רלוונטי וזמין כדי לתמוך בהחלטות רכישה והתקשרות.

כלומר:

השאלון הוא רק חלק מהבדיקה, לא כל הבדיקה.

ומה ההבדל בין שאלון ספקים ל-TPRM?

גם כאן מדובר ברמות שונות.

שאלון אבטחת מידע = כלי.

Vendor Assessment = הערכת ספק מסוים.

TPRM = התהליך הארגוני המלא לניהול סיכוני צד שלישי לאורך מחזור החיים.

לכן TPRM כולל גם את מה שקורה אחרי שהשאלון הסתיים:

• Monitoring
• Incident Management
• Reassessment
• Contract Management
• Offboarding

מידע נוסף במאמר Third-Party Risk Management: הסיכון של הספקים שלא תמיד נמצאים ברשימת הסיכונים.

איך לבנות שאלון יעיל יותר?

אפשר להתחיל מחמישה עקרונות:

1. התאימו את השאלון לסיכון

אל תשלחו אותו שאלון לכל הספקים.

2. שאלו רק שאלות שמשפיעות על החלטה

אם אין משמעות לתשובה, כנראה שאין צורך בשאלה.

3. בקשו Evidence בנושאים קריטיים

בעיקר בספקים בעלי רמת סיכון גבוהה.

4. הגדירו מראש כיצד מתייחסים לפערים

מי מאשר, מי מקבל Risk ומתי נדרש תיקון.

5. חברו את השאלון למחזור החיים של הספק

Assessment, חוזה, Monitoring ו-Offboarding.

10 תחומים שכדאי לכלול בשאלון ספק משמעותי

1. Governance ומדיניות אבטחת מידע.
2. Identity & Access Management.
3. Data Protection והצפנה.
4. Privacy.
5. Vulnerability & Patch Management.
6. Secure Development, כאשר רלוונטי.
7. Logging ו־Monitoring.
8. Incident Response.
9. BCP ו־Disaster Recovery.
10. Subprocessors וספקי צד רביעי.

אין משמעות לכך שכל שאלון יכיל בדיוק את אותם סעיפים.

החשוב הוא שהשאלון ישקף את פרופיל הסיכון של ההתקשרות.

כיצד אינפוגארד יכולה לסייע?

אנחנו באינפוגארד עוזרים לארגונים לבנות ולשפר תהליכי Vendor Security Assessment ו-Third-Party Risk Management, לרבות בניית שאלוני אבטחת מידע מותאמים לרמות סיכון, סיווג ספקים, בדיקת התשובות והראיות, זיהוי פערים וגיבוש דרישות לתיקון.

ניתן להתאים את התהליך גם לספקי SaaS, שירותי Cloud וספקים של מחלקות HR, כספים, משפטית ושיווק, ולחבר אותו לדרישות תקנה 15, לתהליכי Due Diligence ולניהול הסיכונים הארגוני.

המטרה אינה להוסיף עוד שאלון לתהליך הרכש.

המטרה היא לקבל מידע שמאפשר לארגון לקבל החלטה טובה יותר לגבי הספק.

בודקים ספק לפני שנותנים לו גישה למידע ולמערכות – שאלון אבטחת מידע לספקים

Security Questionnaire הוא כלי חשוב לבדיקת ספקים, אך הוא אפקטיבי רק כאשר הוא מותאם לרמת הסיכון ומחובר לתהליך קבלת החלטות. שאלון טוב בוחן לא רק תקנים אלא גם הרשאות, מידע, Incident Response, BCP, ספקי משנה ויכולת התאוששות.
השאלון צריך להיות חלק מ־TPRM ומ־Due Diligence רחבים יותר, הכוללים אימות מידע, בחינת פערים, דרישות חוזיות, Monitoring ו־Offboarding.
בסופו של דבר, המטרה אינה לדעת כמה שאלות הספק הצליח לענות עליהן, אלא האם אנחנו מבינים את הסיכון שאנחנו מקבלים יחד איתו.

מקורות

• מערך הסייבר הלאומי, מדריך שאלון ספקים לחיזוק שרשרת אספקה – שאלון 1.4, עודכן 16.7.2026. המדריך מגדיר את שאלון הספקים ככלי להערכת סיכונים ולהבנת רמת ההגנה של הספק.
• הרשות להגנת הפרטיות, מדריך פעולה ליישום תקנה 15 לתקנות הגנת הפרטיות בעת התקשרות עם גורם חיצוני, כולל נספח שאלון לבדיקת היבטי אבטחת המידע של הספק.
• הרשות להגנת הפרטיות, הנחיות בנושא תקנה 15, לרבות התאמת שאלון הבדיקה לטיב השירות, למידע ולסיכון הנובע מההתקשרות.
• NIST, SP 1326 – Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, יולי 2026.
• CISA, Vendor Supply Chain Risk Management Template ו־Assisting SMBs Assess Vendors and Suppliers, הכוללים תחומי בדיקה בנושאי מדיניות, פרטיות, הרשאות, Incident Response ו־Recovery.

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה ייעוץ מקצועי, רגולטורי, משפטי או טכנולוגי.

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

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך בעזרת בינה מלאכותית ואנושית על ידי רועי קיש, חובב פרטיות, אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).