cloud russia 2015 kpmg

Повышение доверия

к операторам

облачных услуг.

Аудит и

сертификация

CLOUD RUSSIA 2015: Будущее

российского рынка

Москва

16 апреля 2015

© 2015 АО «КПМГ», компания, зарегистрированная в соответствии с законодательством Российской Федерации, член сети независимых фирм КПМГ, входящих в ассоциацию KPMG

International Cooperative (“KPMG International”), зарегистрированную по законодательству Швейцарии. Все права защищены.

1

Содержание

Введение. Немного статистики

Стандарты и требования к информационной

безопасности

■ Обзор основных стандартов

■ Серия ISO 27000

■ ISO 22301

■ HIPAA

■ PCI DSS

■ 382-п

SOC-отчеты

■ Типы отчетов сервис-провайдера

■ Что входит в SOC2/3-отчет?

■ Какой отчет выбрать?

■ Какая информация входит в отчет?

■ Как выбрать домены SOC2/3-проверки?

■ Примеры использования

Введение.

Немного статистики



3

Безопасность – ключевой барьер перехода в облака

Провайдеры облачных технологий (SaaS, IaaS, PaaS) активнее других аутсорсеров предлагают рынку инновационные решения,

сервисы и инструменты, предоставляя ряд возможностей по сокращению издержек. Облачные технологии также играют значимую

роль при создании центров разделяемых сервисов. Популярность «облаков» растет, но, тем не менее, результаты опроса КПМГ в

мире показывают, что процесс перехода к таким технологиям протекает достаточно медленно.

В числе основных препятствий, названных респондентами, – риски, связанные с безопасностью и защитой персональных данных,

проблемы интеграции с существующими процессами и решениями, риски нарушения требований регуляторов. Боязнь подобных

рисков понятна, но ими вполне возможно управлять.

60%компаний тратят меньше 10% ИТ-

бюджета на облака

71%тратят меньше 20% ИТ-

бюджета на облака

28%

Местонахождение

данных – риски

безопасности и защиты

персональных данных

17%

Проблемы

интеграции с

существующей

операционной

моделью ИТ

16%

Опасения

несоответствия

регуляторным

требованиям

Источник: Глобальное исследование КПМГ (KPMG IT Outsourcing Service Provider Performance & Satisfaction Study 2014/15).

Затраты компаний на облачные технологии

растут не очень быстрыми темпами

Основные барьеры, препятствующие

инвестициям в облачные технологии

Введение




4

Стандартизация, оптимизация, комплайенс – ключевые

козыри сегодняшнего аутсорсинга

Насколько важны следующие преимущества для бизнеса, которые компания ожидает получить от текущих ИТ- и

бизнес-аутсорсеров в ближайшие два года?

Источник: Исследование HfS «Состояние аутсорсинга 2014», проведенное при поддержке КПМГ

Введение


Сегодняшняя

«повестка дня»

Ожидания на

завтра

Более стандартизированные процессы 22% 50% 21% 6%

Значительно меньшие операционные затраты (25%+) 27% 44% 24% 5%

Повышение уровня автоматизации 18% 51% 24% 7%

Гибкость в масштабировании бизнеса 28% 39% 23% 10%

Оптимизация бизнес-процессов 22% 45% 24% 10%

Соответствие регуляторным требованиям 37% 25% 25% 13%

Улучшенные аналитические отчеты 12% 48% 32% 9%

Доступ к знаниям и талантам 11% 48% 28% 13%

Доступ к новым технологиям 9% 47% 30% 13%

Возможность увеличения выручки 14% 33% 33% 20%

Увеличение и улучшение облачных сервисов 10% 29% 40% 20%

0% 25% 50% 75% 100%

Важно, но не критично Важно НеважноОткажусь от провайдера, если не

будет достигнуто



5

Беспокойства при переходе в облака достаточно просты

и даже наивны

Что больше всего беспокоит компанию при оценки возможности перехода на облачные решения?

Источник: Исследование HfS «Состояние аутсорсинга 2014», проведенное при поддержке КПМГ

Введение


30%

40%

41%

41%

46%

34%

33%

33%

7%

15%

15%

12%

16%

12%

12%

14%

Возможные трудности интеграции данных

между разными облачными приложениями

Не понятно, где физически находятся наши

данные

В случае возникновения ошибок, будет сложно

установить место возникновения и ответственность

Не ясны вопросы обеспечения


52% 28% 8% 13%Несовместимость данных в случае

