سیاست انطباق مدیریت تغییر

1) چرا تغییر را مدیریت می کنیم

• پاسخ به موقع به مقررات/ریسک ؛
• سازگاری و اندازه گیری الزامات
• اجرای قابل پیش بینی بدون رگرسیون و تفسیرهای بحث برانگیز ؛
• مبنای شواهد برای حسابرسان (چه کسی، چه زمانی، چرا و چگونه تغییر کرده است).

2) تغییر عوامل

قوانین جدید/به روز شده، راهنماهای نظارتی، نامه های موقعیت.
نتایج حسابرسی، حوادث، درس های آموخته شده، KRI های افزایش یافته.
راه اندازی/تغییر محصولات، دسترسی به حوزه های قضایی جدید.
تغییرات فنی (معماری، ابر، رمزگذاری، IAM، DevSecOps).

تغییر ریسک پذیری/استراتژی شرکت

3) تغییر نوع و معیارها

4) نقش ها و RACI

(R - مسئول ؛ الف - مسئولیت پذیری ؛ C - مشاوره ؛ من - مطلع)

5) فرآیند مدیریت تغییر (SOP)

1. شروع: تغییر کارت (دلیل، هدف، نوع، حوزه های قضایی، مهلت، خطر).
2. ارزیابی تاثیر: چه کسی/چه چیزی تحت تاثیر قرار می گیرد (خدمات، داده ها، نقش ها، قراردادها)، هزینه، وابستگی ها، درگیری با SOP ها/استانداردهای فعلی.
3. پیش نویس و نقشه برداری: نسخه جدید/به روز شده، اظهارات کنترل، نقشه برداری به هنجارها/گواهینامه ها، معیارهای قابل اندازه گیری.

4. بررسی همکار: حقوقی/DPO/SecOps/کسب و کار ؛ پروتکل نظرات و تصمیمات

5. آوریل: مالک → (تحت عمده) سیاست هیئت مدیره/اجرایی.
6. برنامه پیاده سازی: مهلت ها، مراحل، آمادگی سیستم ها/تیم ها، مراحل مهاجرت.
7. ارتباطات: یک صفحه/پرسش و پاسخ، اعلام نقش، مهلت و CTA (نگاه کنید به «ارتباطات انطباق»).
8. آموزش/صدور گواهینامه: دوره ها/آزمونها در LMS، مورد نیاز٪ عبور، مسدود کردن دسترسی در صورت عدم عبور (با خطر).
9. پیاده سازی و کنترل: دروازه در CI/CD، DLP/EDRM/IAM/ارائه به روز رسانی، نظارت بر اجرای.
10. شواهد و ممیزی: نسخه های عکس فوری، مصنوعات آموزشی، پروتکل های راه حل، آرشیو WORM.
11. پس از بررسی: ارزیابی اثر، تنظیم قانون/متریک، بسته شدن دم.

6) نسخه و «سیاست به عنوان کد»

ذخیره سازی در مخزن (Git): خط مشی/استاندارد/رویه ها به عنوان Markdown/YAML ؛ بررسی PR، برچسب های نسخه، تغییرات.
روشن اظهارات کنترل با معیارهای آزمون: مناسب بودن برای اتوماسیون (انطباق به عنوان کد).
«نسخه خط مشی ↔ استانداردها/رویه ها نسخه ↔ قوانین نظارت (CCM)» بسته نرم افزاری.
برای اورژانس - شعبه hotfix + PR اجباری پس از واقعیت با بررسی کامل.

7) محلی سازی و حوزه های قضایی

نسخه اصلی + ضمیمه کشور: دستاوردهای محلی بدون ضعف.

واژه نامه اصطلاحات، شماره نسخه واحد (به عنوان مثال،. 2. 1-EE/2 است. 1-TR)

فرآیند هماهنگ سازی: عمده در استاد → مهلت برای به روز رسانی محل → کنترل خارج از همگام سازی.

8) ارتباطات و مدیریت تغییر «در زمینه»

ماتریس مخاطب: Dev/ops/data/product/finance/AML/HR/exec.
قالب ها: یک پیجر، یادداشت انتشار، سوالات متداول (6-10 سوال)، قالب PR، قطعه SQL/config.
کانال ها: ویکی/پورتال سیاست، اسلک/تیم ها، اهداف ایمیل، LMS، کارگاه های آموزشی.
ارتباطات SLA: ≤ بحرانی 24 ساعت ؛ 7-14 روز قبل از ورود ؛ متوسط 14-30 روز.
تثبیت اجباری: خواندن-دریافت/مسابقه + ورود به GRC.

9) ادغام با کنترل ها و سیستم ها

IAM/IGA: چرخش SoD/دسترسی، پیوند آموزش به نقش ها.
پلت فرم داده: TTL/retention، Legal Hold، masking، lineage.
DevSecOps: گیتس انطباق، SAST/DAST/SCA، مجوزهای OSS.
ابر/IaC - Terraform/K8s را برای نیازهای جدید بررسی کنید.
SIEM/SOAR/DLP/EDRM: قوانین و دستورالعمل ها برای اجرای.
GRC: ثبت نام نسخه، چشم پوشی، چک لیست حسابرسی، هنجار ↔ ماتریس کنترل.

