قرارداد طراحی سایت؛ Scope، IP، SLA و Exit

قرارداد می‌گوید «سایت کامل، امن و سئو شده تحویل می‌شود». روز اختلاف، کارفرما انتظار Source code، محتوای واردشده، Redirect و دسترسی Cloud دارد؛ مجری می‌گوید منظور فقط فایل Theme بوده، Security یعنی SSL و SEO یعنی نصب افزونه. هیچ‌کدام لزوماً دروغ نمی‌گویند؛ قرارداد با صفت نوشته شده، نه با Asset، Scenario، Evidence و Owner.

قرارداد طراحی سایت باید شامل چه بندهایی باشد؟ هویت و اختیار طرفین، ترتیب اسناد، Scope و Exclusion، Acceptance، زمان/وابستگی/Change، مبلغ و Third-party cost، IP/License، حساب و داده، Security/Privacy/Incident، Accessibility/SEO/Migration، Support/SLA، ضمانت و مسئولیت، تعلیق/فسخ، Exit/Transition، اختلاف و Evidence امضا باید روشن شوند.

هشدار: این نوشته نمونه قرارداد، تفسیر قانون یا مشاوره حقوقی برای وضعیت شما نیست. نوع طرفین، مبلغ، داده، مصرف‌کننده، IP، مالیات، محل اجرا و روش حل اختلاف نتیجه را تغییر می‌دهند. نسخه نهایی و قوانین جاری ایران را وکیل واجدصلاحیت و تیم فنی/امنیتی شما بررسی کنند.

پاسخ کوتاه: ۱۸ پیوست و تصمیم کلیدی

1. Contract map و ترتیب اسناد؛
2. طرفین، اختیار امضا و Notice؛
3. تعریف اصطلاحات و Baseline؛
4. Outcome، Scope، Deliverable و Exclusion؛
5. RACI و تعهدات/Dependency دو طرف؛
6. Milestone، Forecast و Delay handling؛
7. Acceptance و Defect severity؛
8. Change control؛
9. قیمت، مالیات، ارز و Third-party؛
10. IP، License، Background/Foreground و Open source؛
11. Asset/account ownership و access؛
12. Data/Confidentiality/Privacy/AI use؛
13. Security/Vulnerability/Incident/Subcontractor؛
14. A11y/Performance/SEO/Migration/Quality؛
15. Support/SLA/Backup/Operations؛
16. Warranty، Liability، Indemnity و Insurance برای بررسی حقوقی؛
17. Suspension/Termination/Force majeure/Dispute؛
18. Exit، Transition، deletion و Handover evidence.

برای انتخاب طرف مناسب، ابتدا راهنمای انتخاب شرکت طراحی سایت را ببینید. قرارداد نباید Due diligence انجام‌نشده را جادویی جبران کند.

Contract map؛ یک نسخه واحد از حقیقت بسازید

در تعارض Proposal، SOW، Email و پیوست، کدام مقدم است؟ ترتیب صریح و Full-agreement/Amendment process را مشاور حقوقی تنظیم کند. لینک ابری قابل‌ویرایش بدون Snapshot/Hash تاریخ‌دار Evidence ضعیفی است.

طرفین، نمایندگی و اختیار امضا

• نام/شناسه/نشانی و اطلاعات ثبتی یا هویتی دقیق؛
• نماینده مجاز و مبنای اختیار امضا؛
• نشانی و روش Notice رسمی و زمان دریافت؛
• Contactهای عملیاتی جدا از Notice حقوقی؛
• اطلاعات Invoice/مالیات/پرداخت؛
• محدودیت واگذاری قرارداد یا تغییر کنترل؛
• تضاد منافع و رابطه Subcontractorهای کلیدی.

«تیم فلانی» بدون طرف پاسخ‌گو و اختیار روشن، اجرای تعهد و مالکیت را مبهم می‌کند.

تعریف‌ها را عملیاتی بنویسید

