הסכם החזקה ועיבוד מידע

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

• תורים: שם וטלפון של מי שקבע, שם השירות, מחירו ומשכו כפי שהיו במועד הקביעה, מועד התור, נותן השירות המשויך, הסטטוס, מועד הקביעה, וסימון האם נשלחה תזכורת.
• רשימת המתנה: שם, טלפון, מועד מועדף והערה חופשית של מי שלא מצא תור פנוי וביקש שיחזרו אליו.
• כרטיס לקוח: מספר הטלפון, הערה חופשית שבעל העסק כותב על אותו לקוח, וסימון “חסום”. ההערה נכתבת בידי העסק ואינה מוצגת ללקוח.
• חשבון לקוח קצה (אופציונלי, רק אם הלקוח פתח כזה בעצמו): שם מלא ואימייל.
• המלצות: שם הממליץ, דירוג וטקסט — כפי שהעסק מזין אותם.
• סטטיסטיקת צפיות: מזהה העסק, סוג האירוע ומועד. אין בה שום מזהה אישי — לא שם, לא טלפון, לא כתובת IP.
• הסכמה לדיוור פרסומי — רק אם הלקוח סימן בעצמו את התיבה בטופס קביעת התור (היא אינה מסומנת מראש ואינה תנאי לקביעת תור): מספר הטלפון, נוסח ההסכמה המלא כפי שהוצג לו על המסך, גרסת הנוסח, מועד הסימון, ומועד הביטול אם ביקש להסיר את עצמו.

שתי הערות על הסכמות הדיוור, ושתיהן נוגעות לכם ישירות.
(א) הרשומה נעולה בפניכם בכוונה. אתם המפרסם, ועליכם נטל ההוכחה לפי סעיף 30א לחוק התקשורת — ורשומה שהצד הנתבע יכול לערוך אינה ראיה. לכן הטבלה אינה נגישה לחשבון שלכם כלל, גם לא לקריאה, ואינה נכללת בייצוא ה-CSV.
(ב) אבל אתם כן רואים את מה שצריך כדי לא לעבור על החוק. כרטיס הלקוח בלוח הבקרה מציג, לקריאה בלבד, “אישר/ה דיוור”, “ביקש/ה הסרה” או “לא אישר/ה”. את הרשומה המלאה — הנוסח, הגרסה והמועדים — נמסור לכם בכתב תוך 14 יום לפי בקשה, ובפרט כשהיא נדרשת לכם להליך. ראו סעיף 8.

המטרה — ורק היא

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

ומה לא מותר לנו לעשות בו — סעיף 3.

• המערכות: בסיס הנתונים של הפלטפורמה, מערכת ההזדהות ואחסון הקבצים (כולם ב-Supabase), וסביבת ההרצה והלוגים (Vercel).
• סוג העיבוד: אחסון, קריאה, הצגה, חישוב, עדכון סטטוס, ייצוא לקובץ ומחיקה — כולם לצורך אספקת השירות. בנוסף: העברה ליומן Google של העסק, אם וכאשר העסק חיבר אותו בעצמו.
• עיבוד ידני בידי אדם מטעם הספק נעשה רק כשהוא נדרש: תמיכה בבקשת העסק, בירור תקלה, או ביצוע בקשת ייצוא/מחיקה. אין “עיון שוטף” במידע של עסק.

זהו הסעיף המהותי של המסמך. הספק מתחייב במפורש:

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

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

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

החלפה או הוספה של ספק משנה

• נודיע לעסק בכתב, לפחות 14 יום מראש, לפני הוספה או החלפה של ספק משנה שנחשף למידע של לקוחות הקצה.
• העסק רשאי להתנגד בכתב בתוך אותם 14 יום. אם התנגד ואין חלופה סבירה — הוא רשאי לסיים את ההתקשרות בלי קנס, לפי סעיף 5 בתנאי השימוש.
• בהחלפה דחופה (ספק שנפל, פגיעת אבטחה אצלו) נפעל מיד ונודיע בתוך 3 ימי עסקים מרגע ההחלפה.
• כל ספק משנה חדש יהיה כפוף להתחייבויות מקבילות לאלה שבמסמך זה.

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

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

