Съдържание show

Съвместимо ли е решението inSign с местното законодателство?

Да. inSign е съвместим с изискванията за електронен подпис съгласно регламента eIDAS (ЕС № 910/2014). Електронният подпис не следва да бъде отхвърлян единствено поради електронната си форма при доказване на автентичност.

Какви типове документи могат да се подписват с inSign?

Освен PDF, могат да се подписват и други формати (напр. изображения/снимки). След подписване документът се конвертира в PDF, като се включват сертификати и криптирани биометрични данни.

Възможна ли е злоупотреба с inSign подписа в системата?

Защитата включва асиметрично криптиране и разделяне на ключовете. Частният ключ се съхранява от независима трета страна (напр. нотариус), която няма достъп до подписаните документи.

Кои устройства могат да се използват с inSign? Има ли технологични ограничения?

Подписването е възможно на сензорно устройство (смартфон, таблет или лаптоп със сензорен екран). Подпис с мишка е възможен, когато не се изисква събиране на биометрични данни.

Какво трябва да се направи, за да започне един бизнес да използва inSign?

Първата стъпка е контакт с представител. Екипът представя детайлите на решението и най-подходящия модел за внедряване спрямо вашия процес и обем документи.

Свържете се с нас

Как се настройва ценовата листа на услугата inSign?

Ценообразуването е според модела на използване и очаквания брой транзакции/подписи. За точна оферта е нужен кратък контекст: обеми, сценарии (вътрешно/клиентско подписване), интеграции и изисквания за хостинг.

Запитване за цена

Какви са възможностите за инсталиране? Само SaaS ли е или има и on-premise?

Възможни са: SaaS (центрове за данни в Германия/Швейцария/друга държава в ЕС) или изпълнение on-premise/в собствен облак на клиента, според регулаторни и ИТ изисквания.

Безопасни ли са центровете за данни при избор на SaaS услуга?

Да. Центровете за данни са защитени и се проверяват регулярно, с покритие на стандарти за сигурност (напр. ISO 27001). Хостингът може да бъде в Германия (данните остават в ЕС), а при изискване – и в Швейцария или друга държава в ЕС.

Казус 1: Как CLOUD Act влиза в директен конфликт с GDPR (чл. 48) – и защо това е „правен капан“?

CLOUD Act (2018) позволява американските власти да изискват данни от US компании независимо къде физически са съхранени (дори в ЕС). GDPR обаче казва, че чужди съдебни разпореждания се признават само при международно споразумение (чл. 48). Резултат: директен сблъсък. :contentReference[oaicite:3]{index=3}

Отговор (в пълен мащаб)

Как изглежда конфликтът – „просто обяснено“

  • GDPR: чужди заповеди са валидни само при международно споразумение (чл. 48).
  • CLOUD Act: US компанията е длъжна да даде данни при валидна US заповед, дори ако данните са в ЕС.
  • Проблемът: US компанията може да е задължена да наруши GDPR, за да изпълни US право („Catch-22“).

Защо „EU hosting“ сам по себе си НЕ решава проблема

Ако данните са „под контрола“ на US компания, локацията (Ирландия/Германия) не елиминира CLOUD Act експозицията. Това е причината „EU-only region“ да е само частично смекчаване, не пълно решение. :contentReference[oaicite:4]{index=4}

Практическа препратка

Виж също: Казус 3 (Schrems II) – „essential equivalence“ и защо US surveillance режимът е ключов.

Казус 2: Защо USA PATRIOT Act (и FISA 702/EO 12333) са проблем за GDPR и европейските права?

PATRIOT Act е „старият“ проблем след 9/11, а CLOUD Act е „новият“ проблем за облака. И двата са част от US surveillance режима, който ЕС критикува заради липса на пропорционалност и ефективна защита за не-американци. :contentReference[oaicite:5]{index=5}

Отговор (в пълен мащаб)

