Срок хранения видео CCTV: как долго хранить

Это инженерное руководство, а не юридическая консультация. Уточняйте конкретику у квалифицированного юриста.

Коротко

Сколько система видеонаблюдения хранит запись, должно быть записанным решением, а не следствием размера дисков – но большинство систем «хранят» видео лишь до заполнения диска, когда самая старая запись перезаписывается, и это привязывает срок хранения к железу, а не к нужде. Настоящая политика хранения лежит между двумя пределами: пол задают операционная нужда и любой юридический или отраслевой минимум (сколько вы обязаны хранить), потолок задаёт закон о приватности (сколько вы вправе). По принципу ограничения хранения в ЕС (GDPR ст. 5(1)(e)) и видео-рекомендациям EDPB (Guidelines 3/2019) рутинное видео обычно стоит удалять через дни, а не месяцы, тогда как отраслевые правила – казино, банки, каннабис – могут предписать более долгий минимум для конкретных камер, а юридическое удержание может вовсе заморозить удаление отдельного видео. Сложность не в выборе числа, а в том, чтобы удаление реально происходило по графику – по экспортам, бэкапам и облачным копиям – с чистым журналом для подотчётности, и это задача политики и инженерии, а не хранилища.

Почему это важно

Наша смежная статья превратила дни хранения в терабайты хранилища; эта статья – про сами дни: как их выбрать, обосновать и проследить за их соблюдением. Она для интегратора систем безопасности, продакт-менеджера, операционного руководителя или владельца комплаенса, которому нужно ответить на обманчиво простой вопрос – «сколько мы храним видео?» – и который обнаруживает, что ответ это ни одно число, ни свободный выбор. Срок слишком короткий – и вы провалили расследование, чарджбэк или минимум регулятора; слишком долгий – и вы нарушаете закон о приватности, несёте лишнюю стоимость хранения и превращаете архив в обязательство, до которого дотянется злоумышленник или повестка. Юридическая подготовка не нужна: каждое правило объяснено простым языком и привязано к названному закону, а каждый срок обоснован реальной операционной или регуляторной причиной. Цель – политика, которую можно записать, заложить в систему и за которой можно стоять.

Одна идея: ретенция – это решение, а не размер диска

Спросите большинство систем видеонаблюдения, как долго они хранят запись, и честный ответ будет «пока диск не заполнится». Регистратор пишет потоки камер на диски, и когда диски заполняются, перезаписывает самую старую запись, освобождая место под новую – петля «первым вошёл – первым вышел». Срок хранения, который из этого получается, – это просто ёмкость диска, делённая на суточный темп записи. Это число, которое никто не выбирал.

Посчитаем с цифрами из нашей статьи о математике хранения. Возьмём 40 камер по 2 Mbps, пишущих непрерывно. Каждая камера пишет около 21,6 ГБ в день, так что объект пишет примерно 0,864 ТБ в день. На массиве 26 ТБ:

26 ТБ ÷ 0,864 ТБ/день ≈ 30 дней до того, как петля закольцуется

Итак, система «хранит 30 дней» – но лишь потому, что массив оказался 26 ТБ. Добавьте камер, поднимите разрешение или включите второй объект – и тот же массив теперь хранит 18 дней. Поставьте диски побольше – хранит 60. Срок дрейфует вслед за железом, а это ровно то, что политика должна предотвращать. Если закон говорит, что вы обязаны хранить 90 дней, эта система молча теряет месяц обязательного видео. Если закон о приватности говорит хранить лишь несколько дней, эта система пере-хранит неделями. В любом случае срок – случайность.

Политика хранения заменяет эту случайность решением: видео данного типа хранится заданный срок, по заданной причине, и затем намеренно удаляется – независимо от того, сколько диска свободно. Остаток статьи – о том, как принять это решение и, что труднее, как заставить систему ему подчиниться.

Нажмите, чтобы увеличить

Два предела, тянущие в разные стороны

