Skill תמיכה בביקורת ל-Claude

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

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

מתודולוגיית בדיקת בקרות SOX 404

סקירה כללית

סעיף 404 של SOX מחייב את ההנהלה להעריך את האפקטיביות של בקרות פנימיות על דיווח כספי (ICFR). תהליך זה כולל:

1. קביעת היקף: זיהוי חשבונות מהותיים וטענות רלוונטיות
2. הערכת סיכונים: הערכת סיכון לטעות מהותית בכל חשבון מהותי
3. זיהוי בקרות: תיעוד הבקרות המטפלות בכל סיכון
4. בדיקה: בחינת אפקטיביות העיצוב והפעולה של בקרות מפתח
5. הערכה: בחינה האם קיימים ליקויים ומה חומרתם
6. דיווח: תיעוד ההערכה וכל חולשה מהותית

קביעת היקף החשבונות המהותיים

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

גורמים כמותיים:

• יתרת החשבון עולה על סף המהותיות (בדרך כלל 3–5% מאמת מידה מרכזית)
• נפח העסקאות גבוה, המגדיל את סיכון הטעות
• החשבון כפוף להערכות או שיקול דעת משמעותיים

גורמים איכותיים:

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

טענות רלוונטיות לפי סוג חשבון

אפקטיביות עיצוב לעומת אפקטיביות פעולה

אפקטיביות עיצוב: האם הבקרה מתוכננת כראוי למניעה או גילוי של טעות מהותית בטענה הרלוונטית?

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

אפקטיביות פעולה: האם הבקרה פעלה בפועל כפי שתוכננה לאורך תקופת הבדיקה?

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

גישות לבחירת מדגם

בחירה אקראית

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

שיטה:

1. הגדרת האוכלוסייה (כל העסקאות הכפופות לבקרה במהלך התקופה)
2. מספור כל פריט באוכלוסייה ברצף
3. שימוש בגנרטור מספרים אקראיים לבחירת פריטי המדגם
4. הבטחה שאין הטיה בבחירה (לכל הפריטים הסתברות שווה)

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

בחירה ממוקדת (שיפוטית)

מתי להשתמש: תוספת לבחירה אקראית לבדיקות מבוססות-סיכון; שיטה ראשית כשהאוכלוסייה קטנה או מגוונת מאוד.

שיטה:

1. זיהוי פריטים עם מאפייני סיכון ספציפיים:
   • סכום גבוה (מעל סף מוגדר)
   • עסקאות יוצאות דופן או לא-סטנדרטיות
   • עסקאות לקראת סוף תקופה (סיכון גזירה)
   • עסקאות עם צדדים קשורים
   • עסקאות ידניות או עוקפות
   • עסקאות עם ספק/לקוח חדש
2. בחירת פריטים התואמים לקריטריוני הסיכון
3. תיעוד הנימוק לכל בחירה ממוקדת

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

בחירה שרירותית

מתי להשתמש: כאשר בחירה אקראית אינה מעשית (אין רשימת אוכלוסייה רצופה) והאוכלוסייה הומוגנית יחסית.

שיטה:

