Чому ваші файли PDF/A постійно отримують відхилення під час аудиту відповідності

Уявіть це. Фінансова команда архівувала звіти клієнтів і записи про операції PDF/A за останні шість років. Кожен файл містить правильний тег метаданих. Кожен співробітник вірить, що робота виконана в момент збереження файлу. Потім регулятор з’являється для планової перевірки, пропускає кілька цих файлів через валідатор, і половина з них виходить з ладу.

Жоден документ ніколи не чіпався, нічого не робилося по-іншому. Ці документи ніколи не відповідали вимогам, вони просто заявляли про відповідність. І саме ця різниця між «стверджувати, що це PDF/A» і «бути PDF/A» є однією з найпоширеніших і дорогих сліпих плям архівування документів сьогодні.

Отже, якщо ваші спроби архівування зазнають невдачі та/або якщо ви хочете залишатися на правильному боці процесу, ось що насправді йде не так і як створити надійний робочий процес для Відповідність PDF/A.

Чому відповідність PDF/A має більше значення, ніж усвідомлює більшість команд

PDF/A — це не просто «PDF з архівом». Це формат, визначений стандартами ISO, щоб гарантувати, що документ відкриватиметься і виглядатиме точно так само зараз, через десять років і через п’ятдесят років, незалежно від того, яке програмне забезпечення чи шрифти були встановлені для його читання на той момент.

Це набуває великого значення, коли йдеться про регулювання. Такі нормативні акти, як GDPR, вимагають від компанії підтримувати цілісність, конфіденційність і доступність своїх персональних даних. Такі нормативні акти, як MiFID II, зобов’язують фірму зберігати комунікаційні дані та дані про транзакції клієнтів протягом багатьох років у форматі, який неможливо таємно змінити. Зробіть тут щось не так, і ви можете зіткнутися зі штрафами, які вимірюються однозначними відсотками від вашого річного доходу, що є значною сумою для великої компанії.

Ось чому коли Відповідність PDF/A відсутній в архіві, це не вважається проблемою з технологією. Це вважається проблемою дотримання нормативних вимог, і відповідальність лежить на відповідній фірмі.

Найпоширеніші причини, через які файли PDF/A не проходять перевірку

Більшість збоїв PDF/A пов’язані з коротким списком повторюваних проблем. Ось де зазвичай все йде не так.

Шрифти, вбудовані не повністю

Безсумнівно, це найпоширеніша причина проблеми. Для файлу PDF/A всі шрифти, які використовуються в документі, мають бути вбудовані у файл, щоб переглядачу не довелося встановлювати шрифти на своєму комп’ютері. У багатьох випадках у PDF-файл вбудовано лише підмножину шрифту, яка зазвичай не проходить процес перевірки. У минулих дослідженнях, проведених на реальних файлах PDF/A, було виявлено, що більше половини випадків невідповідності виникають через шрифти.

Кольорові простори, незалежні від пристрою

Згідно з вимогами PDF/A, колір має бути описаний за допомогою незалежних від пристрою профілів ICC, щоб забезпечити узгоджене відтворення незалежно від монітора, принтера чи прикладного програмного забезпечення, яке ви використовуєте для перегляду документа. Цікаво, що одна з найпоширеніших помилок під час створення PDF/A пов’язана з документом, заснованим на певному просторі кольорів (наприклад, звичайний sRGB), у якому відсутній необхідний профіль ICC.

Метадані, які не відповідають дійсності

Кожен документ PDF/A має містити метадані XMP із зазначенням того, якій версії PDF/A він сумісний (PDF/A-1, -2 або -3) і на якому рівні відповідності (A, B або U). Ненадання таких метаданих або надання їх у неправильний чи оманливий спосіб означає миттєвий збій ще до початку аудиту.

Безладна історія поступових оновлень

Поступове оновлення додає додаткові дані до наявного PDF-документа без переписування всього документа з нуля. Це зручний варіант у стандартних PDF-файлах, але для PDF/A файли, це робиться обережно:

• •PDF/A-1 взагалі не дозволяє поступове оновлення. Будь-яке редагування має призвести до повного перезапису файлу.
• •У PDF/A-2 і PDF/A-3 дозволено поступове оновлення; однак додані дані мають відповідати решті документа. Додавання редакції за допомогою невбудованих шрифтів, наприклад, робить увесь файл недійсним.
• •Номер версії в заголовку файлу також має відповідати версії, заявленій у внутрішньому каталозі документа. Невідповідність тут легко пропустити і простий спосіб провалити перевірку.

Перетворення документа в PDF/A не є еквівалентом перевірки PDF/A

Це сфера, де багато компаній спотикаються; і це має бути чітко сформульовано.

