Введение

Настоящий документ задаёт протокол сертификационного аудита СМК на соответствие требованиям ИСО 9001 для организации цифровой сферы: консалтинг, кастомная разработка, внедрение искусственного интеллекта и машинного обучения, управление IT-продуктами, кибербезопасность и облачная инфраструктура. Протокол опирается на логику стандарта и рекомендации ИСО/ТК 176 для малых и средних организаций: проверяется фактическая работа процессов, а не объём бумажных регламентов. Вопросы расположены по цепочке области применения, процессного подхода, документации, ответственности руководства, ресурсов, жизненного цикла продукции (услуги), измерений и улучшения, а также готовности к сертификации третьей стороной.

Аннотация.

Цель аудита. Подтвердить, что система менеджмента качества разработана, документирована, внедрена и поддерживается в рабочем состоянии в соответствии с применимыми требованиями ИСО 9001, обеспечивает выполнение требований потребителей и обязательных требований к цифровым услугам и создаёт основу для постоянного улучшения результативности. Аудит должен дать измеримый вывод: способность организации стабильно поставлять консалтинговые результаты, кастомное программное обеспечение, решения на базе искусственного интеллекта и машинного обучения, IT-продукты, услуги кибербезопасности и облачной инфраструктуры в согласованных условиях. Дополнительно проверяется снижение рисков неконтролируемого аутсорсинга, неуправляемого релиза, утраты собственности потребителя (данные, код, доступы) и формальной «бумажной» СМК без записей функционирования.

Область применения. В область входят процессы СМК на заявленных площадках и в удалённом режиме: стратегическое и операционное руководство, управление документацией и записями, продажи и анализ обязательств, проектирование и разработка ПО и моделей, закупки и управление поставщиками (включая облако, подрядную разработку, данные и Open Source как влияющую поставку), производство и предоставление услуг, выпуск, сопровождение, мониторинг удовлетворённости, внутренние аудиты, управление несоответствиями, анализ данных, корректирующие и предупреждающие действия, анализ со стороны руководства. Вне области: финансовый аудит, полноценный аудит информационной безопасности по ИСО/МЭК 27001 (кроме влияющих на соответствие услуги аспектов), оценка коммерческой эффективности сделок и техническая экспертиза алгоритмов вне критериев качества, установленных организацией и потребителем. Исключения из раздела 7 допускаются только при обосновании в руководстве по качеству и не могут снимать ответственность за соответствие продукции.

Критерии аудита. Базовый критерий — требования ИСО 9001 (редакция, заявленная организацией; протокол учитывает структуру 9001:2008, на которой построено пособие ИСО/ТК 176, и применимую практику процессного подхода). Дополнительно: собственное руководство по качеству, политика и цели в области качества, обязательные документированные процедуры, применимые законодательные и нормативные требования к продукции, договорные требования потребителей (SLA, критерии приёмки, постпоставка), заявленные KPI процессов. Ориентиры метода — ИСО 19011 (принципы аудита, выборка, независимость). ИСО 9004 не является критерием сертификации и используется только как контекст зрелости.

Объекты проверки. Руководство по качеству и область применения; реестр и карта процессов; политика и цели; записи анализа со стороны руководства; программа и отчёты внутренних аудитов; журналы несоответствий и CAPA; договоры, ТЗ, записи анализа требований; артефакты проектирования (ADR, спецификации, карточки моделей); планы и записи верификации и валидации; реестр поставщиков и акты приёмки; регламенты релиза и свидетельства выпуска; реестр собственности потребителя и журналы доступов; записи компетентности и обучения; состав инфраструктуры (среды, CI/CD, мониторинг); данные удовлетворённости и жалоб; выборка проектных комплектов «от обязательства до сопровождения».

Методика. Комбинация анализа документов, выборки записей за период не менее 12 месяцев (или за срок функционирования СМК, если он короче), интервью с высшим руководством, представителем руководства, владельцами процессов, разработчиками, консультантами, специалистами сопровождения и закупок, наблюдения за рабочими местами и пайплайнами (в том числе удалённо). Выборка — риск-ориентированная: приоритет процессов с высоким влиянием на потребителя (релиз, ИИ, данные заказчика, критичные подрядчики). Триангуляция: документ ↔ запись ↔ слова сотрудника ↔ наблюдаемое действие. Фиксация только на объективных свидетельствах.

Фокус рисков / критичность. Наивысший приоритет: необоснованные исключения п. 7.3 при кастомной разработке и ИИ; неуправляемые аутсорсинговые и облачные процессы; принятие обязательств без анализа способности; выпуск без верификации и валидации; обращение с данными и кодом потребителя; формальные внутренние аудиты и анализ руководства; корректирующие действия без корневой причины; совмещение ролей без компенсации независимости. Высокий приоритет: компетентность персонала, влияющего на соответствие; управление изменениями дизайна и пайплайна; полнота требований, включая обязательные и неявные (безопасность, качество модели). Средний: соразмерность документации масштабу малой организации, коммуникации, инфраструктура рабочих мест.

