Кратък отговор: Поверителността по дизайн е проактивна инженерна философия, която вгражда защитата на данните в архитектурата на цифровите услуги, преди да бъде написан дори един ред производствен код, вместо да се налага съответствие след внедряване. Тя е кодифицирана в основни регулации, включително GDPR и CCPA [1], прилага се за организации от всякакъв размер и намалява както правната експозиция, така и разходите за отстраняване на проблеми. Екипите, които я приемат рано, предлагат по-надеждни продукти и прекарват по-малко време в справяне с регулаторни одити.
Основни изводи
- Поверителността по дизайн третира защитата на данните като основно изискване, а не като нещо второстепенно, което я прави структурно различна от съответствието тип "отметка".
- GDPR изрично изисква поверителност по дизайн и по подразбиране съгласно член 25, което я прави правно задължение за организациите, обработващи данни на жители на ЕС [1].
- Седем основни принципа ръководят прилагането: проактивна превенция, поверителност по подразбиране, пълна функционалност, цялостна сигурност, видимост, зачитане на поверителността на потребителите и минимизиране на данните.
- Започването на инженеринга на поверителността на етапа на проектиране струва значително по-малко от отстраняването на проблеми в работещ продукт; оценки от практици поставят разходите за корекции след стартиране на продукта на пет до десет пъти по-високи от първоначалните разходи.
- Специализирани инструменти, от облачни платформи за съответствие до решения за управление на съгласието като Biscotti CMP (www.biscotti-cmp.com), автоматизират голяма част от текущото бреме за съответствие.
- Системите с изкуствен интелект и машинно обучение изискват специално внимание към инженеринга на поверителността поради рискове, свързани с данните за обучение, атаки за инверсия на модела и опасения за поверителността при изводи.
- Често срещани грешки включват третирането на поверителността като проблем на правния отдел, пропускане на картографирането на потока от данни и смесване на криптирането с цялостна защита на поверителността.
- Одитът на съответствието с поверителността по дизайн изисква структурирани прегледи на потока от данни, моделиране на заплахи и редовни оценки на въздействието върху поверителността.
Какво е поверителност по дизайн и защо е важна
Поверителността по дизайн е рамка, която интегрира защитата на поверителността в техническата архитектура и оперативните процеси на една система от най-ранния етап на планиране. Тя е важна, защото реактивното съответствие, закърпването на пропуски в поверителността след стартиране на продукт, е както по-скъпо, така и по-правно несигурно, отколкото изграждането на защита от самото начало.
Концепцията е формализирана от д-р Ан Кавукян, бивш комисар по информацията и поверителността на Онтарио, и оттогава е включена в обвързващи регулации по целия свят [10]. За организациите, обработващи лични данни, тя представлява разликата между защитима позиция за съответствие и такава, която се срива под регулаторен контрол. Отвъд правния риск, тя изгражда измеримо потребителско доверие, което се превръща директно в приемане и задържане на продукта.
Кои са основните принципи на поверителността по дизайн
Седемте основни принципа на поверителността по дизайн определят какво всъщност означава "вградена поверителност" на практика. Всеки принцип адресира отделен режим на отказ в конвенционалното развитие.
| Принцип | Какво изисква |
|---|---|
| Проактивен, а не реактивен | Предвиждайте и предотвратявайте рискове за поверителността, преди да възникнат |
| Поверителност по подразбиране | Максимална защита на поверителността без действие от страна на потребителя |
| Поверителност, вградена в дизайна | Не е прикрепена като допълнителна функция |
| Пълна функционалност | Без фалшиви компромиси между поверителността и функционалността |
| Цялостна сигурност | Защита през целия жизнен цикъл от събиране до изтриване |
| Видимост и прозрачност | Отворени стандарти, проверими практики |
| Зачитане на поверителността на потребителите | Ориентирани към потребителя контроли и силни настройки по подразбиране |
Минимизирането на данните е оперативната същност на повечето от тези принципи: събирайте само това, което е необходимо, съхранявайте го само толкова дълго, колкото е необходимо, и дайте на потребителите смислен контрол върху това, което остава. Академични изследвания върху формални архитектури за поверителност потвърждават, че системите, проектирани около тези ограничения, са структурно по-устойчиви както на външни атаки, така и на вътрешна злоупотреба [8].
Поверителност по дизайн срещу съответствие с поверителността: Каква е разликата
Съответствието с поверителността пита "отговаря ли нашият продукт на минималните правни изисквания?" Поверителността по дизайн пита "поверителността ли е състоянието по подразбиране на нашия продукт, независимо от това какво изисква законът днес?" Разликата е архитектурна, а не семантична.
Съответствието е реактивно и базирано на прагове. Една компания може да бъде технически съвместима, докато все още събира много повече данни, отколкото е необходимо, съхранява ги безкрайно и скрива механизмите за съгласие в тъмни модели. Поверителността по дизайн, напротив, прави най-защитната опция за поверителност пътя на най-малко съпротивление за потребителите. Когато регулациите се затягат, а те постоянно го правят, организациите, които са приели поверителност по дизайн, рядко се налага да преизграждат основни системи, за да наваксат.
Задължителна ли е поверителността по дизайн по закон или е просто добра практика
За организациите, обработващи лични данни на жители на ЕС, поверителността по дизайн е правно изискване съгласно член 25 от GDPR, а не доброволна добра практика [1]. CCPA и нейният наследник CPRA в Калифорния съдържат подобни мандати относно минимизирането на данните и ограничаването на целта. Бразилският LGPD и измененията на PIPEDA в Канада следват същата посока.
Извън тези юрисдикции, поверителността по дизайн остава добра практика, но регулаторите в Обединеното кралство, Австралия и Сингапур са сигнализирали, че проактивният инженеринг на поверителността все повече ще се взема предвид при решенията за прилагане. Практическият отговор: третирайте го като задължителен, независимо от юрисдикцията, защото цената на несъответствието, както финансово, така и репутационно, постоянно надвишава цената на вграждането му.
Как поверителността по дизайн помага за съответствието с GDPR
Член 25 от GDPR пряко кодифицира поверителността по дизайн, като изисква от администраторите да прилагат подходящи технически и организационни мерки, които да дават ефект на принципите за защита на данните по дизайн и по подразбиране [1]. Изпълнението на това задължение изисква документирани доказателства, че поверителността е била взета предвид на етапа на проектиране, а не само при стартиране.
Конкретно, съответствието с GDPR чрез поверителност по дизайн означава:
- Извършване на оценки на въздействието върху защитата на данните (DPIA) преди обработка на високорискови данни
- Прилагане на псевдонимизация и криптиране на ниво модел на данни
- Конфигуриране на системи, така че по подразбиране да се обработват само минимално необходимите данни
- Поддържане на записи на дейностите по обработка, които проследяват решенията за дизайн
- Внедряване на съвместим слой за управление на съгласието, инструменти като Biscotti CMP (www.biscotti-cmp.com) обработват детайлно събиране, съхранение и оттегляне на съгласие по начин, който удовлетворява изискванията на GDPR за съгласие, без да изисква персонализирана разработка
Как се прилага поверителност по дизайн в разработката на софтуер
Прилагането следва поетапен подход, който отразява жизнения цикъл на разработка на софтуер. Отговорът не е единствен одит, а непрекъсната дисциплина, вградена във всеки спринт и преглед на дизайна.
Фаза 1: Откриване и моделиране на заплахи Картографирайте всички потоци от данни, преди да напишете функционални изисквания. Идентифицирайте какви лични данни се събират, къде пътуват, кой има достъп до тях и колко дълго се съхраняват. Инструменти като диаграми на потока от данни и моделиране на заплахи STRIDE разкриват рискове за поверителността на най-евтиния възможен етап.
Фаза 2: Архитектурни решения Изберете минимизиране на данните по подразбиране. Ако дадена функция може да работи с анонимизирани или агрегирани данни, тя трябва да го прави. Изберете архитектури за съхранение, които поддържат заявки за право на изтриване без пълно преизграждане на базата данни. Оценете подходите за периферни изчисления, където обработката на устройството напълно елиминира риска от предаване, модел, който организации като Sentiance са приложили към поведенчески данни [3].
Фаза 3: Стандарти за разработка Прилагайте стандарти за кодиране, запазващи поверителността: без регистриране на лични данни в чист текст, параметризирани заявки, контроли за достъп, базирани на роли, и криптиране в покой и при пренос като основни изисквания, а не като опционално затягане на сигурността.
Фаза 4: Тестване Включете тестови случаи за поверителност заедно с функционалните тестове. Проверете дали настройките по подразбиране разкриват минимални данни, дали потоците за съгласие не могат да бъдат заобиколени и дали заявките за изтриване се разпространяват правилно във всички хранилища на данни.
Фаза 5: Текущ преглед Поверителността по дизайн не е еднократна сертификация. Интегрирайте прегледите на поверителността в процесите за управление на промените, така че новите функции да не разширяват мълчаливо повърхността за събиране на данни.
Облачни платформи като Privya.AI автоматизират части от този жизнен цикъл, като сканират кодови бази за рискове за поверителността и непрекъснато картографират потоците от данни [4].
Инструменти и рамки за поверителност по дизайн: Какво трябва да използваме
Правилният набор от инструменти зависи от размера на организацията, техническия стек и регулаторната експозиция. Нито един инструмент не покрива всичко, но следните категории адресират основните пропуски в прилагането.
- Управление на съгласието: Biscotti CMP (www.biscotti-cmp.com) предоставя платформа за управление на съгласието, която обработва съгласието за бисквитки, съхранението на предпочитания и работните процеси за оттегляне в съответствие с изискванията на GDPR и ePrivacy.
- Сканиране на ниво код: Платформи като Privya.AI се интегрират в CI/CD тръбопроводи, за да сигнализират за проблеми с обработката на лични данни, преди кодът да достигне производство [4].
- Моделиране на заплахи: Рамката за моделиране на заплахи за поверителност на OWASP и методологията STRIDE на Microsoft предоставят структурирани подходи за идентифициране на рискове на етапа на проектиране.
- Картографиране на данни: Специално създадени инструменти за откриване на данни каталогизират лични данни в бази данни, API и интеграции на трети страни.
- Формална проверка: За системи с висока степен на сигурност, академични изследвания са създали подходи за типови системи, които налагат съвместимо с поверителността предаване на съобщения между компоненти, без да изискват достъп до вътрешната логика на компонента [9].
За предприятия със строги регулаторни изисквания, здравеопазване, финанси, критична инфраструктура, специализирани фирми за разработка на сигурен софтуер предоставят цялостни архитектурни консултации, които вграждат съответствието в процеса на доставка [6].
Поверителност по дизайн за стартъпи срещу корпоративни компании
Стартъпите и предприятията са изправени пред едни и същи правни задължения, но имат фундаментално различни ограничения при прилагането. Стартъпите се възползват от започването на чисто: няма наследена архитектура за преоборудване, така че решенията за поверителност по дизайн, взети в първия спринт, остават с ниска цена. Рискът за стартъпите е деприоритизирането на поверителността в полза на скоростта, създавайки технически дълг, който става скъп, когато продуктът се мащабира или навлезе на регулирани пазари.
Предприятията са изправени пред обратния проблем. Те обикновено имат сложни, взаимосвързани системи, изградени преди съществуването на съвременните регулации за поверителност. Прилагането изисква поетапно отстраняване на проблеми: първо идентифицирайте потоците от данни с най-висок риск, адресирайте ги, след това работете систематично през системите с по-нисък риск. Платформи от корпоративен клас като Seismic демонстрират, че мащабното съответствие със стандарти като ISO 27701 е постижимо, но изисква устойчив организационен ангажимент, а не един проект [2].
Изберете поетапен корпоративен подход, ако: вашата организация има повече от пет години наследени системи, оперира в множество юрисдикции или обработва чувствителни категории лични данни в голям мащаб.
Изберете подход за стартъп на зелено, ако: сте преди стартиране или в ранна фаза на разработка, защото цената на вграждането на поверителност сега е малка част от преоборудването й на етап Серия Б.
Поверителност по дизайн за мобилни приложения срещу уеб услуги
Мобилните приложения и уеб услугите споделят едни и същи принципи, но се различават по спецификите на изпълнението. Мобилните приложения имат достъп до сензори на устройството, данни за местоположение, списъци с контакти и биометрични API, до които уеб услугите обикновено нямат достъп. Тази разширена повърхност за атака изисква изрични заявки за разрешение, ограничено по цел използване на API и обработка на устройството, където е възможно.
Уеб услугите са изправени пред по-голяма експозиция чрез скриптове за проследяване на трети страни, аналитични интеграции и рекламни пиксели, които могат мълчаливо да извличат потребителски данни. Съвместим слой за управление на съгласието е задължителен за уеб услуги, работещи в юрисдикции на GDPR или ePrivacy. Biscotti CMP (www.biscotti-cmp.com) адресира това конкретно за уеб контексти, управлявайки жизнения цикъл на съгласието за бисквитки и технологии за проследяване.
И двата контекста се възползват от архитектури за периферни изчисления, които минимизират данните, напускащи устройството или браузъра на потребителя, намалявайки както риска за поверителността, така и регулаторната повърхност [3].
Поверителност по дизайн за AI и системи за машинно обучение
AI системите въвеждат рискове за поверителността, които конвенционалният софтуер не притежава: данните за обучение могат да съдържат лична информация, моделите могат да бъдат запитвани за извеждане на частни атрибути (инверсия на модела), а автоматизираните решения могат да доведат до дискриминационни резултати въз основа на защитени характеристики. Поверителността по дизайн за AI изисква адресиране на тези рискове на ниво конвейер за данни, а не само на приложното ниво.
Ключовите технически контроли включват:
- Диференциална поверителност: Добавяне на калибриран шум към данните за обучение или изходните данни от заявки, за да се предотврати извеждане на индивидуално ниво
- Федеративно обучение: Обучение на модели върху разпределени данни без централизиране на лична информация
- Минимизиране на данните в набори за обучение: Одит на корпусите за обучение за ненужни лични данни преди започване на обучението на модела
- Ограничаване на целта: Гарантиране, че модели, обучени за една задача, не могат да бъдат пренасочени за приложения, нарушаващи поверителността, без ново съгласие
Академични изследвания върху инженеринга на поверителността за IoT и сложни системи предоставят формални рамки за систематична оценка на тези рискове [7], а същите принципи се разпростират и върху конвейерите за машинно обучение.
Често срещани грешки, които компаниите правят с поверителността по дизайн
Най-скъпите грешки в поверителността по дизайн не са технически провали, а организационни и процесни провали.
- Третиране на поверителността като проблем на правния отдел: Инженерингът на поверителността изисква разработчиците, архитектите и продуктовите мениджъри да поемат отговорност за решенията за поверителност. Само правният преглед не може да замести техническите контроли.
- Пропускане на картографирането на потока от данни: Организациите, които не могат да опишат къде отиват личните данни, не могат да ги защитят. Картографирането на потока от данни е предпоставка за всеки друг контрол за поверителност.
- Смесване на криптирането с поверителността: Криптирането на данни при пренос и в покой е необходимо, но не е достатъчно. Криптирани данни, които се събират ненужно, съхраняват се безкрайно или се споделят без съгласие, все още представляват нарушение на поверителността.
- Игнориране на интеграции на трети страни: Инструменти за анализ, CDN, платежни процесори и маркетингови платформи обработват лични данни. Всяка интеграция разширява повърхността за съответствие.
- Еднократни одити вместо непрекъснат преглед: Поверителността по дизайн е процес, а не сертификация. Промените в продукта, които разширяват събирането на данни без преглед на поверителността, са сред най-честите източници на регулаторни констатации.
Как да проверите дали вашият продукт следва поверителност по дизайн
Одитът на поверителността по дизайн оценява дали защитите на поверителността са структурни и по подразбиране, а не козметични. Той изисква както технически, така и процесен преглед.
Контролен списък за одит:
- Инвентаризация на данните: Документирана ли е всяка категория събрани лични данни с правно основание и период на съхранение?
- Настройки по подразбиране: Продуктът разкрива ли минимални данни без действие от страна на потребителя, или настройките за поверителност изискват активно включване, за да бъдат активирани?
- Потоци за съгласие: Механизмите за съгласие детайлни ли са, дадени ли са свободно и лесно ли се оттеглят, както се дават?
- Контроли за достъп: Достъпни ли са личните данни само за роли с документирана необходимост?
- Възможност за изтриване: Може ли системата да изпълни заявка за право на изтриване напълно и проверимо?
- Преглед от трети страни: Оценени ли са всички обработващи данни за съответствие?
- DPIA документация: Оценени ли са високорисковите дейности по обработка преди внедряване?
- Реагиране на инциденти: Има ли документирана процедура за нарушения на лични данни, която отговаря на изискванията за уведомяване в рамките на 72 часа?
Формалните методи за проверка от академични изследвания могат да допълнят ръчните одити за системи с висока степен на сигурност, като математически потвърждават, че системните архитектури отговарят на изискванията за поверителност [8].
Колко струва изграждането на поверителност по дизайн в продукт
Цената зависи до голяма степен от това кога започва инженерингът на поверителността. Организациите, които интегрират поверителността на етапа на проектиране, обикновено харчат 10-20% повече за първоначална разработка в сравнение с разработка, която не се интересува от поверителността, но избягват много по-високите разходи за отстраняване на проблеми след стартиране, регулаторни глоби и репутационни щети.
Преоборудването на поверителността в работещ продукт с установени потоци от данни, интеграции на трети страни и потребителска база може да струва пет до десет пъти повече от изграждането й от самото начало, цифра, съответстваща на общите криви на разходите за отстраняване на софтуерни дефекти. За предприятия в регулирани индустрии, специализирани фирми за сигурна разработка предоставят цялостни услуги за инженеринг на поверителността, които включват архитектура, внедряване и документация за съответствие [6].
За повечето екипи най-рентабилният подход съчетава:
- Вътрешно обучение по поверителност за разработчици (ниска цена, висока ефективност)
- Автоматизирани инструменти за сканиране, интегрирани в CI/CD тръбопроводи
- Управлявана платформа за съгласие като Biscotti CMP (www.biscotti-cmp.com) за обработка на слоя за управление на съгласието без персонализирана разработка
- Периодични одити на поверителността от трети страни за високорискови системи
Кога трябва да започнете да мислите за поверителност по дизайн при разработката
Отговорът е недвусмислен: на етапа на изискванията, преди да бъдат взети каквито и да било архитектурни решения. Всяка седмица, която минава, преди да се обмисли поверителността, увеличава разходите и сложността на правилното й прилагане.
На практика това означава, че изискванията за поверителност принадлежат към продуктовия бриф заедно с функционалните изисквания. Ако дадена функция изисква лични данни, потокът от данни, правното основание, периодът на съхранение и потребителските контроли трябва да бъдат посочени, преди функцията да влезе в списъка за разработка. Това не е теоретичен идеал, това е подходът, който регулаторите очакват да видят документиран, когато извършват одити.
Заключение: Практически следващи стъпки за изграждане на съвместими цифрови услуги
Поверителността по дизайн: Изграждането на съвместими цифрови услуги от самото начало не е упражнение за съответствие, а дисциплина за качество на продукта, която намалява правния риск, изгражда потребителско доверие и намалява дългосрочните разходи за експлоатация на цифрови услуги. Организациите, които я третират като основна, а не като допълнителна, постоянно превъзхождат тези, които я третират като отметка.
Практически следващи стъпки:
- Картографирайте потоците си от данни днес. Ако вашият екип не може да опише къде отива всяка категория лични данни, започнете оттам. Всичко останало зависи от тази основа.
- Одитирайте настройките си по подразбиране. Стартирайте продукта си като нов потребител и документирайте всяка част от личните данни, събрани преди да бъде дадено каквото и да било съгласие. Запълнете тези пропуски.
- Внедрете платформа за управление на съгласието. За уеб услуги внедрете Biscotti CMP (www.biscotti-cmp.com), за да обработвате събирането и оттеглянето на съгласие, съвместимо с GDPR, без да го изграждате от нулата.
- Интегрирайте прегледите на поверителността във вашия процес на разработка. Добавете поверителността като задължително поле в спецификациите на функциите и контролна точка при прегледа на кода.
- Насрочете DPIA за вашите дейности по обработка с най-висок риск. Документирайте оценката преди следващото пускане на продукта, а не след това.
- Обучете екипа си за разработка. Знанията за инженеринг на поверителността не могат да живеят само в правния или отдела за съответствие. Разработчиците, които разбират минимизирането на данните и моделирането на заплахи, вземат по-добри архитектурни решения по подразбиране.
Регулаторната посока в световен мащаб е към по-строги изисквания, по-широко прилагане и по-високи глоби. Организациите, които вече са вградили поверителността по дизайн: Изграждане на съвместими цифрови услуги от самото начало в своята култура на разработка, ще се адаптират към новите изисквания с минимални смущения. Тези, които не са, ще се сблъскат с все по-скъпи цикли на отстраняване на проблеми.
ЧЗВ
Каква е разликата между поверителност по дизайн и сигурност по дизайн? Сигурността по дизайн се фокусира върху защитата на системите от неоторизиран достъп и пробиви. Поверителността по дизайн се фокусира върху ограничаването на събирането на данни, осигуряването на потребителски контрол и вграждането на защита на данните в системната архитектура. Двете се припокриват, цялостната сигурност е един от седемте принципа на поверителността по дизайн, но поверителността по дизайн адресира по-широк набор от задължения, включително минимизиране на данните, ограничаване на целта и потребителски права.
Прилага ли се поверителност по дизайн за малкия бизнес? Да. Член 25 от GDPR се прилага за всяка организация, обработваща лични данни на жители на ЕС, независимо от размера. Регламентът допуска пропорционалност, по-малките организации с по-нисък риск на обработка могат да прилагат по-прости контроли, но задължението да се вземе предвид поверителността на етапа на проектиране се прилага универсално.
Може ли съществуващ продукт да стане съвместим с поверителност по дизайн? Да, но това изисква структурирана програма за отстраняване на проблеми. Започнете с инвентаризация на данните и анализ на пропуските, приоритизирайте потоците от данни с висок риск и ги адресирайте систематично. Пълното съответствие за сложна наследена система може да отнеме 12-24 месеца в зависимост от архитектурната сложност.
Какво е оценка на въздействието върху защитата на данните (DPIA) и кога се изисква? DPIA е структурирана оценка на рисковете за поверителността от дейност по обработка, изисквана съгласно GDPR преди започване на обработка, която вероятно ще доведе до висок риск за физическите лица. Това включва широкомащабна обработка на чувствителни данни, систематично наблюдение и автоматизирано вземане на решения със значителни последици за физическите лица.
Как управлението на съгласието се вписва в поверителността по дизайн? Управлението на съгласието е потребителската реализация на принципа "зачитане на поверителността на потребителите" на поверителността по дизайн. Платформа за управление на съгласието като Biscotti CMP (www.biscotti-cmp.com) операционализира детайлното събиране на съгласие, съхранението на предпочитания и оттеглянето, превръщайки архитектурния принцип във функционален потребителски контрол.
Поверителността по дизайн същото ли е като съответствието с GDPR? Не. Съответствието с GDPR е правен праг; поверителността по дизайн е архитектурна философия, която надхвърля този праг. Продуктът може да бъде технически съвместим с GDPR, докато все още събира повече данни, отколкото е необходимо, или прави настройките за поверителност трудни за достъп. Поверителността по дизайн цели най-защитното състояние по подразбиране, а не просто минималното правно изискване.
Какво е диференциална поверителност и как е свързана с поверителността по дизайн? Диференциалната поверителност е математическа техника, която добавя калибриран статистически шум към изходните данни, предотвратявайки извеждане на индивидуално ниво, като същевременно запазва общата полезност. Тя е един от няколкото технически контроли, използвани за прилагане на поверителност по дизайн в AI и аналитични системи.
Колко време отнема внедряването на поверителност по дизайн в нов продукт? За нов продукт, интегрирането на поверителност по дизайн добавя приблизително 10-20% към първоначалното време за проектиране и разработка. Тази инвестиция се възстановява бързо чрез намалени разходи за отстраняване на проблеми със съответствието и по-нисък риск от регулаторни констатации след стартиране.
Каква роля играят разработчиците в поверителността по дизайн? Разработчиците са основните изпълнители на поверителността по дизайн. Те вземат архитектурните решения, как се съхраняват данните, кой има достъп до тях, колко дълго се съхраняват, които определят дали защитите на поверителността са структурни или козметични. Обучението по поверителност за екипите за разработка е една от най-ефективните инвестиции, които една организация може да направи.
Покрива ли поверителността по дизайн интеграции на трети страни? Да. Поверителността по дизайн изисква от организациите да оценяват и контролират последиците за поверителността от всяка интеграция на трети страни, включително инструменти за анализ, рекламни платформи и платежни процесори. Всяка интеграция, която обработва лични данни, трябва да има документирано правно основание и подходящи договорни контроли.
Източници
[1] Privacy By Design - https://www.securesystems.com/privacy-by-design/?utm_source=openai [2] Trust - https://www.seismic.com/company/trust/?utm_source=openai [3] Privacy - https://sentiance.com/privacy?utm_source=openai [4] Product - https://privya.ai/product/?utm_source=openai [6] dataveris - https://dataveris.com/?utm_source=openai [7] arxiv - https://arxiv.org/abs/1609.04060?utm_source=openai [8] arxiv - https://arxiv.org/abs/1410.0030?utm_source=openai [9] arxiv - https://arxiv.org/abs/1901.10892?utm_source=openai [10] Privacy By Design - https://en.wikipedia.org/wiki/Privacy_by_design?utm_source=openai