Ответ сразу: до демонстрации с реальными данными опишите услугу по слоям, определите, являетесь ли вы поставщиком облачных услуг, SaaS-провайдером, обработчиком или самостоятельным контролером, и установите отрасль клиента. Затем постройте карту персональных данных и стран, оцените PDPL и трансграничную передачу, применимость правил Communications, Space & Technology Commission (CST) и National Cybersecurity Authority (NCA), налоговый режим, договор и эксплуатационную поддержку. Пилот запускается только после санкционно-банковского допуска конкретных сторон и письменного утверждения архитектуры.
Материал предназначен для русскоязычных команд независимо от страны регистрации. Целевая юрисдикция русскоязычного продукта не утверждена; язык не означает доступность сервиса, платежа или хостинга для любого пользователя. Статья не заменяет саудовское юридическое, налоговое, privacy- и cybersecurity-заключение.
Главный вопрос до первой сделки
Не «можем ли мы включить регион в настройках hyperscaler?», а:
Можем ли мы предоставить конкретному саудовскому клиенту законную, безопасную, облачно и операционно устойчивую услугу — с понятной ответственностью за каждый байт данных, каждый субподрядчик и каждый инцидент?
SaaS — бизнес-модель, а не освобождение от регулирования. Один продукт может включать хостинг, коммуникации, платежи, AI, cybersecurity, электронную подпись или отраслевую функцию. Клиент из банка, здравоохранения или государства может иметь дополнительные требования сверх общего PDPL.
Семь архитектурных решений
1. Разложите сервис по ролям и слоям
Нарисуйте service blueprint:
- интерфейс и мобильное приложение;
- API и интеграции;
- приложение и модели/алгоритмы;
- база, логи, backups и аналитика;
- IaaS/PaaS, регион и аварийная площадка;
- support, monitoring и privileged access;
- платежи, email/SMS, identity и иные subprocessors;
- локальный reseller/implementation partner;
- кто заключает договор и выставляет счет.
CST объясняет различия IaaS, PaaS и SaaS и регулирует предоставление облачных услуг. Нельзя автоматически считать, что регистрация hyperscaler закрывает обязанности SaaS-компании. Независимый специалист должен сопоставить фактическую услугу с Cloud Computing Service Provisioning Regulations, руководством поставщика и возможной регистрационной категорией.
2. Классифицируйте клиента и отрасль
Один и тот же feature может иметь иной риск у розничной компании, больницы, банка или государственного органа. В intake-форме фиксируйте:
- юридическое лицо и сектор клиента;
- типы пользователей;
- бизнес-процесс и критичность;
- категории и объем данных;
- интеграции с государственными/финансовыми системами;
- требования доступности и восстановления;
- профессиональные или отраслевые разрешения;
- место эксплуатации и администраторов.
До отраслевой проверки запрещайте sales-команде обещать production use. Sandbox с синтетическими данными — не production approval.
3. Постройте PDPL-карту обработки
Saudi Personal Data Protection Law определяет персональные данные широко. Для каждого потока зафиксируйте:
- субъект и категория данных;
- источник и цель;
- правовое основание и уведомление;
- controller, joint controller или processor;
- получатели и subprocessors;
- страна хранения, доступа, резервирования и поддержки;
- срок хранения и удаление;
- запросы субъектов;
- инцидент и уведомление;
- доказательство исполнения.
Роль определяется фактическим решением о целях и средствах, а не заголовком договора. Если SaaS использует данные клиента для собственной аналитики или обучения модели, это может изменить оценку. Не прячьте вторичное использование в общей privacy policy.
4. Спроектируйте трансграничную передачу
Доступ инженера за пределами Королевства, выгрузка в иностранную SIEM, backup или поддержка может быть трансграничной передачей, даже если основная база в Эр-Рияде. Правила и руководства SDAIA предусматривают условия и подходящие гарантии, включая standard contractual clauses, сертификаты или Binding Common Rules в соответствующих случаях; конкретный механизм и transfer impact assessment должен определить специалист.
Создайте реестр передачи:
| Поток | данные | страна/получатель | цель | основание/гарантия | последующая передача | владелец |
|---|---|---|---|---|---|---|
| support | минимальный диагностический набор | конкретная команда | устранение инцидента | утвержденный механизм | запрещена без согласования | support lead |
| backup | зашифрованная копия | указанный регион | восстановление | оценка и договор | облачный subprocessor | CTO/DPO |
| analytics | псевдонимизированные события | указанный сервис | метрики | отдельная оценка | по списку | product owner |
Не обещайте «данные никогда не покидают страну», если иностранный администратор видит их удаленно. Лучше точная ограниченная архитектура, чем маркетинговое абсолютное утверждение.
5. Совместите CST и NCA с техническими контролями
CST Cloud Computing Service Provisioning Regulations и guides определяют права и обязанности в облачной услуге и регистрационный процесс для применимых поставщиков. NCA Cloud Cybersecurity Controls (CCC–2:2024) устанавливают минимальные ожидания для cloud service providers и tenants в своей области применения. Кроме того, отраслевой клиент может навязать собственные контролируемые требования.
Соберите control-evidence matrix, а не папку сертификатов:
- asset inventory и data classification;
- IAM, MFA, least privilege и quarterly access review;
- шифрование и key ownership;
- secure SDLC, dependency и vulnerability management;
- tenant isolation;
- логирование, время, мониторинг и retention;
- incident response и связь с клиентом;
- backup, restore test, RTO/RPO;
- subprocessor due diligence;
- business continuity и exit/export данных;
- независимый тест и закрытие findings.
ISO-сертификат поставщика инфраструктуры не доказывает безопасность вашего кода, ролей или поддержки. На каждый ответ customer security questionnaire должна быть ссылка на актуальное доказательство и ответственное лицо.
6. Превратите архитектуру в договор и operating model
Master Service Agreement, Data Processing Agreement, SLA и security schedule должны соответствовать системе. Определите:
- scope, authorized users и запрещенное использование;
- стороны, роли PDPL и инструкции контролера;
- location, subprocessors и уведомление об изменении;
- security controls и audit evidence;
- инцидент, сроки эскалации и сотрудничество;
- доступность, maintenance, RTO/RPO и service credits;
- IP, customer data и телеметрия;
- support language/time zone и privileged access;
- возврат, перенос и удаление данных;
- ограничения ответственности и страхование;
- налог, валюта, оплата и прекращение.
Арабская версия пользовательских уведомлений, интерфейса, consent и поддержки должна пройти нативную продуктовую и юридическую проверку. Перевод английского UX справа налево не создает понятного арабского продукта.
7. Проверьте коммерческую и налоговую исполнимость
Определите, продает ли иностранная компания дистанционно, через reseller, branch или Saudi company. Saudi Business Center предлагает отдельные пути учреждения компании и регистрации филиала при инвестиционной регистрации; выбор зависит от фактических договоров, людей и рисков, а не от скорости формы.
ZATCA Digital Economy Guide объясняет, что VAT-механизм для электронных услуг нерезидента зависит, в частности, от статуса клиента: для ряда B2C-поставок может возникать регистрация поставщика, а при поставке VAT-зарегистрированному клиенту применяться reverse charge. Конкретный продукт, establishment, withholding tax и invoicing проверяет саудовский налоговый специалист.
Отдельно проведите санкционный, KYC, export-control и банковский допуск компании, клиента, кода, шифрования, платежа и поддержки. Новый cloud region или reseller не устраняет ограничения. Если сторона или банк не допускают сделку, сервис не активируют.
100-дневная карта подготовки
Дни 1–20: discovery без реальных данных
- сегмент, бизнес-процесс и отраслевой регулятор;
- service blueprint и activity map;
- synthetic demo;
- предварительная PDPL-карта;
- список CSP/subprocessors и стран;
- санкционно-экспортный intake.
Дни 21–50: legal и technical design
- заключение о CST/регистрации и отраслевых правилах;
- controller/processor role memo;
- transfer mechanism и impact assessment;
- target cloud architecture;
- control-evidence matrix;
- арабские notices и UX requirements;
- tax/contracting options.
Дни 51–75: тест доказательств
Проведите restore, tenant isolation, incident tabletop, data-subject request, deletion/export и privileged support drill. Findings получают severity, владельца и срок; критические закрываются до пилота.
Дни 76–100: ограниченный платный пилот
Используйте минимальные данные и функции, названных пользователей, отдельную среду, критерии принятия, срок и план удаления. Пилот не становится production молча. Решение о масштабировании принимает committee после проверки безопасности, права, налога, платежа и unit economics.
Контрольный список production readiness
- Юрисдикция аудитории и правовая допустимость конкретных сторон утверждены.
- Фактический сервис разложен на SaaS/cloud/communications/security функции.
- Применимость CST, NCA и отраслевых правил подтверждена письменно.
- Все категории данных и страны доступа внесены в live data map.
- Controller/processor роли отражают реальность.
- Уведомления, основания, retention и права субъектов реализованы.
- Механизм и оценка трансграничной передачи утверждены.
- CSP/subprocessors проверены, а изменения управляются.
- CCC/customer controls связаны с доказательствами и тестами.
- Арабские UX, legal notices и support прошли нативную проверку.
- Договор, DPA, SLA и security schedule не противоречат архитектуре.
- VAT/withholding/permanent-establishment анализ завершен.
- Санкции, экспортный контроль, KYC и банк одобрили конкретную конфигурацию.
- Exit, data export/deletion и business continuity практически протестированы.
Сценарий — учебное предположение
Предположим, русскоязычная SaaS-команда продает саудовским логистическим компаниям систему маршрутизации. Продажи обещали «хостинг в Саудовской Аравии», но карта показывает: support видит логи из другой страны, email-уведомления идут через иностранного subprocessora, а AI-модуль использует события для улучшения общей модели.
Компания не маскирует это формулировкой «данные локализованы». Она отделяет tenant data от продуктовой телеметрии, минимизирует логи, ограничивает поддержку, проектирует transfer mechanism, дает клиенту прозрачный список subprocessors и исключает обучение на клиентских данных без отдельного законного решения. Затем проверяет CST, NCA и отрасль клиента. Сценарий не подтверждает допустимость конкретной страны хостинга или команды; он показывает, что location базы — только один слой.
Частые ошибки
- Считать SaaS нерегулируемым, потому что сервер арендуется у известного CSP.
- Начинать demo с реальными персональными данными до договора и карты.
- Назвать себя processor, одновременно самостоятельно переиспользуя данные.
- Игнорировать удаленный доступ как трансграничную передачу.
- Обещать абсолютную локализацию без проверки backup, логов и support.
- Выдать сертификат инфраструктуры за безопасность приложения.
- Скопировать европейский DPA без саудовской правовой привязки.
- Перевести интерфейс, но оставить ошибки, письма, consent и поддержку на английском.
- Отложить VAT и withholding до первого инвойса.
- Использовать reseller для сокрытия реального поставщика, обработки или платежа.
Когда нужен лицензированный специалист
До любого production-пилота с персональными данными; при cross-border access, sensitive/health/financial data, AI training, cloud/cybersecurity service, государственном или регулируемом клиенте; при учреждении, налоге и нестандартном платеже. Нужны саудовский лицензированный юрист, специалист по PDPL/SDAIA, CST/отраслевой консультант, налоговый adviser и независимый security reviewer. Санкционный и экспортный юрист оценивает каждую применимую юрисдикцию.
Вопросы руководителя
Все ли данные саудовского клиента обязаны храниться в Саудовской Аравии?
Универсального ответа нет. Имеют значение категория данных, сектор, клиент, PDPL transfer rules, NCA/CST и договор. Не подменяйте юридическое требование корпоративным предпочтением и наоборот.
Если hyperscaler зарегистрирован, нужна ли регистрация SaaS-компании?
Статус инфраструктурного поставщика не решает автоматически статус вашего сервиса. Фактические функции и Cloud Computing Regulations должен оценить специалист.
Можно ли поддерживать клиента из другой страны?
Только после анализа доступа как обработки/передачи, санкций, экспортного контроля, трудового/налогового присутствия и мер безопасности. Доступ должен быть минимальным, утвержденным, журналируемым и отзываемым.
Нужна ли саудовская компания для первого контракта?
Зависит от деятельности, клиента, закупки, персонала, регулирования и налога. Дистанционная продажа не означает отсутствие саудовских обязательств; учреждение не решает несоответствие продукта.
Вывод для руководства
До продаж утвердите не только pitch, но и сервисную архитектуру: роли, данные, страны, CST/NCA, доказательства безопасности, договор, налог и поддержку. Проведите 100-дневный ограниченный путь от synthetic discovery до платного пилота. Надежный SaaS в Саудовской Аравии — это не интерфейс над облаком, а проверяемая система ответственности, которая остается понятной при инциденте, аудите и выходе клиента.
Официальные и первичные источники
Дата доступа и отсечения источников: 2026-07-14. Регуляторные версии и применимость необходимо перепроверять перед пилотом и каждым существенным изменением архитектуры.
- Saudi Data & AI Authority, Personal Data Protection Law.
- SDAIA Data Governance Platform, PDPL Implementing Regulation.
- SDAIA, Guidelines for Binding Common Rules for Personal Data Transfer.
- Communications, Space & Technology Commission, Cloud Computing Service Provisioning Regulations decision.
- CST, Guide for Cloud Computing Service Providers.
- National Cybersecurity Authority, Cloud Cybersecurity Controls CCC–2:2024.
- Saudi Business Center, Establishment of Company under Investment Registration Certificate.
- ZATCA, Digital Economy VAT Guide.
- ZATCA, tax services for VAT, withholding tax and interpretative rulings.