10) چشم پوشی و انتقال

درخواست: دلیل، خطر، اقدامات جبرانی، تاریخ انقضا.
دسته بندی ها: عدم امکان فنی، وابستگی تامین کننده، محدودیت های قراردادی.
دید در داشبورد، یادآوری خودکار، تشدید بزهکاری.
پنجره های انتقال (دوره فضل) با تاریخ ها و KPI های پیاده سازی ثابت می شوند.

11) تغییر معیارهای فرآیند و SLO

MTTU (میانگین زمان به روز رسانی) - از ماشه تا انتشار (عمده ≤ 30 روز).
SLA ارتباطات:٪ از نقش های آسیب دیده که اعلان ها را به موقع دریافت می کنند (≥ 98٪).
پوشش آموزشی:٪ واجد شرایط در زمان (≥ 95٪).
نرخ پذیرش: درصد سیستم ها/فرایندهایی که الزامات اجرا می شوند (≥ برنامه هدف).
رانش پس از تغییر: نقض کنترل پس از ورود (روند ↓).
چشم پوشی بهداشت:٪ چشم پوشی با تاریخ انقضا واقعی (100٪).
آمادگی حسابرسی: زمان جمع آوری شواهد برای یک نسخه خاص (≤ 8 ساعت).

12) داشبورد (حداقل مجموعه)

تغییر خط لوله: стадия (پیش نویس/بررسی/تایید/Comm/قطار/استقرار).
پوشش و پذیرش: آموزش، ادعای پذیرش، بسته شدن بلیط.
رانش و نقض: توسط مالک/شدت.
چشم پوشی & مهلت: استثنا فعال, مهلت, تشدید.
محلی سازی همگام سازی: وضعیت محلی و desynchrones.
Audit Pack: مجموعه ای از مصنوعات «بر روی دکمه» برای نسخه انتخاب شده.

13) چک لیست

قبل از شروع تغییر

• کارت 7W (چه/چرا/چه کسی/چه زمانی/کجا/چگونه/برنده).
• ارزیابی تاثیر، وابستگی ها، ماتریس درگیری.
• Norm/certification mapping + اظهارات کنترل قابل اندازه گیری.
• بررسی همکار (حقوقی/DPO/SecOps/کسب و کار) بسته، پروتکل در GRC.
• طرح ارتباطات و آموزش ؛ مواد یک پیجر/پرسش و پاسخ/قطعه.
• طرح پیاده سازی و تست (مرحله بندی → prod)، سازگاری با عقب.
• لیست شواهد: چه چیزی را تعمیر و کجا ذخیره کنید (WORM).

پس از پیوستن به

• تأیید کنترل های گنجانده شده (CCM) و داشبورد.
• آموزش و پوشش گزارش.
• تجزیه و تحلیل رانش/حادثه، تنظیمات قانون.
• به روز رسانی مرتبط SOPs/استانداردها/playbooks.

[درس های آموخته شده]

14) ضد گلوله

تغییر «از طریق پست» بدون رجیستری، نسخه ها و شواهد.
عبارت غیر قابل اندازه گیری («باید کافی باشد»)، برای اتوماسیون مناسب نیست.
بدون ارزیابی تاثیر و درگیری با اسناد مرتبط.
ارتباطات بدون مهلت/STA و بدون تثبیت خواندن/یادگیری.
چشم پوشی «ابدی» و دوره های انتقالی.
هیچ هماهنگ سازی محلی سازی → نیازهای مختلف در مناطق وجود دارد.

15) مدل بلوغ (M0-M4)

مستند M0: به روز رسانی نادر، ارسال نامه های دستی.
کاتالوگ M1: ثبت نام نسخه یکپارچه، روند ارتقاء اساسی.
M2 مدیریت: RACI، داشبورد، آموزش، چشم پوشی ثبت نام.
M3 یکپارچه: سیاست به عنوان کد، دروازه در CI/CD، کنترل CCM، شواهد WORM.
M4 تضمین مداوم: تغییر → ارتباطات خودکار → آموزش → کنترل → «حسابرسی آماده توسط دکمه».

16) مقالات ویکی مرتبط

چرخه عمر سیاست ها و رویه ها

ارتباطات راه حل های انطباق در تیم

نظارت بر انطباق مداوم (CCM)

اتوماسیون انطباق و گزارش دهی

نگهداری قانونی و انجماد داده ها

KPI ها و معیارهای انطباق

علت سعی و کوشش و خطرات برون سپاری

مجموع

مدیریت تغییر قوی یک فرایند شفاف و تجدید پذیر است: محرک های روشن، الزامات قابل اندازه گیری، ارتباطات و آموزش منظم، ادغام در سیستم های کنترل فنی و مجموعه ای کامل از شواهد. بنابراین سیاست انطباق زنده، قابل فهم و «حسابرسی» باقی می ماند - بدون شگفتی برای کسب و کار.