הענן פה – אז מה עושים?

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

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

הטמעת תמידית של תהליכים עסקיים ומערכות המידע התומכות בהם

רובם המכריע של הפתרונות המוצעים בענן מבוססים על ארכיטקטורה של multi-tenant והמשמעות היא שכל המשתמשים בעולם נמצאים באותו בסיס של קוד ומסד נתונים ולכן כאשר מתבצע שדרוג – הוא מתבצע לכל המשתמשים בעולם באותו זמן ולא ניתן לדחות שדרוג זה. רוב יצרני הפתרונות בענן מבצעים שדרוג פעמיים בשנה והמשמעות היא שארגונים צריכים (תלוי בגודל השינוי של הגרסה החדשה לעומת הגרסה הישנה) לבצע הטמעה של הגרסה החדשה של המערכת, כולל שינוי של תהליכים עסקיים המתבקשים משינויי המערכת. זאת לעומת המצב הקודם שבו שינויים (אמנם גדולים יותר) היו מתרחשים רק פעם במספר שנים. לפיכך, מאמץ ההטמעה הארגוני אמור לגדול, כאשר הטמעת מערכות הופכת להיות פעולה שהיא יותר on going ולא פעולה שמתרחשת פעם במספר שנים. הגורמים העסקיים צריכים לקבל את העובדה שתהליכים העסקיים משתנים\מתפתחים כל הזמן.

מעבר מ- CAPEX ל- OPEX