1. בחירת פריטים ללא תבנית ספציפית או הטיה
2. הבטחה שהבחירות מפוזרות על פני כל תקופת האוכלוסייה
3. הימנעות מהטיה לא-מודעת (לא לבחור תמיד פריטים בתחילה, מספרים עגולים וכו')

יתרונות: פשוט, אינו דורש טכנולוגיה חסרונות: אינו תקף סטטיסטית, רגיש להטיה לא-מודעת

בחירה שיטתית

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

שיטה:

1. חישוב מרווח הדגימה: גודל האוכלוסייה / גודל המדגם
2. בחירת נקודת התחלה אקראית בתוך המרווח הראשון
3. בחירת כל פריט ה-N מנקודת ההתחלה

דוגמה: אוכלוסייה של 1,000, מדגם של 25 → מרווח של 40. התחלה אקראית: פריט 17. בחירת פריטים 17, 57, 97, 137, ...

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

הנחיות לגודל מדגם

גורמים המגדילים את גודל המדגם:

• סיכון מובנה גבוה יותר בחשבון/תהליך
• הבקרה היא הבקרה היחידה המטפלת בסיכון מהותי (ללא יתירות)
• ליקוי בקרה זוהה בתקופה קודמת
• בקרה חדשה (לא נבדקה בתקופות קודמות)
• הסתמכות מבקר חיצוני על בדיקת ההנהלה

תקני תיעוד בדיקות

דרישות ניירות עבודה

כל בדיקת בקרה צריכה להיות מתועדת עם:

1. זיהוי הבקרה:

   • מספר/מזהה הבקרה
   • תיאור הבקרה (מה נעשה, על ידי מי, באיזו תדירות)
   • סוג הבקרה (ידנית, אוטומטית, ידנית תלויית-IT)
   • תדירות הבקרה
   • הסיכון והטענה שהבקרה מטפלת בהם

2. תכנון הבדיקה:

   • מטרת הבדיקה (מה מנסים לקבוע)
   • נהלי הבדיקה (הוראות שלב-אחר-שלב)
   • ראיות צפויות (מה צפוי לראות אם הבקרה אפקטיבית)
   • מתודולוגיית בחירת מדגם ונימוק

3. ביצוע הבדיקה:

   • תיאור האוכלוסייה וגודלה
   • פרטי בחירת המדגם (שיטה, פריטים שנבחרו)
   • תוצאות לכל פריט מדגם (עבר/נכשל עם ראיות ספציפיות שנבדקו)
   • חריגות שנרשמו עם תיאור מלא

4. מסקנה:

   • הערכה כוללת (אפקטיבי / ליקוי / ליקוי מהותי / חולשה מהותית)
   • בסיס למסקנה
   • הערכת השפעה לכל חריגה
   • בקרות מפצות שנשקלו (אם רלוונטי)

5. חתימה:

   • שם הבודק ותאריך
   • שם הסוקר ותאריך

תקני ראיות

ראיות מספיקות כוללות:

• צילומי מסך המציגים בקרות שנאכפות על ידי המערכת
• מסמכי אישור חתומים/מאושרים בראשי תיבות
• אישורים בדואר אלקטרוני עם מזהה מאשר ותאריך
• יומני ביקורת מערכת המציגים מי ביצע את הפעולה ומתי
• חישובים שבוצעו מחדש עם תוצאות תואמות
• הערות תצפית (עם תאריך, מיקום, משקיף)

ראיות לא מספיקות:

• אישורים בעל-פה בלבד (חייבים אימות)
• מסמכים ללא תאריך
• ראיות ללא מבצע/מאשר מזוהה
• דוחות מערכת גנריים ללא חותמות תאריך/שעה
• "לפי שיחה עם [שם]" ללא תיעוד מאמת

ארגון ניירות עבודה

ארגון קבצי הבדיקה לפי תחום בקרה:

SOX Testing/
├── [Year]/
│   ├── Scoping and Risk Assessment/
│   ├── Revenue Cycle/
│   │   ├── Control Matrix
│   │   ├── Walkthrough Documentation
│   │   ├── Test Workpapers (one per control)
│   │   └── Supporting Evidence
│   ├── Procure to Pay/
│   ├── Payroll/
│   ├── Financial Close/
│   ├── Treasury/
│   ├── Fixed Assets/
│   ├── IT General Controls/
│   ├── Entity Level Controls/
│   └── Summary and Conclusions/
│       ├── Deficiency Evaluation
│       └── Management Assessment

סיווג ליקויי בקרה

ליקוי

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

גורמי הערכה:

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

ליקוי מהותי

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

מדדים:

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

חולשה מהותית

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

מדדים:

• זיהוי מרמה על ידי הנהלה בכירה (בכל סכום)
• תיקון (restatement) של דוחות כספיים שפורסמו בעבר לתיקון טעות מהותית
• זיהוי על ידי המבקר של טעות מהותית שלא הייתה מתגלה על ידי בקרות החברה
• פיקוח לא אפקטיבי של ועדת הביקורת על הדיווח הכספי
• ליקוי בבקרה רחבה (ברמת הישות, בקרה כללית IT) המשפיעה על תהליכים מרובים

צבירת ליקויים

ליקויים בודדים שאינם מהותיים בנפרד עשויים להיות מהותיים במשולב:

1. זיהוי כל הליקויים באותו תהליך או המשפיעים על אותה טענה
2. הערכה האם ההשפעה המשולבת עשויה לגרום לטעות מהותית
3. שקילה האם ליקויים בבקרות מפצות מחמירים ליקויים אחרים
4. תיעוד ניתוח הצבירה והמסקנה

תיקון

לכל ליקוי שזוהה:

1. ניתוח שורש: מדוע הבקרה נכשלה? (פגם בעיצוב, כשל בביצוע, כוח אדם, הכשרה, בעיית מערכת)
2. תוכנית תיקון: פעולות ספציפיות לתיקון הבקרה (עיצוב מחדש, הכשרה נוספת, שיפור מערכת, סקירה נוספת)
3. לוח זמנים: תאריך יעד להשלמת התיקון
4. בעלים: האחראי ליישום התיקון
5. אימות: כיצד ומתי הבקרה המתוקנת תיבדק מחדש לאישור אפקטיביות

סוגי בקרות נפוצים

בקרות כלליות IT (ITGCs)

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

בקרות גישה:

• הקצאת גישה למשתמשים (בקשות גישה חדשות דורשות אישור)
• ביטול גישה למשתמשים (עובדים שסיימו עבודתם מוסרים בזמן)
• ניהול גישה מורשית (גישת admin/superuser מוגבלת ומפוקחת)
• סקירות גישה תקופתיות (גישת משתמש מאושרת מחדש בלוח זמנים מוגדר)
• מדיניות סיסמאות (מורכבות, רוטציה, נעילה)
• אכיפת הפרדת תפקידים (גישה מתנגשת נמנעת)

ניהול שינויים:

• בקשות שינוי מתועדות ומאושרות לפני יישום
• שינויים נבדקים בסביבה שאינה ייצור לפני קידום
• הפרדה בין סביבות פיתוח וייצור
• נהלי שינוי חירום (מתועדים, מאושרים לאחר יישום)
• סקירת שינויים ואימות לאחר יישום

תפעול IT:

• ניטור משימות batch וטיפול בחריגות
• נהלי גיבוי ושחזור (גיבויים סדירים, בדיקות שחזור)
• ניטור זמינות ביצועי מערכת
• נהלי ניהול תקריות והסלמה
• תכנון ובדיקת התאוששות מאסון

בקרות ידניות

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

דוגמאות:

• סקירת הנהלה של דוחות כספיים ומדדי מפתח
• אישור מפקח לרשומות יומן מעל סף מסוים
• אימות תלת-כיווני (הזמנת רכש, קבלה, חשבונית)
• הכנה וסקירה של התאמת חשבונות (כרטסת)
• תצפית וספירת מלאי פיזי
• אישור שינוי נתוני אב ספקים
• אישור אשראי ללקוח

מאפייני מפתח לבדיקה:

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

בקרות אוטומטיות

בקרות שנאכפות על ידי מערכות IT ללא התערבות אנושית.

דוגמאות:

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

גישת בדיקה:

• בדיקת עיצוב: אישור שתצורת המערכת אוכפת את הבקרה כמיועד
• בדיקת אפקטיביות פעולה: לבקרות אוטומטיות, אם תצורת המערכת לא השתנתה, בדיקה אחת של הבקרה בדרך כלל מספיקה לתקופה (בתוספת בדיקת ITGCs של ניהול שינויים)
• אימות שה-ITGCs של ניהול שינויים אפקטיביים (אם המערכת השתנתה, בדיקת הבקרה מחדש)

בקרות ידניות תלויות-IT

בקרות ידניות המסתמכות על שלמות ודיוק של מידע שנוצר על ידי המערכת.

דוגמאות:

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

גישת בדיקה:

• בדיקת הבקרה הידנית (סקירה, אישור, מעקב על חריגות)
• ובנוסף בדיקת שלמות ודיוק הדוח/נתונים הבסיסיים (IPE — מידע שנוצר על ידי הישות)
• בדיקת IPE מאשרת שהנתונים עליהם הסתמך הסוקר היו שלמים ומדויקים

בקרות ברמת הישות

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

דוגמאות:

• "טון מלמעלה" / קוד אתיקה
• תהליך הערכת סיכונים
• פיקוח ועדת הביקורת על הדיווח הכספי
• תפקוד הביקורת הפנימית ופעילויותיה
• הערכת סיכוני תרמית ותוכניות למניעת תרמית
• קו חם לעובדים/אתיקה
• ניטור הנהלה על אפקטיביות הבקרה
• יכולת דיווח כספי (כוח אדם, הכשרה, כישורים)
• תהליך הדיווח הכספי לסוף תקופה (נהלי סגירה, סקירות עמידה ב-GAAP)

חשיבות:

• בקרות ברמת הישות יכולות להקטין אך בדרך כלל אינן יכולות להחליף בקרות ברמת התהליך
• בקרות לא-אפקטיביות ברמת הישות (בעיקר פיקוח ועדת הביקורת וטון מלמעלה) הן אינדיקטורים חזקים לחולשה מהותית
• בקרות אפקטיביות ברמת הישות עשויות להפחית את היקף הבדיקות הנדרשות לבקרות ברמת התהליך