[[HE: Draft for Tamir's review. Not published.]]
לכתוב את שתי העמדות מול רשימה יחידה
מבוי סתום לרוב מסתיר דרישה שקטה מכל צד. בקשו מהעסק להגדיר בעמוד בודד את הגרסה המינימלית בעלת ערך. דרשו מאבטחה, סיכונים או רגולציה את הבקרות המדויקות לגרסה הזו, לצד המקור לכל דרישה.
תנו ציון לשתי ההצעות מול רשימת תרחישי שימוש ומקרי קצה זדוניים. דרגו ממצאי אבטחה לפי נזק מעשי שתוקף יכול לחולל. חלק מהסעיפים הם עניין סגנוני, וחלקם חושפים מידע לקוחות.
לחפש את האמצע בין למחוק ללהשאיר
לרוב שני הצדדים צודקים בחלק שלהם. גישה מרחוק של ספק חומרה אפשר לאשר פר סשן, מוקלטת, מוגבלת בזמן ומבודדת, במקום לחסום לגמרי או להשאיר פתוחה לרווחה. אפליקציית נהגים יכולה להעביר את הדאטה שהרשות דורשת בלי דירוג אישי שמקפיץ את העובדים.
כשספק טוען שהמתווה אושר במקום אחר, בדקו מה האישור הזה כלל ותחת אילו חוקים. תנו לו למפות את המבנה שלו שלב אחר שלב מול הדרישות הכתובות שלכם. כשיש מחלוקת מרובת משתתפים, נתחו מקרי אמת כדי לאתר איפה העסק נתקע ומי יכול לקדם.
תלוי באיזה כיסא יושבים
אם מובילים כמנכ"ל, הימנעו מלדרוס צד אחד ולקחת לבד את מלוא האחריות. תדאגו שגרסה ראשונה תהיה מהודקת מספיק לחתימה משותפת, שימו את שני השמות על הדף, ותקבעו דדליין. הציגו לשני הצדדים את העלות החודשית של הספק בעודו ממתין.
אם מנהלים מערכות מידע ושני צוותים פוסלים זה את התוכנית של זה, מסגרו את זה כהשוואה מול אותם סיכונים ומשימות. במבוי סתום מול גוף חיצוני על נושא התשלום, כווצו היקפים להעברות המידע שמייצרות את החיסכון הגבוה ביותר לשניכם. אחרי זה תנו לכל צד לנהל את הקצה שלו.
מה לבדוק לפני שמחליטים
- לבקש מהביזנס על עמוד אחד את הגרסה הראשונה הקטנה ביותר שנותנת ערך.
- לדרוש מהצד החוסם את הבקרות הנדרשות לגרסה הזו, יחד עם המקור לכל דרישה.
- לתמחר את שתי החלופות בטבלה מרוכזת של משימות משתמש, סיכונים ותרחישי תקיפה.
- לסווג כל ממצא לפי רמת החשיפה, ולחייב תיקון לפני עלייה לרכיבים שנוגעים בנתוני לקוחות.
- לברר מה אישורים קודמים של הספק כיסו בפועל, ומה עובד אצלו תכלס כרגע.
- להגדיר אחראי בודד לתוצאת הלקוח וגורם מכריע למקרים שבהם המחלוקת נשארת.
- לנעול תאריך לגרסה הראשונה עם שמות שני הצדדים על המסמך, ולתעד סיכון שיורי.
שאלות שאנשים שואלים
מיזם AI תקוע חודשים בין הביזנס לניהול סיכונים, איך מגיעים להכרעה בלי לדרוס אף צד?
מייצרים דף עבודה אחיד: מה המערכת מבצעת בגרסה הראשונית, איזה החלטות היא מקבלת לבד, ואיזה בקרות קיימות לכל פעולה. רוב התקיעויות נפתרות כשמצמצמים גרסה ראשונה לגבול שסיכונים יכולים לאשר והעסק עדיין מרוויח ממנו. זה יושב על השאלה אם ה-AI חותך או רק ממליץ, ומה הרגולטור מחפש באינטראקציות לקוח אוטונומיות.
אבטחה דורשת לסגור חיבור מרוחק לספק מכשור רפואי וההנדסה טוענת שהציוד מושבת בלעדיו, איך מכריעים?
שניהם צודקים בזווית שלהם, אז הכיוון הוא גישה מנוטרת במקום לנתק או להשאיר כמו שהוא: סשנים של הספק באישור נקודתי של המוסד, מתועדים, קצוצים בזמן ובנתיב מבודד. ספקי ציוד זורמים עם זה כשמגדירים נכון. זה תלוי אילו מערכות חייבות תמיכה מרחוק ומה החוזה מול הספק סוגר.
אונבורדינג דיגיטלי נתקע על אימות זהות, והספק טוען שכבר עבר אישורים בארגונים אחרים, איך ממשיכים?
אישורים במקומות אחרים מראים שהתהליך בר-אישור. הם לא מוכיחים שהוא מתאים לפרשנות הרגולטור שלכם או לרמת הסיכון שאתם לוקחים. תושיבו את הציות להגדיר דרישות ספציפיות ותנו לספק להראות צעד-אחר-צעד איך הוא מכסה אותן. תעלו קודם על סגמנט לקוחות פחות רגיש אם התהליך המלא דורש עוד עבודה. זה תלוי ברגולציית הזיהוי שלכם ובקהל היעד.
הטמעת אפליקציית נהגים תקועה בגלל התנגדות למעקב והרגולטור דורש נתונים, איך יוצאים מזה?
מפרקים בין מה שהרשות דורשת הלכה למעשה, לרוב נתוני רכב ונסיעה, לבין מה שהספק דחף לאפליקציה, לרוב ציונים אישיים; על החלק הראשון קל יותר לגשר מול הנהגים כשמוותרים על השני או חותכים אותו. אז מגבשים כללים על מה אוספים, מי מציץ בזה ולאיזו מטרה. הכל תלוי בדרישות המדויקות של הרשות ובהסכמי העבודה אצלכם.
מי אמור להכריע כשזיכויי כרטיסים תקועים בין שרשרת ספקים שונים?
מגדירים בעלים יחיד לתוצאת הלקוח ומפרקים את שלבי העבודה שבמחלוקת. הפתרון נשען על מעקב של נקודות מסירה וההתחייבויות שכבר סוכמו, עם בחינה חוזית מסודרת במקומות הבעייתיים.
פרויקט אפליקציית מטופלים עומד במקום כי אבטחה ומוצר לא מתיישרים על זיהוי והסכמות, איך משחררים את זה?
בדרך כלל מסתתרת שם דרישה שלא נאמרה, אז שמים את שתי הגישות מול רשימה אחת של סיכונים ומשימות משתמש. בודקים כל גישה מול שלושת התרחישים הכי נפוצים ומול שני מקרי הקיצון המסוכנים ביותר. זה יושב על מה שחוקי הפרטיות דורשים לאימות מזהה ועל קבוצות המטופלים שהמערכת משרתת.
סקר אבטחה מצא ריג'קטים ב-API של שותפים ממש לפני עלייה והספק טוען שככה מקובל בתעשייה לעלות או לחכות?
מתמחרים כל ממצא לפי מה שתוקף יכול להוציא מזה דרך שותף, כי חלק זה עניין של גימורים וחלק זו דליפת מידע מלאה. מתקנים או מגדרים סעיפים שנוגעים בדאטה של לקוחות, ועולים עם לוח זמנים מוגדר לטיפול בשאר. זה תלוי בסעיפים שנוגעים באימות, הרשאות וחשיפת מידע.
סנכרון נתונים בין בית חולים לקופת חולים נתקע על מי מממן את הממשקים, איך מזיזים את העסק?
מצמצמים את ההיקף לחיבור אחד או שניים שמייצרים את הערך הכי גדול לשני הצדדים, וסוגרים הסכם תמציתי על מי מפתח, מי מאחסן ומי מתחזק. ממשקים בתקן אחיד חותכים ויכוחים כי כל צד אחראי על ה-endpoint שלו. זה תלוי בחשיבות הקלינית ובשאלה אם יש כבר תשתית סנכרון מגזרית שאפשר להתלבש עליה.
איך אני יכול לעזור בהחלטה הזו
- שאלה או שיחה (ללא עלות)
- אני מחדד זווית ראייה איך להדק את הגרסה הראשונה כדי ששני הצדדים יחתמו, ואיזו שאלת בקרה או פרטיות בדרך כלל פותרת את העניין.
- בדיקה והערכה (משלמים רק אם קיבלתם ערך)
- אני מייצר חוות דעת בלתי תלויה על התכולה, הבקרות, הממצאים והדרישות שכל צד נשען עליהן. אני ממליץ על גרסה ראשונית ששני הצדדים יכולים לחיות איתה, יחד עם התנאים הנדרשים.
- ליווי שוטף (בזמן ובקצב שמתאימים לכם)
- אני מלווה את התהליך לכל אורך הגרסה הראשונה כדי לבחון יישום בקרות, ממצאים שנשארו והחלטות התכולה הבאות.