Under 16 CFR 314.4, a covered financial institution must "develop, implement, and maintain" a written information security program. And as the previous post in this series sets out, the rule's own examples say an accountant or tax preparation service is a financial institution.
We are not your compliance adviser and none of this is advice. It is a description of published rules with the links attached, so you can hand it to the person who is.
The IRS Security Summit publishes a sample plan for exactly this audience — Publication 5708, Creating a Written Information Security Plan for Your Tax & Accounting Practice — and Publication 4557, Safeguarding Taxpayer Data, as the guide alongside it.
So the question is not should we write an AI policy. It is what does AI add to the plan we already owe. That is a much smaller job, and it starts with a document that already has a person's name on it.
The scaffolding is already in the rule
Three parts of 314.4 do most of the work before you write a word about AI.
Paragraph (a): "designate a qualified individual responsible for overseeing and implementing your information security program and enforcing your information security program." So there is already an owner. You do not need to invent a second governance structure with a different name.
Paragraph (b): the program is based on "a risk assessment that identifies reasonably foreseeable internal and external risks." A tool staff are already pasting into is a reasonably foreseeable internal risk, whether or not anyone has written it down.
Paragraph (i): the qualified individual reports "in writing, regularly and at least annually, to your board of directors or equivalent governing body." There is your review cadence, already required, already dated.
An owner, a risk assessment and an annual written report. Three things every AI governance article tells you to build, and a tax practice is already required to have all three.
The six things to add
That is a page. Possibly two. It is not a manual, and a manual would be worse — a policy nobody has read is a policy that is not in effect.
A policy that cannot be followed gets routed around
Here is one of ours, and it is embarrassing in a useful way.
We built a rule to stop one specific dangerous command from ever running on our machine. It worked. It then refused a note we were writing that explained why the command was dangerous — because the note contained the command's text.
Two things came out of that. The gate refused rather than allowed, which is the right way round to fail. And the files most likely to trip a policy are the ones explaining the policy.
The lesson transfers directly. A rule that makes ordinary work impossible does not get complied with; it gets worked around quietly, and then you have a policy that is both ignored and inaccurate, which is worse than not having written it. If your draft would stop a reasonable person doing a reasonable thing at nine at night in busy season, it will not survive busy season.
What to do
Open the plan you already have and find the name in it. Paragraph (a) already made you designate someone. That person owns this, today, without a new committee, a new title or a new document.
Give them the first three of the six: the tool list, the paste rule and the review evidence. That is an afternoon and it covers most of the exposure. The other three can ride on the annual written report the rule already requires, which means they already have a date.
The cost of not doing it is not the penalty. It is that when something does go wrong, the first thing anyone asks for is the written plan, and "we had good practices" is not a document. You will be writing it that week either way. The only thing you control is whether it is dated before the event or after it.
If you would rather draft the AI section alongside somebody who has had to write one, start here.