Finance and accounting · Work you can show

You already owe the document this belongs in

Most advice about writing an AI policy starts from a blank page. If you prepare tax returns you are already required to hold a written information security plan — with a named owner, an annual reporting cadence and a service provider section. The AI part is six additions to a document you already have.

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

1. The list of tools — including the ones you did not buy Named applications, not a category. This is the part that gets skipped, and the AI embedded in software you bought for other reasons is the part that gets missed inside it.
2. Approved, and a default of no Which tools staff may use for client work, and the position on everything else. "Not yet approved" is a real answer and a much better one than silence, because silence reads as yes.
3. What may never be pasted, in categories your staff recognise Not "confidential information" — that is invisible at eleven at night in March. Name the actual artefacts: return information, SSNs and EINs, bank details, the client's name alongside their numbers. Tax return information carries its own statutory constraint under Sec. 7216.
4. Where the output goes Into the engagement file, or only into a window? For SEC- registered advisers, 17 CFR 275.204-2 puts a five-year life on communications relating to advice given or proposed to be given, and the draft counts.
5. Who reviews it, and how the review is evidenced "Staff will review output" is not a control. Name who signs, on what, and where the sign-off lands. If nothing records that the review happened, it did not happen as far as anyone outside the room is concerned.
6. What happens when it goes wrong Who is told, in what order, and how fast. Firms covered by the amended Regulation S-P already run an incident response programme with a 30-day notification duty; 314.4(h) requires "a written incident response plan designed to promptly respond to, and recover from, any security event."

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.

Want this running in your own practice? Let's talk.