Вернуться к блогу
Hola, Amigos! На связи команда Amiga. Чтобы проверить IT-подрядчика до договора, начните с контрагента и полномочий подписанта. Затем изучите судебные и финансовые сигналы, уточните, кто получит доступ к проекту, согласуйте NDA и правила работы с данными. Только после этого принимайте решение о первом платеже и выдаче доступов.
Контрагент – это конкретная компания или человек, с которым вы заключаете договор. Название студии на сайте, команда на презентации и получатель денег могут не совпадать. Поэтому хорошее впечатление от встречи еще не означает, что подрядчика можно подключать к рабочим системам.
Эта статья поможет проверить контрагента и определить условия его допуска к проекту. Здесь не будет подробного сравнения студий или разбора передачи прав на код: для этих задач у Amiga есть отдельные материалы о выборе подрядчика на разработку и защите ИТ-продукта и прав на код.
Рекомендации рассчитаны прежде всего на российскую компанию или ИП и не заменяют индивидуальную юридическую консультацию. Для иностранных исполнителей, регулируемых отраслей и проектов с чувствительными данными состав проверки нужно расширять вместе с юристом и специалистом по безопасности.
Проверка должна заканчиваться конкретным решением, а не папкой скачанных документов. Для небольшой задачи с публичными данными достаточно одного уровня контроля; для интеграции с клиентской базой или доступа к рабочей инфраструктуре потребуется более глубокая проверка. Ни один сервис не выдает универсальной гарантии надежности.
Начните с такой карты проверки.
Что проверить | Где или у кого | Сигнал риска | Следующий шаг |
Контрагент и реквизиты | ЕГРЮЛ или ЕГРИП, проект договора | Сторона договора не совпадает с согласованной | Уточнить схему сделки до подписания |
Подписанта | Реестр, документы о полномочиях | Договор подписывает лицо без понятного основания | Запросить и проверить полномочия |
Судебные споры | Картотека арбитражных дел | Повторяющиеся претензии по схожим обязательствам | Изучить решения и объяснение подрядчика |
Финансовые возможности | Отчетность, сведения подрядчика | Масштаб обязательств не объяснен ресурсами | Уточнить обеспечение работ и порядок оплаты |
Фактических исполнителей | Руководитель проекта, список ролей | Неясно, кто работает с данными | Установить круг получателей и правила замены |
Защиту информации | NDA и правила обмена файлами | Материалы можно передавать третьим лицам без контроля | Ограничить цель и круг получателей |
Доступ к системам | Владелец системы и подрядчик | Требуется общий пароль или полный доступ «на всякий случай» | Выдать отдельную минимальную роль |
Четыре направления проверки помогают оценить не только компанию, но и команду, процессы и правила безопасности.
Попросите полное наименование или ФИО, ИНН, ОГРН или ОГРНИП, реквизиты и проект договора. Ищите сведения по идентификаторам, а не только по названию бренда: одноименные компании легко перепутать.
Получите выписку через сервис ФНС и дополнительно проверьте компанию в «Прозрачном бизнесе». Сверьте статус, наименование и сведения о руководителе с документами подрядчика. Отметки о недостоверности требуют объяснения и дополнительной проверки.
Затем сопоставьте одну и ту же компанию в коммерческом предложении, NDA, договоре и счете. Если переговоры ведет один бренд, договор предлагает другая компания, а деньги просят перечислить третьей, сначала выясните основания. Такая схема не обязательно незаконна, но должна быть понятна и документально оформлена.
Платежные реквизиты не подтверждаются одной выпиской. Если их внезапно меняют письмом или сообщением, свяжитесь с подрядчиком по ранее проверенному каналу, а не по номеру из нового письма. До подтверждения оплату лучше остановить.
Если договор подписывает представитель, запросите доверенность и проверьте дату выдачи, срок действия, объем полномочий и право подписать именно этот договор. Убедитесь, что доверенность не отменена. Если полномочия переданы в порядке передоверия, проверьте всю цепочку документов. Право вести переговоры не следует автоматически считать правом подписывать договор.
Для электронной подписи также важно понять, кому она принадлежит и на каком основании человек действует от имени компании. В зависимости от способа подписания может потребоваться машиночитаемая доверенность. Формат и проверку согласуйте с юристом и используемой системой электронного документооборота.
Не собирайте полный архив паспортов сотрудников «на всякий случай». Запрашивайте только сведения и документы, необходимые для проверки контрагента и полномочий.
Судебное дело само по себе не означает, что подрядчик ненадежен. Компания может взыскивать деньги с заказчика, спорить о непохожей сделке или успешно защищаться от необоснованных требований. Важно содержание, исход и повторяемость ситуаций.
В Картотеке арбитражных дел найдите нужного участника и проверьте:
Например, повторяющиеся споры о возврате авансов по незавершенным работам требуют более внимательной проверки, чем один спор о задолженности заказчика. Это основание запросить объяснение и скорректировать условия сделки, а не публично объявлять компанию недобросовестной.
Если увидели существенный риск, передайте юристу конкретные номера дел и документы. Формулировка «мы нашли десять судов» без контекста мало помогает принять решение.
Для организации посмотрите доступную отчетность в ГИР БО ФНС. Сравнивайте несколько периодов, если они доступны, и учитывайте ограничения доступа. Отсутствие отчетности в открытом поиске не всегда означает нарушение: ресурс не содержит данные всех возможных контрагентов. ФНС отдельно описывает правила и ограничения ГИР БО.
Отчетность показывает прошлые периоды, а не гарантирует способность выполнить ваш проект завтра. Попросите объяснить, какими ресурсами будут обеспечены согласованные работы и зачем нужен предложенный размер аванса. Небольшой штат тоже не является самостоятельным основанием для отказа: у исполнителя могут быть ИП и субподрядчики. Важно понять эту модель до передачи данных.
Для значимого аванса или критичного проекта дополнительно изучите сведения о банкротстве в ЕФРСБ. Объем проверки и условия оплаты определяйте с учетом конкретных рисков, а не по универсальному правилу вроде «любой аванс больше определенного процента опасен».
До допуска выясните не только состав команды, но и маршрут информации: кто получит документы, где они будут храниться и кто сможет передать их дальше.
Запросите список ролей, ответственного за выдачу доступов и участие субподрядчиков. Не обязательно согласовывать каждого специалиста лично, но правила должны позволять установить конкретного пользователя системы. Уточните, что происходит при замене сотрудника и кто отзывает его права.
Отдельно спросите:
Не проверяйте безопасность только по обещанию «мы все храним защищенно». Попросите описать конкретный процесс на примере: разработчик уходит из команды – кто узнает об этом, какие доступы закрываются и как подтверждается результат.
Доступ к клиентской базе, обращениям поддержки или рабочим журналам может означать обработку персональных данных. До передачи нужно определить правовое основание, состав данных, операции и роли сторон.
При обработке по поручению оператора часть 3 статьи 6 закона № 152-ФЗ предусматривает договорное поручение с установленными законом условиями, включая цели, перечень данных, перечень операций, конфиденциальность, безопасность и уведомление оператора об инцидентах. NDA не заменяет такое поручение. Основание передачи, размещение данных, удаленный доступ и трансграничные вопросы проверьте с профильным специалистом.
Для первичной оценки безопаснее использовать синтетические тестовые данные. Если они не подходят задаче, можно подготовить обезличенную выборку, но до ее передачи нужно проверить законность обработки и достаточность обезличивания. Само слово «обезличенная» не означает, что данные разрешено передавать: важно убедиться, что человека нельзя повторно определить по оставшимся полям или их сочетанию. Не отправляйте рабочую базу только ради расчета стоимости интеграции.
Перед первым обсуждением можно показать публичное описание продукта и общий сценарий. Если для оценки нужны непубличные документы, архитектура, код или коммерческие сведения, согласуйте конфиденциальность до их передачи.
NDA фиксирует состав конфиденциальной информации, допустимые цели, круг получателей и порядок действий при инциденте.
Проверьте пять вопросов:
1. Какая информация защищается. Опишите категории материалов и способ их обозначения. Не оставляйте критичные документы за пределами определения.
2. Для чего ее можно использовать. На этапе переговоров это может быть только оценка конкретного проекта. Публикация, портфолио и обучение моделей требуют отдельного согласования.
3. Кому ее можно передавать. Установите правила для сотрудников и субподрядчиков и ответственность стороны, которая привлекает их к работе.
4. Что происходит при инциденте. Укажите контакт и срок, в течение которого подрядчик обязан сообщить об утечке, ошибочной передаче данных или компрометации доступа. Этот срок должен позволять оператору выполнить требования закона: в предусмотренных случаях первое уведомление Роскомнадзора направляют в течение 24 часов с момента выявления инцидента, а результаты внутреннего расследования – в течение 72 часов. Поэтому подрядчик должен сообщить о происшествии раньше.
5. Что делать после отказа от сделки. Определите возврат или удаление материалов, подтверждение выполнения и законные исключения для хранения.
Дополнительно согласуйте каналы обмена файлами, срок обязательств и исключения, например для общедоступной информации или обязательного раскрытия по закону. Ответственность и возможность доказать нарушение должны оцениваться вместе с юристом.
Отдельный NDA нужен не всегда: подходящие условия могут быть в другом соглашении. Важно, чтобы защита действовала уже в момент раскрытия информации и документы не противоречили друг другу.
Если бизнес рассчитывает на режим коммерческой тайны, одного NDA недостаточно. Статья 10 закона № 98-ФЗ предусматривает комплекс мер, в том числе перечень сведений, ограничение и учет доступа, регулирование отношений и маркировку. Эти меры организуют внутри компании, а не заменяют названием соглашения.
Допуск к проекту не означает передачу всех паролей. Выдавайте права под конкретную задачу и расширяйте их только при обоснованной необходимости. Это соответствует принципу минимальных привилегий NIST.
Составьте реестр доступа: система, конкретный пользователь, задача, роль, дата окончания и ответственный за отзыв. Если оценку можно выполнить по схеме API или в тестовой среде, доступ к рабочему контуру не нужен.
Этап | Что обычно достаточно предоставить | Что требует отдельного обоснования |
Предварительное обсуждение | Публичный бриф и общие сценарии | Непубличные документы и данные клиентов |
Оценка после NDA | Выбранные документы, макеты, описания интеграций | Полный архив проекта или рабочая база |
Согласованное обследование | Тестовый контур, нужные разделы репозитория, синтетические данные | Административная роль, платежные настройки |
Выполнение утвержденной задачи | Именная роль и ограниченный набор ресурсов | Доступ к production, домену и ключам всех сервисов |
Эта таблица – ориентир для согласования, а не универсальное разрешение. Для каждого проекта владелец системы должен проверить, что конкретный объем доступа действительно необходим.
Используйте многофакторную аутентификацию, защищенный обмен секретами и журналирование там, где это поддерживается. Не выдавайте общий аккаунт нескольким людям. Проверьте, кто сможет восстановить основной аккаунт: рабочий контакт бизнеса не должен исчезнуть после подключения подрядчика.
Перед доступом к рабочей среде отдельно согласуйте действия, окно работ, резервирование и способ возврата к предыдущему состоянию, если это применимо. Если сотрудничество не началось или задача завершена, отзовите ненужные права, проверьте сессии и при необходимости замените выданные секреты.
Рабочие аккаунты остаются под контролем бизнеса, а подрядчик получает только именной доступ, необходимый для своей задачи.
Проверка контрагента не заменяет договор. Но до оплаты нужно согласовать минимальный набор условий, без которых бизнес не понимает, за что и кому платит.
Например, если первый этап – обследование интеграции, в результате могут быть перечень систем, ограничения, вопросы к владельцам API и варианты реализации. Формулировка «предоплата за разработку» без понятного состава этого этапа не дает того же контроля.
Условия о правах на будущие результаты также согласуют до начала работ. Подробный разбор этого вопроса вынесен в материал о защите продукта и прав на код. Здесь важно не повторить весь договорный чек-лист, а убедиться, что вопрос не оставлен «на потом».
Не сводите разные риски к одному баллу. Положительные отзывы не компенсируют отсутствие полномочий, а длительный срок работы компании не делает безопасной передачу общего пароля. Сначала определите препятствия, которые нельзя принимать без устранения, затем согласуйте управляемые ограничения.
По итогам проверки компания выбирает один из трех вариантов: допустить подрядчика, ограничить доступ или отложить старт.
Компания и полномочия проверены, существенные вопросы закрыты, документы и правила работы с данными согласованы. Выдайте только утвержденные доступы: положительное решение не означает неограниченных прав.
Есть вопросы, которые не мешают конкретной безопасной задаче. Например, можно начать согласованное обследование в тестовом контуре, но не открывать клиентскую базу до оформления необходимых условий.
Запишите ограничение, ответственного и условие расширения доступа. Не принимайте неопределенное обещание «документы принесем после старта» вместо понятного решения.
Остановите платеж или передачу материалов, если неясны сторона сделки, полномочия или реквизиты; не определены получатели чувствительных данных; подрядчик настаивает на неограниченном доступе без объяснения. При существенных судебных или финансовых сигналах запросите документы и заключение профильного специалиста.
Пауза не всегда означает окончательный отказ. Сформулируйте, что нужно подтвердить или изменить, чтобы вернуться к решению.
В рабочей папке стоит зафиксировать дату, проверяемое лицо и ИНН, источники, найденные вопросы, ответы, принятое решение и ограничения. Перед существенным изменением условий или новым уровнем доступа проверьте, не изменились ли исходные обстоятельства.
Учебный пример: подрядчик предлагает оценить интеграцию на копии рабочей базы. Компания и полномочия подтверждены, но правила обработки данных еще не согласованы. Решение – предоставить схему и синтетическую выборку, согласовать оплачиваемое обследование и оставить доступ к рабочей базе закрытым. Так проверка превращается в конкретное условие старта.
Amiga – агентство продуктовой разработки. На этапе подготовки проекта команда помогает описать задачу и интеграции, определить исходные материалы и сформировать понятный результат первого этапа. Подробнее о таком подходе – на странице системной аналитики.
Проверку контрагента и правовые условия организует заказчик вместе со своими ответственными специалистами. Со стороны проектной команды важно заранее согласовать участников, рабочее пространство, нужные доступы и процесс обмена материалами.
Если вы планируете веб-приложение или интеграцию, можно обсудить задачу с командой веб-разработки Amiga и определить, какие сведения нужны для оценки, а какие доступы пока выдавать не требуется.
ИНН помогает найти нужногоконтрагента и не перепутать его с одноименной компанией. Но он не подтверждает полномочия представителя, фактическую команду и правила доступа. Проверка по реестру – начальный шаг, после которого нужно проверить условия конкретной сделки.
Нет универсального правила. Изучите предмет, роль компании, стадию, исход и повторяемость споров. Решение лучше принимать по установленным обстоятельствам и условиям вашего проекта, а не по количеству найденных дел.
Да, если меняются значимые обстоятельства: юридическое лицо, подписант, реквизиты, субподрядчики, состав данных или уровень доступа. Прежний положительный результат не подтверждает автоматически новую схему работы.
Не требуйте нарушать чужую конфиденциальность. Можно запросить обезличенное описание опыта и разрешенные подтверждения. Но ссылка на NDA не должна мешать подрядчику назвать сторону вашей сделки, подтвердить полномочия и объяснить, кто будет работать с вашими материалами.
Само отсутствие основного договора на разработку не определяет ответ. Для отдельно согласованного обследования нужны понятная задача, действующие условия работы с информацией и необходимые основания для обработки данных. Объем доступа должен соответствовать этому этапу. Общий доступ к рабочей системе ради предварительного знакомства давать не стоит.
Остановите платеж и подтвердите изменение по ранее проверенному каналу связи. Уточните, относится ли счет к той же стороне сделки и нужны ли новые документы. Не считайте новое письмо достаточным подтверждением.
Можно, если она имеет самостоятельный результат и безопасные границы. Зафиксируйте условия оплаты, используйте необходимый минимум материалов и не открывайте чувствительные системы только потому, что задача небольшая. Тестовый этап не заменяет проверку контрагента.
Главный результат проверки – понимание, кому вы передаете деньги и информацию, на каких условиях и с каким уровнем доступа. Начинайте в согласованных границах и расширяйте их по мере появления проверенной необходимости.
Если вы готовите проект к старту, команда Amiga поможет описать первый этап, определить необходимый минимум материалов и доступов и зафиксировать проверяемый результат работ. Примеры проектов собраны в разделе кейсов Amiga.