Ожидаемый результат аудита. Заполненный протокол с картой свидетельств по каждому вопросу, классифицированными находками (соответствие, наблюдение, несоответствие) и основой для корректирующих действий. Результат позволяет органу по сертификации или внутренней комиссии принять решение о готовности к сертификации / надзору, а организации — закрыть системные разрывы до повторения дефектов у потребителя. Протокол не заменяет отчёт об аудите, но задаёт единый чек-лист сбора доказательств и исключает пропуск обязательных элементов СМК.

Определена ли и документально зафиксирована область применения системы менеджмента качества, включая обоснованные исключения из раздела 7 ИСО 9001?

Цель вопроса. Убедиться, что граница СМК понятна, исключения допустимы только из раздела 7 и не снимают ответственность за соответствие продукции и услуг.

Область применения. Высшее руководство, представитель руководства, руководство по качеству, договоры с заказчиками цифрового консалтинга, разработки ПО, внедрения ИИ и облачных услуг.

Критичность. Critical — неверная область или необоснованное исключение (например, исключение 7.3 при кастомной разработке) делает сертификацию невозможной.

Ожидаемые доказательства. Руководство по качеству (раздел «область применения»), перечень процессов, договоры, описание услуг (консалтинг, кастомное ПО, ML/AI, кибербезопасность, облако), записи анализа применимости.

Как проверить. Сопоставить заявленные услуги с пунктами раздела 7. Проверить, что исключения ссылаются только на 7.x и обоснованы характером процессов. Опросить представителя руководства о границах СМК и площадках (офис, удалённые команды, облачные контуры).

Типичные несоответствия. Исключён 7.3 при наличии проектирования ПО/моделей; область не включает аутсорсинг разработки; нет обоснования исключения.

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

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

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

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

Ожидаемые доказательства. Карта / реестр процессов, описание входов-выходов, критерии и методы управления, схема взаимодействия (включая PDCA).

Как проверить. Запросить реестр процессов и схему взаимодействия. Выбрать 3–4 сквозных процесса (например, «заказ → релиз ПО») и проследить владельца, входы, выходы, критерии, мониторинг. Сверить с п. 4.1.

Типичные несоответствия. Процессы перечислены списком без взаимодействий; нет владельцев; схема существует, но не используется в работе.

Определены ли критерии и методы, необходимые для обеспечения результативности как осуществления, так и управления процессами СМК?

Цель вопроса. Подтвердить, что процессы не только названы, но имеют измеримые критерии и рабочие методы.

Область применения. Владельцы процессов, служба качества, проектные команды разработки и внедрения ИИ.

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

Ожидаемые доказательства. Паспорта процессов, KPI процессов, рабочие инструкции, регламенты code review / MLOps / инцидент-менеджмента.

Как проверить. По выборке процессов проверить наличие критериев (сроки, дефектность, SLA, точность модели) и методов (регламенты, чек-листы). Сопоставить фактические измерения с заявленными критериями.

Типичные несоответствия. KPI есть только на уровне компании; процесс «разработка» не имеет критериев приёмки.

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

Цель вопроса. Оценить, что процессы не «бумажные»: у них есть люди, инфраструктура, доступ к данным.

Область применения. Планирование ресурсов, ИТ-инфраструктура, HR, владельцы процессов.

Критичность. High — дефицит ресурсов делает СМК формальной.

Ожидаемые доказательства. Планы загрузки, бюджеты проектов, доступы в репозитории и облако, протоколы анализа со стороны руководства (ресурсы).

Как проверить. Сверить заявленные процессы с фактической укомплектованностью. Опросить владельцев: чего не хватает. Проверить решения анализа руководства по ресурсам.

Типичные несоответствия. Процесс внутреннего аудита без обученных аудиторов; ML-процесс без вычислительных ресурсов.

Осуществляются ли мониторинг, измерение (где применимо) и анализ процессов, и реализуются ли действия для достижения запланированных результатов и постоянного улучшения?

Цель вопроса. Проверить замкнутость цикла PDCA на уровне процессов.

Область применения. Все ключевые процессы СМК, включая аутсорсинговые.

Критичность. High — без анализа процессы деградируют.

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

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

Типичные несоответствия. Измерения собираются, но не анализируются; улучшения не связаны с данными процесса.

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

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

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

Критичность. Critical — потеря управления подрядчиком напрямую влияет на качество услуги и безопасность.

Ожидаемые доказательства. Договоры с SLA/NCA/NDA, критерии выбора поставщика, акты приёмки, доступы, мониторинг SLA, перечень аутсорсинговых процессов в руководстве по качеству.

Как проверить. Составить список фактически переданных процессов (облако, pentest, дата-разметка, аутстафф). Проверить, как организация определяет методы управления каждым. Выборочно проверить одного критичного подрядчика.

Типичные несоответствия. Аутсорсинг не идентифицирован; нет критериев управления; облачный провайдер не входит в СМК.