צריך להבין שהענן הוא 'שירות', ללקוח אין בעלות על הענן אפילו אם מבצע עסקה ארוכת טווח. לפיכך מדובר בהוצאה שוטפת הנרשמת ב- OPEX. זאת לעומת התוכנה שמותקנת בארגון – שהיא בבעלות הלקוח והסכום ששימש לרכישה מופיע בתקציב ההשקעות הארגוני CAPEX. התוכנה בבעלות הארגון הוא נכס שמופיע כחלק מנכסי הארגון במאזן ומופחת עם השנים. בארגונים מסחריים רבים ישנה העדפה ל- CAPEX לעומת ה- OPEX ומשום כך יחסי ה- CAPEX \OPEX משפיעים על מדד חשבונאי EBITDA- רווח לפני ריבית, מיסים, הפחתות ופחת (כלומר הפחת אינו חלק ממדד זה). במסגרת המעבר לענן הגורמים הפיננסיים (CFO, חשבות, קשרי בורסה וכד') יצטרכו "לעכל" את העובדה שהתמונה הפיננסית של הארגונים השתנתה ויצטרכו להסביר זאת לגורמים הרלוונטיים, כגון המשקיעים בבורסה.

סייבר ורגולציה בקצב מואץ

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

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

במאמר הקודם כבר דיברנו על כך שהענן מחייב התארגנות שונה ובניית תהליכים חדשים בין הגורמים הבאים: תפעול תשתיות, רגולציה, רכש ,מטה ה- IT (העוקב אחרי התקציבים ומתעדף משאבים) ואבטחת מידע\סייבר. במאמר גם הזכרנו כלים אשר באים לתת מענה לסוגיות אלו – תחום ה- cloud management platforms. הפעם נשים את הדגש על שילוב הישן עם החדש. לארגונים יש נטייה לבנות צוות ענן המופרד מהצוותים הקיימים בארגון. למרות היתרון במיקוד ובמקצועיות מדובר על מהלך שגוי, מכיוון שבניית צוות נפרד אשר מטפל בענן גורם ליצירת שני מחנות בארגון "ישן" מול "חדש", דבר שמהווה מתכון לכישלון בטווח הארוך. הדרך המומלצת היא לשלב את החדש בתוך הישן – במידת האפשר. כלומר, לדוגמא, צוות הסיסטם יטפל בשרתים בענן וגם בשרתים on prem. צוות ה- DBA יטפל בנתונים גם בענן וגם ב- on prem וכד'. רק האזורים שלא קיימים כלל בסביבת ה- on prem צריכים להיות מטופלים על ידי צוות הענן – דברים כמו ניהול הקשר מול ספק הענן בהקשר של תקציבים, מידת השימוש וכד'.

עד כאן להפעם.

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

הענן פה – אז מה עושים?

STKI Market Pulse – עדכונים מהירים על קצה המזלג:

מיהו ה- CTO החדש?

כידוע אנחנו נמצאים בתקופה בה מתרחשים שינויים טכנולוגיים כבירים ומואצים. נשאלת השאלה האם תפקיד ה- CTO משתנה ביחד עם שינויים טכנולוגיים אלו. זה היה הנושא העיקרי במפגש שולחן עגול שהתקיים לאחרונה.  בדיון עלתה הסוגיה לפיה ה-"CTO התפעולי-טכנולוגי" קרוב לעולם ה-IT ובמובנים רבים מסתכל "פנימה". CTO זה קרוב לעיתים לתחום התשתיות ובמקרים מסוימים גם ייקח אחריות תפעולית על משימות טכנולוגיות שקשורות לתחום התשתיות (לדוגמה, אחריות על הוצאת מכרזים, אחריות על פרויקטים תשתיתיים). לעיתים ה- CTO הוא גם מנהל התפעול והתשתיות בעצמו (במקרה זה חלק מהקונפליקטים והבעיות שמתוארות בהמשך לא קיימות). לעיתים חלק לא מבוטל מתפקיד ה- CTO ה"תפעולי" בארגון הוא להוות "גשר" בין תחום הפיתוח לבין תחום התשתיות\תפעול.

בדיון גם עלתה הסוגיה של חיבור ה- CTO לתחומים המקצועיים. הרי ה- CTO אינו מכיר את הטכנולוגיות הספציפיות בתחומים השונים (פיתוח, אחסון, תקשורת, ERP וכד') באותה רמה של הגורמים המקצועיים בתחומים אלו, ונשאלת השאלה כיצד מחברים את ה- CTO לגורמים המקצועיים. בדיון גם עלתה דעה (על ידי CTO שמשמש גם כמנהל תפעול\תשתיות) שלא ניתן להיות CTO ללא אחריות תפעולית – אחרת מאבדים את ה"מגע המקצועי". אחד הרעיונות שעלה בדיון בהקשר לסוגיה זו הוא ביצוע רוטציה בין הגורמים המקצועיים לבין צוות ה- CTO, כךשומרים על ה"עדכניות המקצועית" של צוות ה- CTO. במידה ומצליחים ליישם זאת ארגונית מדובר על רעיון טוב. מעבר לכך, מסתבר שהיחסים בין הגורמים המקצועיים לבין ה- CTO  אינם פשוטים. מצד אחד, הגורמים המקצועיים הם "שחיים את התחום" ומכירים לפרטי פרטים את התחום הספציפי שלהם הרבה יותר מה-CTO. עם זאת, לצוותים המקצועיים חסרה לעיתים פרספקטיבה רחבת טווח שנמצאת בידי ה-CTO, חשיפה למגמות טכנולוגיות ומידע על פרויקטים עתידיים בגוף מערכות המידע. כמו כן, הגורמים המקצועיים אינם "חפים מאינטרסים" ובהחלטות טכנולוגיות נוטים לבחור בבחירות שמוכרות להם יותר. ה-CTO אמור להיות הגורם האובייקטיבי-מקצועי בארגון.

שורה תחתונה: חלוקת האחריות בין הגורמים המקצועיים לבין ה-CTO  אינה טריוויאלית ומחייבת עבודה בשיתוף פעולה כאשר לעיתים ה-CIO  נאלץ לבצע החלטה כאשר ישנם נושאי מחלוקת. אך ברוב המקרים העבודה מתבצעת בשיתוף פעולה, כאשר כל גורם תורם כמיטב יכולתו.

שימוש במוצרי BI במודל קוד פתוח

לאחרונה קיבלנו כמה פניות מארגונים ששוקלים שימוש בכלי BI קוד פתוח. המניע לשאלות אלה בתחום ה-BI ספציפית הנו ברובו הגדול של המקרים בו אנו נתקלים – חיסכון בעלויות רישוי. חלק מהארגונים מעוניינים להרחיב משמעותית את השימוש בשירותי BI אל מעבר למשתמשי ה-BI הקלאסיים (כיום % משתמשי ה-BI עומד על כ-30% מכלל העובדים), לשותפים חיצוניים או ללקוחות. במקרה זה, ה Business case של שימוש במוצרי קוד פתוח הנו ברור. כאשר בוחנים כלי BI קוד פתוח, מעניין לראות כי בתחום זה ספציפית, כל שלושת המוצרים הבולטים נרכשו על ידי חברות טכנולוגיות:

  • Pentaho – אשר נרכשה לפני מספר חודשים על ידי HDS במטרה המוצהרת להיכנס לתחום האנליטיקה ב-IoT analytics
  • JasperReport – נקנו על ידי Tibco
  • BIRT – חלק מ Eclipse, נדחף על ידי Actuate- כיום חלק מ-Open Text.

רוב השימוש בכלים אלה עד כה הנו לחברות טכנולוגיות המעוניינות לפתח רכיבי BI ולשלבם בתוך האפליקציות שלהם אותן הן מוכרות לשוק (Embedded BI). אולם מודלי הרישוי – המאפשרים גישה למסה של משתמשים, הרבה יותר מותאמים ל Customer facing BI מאשר אלה של רוב ספקי ה-BI המסורתיים. כתוצאה מכך, אנו צופים שארגונים אשר יהיו מעוניינים להציע שירותי BI אל מחוץ לגבולות הארגון יבחנו ברצינות מודל קוד פתוח. ייתכן והדבר יוביל בסופו של דבר לרצון לממש כלי קוד פתוח גם לשימוש של BI פנים ארגוני לעובדים (אך כיום ובעתיד הנראה לעין אנו לא רואים מגמה כזו בארגוני Enterprise).

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

שורה תחתונה: פתרונות במודל קוד פתוח בתחום ה-BI מהוות אלטרנטיבה טובה אשר ראוי לבחון ב use case של שימוש חיצוני כלפי שותפים/ ספקים / לקוחות הארגון, אך יש להיערך לנושא התמיכה ולוודא כי יש גישה לידע הנדרש, בין אם בהתארגנות פנימית או בהסתמכות על כ"א חיצוני.

ניהול סיכוני טכנולוגיות המידע

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

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

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

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

STKI Market Pulse – עדכונים מהירים על קצה המזלג:

STKI MARKET PULSE – עדכונים מהירים על קצה המזלג:

הדבר הבא באנליטיקה: Machine intelligence

Machine Intelligence (השילוב בין Machine Learning ובין Artificial intelligence) הנה ההתפתחות הטכנולוגית המעניינת ביותר שתשפיע לא רק על עולם העסקים, אלא על הדרך בה אנחנו כצרכנים ועובדים נחיה את חיינו היום-יומיים. מחשבים כבר למדו לחשוב, לקרוא, להבין, לדבר וללמוד דפוסי התנהגות (כיום עובדים על חוש הריח).

אך היכן נמצא השוק ביחס להתפתחויות טכנולוגיות אלה? טכנולוגיות Machine learning כבר די בשלות, ברמות שונות. ישנן טכנולוגיות בסיסיות אשר זמינות ופותחות החוצה את שירותיהן בתצורת APIs, יש מתקדמות יותר. וישנן גם אפליקציות – וכאן החלק המעניין באמת. במסגרת כנס ביג דאטה ו Machine Learning,Shivon Willis (החוקרת את התחום ב- Bloomberg), יצרה מפת טכנולוגיות מעניינת, אותה היא מחלקת לטכנולוגיות; אפליקציות המיועדות לשינוי חיי אנשים; תעשיות; Enterprises; כלים משלימים ועוד חלקים המרכיבים את ה Eco system הזה, שכמעט כולו מורכב מסטארטאפים. אבל לא רק, גם ספקים כדוגמת מיקרוסופט (יכולות ML ב Azure), אמאזון Machine Learning, היכולות הקוגניטיביות, ספקי אנליטיקה כדוגמת SAS ועוד.

שורה תחתונה: בקרוב כולנו נרגיש את ההשפעה של כלי Machine Learning בתחומים שונים, כאשר בתחומי ה-IT התחום הראשון בו ארגונים יוכלו להתחיל ליהנות מיכולות אלה יהיה תחום האנליטיקה, במיוחד פרויקטים חדשניים באנליטיקה ו – Big data analytics בהם לאנליסטים ו Data Scientists "מתחילים" אין תמיד מספיק ניסיון לדעת איזה מודל אנליטי מתאים לאיזו בעיה עסקית, טכנולוגיות אלה יוכלו לסייע בתהליך חשוב זה ולקצר את עקומת הלמידה, שהנה מאוד משמעותית כיום ומעכבת time to market. אנו ממליצים לחפש יכולות ML בכלי האנליטיקה שארגונים בוחנים כיום.

 Internet of Things

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

שעון מעורר המנטר את השינה שלי יצלצל בדיוק בשלב המתאים ביותר להתעוררות, הסנסורים בבית החכם ידליקו את האור (בהדרגה) ויפעילו את מכונת הקפה, ובזכות החיבור ליומן ולפקקים מכשירים אישיים חכמים יציעו לי מתי לצאת מהבית, יתאמו מוזיקה, ידברו עם הרכב… וכמובן, הציפייה לשירות מחובר, רציף, מנותר ופרו-אקטיבי נכנסת במהירות גם לעולם הארגוני. אולם, תחום ה- M2M – Machine-to-Machine קיים כבר היום, מכונת השתייה שידרה למרכז הבקרה שהקולה נגמרה, אבל האדם היה זה שהחליט האם להוציא את משלוח הקוקה קולה כבר עכשיו וכמה בקבוקים צריכים להיות שם. העתיד מדבר על מערכות שייקחו את ההחלטות הללו באופן עצמאי. מכשירים חכמים, המדברים בינם ובין עצמם משדרים לענן, מנתחים את המידע ומחליטים החלטות בכל רגע נתון.

שורה תחתונה: ניטור וניתוח מתמיד של מידע המתאפשר היום בזכות מיליוני סנסורים, ענן, אנליטיקה דיגיטאלית, מזהה דפוסים שלא היינו ערים להם קודם לכן, מקצר לנו את תהליך של קבלת ההחלטות, מציע ומבצע את הדבר המומלץ ביותר עבורי. ולמרות לא מעט אתגרים לא פתורים של התחום, הצדקתו הכלכלית ברורה וקלה להוכחה. אנו צופים בתקופה הקרובה כניסה רחבה של ארגונים לפרויקטי IoT, הן פרויקטים הפונים לקהל הרחב, אשר משדרגים את חווית הלקוח וחדשנות, והן פרויקטים ארגוניים Internet of Corporate Things-, אשר מייעלים תפעול, חוסכים העלויות ומציעים תהליכי עבודה שלא היו אפשריים קודם לכן.

תיבות דואר בענן כמשל לענן – פוטנציאל גדול אך מציאות מורכבת

ככל שהזמן עובר נראה שפתרונות ענן  תופסים תאוצה והופכים להיות "the new normal" במצבים רבים יותר ויותר. מדובר על פתרונות חדשניים, המסייעים בהורדת מאמץ התפעול ותוך תשלום לפי שימוש בפועל. כלומר מדובר על התאמה מיטבית לדרישות הארגון.

אולם, מסתבר שהענן אינו "התשובה לכל שאלה" ויישום פתרון ענן עלול להיות מאתגר במיוחד. לאחרונה אנחנו מקבלים פידבקים מארגונים אשר מתחילים תהליך של העברת תיבות הדואר שלהם מהארגון לענן. באופן כללי הפידבק הנו פידבק טוב. תיבות הדואר בענן בעלות קיבולת גדולה יותר ממה שהיה מקובל בארגון ואין צורך לבנות סביבה ייעודית של ארכיון. הזמינות גבוהה. הביצועים טובים. הארגון מקבל שירותים של גיבוי כחלק מהשירות (ללא התקנה של תוכנה נוספת) ועוד. שירות דואר בענן הנו אחד מהתחומים הטבעיים ביותר במיוחד לחברות חדשות, זאת גם בגלל שבעולם הפרטי מדובר על סטנדרט (gmail, outlook.com וכד').

עם זאת, מתקבלים פידבקים המצביעים על כך שמעבר של ארגון ותיק לענן אינו טריוואלי בלשון המעטה. לדוגמה, אצל לקוח מסוים חלק מהארגון הסתמך על תכונה ישנה של שרת הדואר- עבודה בתצורה של online- כל הבקשות מטופלות מיד על ידי השרת המקומי. אך הסתבר שפתרון הענן תומך רק בתצורה של cached mode והמשמעות היא שהשרת שולח מספר בקשות ביחד ולא מטפל בכל בקשה באופן מידי. לפתרון זה מספר יתרונות ביניהם חסכון בתקשורת אולם טכנולוגיה זו גם גורמת לכך שישנם לעיתים עיקובים של מספר דקות בטיפול בבקשות. ברוב המקרים משתמשי הדואר אינם ערים לכך ועבודתם אינה מושפעת אולם באחד הארגונים תהליך עסקי של שירות הלקוחות הסתמך על כך שנציג שירות הלקוחות מבצע שיחת ועידה עם האחראי עליו ובמקביל שולח לו את המייל הרלוונטי. כל עוד עבדו בשיטה הישנה המייל היה מגיע מיד כאשר עברו לענן היו עיכובים בקבלת המיילים (בגלל המעבר ל-cached mode) כל זאת בזמן שהלקוח ממתין בטלפון. המשמעות היא פגיעה בתהליכי העבודה ומובן שהדבר עורר תרעומת בקרב הגורמים העסקיים.

פידבק נוסף דיבר על מצבים שבהם מגיעים למגבלות בענן. תיבת דואר בענן מוגבלת למשלוח של 30 הודעות מייל בדקה או 10K הודעות ביום. אין אדם שמגיע או אפילו מתקרב למגבלות אלו אולם תיבת דואר מתוך אפליקציה (ERP\CRM) או תיבת דואר ארגונית המספקת הודעות ארגוניות (תקלות בארגון, אירועים חשובים וכד') מגיעה בקלות למגבלות אלו ולכן נדרשת התאמה מיוחדת ושינויים באפליקציה כאשר עוברים לענן.

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

The Israeli Privacy Data Dance – Opportunity or Difficulty?

Israel's Privacy Protection Law states that a citizen's personal data cannot be exported to a country with a lesser level of protection than that guaranteed by Israel. On October 6th, the European Court of Justice (ECJ) decided to invalidate the Safe Harbor Program between the EU and US.  The European Court of Justice held that the U.S.-EU Safe Harbor Program failed to provide adequate protection for EU citizens. Based on that decision, the Information and Technology Authority (ILITA), Israel's data protection authority revoked on October 19th its prior authorization for data transfers from Israel to the U.S. based on the U.S-EU Safe Harbor Program certification.

This may create an opportunity for Israeli companies, since the European Commission's 2011 decision remains in effect, the ECJ decision may create a competitive advantage to companies conducting processing or storage activities in Israel, as these companies can continue to receive data from Europe without the uncertainty now inherent in EU-US data transfers. Consequently, Israeli companies will need to find an alternative legal basis for transferring personal data to the U.S., and could experience an “uncomfortable transition period,” according to Limor Shmerling, ILITA's director of licensing and inspection.  “It's too early to tell how the market will be affected and how practices may need to be changed,” she said, adding that the authority is “considering the implications of the new legal status and will further address the subject accordingly.”

This may also create a challenge for local operators of multi-nationals including large local operations of multi-nationals such as IBM, Intel Corp., Microsoft Corp., Google Inc., Facebook Inc. and Hewlett-Packard Co., as well as Israeli “unicorns” such as Waze, Wix and IronSource., according to a statement by the U.S.-based International Association of Privacy Professionals (IAPP), “the decision could pose a significant barrier to data flow from Israel's surging technology sector,”

“Since the Safe Harbor arrangement is currently invalid under European law, and as long as there is no other valid arrangement or another formal decision of the European Union (EU) with respect to the transfer of data from Europe to destinations in the United States, database owners who wish to transfer personal data from Israel to entities in the United States are therefore required to assess whether they can base the data transfer on another of the derogations determined in the regulations,“ the ILITA said in its decision.

The EU's recognition of U.S. Safe Harbor certification, combined with its 2011 granting of “adequacy” status to Israel under the EU Data Protection Directive, allowed personal data to flow freely between the EU and Israel, and on to U.S. companies on the Safe Harbor certification list.

The Safe Harbor system has been widely used to legitimize the outsourcing of services by EU-based companies and their commercial partners to U.S.-based cloud or software-as-a service (SAAS) providers, and to facilitate intra-group data-sharing among entities with both U.S. and EU operations.  Although this has not had the desired effect in Israel and this new stance by ILITA goes hand in hand with the new Israeli Cloud Banking Regulation 357 stating that core data cannot be in the cloud.

It added, however, that current Israeli business models could be affected, including Israeli companies with European affiliates that previously relied on the Safe Harbor arrangement to transfer data to the U.S., as well as Israeli companies outsourcing storage or processing activities to U.S. service providers or affiliates that include information on European customers, in which case they may need to amend their customer agreements to include authorization for the transfers.

Bottom Line: Know your options and plan accordingly.

STKI MARKET PULSE – עדכונים מהירים על קצה המזלג: