گزارش نگرانی محفوظ؛ از Safe Route تا Protection

پاسخ کوتاه: وقتی یک متخصص نرم‌افزار با نشانه‌ای از تخلف، خطر عمومی، پنهان‌کاری یا Retaliation روبه‌رو می‌شود، اقدام حرفه‌ای این نیست که فوراً «همه‌چیز را کپی کند»، همهٔ مدیران را ایمیل بزند یا رسانه را آخرین مرحلهٔ یک نردبان ثابت بداند. ابتدا باید Fact و Allegation جدا شوند، فوریت و Harm سنجیده شود، حوزه و شرایط حمایت احتمالی با مشاور مستقل بررسی شود، Route امن و صاحب صلاحیت انتخاب گردد و Evidence فقط در حدود مجاز و ضروری حفظ شود. خروجی این راهنما یک Protected Concern Case Record است؛ نه تضمین Protected Disclosure.

این مقاله اطلاعات عمومی برای طراحی فرایند و گفت‌وگو با متخصص واجد صلاحیت است. دربارهٔ پرونده، شخص، شرکت یا قانون خاصی نظر حقوقی نمی‌دهد و کسی را به افشاگری، سکوت، استعفا، ضبط مکالمه، انتقال Secret یا انتشار عمومی دعوت نمی‌کند.

مالکیت این مقاله: Concern Case و Safe Route

یک Bug عادی را با قالب گزارش باگ حرفه‌ای ثبت کنید. چرخهٔ Finding و Triage در مدیریت نقص نرم‌افزار است. اگر موضوع گزارش یک آسیب‌پذیری به مالک محصول است، افشای هماهنگ آسیب‌پذیری Route جدا دارد. اگر سؤال یک دوراهی اخلاق حرفه‌ای است، اخلاق در تست نرم‌افزار چارچوب وسیع‌تری ارائه می‌دهد.

مقالهٔ حاضر زمانی مفید است که Concern دربارهٔ Wrongdoing یا Harm بالقوه باید از نظر Eligibility، Channel، Protection، Confidentiality، Retaliation و Case handling ارزیابی شود. عنوان «افشاگر» را پیش از بررسی شرایط حقوقی یا سیاستی به شخص نچسبانید.

چهار مسیر نزدیک اما متفاوت‌اند

مسیر	موضوع	مالک اولیه
Bug/Quality issue	رفتار محصول، Requirement یا Evidence فنی	Product/Engineering/QA
Grievance	اختلاف یا رفتار مربوط به وضعیت شخصی کار	HR/Employee relations طبق سیاست
CVD/Incident	آسیب‌پذیری یا بهره‌برداری امنیتی	Security/Incident/CVD owner
Whistleblowing candidate	اطلاعات دربارهٔ Wrongdoing با شرایط حمایت حوزه‌محور	Protected channel/competent body/advisor

یک رخداد می‌تواند چند مسیر داشته باشد، اما داده و دسترسی هر مسیر متفاوت است. Ticket عمومی باگ جای Case محرمانه نیست؛ Case افشاگری نیز نباید Incident response فوری یا حمایت فردی را معطل کند. Boundary و Cross-reference را ثبت کنید، نه اینکه همهٔ اطلاعات را در یک Inbox جمع کنید.

Whistleblowing تعریف جهانی واحد ندارد

Worker status، موضوع قابل گزارش، Public-interest/equivalent test، Reasonable-belief، زمان، Recipient، Channel، Deadline، Confidentiality و Remedy میان حوزه‌ها متفاوت‌اند. حتی نام حقوقی آن ممکن است Protected disclosure، reporting person، retaliation complaint یا اصطلاح دیگری باشد. مقالهٔ وب نمی‌تواند جای Applicability review را بگیرد.

مثال اتحادیهٔ اروپا: شرط‌ها و Routeها مشخص‌اند

Directive (EU) 2019/1937 برای Breachهای داخل Scope خود، شرایطی مانند Reasonable grounds و گزارش داخلی/خارجی یا Public disclosure مطابق فصل‌های مربوط دارد. Directive گزارش داخلی را هنگامی تشویق می‌کند که موضوع بتواند موثر در داخل رسیدگی شود و Reporter خطر Retaliation نبیند؛ پس «همیشه اول داخلی» برداشت درستی نیست. اجرای ملی، Role، Subject matter و تاریخ باید جدا بررسی شوند.

Public disclosure یک دکمهٔ مرحلهٔ آخر نیست