Acceptance | Business Day | Change | Confidential Information
Customer Data | Defect | Deliverable | Documentation
Go-live | Incident | Intellectual Property | Open-source software
Personal/Sensitive Data | Production | Severity | Service
Subcontractor | Third-party service | Warranty | Work Product

تعریف باید در تمام پیوست‌ها یکسان باشد. «روز» تقویمی یا کاری، Timezone، تعطیلات و ریال/تومان را روشن کنید.

Outcome، Scope و Exclusion را جدا کنید

Outcome دلیل خرید است؛ Deliverable چیزی است که مجری تحویل می‌دهد؛ Acceptance شاهد عملکرد است. هیچ‌کدام جای دیگری را نمی‌گیرد.

برای هر Deliverable، ID، Format، Environment، Owner، Due window، Dependencies، Acceptance و Handover بنویسید. «سایت حرفه‌ای» Deliverable نیست.

Scope matrix را Asset و State محور کنید

item_id | audience/job | content/template/capability
roles/rules/data/integration | states/failure/recovery
devices/browsers/languages | migration/SEO
quality/security/privacy | owner | acceptance/evidence

Loading/Empty/Error/Permission/Offline/Pending، Mobile/RTL، Admin/Editor، Email/SMS و Backstage operations را حذف نکنید. تعداد صفحه بدون Template/State/Content readiness کافی نیست.

تعهدات کارفرما نیز Schedule واقعی‌اند

• محتوا، Claim، Media و مجوز استفاده؛
• Domain/DNS/Hosting/API/Payment/CRM access؛
• Test data و UAT participant؛
• Review و تصمیم در مهلت مشخص؛
• Legal/Brand/Security approval؛
• پرداخت و خرید Third-party؛
• اعلام تغییر Policy/Process/System؛
• مالک Product/Content/Data/Operations.

اثر تأخیر باید با Critical path و Duty to mitigate محاسبه شود، نه اینکه هر تأخیر کارفرما خودکار هر تاریخ/هزینه‌ای را توجیه کند.

RACI را برای تصمیم‌های مهم پیوست کنید

زمان: Milestone، Dependency و Forecast

یک تاریخ پایان کافی نیست. Baseline باید Scope version، Calendar، Dependency، Review windows، Critical milestones و Assumption داشته باشد. Delay notice شامل علت، Evidence، اثر، Mitigation و Forecast تازه باشد.

راهنمای برآورد زمان طراحی سایت Effort/Duration، Critical path، Range و P50/P80 را توضیح می‌دهد. در قرارداد مشخص کنید چه چیزی Commitment است و چه چیزی Rolling forecast.

Acceptance؛ «تأیید سلیقه‌ای» یا «سکوت نامحدود» نباشد

deliverable/build/environment
acceptance scenarios + quality thresholds
test data/prerequisites
review window + authorized reviewer
result/evidence format
defect severity + cure/retest
accept/reject with reasons
conditional acceptance/waiver expiry
deemed acceptance (if any) and exceptions
production use effect

Deemed acceptance، Production use و حق رد باید توسط وکیل متناسب تنظیم شوند. Defect نسبت به Requirement از Change جدید جداست. «تأیید شد» بدون Build/Scope/Evidence قابل‌دفاع نیست.

Severity و Release gate را تعریف کنید

Waiver باید Risk owner، Scope، Mitigation، Expiry و Revalidation داشته باشد.

Change control؛ تغییر طبیعی را قابل‌محاسبه کنید

change_id + requester + reason/evidence
affected requirements/deliverables
options + impact on time/cost/risk/quality/operations
assumptions/exclusions + price validity
authorized approvers
approved/rejected/deferred + target release
baseline/acceptance/docs update

Email یا پیام‌رسان چه زمانی فقط بحث و چه زمانی دستور تغییر است؟ Emergency change چه مسیر کوتاه و Post-review دارد؟ شروع کار پیش از Approval چه اثری دارد؟ پاسخ حقوقی/تجاری را صریح کنید.

قیمت و پرداخت را نرمال کنید