Согласована ли система менеджмента качества со стратегическим решением организации и её внешней средой, целями, продукцией и структурой?

Цель вопроса. Введение стандарта подчёркивает, что СМК — стратегическое решение, а не «сертификат для тендера».

Область применения. Высшее руководство, стратегия, портфель услуг.

Критичность. Medium — показывает зрелость намерения, а не только формальное соответствие.

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

Как проверить. Опросить высшее руководство: зачем внедрена СМК, какие цели бизнеса она поддерживает. Сверить формулировки политики с фактической стратегией.

Типичные несоответствия. Политика скопирована из шаблона; руководство не может связать СМК с целями бизнеса.

Понимает ли персонал, что требования ИСО 9001 дополняют, а не заменяют требования к продукции (включая обязательные законодательные требования)?

Цель вопроса. Исключить подмену: сертификация СМК не равна качеству кода, модели или консультации.

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

Критичность. Medium — типичная ошибка малых организаций.

Ожидаемые доказательства. Договоры, ТЗ, чек-листы приёмки, перечень обязательных требований (ПДн, лицензии ПО, отраслевые нормы).

Как проверить. На выборке проектов проверить, как обязательные требования к продукции фиксируются отдельно от требований СМК.

Типичные несоответствия. В договоре только ссылка на ISO 9001 без требований к услуге; игнорируются требования по ПДн.

Включает ли документация СМК заявления о политике и целях в области качества, руководство по качеству, обязательные документированные процедуры и записи, а также документы, необходимые организации для планирования, осуществления и управления процессами?

Цель вопроса. Проверить полноту пакета документации по п. 4.2.1 без избыточной бюрократии.

Область применения. Служба качества, владельцы процессов, высшее руководство.

Критичность. High — документная база — каркас аудита и ежедневной работы.

Ожидаемые доказательства. Реестр документов СМК, политика, цели, руководство по качеству, 6 обязательных процедур (2008): управление документацией, записями, внутренние аудиты, несоответствующая продукция, корректирующие и предупреждающие действия.

Как проверить. Сверить реестр с п. 4.2.1. Убедиться, что есть все обязательные процедуры и те дополнительные документы, без которых процессы (разработка, MLOps, инциденты) неуправляемы. Оценить, нет ли «мёртвых» шаблонов.

Типичные несоответствия. Нет процедуры предупреждающих действий; руководство по качеству без ссылок на процедуры; избыток неиспользуемых регламентов.

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

Цель вопроса. Руководство — дорожная карта СМК для сотрудников и органа по сертификации.

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

Критичность. Critical — без актуального руководства сертификация обычно не начинается (этап 1).

Ожидаемые доказательства. Актуальная редакция руководства, лист ознакомления, матрица процессов, таблица перекрёстных ссылок на пункты ИСО 9001.

Как проверить. Проверить статус документа, дату пересмотра, соответствие фактическим процессам (ИИ, облако, кибербезопасность). Убедиться, что это не импортированный шаблон другой организации.

Типичные несоответствия. Руководство не обновлялось после смены услуг; отсутствуют исключения; нет описания взаимодействия процессов.

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

Цель вопроса. П. 4.2.3 — обязательная процедура; в ИТ критичен контроль версий регламентов, политик ИБ, стандартов кодирования.

Область применения. Все подразделения, создающие документы СМК, включая wiki, Git и облачные диски.

Критичность. High — устаревшая инструкция приводит к дефектам поставки.

Ожидаемые доказательства. Процедура управления документацией, мастер-лист, система версионирования (Git/Confluence с правами), архив устаревших версий, записи утверждения.

Как проверить. Выбрать 8–10 документов разного типа (политика, SOP, стандарт кодирования, runbook). Проверить утверждение, версию, доступ на рабочих местах, изъятие устаревших копий, управление внешними документами (стандарты, требования заказчика).

Типичные несоответствия. Одновременно используются две версии регламента релиза; внешние требования заказчика не управляются как документы.

Установлена ли документированная процедура управления записями, обеспечивающая идентификацию, хранение, защиту, восстановление, определение сроков хранения и изъятие записей?

Цель вопроса. Записи — объективные свидетельства; без них соответствие недоказуемо.

Область применения. Все процессы, формирующие записи: проекты, аудиты, закупки, обучение, инциденты, релизы.

Критичность. High — потеря записей = потеря доказуемости.

Ожидаемые доказательства. Процедура управления записями, номенклатура дел / реестр записей, правила резервного копирования, сроки хранения (в т.ч. по договорам и закону о ПДн).

Как проверить. По выборке типов записей проверить место хранения, защиту (доступ, бэкап), извлекаемость, соблюдение сроков. Особо — журналы релизов, протоколы приёмки моделей, записи аудитов.

Типичные несоответствия. Записи в личных чатах; нет сроков хранения; бэкап не проверялся.

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

Цель вопроса. Пособие для малых предприятий прямо предостерегает от бюрократизации СМК.

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

Критичность. Medium — избыток документов снижает вовлечённость.