Причина, по которой ретенция кажется запутанной, в том, что её задают две разные силы, и тянут они в разные стороны. Держать их раздельно – весь фокус.

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

Вторая сила – максимум, потолок, выше которого хранение видео становится обязательством, а не активом. Он приходит из закона о приватности, который трактует записанное видео опознаваемых людей как персональные данные и говорит, по сути, что нельзя держать персональные данные дольше, чем они реально нужны. Выше максимума каждый лишний день – ненужный риск: больше защищать, больше под угрозой утечки, больше доступно в суде и – в юрисдикциях, где это применяют, – длящееся нарушение.

Срок хранения – любое число между этими пределами. Минимум говорит «не короче этого»; максимум – «не дольше этого». Когда минимум превышает максимум – когда отраслевое правило требует больше, чем иначе позволил бы закон о приватности, – конкретная юридическая обязанность, как правило, для этого видео побеждает, и более долгий срок сам становится законным основанием хранить. Задача политики – найти верную точку в этом окне для каждого типа видео, записать её и удалять вовремя.

Минимум: сколько вы обязаны хранить видео

Начнём с пола, потому что его проще осмыслить и именно его большинство команд задаёт наугад.

Операционно вопрос такой: какой самый правдоподобно долгий разрыв между событием на камере и тем, кому понадобится видео? Для тихого офисного холла это, может, неделя. Для розничного магазина со спорами по картам – это окно оспаривания платёжной схемы, которое может идти 60–120 дней. Для рабочего места, где могут подать иск о домогательстве или травме, – ещё дольше. Честный метод – перечислить типы инцидентов, ради которых камеры существуют, найти самый медленный по всплытию и задать минимум так, чтобы пережить его, – а не выбрать круглое число, потому что оно звучит безопасно.

Поверх операционной нужды лежат отраслевые минимумы, прописанные в регламенте, и они конкретны, цитируемы и легко ошибаемы. Несколько реальных примеров по состоянию на 2026:

Закономерность, которую стоит заметить: универсального числа нет. У вопроса «как долго хранить видео?» нет ответа без названия отрасли, юрисдикции и цели камеры. Камера игрового зала казино, камера сейфа диспансера и камера холла бэк-офиса в одном здании могут иметь три разных законных минимума.

«Частая ошибка: «PCI DSS требует 90 дней видео». Это один из самых повторяемых мифов в видеонаблюдении. Стандарт PCI DSS управляет тем, как защищаются данные карт; он ожидает физический контроль доступа и, в требовании к журналам доступа, удержание записей – но не задаёт никакого срока хранения видео вообще. Цифра «90 дней» взята из несвязанной строки о хранении логов и наклеена на камеры. Если ваша единственная заявленная причина хранить 90 дней видео – «PCI требует», у вас нет реального основания: найдите настоящую операционную или отраслевую причину или сократите срок.»

Максимум: сколько вы вправе хранить видео

Теперь потолок, где команды видеонаблюдения чаще всего сползают в тихое несоответствие – потому что дешёвое хранилище делает «храним всё, вечно» как бы бесплатным, а закон о приватности говорит обратное.

Управляющий принцип в ЕС – ограничение хранения, изложенный в Общем регламенте по защите данных (GDPR, Регламент (ЕС) 2016/679), статья 5(1)(e). Он гласит, что персональные данные должны «храниться в форме, позволяющей идентификацию субъектов данных, не дольше, чем необходимо для целей, ради которых они обрабатываются». Записанное видео опознаваемых людей – персональные данные, так что часы не опциональны: как только видео больше не нужно для цели, оправдавшей его запись, оно должно уйти.

