למה CISOs ממשלתיים צריכים מדריך רכש ייעודי ל-Zero Trust?

רכש ממשלתי של פלטפורמות סייבר שונה מהותית מרכישה מסחרית. CISO ממשלתי לא יכול פשוט להעריך מוצר, לבחור ספק ולהוציא הזמנת רכש. הרכש חייב לנווט בין כלי חוזים (GSA MAS, EIS, OASIS+, Polaris GWAC), לעמוד בדרישות FAR ו-DFARS, לספק את הגורם המסמיך (AO) דרך תהליך RMF, להדגים התאמה ל-Executive Order 14028 ו-OMB M-22-09, ולייצר תיעוד שעומד בביקורת – הכל לפני שרכיב אחד נפרס.

האתגר מתעצם כשהפלטפורמה חוצה גבולות רשת. רכש ממשלתי של פלטפורמת zero trust חוצת-רשתות חייב לאבטח קישוריות בין רמות סיווג, בין אזורי IT ו-OT, בין תשתית הסוכנות לשותפים חיצוניים, ובין מערכות מקומיות לשירותי ענן. כל גבול מוסיף דרישות עמידה, שיקולי הרשאה ואילוצים ארכיטקטוניים שמדריכי רכש ZTNA סטנדרטיים לא מכסים.

נכון לתחילת 2025, רק 14% מפעילויות Zero Trust ברמת יעד של ה-DoD הושלמו. חוק הביטחון לשנת הכספים 2026 הקצה 15 מיליארד דולר למודרניזציה סייבר. סוכנויות נמצאות תחת לחץ כפול – לזוז מהר יותר ולרכוש בצורה חכמה יותר. המדריך הזה מספק את מסגרת הרכש ש-CISOs ממשלתיים צריכים כדי לרכוש פלטפורמות קישוריות Zero Trust חוצות-רשתות דרך כלי רכש קיימים, עם דרישות מבוססות, קריטריוני הערכה מובנים, ותיעוד עמידה מהיום הראשון.

אילו כלי רכש תומכים ברכישת Zero Trust חוצת-רשתות?

CISOs ממשלתיים לא צריכים סמכות חוזית חדשה כדי לרכוש פלטפורמות Zero Trust. כלים קיימים כבר תומכים בקטגוריית הרכש הזו – האתגר הוא לבחור את הכלי הנכון להיקף ולציר הזמן.

מיפוי כלי רכש לרכישת פלטפורמת Zero Trust

כלי	הכי מתאים ל-	ציר זמן	שיקולים מרכזיים
GSA MAS (Multiple Award Schedule)	רכש סוכנות בודדת; היקף מוגדר; מוצרים מסחריים	2–6 חודשים מדרישה להענקה	SIN 54151S (שירותי IT מקצועיים) ו-518210C (שירותי ענן); נהלי הזמנה מייעלים; נדרשת קביעת best value
GSA EIS (Enterprise Infrastructure Solutions)	תשתית רשת וטלקומוניקציה; פריסות רב-אתריות	6–12 חודשים	מסומן BIC; כולל תרחישי ZTA; Task Order Unique CLINs (TUCs) לפתרונות מותאמים; EIS מסתיים ב-2032
OASIS+ / Polaris GWAC	שירותי IT מורכבים; דרישות רב-תחומיות; פריסות עתירות-אינטגרציה	4–8 חודשים לכל task order	OASIS+ Phase II נפתח בינואר 2026; Polaris – הענקות ראשונות סוף 2025; מתאים לפריסות שדורשות שירותי אינטגרציה משמעותיים
IDIQ ייעודי לסוכנות	סוכנות עם IDIQ קיים שמכסה סייבר/שירותי רשת	2–4 חודשים לכל task order	הנתיב המהיר ביותר אם כלי קיים מכסה את ההיקף; עשוי להגביל תחרות
הסכם OneGov	תמחור ארגוני סטנדרטי; תוכנה מסחרית	שבועות עד חודשים	GSA מנהל תנאים מוסכמים מראש; בעיקר למוצרים מסחריים נפוצים; מתרחב לסייבר ב-2026
חוזה ישיר (FAR Part 15)	דרישה ייחודית; אין כלי קיים שמכסה את ההיקף	12–18 חודשים	תחרות מלאה ופתוחה; ציר הזמן הארוך ביותר; העומס הרכשי הגבוה ביותר; השתמשו רק כשאין כלי קיים מתאים

