как да се уверя, че данните в продуктовия паспорт са защитени

Какво конкретно трябва да направите

Какво се очаква от вас

ESPR поставя изисквания към удостоверението за продукта, които се отнасят не само до кои данни са в него, но и как тези данни се управляват и защитават. Член 10 и член 11 на ESPR (Наредба (ЕС) 2024/1781) заедно образуват основата за това: член 10 описва изискванията, на които трябва да отговори удостоверението, член 11 се отнася специфично към техническото проектиране и функционирането. За една стоманена търговия или металообработваща компания, която организира това за първи път, това се разделя на няколко практични точки на внимание.

Регулиране на достъпа до данни според роля

Не всеки, който преглежда удостоверението, трябва да вижда еди едни и същи данни. Един закупник в строително предприятие има нужда от различна информация отколкото надзирател или переработвач в края на живота на продукта. Член 10 на ESPR предполага диференциран достъп: някои данни са публични, други са видими само за определени страни като участници на пазара или органи. За един бизнес от 10 до 100 служители това означава, че преди удостоверението да влезе в живот, трябва да е направен избор относно кой вижда какъв слой от данни — и че този избор е технически наистина приложен, не само на хартия.

Осигуряване на произход и точност на данни

Едно удостоверение за продукта има стойност само ако данните в него са верни и проследими до източника. Това засяга надеждността на цялата система: ако един получател не може да проследи откъде идва един елемент от данни, удостоверението си губи функцията. Практически това означава, че трябва да е документирано кой е доставил кой данен елемент — производителят, вносителят или една междинна страна — и когато е станало това. За компании, които сами не въвеждат данни, а ги преминават, е важно да знаят как данните са доставени в правилния формат, тъй като неправилна доставка води до недостоверно удостоверение по-нататък в веригата.

Защита срещу изменение след публикуване

Член 11 на ESPR описва, че дигиталният продуктен паспорт трябва да функционира технически по такъв начин, че данните да не могат да бъдат променени незабелязано след като бъдат регистрирани. За металообработвателя, който не хостира паспорта сам, а го оставя на хостинг партньор — например чрез платформа като тази — това означава, че изборът на хостинг партньор е също и избор относно начина, по който тази партньор регистрира, логира и защитава промените. Това не е теоретична точка: ако клиент или контролен орган оспорят дадено число от паспорта, трябва да бъде доказуемо кога е регистрирано числото и от кого.

Свързване със съществуващи корпоративни системи

Много компании искат да управляват продуктния паспорт не като изолирана система, а да го свържат с администрацията, която вече имат. Това е възможно, но сигурността на паспорта тогава не е отделна от сигурността на тази подлежаща система. Които разглеждат да свържат паспорта със собствената си ERP или инвентарна система, е добре да преглеждат кой има достъп до това свързване и дали течове в едната система ще имат последствия за другата.

Където нещата се объркват на практика

Редица ситуации се повтарят постоянно в практиката.

При компании, които накарат QR кода да бъде поставен на самия продукт, понякога се пропуска, че кодът сам по себе си не предоставя защита — въпросът е какво се случва зад този код. Който се пита как QR кодът попада на стоманата, трябва също да се пита кой управлява подлежащите данни и дали разделението между носител и съдържание е ясно фиксирано.

Друга ситуация възниква, когато няколко партньори в веригата предоставят данни за един и същ паспорт, без предварително да е договорено кой може да променя кой дял. Това води до объркване относно коя версия е валидна и понякога до случайно презаписване на правилни данни от друга партньор.

Също и при малки компоненти понякога нещо се объркава: ако QR код на малко парче стомана е технически ограничена, понякога се избира опростена връзка или междинна страница — като не винаги се е замислило дали този междинна стъпка следва същите ангажименти за сигурност като главния паспорт.

Четвърта ситуация: компании, които сами съхраняват офлайн копие на данните от паспорта за използване на места без връзка, забравят да синхронизират или защитят то копие по същия начин като онлайн версията. Това е реална точка, защото не всяко работно място има стабилна връзка, и въпросът дали паспортът трябва също да работи офлайн е от значение особено при такъв вид практическо устройство.

И най-накрая: компании, които спират или отчуждават бизнес отдел, понякога забравят, че данните на паспорта остават в съществуване и че достъпът и управлението им трябва да бъдат прехвърлени — нещо, което е свързано с въпроса какво се случва с паспорта, ако компанията спре.

Какво можете да документирате

Редица ангажименти и документи помагат да се покаже сигурността на данните на паспорта:

• Обзор на това кой има каква роля в предоставянето и управлението на данни, включително контактно лице на партньор в веригата.
• Регистрация на източника на всяко число: от кой производител, внос или междинна партньор е то получено и в кой момент е предоставено.
• Ангажименти с хостинг партньора относно логирането на промени, така че да бъде доказуемо кога е регистрирано числото и дали е променено впоследствие.
• Описание на нивата на достъп, които са конфигурирани: кои данни са открити и кои са видими само за определени партньори.
• Ако е приложимо, обзор на свързването със собствената ERP или инвентарна система, с посочени кой има достъп до това свързване.
• План за ситуацията, в която компанията спира или дял се прехвърля, така че управлението и достъпът до съществуващи паспорти да не остават в окачката.

Това документиране не е само полезно по отношение на контрола, но и практично: предотвратява загубата на вътрешни познания за кой какво управлява при смяна на персонала или преглед на компанията.