Насколько коротко «не дольше, чем необходимо» для видео? Орган, толкующий GDPR для камер – Европейский совет по защите данных (EDPB) – отвечает на это прямо в своих Guidelines 3/2019 об обработке персональных данных через видеоустройства. Его позиция, повторённая в собственной обзорной памятке EDPB от апреля 2026 по этим рекомендациям, прямолинейна: поскольку ущерб или инцидент «можно обнаружить в течение одного-двух дней», срок хранения «несколько дней» часто достаточен, и видео стоит удалять – в идеале автоматически – как только оно больше не нужно. Рекомендации приводят разобранный пример (пункт 119): организация, авто-удаляющая видео через два дня, просто не может предоставить это видео никому впоследствии, потому что его больше нет. Руководство оставляет место для большего там, где государство-член задаёт конкретный срок или где это оправдано реальной нуждой, но дефолтное ожидание – коротко.

Это зеркальное отражение минимума, и напряжение реально. Окно спора по карте может говорить за 90 дней; дефолт приватности – за несколько. Решение не в том, чтобы поделить разницу, а в том, чтобы привязать каждый срок к названной, защищаемой цели: POS-камера на 90 дней хранится 90 дней из-за задокументированного окна споров, а камера холла без такой нужды – несколько дней. Срок, который нельзя обосновать целью, – срок слишком долгий.

«Частая ошибка: хранить всё вечно, потому что хранилище дешёвое. Важна не стоимость диска – важно обязательство. Каждый лишний день хранимого видео – это больше персональных данных защищать, больше потерять при утечке, больше того, до чего дотянется повестка или запрос субъекта на доступ, и в ЕС – длящееся нарушение ограничения хранения. Архив, который нельзя обосновать, – не актив; это запас риска, растущий каждый день, когда не запускается задача удаления. Инстинкт «хранилище дешёвое» (см. нашу статью об уровнях хранения, где архивный класс за $1/ТБ соблазняет ровно этим) – ровно то, что максимум существует останавливать.»

Более жёсткий потолок: биометрическое видео

Одна категория несёт куда более жёсткий максимум: видео, обрабатываемое для биометрии – распознавания лиц или любой аналитики, превращающей лицо в искомый шаблон. По GDPR это особая категория данных (ст. 9) с более высокой планкой; по праву США это активирует биометрические законы штатов. Закон Иллинойса о приватности биометрической информации (BIPA, 740 ILCS 14/15(a)) требует от любой частной организации, держащей биометрические идентификаторы, опубликовать письменный график хранения и навсегда уничтожить данные, когда цель выполнена или в течение трёх лет с последнего взаимодействия человека, что наступит раньше. Это законный крайний срок удаления с частным иском за спиной. Если ваша система запускает распознавание лиц, у шаблонов лиц свои часы хранения – отдельные от видео, из которого они получены, и строже, – на что указывает наша статья о распознавании лиц, а статья про BIPA разбирает это полностью. Всегда трактуйте биометрию как отдельный класс хранения.

Нажмите, чтобы увеличить

Настройка политики: одна система, много часов

Ошибка, скрытая внутри «как долго мы храним видео?», – слово мы, будто одно число управляет всей системой. Почти никогда не должно. Настоящая политика хранения назначает каждому классу видео свой срок, каждый обоснован своей целью, и позволяет системе вести несколько часов разом.

Метод короткий. Сначала сгруппируйте камеры (или события) в классы по цели: общее покрытие, транзакции или кассы, контролируемые или ценные зоны, помеченные инцидентом клипы и любой биометрический вывод. Второе – для каждого класса найдите минимум (операционная нужда плюс отраслевой мандат) и максимум (дефолт приватности, если конкретная обязанность не поднимает его). Третье – задайте срок как кратчайшее значение, что проходит минимум и остаётся на максимуме или ниже – кратчайшее, потому что ограничение хранения вознаграждает сдержанность, а каждый лишний день – риск. Четвёртое – запишите его, включая причину каждого срока, потому что регулятор, аудитор или ваша же будущая команда спросят почему.

Вот этот метод как разобранная политика для смешанного розничного объекта:

