Ако вашата фирма изготвя федерални данъчни декларации, обработва ведомости за заплати или има достъп до банковите извлечения на клиенти, федералното правителство вече ви счита за „финансова институция“ — и считано от отчетния сезон през 2026 г., IRS няма да поднови вашия PTIN, освен ако не удостоверите, под страх от наказателна отговорност за лъжесвидетелстване, че имате писмена програма за информационна сигурност (WISP). Това удостоверяване не е просто формалност. То е клетвена декларация, че вашата фирма е внедрила деветте елемента на Правилото за предпазни мерки на FTC (FTC Safeguards Rule), определила е Квалифицирано лице за управление на програмата, тествала я е през изминалата година и има план за докладване на пробив в сигурността пред регулаторите в рамките на тридесет дни.
Повечето самостоятелни специалисти и малки счетоводни кантори научават за изискването за WISP или когато клиент поиска такава като част от въпросник за проверка на доставчици, или когато IRS изпрати писмо за „информираност за сигурността на данъчните професионалисти“ след инцидент с фишинг. Нито един от тези моменти не е подходящ за започване от нулата. Това ръководство разглежда какво всъщност трябва да съдържа WISP, как Правилото за предпазни мерки на FTC се адаптира към реалността на малката фирма и как да създадете надеждна програма, без да наемате външен CISO или да купувате корпоративен инструмент за GRC (управление, риск и съответствие).
Защо WISP вече не е по желание
Два регулаторни органа стоят над всеки данъчен консултант и счетоводител в Съединените щати и те се подкрепят взаимно.
Първият е IRS, който изисква писмен план за сигурност съгласно Раздел 7216 и Закона Грам-Лийч-Блайли (Gramm-Leach-Bliley Act) от години, но едва наскоро му придаде реална тежест. Започвайки с цикъла на подновяване на PTIN за 2024 г., всеки изготвящ декларации трябва да потвърди, че има актуален WISP. Прозорецът за подновяване през 2026 г. добавя изрично удостоверяване за деветте елемента на Правилото за предпазни мерки на FTC. Неверните или небрежни удостоверявания са нещата, които се откриват постфактум по време на разследване на пробив, а погрешното твърдение в заявление за PTIN е отделно нарушение от самия пробив.
Вторият е Федералната търговска комисия (FTC), която прилага Правилото за предпазни мерки съгласно 16 CFR Part 314. FTC има правомощието да налага граждански неустойки до 100 000 долара за нарушение срещу фирми, които не успяват да поддържат съвместима програма, а „нарушение“ може да бъде дефинирано тясно — липсата на един-единствен механизъм за контрол в стотици клиентски досиета е вид математика, която е довела до осемцифрени споразумения срещу по-големи данъчни консултанти.
Правилото за предпазни мерки също така беше затегнато през последните три години. Изменението от октомври 2023 г. изисква фирмите да уведомяват FTC в рамките на 30 дни за всяко „събитие за уведомяване“ — неоторизирано придобиване на некриптирана информация за клиенти, засягащо 500 или повече души. Това изискване за докладване влезе в сила през май 2024 г. и FTC вече го е използвала за идентифициране на фирми, които не са имали WISP по време на пробива. Пробив без план е много по-лоша ситуация от пробив с такъв.
За данъчните професионалисти тази структура означава, че един инцидент с фишинг може да доведе до риск за PTIN пред IRS, граждански санкции от FTC, разследвания от главния прокурор на щата съгласно законите за уведомяване при пробив в 50-те щата и вълна от искове за кражба на самоличност от засегнатите клиенти. WISP е единственият документ, който значително намалява мащаба на тези последствия.
Деветте елемента, които трябва да документирате
Правилото за предпазни мерки на FTC изброява девет специфични програмни елемента в 16 CFR § 314.4. Шаблонът на IRS в Публикация 5708 организира своите раздели около същите девет и WISP, който не адресира всеки от тях писмено, не е съвместим WISP. Ето какво всъщност означава всеки елемент в една малка фирма.
1. Определяне на квалифицирано лице
Трябва да посочите едно лице — по длъжност и по име — което е отговорно за програмата за сигурност. FTC е изрична, че Квалифицираното лице не се нуждае от конкретна степен или сертификат. Важното е ролята да е документирана, лицето да има правомощия да взема решения и да се отчита пред висшето ръководство поне веднъж годишно. В самостоятелна практика Квалифицираното лице обикновено е собственикът. В малка фирма това често е управляващият съдружник или офис мениджърът, подпомаган от външен доставчик на ИТ услуги (MSP) за техническата работа. Ролята може да бъде възложена на външен изпълнител, но отговорността не може.
2. Провеждане на писмена оценка на риска
Оценката на риска идентифицира предвидимите вътрешни и външни рискове за клиентската информация в хартиените записи, цифровите файлове, облачните приложения, имейлите, мобилните устройства и всякакви услуги на трети страни, които използвате. Тя трябва да бъде писмена, периодична и достатъчно специфична, за да може някой, който я чете, да види какви заплахи сте разгледали. Таблица от една страница, показваща „актив → заплаха → вероятност → въздействие → смекчаване“, е достатъчна за повечето малки фирми. Двуредово изявление, че „използваме антивирусен софтуер“, не е.
3. Проектиране и внедряване на защитни мерки
Правилото за защитните мерки (Safeguards Rule) посочва конкретни технически контроли, на които вашата програма трябва да обърне внимание: контроли на достъпа, инвентаризация на активите, криптиране на клиентската информация в покой и в движение, практики за сигурна разработка на всякакви вътрешни приложения, многофакторна автентификация за всяка система, която осъществява достъп до клиентски данни, сигурно изхвърляне на клиентска информация не по-късно от две години след последното взаимодействие, управление на промените и мониторинг на дейността на оторизираните потребители.
Двете контроли, които повечето малки фирми грешат, са криптирането и MFA. Правилото изисква криптиране на клиентската информация във вашите системи и в движение. Ако вашите договори за ангажимент стоят некриптирани в папка на Dropbox, синхронизирана с личен лаптоп, това е нарушение. MFA трябва да използва поне два от трите фактора за автентификация — знание, притежание, биометрия — и единственият начин да бъде пропуснато е писмено одобрение от Квалифицираното лице за еквивалентна контрола. „Неудобно е“ не е еквивалентна контрола.
4. Редовен мониторинг и тестване на защитните мерки
Правилото изисква или непрекъснат мониторинг, или годишно тестване за пробив (пенетрационни тестове) и двугодишни оценки на уязвимостта. За малка фирма реалистичният път е вторият: сканиране за уязвимости с автентификация два пъти годишно и тест за пробив ежегодно, ако обработвате значителен обем декларации или високорискови клиентски данни. Резултатите от тестовете трябва да бъдат документирани и прегледани от Квалифицираното лице.
5. Обучение на вашия персонал
Всеки служител с достъп до клиентска информация се нуждае от подходящо за ролята си обучение по сигурност, като това обучение трябва да се опреснява периодично. Квалифицираното лице се нуждае от нещо повече от базово обучение. Симулации на фишинг, хигиена на паролите, сигурна работа с файлове и процедури за докладване на инциденти са задължителните теми. Регистрите за обучение — дата, присъстващ, тема — трябва да се съхраняват в папката на WISP.
6. Надзор над доставчиците на услуги
Ако използвате доставчик на данъчен софтуер, платформа за съхранение в облака, услуга за подписване на документи, процесор за ведомости или приложение за счетоводство, това са доставчици на услуги според Правилото. Трябва да ги избирате въз основа на способността им да поддържат подходящи защитни мерки, да изисквате от тях по договор да го правят и периодично да оценявате дали продължават да отговарят на тези стандарти. Докладите SOC 2 Type II са стандартното доказателство; доставчик, който не може да представи такъв, е сигнал за внимание.
7. Поддържане на програмата актуална
WISP е жив документ. Правилото изисква да оценявате и коригирате програмата в светлината на резултатите от тестовете, съществени промени в операциите и промени в пейзажа на заплахите. Минимум годишен преглед, плюс опресняване винаги, когато сменяте данъчния софтуер, мигрирате към нова облачна платформа, отваряте нов офис или привличате нов партньор.
8. Съставяне на писмен план за реакция при инциденти
Планът за реакция при инциденти (IRP) трябва да уточнява вътрешния процес за реагиране на събитие в сигурността: цели, роли и отговорности, вътрешни комуникации, външни комуникации, запазване на доказателства, стъпки за отстраняване на последиците и преглед след инцидента. Планът трябва също така да включва пътя за регулаторно уведомяване — към FTC в рамките на 30 дни за събития, засягащи над 500 души, към службата на IRS за връзки със заинтересованите страни (IRS Stakeholder Liaison) за всяка кражба на данни и към главния прокурор на всеки щат съгласно съответния щатски закон за нарушения на сигурността.
9. Годишно отчитане пред борда (или собственика)
Квалифицираното лице трябва да докладва писмено, поне веднъж годишно, пред управителния орган на фирмата — борда, управляващия партньор или едноличния собственик. Докладът обхваща цялостното състояние на програмата, съществените рискове, резултатите от тестовете, проблемите с доставчиците на услуги и всички събития в сигурността. За фирма от един човек това означава, че собственикът пише меморандум до себе си, поставя му дата и го архивира. Изглежда глупаво, докато не се окажете лице в лице с инспектор от FTC.
Шаблонът на IRS Publication 5708 е най-лесната отправна точка
Security Summit — партньорство между IRS, щатските данъчни агенции и основните доставчици на данъчен софтуер — публикува попълваем шаблон на WISP като IRS Publication 5708. Това е документ от 28 страници, структуриран около деветте елемента на FTC, който води малката фирма през всеки задължителен раздел. Последните редакции добавиха текстове относно работните процеси за одобрение на MFA, алтернативи за криптиране и процеса за 30-дневно уведомяване за нарушение.
Две практически бележки относно Публикация 5708:
- Разглеждайте я като скеле, а не като завършен план. Шаблонът изисква да попълните специфичните за вашата фирма защитни мерки, доставчици, теми за обучение и контакти за реакция при инциденти. WISP, който все още съдържа заместващия текст (placeholder), е по-лош от липсата на WISP — той е документално доказателство, че не сте извършили оценка на риска.
- Не прескачайте приложенията. Приложението за класификация на данните, инвентаризацията на активите и списъкът с доставчици са частите, които правят WISP защитим. Реакция при нарушение, която започва с „не знаем точно кои клиенти са засегнати“, защото не е имало инвентаризация на активите, е най-лошата възможна отправна точка.
Придружаващата публикация, IRS Publication 4557 — Safeguarding Taxpayer Data, е по-дълго образователно ръководство, което обхваща по-широкия контекст: федералните и щатските закони за уведомяване при нарушения, често срещани модели на атаки срещу данъчни специалисти, работния процес за докладване към IRS, когато EFIN на съставителя е компрометиран, и списък с безплатни или евтини технически ресурси. Прочетете я веднъж, запазете я в отметките си и се връщайте към нея, когато наемате нов персонал.
Реално изграждане: 90-дневен план за малка фирма
Създаването на Писмен план за информационна сигурност (WISP) от нулата е плашещо най-вече защото регулациите описват програма за корпоративна сигурност на език, който не съответства ясно на счетоводна фирма от шест души. Ето една последователност, която действително е подходяща за малка практика.
Дни 1 до 14 — Инвентаризация и определяне. Определете Квалифицираното лице писмено. Изградете инвентара на активите: всяко устройство, което има достъп до клиентски данни, всяко облачно приложение, всяко местоположение на хартиени досиета, всеки доставчик на услуги. Инвентарът е най-влиятелният документ в WISP — оценката на риска, решенията за криптиране, надзорът на доставчиците и реагирането при инциденти се позовават на него.
Дни 15 до 30 — Оценка на риска. Прегледайте инвентара и идентифицирайте предвидимите заплахи. Фишинг срещу персонала. Изгубен лаптоп със синхронизирани клиентски файлове. Рансъмуер, криптиращ хранилището за документи. Пробив при доставчик, излагащ клиентски качвания. Оценете всеки риск, отбележете текущите мерки за смекчаване и посочете пропуските.
Дни 31 до 60 — Внедряване на механизми за контрол. Запълнете пропуските. Многофакторна автентификация (MFA) във всяка система, която има достъп до клиентски данни, включително данъчен софтуер, имейл, облачно съхранение, подписване на документи и платформи за счетоводство. Пълно криптиране на диска на всяка работна станция и лаптоп. Процедури за сигурно изхвърляне на хартия, твърди дискове и папки на бивши клиенти. Договорите с доставчици са актуализирани, за да включват задължения за сигурност. Обучението на персонала е стартирано с регистър за проследяване на завършването.
Дни 61 до 80 — Напишете плана. Отворете Публикация 5708 и попълнете всеки раздел спрямо инвентара, оценката на риска и механизмите за контрол, които вече сте внедрили. Напишете плана за реагиране при инциденти с конкретни имена за контакт, работния процес за докладване към FTC и контакта на връзката със заинтересованите страни към IRS за вашия регион. Документирайте графика за годишен преглед.
Дни 81 до 90 — Тестване, обучение, докладване. Проведете симулация на плана за реагиране при инциденти. Направете сканиране за уязвимости от реномиран доставчик. Проведете официалната сесия за обучение на персонала и подгответе списъка за присъствие. Напишете първия годишен доклад на Квалифицираното лице, подпишете го и го архивирайте.
В края на 90-те дни разполагате със защитим WISP. Това не е еднократно действие; това е началото на годишен цикъл, който подобрява програмата с всяка изминала година.
Къде повечето малки фирми все още не успяват
След като наблюдавахме стотици малки практики да преминават през своя първи WISP цикъл, едни и същи пропуски се появяват многократно.
- Третиране на WISP като Word документ вместо като оперативна практика. Планът, прибран в чекмеджето, не е програма. Доказателството за съответствие живее в дневниците за обучение, прегледите на доставчиците, докладите от сканиране на уязвимости и годишните доклади до борда — не в самия документ на плана.
- Объркване на поверителността на клиентите със сигурността на данните. Клаузата за поверителност в договора за ангажимент е договорно задължение. Правилото за предпазни мерки на FTC (FTC Safeguards Rule) е регулаторно задължение с технически, административни и физически изисквания за контрол. Те се застъпват, но не са едно и също нещо.
- Игнориране на личните устройства. Ако партньор проверява клиентски имейл на личен телефон, този телефон попада в обхвата на WISP. Оценката на риска трябва да го обхване, MFA трябва да бъде наложена на него, а планът за реагиране при инциденти трябва да го предвиди.
- Пропускане на прегледа на доставчиците на услуги. Доставчик, който претърпи пробив, засягащ вашите клиенти, все пак ви оставя отговорни за уведомяването на FTC, ако не можете да демонстрирате подходящ надзор. Годишният преглед на SOC 2 отнема час и може да спаси фирмата.
- Оставяне на работния процес за докладване на пробив в категорията „ще го измислим, ако се случи“. 30-дневният срок от FTC започва при откриването, а не на датата, на която решите, че инцидентът е реален. Предварителното подготвяне на формуляра за докладване, списъка с контакти за уведомяване по щати и номера на застрахователя за киберсигурност в WISP е разликата между контролиран инцидент и регулаторен хаос.
Какво общо има доброто счетоводство с това
WISP е по същество история за записите — какво притежавате, къде живее то, кой може да го докосва и какво правите, когато нещо се обърка. Фирмите, които се борят най-много с Правилото за предпазни мерки, са същите, които се борят със собственото си счетоводство: разпръснати записи в несвързани системи, липса на история на версиите, липса на одитна следа за това кой какво е променил и кога.
Връзката не е случайна. Счетоводната практика, изградена върху обикновен текст (plain-text) и счетоводство с контрол на версиите, ви дава същите примитиви, от които се нуждае една надеждна програма за сигурност: единен източник на истина, история, защитена от подправяне, способността да възстановите точно какво е било състоянието на света на всяка конкретна дата и възможността да предоставяте или отнемате достъп, без да губите следата. Когато FTC попита какви клиентски данни сте притежавали на датата на инцидента, „позволете ми да проверя главната книга към онзи момент“ побеждава „позволете ми да проверя дали онзи архив все още е добър“.
Поддържайте финансовите записи на вашата фирма толкова защитими, колкото и вашия WISP
Писменият план за информационна сигурност е толкова добър, колкото и записите, които защитава. Ако вашите собствени книги живеят в непрозрачни системи без история на версиите, вече сте загубили одитната следа, която Правилото за предпазни мерки на FTC, вашият застраховател за професионална отговорност и вашите клиенти очакват да поддържате. Beancount.io осигурява счетоводство в обикновен текст с Git версии, което дава на счетоводните фирми пълна прозрачност върху собствените им финансови данни — всяка трансакция, всяка рекласификация, всяко равнение, уловено в история, защитена от подправяне, която вие действително контролирате. Започнете безплатно и управлявайте практиката си според същия стандарт за доказателства, който дължите на клиентите си.