• Fixed/Time-and-materials/Retainer و واحد محاسبه؛
• مبلغ به عدد/حروف و ریال یا تومان؛
• مالیات/عوارض/کسورات و مسئولیت Invoice؛
• ارز/نرخ تبدیل/تاریخ مبنا برای سرویس خارجی؛
• Third-party setup/usage/renewal/overage؛
• Milestone payment و شرط Evidence/Acceptance؛
• Holdback/Retention اگر حقوقاً و تجاریاً مناسب؛
• هزینه Change، سفر، On-call، Exit و Transition؛
• Late payment، Suspension و Restart؛
• Refund/settlement در Termination.

راهنمای TCO و هزینه‌های پنهان سایت اقلام Run/Change/Risk/Exit را پوشش می‌دهد.

IP را Asset-by-Asset و لایه‌لایه بنویسید

قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای ایران و مقررات مرتبط می‌توانند بر حقوق نرم‌افزار اثر بگذارند، اما نتیجه برای Employee/Contractor، Background component، سفارش خاص و شروط شما نیازمند تفسیر حقوقی است. متن جاری را در سامانه رسمی قوانین بررسی و Clause را وکیل تنظیم کند؛ به یک جمله «کلیه حقوق منتقل شد» اکتفا نکنید.

License و Open-source inventory

component/asset | version/source | license
use/modify/distribute rights | notices/source obligations
commercial seat/domain limits | renewal/expiry
security/support status | replacement/export impact

کد سفارشی می‌تواند به Framework/Open-source/Commercial plugin وابسته باشد. Vendor چیزی را که مالک نیست نمی‌تواند فراتر از License منتقل کند.

مالکیت حساب و دسترسی

Domain، DNS، Hosting/Cloud، Repo، CI/CD، CMS، Database، Design، Analytics، Search Console، Tag manager، Email/SMS/Payment و Vendor portals را در Account register بیاورید:

business/legal owner | admins | MFA/recovery
billing/expiry | least privilege | emergency access
handover date/evidence | offboarding/delete

اصل مناسب معمولاً کنترل سازمان بر حساب حیاتی و دسترسی حداقلی Vendor است؛ استثنا و Managed service را با Exit روشن کنید.

محرمانگی؛ چه چیزی، برای چه مدت و با چه استثنا؟

• تعریف Confidential information و روش علامت‌گذاری؛
• Purpose مجاز و Need-to-know؛
• Standard حفاظت و کانال انتقال؛
• استثناهای اطلاعات عمومی/قبلی/مستقل/الزام قانونی؛
• Subcontractor و Flow-down obligation؛
• مدت و Survival پس از خاتمه؛
• Return/delete و Backup exception؛
• Injunctive/Remedy موضوع بررسی وکیل.

قانون تجارت الکترونیکی ایران موضوعاتی مانند Data-message، امضای الکترونیکی و اسرار تجاری الکترونیکی را پوشش می‌دهد. کاربرد دقیق، اعتبار Evidence و وضعیت تنقیح باید برای قرارداد شما در منبع قانونی رسمی و با وکیل تأیید شود.

Data schedule؛ Purpose تا Delete

نقش‌های حقوقی و الزامات داده را وکیل با قوانین جاری و صنعت/مخاطب تعیین کند. داده Production را برای Test یا Demo پیش‌فرض نکنید.

استفاده Vendor از AI را Contract کنید

• Tool/provider/account و قابلیت Training/Retention؛
• نوع Prompt/Code/Content/Log/Data مجاز و ممنوع؛
• Secret/PII/Confidential data prohibition؛
• Subprocessor/location و تنظیمات سازمانی؛
• Human review و Acceptance responsibility؛
• IP/license/provenance و third-party claim؛
• Security incident و change notification؛
• حذف/Export و Audit evidence.

«استفاده از AI» نه خودکار مجاز است نه خودکار ممنوع؛ Data/Risk/IP/Quality آن باید قابل‌کنترل باشد.

Security requirements را نسخه‌دار کنید

OWASP ASVS 5.0.0 برای Requirement و Verification امنیت Web در Procurement قابل استفاده است. Requirementهای مرتبط را با Version/ID/Applicability، Test method و Evidence انتخاب کنید؛ «امنیت کامل» تعهد قابل‌آزمون نیست.

