9. Особые указания по валидации
9. Особые указания по валидации 
Валидация глобальных систем
247. Глобальные системы - это IT-системы, которые централизованно управляются и используются на нескольких площадках регулируемой компании. Такие системы могут быть централизованно внедрены и введены в эксплуатацию или распространены для использования на каждой площадке. Для этих систем жизненный цикл валидации, рассматриваемый в рамках данной процедуры, может быть скорректирован таким образом, чтобы обеспечить максимально централизованное создание согласованной документации и свести к минимуму усилия по валидации на уровне площадки.
248. Для каждой глобальной системы подход к валидации определяется в едином глобальном плане валидации, который определяет глобальные и локальные результаты. Локальная реализация может быть детализирована в плане проверки конкретной площадки, созданном в соответствии с вышеупомянутым глобальным валидационным планом.
249. Процесс валидации для этих систем может включать глобальный пакет валидации, ориентированный в первую очередь на обеспечение функциональной надежности системы. Каждая площадка может официально принять результат глобальной валидации и создать локальную спецификацию (документацию) по тестированию, связанную с функциональными возможностями площадки, если таковые имеются. Процесс валидации должен включать в себя верификацию процессов, выполняемых посредством системы на каждой отдельной площадке.
250. Глобальная документация должна быть доступна для площадки в случае проведения инспекции. Локальный подход площадки к валидации должен утверждаться глобальным руководством для обеспечения гармонизированного и согласованного подхода.
251. Локальная команда должна быть обучена, чтобы быть в курсе стратегии, используемой для проведения валидации на глобальном и локальном уровнях.
Валидация "облачных" систем
252. При использовании "облачных" или "виртуальных" сервисов следует уделять внимание пониманию предоставляемых услуг, владению, извлечению, хранению и безопасности данных.
253. Обязанности заказчика системы (регулируемой компании) и исполнителя (поставщика IT-услуг) определяются техническим соглашением или договором. Соглашение должно обеспечивать своевременный доступ к данным (включая метаданные и контрольные журналы) владельцу данных и национальным компетентным органам по запросу. Контракты с поставщиками определяют ответственность за архивирование и непрерывную читаемость данных в течение всего периода хранения.
254. В настоящее время регулируемым компаниям представляются следующие виды услуг:
а) программное обеспечение как услуга (Software-as-a-Service, SaaS). Регулируемые компании используют приложения, работающие на инфраструктуре, принадлежащей поставщику IT-услуг. Регулируемые компании не управляют и не контролируют базовую инфраструктуру или даже отдельные возможности приложений, за исключением ограниченных пользовательских параметров конфигурации приложений;
б) платформа как услуга (Platform-as-a-Service, PaaS). Регулируемые компании используют IT-инфраструктуру, размещенную поставщиком IT-услуг, для запуска приложений, созданных с использованием операционных систем, языков программирования и инструментов, поддерживаемых поставщиком IT-услуг. Регулируемые компании не управляют и не контролируют базовую облачную инфраструктуру, включая сеть, серверы, операционные системы или хранилище, но по-прежнему контролируют развернутые приложения и, возможно, конфигурации среды размещения приложений;
в) инфраструктура как услуга (Infrastructure-as-a-Service, IaaS). Владелец использует основные вычислительные ресурсы, такие как обработка, хранение, сети, где клиент может развертывать и запускать произвольное программное обеспечение, которое может включать операционные системы и приложения. Клиент не управляет базовой облачной инфраструктурой, но имеет контроль над операционными системами, хранилищем, развернутыми приложениями и, возможно, ограниченный контроль над выбранными сетевыми компонентами (например, брандмауэрами хоста).
255. Надежность компьютеризированной системы, используемой регулируемой компанией, всегда находится в зоне ответственности регулируемой компании, которой следует документировать соответствующий процесс валидации, используя документацию, представленную поставщиком системы.
256. Жизненный цикл валидации осуществляется в соответствии с изложенным в предыдущих разделах, с гарантией, что следующие конкретные меры должным образом проверены (подтверждены):
а) оценка поставщика выполнена на месте и до определения стратегии валидации в плане валидации. Метод оценки поставщика основан на риске, связанном с системой;
б) план валидации учитывает результаты этапа оценки поставщика;
в) документация по валидации может использовать спецификации, документацию по квалификации монтажа (IQ) и функционирования (OQ), предоставленную поставщиком, если эти документы будут признаны адекватными при оценке поставщика;
г) эффективный статус соглашения об уровне обслуживания проверен на этапе тестирования IQ;
д) квалификация эксплуатации (приемочный тест пользователя (User Acceptance Test UAT)) выполняется конечным пользователем регулируемой компании, проверяющим, что система работает по назначению пользователя (на основе спецификации требований пользователей) во всех предполагаемых рабочих диапазонах.
257. Выбор систем осуществляется на основе надежной оценки поставщиков по всем аспектам предоставляемых услуг. Допускается привлекать консультантов, обладающих знаниями в области IT, для эффективного тестирования "облачного" программного обеспечения, платформы и инфраструктуры, а также для проверки соответствия и управляемости "облачного" приложения. Аудит IT-безопасности должен быть ориентирован как минимум на следующие аспекты:
а) порядок уведомления поставщиком регулируемой компании о проблемах, которые влияют на целостность данных, включая (но не ограничиваясь) следующие из них:
технические ошибки и ошибки хостинга;
ошибки, связанные с нарушениями защиты;
ошибки в программном обеспечении;
проблемы резервного копирования и восстановления и (или) выполнения плана аварийного восстановления;
б) безопасность авторизации и требования по разделению обязанностей;
в) процесс управления изменениями для улучшений, исправлений, обновлений;
г) требования к хранению контрольного следа и журнала событий (Event Log);
д) механизм управления доступом;
е) механизм идентификации и аутентификации;
ж) механизм шифрования;
з) квалификация инфраструктуры (даже если инфраструктура управляется третьей стороной);
и) пакет валидации (спецификация и протоколы тестирования). Любые обнаруженные пробелы (несоответствия) следует устранить посредством корректирующих действий, согласованных с поставщиком, и дополнительных мероприятий по валидации в рамках проекта внедрения (например, дополнительных испытаний), выполняемых регулируемой компанией.
258. "Облачные" приложения рассматриваются только как соответствующие категориям 4 или 5 по классификации категорий компьютеризированных систем, указанной в пункте 148 настоящего Руководства. С точки зрения регулируемой организации конфигурацию "облачных" приложений, следует рассматривать как соответствующую категории 4, в то же время любую пользовательскую разработку интерфейсов или передачи данных, влияющих на GMP, связанную "облачным" приложением, следует рассматривать как соответствующую категории 5 и испытать соответствующим образом.
259. Если "облачная" инфраструктура (IaaS и PaaS) была выбрана для реализации, следует убедиться, что она соответствующим образом квалифицирована поставщиком и (или) регулируемой компанией в соответствии с пунктами 265 - 272 настоящего Руководства.
Валидация электронных таблиц
260. Каждая электронная таблица рассматривается в качестве одиночной компьютеризированной системы, и поэтому критические электронные таблицы подлежат инвентаризации, оценке риска и валидации соответственно.
261. Электронные таблицы обычно применяются для повторения алгоритма расчета. Применение формата Excel (то есть электронной таблицы, используемой для хранения и архивирования GMP-данных) качестве базы данных не допускается, если контрольный след не отслеживается с помощью дополнительных мер.
262. Категория таблицы Excel по категоризации компьютеризированных систем, приведенной в пункте 148 настоящего Руководства, зависит от типа операций, которые выполняются с GMP-данными в этой таблице и определяется следующим:
а) категория 3 (не конфигурированная) - электронная таблица просто использует собственные функции без конфигурации (например, данные валидации, условное форматирование);
б) категория 4 (конфигурированная) - электронная таблица выполняет вычисления с помощью настроенных формул, а также формул, использующих основные функции Excel (например, сложение, вычитание, деление);
в) категория 5 (пользовательская) - электронная таблица использует пользовательские макросы, сложные или вложенные логические и схожие функции.
263. Каждая система электронных таблиц используется с учетом следующих факторов:
а) обеспечение безопасности электронной таблицы, с гарантией, что могут быть заполнены только входные ячейки (например, формулы не могут быть намеренно или случайно перезаписаны, параметры разработки отключены);
б) настройка безопасности доступа и проверки авторизации (например, создание электронной таблицы Excel в выделенной папке с правами доступа, определенными для всех пользователей электронной таблицы);
в) выполнение любых вычислений, связанных с точностью, отображаемой на экране и в отчетах;
г) использование переменных электронной таблицы (в Microsoft Excel называемых "именами"), дающих возможность создания формулы (например, вместо включения в формулу ссылки на ячейку A4 определить A4 именем "количество" и включить строку "Количество" в формулу);
д) обеспечение правильности выполнения резервного копирования (для электронных таблиц, хранящихся в локальных каталогах);
е) защищенность "привязки" ко времени, включая часовой пояс;
ж) проверка того, что заполненная таблица сохраняется в нередактируемом файле (например, в формате PDF);
з) при использовании таблицы как шаблона настройка обеспечивает ее сохранение только в защищенной папке.
264. Результаты жизненного цикла валидации, описанные в пунктах 160 - 219 настоящего Руководства, создаются для каждой таблицы, при этом некоторые документы могут быть объединены вместе (например, единый документ, описывающий функциональные требования спецификации требований пользователей URS/FS).