לאיזו רמת אבטחה המאגר מסווג — ולמה זה נוגע לכם

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

אבל התשתית אחת. בסיס נתונים אחד ומפתח שרת אחד משרתים את כל העסקים, ואי אפשר להפעיל בקרה על חלקם בלבד. תקנה 19 מחילה על המחזיק — כלומר עלינו — את חובות בעל המאגר, למעט מסמך הגדרות המאגר (תקנה 2) ותקנה 15(א). לכן הפלטפורמה נבנית לרמה הבינונית, מרגע שדייר אחד מייצר מאגר כזה. זו גם אמת המידה שלפיה נכתב “מה אין” למטה: מה שחסר, חסר ביחס לרמה הבינונית.

מה קיים

• בידוד בין עסקים ברמת בסיס הנתונים (RLS). כל טבלת נתונים נושאת מזהה עסק, ומדיניות אבטחה ברמת השורה מתירה גישה אך ורק לשורות של העסק שהמשתמש משויך אליו כאיש צוות פעיל. הבדיקה חלה גם על קריאה וגם על כתיבה — אי אפשר “להגניב” שורה לעסק זר. זה נאכף במסד, לא בממשק: פנייה ישירה למסד, בעקיפת המסכים, מקבלת בדיוק אפס שורות.
• הפרדת הרשאות בין בעלים לעובד. בעל העסק רואה את כל העסק; עובד עם חשבון התחברות רואה את עצמו בלבד — התורים שהוא נותן והשעות שלו. כרטיס לקוח נגיש לעובד רק ללקוחות שבאמת טופלו על ידו. רשימת ההמתנה, הגלריה, ההמלצות והסטטיסטיקה — לבעלים בלבד. גם זה אכוף במסד ולא בממשק.
• ייצוא הנתונים — לבעל העסק בלבד. כפתור שמוריד את רשימת הלקוחות כקובץ חסום בפני עובד, גם על התורים שלו עצמו.
• המפתח הציבורי של הדפדפן נעול לחלוטין. המפתח שמגיע לדפדפן אינו יכול לקרוא או לכתוב שום טבלה — הוא משמש להזדהות בלבד. כל הזרימה הציבורית (קביעת תור, חישוב זמינות) עוברת דרך קוד שרת שאוכף את חוקי העסק, ולא דרך המסד ישירות.
• מפתח השרת לעולם אינו נחשף לדפדפן. הוא מסומן בקוד כמפתח צד-שרת בלבד, ואינו חלק מהמשתנים שנארזים לצד הלקוח.
• סיסמאות אינן נשמרות אצלנו כטקסט קריא — הן מנוהלות במערכת ההזדהות של ספק בסיס הנתונים.
• קודי אימות חד-פעמיים: נשמרת רק טביעה חד-כיוונית של הקוד (HMAC-SHA256), לא הקוד עצמו, והטבלה נעולה כך שרק צד השרת ניגש אליה.
• אסימוני יומן Google מוצפנים במנוחה ב-AES-256-GCM עם מפתח שיושב במשתני הסביבה בלבד, ואינם נחשפים בדפדפן.
• קישור ניהול התור של לקוח קצה מוצפן. עד שנוסף המנגנון הזה אפשר היה לראות ולבטל תור של אדם אחר רק בידיעת מספר הטלפון שלו. היום הקישור נושא טוקן מוצפן (AES-256-GCM) שמספר הטלפון אינו מופיע בו, והוא קשור לעסק אחד בלבד — טוקן של עסק אחד לא ייפתח אצל עסק אחר.
• מחרוזת השאילתה נחתכת מכל נתיב שיוצא להתראה חיצונית, כדי שטוקן הניהול לא ידלוף לשירות חיצוני.
• הגבלת קצב על הטפסים הציבוריים (הרשמה, קביעת תור, רשימת המתנה). הספירה מוחזקת בזיכרון תהליך השרת, לפי כתובת IP שהפלטפורמה מציבה ולא כזו שהלקוח יכול לזייף. כתובת ה-IP אינה נכתבת לבסיס הנתונים ואינה מקושרת לתור, ללקוח או לחשבון.
• הגנה על קובץ הייצוא: תא שמתחיל בתו שגיליון אלקטרוני מפרש כנוסחה מנוטרל בייצוא, כדי ששם לקוח שהוזן בזדון לא יהפוך לקוד רץ אצל רואה החשבון של העסק.
• מניעת חפיפת תורים ואילוצי שלמות נאכפים במסד עצמו, כך שנתוני היומן נשארים עקביים.
• הנתונים יושבים באיחוד האירופי (פרנקפורט), ותעבורת הרשת מוצפנת.
• גישה של הספק לנתונים שלכם דרך קונסולת הניהול מתועדת ביומן גישה — מי ניגש, מתי, לאיזה משאב, והאם הגישה אושרה או נדחתה. היומן נשמר 24 חודשים ואינו ניתן למחיקה או לעריכה, וכניסה לקונסולה בלי רישום ביומן פשוט אינה אפשרית. אנחנו מיידעים אתכם על קיומו כאן כנדרש בתקנה 10(ה) לתקנות אבטחת מידע. היומן שומר מזהים ומספרים בלבד — לא שמות, לא טלפונים ולא תוכן הרשומות שנצפו. המנגנון נאכף בקוד, והכיוון שבו הוא נכשל הוא הכיוון הבטוח: אין יומן שאפשר לכתוב אליו, אין כניסה לקונסולה.