• Threat/risk و Security owner؛
• Secure development/review/dependency/secret؛
• Environment/CI/CD/repo protection؛
• Identity/MFA/least privilege/audit؛
• Encryption/key/backup/restore؛
• Logging/monitoring/alert/time sync؛
• Vulnerability intake/severity/remediation/retest؛
• Pen test scope/date/independence/remediation؛
• Patch/EOL/component provenance؛
• Security evidence و exception/waiver.

Incident clause؛ ساعت و مسئول را روشن کنید

what constitutes incident + severity
detect/contain/preserve/recover duties
notification trigger and maximum window
24x7 contacts/escalation
initial facts + periodic updates
forensics/evidence/cooperation
public/regulatory/customer communications authority
root cause/corrective action
cost allocation subject to legal review

NCSC Supply chain security بر Incident reporting، بازگشت/حذف Data/Assets در Exit و مشارکت Supply chain در تمرین پاسخ تأکید دارد. Subcontractor نباید Notice را متوقف کند.

Subcontractor و Third-party service

• فهرست، نقش، محل و Data/System access؛
• Approval یا Notice برای تغییر؛
• Flow-down Security/Privacy/IP/Confidentiality؛
• Vendor همچنان مسئول چه چیزی است؟
• Availability/Support/Exit وابسته؛
• License/renewal/price change؛
• Replacement و continuity plan.

Third-party outage را Force majeure خودکار فرض نکنید؛ Control، redundancy و allocation of risk را وکیل و تیم فنی بررسی کنند.

Accessibility در Requirement، Review و Sustain

W3C Planning and Managing Accessibility Policy، مسئولیت، بودجه، ارزیابی زودهنگام و Monitoring را در کل چرخه قرار می‌دهد. Contract مشخص کند:

• Standard/version/level و Scope pages/components/content/PDF؛
• نقش Content/Design/Dev/QA/Vendor/Client؛
• روش Automated/Manual/Assistive/User test؛
• Browser/AT/sample و Evidence؛
• Severity، Remediation، Retest و Waiver؛
• Authoring/CMS workflow و محتوای آینده؛
• Feedback channel و monitoring پس از Live.

برای Baseline و Test design به راهنمای ممیزی WCAG مراجعه کنید.

Performance، SEO و Migration را با خروجی HTTP ببندید

Google Search Central Mapping، Redirect دائم، تست و پایش را لازم می‌داند و نگهداری Redirectها را عموماً دست‌کم یک سال توصیه می‌کند. اگر این مسئولیت در Scope است، مدت Monitoring/Redirect ownership را قرارداد روشن کند؛ رتبه تضمین‌پذیر نیست.

Test portfolio و UAT

Test responsibility matrix بنویسید: چه کسی Unit/Component/Contract/E2E/A11y/Security/Performance/SEO/Migration/Restore را در کدام Environment با چه Evidence اجرا می‌کند. UAT کسب‌وکار جای QA Vendor نیست.

راهنمای استراتژی تست وب Risk-based portfolio و Release gate را توضیح می‌دهد.

Launch، Rollback و Hypercare

• Content/Code/Config freeze؛
• Backup و Restore evidence؛
• DNS/CDN/Certificate/TTL؛
• Data delta و Reconciliation؛
• Go/No-go authority؛
• Cutover steps/owners/time؛
• Smoke/controlled transaction؛
• Rollback trigger/point of no return؛
• Stakeholder/customer communication؛
• Hypercare hours/team/exit criteria.

«انتشار سایت» Milestone فنی است؛ Acceptance نهایی یا پایان Support را خودکار به آن گره نزنید مگر صریح و منطقی.

Support، SLA و SLO

برای تعریف Telemetry، SLO و Alert از راهنمای Observability سایت استفاده کنید.

Backup و Disaster recovery؛ وجود فایل کافی نیست

scope + frequency + retention + location
encryption/access + immutability (if required)
RPO/RTO per journey/data
restore method/environment/frequency
last evidence + failure remediation
ownership/cost at exit