همین Directive برای Public disclosure شرایط خاصی مانند Follow-up ناکافی پس از Routeهای مربوط یا Reasonable grounds دربارهٔ خطر قریب/آشکار، آسیب برگشت‌ناپذیر، Retaliation یا احتمال پایین رسیدگی موثر بیان می‌کند. این شروط را نمی‌توان به هر کشور یا پرونده کپی کرد. رسانه، شبکهٔ اجتماعی یا انتشار Document می‌تواند حقوق افراد دیگر، Investigation، امنیت و خود Reporter را متاثر کند.

مثال بریتانیا: Recipient و Remit مهم‌اند

راهنمای رسمی GOV.UK برای Prescribed persons Scope خود را به Great Britain محدود می‌کند و از Public-interest/Reasonable-belief، نوع Wrongdoing و Channel مناسب می‌گوید. برای گزارش به Prescribed person، موضوع باید در Remit آن باشد و Reporter نسبت به صحت اساسی اطلاعات Reasonable belief داشته باشد. خود Recipient نیز همیشه مرجع نهایی تعیین Protection نیست.

مثال آمریکا: Deadline می‌تواند بسیار کوتاه باشد

فرم رسمی OSHA برای شکایت Retaliation توضیح می‌دهد Deadline بسته به قانون می‌تواند از ۳۰ تا ۱۸۰ روز از اقدام تلافی‌جویانه متفاوت باشد و فرم Emergency route نیست. این یک مثال مهم از خطر «اول چند ماه صبر کن» است؛ اما OSHA نیز Route عمومی برای هر کشور، صنعت یا موضوع نیست.

ایران: نهاد و حمایت را از روی نوع نرم‌افزار حدس نزنید

عبارت‌هایی مانند «مالی = بانک مرکزی» یا «پزشکی = سازمان غذا و دارو» برای انتخاب Route کافی نیستند. Legal entity، Sector، مجوز، موضوع Concern، Worker/contractor status، دادهٔ محرمانه، محل کار/اثر، قانون جاری، مرجع صالح و Deadline ممکن است متفاوت باشد. برای وضعیت واقعی ایران از وکیل واجد صلاحیت، نمایندهٔ صنفی/کارگری یا مرکز مشاورهٔ معتبر و مستقل کمک بگیرید؛ این مقاله فهرست نهاد یا تضمین حمایت ارائه نمی‌کند.

Protection نتیجهٔ شرایط است، نه نیت خالص

متن قدیمی «انگیزه باید کاملاً اخلاقی باشد» را کنار بگذارید. برخی چارچوب‌ها Reasonable belief، Truth-at-time، Subject matter، Public interest یا Channel را می‌سنجند و Motive ممکن است نقش متفاوتی داشته باشد. نیت شخص نه Fact را اثبات می‌کند، نه Protection را تضمین. تمرکز بر اطلاعات، مبنای باور، Route و شرایط حوزه‌ای امن‌تر است.

هدف، تشخیص زودهنگام Status نیست

در Intake اولیه از برچسب‌های «افشاگر واقعی»، «شکایت بی‌اساس»، «بدخواه» یا «Protected» پرهیز کنید. Concern را جدی، محرمانه و بی‌طرف دریافت کنید؛ سپس Scope/Eligibility را با Reviewer واجد صلاحیت بسنجید. ممکن است یک Report خارج Scope حمایت خاص باشد اما همچنان Bug، Grievance، Safety issue یا misconduct قابل رسیدگی باشد.

دو Perspective را در یک سند مخلوط نکنید

Reporter-side note برای Factهای خود شخص، گزینهٔ Route، Safety، Advice و Contact preference است. Organization case file برای Intake، Access، Conflict، Triage، Investigation و Follow-up است. سازمان مالک دفترچهٔ خصوصی Reporter نیست و Reporter نیز نباید Case file سازمان را خارج کند. RecordPerspective و Not-represented parties را صریح کنید.

Artifact اصلی: Protected Concern Case Record

CaseID / Version / Status / OpenedAt / Owner / Classification
Perspective / ReporterRole / RecipientRole / NotRepresentedParties
Concern: Observation / Interpretation / Allegation / Uncertainty / NotClaimed
Boundary: Bug / Grievance / CVD / Incident / WhistleblowingCandidate / Emergency
Harm / Urgency / AffectedPeople / SafeImmediateAction
Jurisdiction / WorkerStatus / Sector / Instrument / OfficialSource / AsOf
Eligibility / SubjectMatter / ReasonableBelief / Conditions / Unknowns
Channel / RecipientRemit / RouteOptions / Risks / AdvisorReview / Decision
ReporterSafety / ConfidentialityLimits / Data / EvidenceBoundaries
Report / Intake / Triage / Impartiality / RetaliationMonitoring
Investigation / Response / Feedback / External/Public Conditions
Support / Lifecycle / Closure / Correction / Limits

