Главная / Договоры, шаблоны и архив
Клиентский портал →
Договоры, шаблоны и архивdocs/47_data_room_access_policy.md

Data room access policy

Дата: 2026-06-01

Документ задает правила доступа, именования, версий и контроля документов в проектной data room девелоперской группы. Это не замена DLP/ЭДО/корпоративной ИБ-политики, а рабочий регламент для запуска проекта и передачи материалов банку, юристам, налоговым консультантам, аудиторам и техническим экспертам.

1. Цель

Data room должна решать четыре задачи:

  1. Быстро показать состояние проекта собственнику, банку и экспертам.
  2. Исключить хаос версий, когда разные участники работают с разными файлами.
  3. Сохранить доказательства деловой цели, рыночности, реальности функций и управленческих решений.
  4. Подготовить архив для закрытия SPV, налоговой защиты, гарантийных споров и последующих проектов.

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

2. Классы доступа

Класс Смысл Примеры Базовый режим
Public internal Материалы без критичных коммерческих и персональных данных Общая презентация проекта, публичные разрешения, общие графики Чтение внутри группы
Confidential Рабочая коммерческая информация Финмодель, договоры, тендеры, бюджеты, продажи Чтение по роли, изменение владельцем
Strict confidential Данные, способные повлиять на переговоры, налоги, контроль или безопасность UBO, структура владения, условия банка, спорные налоговые позиции, security package Точечный доступ по решению CEO/CFO/Legal
Personal data Персональные данные сотрудников, покупателей, контрагентов Паспортные данные, трудовые документы, анкеты клиентов Только HR/Legal/уполномоченные лица
Litigation privileged Споры, претензии, legal opinions, материалы расследований Претензии, судебные позиции, заключения юристов Legal owner, выдача внешним только по approval

3. Роли доступа

Роль Чтение Изменение Комментарий
Investor / Sponsor Все итоговые материалы, ключевые реестры, решения, финмодель Обычно нет, кроме approval/решений Не должен править операционные файлы напрямую
CEO / Project Director Все проектные материалы, кроме ограниченных HR/персональных данных Governance, решения, проектные статусы Операционный владелец результата
CFO / Finance Финмодель, банк, платежи, ковенанты, продажи, бюджет, налоги Финмодель, платежные и банковские реестры Отвечает за связку модель - банк - платежи
Legal Corporate, land, permits, contracts, claims, related-party, closure Legal documents, contract comments, risk positions Владелец юридической доказательной базы
Tax / Accounting Tax/accounting, related-party, contracts, finance extracts Tax memos, VAT register, accounting evidence Контролирует налоговые позиции и первичку
Technical customer Land technical DD, design, permits, construction, commissioning Технические реестры, акты, change orders Контролирует техническую сторону проекта
Sales / Marketing Sales, pricing, CRM extracts, escrow sales reports Sales reports, price-list approvals Не получает лишний доступ к банковским условиям
HR / Admin HR/admin, access logs, org charts HR docs, access requests, offboarding Отдельный контур персональных данных
Bank Bank package, approved finance model, permits, land, sales, construction reports Нет Выдавать только согласованную витрину
Auditor Finance, tax, contracts, related-party, governance evidence Нет или comments-only Выдавать с журналом запросов
External expert Только релевантный раздел Comments-only Каждый запрос фиксируется в expert review tracker

4. Матрица по папкам

Раздел Owner Backup owner Критичность Обязательный реестр
00_index Project office Legal Strict confidential Document register
01_corporate Legal CFO Strict confidential Entity passport
02_land Legal Technical customer Confidential Land DD checklist
03_permits Technical customer Legal Confidential Permit tracker
04_design Technical customer Project director Confidential Design issue register
05_bank CFO CEO Strict confidential Covenant and bank report registers
06_financial_model CFO Investment analyst Strict confidential Model version log
07_tax_accounting Tax/accounting CFO Strict confidential VAT/tax position register
08_contracts Legal Procurement Confidential Contract register
09_construction Technical customer Project controls Confidential Change order and KS registers
10_sales_marketing Sales director CFO Confidential Sales register
11_related_party CFO/Legal Tax Strict confidential Related-party transaction register
12_governance CEO/Project office Legal Strict confidential Decision register
13_hr_admin HR CEO Personal data HR archive/access register
14_risks_claims Legal/Risk owner Project director Strict confidential Risk and claim registers
15_commissioning_handover Technical customer Sales/UK Confidential Commissioning tracker
16_closure_archive Legal CFO Strict confidential Closure checklist

5. Правило именования файлов

Базовый формат:

YYYY-MM-DD__PROJECT__SECTION__DOC-TYPE__COUNTERPARTY-OR-TOPIC__vNN__STATUS.ext

Примеры:

2026-06-01__PROJECT-A__BANK__TERM-SHEET__BANK-NAME__v01__draft.pdf
2026-06-01__PROJECT-A__LAND__EGRN__PLOT-77-00-000000__v01__received.pdf
2026-06-01__PROJECT-A__CONTRACT__GENCONTRACT__GC-NAME__v03__legal-review.docx
2026-06-01__PROJECT-A__TAX__VAT-MEMO__RESIDENTIAL-COMMERCIAL__v02__approved.pdf