מה אין — במפורש

• אין הצפנה ייעודית ברמת השדה על שמות וטלפונים של לקוחות קצה. הם נשמרים כעמודות רגילות; ההגנה עליהם היא בקרת הגישה שלמעלה וההצפנה במנוחה של ספק בסיס הנתונים.
• יומן הגישה מכסה את גישת הספק בלבד, ולא גישה של בעל העסק או של הצוות לנתוני הלקוחות שלהם. אם ייווצר חשד שעובד צפה ברשומה שלא היה צריך, אין היום מקור לשחזר זאת. זהו פער פתוח. (היומן עצמו מתואר ברשימת “מה קיים” שלמעלה.)
• אין ניטור אוטומטי או התרעה על גישה חריגה. צינור ההתראות הקיים מתריע על תקלות יישום ולא על אירועי אבטחה, והוא תלוי בהגדרת ערוץ שקיימת בסביבת הייצור בלבד.
• אין אימות דו-שלבי לכניסת בעל העסק או העובד. הכניסה היא אימייל וסיסמה, או קוד חד-פעמי למייל.
• אין נוהל אבטחת מידע מאושר. קיימת אצלנו טיוטה כתובה שטרם אושרה ואינה בתוקף, ולכן החובה שבתקנה 4 — שחלה כבר ברמה הבסיסית ולא רק בבינונית — אינה מקוימת היום. ואין ביקורת תקופתית מתועדת: תקנה 16 מחייבת ברמה בינונית ביקורת אחת ל-24 חודשים לפחות, בידי גורם בעל הכשרה מתאימה שאינו ממונה האבטחה של המאגר — כלומר לא אנחנו על עצמנו. שניהם רשומים כפער פתוח.
• אין מסמך הגדרות מאגר (תקנה 2). אצלנו הוא אינו נדרש — תקנה 19 פוטרת ממנו את המחזיק במפורש — אבל אצלכם, כבעלי המאגר, הוא כן נדרש, ובכל רמת אבטחה. אין לו פטור לעסק קטן. זו החובה הזולה ביותר להשלים, ואיננו יכולים להשלים אותה במקומכם.
• אחסון הקבצים ציבורי. לוגו, באנר ותמונות גלריה נגישים לכל מי שמחזיק בקישור הישיר, גם בלי התחברות — כך הם מוצגים באתר. שום נתון של לקוח קצה אינו נשמר שם, ואין להעלות לשם תמונות או מסמכים שאינם מיועדים לפרסום.
• הגבלת הקצב אינה הרמטית — היא מוחזקת בזיכרון של כל מופע שרת בנפרד, ולכן היא מאטה הצפה ולא חוסמת אותה מוחלטת.

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