Заметьте, что одно здание ведёт пять разных часов, и в каждой строке побеждает кратчайший защищаемый срок. Заметьте также, что лишь класс помеченных инцидентов хранится долго, и лишь потому, что конкретная задокументированная причина поднимает его – а это ровно то, как задуман к преодолению максимум ограничения хранения: названной целью, а не по умолчанию. Арифметика из нашей статьи о математике хранения по-прежнему работает снизу, но теперь терабайты следуют за политикой, а не политика за дисками.

Нажмите, чтобы увеличить

Как заставить удаление реально работать

Выбор сроков – лёгкая половина. Трудная половина – та, что валит аудиты, – заставить систему удалять по графику и доказать, что она это сделала. Три вещи мешают.

Первое: два рода «удаления» не одно и то же. Перезапись самого старого видео при заполнении диска (петля «первым вошёл – первым вышел», с которой мы начали) – это удаление по ёмкости: видео исчезает, когда кончается место, в возрасте, зависящем от размера диска и нагрузки камер. Удаление видео по достижении заданного возраста – это удаление по политике: видео исчезает по графику, независимо от свободного места. Соответствующей системе нужно второе, а большинство регистраторов поставляются настроенными лишь на первое. Лечение – задать явный максимальный возраст хранения, чтобы видео удалялось на, скажем, 14 или 90 днях вне зависимости от того, заполнен ли диск, – и рассчитать хранилище так, чтобы возраст по политике наступал до закольцовки диска, а не после.

Стандарты видеонаблюдения делают это исполнимым. ONVIF – общий язык, позволяющий камерам и ПО записи разных производителей работать вместе – управляет записанным видео через Profile G (запись и выдача; текущая Спецификация v1.1, октябрь 2025). Его Recording Control Service задаёт MaximumRetentionTime на записи: устройство «обязано удалить любые данные старше максимального времени хранения». Задайте реальное число – и стандарт обязывает регистратор соблюдать возраст по политике; задайте ноль – и хранение ограничено лишь местом на диске, что снова случайный режим по ёмкости. Profile G стандартизирует управление – как VMS задаёт и соблюдает возраст хранения на разнородных регистраторах, – но не решает число. Вспомните границу из нашего объяснения ONVIF: стандарт гарантирует интерфейс, которому обе стороны соответствуют, а не политику, которую вы в него заливаете. Коммерческий обзор того, как профили ложатся на реальные продукты, – спутник для чтения: гид Фора Софт по профилям ONVIF в системах безопасности.

Второе: видео ускользает из графика. Часы хранения управляют основной записью, но копии утекают из неё постоянно: клип, экспортированный для расследования, ночной бэкап, облачная архивная копия (та, что описывает наша статья об облачном и гибридном хранении), кадр, отправленный руководителю по почте. Каждая из них – видео, что переживёт задачу удаления, если его не отслеживать. Политика, удаляющая основную запись на 14 днях, но оставляющая годовалые экспорты в общей папке, на деле не хранила 14 дней – она хранила год, в худшем месте для защиты. Каждому экспорту и бэкапу нужно своё правило хранения и своё удаление, иначе политика – фикция.

Третье: удаление должно быть доказуемым. Закон о приватности ожидает подотчётности (GDPR ст. 5(2)): возможности показать, а не просто заявить, что видео удалено вовремя. Это значит логировать удаления – что удалено, когда и по какому правилу – не логируя само видео. Когда регулятор или запрос субъекта на доступ спрашивает «есть ли у вас ещё видео меня за прошлый месяц?», защищаемый ответ – запись об удалении, показывающая, что видео ушло по графику, а не пожимание плечами. Режимы записи тоже играют роль: система на записи по движению или событию хранит меньше изначально, что упрощает историю удаления.

Нажмите, чтобы увеличить

Исключение, которое перекрывает всё: юридическое удержание