миграции

22% 46% 15% 16%Недостаточная кастомизация под наши

цели

0 % 25 % 50 % 75 % 100 %

Очень беспокоит Несколько беспокоит Не беспокоит Не задумывались

Стандарты и

требования к

информационной




7

В центре внимания – защита информацииОсновные стандарты

Обзор

ISO 22301

HIPAA

ITIL

COBIT

COSOSSAE

ISAE

SOC

ISO 27002

ISO 21827

CMM

PCI

ANSI

ISO 20000

ISO 17799

WebTrust

SysTrust

SOX 404

FFIEC

ITGI

NIST

CISP

EV SSL

152-ФЗ

СТО БР ИББС

382-П

Таким образом, для ИТ-аутсорсинга на первое место выходят вопросы обеспечения безопасности, целостности, доступности,

конфиденциальности данных и соблюдения регуляторных требований. Эти вопросы затрагиваются целым рядом стандартов и

положений, в том числе специфичных для отдельных стран. К счастью, локальные стандарты и акты обычно базируются на

международных положениях, и, применяя передовые мировые практики, можно удовлетворить всем требованиям.

TIER



8

Многие стандарты сфокусированы на узком сегменте

информационной безопасностиОсновные стандарты

Обзор

Карта стандартов

Тип стандарта

Контрольная

среда

Информационная

безопасностьИТ-сервисы Разработка ПО

Системы

финансовой

отчетности

Специфические

требования к

технологиям

Лучшие

практики

COBIT

COSO ISO 27002

СТО БР

ITIL

ISO 20000-2

CMM/ISO 9001

ISO 21827

IT Controls / SOX ISO

ANSI

Сертификация/

критерии

аудита

ISO 27001

ISO 22301

ISO 20000-1

Требования

регуляторов/

индустрии

FFIEC

HIPAA, HITRUST

PCI

ISO 2700X

382-п

SOX

PCAOB

EV SSL

152-ФЗ

Аудиторский

подход

ISAE / SSAE

SysTrust

WebTrust

SOC2/SOC3

PCAOB WebTrust CA

WebTrust EV



9

Основная сертификация по информационной

безопасности не может набрать популярность в России

ISO/IEC 27001 – «Информационные

технологии. Методы обеспечения

безопасности. Системы управления

информационной безопасностью.

Требования»



безопасности. Практические правила

управления информационной

безопасностью»



безопасности. Управление рисками

информационной безопасности»

Требования к ИБ

Серия ISO 27000

4 210

8 788

9 665

10 42210 748

0

2000

4000

6000

8000

10000

12000

0

20

40

60

80

100

120

140

2006 2010 2011 2012 2013

Россия Ост. страны СНГ США и Канада

Количество выданных сертификатов ISO/IEC 27001

Замечание: Рост числа сертификатов в СНГ в 2013 году обеспечен

Таджикистаном – 57 выданных сертификатов.

Источник: ISO 2013 Survey.

Несертификационныестандарты. Однако, иногда

клиенты запрашивают у провайдеров независимую

оценку по данным стандартам вместо

сертификации по ISO 27001.

Сфокусированность на общих подходах к управлению информационной безопасностью, нежели на эффективности отдельных контролей,

недоверие к другим сертификатам ISO, дороговизна сертификации – возможные причины непопулярности стандарта в России, который де-

факто является «must-have» на Западе.



10

Непрерывность бизнеса представлена в ISO 27001, но

более полно охвачена в недавно выпущенном ISO 22301

ISO 22301 является относительно новым стандартом и еще немногие организации успели по нему сертифицироваться. Однако,

многие опираются на него при построении систем управления непрерывностью бизнеса


ISO 22301

18,3%

27,2%

20,8%

19,4%

42,0%

0% 5% 10% 15% 20% 25% 30% 35% 40% 45%

Прочие

Никакие

ITIL

ISO 27001

ISO 22301

Стандарты, используемые при развитии системы управления непрерывностью бизнеса

(помимо регуляторных положений)

Источник: The 2013 – 2014 Continuity Insights and KPMG Global BCM Program Benchmarking Study.

Тим Мэтью, исполнительный директор, Eterprise

Resiliency, Educational Testing Service (ETS)

«[Результаты] показывают,

что влияние ISO 22301 даже

выше, чем многие в Америке

могли подумать».

Линдон Бёрд, технический

директор BSI

«Удивляет и вдохновляет, что более 42%