این Schema استاندارد ISO، قانون یا فرم رسمی هیچ نهاد نیست؛ یک ترکیب عملی برای Route review و Case governance است. فیلد کامل Protection یا Truth را ثابت نمی‌کند.

Concern را به سه لایه بشکنید

لایه	نمونهٔ محدود
Observation	در تاریخ D، Release gate با وضعیت HOLD ثبت شد.
Interpretation	ممکن است شرط مستند نادیده گرفته شده باشد.
Allegation/Hypothesis	احتمال دارد تغییر Status عمدی یا خلاف Policy بوده باشد؛ بررسی نشده.
Not claimed	نیت، جرم، مسئولیت حقوقی و گسترهٔ Harm اثبات نشده است.

«مدیر دستور پنهان‌کاری داد» با «Status تغییر کرد و دلیل ثبت نشد» یکی نیست. Fact، Source basis، زمان، فرد نام‌برده، Uncertainty و Correction route را نگه دارید. Allegation را با زبان قطعی وارد Subject line یا Channel عمومی نکنید.

Harm و فوریت را از Reputation جدا کنید

HarmID، افراد متاثر، Mechanism، Severity، Likelihood، Immediacy، Duration، Reversibility، Scale و Evidence را ثبت کنید. «شهرت شرکت آسیب می‌بیند» نه معیار اصلی Public interest است و نه مجوز پنهان‌کاری. اگر خطر فوری جان/سلامت/امنیت یا Incident جاری است، Emergency/Incident route ممکن است مقدم باشد؛ فرایند اداری نباید کمک فوری را معطل کند.

Emergency را در فرم عادی دفن نکنید

Urgent threat، Emergency route، Safe immediate action، Preservation need، Stop-work authority و Do-not-delay boundary را ازپیش تعیین کنید. Inbox افشاگری ممکن است ۲۴/۷ مانیتور نشود. شماره یا نهاد اضطراری واقعی به کشور/موضوع بستگی دارد؛ از منبع رسمی جاری و متخصص محلی استفاده کنید.

Jurisdiction Snapshot پیش از Route

Country/region، Employment nexus، Worker/contractor/applicant status، Sector، Instrument/version، Official source، As-of و Advisor را ثبت کنید. Remote work، شرکت چندملیتی، Contract law، محل وقوع رفتار و محل اثر می‌توانند چند حوزه بسازند. یک Template انگلیسی را به کارمند ایران منتقل نکنید.

Eligibility را یک Decision چندحالته نگه دارید

Reporting-person coverage، Subject-matter coverage، Public-interest/equivalent، Reasonable-belief test، Timing، Excluded information، Conditions و Unknowns را ثبت کنید. خروجی اولیه می‌تواند POTENTIALLY_COVERED، OUT_OF_SCOPE_BUT_ROUTE یا UNKNOWN_PENDING_ADVICE باشد؛ نه حکم قطعی Protection.

Channel باید Recipient و Remit داشته باشد

ChannelID/type، Recipient، Official remit، internal/external/public، Authentication، Accessibility، Language، Availability، Receipt و Current contact را بررسی کنید. ایمیل مدیر ارشد، Ethics hotline، Union، Legal adviser، Regulator و رسانه از نظر Protection و Confidentiality یکسان نیستند. Channel جعلی یا قدیمی می‌تواند اطلاعات حساس را لو بدهد.

Internal-first قاعدهٔ جهان‌شمول نیست

Internal feasibility، Conflict، Evidence concealment/destruction risk، Retaliation، Urgency، Competent external authority و Conditions public route را مقایسه کنید. گاهی داخل موثر و امن است؛ گاهی Recipient در Concern دخیل است؛ گاهی قانون مستقیم External reporting را می‌پذیرد؛ گاهی شروط دیگری دارد. Route را با Advisor review انتخاب کنید، نه نردبان ثابت.

CEO escalation همیشه ایمن نیست

فرستادن Email جمعی یا Deadline خودساخته ممکن است Identity را آشکار، Evidence را در معرض تغییر یا مسیر رسمی را مختل کند. Policy، Conflict map، Recipient remit، Legal privilege، Retaliation risk و Urgency را بسنجید. اگر escalation انتخاب شد، Scope، Request، Delivery receipt و Next update را محدود ثبت کنید.

Reporter Safety Plan پیش از Contact

Contact/device/account/location safety، Identity preference، anonymous/pseudonymous choice، Exposure risk، Support person، Wellbeing و Accessibility/language support را مرور کنید. استفاده از Device یا Account نامناسب ممکن است Metadata بسازد؛ اما این مقاله دستور پنهان‌سازی هویت یا دورزدن Monitoring نمی‌دهد. متخصص امنیت/حقوق محلی باید گزینهٔ مشروع و ایمن را تعیین کند.

