Сертификация по ГОСТ Р 53624-2009 нужна организациям, которые разрабатывают, поставляют, эксплуатируют или сопровождают программное обеспечение и должны подтвердить управляемость качества в ИТ-процессах. Этот стандарт не про менеджмент знаний. Его область — информационные технологии, информационно-вычислительные системы, программное обеспечение и требования к системе менеджмента качества при создании ПО.
ГОСТ Р 53624-2009 применяют, когда заказчику важно видеть не только готовую программу, но и порядок её разработки: требования, проектирование, кодирование, тестирование, выпуск, сопровождение, управление изменениями, исправление дефектов и ответственность команды. Стандарт может использоваться при подготовке СМК к сертификации, повышении результативности процессов и поддержании работоспособности уже сертифицированной системы.
Сертификация по ГОСТ Р 53624-2009: что проверяют
Аудитор смотрит, есть ли у компании управляемый жизненный цикл программного обеспечения. Если требования заказчика меняются в переписке, дефекты теряются между разработчиком и тестировщиком, релизы выкатываются без протокола, а сопровождение живёт отдельно от разработки, СМК будет слабой. Нужны не только регламенты, но и записи по реальным проектам.
| Блок | Что готовят | Типичная проблема |
|---|---|---|
| Требования | ТЗ, backlog, согласования, изменения, критерии приёмки | Заказчик меняет требования устно, следов решения нет |
| Разработка | Планы, роли, архитектура, код-ревью, контроль версий | Процесс зависит от конкретных разработчиков |
| Тестирование | Тест-планы, протоколы, дефекты, повторная проверка | Ошибки исправляют, но причины не анализируют |
| Сопровождение | Релизы, обращения, исправления, эксплуатационная документация | Поддержка не связана с разработкой и управлением изменениями |
Кому подходит стандарт
ГОСТ Р 53624-2009 полезен разработчикам заказного ПО, интеграторам, поставщикам информационных систем, компаниям сопровождения, разработчикам встроенного ПО, SaaS-проектам, подрядчикам государственных и корпоративных заказчиков. Особенно если в договоре важны прослеживаемость требований, качество поставки, сопровождение, работа с дефектами и управляемость изменений.
Сертификат может потребоваться в тендере или при квалификации ИТ-поставщика. Но реальная ценность шире: меньше спорных требований, понятнее статус релиза, проще доказывать качество работ, легче передавать проект между командами и поддерживать продукт после внедрения.
Когда ГОСТ Р 53624-2009 не нужен
Если компания делает разовые небольшие сайты, не участвует в закупках с требованиями к СМК и не сопровождает сложные системы, отдельная сертификация может быть лишней. В таком случае достаточно нормального договора, технического задания, контроля версий, тестирования и понятного порядка передачи результата заказчику.
Стандарт не заменяет сертификацию средств защиты информации, регистрацию российского ПО, лицензии ФСТЭК или ФСБ, требования по персональным данным, аттестацию информационных систем и испытания по специальным методикам. Он относится к системе менеджмента качества процессов разработки и сопровождения ПО.
Сроки и стоимость
В карточке услуги указана стоимость от 8000 рублей и срок 25-30 рабочих дней. Если у компании уже есть ISO 9001, система управления задачами, репозиторий, тестовая документация, релизный порядок и поддержка, подготовка идёт быстрее. Если процессы живут в чатах, а документы собираются только перед сдачей проекта, потребуется больше времени на восстановление прослеживаемости.
| Состояние ИТ-процессов | Что делаем | Ориентир |
|---|---|---|
| Есть ISO 9001 и SDLC | Дорабатываем требования ГОСТ Р 53624-2009, записи, аудит | 20-25 рабочих дней |
| Процессы есть, документов мало | Описываем жизненный цикл, роли, тестирование, релизы | 25-30 рабочих дней |
| Проекты ведутся хаотично | Сначала выстраиваем минимальный управляемый процесс | после диагностики |
Какие документы потребуются
Обычно нужны область применения СМК, политика и цели качества, порядок управления требованиями, проектированием, разработкой, тестированием, релизами, сопровождением, конфигурациями, изменениями, дефектами, документацией и поставщиками. Отдельно готовят формы записей: протоколы согласования требований, планы проекта, тест-кейсы, отчёты о тестировании, реестр дефектов, акты приёмки, журнал изменений и результаты внутренних аудитов.
Для ИТ-компаний важно не дублировать инструменты бумажными формами. Если задачи ведутся в Jira, YouTrack, GitLab, Redmine или другой системе, можно использовать выгрузки и правила работы с ними. Главное — показать, что данные полные, управляемые и связаны с процессами качества.
Частые ошибки
Первая ошибка — описывать разработку слишком общо: “получаем требования, пишем код, тестируем”. На аудите нужны конкретные роли, входы, выходы, критерии готовности и записи. Вторая — разрывать разработку и сопровождение. Ошибка клиента после внедрения должна попадать в управление дефектами и изменениями, а не растворяться в переписке поддержки.
Третья ошибка — считать, что наличие репозитория и трекера задач уже является СМК. Инструменты помогают, но сами по себе не задают ответственность, критерии качества, анализ причин дефектов и управленческий контроль.
Кейс из практики
Разработчик корпоративной системы участвовал в закупке, где заказчик запросил подтверждение СМК для разработки ПО. У компании были сильные программисты и рабочий GitLab, но документы по качеству отставали от практики: требования фиксировались в разных местах, тестирование зависело от конкретного аналитика, релизные заметки не всегда совпадали с фактическим составом поставки.
Мы начали с одного завершённого проекта и восстановили цепочку: требование, задача, изменение кода, тестирование, дефект, исправление, релиз, приёмка. После этого оформили порядок управления требованиями, тестирования и релизов так, чтобы он совпадал с реальной работой команды. На аудите сотрудники объясняли процесс своими словами, а не читали чужой регламент.
Кому подходит услуга, а кому нет
Сертификация СМК разработки ПО закрывает конкретные запросы заказчиков. Проверьте себя по таблице, чтобы не оформлять документ, который вам не пригодится.
| Ситуация | Подходит? | Комментарий |
|---|---|---|
| Разработчик заказного ПО идёт в закупку, где требуется подтверждение СМК для разработки программ | Да | Восстанавливаем цепочку от требования до релиза по реальному проекту и готовим записи, которые выдержат аудит. |
| Интегратор сопровождает корпоративные системы, а поддержка живёт отдельно от разработки | Да | Связываем обращения, дефекты, изменения и релизы в один управляемый контур: ошибка клиента перестаёт растворяться в переписке. |
| SaaS-команда хочет показать корпоративным клиентам прозрачный релизный порядок | Да | Тест-планы, протоколы и журнал изменений строим на базе вашего трекера и репозитория, без бумажного дублирования. |
| Студия делает разовые небольшие сайты и в закупках не участвует | Нет | Хватит договора, технического задания, контроля версий и понятной передачи результата. Сертификация добавит расходов, а не пользы. |
| Нужно подтвердить безопасность ПО, аттестовать систему или получить допуск к защищаемой информации | Нет | Это поле сертификации средств защиты информации и лицензий ФСТЭК или ФСБ. Стандарт СМК такие требования не закрывает. |
| Разработчик встроенного ПО для приборов: заказчик спрашивает про управляемость изменений | Да | Выстраиваем управление конфигурациями и изменениями так, чтобы состав поставки всегда совпадал с релизными записями. |
Когда услуга не нужна
Если заказчик просит сертификат системы менеджмента качества на компанию в целом, без привязки к процессам разработки ПО, профильный стандарт можно не трогать. Такой запрос закрывает сертификация ISO 9001: она понятна любой закупочной комиссии, а ИТ-специфику добавляют позже, когда в тендере прямо появятся требования к жизненному циклу программ.
Не поможет сертификат СМК и там, где речь о защите информации. Когда компания собирается разрабатывать средства защиты конфиденциальной информации, ей понадобится лицензия ФСТЭК на СЗКИ, а для отдельных задач и сертификация самих средств защиты. Порядок разработки по ГОСТ Р 53624-2009 эти разрешения не заменяет, начинать нужно с лицензионных требований.
Для включения продукта в реестр российского ПО сертификат СМК тоже не требуется: у реестра собственные критерии, связанные с правами на программу и её происхождением. Если цель ограничивается регистрацией, тратиться на сертификацию не нужно; вернётесь к ней, когда корпоративный заказчик запросит подтверждение процессов разработки.
Как помогает «Реестр Гарант»
Мы сначала смотрим реальные ИТ-процессы: как принимаются требования, где ведутся задачи, как устроены репозитории, тестирование, релизы, поддержка и управление дефектами. Затем готовим документы по ГОСТ Р 53624-2009 без лишней бумажной нагрузки и помогаем собрать доказательства по действующим проектам.
Для первичной оценки можно связаться с «Реестр Гарант» по телефону +7 920-898-17-18, написать в WhatsApp или Telegram, либо отправить вводные на reestrgarant@mail.ru. В сообщении лучше указать тип ПО, число проектов, используемые системы управления задачами и кодом, наличие ISO 9001 и требования заказчика.
Частые вопросы
Отвечают специалисты «Реестр Гарант». Не нашли свой вопрос? Позвоните +7 920-898-17-18.
В.01 ГОСТ Р 53624-2009 относится к менеджменту знаний?
В.02 Это обязательная сертификация?
В.03 Нужен ли ISO 9001 перед ГОСТ Р 53624-2009?
В.04 Можно использовать данные из GitLab или Jira?
В.05 Задачи у нас в Jira, код в GitLab. Придётся переписывать всё это в бумажные регламенты?
В.06 У нас уже есть ISO 9001. Подготовка по ГОСТ Р 53624-2009 пройдёт быстрее?
В.07 Требования заказчик у нас меняет устно или в переписке. Это правда проблема для аудита?
Требования и условия
- описать область применения СМК для разработки, поставки или сопровождения ПО;
- наладить управление требованиями, проектированием, разработкой, тестированием и релизами;
- связать задачи, код, дефекты, изменения и приёмку в прослеживаемую систему;
- собрать записи по проектам, тестированию, дефектам, релизам, аудитам и улучшениям.
Необходимые документы
- карточка компании и описание сертифицируемых ИТ-процессов;
- ТЗ, backlog, планы проектов, регламенты разработки, тестирования и релизов;
- выгрузки из трекеров задач, репозиториев, реестров дефектов и систем поддержки;
- протоколы тестирования, акты приёмки, внутренние аудиты и корректирующие действия.
Нормативная база
Стандарты и акты, упомянутые на этой странице: официальный текст и PDF для скачивания.
- ГОСТ Р 53624-2009 ИТ. Программное обеспечение. Системы менеджмента качества. Требования официальный текст ↗
Какие документы собирают вместе с этим
Реальные комплекты из практики наших клиентов: что оформляют одним заходом и зачем.
ИТ-компания в госзаказе: качество разработки, безопасность, реестр ПО
Разработчику, который идёт в госзаказ и корпоративные тендеры, мало показать готовый продукт — заказчик смотрит на процессы. ГОСТ Р 53624-2009 подтверждает управляемость разработки ПО, ИСО/МЭК 27001 — защиту данных заказчика. Для закупок с ограничениями на иностранный софт продукт включают в реестр российского ПО Минцифры, а аккредитация ИТ-компании открывает налоговые льготы и подкрепляет статус разработчика.
- 01 Сертификация по ГОСТ Р 53624-2009 СМК для разработки, поставки и сопровождения ПО: требования, тестирование, выпуск, поддержка. база от 8 000 ₽
- 02 Сертификация ГОСТ Р ИСО/МЭК 27001-2021 Систему защиты информации спрашивают банки, госструктуры и крупные корпоративные заказчики. информационная безопасность от 11 000 ₽
- 03 Включение в реестр российского ПО Продукт из реестра Минцифры допускается в закупки с запретом на иностранный софт и продаётся без НДС. для госзакупок
- 04 Аккредитация ИТ-компаний Аккредитация Минцифры — условие пониженных страховых взносов и других мер поддержки ИТ-отрасли. налоговые льготы