החלטת בחירת הכלי

לרוב רכישות הרכש הממשלתי של פלטפורמת zero trust חוצת-רשתות, GSA MAS מספק את הנתיב המהיר ביותר לפריסה ראשונית, בעוד EIS תומך ברכיבי תשתית הרשת לפריסות רב-אתריות גדולות יותר. ספר הטכנולוגיות של GSA לארכיטקטורת Zero Trust ממפה מפורשות שירותי EIS לכל עמוד של מודל הבשלות Zero Trust של CISA, ומספק עקיבות ישירה מרכש לעמידה.

לסוכנויות ביטחוניות, דרישות DFARS ספציפיות (כולל התאמת CMMC ושיקולי ITAR) עשויות לדרוש כלים ייעודיים לסוכנות או task orders של OASIS+ שמשלבים אנשי סיווג ודרישות מתקנים מסווגים.

מה צריך לכלול במסמך הדרישות?

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

דרישות טכניות חובה

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

קטגוריית דרישה	דרישה ספציפית	למה חשוב	שיטת אימות
ארכיטקטורה	אפס פורטים נכנסים ב-firewall על רשתות מוגנות	מבטל את הווקטור הראשי ל-ransomware בסביבות OT ממשלתיות	סקירת תרשים ארכיטקטורה + סריקה חיצונית במהלך פיילוט
ארכיטקטורה	אפשרות פריסה מקומית ללא ניתוב מידע דרך תשתית ענן של הספק	נדרש לסביבות מסווגות ורגישות שבהן מידע לא יכול לעבור דרך ענן מסחרי	סקירת ארכיטקטורת פריסה; אימות תרשים זרימת מידע
ארכיטקטורה	תמיכה במספר גבולות רשת (IT/OT, מסווג/לא-מסווג, סוכנות/חיצוני) מפלטפורמה אחת	יכולת חוצת-רשתות היא הדרישה המרכזית; פלטפורמות מרובות לגבולות שונים מבטלות את האיחוד	סקירת ארכיטקטורה + הדגמת פיילוט על שני סוגי גבול
זהות	MFA לכל סשן לכל בקשת גישה (לא רק כניסה ראשונית)	מסגרת ZT של ה-DoD ו-OMB M-22-09 דורשים אימות רציף; MFA ברמת VPN לא מספיק	סקירת הגדרות + בדיקה בפיילוט
זהות	שילוב טבעי של PIV/CAC דרך שרשרת תעודות AD/LDAP	דרישת תשתית זהויות פדרלית; פתרונות שדורשים עוקפים ל-PIV/CAC יוצרים פערי עמידה	בדיקת אימות PIV/CAC במהלך פיילוט
זהות	חשבונות אישיים לכל המשתמשים כולל ספקים (ללא הרשאות משותפות)	שיוך סשנים דורש זהות אישית; הרשאות משותפות הופכות חקירת אירועים לבלתי אפשרית	סקירת הגדרות מדיניות
בקרת גישה	גישה ברמת אפליקציה למשאבים ספציפיים (לא גישה ברמת רשת)	עקרון הרשאות מינימליות; גישת VPN ברמת רשת מאפשרת תנועה רוחבית	הדגמת מדיניות: משתמש ניגש לתחנה אחת, לא יכול להגיע לאחרות
בקרת גישה	מדיניות ברמת תחנה/אפליקציה עם תמיכה בחלונות זמן ותהליכי אישור	אכיפת מדיניות גרנולרית נדרשת על ידי NIST 800-207 ותוצאות יכולת ZT של ה-DoD	הגדרת מדיניות + בדיקת תרחישים
שיתוף קבצים	שיתוף קבצים דו-כיווני משולב עם סריקת CDR (Content Disarm & Reconstruction)	חילופי קבצים חוצי-רשתות ללא CDR הם וקטור להכנסת נוזקה; מוצרים נפרדים מפצלים את עקבות הביקורת	בדיקת העברת קבצים עם קבצי בדיקה זדוניים ידועים
שיתוף קבצים	תמיכה בפרוטוקול SMB עם אימות Kerberos/NTLM ו-SMB Signing	נדרש לתאימות עם תשתית שיתוף הקבצים הממשלתית הקיימת	בדיקת גישה לשיתוף SMB מתחנת Windows סטנדרטית
ביקורת	הקלטת סשנים (וידאו + הקלדות) לכל הסשנים האינטראקטיביים	נדרש בסביבות מסווגות; קריטי לחקירת אירועים ולראיות עמידה	סקירת הקלטות סשנים
ביקורת	עקבות ביקורת אחידים לכל סוגי הקישוריות (גישה אפליקטיבית + שיתוף קבצים + העברת מידע) עם פיד Syslog אחד	לוגים מפוצלים ממוצרים מרובים מגדילים MTTI ויוצרים פערי עמידה; ביקורת מאוחדת מצמצמת זמן חקירה ב-95%	בדיקת שילוב SIEM; סקירת שלמות לוגים
עמידה	ניתן למיפוי ל-CISA ZTMM v2.0 על כל חמשת העמודים	נדרש לדיווח עמידה OMB M-22-09	מסמך מיפוי עמידה מהספק
פריסה	ניתן לפריסה על מכונות וירטואליות סטנדרטיות (ללא חומרה ייעודית)	מבטל מחזור רכש חומרה; מאפשר פריסה מדורגת בתוך תשתית קיימת	סקירת מפרט ארכיטקטורת פריסה