Статусы:

  • draft - рабочая версия;
  • review - передано на проверку;
  • legal-review - юридическая проверка;
  • tax-review - налоговая проверка;
  • bank-review - банковская проверка;
  • approved - утверждено;
  • signed - подписано;
  • superseded - заменено новой версией;
  • archive - архивная финальная версия.

6. Версионность

  1. Нельзя перезаписывать утвержденный файл новой редакцией.
  2. Каждая существенная правка получает новый vNN.
  3. В 00_index/data_room_master_index.md фиксируется актуальная версия.
  4. Старые версии не удаляются, а переносятся в подпапку _superseded или помечаются статусом superseded.
  5. Для финмодели рядом с файлом должен быть model change log: что изменено, кто утвердил, какие outputs поменялись.

7. Журнал выдачи внешним сторонам

Для банка, аудитора, консультанта или подрядчика фиксируется:

  • дата выдачи;
  • кому выдано;
  • основание;
  • перечень файлов или ссылка на snapshot index;
  • срок доступа;
  • ограничения использования;
  • ответственный внутри группы;
  • дата закрытия доступа;
  • замечания и полученные comments.

Журнал можно вести в models/dev_corp_operational_registers_v0_2.xlsx или в отдельном access_log.xlsx, если проект уже перешел в реальную эксплуатацию.

8. Snapshot-подход

Для внешних пользователей лучше выдавать не живую рабочую папку, а snapshot:

external_snapshots/
  2026-06-01__bank-package__v01/
  2026-06-15__legal-dd__v02/
  2026-07-01__auditor-request__v01/

Snapshot должен иметь собственный index, чтобы потом можно было доказать, что именно было передано банку или эксперту.

9. Минимальный контроль качества

Перед выдачей внешней стороне проверяется:

  • файл открывается;
  • название соответствует naming convention;
  • владелец документа указан;
  • есть актуальный статус;
  • документ есть в master index;
  • документ связан с реестром, если влияет на обязательства, платежи, налоги, сроки или права;
  • нет лишних персональных данных;
  • нет черновых комментариев, которые не должны уходить внешнему адресату;
  • PDF сформирован из актуальной версии;
  • у подписанных документов есть скан/ЭДО-подтверждение и карточка договора.

10. Красные флаги

Красные флаги, которые требуют остановки выдачи или отдельного approval:

  • документ есть в папке, но отсутствует в реестре;
  • в реестре сумма отличается от договора/КС/счета;
  • финмодель не совпадает с банковским отчетом;
  • договор с взаимозависимым лицом без карточки деловой цели и рыночности;
  • налоговая позиция без memo и первички;
  • подписанный документ лежит только в переписке;
  • доступ внешнему консультанту выдан шире, чем его задача;
  • в data room лежат персональные данные без основания и ограничения доступа.

11. Связь с другими материалами

  • docs/34_document_management_archive.md - общий document management и архив закрытия.
  • docs/43_operational_registers_spec.md - реестры, с которыми связана data room.
  • docs/44_expert_review_pack.md - выдача материалов экспертам.
  • templates/13_data_room_index.md - шаблон индекса.
  • data_room_template/ - папка-шаблон.
  • data_room_projects/example_project/ - пример проектной комнаты.

12. Нормативная опора доступа и персональных данных

Дата проверки: 2026-06-08.

Контроль Нормативная опора Требование
Определение оператора персональных данных 152-ФЗ каждое юрлицо определяет цели, состав и операции с данными
Основание обработки статьи 6 и 9 152-ФЗ согласие не является единственным основанием, но основание должно быть зафиксировано
Уведомление Роскомнадзора статья 22 152-ФЗ проверить обязанность уведомления и применимость исключений
Политика обработки статья 18.1 152-ФЗ политика должна быть утверждена и доступна в установленных случаях
Локализация при сборе через интернет статья 18 152-ФЗ базы первичного сбора персональных данных граждан РФ должны соответствовать требованиям закона
Защита данных статья 19 152-ФЗ организационные и технические меры, доступы и журналирование
Реагирование на инцидент статья 21 152-ФЗ установить внутренний порядок выявления, фиксации и уведомлений
Передача внешней стороне 152-ФЗ; договор и поручение обработки определить получателя, цель, состав, срок и меры защиты
Удаление доступа 152-ФЗ и внутренние политики закрывать доступ после завершения задачи или договора

Официальная информация Роскомнадзора:

  • для операторов персональных данных: https://22.rkn.gov.ru/p10331/p32018/;
  • памятка о согласии: https://42.rkn.gov.ru/p32026/p32474/.

Правило внешнего snapshot

До передачи пакета внешнему лицу:

  1. Определить законное основание передачи.
  2. Исключить лишние персональные данные.
  3. При необходимости обезличить документы.
  4. Установить срок доступа.
  5. Запретить несанкционированное дальнейшее распространение.
  6. Зафиксировать состав переданного snapshot.
  7. Закрыть доступ и записать дату закрытия.

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