Создание архива электронных документов (АЭД) — это сложный организационно-технический процесс‚ который невозможен без четко прописанного регламента приема. Этот документ является основным локальным нормативным актом‚ определяющим порядок передачи‚ проверки‚ регистрации и размещения электронных документов (ЭД) в архивное хранилище. В условиях ужесточения законодательства (ФЗ-43‚ ФЗ-149‚ ГОСТ Р 7.0.100-2018‚ требования к доверенным хранилищам) регламент перестает быть просто «инструкцией» и становится инструментом обеспечения юридической значимости‚ подлинности и целостности документов на протяжении всего срока хранения.

Нормативно-правовая база и цели регламента

Разработка регламента должна опираться на иерархию нормативных актов:

• Федеральный закон от № 149-ФЗ «Об информации‚ информационных технологиях и о защите информации» (статьи про ЭДО‚ ЭП‚ доверенные третьи стороны).
• Федеральный закон от № 43-ФЗ «Об архивном деле в Российской Федерации» (статьи 15‚ 16‚ 22 — порядок формирования архивных фондов‚ приема и хранения).
• ГОСТ Р 7.0.100-2018 «Архивное дело. Термины и определения».
• ГОСТ Р 7.0.99-2018 «Архивное дело. Формирование архивных фондов организаций. Общие требования».
• Приказ Минкультуры России от № 2768 (утверждает типовые состав и правила ведения справочников‚ в т.ч. для ЭД).
• ISO 14721 (OAIS) и ISO 16175, международные стандарты для систем долгосрочного хранения (применяются как best practice).

Основные цели регламента:

1. Обеспечение правовой силы архивных копий документов.
2. Гарантия целостности‚ подлинности‚ доступности и читаемости ЭД на протяжении всего срока хранения.
3. Установление единых форматных требований (PDF/A‚ XML‚ TIFF и др.) и метаданных (профили Dublin Core‚ METS‚ схемы Минкультуры).
4. Разграничение ответственности и полномочий участников процесса (отправитель‚ архивист‚ администратор СЭД/АЭД‚ ИБ).
5. Описание процедур отказа в приеме и возврата документов на доработку.

Структура регламента приема (рекомендуемый состав разделов)

Типовой регламент состоит из следующих структурных элементов:

Общие положения

• Наименование организации‚ название документа‚ дата вступления в силу‚ срок действия.
• Область применения: какие виды документов (договоры‚ акты‚ кадровые‚ бухгалтерские‚ техническая документация)‚ из каких систем (СЭД‚ 1С‚ SAP‚ почта) поступают в архив.
• Определения терминов: АИС (Автоматизированная информационная система)‚ АЭД‚ Архивный пакет (SIP — Submission Information Package)‚ ЭП (Электронная подпись)‚ Хэш-сумма‚ Метаданные.

Участники процесса и матрица ответственности (RACI)

Требования к комплекту документов на входе (SIP — Submission Information Package)

Это критически важный раздел. Он должен содержать жесткие технические спецификации:

А. Форматы файлов (Рекомендации ГОСТ Р 7.0;99-2018 и Приказа № 2768)

• Текстовые документы: PDF/A-1b или PDF/A-2b (ISO 19005) — обязательно для визуального представления.
• Структурированные данные: XML (с привязкой к XSD-схеме)‚ JSON (для реестров).
• Изображения/Скан-копии: TIFF (Group 4 compression) или JPEG 2000 (lossless)‚ PDF/A для многостраничных.
• Таблицы: CSV (UTF-8) или ODS / XLSX (только как приложение к PDF/A).
• Запрещено: Исполняемые файлы (.exe‚ .bat)‚ проприетарные форматы без открытой спецификации‚ заархивированные контейнеры без контроля целостности (только как транспортный контейнер с манифестом).

Б. Метаданные (Карточка документа / Архивная справка)

Минимальный обязательный набор атрибутов (профиль Dublin Core / Схема Минкультуры):