Перетворення бере документ, незалежно від його вихідного формату (документ Word, сторінка HTML або PDF), і перетворює його на PDF/A файл. При цьому програмне забезпечення додає метадані, які засвідчують, що щойно створений файл є PDF/A-сумісним.

Валідація — це зовсім інший процес, коли спеціальна програма перевіряє, чи справді файл відповідає всім вимогам для отримання сертифіката.

Але тут є поворот: метадані, вставлені на етапі перетворення, є заявою, а не доказом. Файл може містити інформацію в своїх метаданих про те, що він сумісний з PDF/A-2b, але не пройшов перевірку PDF/A-2b.

Що ще гірше, багато безкоштовних і відкритих кодів Валідатори PDF/A використовуйте евристику, а не порівняння рядків із усією специфікацією. Це означає, що вони часто заявлятимуть, що документ «імовірно» дійсний, що спочатку може здатися гарною новиною, але це точно не так. Ще один спосіб перевірити відповідність – візуально, коли хтось просто відкриває документ і дивиться, чи правильно він виглядає.

Щонайменше кожен файл PDF/A має:

• •Вставте всі шрифти, зображення та вміст напряму, без жодних зовнішніх посилань
• •Повністю уникайте форм аудіо, відео, JavaScript і XFA
• •Пропустіть стиснення LZW, шифрування та захист паролем
• •Надайте кожному полю інтерактивної форми словник належного вигляду
• •Зберігайте метадані за стандартом XMP

Пропустіть перевірку, і ви повірите, що кожне з цих полів було встановлено правильно, навіть не підтверджуючи це.

Рівні відповідності не є взаємозамінними

Іншим тихим джерелом невдалих перевірок є невідповідність рівня відповідності, коли файл заявляє про рівень відповідності, якому він насправді не відповідає.

Тут варто зрозуміти дві речі:

Самі стандарти відрізняються один від одного. PDF/A-1, PDF/A-2 і PDF/A-3 були опубліковані з різницею років і не мають однакових правил. PDF/A-1, наприклад, не підтримує прозорість або шари та пропонує лише рівні відповідності A та B. PDF/A-2 додав підтримку прозорості, шарів і навіть вбудовування інших файлів PDF/A разом із новим рівнем U.

Рівні відповідності будуються один на одному. Рівень U включає все необхідне для рівня B, а рівень A включає все необхідне для рівня U та багато іншого. Вибір правильного рівня — це не просто технічна деталь, це рішення, яке має реальні наслідки щодо того, наскільки придатним для використання буде ваш архів через роки. Наприклад, архів претензій, у якому документи мають залишатися доступними для пошуку та вилучення тексту, потребує принаймні рівня U. Рівень B сам по собі цього не гарантує.

Рівень U стосується цілісності тексту. Це гарантує, що базовий текст Unicode в документі можна буде надійно витягнути або здійснити пошук пізніше, що надзвичайно важливо для будь-якого архіву, який може знадобитися переглядати або шукати через роки після подання.

Як насправді виглядає надійний конвеєр PDF/A

Обґрунтований процес архівування зазвичай має таку форму:

Нормалізуйте вихідний документ → Перетворіть на PDF/A → Перевірте самостійно → Архівуйте файл

Це крок, який більшість організацій зазвичай пропускають, але це найважливіший крок. Якщо програмне забезпечення, яке перетворює файл в іншу форму, є програмним забезпеченням, яке перевіряє процес перетворення, все, що ви робите, це перевіряєте результат, створений програмним забезпеченням, на основі специфікації, яку програмне забезпечення розуміє. Неправильні інтерпретації специфікації, зроблені програмним забезпеченням, не будуть виявлені, доки файл не буде перевірено незалежним валідатором.

Надійний аудиторський слід повинен включати:

• •Запис про те, хто та коли конвертував кожен файл
• •Назва та версія використовуваного інструменту
• •Незалежний звіт про перевірку, що підтверджує заявлений рівень відповідності, в ідеалі з позначкою часу та зберігається разом із самим документом

Очікується, що генерація та перевірка виконуватимуться різними системами; звіти про валідацію мають бути машинозчитуваними та зберігатися як доказ аудиту; узгодженість між заявленим і фактичним вмістом має бути реальною. Відповідно до GDPR та MiFID II, відповідальність за забезпечення підтвердження цілісності повністю лежить на власнику архіву, а не на постачальнику програмного забезпечення.

Висновок

Файл PDF/A, який не пройшов незалежну перевірку, насправді є просто файлом, який сподівається, що він відповідає вимогам. Це може бути добре протягом багатьох років, аж до тих пір, поки регулятор не попросить переглянути архів. будівля Перевірка PDF/A у конвеєр як окремий, незалежний крок – це те, що перетворює архів, який має надію, на архів, який можна захистити, і це набагато дешевша звичка створити зараз, ніж штраф, який потрібно сплатити пізніше.

---