GH GambleHub

יומן שינוי מדיניות

1) מטרה וערך

בשביל מה:
  • היסטוריה שקופה של שינוי: מי, מה, מתי ולמה.
  • ציות למבקרים/רגולטורים (ISO 27001, SOC 2, PCI DSS, GDPR ותקנות מקומיות).
  • ניהול סיכונים: קישור שינויים להערכות סיכונים, תקריות ותוכניות CAPA.
  • מקור אמת אחד לעובדים, ספקים ושותפים.

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

2) היקף

כתב העת מכסה את כל מסמכי המדיניות והרמה הסטנדרטיים:
  • אבטחה וגישה: מדיניות אבטחת מידע, ניהול אירועים, נקודות תורפה, מפתחות/הצפנה, ניהול סודי, מדיניות סיסמה, IAM.
  • נתונים ופרטיות: GDPR/DSAR/RTBF, אחסון ומחיקה, סיווג נתונים, DLP, יומנים וביקורת.
  • מימון/AML/KYC: AML/KYB/KYC, סינון סנקציה, הוכחה למקור כספים.
  • פעולות: BCP/DRP, שינוי ניהול, מדיניות שחרור, RACI, SRE/SLO.
  • חוקי/רגולטורי: דרישות שוק מקומיות, הגבלות פרסום, משחק אחראי.

3) תפקידים ואחריות (RACI)

בעל מדיניות ועורך מדיניות.
א '(אחראי): בעל מסמך של התחום/CISO/ראש הציות.
C (ייעוץ): Legal/DPO, Risk, SRE/Operations, Product, Data.
כל העובדים, קבלנים חיצוניים (אם יש צורך).

עקרונות: שליטה כפולה לכל פרסום; הפרדה גזעית של חובות; ייעוץ משפטי/משפטי מנדטורי לנושאים מח "ש/רגולטוריים.

4) שינוי אופן החיים

1. יוזמה: הדק (דרישה רגולטורית, מימון ביקורת, תקרית, מבחן חדירה, שינוי ארכיטקטורה).
2. טיוטה - שינוי במערכת ניהול מסמכים (Confluence/Git/Policy CMS).
3. הערכת השפעה: על תהליכים, רישום סיכונים, אימונים, חוזים, אינטגרציות.
4. אישור: Legal/DPO/Complication/Tech/Operations, אישור הבעלים הסופי.
5. פרסום: משימת גירסה, תאריך יעיל, הפצה.
6. עלייה למטוס: אימון/הכרה, עדכון SOP/Runbook.
7. בקרת ציות, מדדים, רטרוספקטיבה.

5) מודל נתוני יומן (שדות נדרשים)

'policy _ id' הוא זיהוי מדיניות קבוע.
שם המסמך הוא policy _ gate.
'change _ id' הוא המזהה הייחודי של השינוי.
Version '- גרסה סמנטית (מייג' ור. מינורי. PATCH) או מיום.

”change _ type” - מייג 'ורמינורתיקוןדחוףרגולטורים.
”status” - [טיוטה]in_reviewאושר על ידיפורסםאפקטיבי
מציע ”/עורך ”/” מאשר ”- משתמשים/קבוצות.
'submided _ at '/' אושר _ at/' published '/' יעיל _ from'.
”סאמרי” - תיאור קצר של השינוי (300 תווים).
'change _ log' - פרטים: מה כבר השתנה ולמה.
רציונל - הצדקה (התייחסות רגולטורית/תקרית/ביקורת).
'risk _ reff' refores לרשם הסיכון/הערכת השפעה.
'legal _ refs' - קודים/סטנדרטים (למשל. GDPR Art. 32, ISO A.8).
'impact _ scope' - מי מושפע (פקודות/תהליכים/אזורים).
”training _ direct” - כן/לא + התייחסות כמובן.
מחובר - diff/pdf, פרוטוקול משא ומתן.
distribution _ list '- למי להודיע.
'ac _ נדרש' - האם הכרה נדרשת.
'Hold _ flags' - Hold/Preze משפטי (אם מתאים).
דוגמה (YAML):
yaml change_id: POL-SEC-001-2025-11-01-M01 policy_id: POL-SEC-001 policy_title: Access Control Policy version: 2. 0. 0 change_type: MAJOR status: approved submitted_at: 2025-10-18T14:20:00Z approved_at: 2025-10-29T10:05:00Z published_at: 2025-10-30T09:00:00Z effective_from: 2025-11-15 proposer: d. kovalenko editor: secops. editors approver: ciso summary: Review roles and JIT access, enter quarterly-review.
rationale: "SOC Audit 2: CAPA-2025-17; incident # INC-5523"
risk_ref: RSK-AC-2025-004 legal_refs: ["ISO27001 A.5, A.8", "GDPR Art. 32"]
impact_scope: ["Prod Ops", "Payment Ops", "Affiliates"]
training_required: true attachments:
- link: confluence://AC-Policy-v2-diff
- link: git://policy-repo/pol-sec-001@v2. 0. 0 distribution_list: ["all@company", "ops@company", "vendors:payments"]
ack_required: true hold_flags: []