1. Идентификатор: Уникальный ID в системе-источнике + Глобальный UUID в АЭД.
2. Наименование: Полное официальное название.
3. Дата документа / Дата регистрации: В формате ISO 8601 (YYYY-MM-DD).
4. Вид документа: По номенклатуре дел (договор‚ приказ‚ акт‚ журнал и т.д.).
5. Автор / Исполнитель / Подписант: ФИО‚ должность‚ ИНН/СНИЛС (для кадровых).
6. Срок хранения: Год окончания срока / Категория (временное / постоянное).
7. Группа доступа / Уровень секретности: Открытый‚ ДСП‚ Коммерческая тайна‚ Гос. тайна (требует отдельного контура).
8. Реквизиты ЭП: Отпечаток сертификата (Thumbprint)‚ алгоритм (ГОСТ Р 34.10-2012)‚ статус валидации на момент архивирования.
9. Хэш-сумма файла: Алгоритм ГОСТ Р 34.11-2012 (Streebog) -56/512 бит или SHA-256 (для совместимости).
10. Связи: ID родительского дела‚ ID связанных документов (приложения‚ соглашения).

В. Структура архивного пакета (Пример структуры папок/архива)

/SIP_[ID_Дела]_[Дата]/
 ├── manifest.xml # Манифест: список файлов‚ хэши‚ структуру‚ метаданные дела (METS/префиксная схема)
 ├── /documents/ # Полезная нагрузка (Payload)
 │ ├── doc_001.pdf.a # Основной файл (PDF/A)
 │ ├── doc_001.xml # XML-вложение/данные (если есть)
 │ └── doc_001.sig # Открепленная ЭП (CAdES-BES / CAdES-X-Long) — ОБЯЗАТЕЛЬНО
 └── /metadata/
 └── metadata.xml # Детальные метаданные по каждому файлу (опционально‚ если не в manifest)

Процедура приема: Пошаговый алгоритм (Workflow)

Регламент должен описывать процесс как последовательность состояний (State Machine).

Этап 1: Инициация и подготовка (Сторона передачи)

• Формирование дела/комплекта в соответствии с Номенклатурой дел и Срокографами.
• Конвертация в архивные форматы (PDF/A и т.д.)‚ наложение ЭП (если документ не был подписан ранее‚ но требует подписания архивной копии уполномоченным лицом).
• Расчет хэш-сумм‚ формирование манифеста (manifest.xml).
• Упаковка в транспортный контейнер (ZIP без пароля / TAR) или передача через API/шлюз.

Этап 2: Техническая приемка (Автоматизированная / Администратор СЭД)

1. Проверка целостности контейнера (сравнение хэша контейнера).
2. Распаковка‚ парсинг манифеста.
3. Автоматические валидации:
   • Соответствие форматов (верификатор PDF/A, veraPDF).
   • Проверка хэш-сумм каждого файла по манифесту.
   • Проверка структуры пакета (наличие обязательных папок/файлов).
   • Проверка уникальности UUID (нет дублей в АЭД).
4. При ошибках: автоматический возврат статуса «Отклонен на техническом контроле» с протоколом ошибок (лог).

Этап 3: Архивная экспертиза / Квалификационный контроль (Архивист)

Самый трудоемкий этап‚ требующий экспертной оценки.

• Полнота дела: Соответствие номенклатуре‚ наличие всех листов дела‚ внутренняя хронология.
• Качество метаданных: Корректность заполнения атрибутов‚ соответствие справочникам (классификаторам)‚ полнота реквизитов ЭП.
• Юридическая значимость: Проверка валидности ЭП на момент подписания (построение цепочки доверия‚ проверка CRL/OCSP‚ наличие метки времени — CAdES-X-Long / CAdES-A высоко рекомендуются для долговременного хранения).
• Читаемость: Визуальный контроль открытия файлов‚ корректность рендеринга шрифтов‚ слоев‚ печатей.

Этап 4: Регистрация и размещение (Администратор АЭД / Архивист)

1. Присвоение архивных кодов (Фонд-Опись-Дело).
2. Запись в Учетные документы (Журнал приема‚ Реестр архивных фондов‚ Карточка дела).
3. Физическое/логическое размещение в хранилище (Hot/Warm/Cold tiers) с контролем записываемости (WORM) и репликацией.
4. Формирование Акта приема-передачи документов в архив (двусторонний‚ с ЭП сторон).

Этап 5: Подтверждение и закрытие

• Отправка акта инициатору.
• Уничтожение/архивирование рабочих копий у инициатора (по согласованию).
• Перевод дела в статус «Хранится постоянно» / «Хранится до ГГГГ».

Процедуры исключительных ситуаций

Отказ в приеме

Формализуется Актом отказа в приеме (или протоколом расхождений). Основания:

• Несоответствие форматов (невалидный PDF/A).
• Нарушение целостности (хэши не совпадают).
• Невалидная/просроченная/отозванная ЭП без метки времени‚ подтверждающей момент подписания.
• Отсутствие обязательных метаданных (срок хранения‚ подписант).
• Несоответствие номенклатуре дел (неверное дело‚ смешение сроков хранения в одном деле).

Важно: Регламент должен устанавливать сроки устранения замечаний (например‚ 5-10 рабочих дней) и порядок повторной передачи.

Прием документов с истекшим сроком действия ЭП

Если ЭП истекла/отозвана‚ но документ подписан до истечения срока действия сертификата:

1. Обязательно наличие метки времени (Time Stamp Token) от Уполномоченного оператора метки времени (ОМВ)‚ подтверждающей факт подписания в валидный период.
2. Или наличие архивной подписи (CAdES-A) с периодической переподписью (перештамповкой) администратором АЭД.
3. Без метки времени — прием невозможен‚ документ считается неимеющим юридической силы.

Миграция форматов при приеме

Если исходный формат не является архивным (например‚ DOCX‚ XLSX‚ DWG):

• Регламент должен определять: кто конвертирует (инициатор или архив)‚ каким ПО (сертифицированное СЗИ/Средство конвертации)‚ как подтверждается адекватность (визуальное сравнение‚ контроль хэшей оригинала + производного файла).
• Оригинал в нативном формате может храниться как приложение к архивной копии PDF/A‚ но юридической силы обладает именно PDF/A с ЭП.

Обеспечение информационной безопасности при приеме

• Канал передачи: Только защищенные контуры (VPN‚ TLS 1.2+/ГОСТ TLS‚ СДСЗ). Запрет передачи через открытую почту‚ мессенджеры‚ флешки без шифрования.
• Разделение доступа: Приемный буфер (Quarantine zone) — изолированная зона‚ недоступная пользователям‚ только для процессов валидации и антивирусной проверки.
• Антивирусная проверка: Обязательное сканирование файлов актуальными базами сигнатур перед попаданием в карантин.
• Учет действий (Audit Trail): Все операции в приемном буфере логируются в неизменяемый журнал аудита (SIEM/СКЗИ): кто‚ когда‚ какой файл‚ какой вердикт.

Приложения к регламенту (обязательные формы)

Регламент не работает без утвержденных форм. Минимальный набор приложений:

1. Приложение А: Техническая спецификация SIP (XSD-схема manifest.xml‚ словарь метаданных‚ контролируемые словари/классификаторы).
2. Приложение Б: Форма Акта приема-передачи электронных документов в архив (с реквизитами ЭП сторон).
3. Приложение В: Форма Акта отказа в приеме / Протокола расхождений.
4. Приложение Г: Чек-лист архивиста для экспертной проверки (Квалификационный контроль).
5. Приложение Д: Реестр допустимых форматов файлов и версий ПО для валидации (veraPDF version‚ КриптоПро CSP version и т.д.).
6. Приложение Е: Инструкция по работе с приемным модулем АЭД (для администратора/архивиста).

Контроль за соблюдением регламента и его актуализация

• Внутренний аудит: Ежеквартально/раз в полгода проверка выборки принятых дел на соответствие регламенту.
• Метрики (KPI) приема:
  • % пакетов‚ принятых с первого раза (First Pass Yield).
  • Среднее время цикла приема (Lead Time).
  • Количество критических ошибок (нарушение ЭП‚ целостности) в месяц.
• Процесс изменения регламента: Любые изменения (новые форматы‚ смена криптопровайдера‚ обновление ГОСТов) вносятся по согласованию с ИБ‚ юристами‚ ИТ и утверждением руководителем. Версионирование обязательно (v1.0‚ v1.1‚ v2.0).

Регламент приема в создаваемый архив электронных документов — это не бюрократическая формальность‚ а фундамент доверия к архиву. От качества проработки технических требований (форматы‚ хэши‚ ЭП‚ метаданные) и процедур контроля зависит‚ будут ли электронные документы признаны судом‚ налоговой или аудиторами через 10‚ 50 или 75 лет хранения. Инвестиции в автоматизацию входного контроля (валидаторы PDF/A‚ проверка ЭП‚ парсинг манифестов) на этапе создания АЭД многократно окупаются за счет исключения ручного труда и рисков потери юридической значимости фондов.

Ключевой принцип: «Никакой документ не попадает в архив без прохождения всех этапов верификации: Технической -> Криптографической -> Архивной».