דרישות טכניות רצויות

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

דרישה	קריטריוני ניקוד
הערכת מצב מכשיר בכל סשן (OS, EDR, הצפנה, רמת עדכונים)	בדיקת מצב מלאה = 10 נק'; חלקית = 5 נק'; ללא = 0 נק'
שילוב תהליכי אישור (ServiceNow, ITSM)	שילוב API טבעי = 10 נק'; תהליך ידני = 5 נק'; לא נתמך = 0 נק'
תמיכה בפרוטוקולי OT ישנים (RDP ל-SCADA, SSH לתחנות הנדסה)	תמיכת OT מלאה = 10 נק'; IT בלבד = 0 נק'
פריסה תוך שבועיים לפיילוט ראשוני (לא כולל מיגרציה מלאה)	≤ 2 שבועות = 10 נק'; 2–4 שבועות = 5 נק'; > 4 שבועות = 0 נק'
הספק מספק מתודולוגיית מיגרציה מדורגת עם קריטריוני rollback לכל שלב	מתודולוגיה מתועדת = 10 נק'; גישה ad hoc = 0 נק'

איך צריכה להיבנות ההערכה?

גורמי הערכה ושקלול

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

גורם	משקל	הסבר
יכולת טכנית	40%	האם הפתרון עומד בכל דרישות החובה? איך הוא מנוקד בדרישות הרצויות?
ארכיטקטורת אבטחה	25%	אפס פורטים נכנסים, נתיב מידע מקומי, בידוד ברמת אפליקציה, הקלטת סשנים – התכונות הארכיטקטוניות שקובעות את רמת האבטחה בפועל
ביצועי עבר	15%	פריסות מוכחות בסביבות ממשל וביטחון; רפרנסים מסוכנויות עם דרישות סיווג ו-OT דומות
גישת ניהול	10%	מתודולוגיית מיגרציה, תוכנית פריסה מדורגת, נהלי rollback, הדרכה והעברת ידע
מחיר	10%	עלות בעלות כוללת כולל רישוי, פריסה, אינטגרציה ותמיכה שוטפת – לא רק מחיר ליחידה

למה ארכיטקטורת אבטחה מצדיקה שקלול נפרד

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

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

הדגמת פיילוט

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

היקף פיילוט (מינימום שבועיים):

