By · Last updated 2026-06-05

חזרה לבלוגGDPR ועמידה

כישלון בביקורת GDPR: כלי PII מפוצלים

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

June 5, 20266 דקות קריאה
GDPR auditcompliance controlsPII tool consistencyDPA investigationtechnical measures

כישלון בביקורת GDPR: כלי PII מפוצלים

עדכון לשנת 2026.

המבקר שלכם שואל שאלה אחת: "אילו בקרות טכניות מגינות על נתונים אישיים?" התשובה השגויה: "אנחנו משתמשים בחמישה כלים שונים." הנה מדוע שימוש בחמישה כלים נכשל בביקורות GDPR — ומה נראית תשובה נכונה.

רגע הביקורת

חוקר מרשות הגנת נתונים (DPA) נפגש עם קצין ציות. ה-DPA בוחן תלונת נושא נתונים. לקוח לשעבר טוען כי המידע שלו טופל שלא כשורה.

השאלה: "אילו בקרות הארגון שלכם משתמש בהן כדי לשמור על אבטחת נתונים אישיים בעת עיבודם על ידי עובדים?"

קצין הציות: "עורכי הדין שלנו משתמשים בתוסף Word. צוות התמיכה משתמש בהרחבת Chrome. צוות הנתונים שלנו יש לו סקריפט Python. לבקשות חד-פעמיות, כל אחד יכול להשתמש ביישום האינטרנט."

החוקר: "האם אלו אותו כלי? אותו מנוע? אותו כיסוי?"

קצין הציות: "לא. הם עובדים בצורה שונה."

באותו רגע הביקורת מסתבכת.

מדוע כלים מפוצלים נכשלים בסעיף 32

סעיף 32 ל-GDPR דורש "אמצעים טכניים וארגוניים מתאימים." לסטנדרט יש שני חלקים.

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

הוכחה. ניתן להוכיח אמצעים. עיקרון האחריותיות — סעיף 5(2) — דורש שבקרים "יוכלו להוכיח ציות." כלומר ראיות לבקרה עקבית. לא מאמץ מיטבי. עקבית.

כלים מפוצלים נכשלים בהוכחה. כלי A מזהה 285 סוגי ישויות. כלי B מזהה 50. כלי C מזהה 200 אך עם ספים שונים. אי אפשר להוכיח הגנה עקבית עם ערימה כזו. ניתן רק להראות שחלק מהכלים פעלו בחלק מההקשרים.

ממצא DPA על כלים מפוצלים קובע: "בקרות טכניות להגנת PII אינן עקביות בזרימות עבודה. זה יוצר פערים בכיסוי ומונע סקירת מסלול ביקורת מרכזית."

בעיית גילוי הפערים

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

נניח שכלי B (המשמש את צוות הנתונים) אינו מזהה מספרי זהות לאומיים אירופאיים. כלי A (המשמש עורכי דין) כן מזהה. פער זה בלתי נראה במהלך עבודה רגילה. קבצים מעובדים. אין התראות. נראה שהכל בסדר.

הפער מתגלה כאשר:

  • מספר זהות לאומי אירופאי מופיע בקובץ שצוות הנתונים עיבד
  • קובץ זה משותף ללא בקרות
  • נושא הנתונים מגלה את החשיפה ומגיש תלונת GDPR

כעת ה-DPA חושף פער. צוות הנתונים הריץ כלי עם כיסוי שונה מצוותים אחרים. פער שהיה צריך להימצא ולהיסגר.

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

ראו סעיף 32 ל-GDPR וניטור כלי בינה מלאכותית למה מבקרים מחפשים בבקרות טכניות.

איך נראית תשובת ציות תקינה

קצין הציות עם פלטפורמה מאוחדת עונה אחרת.

"אנחנו משתמשים בפלטפורמת זיהוי PII אחת בכל זרימות העבודה. עורכי דין, סוכני תמיכה ומהנדסי נתונים משתמשים באותו מנוע זיהוי. הממשקים שונים — תוסף Word, הרחבת Chrome, יישום שולחן עבודה — אך המודל וההגדרה זהים. כל העיבוד נרשם במסלול ביקורת מרכזי. ההגדרה שלנו מכסה 285+ סוגי ישויות עם הגדרות מותאמות לתחום שיפוט. אני יכול למשוך כל תקופה שתצרכו."

תשובה זו:

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

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

סטנדרט העקביות חוצת-הפלטפורמות

לעמדת סעיף 32 חזקה, אלו הדרישות המינימליות.

עקביות זיהוי:

  1. אותו מודל זיהוי או API בכל הפלטפורמות
  2. אותו כיסוי סוגי ישויות — אם יישום האינטרנט בודק 285 ישויות, יישום שולחן העבודה חייב גם כן
  3. אותם ספי ביטחון — אף כלי אינו רפוי או מחמיר יותר עבור אותו סוג ישות
  4. אותם אסימוני החלפה עבור אותם סוגי ישויות
  5. מסלול ביקורת מרכזי בכל הפלטפורמות

דרישות תיעוד:

  • תמונת תצורה: כיסוי ישויות וספים נוכחיים
  • היסטוריית שינויים: מה השתנה ומתי
  • הוכחת כיסוי: כל הפלטפורמות חולקות את אותה הגדרה

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

להסתכלות רחבה יותר על עקביות חוצת-פלטפורמות, ראו ציות PII חוצה-פלטפורמות: Mac, Linux, Windows.

מעבר מעשי: מפוצל לאחיד

שלב 1: מפו כלים וכיסוי

  • פרטו כל כלי לפי צוות וזרימת עבודה
  • תעדו אילו סוגי PII כל כלי מזהה
  • מצאו את הפערים — מה כלי A מזהה שכלי B מפספס?

שלב 2: הגדירו את סטנדרט הכיסוי

  • בהתבסס על חובותיכם — סוגי ישויות GDPR, PHI של HIPAA, קטגוריות CCPA
  • קבעו סטנדרט אחד שחל על כל זרימות העבודה

שלב 3: בחרו את הפלטפורמה המאוחדת

  • האם ניתן לפרוס אותה על פני אינטרנט, שולחן עבודה, Word ודפדפן?
  • האם היא עומדת בסטנדרט הכיסוי שלכם?
  • האם היא מספקת מסלול ביקורת מרכזי?

שלב 4: העבירו

  • התחילו עם זרימות העבודה בסיכון הגבוה ביותר
  • עברו צוות אחרי צוות ופסלו כלים ישנים כשהמשתמשים עוברים
  • תעדו את ההגירה ביומן הציות שלכם

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

מקורות

מוכן להגן על הנתונים שלך?

התחל לאנונימיזציה של PII עם 285+ סוגי ישויות ב-48 שפות.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.