Anonymous با Confidential یکی نیست

Anonymous یعنی Recipient هویت را نمی‌داند؛ Confidential یعنی می‌داند اما Access/Disclosure را محدود می‌کند. Pseudonymous نیز شناسهٔ واسط دارد. هرکدام Follow-up، Credibility، Protection و Investigation trade-off دارند. Preference، Limit، Re-identification risk و Recovery contact را ثبت کنید؛ وعدهٔ مطلق ندهید.

Confidentiality Guarantee را از Limit جدا کنید

چه کسی اختیار وعده دارد؟ Need-to-know چیست؟ چه قانون/تحقیق/دفاعی ممکن است Disclosure را لازم کند؟ آیا پیش از افشای هویت Notice داده می‌شود؟ Breach response چیست؟ UNODC محرمانگی را خط نخست حفاظت می‌داند، اما حتی آن نیز ممکن است در فرایند قضایی/تحقیق با حقوق طرف مقابل تعارض پیدا کند. وعدهٔ «هویت هرگز فاش نمی‌شود» خطرناک است.

«همه‌چیز را مستند کن» توصیهٔ ایمن نیست

Evidence باید در مالکیت/دسترسی مجاز، حداقل و مرتبط باشد. Personal data، Health/financial data، Secret، Source code، Credential، Customer record، Legal privilege، Trade secret و اطلاعات شخص ثالث محدودیت‌های جدا دارند. کپی به Personal email/cloud/USB یا خروج از محیط می‌تواند نقض تازه و خطر برای دیگران بسازد.

Evidence Preservation با Exfiltration فرق دارد

EvidenceID، Lawful possession، Original location، Metadata، Integrity، Access، Transfer، Copy rule، Recording rule، Do-not-acquire rule و Preservation request را ثبت کنید. گاهی اقدام درست درخواست Legal hold یا ثبت مسیر موجود است، نه ساخت نسخهٔ پنهان. اگر احتمال حذف Evidence هست، پیش از اقدام از Advisor/competent authority راهنمایی بگیرید.

ضبط مکالمه نسخهٔ عمومی ندارد

قانون ضبط، رضایت طرفین، Privacy، Employment policy و admissibility به حوزه و Context وابسته‌اند. هیچ مکالمه‌ای را صرفاً به توصیهٔ وبلاگ ضبط نکنید. Fact note معاصر نیز باید دقیق، حداقلی و بدون دستکاری باشد؛ متخصص محلی تعیین می‌کند چه روشی مشروع است.

Report حداقلی و تصمیم‌پذیر

• Factها با تاریخ، Source basis و Uncertainty؛
• Affected process و Harm boundary؛
• افراد نام‌برده فقط در حد ضرورت؛
• Evidence reference امن، نه Secret در Body؛
• Route/Follow-up درخواست‌شده؛
• Contact و Identity preference؛
• Not-claimed و Correction route.

عبارت «مدرک غیرقابل‌انکار» را حذف کنید. Intake باید بتواند Evidence ناقص یا در حال تکمیل را ارزیابی کند. Reporting person لازم نیست Investigator یا Prosecutor باشد و نباید برای «اثبات» به دسترسی بیشتر ترغیب شود.

سازمان چگونه Report را دریافت کند؟

ReceivedAt/By، Ack، Case reference، Next update، Secure storage، Access list، Conflict check، Triage owner و Support information را ثبت کنید. Receipt صرفاً تحویل را تایید کند، نه Truth، Protection یا Outcome. Channel باید برای زبان/معلولیت قابل استفاده و Fallback داشته باشد.

ISO ۳۷۰۰۲ چه می‌دهد و چه نمی‌دهد؟

ISO 37002:2021 راهنمای سیستم مدیریت Whistleblowing بر پایهٔ Trust، Impartiality و Protection و چهار مرحلهٔ Receiving، Assessing، Addressing و Concluding است. این استاندارد عمومی به سازمان برای طراحی فرایند کمک می‌کند؛ متن عمومی ISO نشان می‌دهد Guideline است و وضعیت Protected disclosure یا انطباق قانونی یک Case را صادر نمی‌کند. استاندارد در سال ۲۰۲۶ در systematic review است؛ نسخه و وضعیت را ثبت کنید.

Triage حقیقت نهایی صادر نمی‌کند

Scope، Credibility، Harm، Urgency، Retaliation risk، Investigation/referral need و Interim protection را بسنجید. Credible یعنی ارزش بررسی دارد، نه اینکه Allegation اثبات شده است. Outside scope نیز باید Safe handoff یا اطلاعات Route بگیرد؛ Case را بدون اطلاع در Inbox رها نکنید.