• פרסו תשתית פלטפורמה (Access Controller + Gateway) בסביבת בדיקה של הסוכנות
• שלבו עם Active Directory / תשתית PIV של הסוכנות
• הגדירו 5 סשנים על לפחות 2 גבולות רשת (למשל IT-to-OT ו-מסווג-ל-לא-מסווג)
• הדגימו MFA לכל סשן, בדיקת מצב מכשיר, והקלטת סשן
• בצעו העברת קבצים דו-כיוונית עם סריקת CDR
• הריצו סריקה חיצונית לאימות אפס שירותים גלויים
• ייצאו עקבות ביקורת ל-SIEM של הסוכנות; אמתו שלמות לוגים
• הדגימו rollback: הסירו פלטפורמה, אמתו שקישוריות ישנה לא מושפעת

הערכה במהלך פיילוט:

קריטריון פיילוט	עובר/נכשל	הערות
הפלטפורמה נפרסת עם אפס כללי firewall נכנסים	עובר/נכשל	כל כלל נכנס = נכשל אוטומטית
אימות PIV/CAC עובד באופן טבעי	עובר/נכשל	עוקפים או גשרים צד שלישי = נכשל
הקלטת סשן לוכדת סשן מלא (וידאו + הקלדות)	עובר/נכשל	לכידה חלקית = נכשל
סריקת CDR חוסמת נוזקת בדיקה בהעברת קבצים	עובר/נכשל	כל קובץ לא נסרק שחוצה גבול = נכשל
סריקה חיצונית מחזירה אפס תוצאות	עובר/נכשל	כל שירות גלוי = נכשל
עקבות ביקורת אחידים ב-SIEM מכילים רשומות סשן מלאות	עובר/נכשל	שדות חסרים או רשומות מפוצלות = נכשל

איזה תיעוד עמידה הספק צריך לספק?

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

תיעוד לפני הענקה

מסמך	מטרה	מה לחפש
מיפוי עמודי CISA ZTMM	מדגים איך הפתרון נותן מענה לכל אחד מחמשת עמודי ZTMM ויכולות חוצות-עמודים	כיסוי על כל חמשת העמודים; תוצאות יכולת ספציפיות מצוטטות; שלב בשלות נתמך לכל עמוד
התאמה ל-NIST SP 800-207	ממפה ארכיטקטורת פתרון לעקרונות Zero Trust Architecture	החלטות גישה לכל בקשה; אימות רציף; אכיפת הרשאות מינימליות; הפרדה בין data-plane ל-control-plane
מיפוי IEC 62443 FR (אם OT רלוונטי)	ממפה פתרון לדרישות יסוד לאבטחת OT	כיסוי FR1-FR7; פירוט אילו רמות אבטחה (SL1-SL4) הפתרון תומך
תרשים זרימת מידע	מראה בדיוק לאן מידע נוסע במהלך כל סוגי הסשנים	אימות שאין מידע שעובר דרך תשתית בשליטת הספק לתרחישי שימוש מסווגים
הערכת אבטחת ארכיטקטורה	הערכה עצמאית או מספק של ארכיטקטורת האבטחה של הפלטפורמה	מיקוד בניתוח שטח תקיפה: פורטים נכנסים, רכיבים חשופים לאינטרנט, שרשרת אימות, תקני הצפנה
תיעוד SCRM (ניהול סיכוני שרשרת אספקה)	עונה על דרישות EO 14028 לאבטחת שרשרת אספקת תוכנה	זמינות SBOM; שיטות פיתוח מאובטח; תהליך חשיפת פגיעויות; מקור רכיבים

תיעוד אחרי הענקה / לפני פריסה

מסמך	מטרה
ארכיטקטורת פריסה לסביבת הסוכנות	ארכיטקטורה ייעודית לאתר שמראה מיקום רכיבים, גבולות רשת וזרימות מידע
דוח הערכת אבטחה (SAR) ל-RMF	תומך בהחלטת ההרשאה של ה-AO; ממפה פלטפורמה לבקרות NIST 800-53 הרלוונטיות
תוכנית הערכה שוטפת	מגדירה איך הפלטפורמה תנוטר ותוערך באופן רציף לפי דרישות FISMA