респондентов обозначили ISO 22301 как

стандарт, влияющий на их программы [по

BCP]. Особенно если учесть, что

исследование 2011–2012 показало общее

влияние стандартов BS25999-2 и ASIS/BSI

BCM.01:2010 на уровне всего 16%».

«Очевидно, сертификация

рассматривается полезным

шагом – более 50%

респондентов отметили, что их

организация собирается

получить сертификацию от

DRI, еще 34% - от BCI…».

Майк Джанко, менеджер,

The Goodyear Tire & Rubber Co.



11

HIPAA – особые требования законодательства США к

защите медицинских сведений

Согласно требованиям HIPAA (Health Insurance Portability and Accountability Act) уровень защищенности медицинских сведений не

должен уменьшаться только потому, что организация передала часть функций по их обработке и хранению третьей стороне.


HIPAA

PHI –

Protected Health

Information

Медицинские

страховые

организации

Медицинские

информационно-

аналитические

центры

Лечебные и

профилактические

организации

Поставщики

медицинского

ПО

Административные

меры

■ Анализ рисков

■ Управление рисками

■ Санкционная политика

■ Анализ СОИБ

Процедуры и

ответственность

■ Управление кадрами

■ Управление доступом

■ Осведомленность

пользователей

■ Управление

инцидентами

■ Непрерывность бизнеса

■ Оценка поставщиков

Физическая

безопасность

■ Физический доступ

■ Контроль

оборудования и

устройств

Технологические

меры

■ Логический доступ

■ Передача данных

■ Целостность данных

■ Аудит контролей

Безопасность и защита персональных данных



12

Стандарт по обеспечению безопасности при

осуществлении транзакций по кредитным картам

В требованиях стандарта прописано, что его положения распространяются как на сами организации, занимающиеся процессингом

карточных транзакций, так и на их провайдеров сервисных услуг. В виду того, что международные платежные системы (Visa,

MasterCard, American Express, JCB и др.) выставляют требования по соответствию PCI DSS работающим с ними банкам и

процессинговым центрам, стандарт влияет на центры обработки данных и провайдеров облачных услуг.


PCI DSS

Управление

файерволами

Системные

настройки

Защищенное

хранение данных

Шифрование при

передаче данных

Антивирусная

защита

Технические

средства защиты

Разграничение

прав доступа

Авторизация и

аутентификация

Физическая защита

данных

Логирование и

мониторинг

Тестирование

СОИБ

Политики и

процедуры

Важный компонент PCI DSS – необходимость сегментирования систем и сетей, участвующих в хранении и обработке финансовых данных,

от других систем и сетей. Такое разграничение помимо уменьшения рисков безопасности данных, уменьшает и объем аудита на

соответствие PCI DSS.



13

Требования мегарегулятора – препятствие для

аутсорсинга?

Выпущенное в 2012 году Положение Центрального Банка РФ явилось следствием появления закона 161-ФЗ «О национальной

платежной системе». В положении регулятор детально прописал технические и административные требования ко всем участникам

процесса перевода денежных средств (в т.ч. электронных). Также ЦБ РФ выпустил необязательный стандарты ИБ (СТО БР ИББС).

Несмотря на наличие понятия оператора платежной инфраструктуры и наличия требований к ним, до сих пор не было случаев

подачи в Центральный банк результатов оценки по 382-п провайдеров ИТ-услуг. Вместе с тем, именно из-за наличия отдельных

положений мегарегулятора банки России зачастую боятся передавать на аутсорсинг такие функции, как центры обработки данных,

сервис-деск, поддержка ИТ-систем.


Положение 382-п

Операторы по переводу

денежных средств

Банковские платежные

агенты

Операторы платежных

систем

Операторы платежной

инфраструктуры

■ информация об остатках денежных средств на

банковских счетах;

■ информация об остатках электронных денежных

средств;

■ информация о совершенных переводах денежных

средств, в том числе информации, содержащейся в

извещениях, распоряжениях;

■ информация о платежных клиринговых позициях;

■ информация, необходимая для удостоверения

клиентами права распоряжения денежными

средствами;

■ ключевая информация СКЗИ

■ информация о конфигурации, определяющей

параметры работы автоматизированных систем,

используемых для осуществления переводов

денежных средств;

■ персональные данные

129

контрольных

процедур

3

категории

проверки

Отчеты сервис-

провайдера



15

SOC-отчеты о системе внутреннего контроля сервисной