Одно событие приостанавливает всю политику хранения для конкретного видео: юридическое удержание (legal hold, также litigation hold или preservation hold). Когда организация знает или разумно должна знать, что конкретное видео относится к реальному или ожидаемому судебному делу, расследованию или запросу регулятора, возникает обязанность по общему праву сохранить – и плановое удаление этого видео должно остановиться, даже если его срок хранения истёк.

Ставки конкретны. По Федеральным правилам гражданского процесса США (Rule 37(e)) уничтожение электронно хранимой информации, которую следовало сохранить – видеонаблюдение прямо включено, – может повлечь санкции за spoliation (уничтожение доказательств), от инструкции о неблагоприятном выводе (присяжным говорят считать, что утраченное видео навредило бы вам) до решения против вас по умолчанию. Рутинное автоматическое удаление, держащее вас в соответствии в остальное время, становится тем, что топит вас, если пройдётся по видео, которое вы были обязаны удержать.

Из этого следуют два инженерных вывода. Удержание должно быть точечным: оно замораживает конкретные клипы, камеры и интервалы, что важны, пока остальная система продолжает удалять по обычному графику – удержание, замораживающее всё, превращает функцию соответствия в проблему хранения и приватности. И оно должно быть снимаемым: когда дело разрешается, удержанное видео возвращается к обычным часам хранения и удаляется, а не живёт вечно, потому что никто не вспомнил снять удержание.

«Частая ошибка: задача удаления уничтожает видео под удержанием – или удержание, что никогда не снимается. Первое – spoliation: авто-удаление срабатывает на 14 днях и стирает ровно тот клип, что нужен иску, потому что системе не сказали сохранить. Второе – его зеркало: удержание поставлено, дело урегулировано, и три года спустя «временная» копия сохранения всё ещё лежит в хранилище, теперь – нарушение пере-хранения. Рабочая система умеет помечать видео как удержанное, исключать его из автоудаления и – что не менее важно – выводить удержания, готовые к снятию. Стройте заморозку и оттаивание вместе.»

Где Фора Софт в этом

Ретенция – та часть системы видеонаблюдения, где чистая демонстрация и защищаемое развёртывание расходятся, потому что демо никогда не запускает задачу удаления и не получает повестки. Фора Софт строит системы видеостриминга, реального времени и компьютерного зрения с 2005 года – более 250 поставленных проектов, – и работа по видеонаблюдению лежит там, где встречаются хранение, стандарты и приватность. Когда мы проектируем или интегрируем VMS, мы задаём ретенцию явной политикой по классу видео, а не отдаём решение размеру диска, соблюдаем срок через управление максимальным хранением ONVIF Profile G, чтобы разнородные регистраторы подчинялись одному правилу, и строим путь удаления так, чтобы он доставал до экспортов, бэкапов и облачных копий – а не только до основного массива. Мы трактуем биометрический вывод как отдельные, более строгие часы, встраиваем точечный, снимаемый механизм юридического удержания и логируем удаления, чтобы система могла доказать, что удалила вовремя. Привычка «точность против производительности» применяется напрямую: политику судят не в день, когда её написали, а в день, когда кто-то спросит, было ли видео на месте, когда должно было, – и ушло ли, когда должно было.

Ключевые выводы

• Ретенция – записанное решение по классу видео, а не побочный эффект размера диска.
• Её ограничивают два предела: юридический/операционный минимум и максимум закона о приватности.
• Дефолт ЕС – короткий: GDPR ст. 5(1)(e) плюс «несколько дней» EDPB для рутинного видео.
• Отраслевые минимумы (казино 7/60 дней, каннабис 30–90, банки ~90) задают пол для конкретных камер.
• Соблюдайте удаление по политике (ONVIF Profile G MaximumRetentionTime), а не перезапись при заполнении.
• Юридическое удержание замораживает удаление конкретного видео; стройте заморозку и снятие вместе.

Что читать дальше

• Как работает хранение видеонаблюдения: математика ретенции
• GDPR для видеонаблюдения
• Пределы хранения и законное удаление