קהילת הידע לעמותות

איך ממפים מי בעל השליטה, המחזיק והמעבד בכל מאגר מידע של העמותה?

מאת מדריך דוח בקליק · מדריך רשמי

· תפעול, פרטיות וכלים דיגיטליים

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

התשובה הקצרה

לא מתחילים מרשימת תוכנות ולא שואלים “אצל מי השרת”. מתחילים מכל פעולת עיבוד ומטרה:

  • מי מחליט למה אוספים או משתמשים במידע ובאילו דרכים מהותיות? זהו בדרך כלל בעל השליטה במאגר. בעמותה, בעל השליטה הוא בדרך כלל העמותה כתאגיד — לא יו״ר הוועד, המנכ״ל, מנהל המחשוב או הממונה על הגנת הפרטיות באופן אישי.
  • מי שהוא גורם חיצוני לעמותה ומעבד מידע בעבורה הוא “מחזיק” לפי ההגדרה שלאחר תיקון 13. המילה המקצועית “מעבד” שימושית במפה ובחוזים, אך בדין הישראלי יש לבדוק אם אותו מעבד הוא למעשה “מחזיק”.
  • מי שמקבל מידע וקובע בעצמו מטרה עצמאית לעיבוד אינו רק ספק מבצע; ביחס לפעולה הזאת הוא עשוי להיות בעל שליטה נפרד. אם העמותה וגוף אחר קובעים יחד את המטרות, ייתכן שהם בעלי שליטה יחד.
  • עובד או מתנדב שפועל בתוך מערך העמותה ובהרשאתה אינו “מחזיק” רק מפני שהוא נוגע במידע; הוא בעל הרשאה פנימי. ספק חיצוני אינו הופך לעובד פנימי רק מפני שמכנים אותו “פרילנסר”.
  • אותו גוף יכול להיות מחזיק בפעולה אחת ובעל שליטה עצמאי בפעולה אחרת. לכן מסווגים כל מטרה וזרימת מידע, ולא מדביקים לספק תווית אחת לכל ההתקשרות.

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

קודם מתקנים את המונחים

בעל שליטה במאגר מידע

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

סימנים שהעמותה היא בעלת השליטה:

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

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

מחזיק ומעבד

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

דוגמאות אפשריות:

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

“מעבד” יכול לשמש כתיאור תפעולי מקביל, במיוחד בחוזים בין־לאומיים, אך אסור להסתפק בו. במפה מוסיפים שדה מפורש: האם הגורם הוא מחזיק לפי החוק הישראלי, ולגבי איזו פעולה.

בעל שליטה נפרד או משותף

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

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

מנהל מאגר, DPO וממונה אבטחה

אל תכתבו אוטומטית את שם המנכ״ל כ“בעל השליטה”. לאחר תיקון 13 החובות שהיו מוטלות בחוק על מנהל מאגר בגוף פרטי חלות על בעל השליטה, והארגון הוא בעל השליטה. ממונה הגנת פרטיות מייעץ, מפקח, מדריך ומשמש איש קשר; הוא אינו מחליף את אחריות ההנהלה ואינו נעשה בעל השליטה מפני שמונה לתפקיד.

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

עץ החלטה לכל פעולה

עברו על כל שימוש במידע ושאלו לפי הסדר:

  1. מה המטרה המדויקת? “ניהול CRM” אינו מטרה; “ניהול קשר עם תורמים והפקת קבלות” כן.
  2. מי יזם וקובע את המטרה? אם העמותה — היא בעלת השליטה. אם גוף נוסף קובע עמה — בדקו שליטה משותפת.
  3. מי קובע רק אמצעים טכניים? ספק רשאי לבחור שרת או תוכנה ועדיין להיות מחזיק, כל עוד אינו משנה את מטרת העיבוד.
  4. האם הגורם חיצוני ומעבד רק בעבור העמותה ובהוראותיה? סווגו כמחזיק והחילו את תקנה 15.
  5. האם הוא רשאי להשתמש במידע למטרה משלו? הפרידו את הפעולה הזאת ובדקו בעל שליטה עצמאי, בסיס מסירה והודעה לאדם.
  6. האם הוא ספק משנה של המחזיק? רשמו אותו, את המדינה, השירות, סוג הגישה והאישור החוזי.
  7. האם מדובר באדם פנימי? רשמו כבעל הרשאה, עם תפקיד, היקף גישה ומועד סיום — לא כמחזיק.
  8. מי מקבל החלטה על עיון, תיקון, מחיקה ואירוע אבטחה? אם אין תשובה ברורה, המיפוי עוד לא שלם.

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

בונים מצאי אמיתי, כולל “מערכות צל”

אספו מידע מארבעה כיוונים במקביל:

  1. אנשים ותהליכים — כספים, גיוס משאבים, שירותים, עובדים, חברים, מתנדבים, אירועים ואתר.
  2. טכנולוגיה — כניסה אחודה, מחשבים, ענן, מסדי נתונים, טפסים, אנליטיקה, גיבויים, API וסביבות בדיקה.
  3. רכש וכספים — חשבוניות ספקים, כרטיסי אשראי, חידושי מנוי והסכמי שירות; כך מוצאים שירותים שה־IT אינו מכיר.
  4. הרשאות ונתונים בפועל — ייצוא משתמשים, מפתחות API, חשבונות שירות, תיקיות שיתוף, כתובות העברה אוטומטית וקבוצות דוא״ל.

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

