מדיניות פרטיות לאפליקציה צריכה להסביר למשתמש בצורה ברורה איזה מידע נאסף עליו, כיצד הוא נאסף, למה משתמשים בו, למי הוא עשוי להימסר, כמה זמן הוא נשמר ומהן האפשרויות העומדות לרשותו ביחס למידע. אבל באפליקציה הבדיקה אינה מסתיימת בפרטים שהמשתמש מקליד בטופס ההרשמה. צריך לבחון גם הרשאות למיקום, מצלמה, מיקרופון ותמונות, מידע טכני מהמכשיר, כלי אנליטיקה, שירותי פרסום ורכיבי תוכנה של צדדים שלישיים.
בישראל, חוק הגנת הפרטיות לאחר תיקון 13 מגדיר “מידע אישי” באופן רחב כנתון הנוגע לאדם מזוהה או לאדם שניתן לזהותו, לרבות באמצעות מזהים מקוונים ונתוני מיקום. התיקון גם הרחיב את חובת היידוע בעת איסוף מידע אישי.
בנוסף לדין הישראלי, אפל וגוגל מציבות דרישות משלהן. אפל דורשת מדיניות פרטיות והצהרה על נוהגי המידע של האפליקציה ושל רכיבי צד שלישי המשולבים בה; גוגל דורשת מדיניות פרטיות ו־Data safety שמשקפים את איסוף המידע, השימוש בו והשיתוף שלו בפועל.
לכן השאלה מה צריכה לכלול מדיניות פרטיות לאפליקציה אינה נענית באמצעות תבנית כללית. צריך להתחיל במה שהאפליקציה עצמה עושה.
מדיניות הפרטיות מתחילה במיפוי האפליקציה, לא בניסוח משפטי
נניח שאפליקציה מבקשת מהמשתמש שם, מספר טלפון וכתובת דואר אלקטרוני. קל יחסית לזהות את הפרטים האלה כמידע שנאסף. אבל מאחורי המסכים יכולים לפעול גם שירותי אנליטיקה, מערכת התראות, כלי זיהוי תקלות, ספק התחברות חיצוני ורכיב שמקבל מידע טכני על המכשיר.
מבחינת המשתמש מדובר באפליקציה אחת. מבחינת הפיתוח, כל אחד מהרכיבים האלה יכול להיות מערכת נפרדת. לכן לפני שמנסחים מדיניות פרטיות צריך להבין את זרימת המידע כולה: איזה מידע נכנס, מאיפה הוא מגיע, לאילו מערכות הוא עובר ומי יכול לגשת אליו.
זו גם הסיבה שמדיניות פרטיות לא צריכה להיכתב רק על סמך צילומי המסכים של האפליקציה. חלק משמעותי מעיבוד המידע מתרחש מאחורי הקלעים, ולעיתים אפילו צוות השיווק או בעל המוצר אינם מודעים לכל מה שה־SDKs והכלים הטכנולוגיים אוספים.
באפליקציה אפשר לאסוף מידע גם בלי שהמשתמש ממלא טופס
אדם יכול לפתוח אפליקציה, לא להקליד אפילו מילה אחת, ועדיין להיווצר מידע הנוגע אליו.
האפליקציה עשויה לקבל נתונים על סוג המכשיר, מערכת ההפעלה, כתובת רשת, מזהים מקוונים, פעילות בתוך האפליקציה, זמני התחברות, מסכים שנצפו ונתוני תקלות. בחלק מן המקרים המידע עשוי לשמש לאבטחה ולתפעול, ובמקרים אחרים לסטטיסטיקה, פרסום או התאמה אישית של השירות.
תיקון 13 הרחיב והבהיר את ההגדרה של מידע אישי כך שהיא כוללת כל נתון הנוגע לאדם מזוהה או לאדם שניתן לזהותו במאמץ סביר, לרבות באמצעות מזהה מקוון או נתוני מיקום. לכן אין להניח שמידע הוא חסר משמעות מבחינת פרטיות רק משום שלא מופיע בו שם מלא.
המדיניות צריכה לשקף את סוגי המידע הרלוונטיים באמת ולא להסתפק במשפט כללי שלפיו “ייתכן שנאסוף מידע טכני”.
הרשאה למצלמה או למיקום אינה מדיניות פרטיות
אפליקציות רבות מבקשות גישה למשאבים במכשיר: מצלמה, מיקרופון, תמונות, אנשי קשר או מיקום. המשתמש רואה חלון של מערכת ההפעלה ולוחץ “אפשר” או “אל תאפשר”.
אבל ההרשאה הטכנית הזאת אינה תחליף להסבר רחב יותר על השימוש במידע. אם משתמש מאפשר גישה למיקום כדי למצוא עסק קרוב, עדיין צריך להבין האם המיקום נשלח לשרת, האם הוא נשמר, האם הוא משמש גם לסטטיסטיקה והאם הוא מועבר לגורם נוסף.
אפל מדגישה כיום כי בקשות הרשאה למשאבים מוגנים צריכות לכלול הסבר ברור ומדויק על מטרת השימוש, וכי אפליקציות צריכות לבקש רק מידע הרלוונטי לפונקציונליות שלהן.
לכן יש שלוש שכבות שצריכות להתיישב זו עם זו: מה האפליקציה עושה בפועל, מה המשתמש רואה בעת בקשת ההרשאה ומה שכתוב במדיניות הפרטיות.
דוגמה: אפליקציה שמבקשת מיקום
נניח שאפליקציה מציגה למשתמש מסעדות או בעלי מקצוע שנמצאים בקרבתו. היא מבקשת גישה למיקום ומציגה הודעה שלפיה המידע דרוש כדי להציג תוצאות רלוונטיות.
אם המיקום משמש רק באותו רגע לצורך החיפוש ואינו נשמר, זו תמונה אחת. אם האפליקציה שומרת היסטוריית מיקומים במשך חודשים, משתמשת בה לבניית פרופיל או מעבירה אותה למערכת פרסום, מדובר בפעילות אחרת לחלוטין.
הכותרת “גישה למיקום” אינה מספיקה כדי לתאר את ההבדל. מדיניות הפרטיות צריכה להסביר את מטרת השימוש ואת אופן הטיפול במידע במידה המתאימה לפעילות האמיתית.
גם אפל עצמה קובעת ששירותי מיקום צריכים לשמש כאשר הם רלוונטיים ישירות לתכונות ולשירותים שמציעה האפליקציה ושיש להסביר למשתמש את המטרה.
SDK של צד שלישי יכול לאסוף מידע בשם האפליקציה
אחת הנקודות החשובות ביותר במדיניות פרטיות לאפליקציה היא רכיבי צד שלישי.
מפתח יכול לשלב כלי למדידת שימוש, מערכת פרסום, שירות לזיהוי תקלות או כלי התחברות באמצעות כמה שורות קוד. מבחינת המשתמש, הוא מתקשר עם האפליקציה שלכם. אבל אותו רכיב יכול לקבל מידע ישירות מהמכשיר ולהעביר אותו לחברה חיצונית.
לכן לא מספיק לשאול את צוות הפיתוח: “איזה מידע אנחנו שומרים בשרת שלנו?” צריך לבדוק גם איזה מידע נשלח באמצעות שירותים חיצוניים.
אפל דורשת במפורש שהצהרות הפרטיות ב־App Store יכללו גם את נוהגי המידע של צדדים שלישיים שקוד שלהם משולב באפליקציה. גם Google Play מטילה על המפתח אחריות לדווח על איסוף ושיתוף מידע שמתבצעים באמצעות ספריות ו־SDKs.
אפל דורשת יותר ממסמך שמופיע באתר
באפליקציה שמופצת דרך App Store, מדיניות הפרטיות היא גם חלק מדרישות ההפצה של אפל.
אפל דורשת כתובת למדיניות פרטיות עבור אפליקציות ומחייבת את המפתח למסור ב־App Store Connect מידע על סוגי המידע שנאספים ועל אופן השימוש בהם. הפרטים האלה משמשים להצגת מידע למשתמש בעמוד האפליקציה בחנות.
המשמעות היא שיכולים להתקיים במקביל שלושה מקורות מידע: מדיניות הפרטיות, ההצהרות שמולאו ב־App Store Connect והאפליקציה עצמה. אם המדיניות אומרת דבר אחד, הצהרת App Privacy אומרת דבר אחר והקוד עושה דבר שלישי — קיימת בעיה.
אפל אף דורשת שמדיניות הפרטיות תתייחס לאיסוף, שימוש ושיתוף במידע, וכן למדיניות שמירה ומחיקה ולדרך שבה משתמש יכול לבטל הסכמה או לבקש מחיקת מידע.
גם Google Play דורשת התאמה בין המדיניות לבין Data safety
Google Play דורשת לכל אפליקציה מדיניות פרטיות נגישה מתוך האפליקציה ומקושרת גם דרך Play Console. המדיניות צריכה להסביר כיצד האפליקציה ניגשת למידע משתמש ומכשיר, אוספת אותו, משתמשת בו ומשתפת אותו.
בנוסף, מפתחים נדרשים למלא את אזור ה־Data safety שבו הם מצהירים אילו סוגי מידע נאספים, האם הם משותפים ומה מטרת השימוש. המפתח אחראי לכך שההצהרות יהיו מדויקות ומעודכנות, והן צריכות להתאים למדיניות הפרטיות ולפעילות האפליקציה בפועל.
לכן אין נכון להכין קודם מדיניות פרטיות באמצעות תבנית ורק לאחר מכן לנסות להתאים אליה את תשובות החנות. שני הדברים צריכים לצאת מאותו מיפוי של פעילות המידע.
איזה מידע צריכה המדיניות לתאר?
אין רשימה זהה לכל אפליקציה, משום שהמידע תלוי במוצר. באפליקציה אחת ייאספו רק כתובת דואר אלקטרוני וסיסמה, ובאחרת יכולים להיאסף מיקום, תמונות, היסטוריית רכישות, תוכן שהמשתמש מעלה ונתוני שימוש.
המדיניות צריכה לתאר את הקטגוריות הרלוונטיות בצורה שהמשתמש יכול להבין. אין צורך להפוך אותה למסמך טכני שמתאר כל משתנה בקוד, אך גם לא נכון להשתמש רק במונחים רחבים כמו “מידע שונה” או “נתונים טכניים” כאשר בפועל האפליקציה אוספת מידע משמעותי.
כדאי גם להבחין בין מידע שהמשתמש מוסר בעצמו לבין מידע שנאסף כתוצאה מהשימוש באפליקציה ומידע שמתקבל מגורמים אחרים. ההבחנה הזאת עוזרת להסביר למשתמש מאיפה מגיע המידע גם כאשר הוא אינו זוכר שמסר אותו ישירות.
לא פחות חשוב להסביר למה משתמשים במידע
רשימה של סוגי מידע לבדה אינה מדיניות פרטיות מלאה.
אותו מספר טלפון יכול לשמש לאימות חשבון, לשירות לקוחות, לאבטחה או למשלוח פרסום. מיקום יכול לשמש להצגת תוצאה קרובה או לניתוח התנהגות לאורך זמן. לכן חשוב לחבר בין סוג המידע לבין מטרות השימוש בו.
חובת היידוע לפי סעיף 11 לחוק הגנת הפרטיות עוסקת בין היתר במטרה שלשמה מבוקש המידע, בזהות בעל השליטה ובדרכי ההתקשרות עמו, בגורמים שאליהם עשוי המידע להימסר ובמטרות המסירה, וכן בזכויות העיון והתיקון. תיקון 13 הרחיב במפורש את הפרטים שיש למסור במסגרת החובה.
לכן גם באפליקציה חשוב להימנע מניסוח שמבקש “הסכמה לכל שימוש עתידי שנחליט עליו”. השימוש בפועל צריך להתיישב עם מה שנמסר למשתמש.
שינוי מטרת השימוש יכול לחייב בחינה חדשה
נניח שאפליקציה אוספת כתובת דואר אלקטרוני כדי לפתוח חשבון. לאחר כמה חודשים מחליטה החברה להשתמש בכל כתובות הדואר כדי לשווק שירות של חברה אחרת.
העובדה שהמידע כבר נמצא בידי האפליקציה אינה אומרת שכל שימוש חדש בו מותר אוטומטית. צריך לבחון לאיזו מטרה הוא נאסף, מה הוסבר למשתמש ואיזה בסיס קיים לשימוש החדש.
הבעיה הזאת נפוצה במיוחד בחברות שמתפתחות במהירות. מוצר שהתחיל ככלי פשוט יכול להפוך בהמשך לפלטפורמה גדולה עם מודל עסקי שונה לחלוטין. מדיניות הפרטיות צריכה להתעדכן יחד עם השינויים, אבל שינוי המסמך בדיעבד אינו בהכרח מכשיר שימוש שלא היה חלק מן ההסכמה או מהבסיס המשפטי המקורי.
מידע רגיש דורש תשומת לב גבוהה יותר
לא כל סוגי המידע יוצרים אותו סיכון.
אפליקציות בתחום הבריאות, הכושר, הפיננסים, היכרויות או שירותים משפחתיים יכולות לעבד מידע אינטימי או משמעותי במיוחד. תיקון 13 משתמש כיום במונח “מידע בעל רגישות מיוחדת” ומונה קטגוריות שונות של מידע שדורשות תשומת לב מוגברת.
במוצר כזה מדיניות הפרטיות אינה צריכה רק להיות ארוכה יותר. חשוב לבחון אם מלכתחילה נדרש לאסוף כל נתון, מי יכול לגשת אליו, לאילו ספקים הוא עובר וכמה זמן הוא נשמר.
גם הרשאת מערכת אינה צריכה להפוך לאיסוף בלתי מוגבל. אם אפליקציה צריכה צילום אחד לצורך פונקציה מסוימת, אין משמעות הדבר שהיא זקוקה לגישה רחבה לכל ספריית התמונות של המשתמש.
מדיניות הפרטיות צריכה להתייחס לשיתוף עם גורמים אחרים
אפליקציה כמעט אף פעם אינה פועלת לבד. ספק ענן יכול לאחסן מידע, מערכת תשלומים יכולה לקבל פרטי עסקה, ספק דיוור יכול לשלוח הודעות ושירות אנליטיקה יכול לקבל נתונים על השימוש.
כאשר מידע מועבר לגורמים נוספים, צריך לבחון כיצד לתאר את השיתוף ואת מטרתו. אין חובה להפוך את המדיניות לאינדקס אינסופי של כל ספק טכנולוגי, אבל המשתמש צריך להבין את התמונה המהותית של מי עשוי לקבל מידע ולשם מה.
גם כאן כדאי להיזהר ממשפטים רחבים מדי כמו “אנו רשאים להעביר את המידע לכל צד שלישי לפי שיקול דעתנו”. מדיניות פרטיות אמורה ליצור שקיפות ולא לשמש היתר כללי לכל פעולה אפשרית.
כמה זמן נשמר המידע?
זו שאלה שמדיניות פרטיות רבות כמעט אינן מתייחסות אליה, למרות שהיא חשובה במיוחד באפליקציות.
עסק יכול לצבור במשך שנים חשבונות לא פעילים, היסטוריית מיקום, לוגים, תמונות ומידע על פעילות משתמשים בלי לעצור ולשאול אם עדיין קיימת הצדקה לשמור אותם.
תקופת שמירה אינה חייבת תמיד להיות מספר מדויק של ימים. בחלק מהמקרים ניתן להסביר לפי אילו שיקולים נקבעת תקופת השמירה או אילו סוגי מידע נשמרים למשך תקופות שונות.
אפל עצמה דורשת ממדיניות הפרטיות להסביר את מדיניות שמירת המידע ומחיקתו.
מחיקת חשבון ומחיקת מידע אינן תמיד בדיוק אותו דבר
משתמש שלוחץ “מחק חשבון” מצפה בדרך כלל שהקשר עם האפליקציה יסתיים ושמידע המשויך לחשבון לא יישאר ללא סיבה.
אבל יש מקרים שבהם חלק מהמידע צריך להישמר לאחר סגירת החשבון, למשל לצורך חובה משפטית, התחשבנות, מניעת הונאה או טיפול במחלוקת קיימת. לכן מדיניות הפרטיות צריכה להבחין בין מחיקה לבין מידע שנשמר כדין מסיבה מוגדרת.
מעבר לדין המקומי, החנויות קובעות דרישות ברורות. אפליקציות באפל שמאפשרות יצירת חשבון חייבות לאפשר למשתמש ליזום מחיקת חשבון מתוך האפליקציה.
Google Play דורשת באפליקציות שמאפשרות יצירת חשבון גם אפשרות נגישה ליזום מחיקה מתוך האפליקציה וגם משאב חיצוני, למשל עמוד אינטרנט, שבאמצעותו ניתן לבקש מחיקה. הקפאת החשבון בלבד אינה נחשבת למחיקה.
הזכות לעיין במידע ולתקן אותו צריכה לקבל ביטוי מתאים
חוק הגנת הפרטיות מקנה, בכפוף להוראות החוק, זכויות עיון ותיקון במידע אישי. לאחר תיקון 13, עצם קיומן של הזכויות האלה הוא גם חלק מן הפרטים שחובת היידוע צריכה לכלול.
המשמעות אינה שכל אפליקציה חייבת לבנות מיד מסך מורכב שבו ניתן להוריד את כל המידע. הדרך שבה מטפלים בבקשה תלויה במוצר ובדין.
עם זאת, מדיניות פרטיות צריכה לפחות להסביר בצורה ברורה כיצד ניתן לפנות בנושאי פרטיות ומי הגורם שאחראי לטיפול בפנייה. כתובת כללית שאיש אינו בודק אינה מנגנון פרטיות אפקטיבי.
אבטחת מידע אינה מסתכמת במשפט "אנו נוקטים אמצעי אבטחה"
מדיניות פרטיות יכולה לכלול הסבר כללי על שמירת המידע ואמצעי ההגנה, אבל היא אינה תחליף לעמידה בפועל בחובות אבטחת המידע.
אפליקציה יכולה לפרסם מדיניות מרשימה ובמקביל לשמור מידע ללא הרשאות מתאימות, לאפשר גישה רחבה מדי לעובדים או להמשיך להחזיק חשבונות ישנים שאין בהם צורך. לכן הבדיקה המשפטית צריכה להסתכל גם על המתרחש בתוך המערכות.
מצד שני, אין צורך לפרסם במדיניות פרטים טכניים שעלולים לסייע לתוקף. המטרה היא להסביר למשתמש באופן סביר כיצד המידע מטופל, לא לחשוף את ארכיטקטורת האבטחה של המערכת.
מדיניות פרטיות לאפליקציה לילדים אינה עוד מדיניות רגילה
אם האפליקציה מיועדת לילדים או שחלק משמעותי מן המשתמשים בה הם קטינים, נדרשת בדיקה נפרדת.
השאלה אינה רק איזה מידע נאסף, אלא גם עד כמה המשתמש מסוגל להבין את ההסבר, כיצד מתקבלת הסכמה, אילו כלי פרסום משולבים ומה עושים SDKs של צדדים שלישיים.
בנוסף לדין הישראלי, חנויות האפליקציות מפעילות כללים מיוחדים לגבי אפליקציות לילדים. לכן מסמך שהוכן לאפליקציה כללית למבוגרים אינו בהכרח מתאים למוצר שפונה לקטינים.
מדיניות הפרטיות צריכה להתאים גם למסך ההרשמה
אחד הפערים הנפוצים הוא שמדיניות הפרטיות עצמה מפורטת, אבל המשתמש מוסר מידע במסך שבו אין כמעט הסבר.
כאשר האפליקציה מבקשת מידע אישי, צריך לבחון כיצד מתקיימת חובת היידוע בעת האיסוף. עצם העובדה שקיים קישור למדיניות הפרטיות בתפריט ההגדרות אינה בהכרח מספיקה לכל מצב.
לפעמים נכון לתת הסבר קצר ליד השדה או הטופס ולהפנות למדיניות המלאה. במקרים אחרים יש צורך בהסכמה נפרדת. השאלה תלויה בסוג המידע, במטרה ובאופן שבו האפליקציה מתכוונת להשתמש בו.
לא כל שימוש במידע מחייב תיבת סימון
יש נטייה לחשוב שכל סוגיית פרטיות נפתרת באמצעות תיבה של “אני מאשר את מדיניות הפרטיות”.
אבל מדיניות פרטיות היא קודם כול מסמך שקיפות, ולא כל שימוש במידע מבוסס בהכרח על אותה צורת הסכמה. גם כאשר נדרשת הסכמה, היא צריכה להיות קשורה לשימוש שהוסבר למשתמש ולא להפוך להרשאה כללית לכל פעולה בעתיד.
לכן לא נכון להוסיף תיבת סימון רק כדי “להיות מכוסים”. צריך להבין למה נאסף המידע, מה נדרש לפי הדין ומה המשתמש באמת מאשר.
כך גם לגבי הרשאות מערכת: אישור למצלמה, מיקום או מיקרופון הוא פעולה ספציפית של המשתמש ואינו תחליף לבחינת השימושים הנוספים שעשויים להיעשות במידע לאחר מכן.
מה קורה אם האפליקציה משתמשת בבינה מלאכותית?
יותר ויותר אפליקציות שולחות טקסט, תמונות, הקלטות או מידע אחר לשירותי בינה מלאכותית חיצוניים.
מבחינת פרטיות, עצם העובדה שהמשתמש רואה בתוך האפליקציה “עוזר חכם” אינה מספרת לו בהכרח שמידע שהוא מזין מועבר לספק אחר. צריך להבין איזה מידע מועבר, מי הספק, מה הוא רשאי לעשות בו והאם הוא נשמר מחוץ למערכות של מפעיל האפליקציה.
אפל מדגישה כיום שגם שיתוף מידע עם ספקי בינה מלאכותית מצד שלישי צריך להיות שקוף למשתמש ובהתאם לכללי הפרטיות החלים.
לכן שילוב כלי בינה מלאכותית אינו רק החלטת פיתוח. הוא עשוי לחייב גם עדכון של מיפוי המידע ושל מדיניות הפרטיות.
שינוי באפליקציה יכול לחייב שינוי במדיניות
מדיניות פרטיות אינה מסמך שמכינים ביום ההשקה ושוכחים ממנו.
הוספת כלי פרסום, מעבר לספק אנליטיקה אחר, פתיחת אפשרות להעלות תמונות, הוספת שירותי מיקום או שילוב בינה מלאכותית יכולים לשנות את פעילות המידע גם אם מבחינת המשתמש מדובר רק ב”פיצ’ר חדש”.
אפל דורשת מהמפתחים לשמור את תשובות App Privacy מעודכנות כאשר נוהגי המידע משתנים, וגם Google Play מטילה על המפתח אחריות לעדכן את הצהרות Data safety.
לכן בכל שינוי מוצר משמעותי כדאי לבדוק לא רק אם צריך לעדכן את הקוד, אלא גם אם המדיניות וההצהרות לחנויות עדיין נכונות.
מדיניות הפרטיות אינה יכולה לסתור את מה שהאפליקציה עושה בפועל
זו אולי הנקודה החשובה ביותר.
אם המדיניות אומרת שהאפליקציה אינה משתפת מידע עם צדדים שלישיים, אבל מותקן בה SDK שמעביר מידע לספק חיצוני, המסמך אינו מתאר את המציאות. אם המדיניות קובעת שהמידע משמש רק להפעלת החשבון אבל בפועל הוא משמש גם לפרסום, קיימת אותה בעיה.
גם ההפך אינו רצוי: אין טעם להעתיק מדיניות של חברה גדולה שמתארת עשרות פעולות שהאפליקציה כלל אינה מבצעת. מסמך כזה אינו בהכרח “בטוח יותר”; הוא יכול ליצור התחייבויות מיותרות, לבלבל את המשתמש ולהקשות על התאמת הצהרות החנויות.
המטרה היא התאמה בין ארבעה דברים: הקוד, מסכי האפליקציה, מדיניות הפרטיות וההצהרות שנמסרות לאפל ולגוגל.
מתי כדאי לבצע בדיקה משפטית של מדיניות פרטיות לאפליקציה?
ככל שהאפליקציה פשוטה יותר ואוספת פחות מידע, גם הבדיקה יכולה להיות מצומצמת יותר. אבל כאשר קיימים חשבונות משתמשים, מידע רגיש, מיקום, תמונות, תשלומים, פרופילים אישיים או מספר משמעותי של ספקים חיצוניים, החשיבות של התאמה מדויקת עולה.
בדיקה משפטית חשובה במיוחד כאשר המדיניות נכתבה לפני תיקון 13, הועתקה ממוצר אחר, אינה מתייחסת ל־SDKs הקיימים באפליקציה או אינה תואמת את הצהרות App Privacy ו־Data safety.
כדאי לבצע את הבדיקה לפני ההשקה או לפני עדכון משמעותי, כאשר עדיין ניתן לשנות גם את מסכי האפליקציה ואת תהליכי המידע. לעיתים הבעיה אינה סעיף חסר במדיניות אלא עצם העובדה שהמוצר אוסף מידע שאינו באמת צריך.
וכן תקנון לאפליקציה – מה הוא צריך להסדיר?**
מדיניות פרטיות לאפליקציה צריכה לתאר את המוצר האמיתי, לא רק את הטפסים שהמשתמש רואה.
צריך להבין איזה מידע המשתמש מוסר בעצמו, איזה מידע נאסף מן המכשיר ומהשימוש, אילו הרשאות האפליקציה מבקשת, אילו ספקים ו־SDKs מעבדים מידע ומה קורה למידע כאשר החשבון נסגר.
במקביל, המדיניות צריכה להתיישב עם הדין הישראלי ועם הדרישות של חנויות האפליקציות. תיקון 13 הרחיב את מסגרת ההגנה על מידע אישי ואת חובת היידוע, בעוד שאפל וגוגל דורשות שקיפות מפורטת ביחס לנוהגי המידע של האפליקציה ושל רכיבי צד שלישי.
לכן מדיניות פרטיות טובה אינה נוצרת באמצעות החלפת שם החברה בתבנית מוכנה. היא מתחילה במיפוי של פעילות המידע ומסתיימת במסמך שמתאים לקוד, למסכים, לספקים ולהצהרות שהמשתמש רואה בחנות האפליקציות.