מהן טעויות הרכש הנפוצות – ואיך נמנעים מהן?

טעות 1: רכישת ZTNA כפתרון נקודתי

מה משתבש: הסוכנות רוכשת פתרון ZTNA לגישה אפליקטיבית, ואז מגלה שהוא לא מטפל בשיתוף קבצים חוצה גבולות סיווג. רכש נפרד ל-SMB proxy עוקב. ואז עוד אחד להקלטת סשנים. התוצאה היא אותה ערימת ריבוי-ספקים שהסוכנות ניסתה לברוח ממנה – רק עם מוצרים חדשים יותר.

איך נמנעים: מסמך הדרישות חייב לציין קישוריות חוצת-רשתות כהיקף – גישה אפליקטיבית וגם שיתוף קבצים וגם הקלטת סשנים וגם ביקורת אחידה – בפלטפורמה אחת. קריטריוני ההערכה חייבים להוריד ניקוד לפתרונות שדורשים מוצרים משלימים כדי להשיג כיסוי מלא. פתרונות כמו truePass Gravity שמשלבים את כל שלוש השכבות (תשתית reverse-access, SMB Proxy עם CDR, וגישה אפליקטיבית Zero Trust) בפלטפורמה אחת צריכים לקבל ניקוד גבוה יותר מארכיטקטורות שדורשות 2–3 רכישות נפרדות.

טעות 2: ציון Cloud ZTNA ללא ניתוח נתיב מידע

מה משתבש: הסוכנות בוחרת פתרון ZTNA מבוסס ענן על סמך הרשאת FedRAMP והשוואת תכונות, בלי לנתח לאן מידע באמת נוסע. אחרי פריסה, צוות העמידה מגלה שמידע מסווג או CUI עובר דרך תשתית ענן מסחרית של הספק – בניגוד לדרישות ריבונות מידע.

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

טעות 3: קבלת גישה ברמת רשת כ-"Zero Trust"

מה משתבש: הספק טוען "Zero Trust" אבל הפתרון מספק גישת רשת דמוית-VPN אחרי אימות. משתמשים יכולים להגיע לכל מכשיר בסגמנט הרשת – לא רק למשאב המורשה שלהם. לסוכנות יש מוצר "Zero Trust" בחבילת ה-ATO אבל תנועה רוחבית ברמת רשת עדיין אפשרית.

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

טעות 4: לא לכלול השבתת שערים ישנים ב-SOW

מה משתבש: הסוכנות פורסת את הפלטפורמה החדשה אבל ה-VPN הישן, ה-jump server וה-SMB proxy נשארים פעילים כי ה-SOW לא כלל תכנון השבתה. שטח התקיפה גדל – לסוכנות יש עכשיו את הערימה הישנה ועוד הפלטפורמה החדשה.

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

טעות 5: הערכה על מחיר למשתמש ללא עלות בעלות כוללת

מה משתבש: הסוכנות בוחרת את עלות הרישוי הנמוכה ביותר למשתמש, ואז מגלה שהפתרון דורש מוצרים נפרדים לשיתוף קבצים ($X), הקלטת סשנים ($Y), סריקת CDR ($Z), ושירותי אינטגרציה לחבר את כולם. העלות הכוללת עולה על הפלטפורמה המאוחדת שמחירה היה גבוה יותר.

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

אלמנט עלות	ספק א' (מאוחד)	ספק ב' (פתרון נקודתי + משלימים)
רישוי פלטפורמה	מצוטט	מצוטט
שיתוף קבצים / SMB proxy	כלול	נדרש רכש נפרד: $____
הקלטת סשנים	כלול	נדרש רכש נפרד: $____
סריקת CDR	כלול	נדרש רכש נפרד: $____
שירותי אינטגרציה (חיבור 3+ מוצרים)	לא נדרש	נדרש: $____
שילוב SIEM (מספר מקורות לוגים)	פיד אחד	3–4 פידים: עבודת אינטגרציה $____
תחזוקה שנתית (כל המוצרים)	חוזה אחד	חוזים מרובים: $____
מספר ספקים משוער	1	3–4