PATRIOT Act vs CLOUD Act – най-важната разлика

  • PATRIOT Act: по-общ режим за национална сигурност и разширен surveillance след 9/11.
  • CLOUD Act: конкретно за облачни/електронни данни и „extraterritorial“ достъп.
  • Ефект в ЕС: за чужденци (европейци) защитата/редресът е ограничена → конфликт с GDPR философията.

Виж и: Казус 4 (DPF) – опит за временна „стабилизация“ на трансферите. :contentReference[oaicite:6]{index=6}

Казус 3: Какво реално означава Schrems II (16.07.2020) за бизнес, който ползва US доставчици?

Schrems II е решението, което свали Privacy Shield и постави изискване за оценка „case-by-case“ (TIA) и допълнителни мерки, когато местното право на импортера (напр. САЩ) позволява непропорционален достъп. :contentReference[oaicite:7]{index=7}

Отговор (в пълен мащаб)

Ключови изводи за мениджмънт

  • Privacy Shield падна → трансфери без адекватни гаранции стават незаконни.
  • SCC остават, но не „автоматично“ – трябва TIA и реални допълнителни мерки.
  • Ако няма ефективни мерки (напр. provider-ът държи ключовете) → трансферът трябва да се спре.

Виж: Казус 7 (Мерки и реална защита).

Казус 4: Какво е EU-US Data Privacy Framework (DPF) и защо е „временна стабилност“, не гаранция?

DPF е adequacy механизъм (2023), който позволява трансфери към сертифицирани US компании. Към февруари 2026 г. е в сила, но е под натиск (съдебни тестове и риск от следващ „Schrems“). :contentReference[oaicite:8]{index=8}

Отговор (в пълен мащаб)

Как работи (съкратено, но пълно като логика)

  • US компанията се само-сертифицира към DPF (Department of Commerce).
  • Има механизъм за жалби чрез Data Protection Review Court (DPRC).
  • DPF стъпва върху Executive Order 14086 (ограничения за bulk collection, redress механизъм).

Къде остава рискът

  • DPF зависи от US политика и устойчивостта на надзорните механизми.
  • Част от експертите го смятат „крехък“ – подобно на Safe Harbor и Privacy Shield в миналото. :contentReference[oaicite:9]{index=9}

Виж и: Казус 5 (Latombe) и Казус 6 (Schrems III).

Казус 5: Какво се случи по делото Latombe (03.09.2025) и защо апелът (31.10.2025) е важен?

През 2025 г. EU General Court отхвърля жалбата срещу DPF (03.09.2025), но има апел към CJEU (31.10.2025), което държи темата „отворена“. :contentReference[oaicite:10]{index=10}

Отговор (в пълен мащаб)
  • 03.09.2025: General Court потвърждава DPF (засега) – приема, че DPRC и safeguards са достатъчни.
  • 31.10.2025: подаден апел към CJEU – очакван хоризонт за решение 2026–2027.
  • Риск: CJEU исторически е по-строг (Schrems I & II) → възможен обрат.

Виж: Казус 6 (Schrems III) – защо всички очакват следващата атака.

Казус 6: Има ли „Schrems III“ към февруари 2026 г. и какъв е реалният риск за бизнеса?

Към февруари 2026 г. няма официално решение „Schrems III“, но има висока несигурност: DPF е атакуван/тестван, а експерти очакват ново дело или обрат на CJEU. :contentReference[oaicite:11]{index=11}

Отговор (в пълен мащаб)

Какво значи това практично

  • Ако CJEU отмени DPF → връщане към SCC + строги TIA + допълнителни мерки, иначе риск от глоби.
  • Чувствителни отрасли (финанси, публичен сектор, здраве) все по-често избягват чист US cloud за критични данни.

Виж: Казус 7 (Мерки) – как да структурирате риска договорно и технически.

Казус 7: Какво работи на практика за намаляване на риска (и кое е само маркетинг)?

Повечето организации комбинират правни и технически мерки, но „суверенен cloud“ маркетингът не елиминира автоматично CLOUD Act експозицията, ако доставчикът е US-based. :contentReference[oaicite:12]{index=12}

Отговор (в пълен мащаб)

