اگر فروشگاه آنلاین شما حتی یک اسکریپت شخص ثالث را در صفحهای که با فرم پرداخت در تماس است بارگذاری کند، دیگر نمیتوانید فرض کنید که سادهترین نسخه انطباق با PCI برای شما صدق میکند. این سطر واحد، که در اعماق سؤالات متداول PCI DSS v4.0.1 مدفون شده است، بیسر و صدا نقشه انطباق را برای صدها هزار پذیرنده کوچک در سال ۲۰۲۶ باز ترسیم کرده است — و بسیاری از آنها تا زمانی که بانک پذیرنده (Acquirer) مدارکی را بخواهد که قادر به ارائه آن نیستند، متوجه این موضوع نخواهند شد.
PCI DSS v4.0.1 صرفاً یک بهروزرسانی جزئی نیست. ۶۴ مورد از الزامات جدید یا بهروزشده از ۳۱ مارس ۲۰۲۵ اجباری شدهاند؛ تمام ارزیابیها در سال ۲۰۲۶ بر اساس استاندارد جدید انجام میشوند و قوانین واجد شرایط بودن برای سادهترین پرسشنامه خودارزیابی به شکلی سختگیرانه شده است که اکثر فروشگاههای تجارت الکترونیک برونسپاری شده را غافلگیر میکند. خبر خوب این است که این استاندارد هنوز برای یک کسبوکار کوچک با ذهنی شفاف و یک چکلیست، قابل مدیریت است. خبر بد این است که جمله "ما از Stripe Checkout استفاده میکنیم، پس مشکلی نداریم" دیگر یک پاسخ خودکار و کافی نیست.
این راهنما تغییرات ایجاد شده، پرسشنامهای که کسبوکار شما واقعاً به آن نیاز دارد، دو الزامات جدید (۶.۴.۳ و ۱۱.۶.۱) که جایگزین SAQ A قدیمی شدهاند، قوانین احراز هویتی که تیمهای کوچک را به دردسر میاندازد و هزینههای واقعی اشتباه در هر یک از این موارد را بررسی میکند.
وضعیت PCI DSS در سال ۲۰۲۶
استاندارد امنیت دادههای صنعت کارت پرداخت (PCI DSS)، کتابچه قوانین قراردادی است که برندهای اصلی کارت — Visa، Mastercard، American Express، Discover، JCB — بر هر کسبوکاری که دادههای دارندگان کارت را ذخیره، پردازش یا منتقل میکند، تحمیل میکنند. شما این گزارش را به "دولت" ارائه نمیدهید. بانک پذیرنده شما (بانک یا پردازشگری که اجازه پذیرش کارت را به شما میدهد) آن را از طریق قرارداد پذیرندگی شما اجرا میکند و آنها همان کسانی هستند که در صورت بروز مشکل، جریمهها را وصول میکنند.
نسخه ۴.۰ PCI DSS در مارس ۲۰۲۲ منتشر شد. نسخه ۴.۰.۱ — که بیشتر یک نسخه شفافسازی بود تا یک استاندارد کاملاً جدید — در اواسط سال ۲۰۲۴ به نسخه فعال تبدیل شد. بازه زمانی انتقال در ۳۱ مارس ۲۰۲۵ به پایان رسید: از آن تاریخ به بعد، تکتک ۵۱ الزامات تاریخدارِ آینده، بدون هیچ دوره ارفاقی در محدوده ارزیابی قرار میگیرند و هر ارزیابی که در طول سال ۲۰۲۶ انجام شود، بر اساس نسخه ۴.۰.۱ خواهد بود. دیگر گزینه v3.2.1 برای بازگشت وجود ندارد.
۱۲ خانواده اصلی الزامات همچنان ثابت باقی ماندهاند که در ۶ هدف کنترلی سازماندهی شدهاند:
- ایجاد و نگهداری یک شبکه امن: دیوارهای آتش و تنظیمات پیشفرض فروشنده (الزامات ۱–۲)
- محافظت از دادههای دارنده کارت: دادههای ذخیره شده و دادههای در حال انتقال (الزامات ۳–۴)
- نگهداری برنامه مدیریت آسیبپذیری: ضد بدافزار و توسعه امن (الزامات ۵–۶)
- اجرای کنترل دسترسی قوی: نیاز به دانستن، شناسایی، دسترسی فیزیکی (الزامات ۷–۹)
- پایش و آزمایش منظم شبکهها: ثبت وقایع و آزمایش (الزامات ۱۰–۱۱)
- نگهداری خطمشی امنیت اطلاعات: حاکمیت (الزام ۱۲)
آنچه در v4.0.1 تغییر کرده، عمق است، نه وسعت. استاندارد اکنون از شما انتظار دارد در مورد نحوه اجرای اسکریپتها در صفحات پرداخت، دفعات بازبینی کنترلهای خود، نحوه احراز هویت مدیران و اینکه آیا رمز عبوری که حسابدار شما پنج سال پیش انتخاب کرده هنوز قابل قبول است یا خیر، فکر کنید.
سطوح پذیرندگان: جایگاهی که اکثر کسبوکارهای کوچک در آن قرار میگیرند
برندهای کارت، هر پذیرنده را بر اساس حجم تراکنش سالانه در یکی از چهار سطح قرار میدهند. سطح تعیین میکند که انطباق چگونه تایید شود، نه اینکه آیا استاندارد اعمال میشود یا خیر.
- سطح ۱: بیش از ۶ میلیون تراکنش کارت در سال، یا هر پذیرندهای که دچار نشت تایید شده دادههای حساب شده باشد. نیاز به ارزیابی سالانه در محل توسط یک ارزیاب امنیتی تایید شده (QSA) و اسکن سه ماهه توسط فروشنده اسکن تایید شده (ASV) دارد.
- سطح ۲: بین ۱ میلیون تا ۶ میلیون تراکنش در سال. معمولاً به SAQ سالانه یا ارزیابی QSA در محل، بسته به برند کارت، نیاز دارد.
- سطح ۳: ۲۰,۰۰۰ تا ۱ میلیون تراکنش تجارت الکترونیک در سال. SAQ سالانه به اضافه اسکنهای ASV سه ماهه.
- سطح ۴: کمتر از ۲۰,۰۰۰ تراکنش تجارت الکترونیک در سال، یا تا ۱ میلیون تراکنش در مجموع تمام کانالها. SAQ سالانه و برای اکثر کانالها، اسکنهای ASV سه ماهه.
اگر یک بوتیک آنلاین، جریان صورتحساب SaaS، یک کسبوکار خدماتی منطقهای یا یک رستوران تکشعبهای را اداره میکنید، تقریباً به طور قطع در سطح ۴ هستید. این شامل اکثریت قریب به اتفاق پذیرندگان در سراسر جهان میشود. تاییدیه سادهتر است، اما استاندارد اصلی یکسان است — با شماره کارت لو رفته از یک پذیرنده با ۲۰۰ تراکنش در سال، همانگونه برخورد میشود که با نشت داده از یک سازمان بزرگ.
پرسشنامههای خودارزیابی: انتخاب گزینه صحیح
پرسشنامه خودارزیابی (SAQ) روشی است که پذیرندگان سطوح ۲ تا ۴ برای تایید انطباق خود استفاده میکنند. شورای PCI نه نوع SAQ را نگهداری میکند و انتخاب گزینه صحیح دقیقاً به نحوه جریان دادههای پرداخت شما بستگی دارد. انتخاب SAQ اشتباه، رایجترین اشتباه پذیرندگان کوچک است.
- SAQ A: پذیرندگان تجارت الکترونیک یا سفارشات پستی/تلفنی که تمام عملکردهای دادههای دارنده کارت را به طور کامل به اشخاص ثالث تایید شده PCI DSS برونسپاری میکنند. پیش از این، این گزینه برای پذیرندگان Shopify، Stripe Checkout و PayPal بسیار آسان بود — اما بخش بعدی را ببینید، زیرا قوانین واجد شرایط بودن سختتر شده است.
- SAQ A-EP: پذیرندگان تجارت الکترونیک که پردازش پرداخت را بهطور جزئی برونسپاری میکنند، اما وبسایت آنها همچنان بر امنیت تراکنش تأثیرگذار است (بهعنوان مثال، سایتهایی که صفحه پرداخت اختصاصی خود را طراحی کرده و از یک API پرداخت استفاده میکنند).
- SAQ B: پذیرندگانی که فقط از ماشینهای نقشبرجسته (imprint) یا ترمینالهای مستقل و شمارهگیر (dial-out) استفاده میکنند. هیچ اتصال اینترنتی با دادههای کارت در تماس نیست.
- SAQ B-IP: پذیرندگانی که از ترمینالهای پرداخت مستقل متصل به IP استفاده میکنند (بیشتر ترمینالهای پیشخوان مدرن).
- SAQ C-VT: پذیرندگانی که دادههای کارت را از طریق یک ترمینال مجازی روی یک ایستگاه کاری ایزوله وارد میکنند.
- SAQ C: پذیرندگانی که دارای یک برنامه پرداخت متصل به اینترنت هستند، اما دادهها در آن ذخیره نمیشوند.
- SAQ P2PE: پذیرندگانی که از یک راهکار رمزنگاری نقطه-به-نقطه (Point-to-Point Encryption) تایید شده استفاده میکنند.
- SAQ D-Merchant: دستهای کلی برای پذیرندگانی که در هیچکدام از دستههای دیگر SAQ قرار نمیگیرند — و با اختلاف طولانیترین مورد است.
- SAQ D-Service Provider: برای ارائه دهندگان خدمات که واجد شرایط خودارزیابی هستند.
هر SAQ فقط زیرمجموعهای از ۳۰۰+ کنترل را میپرسد که مربوط به آن مدل پذیرش است. SAQ A کمتر از ۳۰ سوال دارد؛ SAQ D-Merchant بیش از ۲۵۰ سوال دارد. تفاوت در تلاش مورد نیاز بسیار زیاد است، به همین دلیل پذیرندگان میخواهند تا حد امکان به طور قانونی واجد شرایط SAQ A باشند.
تله صلاحیت SAQ A
بزرگترین تغییری که پذیرندگان کوچک تجارت الکترونیک در سال ۲۰۲۶ باید درک کنند این است که چه کسی واقعاً واجد شرایط SAQ A است. شورای استانداردهای امنیتی PCI در اوایل سال ۲۰۲۵، سوال متداول (FAQ) شماره ۱۵۸۸ را منتشر کرد و معیارها را به طور قابل توجهی سختگیرانهتر کرد.
طبق نسخه ۴.۰.۱، استاندارد SAQ A تنها زمانی قابل استفاده است که بتوانید تأیید کنید صفحات تجارت الکترونیک شما — از جمله صفحهای که حاوی آیفریم (iframe) پرداخت تعبیهشده یا تغییر مسیر (redirect) است — در برابر حملات اسکریپتهایی که میتوانند بر محیط پرداخت شما تأثیر بگذارند، آسیبپذیر نیستند. این واکنشی است به موج حملات اسکیمینگ دیجیتال (که اغلب "میجکارت" نامیده میشوند) که در آن مهاجمان یک کتابخانه جاوااسکریپت شخص ثالث را هک کرده و دادههای کارت را حتی از سایتهایی که فکر میکردند همه چیز را برونسپاری کردهاند، استخراج میکنند.
در عمل، شما میتوانید به یکی از دو روش زیر این شرایط را برآورده کنید:
۱. اجرای محافظتهای اسکریپت در الزامات ۶.۴.۳ و ۱۱.۶.۱ توسط خودتان. از هر اسکریپتی که در صفحه پرداخت شما بارگذاری میشود فهرستبرداری کنید، هر کدام را مجاز کنید، دلیل نیاز به آن را توجیه کنید و مکانیزم تشخیص تغییر و دستکاری را مستقر کنید که در صورت تغییر غیرمنتظره هدر HTTP یا محتوای صفحه، به شما هشدار دهد. این مکانیزم باید صفحه پرداخت را حداقل هر هفت روز یک بار، یا با فرکانسی که از طریق تحلیل ریسک هدفمند توجیه میکنید، ارزیابی کند. ۲. دریافت تأییدیه کتبی از پردازشگر پرداخت خود مبنی بر اینکه راهکار تعبیهشده آنها شامل محافظتهای داخلی در برابر حملات مبتنی بر اسکریپت از طرف شما است.
مسیر دوم مسیری است که اکثر پذیرندگان کوچک دنبال خواهند کرد، اما این موضوع خودکار نیست. شما به یک بیانیه مستند از پردازشگر نیاز دارید — نه یک صفحه بازاریابی. بسیاری از پذیرندگان Stripe، Adyen، Braintree و Square متوجه خواهند شد که پردازشگر آنها یک گواهی (attestation) منتشر کرده است؛ برخی از درگاههای کوچکتر این کار را انجام ندادهاند. اگر پردازشگر شما نمیتواند آن تأییدیه را به صورت کتبی به شما بدهد، شما باید به سراغ SAQ A-EP بروید یا خودتان کنترلها را بسازید.
اگر فرآیند پرداخت "برونسپاری شده" شما در واقع هر گونه جاوااسکریپت تحت کنترل پذیرنده را بارگذاری میکند که میتواند بر فرم پرداخت تأثیر بگذارد — مانند ابزارهای تحلیلی، تست A/B، ویجتهای چت، مدیریت تگها — تفسیر محافظهکارانه این است که شما دیگر واجد شرایط SAQ A نیستید، صرفنظر از آنچه پردازشگر شما میگوید.
احراز هویت: دو قانونی که تیمهای کوچک را غافلگیر میکند
صرفنظر از اینکه کدام SAQ اعمال شود، دو تغییر در کنترل دسترسی در نسخه ۴.۰.۱ تقریباً هر کسبوکار کوچکی را غافلگیر میکند.
الزام ۸.۳.۶: رمزهای عبور باید حداقل ۱۲ کاراکتر باشند. اگر سیستم فقط ۸ کاراکتر را پشتیبانی میکند، میتوانید روی ۸ بمانید، اما هر سیستمی با قابلیت بیشتر باید ارتقا یابد. رمزهای عبور باید شامل هر دو کاراکتر عددی و الفبایی باشند. حداقل ۷ کاراکتر قدیمی از نسخه ۳.۲.۱ حذف شده است.
الزام ۸.۴.۲: احراز هویت چندعاملی برای تمام دسترسیها به محیط دادههای دارنده کارت. پیش از این، MFA فقط برای دسترسی از راه دور توسط مدیران سیستم الزامی بود. در نسخه ۴.۰.۱، هر کسی — مدیر، توسعهدهنده، پشتیبانی شخص ثالث، خود شما — هر بار که به هر جزء از سیستم در محیط دادههای دارنده کارت دسترسی پیدا میکند، به MFA نیاز دارد، نه فقط زمانی که از خارج از شبکه متصل میشود. خودِ MFA باید در برابر حملات بازپخش (replay attacks) مقاوم باشد و حداقل به دو مورد از اینها نیاز داشته باشد: چیزی که میدانید، چیزی که دارید، چیزی که هستید.
برای یک پذیرنده کوچک، ترجمه عملی این است: MFA را در پورتال پردازشگر خود، پنل کنترل هاستینگ، ثبتکننده دامنه، ارائهدهنده DNS، مدیریت تجارت الکترونیک، بخش پشتی پایانه فروش و هر لپتاپی که با آن سیستمها در تماس است، فعال کنید. از یک اپلیکیشن احراز هویت یا کلید سختافزاری استفاده کنید — MFA مبتنی بر SMS به طور فزایندهای ناکافی تلقی میشود، حتی اگر استاندارد هنوز به لحاظ فنی آن را مجاز بداند.
تحلیل ریسک هدفمند: سندی که احتمالاً به آن نیاز دارید
استاندارد PCI DSS نسخه 4.x مفهومی به نام تحلیل ریسک هدفمند (TRA) را معرفی میکند — یک تحلیل کوتاه و مستند که به شما اجازه میدهد فرکانس انجام برخی کنترلها را توجیه کنید. تقریباً دوازده الزام شامل گزینه "فرکانس تعریف شده در تحلیل ریسک هدفمند نهاد" هستند.
الزام ۱۲.۳.۱ به تفصیل توضیح میدهد که یک TRA باید شامل چه مواردی باشد: شناسایی دارایی مورد محافظت، تهدیدی که کاهش مییابد، عواملی که بر احتمال و تأثیر اثر میگذارند، و منطق فرکانس انتخاب شده. شورای PCI یک الگو در پیوست E2 استاندارد منتشر کرده است.
برای یک پذیرنده سطح ۴، این معمولاً یک سند یکصفحهای برای هر کنترل است. اشتباهی که باید از آن اجتناب کرد، نادیده گرفتن کامل آن است. اگر ارزیاب یا بانک پذیرنده از شما بپرسد چرا صفحه پرداخت خود را برای تشخیص دستکاری هر ۳۰ روز یک بار به جای هر ۷ روز اسکن میکنید، پاسخ "فکر کردیم کافی است" قابل قبول نیست؛ اما پاسخ "این تحلیل ریسک ما به تاریخ ۱۴ ژانویه ۲۰۲۶ است که توسط مالک امضا شده" قابل قبول است.
از رویکرد سفارشی (customized approach) نسخه ۴.۰ دوری کنید. این رویکرد برای شرکتهای بالغ از نظر ریسک با تیمهای امنیتی اختصاصی در نظر گرفته شده است؛ برای پذیرندگان کوچک، رویکرد تعریفشده (defined approach) با چکلیست صریح آن سریعتر، ارزانتر و دفاع از آن آسانتر است.
هزینههای واقعی عدم انطباق
پذیرندگان کوچک میزان مواجهه مالی را دستکم میگیرند زیرا جریمهها تا زمانی که اعمال نشوند، فرضی به نظر میرسند. ارقام جمعآوریشده از جداول بانکهای پذیرنده و گزارشهای صنعت، هوشیارکننده هستند.
عدم انطباق روتین — مانند عدم ارسال SAQ، اسکنهای ASV منقضی شده — معمولاً منجر به جریمههای ماهانه از سوی بانک پذیرنده شما میشود که از ۵,۰۰۰ تا ۱۰,۰۰۰ دلار در ماه شروع میشود. پس از سه تا شش ماه عدم انطباق، این جریمهها معمولاً به ۲۵,۰۰۰ تا ۵۰,۰۰۰ دلار در ماه افزایش مییابد و تخلفات مزمن میتواند به بیش از ۱۰۰,۰۰۰ دلار در ماه برسد. بانک پذیرنده همچنین میتواند کارمزدهای پردازش به ازای هر تراکنش را افزایش دهد یا حساب پذیرنده را مسدود کند که اغلب آسیبزاتر از جریمهها است.
یک نشت داده تأیید شده در سطح دیگری است. برندهای کارت اعتباری جریمههایی در حدود ۵۰ تا ۹۰ دلار برای هر رکورد لو رفته تعیین میکنند، علاوه بر هزینههای اجباری بررسیهای جرمشناسی دیجیتال (۱۵,۰۰۰ دلار به بالا)، هزینههای صدور مجدد کارت که برندها به پذیرنده منتقل میکنند و برگشت از پرداخت (chargeback) برای تراکنشهای کلاهبرداری. مطالعات صنعتی میانگین هزینه کل یک نشت داده کارت پرداخت را برای یک پذیرنده متوسط بین ۱۵۰,۰۰۰ تا ۳ میلیون دلار برآورد میکنند و این رقم برای نشتهای بزرگ به میلیونها دلار میرسد. برای یک پذیرنده سطح ۴، انطباق سالانه ممکن است ۳,۰۰۰ دلار در سال هزینه داشته باشد، در حالی که یک نشت داده واحد میتواند سود ده سال را از بین ببرد.
قوانین ایالتی و FTC نیز بر این هزینهها میافزایند. هزینههای اطلاعرسانی، حقالوکاله، دعاوی دسته جمعی و پیگیریهای رگولاتوری معمولاً از خودِ جریمههای برند کارت فراتر میروند.
یک چکلیست عملیاتی برای انطباق با الزامات ۲۰۲۶ ویژه پذیرندگان کوچک
استانداردها در مجموع ترسناک به نظر میرسند، اما چکلیست برای یک پذیرنده تجارت الکترونیک کوچک یا یک کسبوکار خدماتی، محدود و مشخص است. این مراحل را به ترتیب دنبال کنید:
۱. سطح پذیرنده (Merchant Level) خود را بهصورت کتبی از بانک پذیرنده (Acquirer) خود استعلام کنید. سطوح بر اساس رابطه با هر بانک پذیرنده تعیین میشوند و نه به صورت جهانی. ۲. جریان دادههای دارندگان کارت را ترسیم کنید. نموداری بکشید که نشان دهد دادههای کارت از کجا وارد میشوند، به کجا میروند و از کجا خارج میشوند. اگر دادههای کارت هرگز به سرورهای شما برسند، دامنه مسئولیت شما به شدت گسترش مییابد. ۳. SAQ صحیح را انتخاب کنید. هر گزینه را با دقت بخوانید. اگر یک پذیرنده تجارت الکترونیک هستید که ادعای SAQ A دارید، واجد شرایط بودن خود را بر اساس FAQ 1588 بررسی کنید. ۴. از پردازشگر پرداخت خود تاییدیه کتبی بگیرید که در راهکار تعبیهشده (Embedded Solution) آنها، محافظت در برابر حملات اسکریپتی وجود دارد. این تاییدیه را در سوابق انطباق خود بایگانی کنید. ۵. تمامی اسکریپتهای موجود در صفحات پرداخت خود را فهرستبندی کنید. اگر نمیتوانید تاییدیه پردازشگر را بگیرید، برای اجرای الزامات ۶.۴.۳ (اسکریپتهای مجاز) و ۱۱.۶.۱ (تشخیص دستکاری) آماده شوید. ۶. MFA را در هر جایی که مدیر (Admin) به سیستمهای پرداخت دسترسی دارد، فعال کنید. از یک اپلیکیشن احراز هویت استفاده کنید، نه پیامک (SMS). ۷. طول گذرواژهها را به بیش از ۱۲ کاراکتر با ترکیبی از اعداد و حروف افزایش دهید. ۸. اسکنهای فصلی ASV را برنامهریزی کنید اگر SAQ شما به آنها نیاز دارد (بیشتر سیستمهای متصل به اینترنت به این اسکنها نیاز دارند). ۹. یک تحلیل ریسک هدفمند را مستند کنید برای هر کنترلی که فرکانس اجرای آن را خودتان تعیین میکنید. ۱۰. یک سیاست امنیت اطلاعات بنویسید (الزام ۱۲). یک سند ساده یکصفحهای که شامل موارد استفاده مجاز، مخاطبان پاسخگویی به حوادث و برنامه بررسی سالانه باشد، نیازهای اولیه یک پذیرنده کوچک را برآورده میکند. ۱۱. هر کارمندی را که با پرداختها در ارتباط است بهصورت سالانه آموزش دهید. لیستهای حضور و غیاب یا سوابق آموزش الکترونیکی را نگه دارید. ۱۲. SAQ و تاییدیه انطباق (AoC) را طبق برنامه به بانک پذیرنده خود ارسال کنید. آن را در تقویم خود ثبت کنید.
حتی در این سطح از جزئیات، یک آخر هفته متمرکز به همراه چند صد دلار هزینه برای اسکن ASV، نیازهای اکثر پذیرندگان کوچک را پوشش میدهد.
حسابداری چگونه به این تصویر متصل میشود؟
انطباق با PCI فقط یک تمرین امنیتی نیست؛ بلکه پیامدهای مستقیم حسابداری دارد. هزینههای انطباق (ابزارهای SAQ، اسکنهای ASV، سختافزارهای MFA، خدمات تشخیص دستکاری)، کارمزدهای پردازشگر که بسته به وضعیت انطباق شما تغییر میکنند، و هرگونه جریمه یا هزینههای اصلاحی، همگی در دفاتر مالی شما جریان مییابند. اثرات درآمدی ناشی از نفوذ امنیتی نیز به همین ترتیب است: استرداد وجه (Chargebacks)، بازپرداختها، هزینههای صدور مجدد که توسط بانک پذیرنده به شما منتقل میشود و فروشهای از دست رفته در طول دوره پاسخگویی به حادثه.
نگهداری یک دفترداری تمیز و بهصورت اقلام جزئی برای هر هزینه مربوط به پرداخت — که به تفکیک پردازشگر، ابزارهای امنیتی و خدمات انطباق تفکیک شده باشد — به سه روش سودبخش است. اول، مستند میکند که سرمایهگذاریهای انطباق در حال انجام است (مفید برای زمانی که بانک پذیرنده یا بیمهگر سوال میپرسد). دوم، هزینه واقعی هر کانال پذیرش پرداخت را مشخص میکند که به شما در مذاکره برای نرخهای پردازشگر کمک میکند. و سوم، اگر نفوذی رخ دهد، به حسابرس قضایی شما مسیری شفاف برای تعیین میزان خسارت جهت دریافت از بیمه میدهد.
سوابق انطباق خود را آماده حسابرسی نگه دارید
چه در حال پاسخگویی به پرسشنامه بانک پذیرنده باشید، چه یک بیمهگر ریسکهای سایبری، یا یک حسابرس قضایی پس از نفوذ؛ پذیرندگانی که وقایع PCI را بهخوبی پشت سر میگذارند، کسانی هستند که دفاتر و سوابق آنها داستانی شفاف را روایت میکنند. Beancount.io حسابداری متنمحور و تحت کنترل نسخه را ارائه میدهد که به شما مسیری شفاف و دارای برچسب زمانی از هر کارمزد پردازش پرداخت، ابزار امنیتی و هزینه انطباق میدهد — بدون جعبههای سیاه، بدون وابستگی به فروشنده و آماده برای عصر مالیِ مبتنی بر هوش مصنوعی. رایگان شروع کنید و کارهای انطباق خود را با دفترداری دقیقی همراه کنید که در برابر هرگونه بازرسی سربلند باشد.