אילו KPIs על ה-CISO לעקוב אחריהם אחרי הרכש?

הרכש הוא לא קו הסיום – הוא נקודת ההתחלה. ה-CISO הממשלתי חייב לקבוע מדדי KPI מדידים לאבטחת קישוריות OT מהיום הראשון כדי להדגים שההשקעה מייצרת תוצאות:

KPI	בסיס (ערימה ישנה)	יעד (אחרי פריסה)	תדירות מדידה
מדד חשיפת פורטים נכנסים	תעדו לפני פריסה	0	חודשי (ביקורת firewall + סריקה חיצונית)
יחס איחוד קישוריות	מוצרים ÷ סוגי קישוריות	≤ 0.4	רבעוני
כיסוי שיוך סשנים	% סשנים עם זהות מלאה + הקלטה	95%+	חודשי
זמן חקירה ממוצע (MTTI-OT)	שעות לשחזור סשן	< 15 דקות	לכל אירוע
כיסוי Zero Trust	% סשנים שעומדים בכל 5 קריטריוני ZT	90%+	חודשי

ה-KPIs האלו מספקים את בסיס הראיות למחזור התקציב הבא של הסוכנות, לחידוש ATO, ולתגובה לביקורת IG.

איך נראה ציר הזמן של הרכש מקצה לקצה?

שלב	ציר זמן	פעילויות מרכזיות	תוצרים
פיתוח דרישות	שבועות 1–4	הגדרת היקף חוצה-רשתות; מיפוי ל-CISA ZTMM; כתיבת דרישות חובה/רצויות; זיהוי כלי רכש	מסמך דרישות; מזכר אסטרטגיית רכש
מחקר שוק	שבועות 5–8	הוצאת RFI; ביצוע הדגמות ספקים; ניתוח תגובות מול דרישות; אימות בחירת כלי	דוח מחקר שוק; רשימת ספקים מצומצמת
מכרז	שבועות 9–16	הוצאת RFQ/RFP דרך הכלי הנבחר; הערכת הצעות; ביצוע הדגמות פיילוט	דוח הערכה; תוצאות פיילוט
הענקה	שבועות 17–20	קביעת best value; הודעת הענקה; תדרוך מציעים שלא זכו	הענקת חוזה; SOW עם אבני דרך להשבתה
פריסה שלב 1	שבועות 21–28	פריסת פלטפורמה; שילוב זהויות; העברת גישה אינטראקטיבית; השבתת VPN + jump server	השלמת שלב 1; אימות סריקה חיצונית
פריסה שלב 2	שבועות 29–36	העברת שיתוף קבצים; אימות CDR; הערכת זרימות חד-כיוויות	השלמת שלב 2; עקבות ביקורת מלאים פעילים
ATO / עמידה	שבועות 37–40	הערכת אבטחה RMF; תיעוד ATO; מיפוי עמידה; בסיס KPI	החלטת ATO; דשבורד KPI פעיל

ציר זמן כולל מדרישות ועד ATO תפעולי: כ-10 חודשים. לסוכנויות שמשתמשות בכלי IDIQ קיימים עם task orders שכבר עברו תחרות, שלבי הרכש (שבועות 1–20) יכולים להתכווץ ל-8–10 שבועות.

סיכום

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

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

המנדט ברור: EO 14028, OMB M-22-09, DTM 25-003 ו-CISA ZTMM כולם דורשים יישום Zero Trust. התקציב מוקצה: 15 מיליארד דולר ב-NDAA לשנת הכספים 2026. כלי הרכש קיימים: GSA MAS, EIS, OASIS+, Polaris. מה שנשאר הוא ביצוע הרכש – והסוכנות שמתחילה עם הדרישות הנכונות, מבנה ההערכה הנכון, ושותף הפריסה הנכון לסביבות ממשל וביטחון תגיע ל-Zero Trust תפעולי מהר יותר מהסוכנות שרוכשת פתרונות נקודתיים ומגלה את הפערים אחרי ההענקה.