Ожидаемые доказательства. Реестр документов, факты использования (просмотры, ссылки в работе), отзывы сотрудников.

Как проверить. Опросить 5 сотрудников: какими документами они реально пользуются. Найти документы без владельца и без фактов применения.

Типичные несоответствия. Сотни регламентов «под аудитора»; сотрудники работают «как привыкли».

Управляются ли документы внешнего происхождения, необходимые для планирования и функционирования СМК (стандарты, требования заказчиков, лицензионные условия, нормативные акты)?

Цель вопроса. П. 4.2.3 требует идентификации и управления внешними документами.

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

Критичность. High — пропуск изменения внешнего требования (например, к защите данных) создаёт юридический и качественный риск.

Ожидаемые доказательства. Реестр внешних документов, подписки на обновления НПА, папки требований заказчиков в проектах.

Как проверить. Проверить 3–5 внешних источников (договорные SLA, отраслевые требования, лицензии библиотек). Есть ли владелец, версия, способ доведения изменений до команд.

Типичные несоответствия. Требования заказчика лежат в почте менеджера; обновления ГОСТ/152-ФЗ не отслеживаются.

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

Цель вопроса. Ключевой риск в распределённых ИТ-командах — «тихая» копия на диске.

Область применения. Все точки использования документов: wiki, репозитории, общие диски, печатные чек-листы.

Критичность. High — работа по старой версии Definition of Done даёт системные дефекты.

Ожидаемые доказательства. История версий, рассылка об изменениях, запрет локальных неуправляемых копий, spot-check рабочих мест.

Как проверить. Сравнить версию документа в мастер-системе с копиями у команд разработки и поддержки. Проверить, как персонал узнаёт об изменении.

Типичные несоответствия. Локальные PDF без версии; изменение не доведено до смены.

Ознакомлен ли персонал с документами, необходимыми для выполнения работы, и доступны ли эти документы в местах применения?

Цель вопроса. Документ, который нельзя найти в момент работы, не выполняет функцию управления.

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

Критичность. Medium — доступность — часть п. 4.2.3.

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

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

Типичные несоответствия. Документы только у руководителя; новички не знают, где Definition of Ready.

Определены ли записи, требуемые ИСО 9001, и ведутся ли они фактически (а не только перечислены в процедуре)?

Цель вопроса. Стандарт требует конкретных записей по многим пунктам (анализ требований, анализ руководства, компетентность, внутренние аудиты и др.).

Область применения. Все процессы с обязательными записями.

Критичность. High — «процедура есть — записей нет» — частое несоответствие.

Ожидаемые доказательства. Матрица обязательных записей vs фактический архив за 12 месяцев.

Как проверить. Построить выборку обязательных записей по пунктам 5.6, 6.2.2, 7.2.2, 7.3, 8.2.2, 8.3, 8.5.2, 8.5.3 и подтвердить наличие.

Типичные несоответствия. Нет записей анализа требований; протоколы анализа руководства формальны и без выходных данных.

Защищены ли записи СМК от потери, повреждения, несанкционированного изменения, в том числе в облачных и совместных средах?

Цель вопроса. Для цифровой организации запись = объект ИБ и качества одновременно.

Область применения. ИТ, ИБ, служба качества.

Критичность. High — утрата доказательной базы срывает сертификацию и расследования.

Ожидаемые доказательства. Политика резервного копирования, права доступа, журналы изменений, результаты restore-тестов.

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

Типичные несоответствия. Общий диск без версий; нет reserve copy протоколов аудита.

Предоставляет ли высшее руководство свидетельства своих обязательств по разработке и внедрению СМК и постоянному улучшению её результативности?

Цель вопроса. П. 5.1 — без реального лидерства СМК малых организаций быстро формализуется.

Область применения. Единоличный руководитель / партнёры / директор, совещания руководства.

Критичность. Critical — главная причина провала внедрения по пособию для малых предприятий.

Ожидаемые доказательства. Политика, цели, протоколы совещаний, выделение ресурсов, участие в анализе СМК, коммуникации о важности требований потребителей.

Как проверить. Опросить первое лицо: как лично участвует в СМК. Проверить присутствие на анализе руководства, решения по ресурсам, доведение важности выполнения требований заказчика.

Типичные несоответствия. Подпись на политике без участия; анализ руководства делегирован «чтобы галочка».

Обеспечивает ли высшее руководство, что требования потребителей установлены и выполняются с целью повышения удовлетворённости потребителей?

Цель вопроса. П. 5.2 — ориентация на потребителя как принцип менеджмента качества.

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

Критичность. High — ядро ценности СМК.

Ожидаемые доказательства. Процесс сбора требований, NPS/CSI, разбор жалоб, решения руководства по обратной связи.

Как проверить. Проследить цепочку: голос заказчика → решение руководства → изменение процесса/продукта. Выборочно 3 жалобы / 3 запроса на изменение.

Типичные несоответствия. Жалобы закрываются менеджером без эскалации; руководство не видит тренды удовлетворённости.

