یک تیم QA تست نفوذ را به فروشنده میسپارد، SLA امضا میکند و بیمه هم میخرد. آیا ریسک امنیتی «منتقل» شده است؟ نه لزوماً. شاید فقط فعالیت تست بیرونی شده باشد؛ Exposure عملیاتی، تعهد به مشتری، وظیفهٔ قانونی، اختلال سرویس، Damage بالاتر از سقف قرارداد، Exclusion بیمه، قصور پیمانکار فرعی و هزینهٔ بازیابی همچنان نزد سازمان بماند. انتقال ریسک در تضمین کیفیت خرید Vendor یا سند SLA نیست؛ تخصیص محدود و آزمونپذیرِ پیامد یا تعهد در یک قرارداد، همراه با ثبت ریسک باقیمانده است.
این راهنما QA Risk Transfer Contract & Residual Risk Ledger میسازد: Risk statement و Exposure را قفل میکند، Transfer mechanism و Counterparty را بررسی میکند، Covered/Excluded event و Remedy/Limit را روشن میسازد، Control/Assurance و Claimability را میآزماید، ریسک تازهٔ تأمینکننده و Concentration را اضافه میکند و در پایان، Residual exposure را به صاحب اختیار بازمیگرداند. این متن آموزش مهندسی Risk/Evidence است، نه مشاورهٔ حقوقی، مالی، بیمهای، بانکی یا قراردادی.
پاسخ کوتاه: انتقال ریسک در QA چیست؟
انتقال ریسک یک تصمیم محدود است که طبق آن، Counterparty در برابر Trigger مشخص، بخشی از پیامد مالی، تعهد انجام کار، Remedy یا Recovery service را در Scope، Term، Limit و شرطهای تعریفشده میپذیرد. خود Event ممکن است همچنان رخ دهد؛ سازمان ممکن است Accountability، وظایف قانونی/اخلاقی، اثر شهرت، عملیات، مازاد سقف، Deductible، Exclusion و ریسک ورشکستگی/عدم اجرای طرف مقابل را نگه دارد. بنابراین عبارت درست معمولاً «Exposure X طبق قرارداد Y تا Limit Z تخصیص یافت؛ Residual R نزد Owner O ماند» است، نه «ریسک کاملاً منتقل شد».
- Risk و Exposure فعلی را بدون Vendor نام ببرید.
- پاسخهای Avoid/Reduce/Share/Transfer/Accept را مقایسه کنید.
- وظایف قابل تخصیص و غیرقابلانتقال را جدا کنید.
- Mechanism، Counterparty، Trigger، Coverage، Exclusion و Limit را قفل کنید.
- Control و Evidence مستقل برای عملکرد طرف مقابل طراحی کنید.
- Incident، Claim، Remedy، Recovery، Exit و Failure طرف مقابل را تمرین کنید.
- Residual risk را با Owner، Authority و Expiry بپذیرید یا دوباره درمان کنید.
- تغییر Contract/Evidence/Claim را با Correction و Audit trail نگه دارید.
مرز مالکیت: Transfer با Outsourcing و Acceptance یکی نیست
| موضوع | پرسش اصلی | خروجی | مالک محتوایی |
|---|---|---|---|
| Risk Transfer | کدام Exposure/Obligation با چه Limit تخصیص مییابد؟ | Transfer Contract + Residual Ledger | همین مقاله |
| Freelance/Crowdtesting | چگونه Capacity/Work package بیرونی بخریم؟ | قرارداد کار، دسترسی، پذیرش، پرداخت و Exit | فریلنسر QA و Crowdtesting |
| QA Operating Model | قابلیت QA کجا و چگونه جریان یابد؟ | Centralized/Embedded/Federated service contract | مدل عملیاتی QA |
| Residual-risk release | آیا شواهد و ریسک باقیمانده برای تصمیم کافیاند؟ | Adequacy memo و Release decision | کیفیت بهاندازه کافی خوب |
| Security collaboration | Threat/Control/Finding چگونه به Evidence و Gate برسد؟ | Security Claim و Exception | همکاری QA و AppSec |
Outsourcing انتقال اجرای Activity یا تأمین Capacity است؛ ممکن است هیچ پیامد مالی یا Accountability منتقل نشود. Acceptance تصمیم آگاهانهٔ نگهداشتن Risk است. Insurance ممکن است بخشی از Loss را مطابق Policy جبران کند. Contractual indemnity ممکن است حق مطالبه بسازد، اما Collectability و Remedy timing هنوز جدا هستند.
منابع رسمی چه میگویند و چه چیزی را تضمین نمیکنند؟
NIST SP 800-161 Rev.1 Update 1 مدیریت ریسک زنجیرهٔ تأمین سایبری را در سطح سازمان و چرخهٔ محصولات/خدمات بررسی میکند و بر Strategy، Policy، Plan و Assessment تأکید دارد. Quick Start Guide رسمی C-SCRM برای CSF ۲.۰ نیز Supplier requirement و همکاری سازمانی را برجسته میکند. این منابع برای C-SCRM هستند؛ نه متن قرارداد ایرانی، بیمهنامه یا تعریف عمومی همهٔ انتقالهای QA.
اصل A4 زنجیرهٔ تأمین NCSC صریح میگوید سازمانی که برای Essential function به شخص ثالث متکی است، همچنان برای حفاظت آن پاسخگو میماند. این اصل مربوط به Cyber Assessment Framework بریتانیا است و الزام حقوقی عمومی برای ایران ساخته نمیشود؛ اما یک Guardrail مهم علیه «Outsource شد، پس مسئولیتی نداریم» است.
راهنمای Cyber insurance NCSC میگوید بیمه میتواند حمایت مالی/خدماتی ایجاد کند اما همهٔ مسئلههای امنیتی را فوراً حل یا از Breach پیشگیری نمیکند؛ Coverage، Exclusion، خدمات Incident و شرط Claim/Renewal باید فهمیده شوند. این منبع راهنمای خرید جامع یا مشاورهٔ بیمهای نیست و Policy واقعی فقط با متن قرارداد و متخصص مجاز تفسیر میشود.
قرارداد مرکزی انتقال ریسک QA
transfer_id: QART-CHECKOUT-01 version/status/supersedes: 1.0.0 / PILOT / null effective_from/review_at: 2026-08-17 / 2026-09-16 organization/service/asset: ORG-SYN / SYN-CHECKOUT / CALLBACK-SERVICE objective: preserve fictional checkout continuity risk_id/statement: RISK-SYN-21 / cause→event→consequence inherent_exposure: EXPOSURE-SYN-v3 risk_owner/decision_owner/authority: RISK-OWNER / DEC-OWNER / MANDATE-v2 legal/finance_review: REQUIRED-BY-LOCAL-POLICY duty_map: contractual / operational / legal / ethical / non-transferable mechanism/counterparty: MANAGED-TEST-SERVICE / SUPPLIER-SYN-A allocated/retained/non_transferable: versioned obligations covered/excluded/limit/deductible/waiting/territory/term: contract references trigger/notice/claim_evidence/process/remedy: claim contract controls/assurance/access/data/incident: supplier control plan continuity/recovery/exit/rehearsal/return-delete: lifecycle plan supplier_failure/concentration/dependency/monitoring: third-party risk register residual_exposure/owner/acceptance/expiry: residual ledger people_scoring: false correction/audit/privacy/not_claimed: required
این Record نمونه، قرارداد حقوقی نیست. نام فیلدها برای وادارکردن تصمیم به شفافیت طراحی شدهاند. متن الزامآور، قانون حاکم، قابلیت اجرا، مالیات، تحریم، صلاحیت Counterparty و بیمه نیازمند بررسی متخصص ذیصلاح در همان Jurisdiction هستند.
هویت، نسخه و Term را تثبیت کنید
`transfer_id`، Version، Status، Supersedes، Effective date، Term و Review date باید به Risk/Contract/Evidence مشخص وصل باشند. «قرارداد فعلی Vendor» یا «بیمه داریم» قابل ممیزی نیست. Renewal ممکن است Coverage، Exclusion یا Premium/limit را عوض کند؛ Evidence نسخهٔ قبلی نباید به Policy جدید نسبت داده شود.
Risk را با Cause–Event–Consequence بنویسید
«ریسک امنیت» یا «Vendor ضعیف» برای انتقال کافی نیست. قالب: به علت `Cause` ممکن است `Event` رخ دهد و بر `Objective/Asset/Affected party` پیامد `Consequence` بگذارد. برای مثال مصنوعی: «بهعلت پوشش ناکافی Stateهای Callback، ممکن است Finding مهم دیده نشود و تصمیم Rollout بر Evidence ناقص تکیه کند». Transfer mechanism باید دقیقاً به بخشی از این زنجیره وصل شود.
Inherent Exposure را پیش از قرارداد ثبت کنید
Exposure فقط Expected monetary loss نیست. Operational disruption، Customer harm، Data impact، Recovery effort، legal/regulatory consequence، Reputation و Opportunity cost ممکناند. Likelihood/impact را اگر داده ندارید Range/Scenario/Unknown گزارش کنید. رقم ساختگی دقیق، ریسک را علمی نمیکند. Baseline برای مقایسه Optionها لازم است.
چهار چیز را جدا کنید: Activity، Obligation، Liability و Accountability
| مفهوم | نمونه | با واگذاری چه میشود؟ |
|---|---|---|
| Activity | اجرای تست نفوذ یا Device campaign | قابل برونسپاری است |
| Obligation | تحویل Report تا Deadline | میتواند قراردادی تخصیص یابد |
| Liability/Remedy | Service credit یا Indemnity محدود | طبق متن، Limit و قابلیت اجرا |
| Accountability | حفاظت از خدمت/تصمیم سازمان | ممکن است نزد سازمان بماند |
جملهٔ «مسئولیت را منتقل کردیم» این چهار لایه را مخلوط میکند. Contract باید بگوید Counterparty چه کاری و چه Remedyای دارد و Organization چه تصمیم/وظیفهای را نگه میدارد.
Duty Map؛ برخی وظایف قابل واگذاری نیستند
Duty map دستههای قراردادی، عملیاتی، امنیتی، حریم، قانونی، اخلاقی و Fiduciary را با Owner/Authority نگه میدارد. اینکه چه چیزی قانوناً قابل انتقال است به Jurisdiction و متن واقعی بستگی دارد؛ مقاله حکم عمومی نمیدهد. حتی اگر Vendor کار را انجام دهد، Client ممکن است وظیفهٔ Due diligence، نظارت، Notification، پاسخ به مشتری یا حفاظت از Essential function را نگه دارد.
گزینههای Risk response را پیش از Transfer مقایسه کنید
Avoid، Reduce، Share/Transfer و Accept میتوانند ترکیب شوند. ممکن است ساخت Control داخلی + خرید Incident support + بیمهٔ محدود بهتر از انتقال ادعایی کامل باشد. Optionها را با Exposure before/after، Cost range، Control، Time، Reversibility، Dependency، Residual، legal feasibility و Opportunity cost مقایسه کنید. «خارج از Core competency» بهتنهایی دلیل Transfer نیست.
Transfer Mechanism را دقیق نام ببرید
| Mechanism | چه چیزی ممکن است بدهد؟ | چه چیزی را خودکار نمیدهد؟ |
|---|---|---|
| Managed service | تعهد انجام Service/Deliverable | انتقال همهٔ Consequenceها |
| Fixed-price | قیمت برای Scope/assumption تعریفشده | انتقال Scope change، delay یا quality risk |
| SLA/Service credit | Target و Remedy محدود | جبران کامل Loss یا پیشگیری Failure |
| Warranty | Repair/replace تحت شرط و Term | پوشش همهٔ Defectها و harms |
| Indemnity | تخصیص برخی Claims/Losses | Collectability یا نبود Cap/Exclusion |
| Insurance | Coverage/response service طبق Policy | پیشگیری Incident یا پوشش همه زیانها |
Counterparty Due Diligence باید Evidence داشته باشد
نام برند، Badge و Reference marketing کافی نیست. Ownership، Financial resilience، Capability، Personnel vetting، Security baseline، Incident history در حدود مجاز، Jurisdiction، Subcontractor، Insurance certificate، Conflict، Capacity، Exit cooperation و Evidence قابل راستیآزمایی را بررسی کنید. Due diligence Snapshot است و تضمین آینده نیست؛ Cadence و Trigger بازبینی لازم است.
Scope طرف مقابل را به Claim قابل آزمون تبدیل کنید
work_scope_id: WS-SYN-18 subject/build: CALLBACK-SERVICE / BUILD-SYN-23 question: identify defined weakness classes in synthetic callback boundary included: [API contract, authz scenarios, replay/idempotency states] excluded: [production exploitation, real card data, legal compliance opinion] population/sample: SCOPE-MODEL-SYN-v2 / SAMPLE-SYN-14 environment/data: ENV-SYN-5 / DATASET-SYN-11 method/limits: METHOD-SYN-v3 / LIMITS-SYN-v2 deliverables: [finding records, coverage statement, evidence manifest] acceptance: artifact completeness and reproducibility checks not_promised: all vulnerabilities found, compliance certification, release safety
«همهٔ آسیبپذیریهای حیاتی را پیدا کنید» معمولاً Oracle و Population کامل ندارد و False negative را حذف نمیکند. Scope باید Test object، Boundary، Method، Coverage claim، Exclusion و Limitation را بگوید. برای Security Claim و ابزارهای مکمل، راهنمای QA–AppSec مناسبتر است.
Allocated و Retained Obligation را کنار هم بنویسید
Allocated: Vendor روش مصوب را اجرا، Attempt/Evidence را حفظ، Finding را در Window تحویل و Incident دسترسی را اعلام کند. Retained: Organization Scope/Oracle را Approve، دسترسی را کنترل، Finding را Triage، Fix/Release را تصمیم و Production را Monitor کند. اگر Retained column خالی باشد، Ownerless gap محتمل است.
Covered Event و Excluded Event را با مثال بازبینی کنید
Coverage باید Event، Cause، Subject، Time، Territory، affected party و Loss type را تعریف کند. Exclusion میتواند pre-existing condition، unsupported system، late notice، unapproved change، specific data، war/state action یا failure to maintain controls باشد—بسته به متن واقعی. هیچ فهرست عمومی را به Policy خود تعمیم ندهید؛ Scenario walkthrough با متخصص لازم است.
Limit، Deductible و Waiting period را مدل کنید
Limit ممکن است per-event، aggregate یا Sublimit باشد؛ Deductible/Retention بخشی را نزد سازمان میگذارد؛ Waiting period Loss پیش از زمان مشخص را حذف میکند. Currency، Tax، Legal cost، Defense cost، Inflation و Exhaustion را در سناریوی واقعی با Finance/Legal بررسی کنید. Service credit معمولاً معادل خسارت واقعی نیست.
Trigger را Observable و اختلافپذیر کنید
Trigger «کیفیت پایین» نیست. میتواند Miss یک SLO مشخص، Failure یک Deliverable، Incident تعریفشده یا Claim covered باشد. Event time، Detection time، Notification window، Authority و Evidence minimum را تعیین کنید. اگر Trigger فقط توسط طرف مقابل قابل مشاهده است، حق Audit و Telemetry/record access اهمیت پیدا میکند.
SLA انتقال ریسک را تضمین نمیکند
SLA یک سطح خدمت و گاهی Remedy را تعریف میکند. Availability ۹۹.۹% بدون Measurement point، exclusions، calendar، maintenance، aggregation، source، dispute و credit formula مبهم است. رسیدن به SLA، کیفیت کل یا نبود Risk را ثابت نمیکند؛ Miss هم لزوماً Cause خسارت نیست. SLA باید با SLO داخلی، RTO/RPO، Incident و Business consequence پیوند داشته باشد.
Evidence Claim باید قبل از Incident آماده باشد
claim_packet_id: CLAIM-SYN-6 transfer/contract: QART-CHECKOUT-01 / CONTRACT-SYN-v2 covered_event_candidate: EVENT-SYN-44 event/detected/notified: UTC timestamps subject/service/build: CALLBACK-SERVICE / SYN-CHECKOUT / BUILD-SYN-23 evidence_manifest: MANIFEST-SYN-15 loss_or_remedy_basis: BASIS-SYN-v4 control_state: CONTROL-SNAPSHOT-SYN-8 notification_proof: NOTICE-SYN-3 unknowns/disputes: [causation not established, exclusion review pending] claim_owner/legal_finance_review: CLAIM-OWNER / required status: CANDIDATE_NOT_ACCEPTED
Claim candidate با Claim accepted یا Payment یکی نیست. Chain of custody، Retention، Notice، Mitigation duty و Cooperation شرط ممکناند. Evidence ناقص در روز Incident با Attachment بیشتر ناگهان معتبر نمیشود؛ از قبل Rehearsal کنید.
Remedy را از Recovery جدا کنید
Service credit، Refund، Re-performance، Repair، Indemnification یا Insurance payout Remedy قراردادیاند. Recovery یعنی بازگرداندن Service/Data/Operation. پرداخت پول سیستم را بالا نمیآورد و Recovery فنی Loss را جبران نمیکند. Owner، RTO/RPO، alternate path، communication، data reconciliation و post-incident action باید حتی با Transfer وجود داشته باشند.
Liability Cap و Indemnity Boundary را سناریو کنید
Cap ممکن است از Exposure واقعی کمتر باشد؛ carve-out، indirect/consequential loss، defense/control of claim و aggregate limits معنای تخصصی دارند. این مقاله آنها را تفسیر نمیکند. تیم QA فقط میتواند Scenario، Evidence و Gap را برای Legal/Finance فراهم کند. عبارت «Vendor همهٔ جریمهها را میدهد» بدون متن قابل اجرا و Authority ممنوع است.
Subcontractor و Flow-down را فراموش نکنید
Counterparty ممکن است Cloud، Crowd، آزمایشگاه یا فرد دیگری بهکار گیرد. فهرست/اطلاع تغییر، Approval، Location، Access، Data handling، Control، Incident notice، Audit و Exit باید تا Sub-tier مناسب Flow-down شود. قرارداد اصلی بدون امکان دیدن زنجیره، Concentration و fourth-party risk را پنهان میکند.
Control Requirements را از Certification جدا کنید
Certificate میتواند Evidence محدودی در Scope/Period خود باشد، نه تضمین Control امروز. Control requirement باید Actor، Asset، Behavior، Frequency، Evidence، Failure response و Owner داشته باشد: MFA، least privilege، isolated environment، secret handling، logging، vulnerability disclosure، patching و backup بسته به Risk. Applicability را Contextual کنید.
Assurance Method را مستقل و Risk-based کنید
Self-attestation، document review، sample evidence، independent report، technical test، tabletop و onsite assessment قدرت و هزینه متفاوت دارند. استقلال مطلق نیست؛ Conflict/Scope/Method/Period را ثبت کنید. Assurance هرگز Future performance یا absence of issue را تضمین نمیکند. Cadence با Criticality، Change، Incident و Expiry تنظیم شود.
دسترسی و داده را کمینه، زماندار و قابل برگشت کنید
NDA بهتنهایی داده واقعی را امن نمیکند. Resource-centric access، named identity، MFA، expiry، approval، logging، environment isolation، synthetic/masked data، download restriction، retention و verified deletion را طراحی کنید. Emergency access و offboarding را تست کنید. Data residency/transfer و قانون محلی با متخصص بررسی شود.
Incident Route مشترک بسازید
Severity taxonomy، detection/report channel، ۲۴×۷ contact در صورت نیاز، Ack، containment authority، evidence preservation، notification، regulator/customer route، communication approval و post-incident review را مشخص کنید. External expert مشاور است؛ تصمیم کلیدی و Accountability سازمانی خودکار منتقل نمیشود. تماس فقط در ایمیل یک فرد Single point of failure است.
Continuity و Recovery را با Supplier تمرین کنید
سناریوهای outage، breach، loss of access، corrupted deliverable، unavailable specialist، sanctions/payment disruption و supplier insolvency را تمرین کنید. RTO/RPO، alternate supplier/manual fallback، data restore، decision authority و communication را آزمایش کنید. وجود DR document شواهد Recovery نیست؛ Rehearsal timestamp و Finding لازم است.
Exit Plan را روز خرید بنویسید
Termination trigger، notice، transition assistance، artifact format، data export، credential revoke، knowledge return، data deletion proof، open Finding handoff، tool/license dependency، escrow در صورت نیاز و final reconciliation را تعریف کنید. برای خرید ابزار و Exit عملی، راهنمای انتخاب ابزار مدیریت تست با TCO و Exit مرز تخصصیتری دارد.
Exit Rehearsal قفلشدن را زود آشکار میکند
یک Export کوچک را Import و reconcile کنید؛ Runbook را بدون فرد کلیدی اجرا کنید؛ جایگزین credential و DNS/endpoint را در محیط مصنوعی تمرین کنید؛ زمان و Gap را بسنجید. فایل CSV خروجی به معنی Exit کامل نیست؛ روابط، تاریخچه، Evidence، Permission، ID mapping و Audit باید قابل استفاده بمانند.
ریسک Counterparty را به Register اضافه کنید
Transfer ریسک تازه میسازد: performance failure، moral hazard، opacity، data exposure، financial distress، capacity conflict، key-person loss، subcontractor drift، geopolitical/access/payment issue و dispute. این ریسکها را با Cause–Event–Consequence و Owner مستقل ثبت کنید؛ مزیت Contract آنها را صفر نمیکند.
Concentration و Correlated failure را بسنجید
چند Vendor ممکن است پشت صحنه به همان Cloud، Payment rail، Data center، library یا متخصص وابسته باشند. Diversification ظاهری Correlation را پنهان میکند. Dependency graph، critical path، geographic/legal concentration و common-mode scenario بسازید. تعداد تأمینکننده بهتنهایی Resilience نیست.
Monitoring را به Evidence و Breach rule وصل کنید
| Signal | Evidence | Trigger | Countermetric |
|---|---|---|---|
| Deliverable timeliness | signed timestamps | contract window miss | quality/rework of output |
| Control freshness | current control snapshot | expiry/change | assurance burden |
| Finding reproducibility | sample witness rerun | acceptance failure | sample bias |
| Exit readiness | rehearsal result | critical gap | cost/disruption of rehearsal |
| Concentration | dependency map | threshold/unknown | map freshness |
Monitoring Vendor نباید به Surveillance افراد یا Scorecard کارکنان تبدیل شود. Data quality، denominator، calendar و dispute process را تعریف کنید. Goodhart risk را با Countermetric و sample review کاهش دهید.
Breach، Escalation و Cure را از قبل تعریف کنید
Breach candidate باید Contract version، clause/control، Observation، Evidence، materiality rule و disputed status داشته باشد. مسیر Ack، Cure period، temporary containment، escalation، remedy، termination و appeal را ثبت کنید. هر Miss کوچک Termination نیست؛ هر Miss مکرر هم نباید با Service credit عادیسازی شود.
Residual Exposure را دوباره محاسبه کنید
Residual شامل Excluded event، Cap excess، Deductible، waiting period، nonfinancial harm، non-transferable duty، counterparty default، claim delay/dispute، Control failure و Unknown است. جمع سادهٔ Likelihood×Impact لزوماً معتبر نیست؛ Scenario/Range و dependency را حفظ کنید. Transfer ممکن است Exposure را جابجا یا حتی از مسیر پیچیدگی بیشتر کند.
residual_id: RES-SYN-9 transfer: QART-CHECKOUT-01@1.0.0 inherent_exposure: EXPOSURE-SYN-v3 allocated: defined re-performance + capped fictional service credit retained: operation, customer response, decision, excess, exclusions new_risks: supplier outage, data access, claim dispute, concentration unknowns: enforceability and real loss distribution not assessed controls: internal review, monitoring, fallback, exit rehearsal residual_owner/authority: RISK-OWNER / ACCEPTANCE-MANDATE-v2 decision: REVIEW_NOT_ACCEPTED expires_at: 2026-09-16T00:00:00Z not_claimed: risk eliminated, legal enforceability, financial adequacy
Residual Risk Acceptance باید نامدار و منقضی باشد
Risk owner اطلاعات را نگه میدارد؛ Acceptance authority باید Mandate متناسب با Consequence داشته باشد. تصمیم شامل Evidence، Unknown، Alternatives، Conditions، Review trigger و Expiry است. QA میتواند Evidence و Gap ارائه کند، اما لزوماً مجاز به پذیرش Risk کسبوکار، امنیت، حریم یا قانون نیست. Acceptance بینام، انتقال به آینده است.
Cost Model را فراتر از Fee ببینید
Premium/Fee، Deductible، retained loss، integration، due diligence، contract management، audit، rework، data preparation، access/security، incident coordination، dispute، currency/payment، switching، exit و opportunity cost را Rangeدار بسنجید. Fixed-price ممکن است Change request یا کیفیت حداقلی را تحریک کند؛ مدل Incentive و Countercontrol لازم است.
Insurance را Control جایگزین نکنید
Insurance ممکن است Loss و Incident service مشخصی را پوشش دهد، اما Breach را جلوگیری نمیکند. Existing controls، declarations، exclusions، sublimits، retroactive date، business interruption basis، panel providers، consent before costs، notice و renewal conditions را با Broker/Legal بررسی کنید. Policy summary یا Certificate متن کامل Coverage نیست.
Fixed-price ریسک هزینه را کامل منتقل نمیکند
قیمت فقط برای Scope، Assumption، acceptance، schedule و change rule تعریفشده ثابت است. Client ممکن است Risk ابهام نیاز، Delay دسترسی، rework، quality escape، dispute، FX/payment و opportunity cost را نگه دارد. Vendor نیز Contingency را در قیمت میگذارد یا Incentive کمینهسازی Effort میگیرد. Scenario change را پیش از امضا آزمایش کنید.
Pen test یا Audit مستقل انتقال Risk نیست
Third-party assessment میتواند Assurance و Finding مستقل بدهد. مگر Contract پیامد/Remedy خاصی تخصیص دهد، اجرای تست صرفاً Activity است. حتی با Indemnity، Organization باید Scope، fix، monitoring، incident response و decision را مدیریت کند. Report «هیچ Finding بحرانی» نبودِ Vulnerability را ثابت نمیکند.
Compliance یا Certification را Outsource نکنید
متخصص بیرونی میتواند Gap assessment یا Audit در Scope انجام دهد؛ اینکه سازمان Compliant است، چه Authorityای آن را تأیید میکند و کدام Duty باقی میماند به Scheme/Jurisdiction وابسته است. SLA نمیتواند کشف تمام نقصها یا حذف جریمه را تضمین کند. برای ایران و خدمات فرامرزی، تحریم/قانون/صلاحیت باید مستقل بررسی شود.
AI و Automation در ممیزی Contract محدودند
ابزار میتواند Clause mapping، Expiry reminder، evidence completeness یا Scenario candidate بسازد. مدل زبانی ممکن است قانون/Clause اختراع، Exclusion را جا بیندازد یا متن را بهغلط تفسیر کند. Secret و قرارداد حساس نباید بدون مجوز وارد سرویس شود. خروجی AI Draft است؛ Legal/Finance/Risk owner و Counterparty record Authority هستند.
Correction و Supersession را در کل زنجیره اعمال کنید
اگر Risk statement، Policy term، Exclusion، Evidence، Claim status یا Residual decision اشتباه بود، Correction باید affected Contract/Report/Dashboard/Decision/Notification را فهرست کند. Renewal نسخهٔ تازه است؛ ویرایش بیردپای PDF یا Risk register تاریخ را عوض نمیکند. Claim پرداختشده هم ممکن است بعداً Adjustment یا dispute داشته باشد.
آزمایش تکرارپذیر: Vendor + SLA + بیمه یعنی انتقال کامل؟
Fixture مصنوعی `SYN-QA-RISK-TRANSFER-CONTRACT-۰۱` میگوید Vendor استخدام شده، SLA و Fixed-price امضا شده، Insurance policy وجود دارد و Pen test PASS است. Gate سطحی فقط سه Artifact را میبیند و `RISK_FULLY_TRANSFERRED` میدهد. ممیز مستقل حضور کنترلهای ساختاری را بررسی میکند؛ قابلیت اجرای قرارداد، Truth شواهد یا کفایت مالی را اثبات نمیکند.
{
"fixture": "SYN-QA-RISK-TRANSFER-CONTRACT-01",
"superficialGate": "RISK_FULLY_TRANSFERRED",
"initialAudit": "HOLD",
"initialFindingCount": 76,
"independentRule77PeopleScoringDisabled": true,
"correctedAudit": "READY_FOR_RISK_TRANSFER_REVIEW",
"correctedFindingCount": 0,
"proves": "structural completeness only"
}
ردپای اصلاح Validator
اجرای اول ۷۵ Finding واقعی در برابر انتظار ۷۶ ساخت و `TEST_DESIGN_ERROR` داد. شمارنده به ۷۵ تغییر نکرد؛ ممیزی طراحی نشان داد `dutyMap`—تفکیک وظایف قراردادی، عملیاتی، قانونی/اخلاقی و غیرقابلانتقال—جا افتاده است. با افزودن این کنترل substantive، اجرای دوم دقیقاً `HOLD/۷۶` شد. این Correction نشان میدهد انتظار تست نباید خروجی واقعی را تحریف کند.
۷۶ Finding اولیه در چه گروههایی بودند؟
| گروه | کنترلهای مفقود |
|---|---|
| هویت/چرخه | Transfer ID، Version، Status، Supersedes، Effective، Review |
| Context/Risk | Organization، Service، Asset، Objective، Risk ID/statement، Cause/Event/Consequence، parties، exposure |
| حاکمیت | Risk/Decision owner، Authority، Legal/Finance review، Duty map |
| تخصیص | Mechanism، Counterparty/scope، Allocated/Retained/Non-transferable duties |
| Coverage | Covered/Excluded، Limit، Deductible، Waiting، Territory، Term |
| Claim/Remedy | Trigger، Notice، Evidence، Process، Remedy، Cap، Indemnity |
| زنجیره | Subcontractor و Flow-down |
| Control/Assurance | Requirements، Evidence، Method، Cadence، Access، Data |
| Resilience/Exit | Incident، Continuity، Recovery، Exit/Rehearsal، Knowledge، Return/delete |
| Third-party risk | Failure modes، Concentration، Dependencies، Signals، Breach/Escalation |
| Residual/Decision | Residual exposure/owner، Acceptance authority/expiry، Cost، Options، Decision |
| Governance tail | Review evidence، Correction، Audit، Privacy، Not-claimed |
Rule هفتادوهفتم مستقل `people_scoring=false` را تأیید کرد و جزو Findingها نبود. نسخهٔ کامل با صفر Finding فقط `READY_FOR_RISK_TRANSFER_REVIEW` است—نه اثبات Risk truth، Contract enforceability، Counterparty solvency، Claim acceptance، Insurance adequacy، Control effectiveness، Compliance، Recovery یا حذف ریسک.
آزمایشگاه فارسی و آفلاین انتقال ریسک
Lab کاملاً خیالی و بدون شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification مصنوعی. Timeout پیش/پس از Commit خیالی، Callback تکراری/دیر/جابجا، خروجی Vendor ناقص، SLA miss، Claim دیر، Exclusion، Cap exhaustion، Supplier outage، Subcontractor و Exit failure Seed میشوند. Identityهای Risk/Transfer/Contract/Counterparty/Event/Claim/Evidence/Residual/Decision ثابتاند.
مبالغ canonical و کاملاً خیالی IRR و نمایش تومان فقط با Label صریح است؛ هیچ عددی Premium، خسارت، سقف یا Benchmark واقعی نیست. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، نیمفاصله، RTL/LTR، UTC و `Asia/Tehran`/جلالیِ نمایشی آزموده میشوند. هیچ Production، شرکت، Vendor، بیمهگر، شخص، کاربر، پرداخت، بانک، پول، قرارداد، ادعا، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی وجود ندارد.
سناریوی مصنوعی: ارزیابی Callback توسط Supplier
- Risk owner Cause/Event/Consequence و Exposure وضع موجود را منجمد میکند.
- Options شامل Control داخلی، Service بیرونی، بیمهٔ محدود و ترکیب آنها مقایسه میشوند.
- Work scope وعدهٔ «همهٔ آسیبپذیریها» را با سؤال، Sample و Limitation جایگزین میکند.
- Allocated/Retained duties، Control evidence و Subcontractor flow-down ثبت میشوند.
- Supplier خروجی مصنوعی تحویل میدهد؛ Reviewer مستقل Sample Witness را بازاجرا میکند.
- یک SLA miss Candidate Breach میسازد؛ Cure و Remedy از Recovery فنی جدا میمانند.
- Exit rehearsal وابستگی پنهان به Format اختصاصی را Finding میکند.
- Residual ledger Cap/Exclusion/operational duty/supplier failure را به Acceptance authority میدهد.
۳۲ ضدالگوی انتقال ریسک در QA
- Outsourcing یعنی انتقال کامل ریسک.
- Vendor متخصص کیفیت را تضمین میکند.
- Pen test همهٔ آسیبپذیریها را پیدا میکند.
- Report بدون Finding یعنی Risk صفر است.
- SLA همهٔ خسارت را جبران میکند.
- Service credit معادل Loss واقعی است.
- Fixed-price همهٔ Cost risk را منتقل میکند.
- Insurance از Breach پیشگیری میکند.
- Certificate همان Coverage کامل است.
- Policy summary برای تفسیر Claim کافی است.
- Indemnity یعنی پول حتماً وصول میشود.
- Liability cap با Exposure مقایسه نمیشود.
- Exclusion و waiting period نادیده گرفته میشوند.
- Notice window بعد از Incident کشف میشود.
- QA دربارهٔ enforceability حکم میدهد.
- Vendor همهٔ وظایف قانونی را میپذیرد.
- Retained obligations ستون خالی دارد.
- NDA دادهٔ واقعی را امن میکند.
- Subcontractor خارج Scope است.
- Certification جای Control evidence است.
- Self-attestation تضمین آینده است.
- Incident contact فقط یک فرد است.
- Remedy و Recovery یکیاند.
- DR document بدون تمرین کافی است.
- Export CSV یعنی Exit کامل است.
- چند Vendor یعنی Concentration نداریم.
- Transfer ریسک تازه نمیسازد.
- Residual risk صفر نوشته میشود.
- Acceptance بیOwner و بیExpiry است.
- Renewal بینسخه انجام میشود.
- AI قرارداد یا قانون را معتبر تفسیر میکند.
- Metric Supplier برای رتبهبندی افراد است.
چکلیست ۲۸نقطهای ممیزی Transfer
- Transfer/Contract/Risk versionها همراستا هستند.
- Cause–Event–Consequence و Objective روشناند.
- Inherent exposure Range/Unknown دارد.
- Risk owner و Decision authority مشخصاند.
- Legal/Finance review route تعریف شده است.
- Duty map وظایف غیرقابلانتقال را نشان میدهد.
- Optionهای غیر از Transfer مقایسه شدهاند.
- Mechanism دقیق نامگذاری شده است.
- Counterparty due diligence Evidence دارد.
- Scope و Not-promised روشناند.
- Allocated و Retained obligations کنار هماند.
- Covered/Excluded events نسخهدارند.
- Limit/Deductible/Waiting/Term مدل شدهاند.
- Trigger و Notice آزمونپذیرند.
- SLA measurement و dispute rule دارد.
- Claim packet و Chain of custody تمرین شده است.
- Remedy از Recovery جداست.
- Cap/Indemnity با متخصص بازبینی شدهاند.
- Subcontractor و Flow-down دیده شدهاند.
- Control/Assurance Scope و Freshness دارند.
- Access/Data کمینه و زماندارند.
- Incident route و contacts تمرین شدهاند.
- Continuity/RTO/RPO/Fallback معتبرند.
- Exit/return/delete/knowledge rehearsal شدهاند.
- Supplier failure و Concentration در Register هستند.
- Residual/Acceptance owner و Expiry دارند.
- Metricها Countermetric و `people_scoring=false` دارند.
- Correction/Audit/Privacy/Not-claimed کاملاند.
Pilot سیروزهٔ انتقال ریسک
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱ تا ۵ | Risk/Exposure/Duty baseline و Authority map | Risk statement، duty map، options | مسئله واقعی و قابل تصمیم است |
| روز ۶ تا ۱۰ | Counterparty/Mechanism/coverage review | Draft transfer و residual hypotheses | Legal/Finance route فعال است |
| روز ۱۱ تا ۱۸ | Control/Assurance/Claim/Incident walkthrough | Evidence gaps و amended clauses | Trigger/notice/remedy قابل اجراست |
| روز ۱۹ تا ۲۵ | Recovery/Exit/Subcontractor scenario | Rehearsal findings و fallback | Critical ownerless gap ندارد |
| روز ۲۶ تا ۳۰ | Residual review و decision | TRANSFER/AMEND/REJECT + acceptance/expiry | Residual within mandate یا درمان تازه |
سی روز مثال آموزشی است، نه Timeline خرید/قرارداد. قرارداد پیچیده، خدمت حیاتی، بیمه یا بررسی Jurisdiction ممکن است طولانیتر باشد. Pilot نباید تعهد واقعی یا دادهٔ حساس را بدون Review وارد کند. ابتدا Scope مصنوعی/کمخطر را تمرین کنید.
چه چیزی را از Contract نتیجه نگیریم؟
کاملبودن ۷۶ کنترل ثابت نمیکند Risk درست مدل، Counterparty مناسب، Clause قابل اجرا، Insurance کافی، Test کامل، Control مؤثر، Claim پذیرفته، Loss جبران، Compliance حاصل یا Service بازیابی میشود. انتقال موفق هم Product quality یا Release safety را تضمین نمیکند. Contract فقط مرز ادعا، تعهد، Evidence و Residual را قابل بازبینی میکند.
جمعبندی: Capacity را میتوان خرید؛ پاسخگویی را نه همیشه
انتقال ریسک خوب با واژهٔ «Vendor» شروع نمیشود؛ با Risk/Exposure و Duty map شروع میشود. Mechanism و Counterparty را انتخاب کنید، Covered/Excluded/Limit را روشن کنید، Control/Assurance و Claim/Recovery را تمرین کنید، ریسک زنجیره و Exit را ببینید و Residual را به Authority نامدار برگردانید. جملهٔ حرفهای «کدام پیامد، تحت چه Trigger و سقف، به چه طرفی تخصیص یافت و چه چیزی نزد ما ماند؟» است.
سؤالات متداول انتقال ریسک در تضمین کیفیت
آیا برونسپاری تست یعنی انتقال ریسک؟
نه خودکار. برونسپاری معمولاً Activity/Capacity را واگذار میکند. انتقال بخشی از Exposure یا Remedy به Clause، Trigger، Limit و قابلیت اجرای مشخص نیاز دارد. سازمان اغلب Scope، نظارت، تصمیم، عملیات، Customer impact، Duties غیرقابلانتقال و Residual risk را نگه میدارد.
آیا SLA ریسک عملکرد ضعیف Vendor را منتقل میکند؟
SLA میتواند Target، Measurement و Remedy محدود بسازد، اما Failure را جلوگیری یا همهٔ Loss را جبران نمیکند. Exclusion، credit cap، measurement source، dispute، recovery و retained consequence را بررسی کنید. SLA بخشی از Transfer design است، نه اثبات انتقال کامل.
بیمه سایبری چه ریسکی را منتقل میکند؟
فقط Coverage و خدماتی که Policy در Trigger، Term، Territory، Limit، Deductible، Waiting period و Exclusion تعریف میکند. بیمه از حمله پیشگیری نمیکند و ممکن است Control/notification شرط Claim باشد. تفسیر واقعی باید با بیمهگر/Broker و متخصص حقوقی مجاز انجام شود.
ریسک باقیمانده پس از Transfer را چه کسی میپذیرد؟
صاحب اختیاری که Mandate متناسب با نوع و اندازه Consequence دارد؛ نه لزوماً QA، Vendor یا مدیر قرارداد. Residual ledger باید Exclusion، excess، nonfinancial harm، supplier failure و Unknown را نشان دهد و تصمیم Acceptance/درمان را با شرط و Expiry ثبت کند.
چگونه بفهمیم انتقال ریسک مؤثر است؟
Clause presence کافی نیست. Trigger/notice/claim، Control evidence، Incident coordination، Recovery و Exit را Scenario/Rehearsal کنید؛ Residual و Cost را بازبینی کنید؛ Breach/claim/recovery outcome را با Limit گزارش دهید. این Evidence قابلیت قرارداد را میسنجد، نه اینکه ریسک حذف شده یا نتیجه آینده تضمین است.