Impartiality حقوق همهٔ طرف‌ها را حفظ می‌کند

Conflict، Independence، Recusal، Separation of duties، Reporter rights، Subject rights، Investigator safety و Oversight را ثبت کنید. حفاظت Reporter به معنی حکم پیشاپیش علیه فرد نام‌برده نیست؛ Presumption، Privacy و حق پاسخ باید با عدم Retaliation و Evidence integrity متوازن شوند.

Retaliation فقط اخراج نیست

تنزل، کاهش ساعت/دسترسی، تغییر Task، تهدید، ارزیابی منفی، انزوا، Blacklisting، دعوی، doxxing یا فشار غیرمستقیم ممکن است Signal باشند؛ تعریف قانونی حوزه متفاوت است. Baseline قبل از Report، Monitoring period، Signal route، Interim measure، Owner و Remedy را ثبت کنید. حتی Case unsubstantiated نیز Retaliation را خودکار مجاز نمی‌کند.

Monitoring نباید Surveillance تازه بسازد

برای حفاظت Reporter همهٔ رفتار کارکنان را زیر نظر نگیرید. Data minimization، Access، Retention و Purpose لازم است. Check-in رضایتی، HR event review محدود و Independent contact می‌تواند Signal بدهد؛ هر اقدام با Privacy/Employment review. Concern را به KPI مدیر یا امتیاز اخلاقی فرد تبدیل نکنید.

Investigation Mandate پیش از جمع‌آوری بیشتر

Mandate، Scope، Investigator، Method، Witness plan، Data access، Evidence log، Interview protocol، Finding standard و Limitations را تصویب کنید. Investigator نباید Reporter را به تهیهٔ اطلاعات خارج دسترسی تشویق کند. Legal privilege را خودکار فرض نکنید؛ Owner واجد صلاحیت تعیین کند.

Finding status چندحالته است

Substantiated، Partially substantiated، Not substantiated، Inconclusive و Outside scope را با Standard و Evidence تعریف کنید. Not substantiated به معنی False/malicious report نیست. False allegation عمدی ادعای جدا با Evidence و Process مستقل است. Correction باید Fact تازه را به همهٔ Recipientهای متاثر برساند.

Response فقط تنبیه فرد نیست

Corrective options، Systemic action، Policy/process/control، Owner، Due، Verification و Residual risk را ثبت کنید. Disciplinary action مسیر و محرمانگی خود را دارد. اگر Root issue رفع نشود، بسته‌شدن Case با اقدام نمایشی اعتماد را تخریب می‌کند. RCA را با تحلیل علت ریشه‌ای شواهدمحور انجام دهید، نه مقصرسازی.

Feedback باید هم مفید و هم محدود باشد

Status update، Outcome summary، Timeliness، Recipient و Delivery evidence را ثبت کنید؛ اما Investigation privacy، حقوق فرد نام‌برده، Legal limits و Security ممکن است جزئیات را محدود کند. «نمی‌توانیم چیزی بگوییم» اعتماد را می‌کاهد؛ «همهٔ پرونده را می‌فرستیم» نیز خطرناک است. Scope قابل گفتن را از ابتدا توضیح دهید.

External Route Registry باید جاری باشد

AuthorityID، Official remit، Contact، Filing deadline، Format، Language، Confidentiality info، Protection conditions، Receipt و Follow-up را با As-of نگه دارید. نام عمومی Regulator کافی نیست. فهرست جاری Prescribed persons بریتانیا نمونه‌ای است که Remitها حتی در ۲۰۲۶ تغییر کرده‌اند؛ از آن برای کشور دیگر استفاده نکنید.

Deadline از زمان کدام Event شروع می‌شود؟

Wrongdoing date، Discovery، Report، Retaliatory action یا Dismissal می‌تواند Clock متفاوتی بسازد. Deadline review را فوری و مستقل انجام دهید؛ از انتظار داخلی یا مذاکره نتیجه نگیرید Clock متوقف است. Calendar entry باید Source/Advisor داشته باشد، نه حدس وبلاگ.

Public Route Decision قابل کپی

PublicRouteDecision = {
  jurisdiction, instrument, conditionsReviewed,
  imminentOrManifestDanger, retaliationRisk,
  evidenceConcealmentRisk, priorRoutes,
  truthBeliefStandard, proportionality,
  dataAndThirdPartyHarm, redaction,
  advisor, authority, decision, rationale
}

این Contract مجوز انتشار نیست؛ نشان می‌دهد چرا تصمیمی با ریسک بالا نیازمند بررسی جداست. هیچ Secret، Exploit، PII یا فایل Case در نسخهٔ عمومی Fixture قرار نمی‌گیرد.