организации: охватить все и сразу

В прошлом… Сейчас…

ISAE 3402

МирSSAE 16

США

Австралия UKКитай/

Гонконг

Чили Канада И др.

SOC1 SOC2 SOC3

Аббревиатура SOC расшифровывается как Service Organization Control reports (Отчеты сервисных организаций о системе

контроля). Существуют три типа SOC-отчетов: SOC1 (более известны как ISAE 3402/SSAE 16 – ранее SAS 70), SOC2, SOC3.

SOC-отчеты

Типы отчетов сервис-


Прочие локальные стандарты:



16

Контроли над процессами формирования

финансовой отчетности (ICOFR)Любые операционные контроли

SOC1 (ISAE 3402 / SSAE 16)SOC2

(ISAE 3000, Trust Services)

SOC3

(ISAE 3000, Trust Services)

Общие

сведения

Подробный отчет для пользователей услуг и

их финансовых аудиторов

Подробный отчет для

пользователей услуг, их

аудиторов и других

определенных сторон

(например, руководства,

регуляторов, консультантов по

сделкам слияния-поглощения)

Короткий отчет, который может

публично распространяться.

При этом обязательно должна

быть выполнена проверка

операционной эффективности

контролей.

Применимость Риски неправильного формирования

финансовой отчетности пользователей услуг

и контроли, покрывающие эти риски. Риски и

контроли формулируются провайдером.

Наиболее применимо для провайдеров,

занимающихся обработкой финансовых

транзакций или поддерживающих

финансовые системы.

Фокус на доменах:

– Безопасность

– Доступность

– Конфиденциальность

– Целостность обработки данных

– Защита персональных данных.

Применимо для широкого круга провайдеров.

Разделение SAS 70 стало ответом на эволюцию

аутсорсинговых моделей

Отчеты сервис-провайдеров SAS 70 были предназначены для клиентов и их аудиторов, охватывая контекст финансовой

отчетности. Сейчас AICPA выделяет три типа SOC-отчетов, покрывая более широкий круг потребностей клиентов – таких, как

информационная безопасность, конфиденциальность, защита персональных данных, доступность услуг. При этом стандарт

подготовки отчетов SOC1 в США и Канаде основывался на международном стандарте ISAE 3402. Два других типа отчетов были

введены для возможности охвата контролей на стороне сервис-провайдера, которые не влияют на финансовую отчетность.

SOC-отчеты

Типы отчетов сервис-




17

Отчеты SOC2/3 были выделены для возможности

охватить контроли, не относящиеся к фин. отчетности

Домены, покрываемые отчетами SOC2/3

Безопасность

(обязательный домен)

Доступность Конфиденциальность Целостность

обработки

Защита персональных

данных

Политика ИБ

Осведомленность

пользователей и

коммуникации

Оценка рисков

Логический доступ

Физический доступ

Защита окружающей

среды

Мониторинг

Аутентификация

пользователей


инцидентами

Управление активами

Разработка и

поддержка систем

Защита персонала


конфигурациями


изменениями

Комплайенс

Политика

непрерывности

Резервное

копирование

Восстановление

деятельности


непрерывностью

бизнеса

Политика

конфиденциальности

Сбор

конфиденциальных

данных

Обработка

конфиденциальных

данных

Раскрытие информации

Обеспечение

конфиденциальности

при разработке

информационных

систем

Политики

целостности

обработки

Полнота,

корректность,

своевременность и

авторизация при

выполнении операции

ввода/ вывода

данных и их

обработки


персональными

данными

Уведомление сторон

Получение согласий на

обработку

Сбор данных

Использование,

хранение и

уничтожение

Ограничение доступа

Раскрытия

Контроль качества

Мониторинг процессов

обработки

персональных данных

и законодательства

SOC-отчеты

Что входит в SOC2/3-

отчет?



18

Выбор типа отчета зависит от целевой аудитории и

желаемого объема проверки

Вопрос SOC2SM / SOC3SM (ISAE3000, Trust Services Principles) SOC1 (ISAE 3402 / SSAE 16)

Фокус отчета Операционные контроли Контроли над финансовой отчетностью

клиентов

Тип оказываемых

услуг

Поддержка инфраструктуры

Разработка, поддержка ПО

Выполнение прочих процедур,

затрагивающих людей и данные клиентов

Обработка транзакций

Ведение регистров бухгалтерского учета

Подготовка финансовых отчетов