Най-често използвани мерки (не 100% сигурни)

  • SCC + TIA: оценка „case-by-case“ + документиране на риска.
  • Customer-managed keys / zero-knowledge: криптиране, при което доставчикът няма ключ.
  • EU-only regions: помага, но не решава CLOUD Act самостоятелно.
  • Алтернативи: европейски доставчици или реални суверенни решения (в зависимост от случая).

Критичната истина (за executive management)

Ако доставчикът може да декриптира данните или има административен контрол върху ключовете, това често е недостатъчно за „high-risk“ сценарии. Затова оценката трябва да е на ниво процес + данни + контрол на ключовете, не само „къде са сървърите“. :contentReference[oaicite:13]{index=13}

Виж назад: Казус 1 (CLOUD Act) и Казус 3 (Schrems II).

Executive summary: как да вземете решение (без самоизмама и без юридически риск)

Ако сте в регулиран сектор или подписвате документи с правна/финансова тежест, рискът при чисто US-базирани доставчици не е „теоретичен“. Той е комбинация от конфликт на юрисдикции, изисквания по GDPR и очаквания за контрол и отчетност (особено при финансови и публични организации).

  • Високорисков сценарий: чувствителни данни (финанси, кредитиране, публични услуги) + доставчик под US юрисдикция + доставчикът може да достъпва/декриптира съдържание или ключове. Виж: CLOUD Act и Schrems II.
  • DPF не е „пожизнена застраховка“: може да е валиден механизъм, но остава съдебен и регулаторен риск, който бизнесът трябва да управлява (не да игнорира). Виж: DPF и Latombe (2025).
  • Реалната защита е архитектура + контрол: минимизиране на данните по процес, ясни роли и договори, реален контрол върху криптографските ключове (където е приложимо) и документирана оценка на трансфера (TIA). „EU region“ като маркетингов етикет без контрол на ключовете често е недостатъчен при висок риск. Виж: мерки за смекчаване.

Практично правило за решение: ако не можете уверено да отговорите „кой може да достъпва съдържанието и ключовете, при какви условия и под чия юрисдикция“, значи рискът е недостатъчно управляван.

Как това се адресира с inSign (ясно за бизнеса, без overpromising)

inSign е проектиран за европейски бизнес процеси и цели да намали юрисдикционния и оперативния риск чрез комбинация от разгръщане в ЕС, контролируеми архитектурни опции и ясни договорни рамки. Конкретната конфигурация зависи от вашия сектор, процес и класа данни.

  • EU hosting / избор на локация: опции за хостинг в европейска юрисдикция (според нуждите и регулаторните изисквания), така че данните да се обработват и съхраняват в рамка, която е по-предсказуема за GDPR-контекст.
  • Архитектурни опции за контрол: възможност за модели на внедряване, при които контролът и достъпът се управляват по-стриктно (например в корпоративна среда и/или при on-prem / private cloud сценарии, когато е релевантно).
  • Контрол и разделение на роли: ясна логика „кой прави какво“ (подписващ/организация/доставчик), така че да е по-лесно да защитите позицията си при вътрешен одит, регулаторен преглед или спор.
  • Договорна и процесна дисциплина: поддържими договорни рамки и процесни практики (например правила за достъп, логване, срокове за съхранение), които помагат да документално да докажете „due diligence“.
  • Интеграции: inSign може да бъде внедрен като част от процеса (портал/CRM/core системи), за да намали ръчните стъпки и да повиши контролируемостта на потока. Виж: /integrations/

Важно: никой доставчик не може да „обещае нулев юридически риск“ във всички сценарии. Това, което има значение за management, е дали рискът е идентифициран, намален и документиран с правилната комбинация от архитектура, процес и договори.

Ако искате конкретен отговор „какъв модел е подходящ за нас“, най-бързият начин е кратък разговор за вашия процес (обем, вид документи, сектор, нужда от интеграция, изисквания за хостинг). Поискайте демо/оценка.

Прочети повече тук: EUROPEAN DATA PROTECTION SUPERVISOR - EDPB-EDPS Joint Response on the US Cloud Act