понедельник, 10 августа 2026 г.
Как научиться учиться в сфере управлении информацией и документами
Сколькие из нас [специалистов по управлению документами – Н.Х.] считают свои политики ошибочными?
Крис Арджурис (Chris Argyris) является автором моей любимой публикации об обучении. Он описывает обучение как «обнаружение и исправление ошибок».
Мой комментарий: Крис Арджурис (Chris Argyris, 1923-2013 – на фото) - американский теоретик бизнеса, профессор Йельской школы менеджмента и Гарвардской школы бизнеса. Стал пионером концепции «развития организации» (organization development). Известен своими основополагающими работами по обучающимся организациям.
Под «ошибками» он понимает «любое несоответствие между намерением и результатом» и далее утверждает, что доказательством обучения является наша способность применять полученные знания – то, что мы способны исправить ошибку.
С этой точки зрения, сколькие из наших политик являются ошибочными? Сколько из них приводят к желаемым результатам? И сколькие из наших практик следует считать ошибочными?
Здесь моим любимым примером (как многие из вас знают) является функциональная классификация (классификация документов в зависимости от тех деловых процессов, в которых они участвуют – в отличие, например, от структурной классификации, где основных фактором является то, какое именно структурное подразделение создаёт или обрабатывает документы – Н.Х.).
Цель функциональной классификации заключается в формировании структур, которые не придётся менять с течением времени. В результате обычно получается система, которая охватывает менее 10% от того, что первоначально предполагалось охватить, потому что она не поддерживает те способы, которые используются сотрудниками для организации и управления своей работой.
А что насчет наших жизненных циклов? Обычно мы [специалисты по управлению документами – Н.Х.] заявляем, что целью управления жизненным циклом является снижение юридических рисков и затрат, - и это очень убедительный аргумент.
Здравый смысл подсказывает, что такие результаты будут достигнуты, если мы будем управлять жизненным циклом. Но измерили ли мы полученные результаты? Каждый раз, когда я это делаю, я обнаруживаю, что достигнутое снижение затрат меркнет по сравнению с инвестициями, необходимыми для его достижения.
Общий принцип проектирования указаний по срокам хранения и действиям по их истечении также заключается в том, что мы уничтожаем документы после исполнения соответствующих законодательно-нормативных требований - поэтому можно утверждать, что такая практика устраняет риски в тот момент, когда риски уже исчезли.
Крис Арджурис также десятилетиями изучал поведение с целью «самозащиты», основная функция которого заключается в препятствовании обнаружения ошибки либо её исправлению.
По крайней мере, на протяжении трёх десятилетий уровень ошибок в основных практиках управления документами растёт, и мы используем инстинкты самозащиты.
Это вполне объяснимое поведение, и одному из основных факторов, лежащих в основе проблемы, даже посвящена отдельная книга – концепция «дилеммы новатора» (innovators dilemma) описывает, каким именно образом системы стимулирования мешают реагировать на изменения организациям, в которых уже сложились процессы деловой деятельности.
Однако ясно одно: нам [специалистам по управлению документами – Н.Х.] действительно нужно меняться.
Путь изменений заключается в том, чтобы сфокусировать внимание на результате, а затем спросить себя, обеспечивают ли существующие практики его достижение - и есть ли иные способы.
Что касается политик, то можно задать вопрос - приводит ли повторение лучших практик ISO 15489 и требований законодательства к созданию высококачественной документации и к исполнению законодательно-нормативных требованиям? Нет? А какие практики могли бы это обеспечить?
Говоря о классификации - обеспечивает ли функциональная классификация высокие показатели захвата документов в специализированные системы для управления документами и контентом, а также формирование агрегаций транзакций, которыми легко управлять? Нет? Какие другие варианты возможны? На какие компромиссы приходится идти при использовании альтернативных вариантов?
Снижает ли затраты и риски управление жизненным циклом таким образом, как мы это делаем сейчас? Нет? Каким ещё образом мы могли бы достичь нужных результатов?
Мы действительно сталкиваемся с проблемой «дилеммы новатора», заключающейся в том, что стимулы работают против нас. Мы внедряем передовые практики, и наш подход носит защитный характер – ведь передовая практика остаётся передовой практикой, даже если терпит неудачу. Позитивным фактором является то, что у нас теперь есть стандарт системы менеджмента документов ISO 303001, основанный на цикле Деминга управления качеством «Спланируй – Сделай – Проверь – Улучши» (Plan -Do-Check-Act). В основе цикла управления качеством лежит обучение – мы планируем достижение результата, реализуем этот план, проверяем его выполнение и принимаем меры для закрепления или изменения этого плана.
Я полагаю, что все наши организации поддержат нас в этих усилиях, если мы представим их правильным образом - как возможность улучшить показатели эффективности и производительности деловой деятельности. Организации хотят повышения эффективности, и они искренне хотят того, что мы обещаем. Однако ответственность за первый шаг целиком ложится на нас, и это выявление ошибок. Что мы хотим получить, внедряя тот или иной метод или практику, будет ли это желаемый результат?
Карл Мелроуз (Karl Melrose)
Источник: блог Meta-IRM
https://metairm.substack.com/p/learning-how-to-learn-in-information
ИСО: Заканчивается публичное обсуждение проекта стандарта ISO/DIS 24495-4 «Простой язык – Часть 4: Требования к внедрению принципов простого языка в организациях»
До 11 августа 2026 года есть возможность индивидуально принять участие в публичном обсуждении данного стандарта на сайте Британского института стандартов (BSI) по адресу https://standardsdevelopment.bsigroup.com/projects/2024-02974 (при условии регистрации на сайте).
Стандарт разработан техническим комитетом ИСО TC37 «Язык и терминология» (Language and terminology). О других частях стандарта ISO 24495 «Простой язык» см. также подборку моих постов на блоге: http://rusrim.blogspot.com/search/label/стиль%20языка . О работе над частью 4 я также рассказывала здесь: http://rusrim.blogspot.com/2026/06/iso-24495-32026-3.html .
Во вводной части документа отмечается:
«В настоящем документе признается и разъясняется основополагающая роль обмена информацией на простом языке как приоритета организации. Обмен информацией считается проходящим на простом языке, если информация актуальна, легкодоступна, понятна и удобна в использовании. Простой язык делает информацию доступной как для экспертов в предметных областях, так и для тех, кто такими экспертами не является.
В документе сформулированы требования к организациям в части внедрения принципов простого языка и последовательного использования информационного обмена на простом языке. Эти требования позволят организациям следовать четырем принципам простого языка стандарта ISO 24495-1. Это также позволит организациям получить следующие преимущества от использования простого языка:
- Более ясный, прямой и эффективный обмен информацией, что важно для успеха любой организации;
- Снижение потребности в уточнениях и передаче дополнительных сведений, что приводит к значительной экономии времени и средств в деятельности всех структурных подразделений и служб организации;
- Снижение количества недопониманий и ошибок, благодаря чему смягчаются риски и улучшается соответствие законодательно-нормативным требованиям и политикам;
- Повышение инклюзивности за счет большей доступности информации;
- Большая согласованность в применении простого языка внутри организации и между организациями;
- Повышение доверия и укрепление взаимоотношений между организацией и её аудиторией;
- Повышение удовлетворенности аудитории.
Данный документ охватывает ключевые требования к внедрению принципов простого языка. Существуют и иные полезные руководства и требования, которые могут дополнить данный стандарт - например, другие части стандарта ISO 24495 и стандарты серии ISO 9000.
В настоящем документе также признаётся, что организации иногда разрабатывают документы с использованием искусственного интеллекта (ИИ). Рекомендации по использованию систем ИИ в общем случае см. в стандарте ISO/IEC 42001:2023 «Информационные технологии – Искусственный интеллект - Система менеджмента» (Information technology - Artificial intelligence - Management system, см. https://www.iso.org/standard/81230.html и https://www.iso.org/obp/ui/en/#!iso:std:81230:en - а также мой пост https://rusrim.blogspot.com/2023/12/isoiec-420012023.html - Н.Х.).
… В настоящем документе изложены применимые в любой организации требования в части систематического внедрения простого языка. Он основан на стандарте ISO 24495-1:2023, в котором подчеркивается важность простого языка и устанавливаются его принципы.
Данные требования применимы к любой организации, независимо от размера и сектора. Они распространяются на новые и существующие документы, независимо от того, разработаны ли они с использованием ИИ или без него.
Примечание: Рекомендации по обеспечению доступности электронных документов см. в стандарте ISO/IEC DIS 40500 «Информационные технологии - Рекомендации концерна W3C по доступности веб-контента (WCAG) 2.2» (Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.2, см. https://www.iso.org/standard/94018.html и https://www.iso.org/obp/ui/en/#!iso:std:94018:en , а также мой пост http://rusrim.blogspot.com/2026/05/isoiec-dis-40500-w3c-wcag-22.html - Н.Х.) в европейском стандарте EN 301 549 «Требования по обеспечению доступности для ИКТ-продуктов и услуг» (Accessibility requirements for ICT products and services, см. https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=59546 - текущей является версия 3.2.1 от 19 марта 2021 года, доступная по адресу https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf - Н.Х.).»
Содержание стандарта следующее:
Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Руководящие принципы и концептуальная структура
5. Требования к разработке контента на простом языке
6. Требования к продвижению и поддержанию использования простого языка
Библиография
Источник: сайт ИСО / сайт BSI
https://www.iso.org/standard/90061.html
https://standardsdevelopment.bsigroup.com/projects/2024-02974
Обеспечение защиты информации при использовании искусственного интеллекта (ИИ), часть 1
Методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» был утвержден ФСТЭК России 12 апреля 2026 года.
В раздел III «Мероприятия (процессы) по защите информации, содержащейся в информационных системах органов (организаций)» включён п.3.18 «Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)».
Главная цель - исключение возможности несанкционированного доступа к информационным системам и информации при использовании систем искусственного интеллекта (систем ИИ).
Посредством проведения мероприятий по обеспечению защиты информации при использовании систем ИИ должна быть исключена возможность нарушения конфиденциальности, целостности и доступности информации, обрабатываемой в системе, за счет действий внешних и внутренних нарушителей.
При создании систем ИИ оператором (обладателем информации) должна быть проведена оценка угроз безопасности информации, связанных с разработкой и эксплуатацией системы. Сведения об угрозах безопасности информации систем ИИ содержатся в банке данных угроз безопасности информации ФСТЭК России.
По результатам оценки угроз безопасности информации должно быть разработано техническое задание, содержащее требования к реализации мер защиты информации в системе ИИ.
При разработке системы ИИ должна быть обеспечена защита следующих объектов:
- Объекты информационной инфраструктуры разработки системы ИИ;
- Программное обеспечение, обеспечивающее разработку системы ИИ (подготовка наборов обучающих данных, обучение и тестирование моделей ИИ), в том числе входящие в его состав фреймворки, библиотеки, иные инструменты;
- Программное обеспечение, обеспечивающее разработку API-интерфейсов, агентов, системы фильтрации входных и выходных данных;
- Входная модель ИИ, используемая для разработки (обучения) выходной модели ИИ (при наличии);
- Наборы обучающих данных;
- Выходная модель искусственного интеллекта и ее параметры (веса);
- Программное обеспечение, обеспечивающее реализацию технологий ИИ (модели ИИ), а также агентов ИИ, API-интерфейсов, систем фильтрации (контроля) входных и выходных данных.
В информационной инфраструктуре разработки системы ИИ должны быть реализованы меры по защите информации по классу защищенности не ниже класса защищенности информационной системы оператора (обладателя информации).
Дополнительно в информационной инфраструктуре разработки должны быть обеспечены:
- Выделение информационной инфраструктуры разработки системы ИИ от иной инфраструктуры разработчика, не связанной с разработкой данной системы, в отдельный изолированный сегмент;
- Отказ от использования небезопасных форматов обработки и хранения данных (например, pickle) и применение безопасных форматов данных (ONNX, protobuf и другие форматы);
- Целостность программного обеспечения, реализующего разработку системы ИИ.
В информационной инфраструктуре разработки системы ИИ не допускается решение задач, не связанных с разработкой системы ИИ.
В отношении наборов обучающих данных должны быть обеспечены:
- Применение в приоритетном порядке наборов обучающих данных из доверенных источников (например, информационные системы государственных органов, организаций и учреждений, значимые объекты критической информационной инфраструктуры Российской Федерации);
- Антивирусная проверка обучающих данных на предмет наличия в них вредоносного программного обеспечения;
- Хранение обучающих данных в обособленном хранилище;
- Целостность обучающих данных.
При использовании входной модели ИИ должен быть проведен анализ сведений об уязвимостях указанной модели, получаемых из внешних источников (базы данных известных уязвимостей, официальные ресурсы разработчиков программных средств, специализированные публикации, форумы, иные источники). В отношении выявленных уязвимостей разработчиков системы искусственного интеллекта должны быть приняты меры, направленные на нейтрализацию выявленных уязвимостей.
В отношении программного обеспечения, обеспечивающего разработку и эксплуатацию системы ИИ, должен быть проведен анализ уязвимостей программного обеспечения на основании данных, получаемых из внешних источников (базы данных известных уязвимостей, официальные ресурсы разработчиков программных средств, специализированные публикации, форумы, иные источники), и приняты меры по их устранению.
При эксплуатации системы ИИ в информационной системе должна быть обеспечена защита следующих объектов:
- Объекты информационной инфраструктуры, обеспечивающей эксплуатацию системы ИИ;
- Программное обеспечение, обеспечивающее реализацию технологий ИИ (модели ИИ), а также агентов искусственного интеллекта, API-интерфейсов, систем фильтрации (контроля) входных и выходных данных;
- Обученная и готовая к использованию модель ИИ, ее расширения (LoRA, RAG и другие расширения (при необходимости).
В случае если для эксплуатации системы ИИ используется инфраструктура, не входящая в информационную систему оператора, то в такой инфраструктуре должны быть реализованы меры по защите информации по классу защищенности не ниже класса защищенности информационной системы оператора (обладателя информации).
В случае применения технологии ИИ в составе информационной системы оператором (обладателем информации) должны быть приняты меры защиты информации, направленные на предотвращение несанкционированного доступа или воздействия на систему ИИ, в соответствии с требованиями по защите информации (обеспечению безопасности), в том числе меры по:
- Идентификации и аутентификации пользователей системы ИИ;
- Управлению доступом пользователей системы ИИ;
- Контролю (фильтрации) входных и выходных данных;
- Обеспечению изоляции системы ИИ;
- Защите данных системы ИИ;
- Защите от вредоносного программного обеспечения;
- Выявлению уязвимостей в системе ИИ;
- Ограничению и контролю функциональности системы ИИ.
В информационной системе при эксплуатации системы ИИ дополнительно должны быть реализованы следующие меры защиты информации:
- Обеспечение фильтрации (контроля) входных данных (запросов) системы ИИ;
- Обеспечение фильтрации (контроля) выходных данных (ответов) системы ИИ;
- Мониторинг и квотирование количества запросов к системе искусственного интеллекта;
- Обеспечение регистрации событий безопасности, связанных с запросами к системе ИИ и ее ответами;
- Обеспечение целостности параметров (весов) модели ИИ и конфигурации системы ИИ.
(Окончание следует)
Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=531896
воскресенье, 9 августа 2026 г.
Одна архитектура, несколько заявлений о соответствии
В посте сопоставляются положения стандартов ISO/IEC 42001 и EN 18286 – показывается, где эти положения совпадают, где имеются различия, - а также обсуждается вопрос о том, что нужно сделать до публикации в Официальном журнале Евросоюза нормативно-правовых актов, непосредственно ссылающихся на EN 18286 [т.е. делающих положения этого стандарта обязательными – Н.Х.].
На этой неделе (22 июля 2026 года – Н.Х.) был опубликован новый европейский стандарт EN 18286:2026 «Искусственный интеллект - Система менеджмента качества для поддержки исполнения требований Закона ЕС об искусственном интеллекте». Не прошло и нескольких часов, как один и тот же вопрос был поднят и в комментариях под моими постами, и в поступающей электронной почте, и, судя по всему, буквально на всех европейских совещаниях по вопросам исполнения законодательно-нормативных требований: «У нас уже есть система менеджмента качества для ИИ ISO/IEC 42001. Нужна ли нам теперь ещё одна такая система менеджмента?».
Мой комментарий: Здесь упоминается стандарт ISO/IEC 42001:2023 «Информационные технологии – Искусственный интеллект - Система менеджмента» (Information technology - Artificial intelligence - Management system, см. https://www.iso.org/standard/81230.html и https://www.iso.org/obp/ui/en/#!iso:std:81230:en - а также мой пост https://rusrim.blogspot.com/2023/12/isoiec-420012023.html . В России данный стандарт был адаптирован как ГОСТ Р ИСО/МЭК 42001-2024 «Искусственный интеллект. Система менеджмента», см. https://protect.gost.ru/gost/details/3cb023c3-e628-45ad-b233-65e3d175eb10 , а также мой пост http://rusrim.blogspot.com/2025/01/42001-2024.html .
Краткий ответ, который я дал в рамках одного из таких обсуждений, следующий: чем меньше, тем лучше - нужна одна система менеджмента, на основе которой может быть сделан ряд заявлений о соответствии. Этот вопрос требует более развёрнутого ответа.
Одна и та же структура, разные «хозяева»
Оба стандарта построены на основе гармонизированной структуры систем менеджмента: разделы с 4 по 10 охватывают аспекты, начиная от контекста (условий ведения деятельности) организации и лидерства, рассматривая далее вопросы планирования, поддержки, эксплуатации, оценки эффективности и совершенствования. Если Вы используете систему менеджмента ИИ на основе стандарта ISO 42001, то содержание стандарта EN 18286 покажется Вам знакомым. Это сделано намеренно – европейский технический комитет по стандартизации CEN/CENELEC JTC21 разработал этот стандарт с прицелом на его интеграцию с ISO 9001 (стандарт системы менеджмента качества – Н.Х.), ISO 13485 (стандарт менеджмента качества медицинских изделий – Н.Х.) и ISO/IEC 42001.
Однако эти два стандарта отвечают на разные вопросы. Стандарт ISO/IEC 42001 отвечает на вопрос: «Ответственно ли эта организация управляет своим ИИ?». Стандарт EN 18286 отвечает на другой вопрос: «Может ли этот поставщик использовать систему менеджмента качества, способную продемонстрировать соответствие требованиям Закона об ИИ для систем ИИ высокого риска, начиная со статьи 17 и заканчивая поддерживающими обязательствами, которые должна обеспечивать система менеджмента качества?». Первый вопрос - это вопрос уверенности в организации. Второй вопрос – это вопрос доказательств, наличия которых требует законодательство, в привязке к конкретным системам. Именно это различие, если о нём всё время помнить, делает сопоставление стандартов полезным, а не вводящим в заблуждение.
Где содержание разделов совпадает, и где имеются отличия
- Раздел 4 «Контекст (условия ведения деятельности)». Оба стандарта требуют определить сферу охвата масштаба и заинтересованные стороны. Расширением в EN 18286 является то, что сфера охвата должна быть описана в соответствии с классификацией, введённой в европейском Законе об ИИ - какие из Ваших систем относятся к системам высокого риска, и какие требования применимы к каждой из них.
- Раздел 5 «Лидерство». Оба стандарта требуют наличия политики, определения ролей и подотчётности. Расширение в EN 18286: подотчётность должна соответствовать обязательствам поставщика — в конечном итоге, обеспечение подотчётности ложится на поставщика, ответственном за выдачу Декларации соответствия ЕС (EU Declaration of Conformity).
- Раздел 6 «Планирование». ISO/IEC 42001 предусматривает оценку рисков и оценку воздействия ИИ. EN 18286 должен включать систему менеджмента риска, предусмотренную статьей 9 Закона об ИИ – непрерывно действующую, итеративную, охватывающую весь жизненный цикл и документированную надлежащим образом.
- Раздел 7 «Поддержка». Компетенции, управление документами, информационный обмен Расширением в EN 18286 является стратегическое управление данными в смысле статьи 10 Закона об ИИ: происхождение, репрезентативность и проверка на наличие предвзятости для обучающих, валидационных и тестовых данных.
- Раздел 8 «Эксплуатация». Именно в этом разделе сосредоточена большая часть расхождений: контроль и верификация архитектуры, тестирование, техническая документация в соответствии с Приложением IV Закона об ИИ, протоколирование, меры надзора со стороны человека и надзор над поставщиками по всей цепочке создания продукта.
- Раздел 9 «Оценка эффективности». Оба стандарта говорят о внутреннем аудите и анализе, проводимом руководством. В EN 18286 данный раздел включает постмаркетинговый мониторинг в соответствии со статьей 72 Закона об ИИ.
- Раздел 10 «Совершенствование». Корректирующие действия предусмотрены в обоих стандартах. В EN 18286 добавляется отчетность о серьезных инцидентах в соответствии со статьей 73 Закона об ИИ и структурированный обмен информацией с компетентными органами.
- В отношении чего обеспечивается уверенность. Сертификат соответствия ISO/IEC 42001 подтверждает соответствие организации; в то время, как доказательства соответствия EN 18286 относятся к системе ИИ. Соответственно организуется проверка соответствия: аудитор или орган по надзору за рынком не будет запрашивать Вашу политику - они запросят дело на конкретную систему ИИ.
- Техническая документация. Документация, предусмотренная Приложением IV Закона об ИИ, не является результатом разовых усилий. Для неё должно быть обеспечено управление версиями, она должна быть актуальной и способной надёжно поддерживать реконструкцию того, что представляет собой система, как она была создана и как она себя ведёт.
- Временные рамки создания и представления доказательств. Протоколирование (ведение журналов аудита), постмаркетинговый мониторинг и отчетность об инцидентах - все это происходит в соответствии с определёнными временными рамками. Документы должны быть датированы, должен быть контроль их версий, и они должны быть прослеживаемыми до принятого решения. Документы должны представляться по запросу, а не восстанавливаться «задним числом».
- Юридическая сила. Сертификация на соответствие ISO/IEC 42001 никогда не подразумевала презумпции соответствия европейскому Закону об искусственном интеллекте. Сертификация на соответствие EN 18286 будет подразумевать такую презумпцию - но только после того, как стандарт будет прямо упомянут в подзаконных нормативных актах, опубликованных в Официальном журнале Евросоюза. Пока не будет это не произойдёт, соответствие EN 18286 будет лишь наилучшим из имеющихся подходов, но не гарантированной «безопасной гаванью».
Рекомендуемая мной последовательность действий на практике следующая:
- Ведите один комплект документации. Вместо создания параллельного руководства по качеству, расширьте перечень документов, требуемых для соответствия ISO/IEC 42001, добавив элементы статьи 17 Закона об ИИ.
- Проведите, раздел за разделом, анализ на предмет расхождений между разделами. Большинство разделов ISO/IEC 42001 нуждаются в расширении, а не в замене - эта работа менее трудозатратная, чем может показаться тем, кто паникует; но она более сложная, чем просто поиск и замена текста.
- Расширьте реестр рисков, добавив категории из статьи 9 Закона об ИИ, и сохраните оценку воздействия ИИ. Эта оценка отвечает на вопросы, которые статья 27 Закона об ИИ все равно задаст некоторым внедряющим системы ИИ организациям.
- Создайте техническую документацию на систему ИИ (дело системы ИИ) в соответствии с Приложением IV Закона об ИИ для каждой системы ИИ высокого риска; и рассматривайте это дело как живой артефакт, у которого должен быть владелец, а не как некое вспомогательное приложение.
- Включите постмаркетинговый мониторинг в раздел 9, а отчетность о серьёзных инцидентах - в раздел 10, вместо с отрепетированными (а не просто задокументированными) сроками, предусмотренными статьей 73 Закона об ИИ.
- Отрепетируйте исполнение запросов на представление доказательств. Способны ли Вы представить документы, подтверждающие, что именно сделала конкретная система, по какой причине, и были ли эти действия авторизованы, - немедленно или в течение срока, установленного регулирующим органом? Именно в этом вопросе оба стандарта сходятся.
Гармонизация европейского законодательства со стандартом EN 18286, когда она наступит, вознаградит организации, уже работающие в соответствии с ним - презумпция соответствия не чем-то, что можно быстренько обеспечить уже после получения запроса на информацию. Организации, которые рассматривают EN 18286 чисто как упражнение в документировании, в итоге получат две папки документов там, где раньше была одна. Те же, кто придерживается подхода единой архитектуры доказательств, заставят одну систему менеджмента поддерживать заявления о соответствии обоим стандартам.
Точка слияния этих двух стандартов является не нумерация пунктов, а доказательства: готовая к аудиту, понятная человеку документация, фиксирующая, что конкретная система выполнила именно то, на что она была авторизована. Создайте такую документацию, и большая часть процесса сопоставления стандартов произойдёт сама собой.
Майкл Холл (Michael Hall)
Источник: сайт LinkedIn
https://www.linkedin.com/pulse/one-architecture-multiple-conformity-claims-michael-hall-290ie/