استعفا، سکوت و گزارش را اخلاقی رتبه‌بندی نکنید

امنیت شخصی، سلامت روان، خانواده، وضعیت اقامت/مالی، احتمال اثرگذاری و راه‌های حمایت متفاوت‌اند. کسی وظیفه ندارد خود را بی‌محافظ در معرض خطر بگذارد. تصمیم می‌تواند Pause for advice، Safe internal/external report، emergency route، transfer، leave یا گزینهٔ دیگری باشد. «اگر استعفا دهی وجدان نداری» فشار اخلاقی ناموجه است.

Support Plan بخشی از Quality است

Union/representative، Independent advice، Mental-health support، Financial planning، Safety planning، Accessibility و Language support را از Case merit جدا کنید. درخواست حمایت به معنی ضعف یا اثبات Allegation نیست. سازمان نیز Investigator و Witness را از فشار محافظت کند.

Close Case پایان Retaliation risk نیست

Closure criteria، ClosedAt، Residual action، Reporter feedback، Retaliation-monitoring end، Archive access، Retention end و Reopen trigger را ثبت کنید. UNODC هشدار می‌دهد Retaliation می‌تواند پس از اختتام و حتی در Case بدون اثبات Wrongdoing ادامه یابد. Closure نباید Identity و پرونده را در Archive بی‌حفاظ رها کند.

Correction هم از Reporter و هم از سازمان ممکن است

Fact اشتباه، Timestamp ناقص، Recipient غلط، Finding تغییرکرده یا گزارش عمومی نادرست باید CorrectionID، Affected recipients، Withdrawal، Replacement، Notification، Owner و Evidence داشته باشد. اصلاح داوطلبانه نباید خودکار به «بدخواهی» تعبیر شود؛ سازمان نیز باید Claim اشتباه علیه Reporter یا Subject را اصلاح کند.

آزمایش قطعی: هفت چراغ سبز خطرناک

یک Validator مستقل و بدون وابستگی با Node.js ۲۴.۱۸.۰ روی Fixture ساختگی اجرا شد. Checker سطحی فقط دید باگ جدی است، نیت منفعت عمومی ادعا شده، مدیر و CEO ایمیل شده‌اند، «همهٔ شواهد» کپی شده، برای پاسخ داخلی صبر شده، با Regulator تماس گرفته شده و نام وکیل آمده است؛ بنابراین به‌اشتباه گفت:

CONTROL_COUNT=265
SUPERFICIAL=PROTECTED_WHISTLEBLOWING_READY

ممیز قراردادی ۲۶۵ کنترل یکتا را در ۲۹ گروه بررسی کرد: Identity، Perspective، Concern، Boundary، Harm، Urgency، Jurisdiction، Eligibility، Channel، Route، Reporter safety، Confidentiality، Data، Evidence، Report، Intake، Triage، Impartiality، Retaliation، Investigation، Response، Feedback، External، Public، Legal، Support، Lifecycle، Correction و Limits. همهٔ کنترل‌ها غایب بودند:

AUDIT=HOLD-265
INDEPENDENT_SAFETY=real-confidential-material-copied:false:PASS

قاعدهٔ مستقل ۲۶۶ام تایید کرد هیچ مادهٔ محرمانهٔ واقعی کپی نشده است. پس از ثبت تمام فیلدها با دادهٔ کاملاً ساختگی، خروجی چنین شد:

CORRECTED=READY_FOR_PROTECTED_CONCERN_REVIEW-0
BOUNDARY=structure-only; no protected-disclosure status,
legal protection, truth, wrongdoing, safe route, confidentiality,
non-retaliation, investigation outcome, or moral duty proven

چرا صفر Finding هنوز Protection نیست؟

Validator حضور ساختار را می‌سنجد. Instrument، Worker status، Recipient، Evidence یا Advice ممکن است غلط باشد؛ Channel می‌تواند تغییر کرده باشد؛ و Tribunal/authority ممکن است نظر دیگری دهد. صفر Finding فقط Case را برای بازبینی امن/حقوقی/موضوعی آماده می‌کند.

آزمایشگاه فارسی کاملاً آفلاین

یک سناریوی Tabletop ساختگی دربارهٔ Checkout خیالی بسازید: Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification فقط محلی‌اند. یک Release gate ساختگی بدون Rationale تغییر کرده و Concern فرضی ایجاد می‌شود. هیچ شرکت، مدیر، کارمند، مشتری، تخلف، پرداخت، PSP، بانک یا نهاد واقعی وجود ندارد.