Документально оформлена ли политика в области качества, соответствует ли она намерениям организации, включает ли обязательство соответствовать требованиям и постоянно улучшать результативность СМК, создаёт ли основу для целей и доведена ли до персонала?

Цель вопроса. П. 5.3 — политика должна быть живым документом, а не плакатом.

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

Критичность. High — политика задаёт рамку целей и аудита.

Ожидаемые доказательства. Утверждённый текст политики, записи пересмотра, факты доведения (стенд, портал, адаптация), понимание сотрудниками смысла (не заучивание).

Как проверить. Проверить актуальность, связь с целями, опросить 5 сотрудников: что политика означает в их работе (релиз, консультация, модель ИИ). Проверить анализ пригодности политики.

Типичные несоответствия. Политика скопирована; сотрудники не могут пояснить; нет пересмотра после смены стратегии.

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

Цель вопроса. П. 5.4.1 — цели должны спускаться до уровня команд разработки, поддержки, консалтинга.

Область применения. Руководство, владельцы услуг, команды.

Критичность. High — без измеримых целей улучшение непроверяемо.

Ожидаемые доказательства. Реестр целей, целевые значения, ответственные, сроки, отчёты о достижении, связь с политикой.

Как проверить. Оценить SMART-характер целей (например, доля релизов без критичных дефектов, соблюдение SLA, точность модели, срок закрытия инцидента). Проверить каскадирование и периодический пересмотр.

Типичные несоответствия. Цели сформулированы как «улучшить качество»; нет целей на уровне разработки; нет связи с требованиями к услуге.

Выполняется ли планирование системы менеджмента качества для достижения целей и сохранения целостности СМК при планировании и внесении изменений?

Цель вопроса. П. 5.4.2 — изменения (новая услуга ИИ, миграция в облако) не должны ломать СМК.

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

Критичность. High — типичный риск растущей ИТ-организации.

Ожидаемые доказательства. Планы развития СМК, записи управления изменениями процессов, актуализация руководства и целей при запуске новых услуг.

Как проверить. Взять 2 существенных изменения за год (новый продукт, смена облака, реорганизация). Проверить, планировалось ли влияние на СМК, документы, компетентность, мониторинг.

Типичные несоответствия. Новая услуга запущена, процессы СМК не обновлены; цели старые.

Определены ли и доведены ли ответственность и полномочия в рамках СМК?

Цель вопроса. П. 5.5.1 — в малой организации один человек совмещает роли, но это должно быть явно.

Область применения. Оргструктура, должностные инструкции / матрица RACI, проектные роли.

Критичность. Medium — размытость ролей даёт пропуски приёмки и эскалации.

Ожидаемые доказательства. Оргсхема, положения, RACI по процессам СМК, приказы о назначении.

Как проверить. По ключевым процессам спросить «кто владелец / кто утверждает / кто останавливает релиз». Сверить с документами. Проверить совмещение ролей на конфликт интересов (разработчик сам себе аудирует).

Типичные несоответствия. Нет владельца процесса закупок; полномочие остановить несоответствующий релиз не закреплено.

Назначен ли представитель руководства из состава менеджмента организации, имеющий ответственность и полномочия обеспечивать внедрение и поддержание процессов СМК, представлять высшему руководству отчёты о результативности и способствовать осведомлённости о требованиях потребителей?

Цель вопроса. П. 5.5.2 — роль нельзя формально «повесить» на внешнего консультанта как единственного представителя.

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

Критичность. Critical — орган по сертификации проверяет реальность этой роли.

Ожидаемые доказательства. Приказ о назначении, должностная инструкция, отчёты представителя, участие в анализе руководства, свидетельства работы с персоналом по требованиям заказчика.

Как проверить. Опросить назначенного: как выполняет три функции п. 5.5.2. Проверить, что это сотрудник организации с полномочиями, а не только консультант.

Типичные несоответствия. Представитель — внешний консультант без полномочий; нет отчётов о результативности СМК.

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

Цель вопроса. П. 5.5.3 — в малой фирме каналы простые, но должны быть определёнными.

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

Критичность. Medium — разрыв коммуникации ломает процессный подход.

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

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

Типичные несоответствия. Результаты аудита известны только службе качества; нет канала эскалации дефекта.

Проводит ли высшее руководство через запланированные интервалы анализ со стороны руководства пригодности, адекватности и результативности СМК?

Цель вопроса. П. 5.6.1 — обязательная периодическая деятельность с записями.

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

Критичность. Critical — ключевое свидетельство лидерства и улучшения.

Ожидаемые доказательства. График анализов, протоколы за период не менее 12 месяцев, список участников.

Как проверить. Проверить периодичность (не реже чем заявлено), состав участников (наличие высшего руководства), содержательность, связь с последующими действиями.

Типичные несоответствия. Анализ проводится «под сертификацию» раз в 3 года; протокол без решений.