6) גרסה ושינוי דרישות סוג

מייג 'ור: שינוי דרישות/בקרה, משפיע על ביקורת/סיכונים; דורש אימונים ומעבר.
שינויים, דוגמאות, לא משנים שליטה במהות.
תיקון: עריכת איות/התייחסות; מסלול מהיר.
דחוף: תיקון דחוף עקב תקרית/פגיעות; פרסום על בסיס מזורז.
רגולטור: מעודכן בעקבות מכתב רגולטורי חדש.

ורסיונינג: תיקון תגיות/שחרורים; חפצי PDF/HTML ללא רבב עם חשיש.

7) אישור עבודה

1. Review - תבנית אוטומטית, קישורים ו metadata.
2. Multi-Review: Legal/DPO/Complication/Tech/Operations (מקביל/רציף).
3. אישור: בעל תחום + אחריות.

4. הוצאה לאור: יצירת הערת שחרור, כתיבה לעיתון, דואר, עדכון ”effective_from.”

5. הכרה: איסוף הכרה לעובד (LMS/HRIS).
6. בקרות לאחר פרסום: משימות עדכון SOP/חוזה/סקריפט.

כלל שני מפתחות: הוצאה לאור אפשרית רק עם 2 + אישורים מרשימת התפקידים המאושרים.

8) אחיזה חוקית

חקירה, בקשה משפטית, סקירה רגולטורית.
מה שאנחנו עושים: דגל 'hold _ flags = [ ”חוקי” ], להקפיא תיקוני מחיקה/גרסה, ארכיון WORM, יומן פעילות Hold.
החזק משיכה: חוקי/DPO בלבד; כל הפעולות מחוברות.

9) פרטיות ורגולציה מקומית

מזעור PII ביומן (זיהוי עובד חנות במקום דואר אלקטרוני, במידת האפשר).
תקופות שימור = ”לוחות זמנים” (רשומות מדיניות הן בדרך כלל 5-7 שנים).
DSAR/RTBF: הרישום נשלל ממחיקה אם קיימת חובת משמורת חוקית; אנחנו מתקנים את הבסיס החוקי.

10) אינטגרציות

Confluence/Docs/Git: מקור של עריכה וחפצים (diff, PDF).
תפקידי עובד ומאפיינים גישה ליומן ביקורת.
אימון, בדיקות, הכרה.
מערכת יחסים עם סיכונים, בקרות, CAPA/תוכניות.
SIEM/Logs: ביקורת על פעולות כתב עת (שצפו/ייצאו).
Ticketing (Jira/YouTrace): הפעלת משימות ושחרור רשימות.

11) מדדים ו ־ SLO

כיסוי:% מהמדיניות הנוכחית עם כניסת יומן אחרון (יעד 99%).
Time-to-Publish: זמן חציוני מ- "hasged _ at' to" published _ at "(המטרה, 14 ימים; דחוף 48 שעות).
ack-rate: מידת העובדים שאישרו את ההיכרות (יעד 98% תוך 14 ימים).
ביקורת מוכנות: פרופורציה של מדיניות עם אוסף מלא של חפצים (diff, PDF, חתימות) (100% מטרה).
חריגים נסגרו:% חריגים/סטיות סגורים בתאריך.
ביקורת גישה: 0 תקריות גישה ליומן לא מורשה.