Case/Concern/Report/Evidence/Recipient/Decision شناسهٔ پایدار ساختگی دارند. IRR تخیلی و تومان فقط نمایش برچسب‌خورده است؛ ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، UTC/Asia-Tehran و تاریخ جلالی نمایشی آزمایش می‌شوند. هیچ نام، کدملی، موبایل، ایمیل، IP، صدا، پیام، قرارداد، Source code، Secret، Credential، Token، Log یا Screenshot واقعی وارد Lab نمی‌شود.

LabBoundary = {
  network: false,
  production: false,
  realPersonOrOrganization: false,
  realWrongdoingOrConfidentialData: false,
  legalAdviceOrProtectedStatus: false,
  purpose: "validate Protected Concern record structure only"
}

تمرین Route بدون اقدام واقعی

1. Observation و Allegation ساختگی را جدا کنید.
2. سه حوزهٔ کاملاً خیالی با Eligibility/Deadline متفاوت بسازید.
3. Internal، external و pause-for-advice را بدون Recipient واقعی مقایسه کنید.
4. Evidence overcollection را با Do-not-acquire rule متوقف کنید.
5. Conflict/Retaliation/Confidentiality tabletop اجرا کنید.
6. Case را با Inconclusive finding و Systemic action ببندید.
7. یک Correction و Reopen trigger ساختگی اجرا کنید.

Anti-patternهایی که باید رد شوند

• «هر باگ حیاتی Whistleblowing است»؛
• «اول باید همهٔ مراحل داخلی را تمام کرد»؛
• «رسانه همیشه آخرین مرحله است»؛
• «به CEO مهلت بده»؛
• «هرچه داری کپی کن»؛
• «مکالمه را برای مدرک ضبط کن»؛
• «نیت خالص Protection می‌آورد»؛
• «مدرک باید غیرقابل‌انکار باشد»؛
• «Regulator را از نوع نرم‌افزار حدس بزن»؛
• «NDA همیشه مانع است» یا «NDA هرگز مهم نیست»؛
• «Anonymous یعنی محرمانگی تضمینی»؛
• «Confidential یعنی هویت هرگز فاش نمی‌شود»؛
• «Report بی‌اساس یعنی Reporter بدخواه است»؛
• «عدم اثبات، Retaliation را مجاز می‌کند»؛
• «Case بسته شد، خطر تمام است»؛
• «حمایت قانونی شغل را تضمین می‌کند»؛
• «استعفا سکوت غیراخلاقی است»؛
• «QA می‌تواند Protected status بدهد»؛
• «Deadline با مذاکره متوقف می‌شود»؛
• «این راهنما برای پرونده واقعی کافی است».

چک‌لیست Reporter-side پیش از اقدام

• Fact/Interpretation/Allegation/Unknown جدا شده‌اند.
• Emergency/Incident route در صورت فوریت شناخته شده است.
• کشور، Worker status، Sector و As-of ثبت شده‌اند.
• Deadline فوری با Source/Advisor بررسی شده است.
• Eligibility و Protection قطعی فرض نشده‌اند.
• گزینه‌های Route و Remit Recipient تایید شده‌اند.
• Conflict، Retaliation و Evidence-destruction risk سنجیده شده‌اند.
• Device/Contact/Identity/Wellbeing plan بررسی شده است.
• Confidentiality limits روشن‌اند.
• هیچ داده/Secret خارج دسترسی مجاز جمع نشده است.
• Recording بدون advice انجام نشده است.
• Evidence حداقلی و Third-party harm بررسی شده است.
• Independent qualified advice در دسترس است.
• هیچ فشار اخلاقی برای Self-sacrifice پذیرفته نشده است.

چک‌لیست Organization-side برای Case

• Channel رسمی، معتبر، دسترس‌پذیر و چندزبانه است.
• Ack/Case reference/Next update بدون وعدهٔ Truth/Protection صادر می‌شود.
• Secure storage/Access/Conflict/Recusal فعال‌اند.
• Triage، Investigation و Retaliation monitoring جدا هستند.
• Interim protection و Support بدون شرط اثبات فراهم‌اند.
• Reporter/Subject/Investigator rights حفظ می‌شوند.
• Investigation mandate/method/standard/limitations ثبت‌اند.
• Finding status چندحالته و Correction‌پذیر است.
• Systemic response/owner/due/verification وجود دارد.
• Feedback با Privacy/Legal limits متوازن است.
• External registry/deadline/remit به‌روز است.
• Closure/retention/reopen/retaliation-after-close تعریف شده‌اند.
• Case برای KPI یا امتیاز افراد استفاده نمی‌شود.
• ISO ۳۷۰۰۲ به‌عنوان Guidance، نه Protection certificate استفاده می‌شود.