• מתי נודיע: ללא דיחוי, ולא יאוחר מ-24 שעות מהרגע שבו נודע לנו על האירוע, גם אם עדיין לא ידוע היקפו המלא. עדכון משלים יישלח ככל שהתמונה מתבררת.
• באיזה ערוץ: שיחת טלפון למספר שנמסר לנו, ובנוסף הודעה בכתב לכתובת האימייל הרשומה של העסק. הודעה בכתב תישלח תמיד, גם אם השיחה נענתה — כדי שתהיה לעסק ראיה מתועדת למועד ההודעה ולתוכנה.
• מה תכלול ההודעה: מה קרה, מתי התגלה, אילו סוגי מידע ואילו לקוחות עשויים להיות מעורבים, מה נעשה כדי לעצור את האירוע, ומה אנחנו ממליצים לעסק לעשות.
• מי מדווח לרשות: חובת הדיווח על “אירוע אבטחה חמור” לרשות להגנת הפרטיות מוטלת בדין על בעל השליטה במאגר — כלומר עליכם (בלשון תקנה 11: “בעל המאגר”), ולא עלינו. הרשות מנחה לדווח תוך 24 שעות מגילוי האירוע ובכל מקרה לא יאוחר מ-72 שעות. נמסור לעסק, ללא עלות, כל מידע שנדרש לו כדי לדווח ולעמוד בלוח הזמנים הזה.
• תיעוד: נתעד כל אירוע כזה — מה קרה, מתי התגלה, מה נעשה — ונעמיד את התיעוד לעיון העסק לפי בקשה.

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

החזרה — מה מקבלים ובאיזה פורמט

• בכל רגע, ובלי לבקש מאיתנו, בעל העסק מייצא מלוח הבקרה שני קבצים בפורמט CSV בקידוד UTF-8 (עם סימן סדר בייטים, כדי שעברית תיפתח נכון ב-Excel):

• קובץ התורים: תאריך ושעה · לקוח · טלפון · שירות · מחיר · משך בדקות · נותן שירות · סטטוס · מועד הקביעה.

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

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

השמדה — ומה קורה בפועל

• לבקשת מחיקה — תוך 14 יום. נמחקים העסק ואתרו, פרטי הבעלים, אנשי הצוות, השירותים והשעות, ההמלצות, רשומות הגלריה, רשימת לקוחות הקצה והיסטוריית התורים, כרטיסי הלקוח וההערות שבהם, רשימת ההמתנה, מנויי ההתראות ואסימוני Google.
• גם הראיות נמחקות. ההסכמות לדיוור של לקוחות הקצה ואישורי המסמכים המשפטיים מקושרים לרשומת העסק ונמחקים יחד איתה. לפני המחיקה מופק גיבוי מלא של כל מה שעומד להימחק, והוא נמסר לכם — הוא הראיה שנשארת בידיכם.
• מה שורד את המחיקה, ובמכוון מעט. אצלנו נשארת רשומה מצומצמת שאומרת שניתנה הסכמה — מאיזה סוג, באיזו גרסת נוסח, מתי ובאיזה עסק. בלי טלפון, בלי שם, בלי אימייל, בלי מזהה משתמש ובלי נוסח ההסכמה המלא. היא אינה מידע אישי ולכן אינה נגררת לחובת המחיקה, והיא קיימת מפני שתלונה יכולה להגיע אחרי שהעסק כבר נמחק. ⚠️ המחיר מוצהר: רשומה כזאת מוכיחה שהסכמות ניתנו, כמה ומתי — לא שאדם מסוים הסכים. את זה מוכיח הגיבוי שבידיכם, ולכן שמרו אותו.
• שתי רשומות על העסק עצמו — לא על לקוחותיו — שורדות גם הן. הודעת ביטול מנוי שנמסרה דרך לוח הבקרה, ורישום ההודעות ששלחנו לעסק. שתיהן אינן מכילות שום נתון של לקוחות הקצה, ולכן אינן בתחום המסמך הזה; מה בדיוק נשמר בהן, ולמה, מפורט ב־מדיניות הפרטיות סעיף 9.
• בלי בקשה, אחרי סיום ההתקשרות — 30 יום לשמירה שמאפשרת ייצוא או חרטה, ואז מחיקה.
• נאשר בכתב מה נמחק ומתי. אישור כזה יישלח תמיד, גם אם לא התבקש.
• מסמכים חשבונאיים (חשבוניות וקבלות) נשמרים כנדרש בדין גם אחרי מחיקת כל השאר. הם נוגעים לעסק, לא ללקוחות הקצה שלו.
• גיבויים: רשומה שנמחקה עשויה להוסיף להתקיים בעותק גיבוי עד שהעותק נדרס במחזור הגיבוי הרגיל. היא אינה משוחזרת משם אלא בתקלה בבסיס הנתונים כולו.