Выполнение прочих процедур, оказывающих

значительное влияние на финансовую

отчетность клиентов

Выполнение общих ИТ-контролей

Домены контроля Безопасность

Доступность

Конфиденциальность

Целостность обработки данных

Защита персональных данных

Контроли над процессом обработки транзакций

Общие ИТ-контроли

Уровень

стандартизации

Провайдер выбирает домены

Специфицированы критерии, которым

должны отвечать контроли, но не цели

контроля

Провайдер определяет цели контроля, которые

могут сильно меняться в зависимости от типа

услуг

Пользователи отчета SOC 2: пользователи услуг, их аудиторы и

другие заранее определенные стороны

(например, регуляторы)

SOC 3: Широкая публика

Пользователи услуг и их финансовые аудиторы

SOC-отчеты

Какой отчет выбрать?



19

Независимая проверка (аттестация) SOC2/3-отчетов строится на основе признаваемых во всем мире принципах и критериях

Trust Services (SysTrust, WebTrust) – это набор требований, разработанных Американским институтом сертифицированных

бухгалтеров (AICPA) и Канадским институтом дипломированных бухгалтеров (CICA) с целью обеспечения уверенности во

внутренних контролях за бизнес-процессами. Критерии определены для доменов контроля (безопасность, доступность,

конфиденциальность, целостность обработки, персональные данные). Выбор доменов определяется провайдером.

Отчеты SOC1 (ISAE 3402, SSAE 16) требуют от сервис-провайдера описания бизнеса, бизнес-процессов, целей контроля и

самих контролей в контексте процессов формирования финансовой отчетности пользователей услуг. Прочие услуги, процессы и

контроли не должны входить в отчеты SOC1 (в том числе такие, как защита персональных данных и восстановление

деятельности в случае ЧС).

SOC 1 (ISAE 3402 / SSAE 16)

Контроли над процессами,

влияющими на финансовую

отчетность

SOC 2 / SOC 3

Операционные контроли

Финансовые услуги

Управление активами и депозитарные

услуги

Обработка страховых случаев

Расчет и начисление заработной платы

Обработка платежей

Облачные ERP-услуги

ЦОД

Управление и поддержка ИТ-

систем

Облачные услуги (SaaS, PaaS, IaaS)

HR-услуги

Обеспечение безопасности

Сервисы корпоративной почты, удаленных

рабочих мест, организации телеконференций

Любые услуги, для которых крайне важны

соблюдение вопросов безопасности,

доступности или защиты персональных

данных

ЦОД, облачные сервисы, службы поддержки,

разработчики – их SOC-отчеты интересны клиентамSOC-отчеты

Какой отчет выбрать?



20

SOC1 (ISAE 3402 / SSAE 16) SOC2 SOC3

Заключение аудитора Заключение аудитора Заключение аудитора

Утверждение руководства Утверждение руководства Утверждение руководства

Описание Системы процессов и

контролей


контролей


контролей

Цели контроля Критерии Критерии (ссылочно)

Процедуры контроля Процедуры контроля -

Процедуры проверки

операционной эффективности*

Процедуры проверки

операционной эффективности*

-

Результаты процедур* Результаты процедур* -

Прочая информация

(опционально)

Прочая информация

(опционально)

-

*Только для отчетов II типа. Примерный вид:Типичные разделы:

• Общее представление о компании, ее бизнесе,

структуре владения, региональных офисах

• Организационная структура

• Общие принципы руководства

• Ключевые комитеты

• Управление рисками

• Организация системы внутреннего контроля

• Функция внутреннего аудита

• Внутренние и внешние коммуникации

• Мониторинг и комплайенс

• Процессы на аутсорсинге

• Контроли на стороне пользователей

SOC-отчеты

Какая информация

входит в отчет?

SOC-отчет дает его потребителю гораздо больше

информации, чем сертификат соответствия стандарту



21

Пункт отчета Что интересного для читателя?

1. Объем аудита Охватывает ли отчет все услуги, которые мы получаем от провайдера? Все ли локации?

2. Тип отчета SOC1, SOC2SM, SOC3SM или другое?

Отчет по состоянию на момент времени (Тип 1) или за период времени (Тип 2)?

3. Охватываемый

период Как соотносится охватываемый период с нашим финансовым годом или сроком получения услуг?

4. Заключение Не квалифицировано ли мнение аудитора (достигаются ли заявленные цели и выполняются ли критерии)?