Pilot سی‌روزهٔ سیستم Speak-up

هفتهٔ اول: Channel/Remit/Access/Conflict/Deadline registry را با مشاور بررسی کنید. هفتهٔ دوم: Intake/Triage/Protection/Investigation roles و Case schema را روی دادهٔ ساختگی تمرین کنید. هفتهٔ سوم: Tabletop فوریت، Retaliation، Evidence overcollection، anonymous follow-up و external handoff اجرا کنید. هفتهٔ چهارم: Inconclusive closure، systemic action، Feedback، retention، Reopen و Correction drill را کامل کنید.

شاخص Pilot: زمان Ack، Channel availability، Conflict recusal، Access exception، Interim-protection time، Update missed، Closure without feedback، Retaliation signal و Correction time. تعداد Report کم یا زیاد به‌تنهایی سلامت فرهنگ را نشان نمی‌دهد و نباید هدف تنبیهی باشد.

منابع چگونه استفاده شده‌اند؟

ISO ۳۷۰۰۲ فقط برای اصول عمومی Trust/Impartiality/Protection و چرخهٔ Receive-Assess-Address-Conclude؛ Directive اتحادیهٔ اروپا، GOV.UK و OSHA فقط برای نشان‌دادن تفاوت واقعی Scope/Channel/Condition/Deadline؛ و راهنمای UNODC دربارهٔ حفاظت Reporting persons برای Confidentiality/Case protection استفاده شده‌اند. هیچ‌کدام به ایران یا پروندهٔ دیگر منتقل نشده و Framework این مقاله اقتباس عملی نویسنده است.

جمع‌بندی

Concern امن با شجاعت‌نمایی مدیریت نمی‌شود؛ با Boundary، Advice، Route، Minimization و Protection مدیریت می‌شود. Reporter لازم نیست خود را قربانی یا Investigator کند؛ سازمان نیز نباید Receipt را حکم Truth یا بی‌اساس‌بودن بداند. Case خوب Fact را حفظ، افراد را محافظت، تعارض را مدیریت، Wrongdoing را بی‌طرف بررسی، اقدام را Verify و Correction را ممکن می‌کند.

سوالات متداول

آیا قبل از گزارش بیرونی باید همهٔ کانال‌های داخلی را طی کنم؟

نه به‌عنوان قاعدهٔ جهانی. قانون/سیاست، Subject، Urgency، Retaliation، Conflict، خطر حذف Evidence و Recipient remit مهم‌اند. بعضی چارچوب‌ها گزارش مستقیم بیرونی را در شرایطی می‌پذیرند و بعضی شروط دیگری دارند. پیش از اقدام از مشاور واجد صلاحیت در حوزهٔ مربوط کمک بگیرید.

آیا باید ایمیل‌ها، لاگ‌ها و فایل‌ها را برای مدرک کپی کنم؟

«همه‌چیز را کپی کن» توصیهٔ امنی نیست. اطلاعات ممکن است شخصی، محرمانه، دارای Secret/Privilege/Trade secret یا متعلق به دیگران باشد. Evidence را خارج از دسترسی مجاز جمع یا منتقل نکنید؛ دربارهٔ Preservation و حداقل اطلاعات لازم از Advisor/authority صلاحیت‌دار راهنمایی بگیرید.

آیا Anonymous report هویت و حمایت من را تضمین می‌کند؟

خیر. Metadata یا Factها ممکن است هویت را آشکار کنند؛ Anonymous بودن Follow-up و برخی Protectionها را نیز متاثر می‌کند. Confidential/pseudonymous گزینه‌های متفاوتی‌اند. Channel و قانون جاری را بررسی و یک Safety/Contact plan مشروع طراحی کنید.

آیا قانون حتماً از من در برابر اخراج یا Retaliation محافظت می‌کند؟

هیچ تضمین عمومی وجود ندارد. Protection به حوزه، وضعیت شخص، موضوع، باور معقول، Channel، زمان و شرایط دیگر وابسته است؛ Retaliation عملی نیز ممکن است رخ دهد و Deadline شکایت کوتاه باشد. Advice مستقل و فوری بگیرید و Support/Safety plan داشته باشید.

اگر Concern من اثبات نشد، آیا گزارش‌دادن اشتباه بوده است؟

Not substantiated با گزارش عمدی دروغ یکسان نیست. بسیاری از چارچوب‌ها به Reasonable belief و شرایط زمان Report توجه دارند. سازمان باید Outcome چندحالته، حقوق طرفین و عدم Retaliation را حفظ کند؛ Reporter نیز Fact تازه یا خطا را از مسیر Correction اعلام کند.