12) לוח מחוונים (סט מינימלי של וידג 'טים)

הזנה של פרסומים ופרסומים אחרונים.
מפת מצב לפי תחום (אבטחה, נתונים, AML, Ops).
מפת חום של עיכובים באישור.
היסטוגרמה של זמן לפרסום/זמן-in-Review.
דרגה על ידי מחלקה ותפקיד.
רשימת שינויים רגולטוריים/דחופים פתוחים.

13) נהלים ותבניות

תבנית תקליט סימון:

{policy_title} — {version}
Change ID: {change_id}      Type: {change_type}      Effective: {effective_from}
Summary: {summary}
Rationale: {rationale}
Impacts: {impact_scope}
Approvals: {approver} at {approved_at}
Artifacts: {links}
Training: {training_required}
רשימת המלצות:
[ ] כל השדות והחפצים הנדרשים
[ ] השפעה מוערכת וסיכונים מעודכנים
[ ] שליטה כפולה
[ ] חבילת Immutable שנוצרה (PDF + hash)
[ ] Dailings and ack קמפיין מוגדר
[ ] SOP/Runbooks/חוזים (אם יידרש)

14) בקרת גישה וביטחון

RBAC לקרוא/ליצור/לאשר/תפקידי ארכיון.
רק-in-Time: רשות פרסום/יצוא זמנית.
הצפנה: TLS in-transit, KMS at-rest; לאסור יצוא אנונימי.
ביקורת: רישומים של כל הפעולות, התראות לפעולות חריגות (יצוא המוני, עריכה תכופה).

15) יישום באמצעות צעדים

MVP (2-4 שבועות):

1. ספרייה של מדיניות והבעלים שלהם.

2. תבנית תקליט אחת + נדרשים שדות.

3. Registry in Confluence/Mission או Policy-CMS פשוט; יצוא PDF בלתי הפיך.

4. עבודה בסיסית של אישורים וקמפיין אק באמצעות דואר/LMS.

5. תפקידי גישה וכריתת פעילות.

שלב 2 (שבועות 4-8):
  • אינטגרציה עם Git עבור diff ו ויסות סמנטי.
  • קישורי GRC עם סיכונים/בקרה, דיווחים לביקורת.
  • לוח מחוונים KPI/SLO, תזכורות אוטומטיות לפי תאריך.
שלב 3 (8-12 שבועות):
  • API/webhooks עבור מערכות חיצוניות, התאמת כלל כקוד.
  • ארכיון חוקי Hold + WORM, חתימות קריפטוגרפיות של חבילות שחרור.
  • ריבוי תחומי שיפוט (תגיות לפי שוק/שפה/גרסה).

16) טעויות תכופות וכיצד להימנע מהן

שינויים מחוץ לכתב העת: מכחיש פרסומים לא רשומים, בדיקות אוטומטיות.
אין רציונל/אזכורים: הפוך את תבניות השדה + מקור חובה (רגולטור, ביקורת חשבונות, תקרית).
אין אק בקרה: אינטגרל LMS/HRIS ועקוב אחר KPIs.
מיקס טיוטות ופרסומים - השתמש ברווחים/ענפים נפרדים.
גישה ”לכל”: RBAC קפדן, ביקורת קריאה לייצוא.

17) גלוסרי (קצר)

מדיניות - מסמך ניהול עם דרישות חובה.
תקן/הליך/SOP - סדר גרנולריות וביצוע.
CAPA - פעולות מתקנות ומונעות.
הכרה (אק) - אישור של היכרות על ידי העובד.
Hold משפטי - הקפאה חוקית של שינויים/מחיקות.

18) השורה התחתונה

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

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

בלחיצה על הכפתור אתם מסכימים לעיבוד הנתונים שלכם.