Restore test و Reconciliation باید داخل Acceptance/Support بیایند، نه فقط عبارت «بکاپ روزانه».

Warranty، Liability و Indemnity را کپی نکنید

مدت/Scope Warranty و Remedy برای Defect، Third-party change، Client modification و Unsupported version را روشن کنید. سپس وکیل متناسب با قانون حاکم، مبلغ، بیمه و ریسک درباره موارد زیر تصمیم بگیرد:

• نمایندگی‌ها و ضمانت‌ها؛
• سقف/استثنای مسئولیت و خسارت غیرمستقیم؛
• IP infringement و دفاع/کنترل دعوا؛
• Data/Security/Confidentiality؛
• نقض قانون یا تقصیر؛
• Service credit و انحصاری‌بودن Remedy؛
• Insurance و Evidence پوشش.

این بندها به‌شدت حقوقی و وابسته به Context‌اند؛ نمونه اینترنتی را بدون وکیل وارد نکنید.

تعلیق، خاتمه و Force majeure

Force majeure باید Event، کنترل‌ناپذیری، Notice، Mitigation، اثر، مدت و حق خاتمه را با وکیل روشن کند. قطعی سرویس قابل‌پیش‌بینی یا ضعف Capacity همیشه خارج کنترل نیست.

Exit plan از روز امضا شروع می‌شود

exit triggers + notice + transition period
asset/data/content/media/config export
format/schema/count/hash/sample/reconciliation
repo/build/deploy/docs/ADR/runbook/test evidence
accounts/credentials/domain/DNS transfer
knowledge sessions + replacement supplier cooperation
open incidents/defects/risks/licenses
fees/timescale/roles
return/delete/offboarding confirmation
service continuity + decommission

برای Dry run و Cutover عمیق‌تر، راهنمای مهاجرت سایت را ببینید. Export نمونه را پیش از وابستگی کامل امتحان کنید.

تحویل نهایی یک پوشه نیست؛ Evidence register است

قانون حاکم، حل اختلاف و Evidence الکترونیکی

وکیل باید Governing law، مرجع/روش حل اختلاف، محل، زبان، هزینه، اقدامات فوری و Notice را تنظیم کند. اگر مذاکره/میانجی‌گری/داوری مرحله‌ای است، Trigger و Deadline و اثر آن بر Service روشن شود.

قرارداد و Changeها ممکن است الکترونیکی امضا یا مبادله شوند. قانون تجارت الکترونیکی ایران درباره Data-message و امضای الکترونیکی احکام دارد، اما اینکه روش شما چه اعتبار و شرایطی دارد باید در نسخه جاری منبع قانونی رسمی و با وکیل بررسی شود. Identity، authority، timestamp، integrity، version و archive Evidence را عملیاتی کنید.

روش بازبینی سه‌لایه پیش از امضا

بازبینی حقوقی

اعتبار، اختیار، IP، داده، مسئولیت، مالیات، خاتمه، Force majeure، اختلاف و انطباق قوانین جاری.

بازبینی فنی و امنیتی

Requirement، Architecture، Data flow، Security، Quality، Migration، Operations، Exit و امکان تولید Evidence.

بازبینی تجاری و عملیاتی

Scope، قیمت/TCO، Schedule، Capacity، Change، Support، Continuity و Owner داخلی.

Tabletop اختلاف و Incident

سناریوی Defect، Data incident، Vendor delay، Third-party outage، Scope change و Termination را با متن قرارداد اجرا کنید.

نسخه نهایی و امضا

تمام پیوست‌ها، Hash/Version، اختیار امضا، Notice details و نسخه‌های دو طرف را کنترل کنید.

خطاهای رایج قرارداد طراحی سایت