Включают ли входные данные анализа со стороны руководства результаты аудитов, обратную связь от потребителей, функционирование процессов и соответствие продукции, статус предупреждающих и корректирующих действий, последующие действия предыдущих анализов, изменения, которые могут влиять на СМК, и рекомендации по улучшению?

Цель вопроса. П. 5.6.2 задаёт полный обязательный набор входов.

Область применения. Подготовка анализа — представитель руководства и владельцы процессов.

Критичность. High — неполный вход делает анализ формальным.

Ожидаемые доказательства. Пакет входных материалов к последним двум анализам, приложения с данными CSI, аудитов, KPI, CAPA.

Как проверить. Сверить протокол и приложения с перечнем a)–g) п. 5.6.2. Отметить отсутствующие входы.

Типичные несоответствия. Нет данных по удовлетворённости; статус CAPA не рассматривается; нет анализа изменений.

Включают ли выходные данные анализа решения и действия, относящиеся к повышению результативности СМК и её процессов, улучшению продукции согласно требованиям потребителей и потребности в ресурсах?

Цель вопроса. П. 5.6.3 — анализ без решений не соответствует стандарту.

Область применения. Высшее руководство.

Критичность. High — выходы замыкают PDCA на уровне организации.

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

Как проверить. Проследить 5 решений предыдущего анализа: выполнены ли, оценена ли эффективность. Есть ли решения по ресурсам и улучшению услуг.

Типичные несоответствия. Протокол «принять к сведению»; нет поручений; ресурсы не рассматриваются.

Доводит ли высшее руководство до сведения организации важность выполнения требований потребителей, а также законодательных и нормативных требований?

Цель вопроса. Элемент обязательств п. 5.1 a).

Область применения. Вся организация, особенно продажи и поставка.

Критичность. Medium — формирует культуру соответствия.

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

Как проверить. Опросить сотрудников фронта и бэка: какие обязательные требования критичны в их работе (ПДн, лицензии, SLA). Откуда они это узнали.

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

Определяет ли и обеспечивает ли организация ресурсы, необходимые для внедрения, поддержания СМК, постоянного улучшения её результативности и повышения удовлетворённости потребителей?

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

Область применения. Бюджетирование, HR, ИТ, руководство проектов.

Критичность. High — недоресурс напрямую бьёт по срокам и дефектам.

Ожидаемые доказательства. Штатное расписание, планы найма, бюджет инфраструктуры, решения анализа руководства.

Как проверить. Сопоставить цели и портфель проектов с фактическими FTE, стендами, инструментами. Найти хронически «голодные» процессы.

Типичные несоответствия. Цели роста продаж без плана найма инженеров качества; нет бюджета на калибровку/инструменты мониторинга.

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

Цель вопроса. П. 6.2.1 — компетентность критична для разработки, ИИ, кибербезопасности, консалтинга.

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

Критичность. Critical — некомпетентный выпуск модели/кода — системный риск.

Ожидаемые доказательства. Профили компетенций, записи об образовании и опыте, допуски к работам (prod, модели, pentest), матрица навыков.

Как проверить. Выбрать роли: архитектор, ML-инженер, консультант, аудитор, специалист поддержки. Сверить требования профиля с фактическими записями. Проверить допуск к критичным работам.

Типичные несоответствия. Нет профиля компетенций; junior выкатывает в prod без наставничества; внутренний аудитор без подготовки.

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

Цель вопроса. Полный цикл п. 6.2.2 a)–e).

Область применения. HR, линейные руководители, обучение.

Критичность. High — обучение «для галочки» не закрывает требование оценки результативности.

Ожидаемые доказательства. План обучения, журналы тренингов, оценка эффективности (тест, наблюдение, KPI после обучения), записи осведомлённости, личные дела.

Как проверить. По 5 сотрудникам проследить: выявленный разрыв компетенций → действие → оценка эффекта → запись. Проверить осведомлённость о вкладе в цели качества.

Типичные несоответствия. Сертификаты собраны, результативность не оценена; нет записей по фрилансерам, влияющим на продукт.

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

Цель вопроса. П. 6.3: здания, рабочие места, оборудование, ПО, связь, облако, CI/CD, стенды.

Область применения. ИТ-эксплуатация, офис-менеджмент, DevOps.

Критичность. High — падение CI/CD или отсутствие тестового контура ломает качество поставки.

Ожидаемые доказательства. Реестр инфраструктуры, договоры облака, схемы сред (dev/stage/prod), регламенты обслуживания, мониторинг доступности.

Как проверить. Осмотреть (в т.ч. удалённо) критичную инфраструктуру: репозитории, пайплайны, среды, резервирование, рабочие места консультантов. Сверить с потребностями процессов 7.5.

Типичные несоответствия. Prod и test не разделены; нет обслуживания рабочих станций; критичный SaaS без владельца.

Определяет ли и управляет ли организация производственной средой, необходимой для достижения соответствия продукции требованиям?

Цель вопроса. П. 6.4 — для ИТ это не только климат офиса, но шум, эргономика, режим удалённой работы, конфиденциальность рабочего места, нагрузка.