Как на нашу организацию влияют оговорки аудитора?

5. Фирма-аудитор Насколько хороша репутация фирмы-аудитора в предоставлении услуг под подтверждению достоверности

отчетов?

6. Субподрядчики Если часть процессов провайдера осуществляются на стороне субподрядчика, охвачены ли они в отчете?

Если не охвачены, есть ли для нас необходимость в их отдельной проверке (или отдельном SOC-отчете)?

7. Домены/ цели Достаточно ли покрывают выбранные цели контроля (SOC1) или домены (SOC2, SOC3) получаемые нами

услуги?

8. Описание

контролей Достаточно ли детально для понимания описаны процедуры контроля в отчете SOC1/SOC2?

9. Процедуры и

результаты

проверки

В достаточной ли мере аудитор выполнил необходимые процедуры проверки?

Если аудитор обнаружил недостатки в осуществлении контроля, могут ли они повлиять на нашу

организацию?

10. Дополнительные

контроли на стороне

пользователя

Если выявлены дополнительные контроли на стороне пользователя, внедрены ли они в нашей

организации?

11. Изменения в

периоде Если были существенные изменения, как они могли повлиять на нашу организацию?

12. Прочая

информация

Включает ли отчет прочую полезную информацию (например, как среда внутреннего контроля провайдера

отвечает требованием различных стандартов и регуляторных требований, таких, как ISO 27001, Cloud

Security Alliance, FISMA, HIPAA Security Rule, SOX 404, 382-п, СТО БР ИББС)?

SOC-отчеты

Какая информация

входит в отчет?

В SOC-отчет можно включить информацию о

соответствии международным стандартам



22

«Безопасность» - фундаментальная и

обязательная область SOC2/3-отчета

Домен Принцип Trust Services Когда требуется?

Безопасность

Система [организации бизнес-процессов и

внутренних контролей] защищена от

неавторизованного доступа (физического и

логического)

Наиболее запрашиваемая потребителями область проверки

Критерии безопасности также наследуются другими

принципами Trust Services, так как контроли по безопасности

являются основой для других доменов

Применим для любого провайдера

Доступность

Система доступна для использования и

оперирования в соответствии с

установленными принципами и

договоренностями

Вторая по популярности область, особенно для случаев,

когда восстановление в случае ЧС является частью договора

об оказании услуг/ SLA

Наиболее важный случай применения – строгая

необходимость достижения заявленного в SLA уровня

доступности сервисов (при этом данная область не может

быть покрыта в отчете SOC1)

Конфиденциальность

Информация, обозначенная как

конфиденциальная, защищена в

соответствии с установленными принципами

и договоренностями

Затрагивается в случаях, когда клиентам необходима

дополнительная уверенность в надежности процессов

провайдера относительно сведений, представляющих

корпоративную тайну

Также важен в случаях, когда от провайдера зависит защита

конфиденциальных данных заказчиков услуг его клиентов

Целостность обработки

Обработка данных производится в полном

объема, корректно и авторизованным на это

персоналом

Потенциально может применяться для широкого круга

финансовых и нефинансовых услуг, где важно иметь

уверенность в полноте, своевременности, корректности

обработки данных авторизованным на то персоналом

Защита персональных

данных

Персональные данные собираются,

используются, хранятся, разглашаются и

уничтожаются в соответствии с

обязательствами, изложенными в

соглашении на обработку персональных

данных, а также критериями, изложенными в

общих принципах AICPA и CICA по защите

персональных данных (GAPP)

Применяется в случаях, когда провайдер непосредственно

работает с конечными пользователями услуг и собирает их

персональные данные

Является сильным механизмом, демонстрирующим

эффективность программ по защите персональных данных.

SOC-отчеты

Как выбрать домены

SOC2/3-проверки?

KPMG, логотип KPMG и слоган “cutting through complexity” являются

зарегистрированными товарными знаками или товарными знаками

ассоциации KPMG International.

© 2015 АО «КПМГ», компания, зарегистрированная в соответствии с

законодательством Российской Федерации, член сети независимых

фирм КПМГ, входящих в ассоциацию KPMG International Cooperative

(“KPMG International”), зарегистрированную по законодательству

Швейцарии. Все права защищены.

Андрей Лепёхин

Партнёр

[email protected]

Дмитрий Григорович

Старший менеджер

[email protected]

Константин Аушев

Старший консультант

[email protected]

mailto:[email protected]



cloud russia 2015 kpmg

Business