• «سایت کامل/حرفه‌ای/امن/سئو» بدون Requirement؛
• Proposal/Email/PDF متعارض بدون ترتیب اولویت؛
• طرف یا نماینده بدون اختیار روشن؛
• صفحه‌فهرست به‌جای State/Data/Integration scope؛
• Acceptance سلیقه‌ای یا Deemed acceptance مبهم؛
• تغییر شفاهی بدون اثر Time/Cost/Risk؛
• پرداخت صرفاً با گذر زمان، بدون Evidence؛
• IP کلی بدون Background/Third-party/Open source؛
• دامنه/Repo/Cloud روی حساب شخصی مجری؛
• Data/AI/Subcontractor بدون Flow و Control؛
• Security مطلق یا Pen test بی‌Scope؛
• Accessibility/SEO/Migration در حد شعار؛
• پشتیبانی یک‌ساله بدون Severity/SLA/SLO؛
• Backup بدون Restore test؛
• Termination بدون Exit/Transition/Delete evidence.

منابع و وضعیت زمانی

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. متن قوانین و مقررات، رویه و استانداردها تغییر می‌کنند. برای ایران نسخه جاری را از سامانه رسمی قوانین/روزنامه رسمی بررسی و از وکیل واجدصلاحیت نظر بگیرید.

• متن تنقیحی قانون تجارت الکترونیکی ایران در نظامات؛ برای بررسی منبع رسمی جاری با وکیل
• WIPO Lex: قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای ایران
• OWASP ASVS 5.0.0
• W3C: Planning and Managing Web Accessibility
• NCSC: Supply Chain Security
• Google Search Central: Site Moves

سؤالات متداول قرارداد طراحی سایت

آیا پروپوزال جای قرارداد طراحی سایت است؟

معمولاً Proposal می‌تواند پیوست Scope/Commercial باشد، اما به‌تنهایی لزوماً طرفین، اختیار، ترتیب اسناد، Acceptance، IP، داده، مسئولیت، فسخ، Exit و اختلاف را پوشش نمی‌دهد. نقش و اولویت آن را وکیل در Contract map روشن کند.

مالکیت کد و سایت از چه زمانی منتقل می‌شود؟

پاسخ به قانون حاکم، نوع رابطه، Background/Foreground IP، پرداخت، Licenseهای ثالث و متن توافق وابسته است. Assetها و حقوق منتقل/مجوزداده‌شده، زمان و شرط انتقال و محدودیت Open source/Third-party را وکیل صریح تنظیم کند.

تفاوت ایراد و تغییر در قرارداد چیست؟

Defect انحراف از Requirement/Acceptance نسخه‌دار است؛ Change رفتار، Scope یا Constraint تازه است. Root cause و Evidence تعیین‌کننده‌اند. قرارداد باید Triage، Cure/Retest و Change approval را جدا کند.

قرارداد پشتیبانی سایت چه SLAهایی داشته باشد؟

Scope، ساعات/Timezone، Severity بر Impact، Acknowledge/Engage/Update/Restore/Resolve، SLI/SLO و Exclusion، Maintenance، Escalation، Evidence و Remedy. عدد SLA بدون روش اندازه‌گیری و Source مفید نیست.

چه کسانی قرارداد طراحی سایت را بازبینی کنند؟

وکیل آشنا با قرارداد فناوری و قوانین جاری ایران، صاحب تجاری/Product، مسئول فنی/Data/Security، Content/Marketing و Operations/Finance متناسب با ریسک. بازبینی حقوقی بدون امکان‌سنجی فنی و برعکس کافی نیست.

جمع‌بندی: قرارداد را با سناریوی اختلاف تست کنید

قرارداد خوب همه خطرها را حذف نمی‌کند؛ ابهام، انگیزه و مسیر تصمیم را قابل‌کنترل می‌کند. هر صفت را به Requirement، هر خروجی را به Acceptance، هر حساب را به Owner، هر ریسک را به پاسخ و هر پایان را به Exit evidence تبدیل کنید.

پیش از امضا پنج سناریو را Tabletop کنید: Content دیر، API شکست، Incident داده، درخواست تغییر و فسخ میانه پروژه. اگر متن نمی‌گوید چه کسی، چه وقت، با چه Evidence و چه Remedy تصمیم می‌گیرد، هنوز پیوست یا بازبینی لازم است.