Область применения. HR, охрана труда, ИБ, руководители команд.

Критичность. Medium — среда влияет на дефекты и утечки.

Ожидаемые доказательства. Правила удалённой работы, требования к рабочему месту, политика «чистого стола»/экрана, оценка нагрузки, условия в серверных при наличии.

Как проверить. Опросить удалённых сотрудников об условиях. Проверить меры против утечки с домашних рабочих мест. Оценить переработки как фактор дефектов.

Типичные несоответствия. Нет правил удалённой работы; производственная среда понята только как «офисный климат».

Учитываются ли при обеспечении компетентности подрядный и временный персонал, а также совместители, если их работа влияет на соответствие продукции?

Цель вопроса. Пособие и практика аудита: компетентность относится ко всем, кто влияет на продукт.

Область применения. Закупки, HR, руководители проектов с аутстаффом.

Критичность. High — скрытый контур риска в ИТ.

Ожидаемые доказательства. Договоры, требования к квалификации в SOW, проверки резюме/портфолио, доступы по принципу least privilege, записи ввода в проект.

Как проверить. Выбрать 3 внешних исполнителя в активных проектах. Есть ли подтверждение компетентности и ввод в процессы СМК (стандарты кодирования, ИБ).

Типичные несоответствия. Аутстафф не в матрице компетенций; доступы выданы без ввода в стандарты.

Планируется ли замена критичных компетенций (ключевые архитекторы, ML-специалисты, единственный аудитор), чтобы СМК не зависела от одного человека?

Цель вопроса. Рекомендация для малых организаций: совмещение ролей усиливает риск «единой точки отказа».

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

Критичность. Medium — устойчивость СМК.

Ожидаемые доказательства. Планы преемственности, парное ведение знаний, документирование уникальных практик.

Как проверить. Выявить роли, которые занимает один человек. Проверить наличие дублирования знаний и записей.

Типичные несоответствия. Только один человек умеет собирать релиз или проводить внутренний аудит.

Обеспечена ли инфраструктура мониторинга услуг (логи, APM, мониторинг моделей, резервное копирование), достаточная для выполнения требований 7.5 и 8.2?

Цель вопроса. Связка 6.3 и измерения: без телеметрии нельзя доказать соответствие услуги.

Область применения. DevOps, сопровождение, MLOps, ИБ.

Критичность. High — для цифровых услуг инфраструктура наблюдения — часть качества.

Ожидаемые доказательства. Перечень систем мониторинга, регламенты алертинга, хранение логов, дашборды SLO.

Как проверить. По 2 продуктивным сервисам проверить наличие мониторинга, ответственного и реакции на алерт. Связать с критериями процесса.

Типичные несоответствия. Мониторинг только «жив/не жив»; нет логов аудита доступа; модель ИИ без мониторинга дрифта.

Планируются ли и разрабатываются ли процессы, необходимые для жизненного цикла продукции (услуги), согласованные с требованиями к другим процессам СМК?

Цель вопроса. П. 7.1 — планирование реализации: качество не «проверяется в конце».

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

Критичность. High — хаотичная поставка без плана качества.

Ожидаемые доказательства. Планы качества проекта, шаблоны kick-off, определения этапов (discovery, design, build, release, hypercare), записи планирования.

Как проверить. По 3 проектам разного типа (консалтинг, кастомное ПО, внедрение ИИ) проверить, что до старта определены требования, документы, верификация, валидация, записи, ресурсы.

Типичные несоответствия. Проект стартует с код-райтинга без плана приёмки; нет определённых записей качества.

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

Цель вопроса. Полный перечень п. 7.1 a)–d).

Область применения. PM, QA, архитектура.

Критичность. High — пропуск валидации/записей типичен для Agile-команд без встроенного качества.

Ожидаемые доказательства. План качества / Quality gates в пайплайне, чек-листы этапов, DoR/DoD.

Как проверить. Сверить quality gates с 7.1. Убедиться, что «гибкость» не отменяет верификацию и записи.

Типичные несоответствия. DoD не включает проверки безопасности; нет записей ревью.

Определяются ли требования, относящиеся к продукции: установленные потребителем (включая поставку и постпоставку), не заявленные им, но необходимые для известного или предполагаемого использования, законодательные и нормативные, а также любые дополнительные требования организации?

Цель вопроса. П. 7.2.1 — полнота требований, включая невысказанные и обязательные.

Область применения. Продажи, пресейл, аналитика, юристы, ИБ.

Критичность. Critical — неполная фиксация требований = главный источник претензий.

Ожидаемые доказательства. Брифы, ТЗ, user stories с критериями приёмки, чек-лист обязательных требований, SLA/OLA, перечень законодательных требований к услуге.

Как проверить. По 3 договорам/ТЗ проверить все группы 7.2.1 a)–d). Отдельно — постпоставка (поддержка, обновления моделей) и обязательные требования (ПДн, криптография, лицензии).