שלוש עובדות שצריך לומר, ולא לעגל.
(א) אין באתר כפתור “מחיקת החשבון”. מחיקה מתבצעת בבקשה במייל, בידי אדם.
(ב) אין תהליך אוטומטי שמריץ את מחיקת ה-30 יום. גם היא מבוצעת ידנית, ולכן היא תלויה בכך שסיום ההתקשרות נרשם ונזכר. זה רשום כפער פתוח.
(ג) מחיקת רשומת העסק אינה גוררת מאליה, ברמת בסיס הנתונים, את קבצי המדיה מהאחסון הציבורי ואת חשבון הכניסה במערכת ההזדהות — ולכן כלי המחיקה מטפל בשניהם כחלק מאותה הרצה, בלי שצריך לבקש אותם בנפרד, ורושם ביומן כמה קבצים וכמה חשבונות נמחקו. חשבון שמשמש גם עסק חי אחר אינו נמחק, כדי לא לנעול אדם מחוץ לעסק שאיש לא ביקש למחוק. ההבחנה שנשארת: מה שאינו ידני הוא הביצוע, לא ההרצה — ראו (ב).

• בכל עת, ובלי לנמק, רשאי בעל העסק לבקש ולקבל תוך 14 יום, בכתב: היכן מוחזק המידע, מי ספקי המשנה העדכניים, אילו אמצעי אבטחה חלים, האם היה אירוע אבטחה שנגע לעסק שלו, ומי מטעם הספק בעל גישה למידע.
• עותק של רשומות ההסכמה לדיוור — הן מוחזקות בטבלה נעולה שאינה נגישה לעסק, כדי שהראיה לא תהיה ניתנת לעריכה בידי מי שנהנה ממנה (סעיף 1). עותק שלה יימסר לכם בכתב תוך 14 יום לפי בקשה, ובפרט כשהוא נדרש לכם לצורך הליך.
• אחת לשנה לפחות, גם בלי שהתבקשנו, נמסור לעסק דיווח כתוב על קיום ההתחייבויות שבמסמך זה ועל שינויים שחלו — כנדרש בתקנה 15.
• העסק רשאי להסמיך גורם מקצועי מטעמו לבחון את ההסדרים. הבדיקה תתואם מראש, לא תפגע בשירות ליתר הלקוחות, ותהיה על חשבון העסק.
• נאמר לכם גם מה אין. אם בקרה מסוימת אינה קיימת — נאמר זאת במפורש ולא נעטוף אותה בניסוח מרגיע. סעיף 5 בנוי כך בכוונה.

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

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

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

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

• מסמך זה משלים את תנאי השימוש (ובפרט את סעיפים 7, 8 ו-11 שבהם) ואת מדיניות הפרטיות, ואינו בא במקומם.
• בכל סתירה בין מסמך זה לבין המסמכים האחרים בכל הנוגע לאופן ההחזקה של מידע לקוחות הקצה — מסמך זה גובר, כמסמך הספציפי לנושא. בכל יתר העניינים גוברים תנאי השימוש.
• שינוי מהותי במסמך זה יימסר לעסק לפחות 30 יום מראש, בהתאמה לסעיף 12 בתנאי השימוש.
• על מסמך זה חלים דיני מדינת ישראל בלבד, ובכללם חוק הגנת הפרטיות, התשמ״א-1981 ותקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017.
• ההסכם טעון אישור מתועד של העסק. עד שיוסדר אישור כזה, המסמך מפורסם כהצהרה מחייבת של הספק על אופן ההחזקה בפועל.

לכל שאלה על מסמך זה, לבקשת מידע לפי סעיף 8, לבקשת ייצוא או מחיקה, או לדיווח על אירוע אבטחה:

• אימייל: uribusinessacct@gmail.com
• טלפון: 054-3539750

ראו גם: תנאי שימוש · מדיניות פרטיות · הצהרת נגישות