השדות שצריכים להופיע במפת התפקידים

| שדה | מה רושמים | |---|---| | מזהה תהליך | קוד יציב, למשל DONOR-CRM-01 | | מטרה | למה העיבוד נדרש, בניסוח שאפשר להסביר לאדם | | אוכלוסייה | תורמים, עובדים, מוטבים, חברים, מתנדבים או מבקרים | | סוגי מידע | שדות מדויקים וסימון מידע בעל רגישות מיוחדת | | מקור | מהאדם, גוף אחר, מערכת ציבורית או הסקה | | בעל שליטה | שם התאגיד ומספרו; לא שם עובד | | שליטה משותפת | גוף נוסף, ההחלטות המשותפות וחלוקת המענה | | מערכות | מערכת מקור, ממשקים, ייצוא, גיבוי וסביבת בדיקה | | מחזיק/מעבד | שם משפטי מלא, תפקיד, סוג פעולה והוראות | | ספקי משנה | שם, שירות, מדינה, גישה ואישור | | מקבלים עצמאיים | מי מקבל למטרה משלו ומה בסיס המסירה | | העברה לחו״ל | מדינה, תשתית, מנגנון והגבלות | | בעלים תפעולי | עובד שאחראי לעדכון ולבקרה | | בעלי הרשאה | קבוצות גישה, לא רק “כל הצוות” | | חוזה | מספר הסכם, נספח תקנה 15, תוקף וביקורת אחרונה | | שמירה ומחיקה | אירוע התחלה, תקופה, גיבויים והוכחת מחיקה | | זכויות ופניות | מי מטפל בעיון, תיקון, מחיקה והתנגדות | | סטטוס רגולטורי | רישום, הודעה, מסמך הגדרות, DPO ורמת אבטחה | | אימות | מי בדק, מתי, ומה הראיה |

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

דוגמאות שמכריחות לחשוב לפי הפעילות

| תרחיש | סיווג התחלתי לבדיקה | |---|---| | העמותה מפעילה CRM בענן ובוחרת מטרות ושדות | העמותה בעלת שליטה; ספק ה־CRM והאירוח עשויים להיות מחזיקים | | משרד שכר מקבל נתוני עובדים ומפיק תלושים לפי הוראות העמותה | העמותה בעלת שליטה; המשרד מחזיק; בדקו ספקי משנה ואחסון | | רואה חשבון משתמש בחומר גם לצורך חובה מקצועית עצמאית | יש לפצל: שירות בעבור העמותה מול פעולות שבהן הדין או המטרה העצמאית קובעים תפקיד אחר | | עירייה ועמותה בונות יחד מאגר משתתפים לתוכנית וקובעות זכאות ושימושים | חשד לשליטה משותפת; צריך להגדיר החלטות, הודעה וזכויות | | העמותה מוסרת דיווח לרשות מכוח דין | הרשות אינה בהכרח מחזיק; היא עשויה להיות בעלת שליטה נפרדת מכוח סמכותה | | עובד עמותה מעלה רשימה לכלי מקוון בלי אישור | העובד אינו מחזיק, אך הכלי החיצוני עשוי להיות מחזיק לא מאושר והעיבוד עלול לחרוג מהרשאה | | מתנדב מקבל גישה זמנית למערכת | בעל הרשאה פנימי לפי תפקידו; נדרשים מינימום גישה, סודיות וסגירה במועד | | ספק סליקה משתמש במידע גם למניעת הונאה שלו | ייתכנו תפקידים שונים בכל פעולה; אין להסתפק בתווית אחת |

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

מה עושים עם כל מחזיק שמצאתם

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

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

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

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

בדיקת איכות למפה

מפה מוכנה רק אם אפשר להשיב ממנה במהירות:

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

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

מתי מעדכנים

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

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

מומלץ שהמפה תאושר בידי הנהלה, משפטי/פרטיות, אבטחת מידע והבעלים העסקי של התהליך. ה־DPO, אם מונה, מייעץ ומפקח לפי תפקידו; ההנהלה נשארת אחראית להחלטות ולמשאבים. גילוי הדעת הסופי של הרשות מיום 26.07.2026 מדגיש את תפקיד ה־DPO בקידום תרבות פרטיות, ייעוץ, הדרכה, בקרה וטיפול בפניות.

תוצר סיום מומלץ

שמרו ארבעה מסמכים מחוברים:

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

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

מקורות ואימות

המידע נבדק לאחרונה בתאריך .

  1. חוק הגנת הפרטיות, התשמ״א–1981 — main.knesset.gov.il
  2. שאלות ותשובות — תיקון מס׳ 13 לחוק הגנת הפרטיות — הרשות להגנת הפרטיות
  3. מהן חובותיו של בעל שליטה במאגר מידע — www.gov.il
  4. מדריך פעולה ליישום תקנה 15 — נוסח מעודכן בעקבות תיקון 13 — www.gov.il
  5. המדריך המלא ליישום תקנות הגנת הפרטיות (אבטחת מידע) — www.gov.il
  6. שאלות ותשובות — אחריות בעל מאגר ומחזיק לפי תקנות אבטחת מידע — www.gov.il
  7. חובת הודעה לרשות להגנת הפרטיות על מאגר מידע — www.gov.il
  8. גילוי דעת סופי בנושא מינוי ממונה הגנת פרטיות בעקבות תיקון 13 — www.gov.il

#פרטיות

לפרסומים נוספים בקהילת הידע