Типичные несоответствия. В ТЗ только функционал; поддержка не определена; ПДн не учтены.

Проводится ли анализ требований, относящихся к продукции, до принятия обязательства поставлять продукцию потребителю, и ведутся ли записи результатов анализа и последующих действий?

Цель вопроса. П. 7.2.2 — запрет обещать то, что организация не может выполнить.

Область применения. Продажи, пресейл, инженерия, юристы.

Критичность. Critical — срыв обязательств и «продажа воздуха» по ИИ-возможностям.

Ожидаемые доказательства. Записи анализа оферты/договора/change request, чек-листыfeasibility, согласования емкости команды и ограничений моделей.

Как проверить. Выбрать 5 принятых обязательств (договор, SOW, change). Есть ли анализ до подписи: требования определены, разногласия сняты, способность подтверждена. Проверить изменения после заключения.

Типичные несоответствия. Договор подписан без инженерной оценки; завышены возможности модели ИИ; изменения в чате без анализа.

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

Цель вопроса. П. 7.2.3 — каналы должны быть управляемыми.

Область применения. Аккаунтинг, поддержка, продажи, продукт.

Критичность. High — потеря жалобы или изменения объёма — классическое несоответствие.

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

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

Типичные несоответствия. Жалобы в мессенджере менеджера не регистрируются; изменения объёма не попадают в бэклог.

Обеспечивается ли анализ изменений требований к продукции и доведение изменений до соответствующего персонала?

Цель вопроса. Часть п. 7.2.2 применительно к изменениям — критично в Agile и консалтинге.

Область применения. PM, аналитика, разработка, тестирование, поддержка.

Критичность. High — «уже договорились в чате» ломает конфигурацию поставки.

Ожидаемые доказательства. Change log, версии ТЗ, уведомления команде, обновлённые тест-планы.

Как проверить. Взять 3 изменения mid-project. Проверить анализ влияния, запись, доведение до QA и сопровождения.

Типичные несоответствия. Код изменён, тесты и документация пользователя — нет.

Фиксируются ли требования к постпоставляемой деятельности (сопровождение, SLA, обновление моделей, гарантийные консультации) как часть требований к продукции?

Цель вопроса. Для ИТ-услуг постпоставка часто составляет основную ценность.

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

Критичность. High — разрыв между проектом и эксплуатацией.

Ожидаемые доказательства. Договорные разделы поддержки, runbook передачи в support, KPI сопровождения, правила обновления моделей.

Как проверить. Проверить 2 проекта, перешедших в сопровождение: полнота передачи, измеримость SLA, владелец постпоставки.

Типичные несоответствия. После релиза команда расформирована без передачи; SLA не измерены.

Выявляются ли предполагаемые (не заявленные явно) требования, необходимые для известного использования услуги — например, производительность, безопасность, объяснимость модели, совместимость, доступность?

Цель вопроса. П. 7.2.1 b) особенно важен в цифровом консалтинге и ИИ.

Область применения. Архитектура, ИБ, пресейл, ML.

Критичность. High — заказчик «подразумевал безопасность».

Ожидаемые доказательства. Чек-листы неявных требований, threat model, NFR в ТЗ, гайдлайны ответственного ИИ.

Как проверить. По проектам ИИ и кастомного ПО проверить наличие NFR. Спросить архитектора, как выявляются подразумеваемые требования.

Типичные несоответствия. NFR отсутствуют; модель без требований к смещению и мониторингу.

Планируются ли и управляются ли проектирование и разработка (включая архитектуру ПО, дизайн услуги и разработку моделей ИИ), если эти процессы применимы и не исключены обоснованно?

Цель вопроса. П. 7.3.1 — для кастомного ПО и ИИ исключение 7.3 как правило недопустимо.

Область применения. Архитектура, разработка, ML, UX, консалтинговые методологии.

Критичность. Critical — проектирование есть, а процесса 7.3 нет — частое критическое несоответствие.

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

Как проверить. Убедиться, что 7.3 не исключён. По 2 проектам проверить планирование стадий design/develop, межгрупповое взаимодействие (backend/ML/security).

Типичные несоответствия. 7.3 исключён при наличии кастомной разработки; нет плана проектирования.

Определены ли входные данные проектирования и разработки, включая функциональные и эксплуатационные требования, применимые законодательные требования, информацию предыдущих аналогичных проектов и другие существенные требования, и проводится ли анализ этих входов?

Цель вопроса. П. 7.3.2 — качество входа определяет качество выхода.

Область применения. Аналитика, архитектура, ИБ, юристы.

Критичность. High — «размытое ТЗ» на входе проектирования.

Ожидаемые доказательства. Дизайн-брифы, architecture decision records (ADR), перечни ограничений, результаты анализа входов, записи.

Как проверить. Проверить полноту входов и факт их анализа (непротиворечивость, достаточность). Есть ли уроки прошлых проектов.

Типичные несоответствия. Входы не документированы; противоречия ТЗ не сняты до старта разработки.