Security checklist for evaluating AI software for a tax practice

The short answer: vet the tool the way the rules already require

Adopting an AI tool in a tax practice is a security decision before it is a productivity decision. The moment client tax data flows into a third-party system—for document extraction, drafting, notice response, or client communication—that system becomes part of the environment your firm is legally responsible for protecting. Paid tax preparers are treated as "financial institutions" under the Gramm-Leach-Bliley Act, which places them squarely under the FTC Safeguards Rule, and the IRS reinforces the same expectations through Publication 4557, Safeguarding Taxpayer Data. Neither rule stops at your office door; both follow the data.

So the useful question is not "is this AI tool secure?"—every vendor will say yes—but "can this vendor demonstrate the specific safeguards my firm is required to have, and will they put the answers in writing?" This guide gives you an itemized, practitioner-level checklist to do exactly that: encryption, multi-factor authentication, access controls, data retention and deletion, model-training and consent, hosting and subprocessors, breach notification, audit logging, alignment with your Written Information Security Plan (WISP), and independent attestations such as a SOC 2 report.

One honest framing note that runs through the whole article: third-party audits like SOC 2 are things you should ask any vendor about and evaluate on their merits. This checklist tells you what to request and how to read the answer—not which vendors already hold which certifications. Get evidence, not adjectives.

Why a vendor's security is your firm's legal problem

Before the checklist, it helps to be precise about why vendor security is a procurement question rather than an IT afterthought. Three overlapping bodies of rules put the responsibility on you, the firm—not on the software.

The FTC Safeguards Rule extends to your service providers

The Safeguards Rule (16 CFR Part 314) requires every covered firm to maintain a written information security program built on specific elements: a designated qualified individual, a documented risk assessment, access controls, encryption of customer information, multi-factor authentication, secure disposal, monitoring and logging, an incident response plan, and—critically—oversight of service providers. The rule explicitly requires firms to select and retain service providers capable of maintaining appropriate safeguards and to contractually require them to do so. An AI vendor that touches client data is a service provider under this rule. Their weaknesses become your compliance gap.

IRS Publication 4557 and the "Security Six"

Publication 4557 translates these obligations into practitioner language and, with the Security Summit, promotes the "Security Six" baseline: anti-virus, firewalls, multi-factor authentication, backups, drive encryption, and a virtual private network for secure remote access. The IRS is blunt that MFA is now a Safeguards Rule requirement for all tax professionals, not an optional nicety. When you plug an AI tool into your workflow, it must not weaken any of these controls—and ideally it should extend them.

IRC §7216 governs how the data may be used

Separately from how data is protected, Internal Revenue Code §7216 governs how tax return information may be used or disclosed. It imposes criminal penalties on preparers who knowingly or recklessly use or disclose return information for purposes other than preparing the return, absent an exception or the taxpayer's consent, with a companion civil penalty under §6713. As we will see, this is the rule that decides whether an AI vendor may train its models on your clients' data at all.

Put together: you own the responsibility, the vendor holds much of the actual data, and the law does not let you look away. That is why the following checklist matters.

The security checklist, item by item

Work through each of these when evaluating any AI tool. For each item, the goal is not a reassuring sentence on a marketing page but a specific, verifiable answer—ideally in the contract, the data processing addendum, or a security document the vendor will share under NDA.

1. Encryption in transit and at rest

Confirm that client data is encrypted both while moving between your systems and the vendor (in transit) and while stored on the vendor's servers (at rest). In transit, the modern baseline is TLS 1.2 or higher; at rest, strong symmetric encryption such as AES-256. Ask specifically: is data encrypted at rest, not only in transit? Who holds the encryption keys, and are they rotated? "We use encryption" is not an answer—get the where and the how.

2. Multi-factor authentication, enforced

MFA should be mandatory for every account that can reach client data—yours and the vendor's staff. Ask whether MFA is enforced by default or merely available, whether it can be required firm-wide, and which factors are supported. Because the FTC and IRS both now treat MFA as a requirement rather than a recommendation, a tool that cannot enforce it is a poor fit for a tax practice.

3. Access controls and least privilege

The tool should let you grant each user only the access their role requires—preparer, reviewer, admin, front-desk—and no more. Ask about role-based access control, whether client-level or engagement-level restrictions are possible, and how quickly access is revoked when a staff member leaves. Equally important: how tightly is the vendor's own access to your data restricted? Can their support staff read client returns, and under what controls?

4. Data retention and deletion

Know how long the vendor keeps your data, where, and how you get it back or delete it. Ask: can you export your data on demand? When you cancel, is client data deleted, and on what timeline? Is there a documented, verifiable deletion process, or does data linger indefinitely in backups and logs? Retention you cannot control is a liability that outlives the engagement.

5. Model training on your data (the §7216 question)

Ask directly and get it in writing: does the vendor use your clients' tax data to train, fine-tune, or improve its AI models—its own or a third party's? If yes, that use likely goes beyond preparing the client's return and may require specific, informed taxpayer consent under §7216. Many reputable tools contractually commit that customer data is never used for model training; that commitment should be explicit, not implied. This item is important enough to get its own section below.

6. Hosting, region, and subprocessors

Find out where your data physically lives and which other companies (subprocessors) can touch it. Most AI tools rely on cloud infrastructure and often on third-party model providers, each of which is a subprocessor handling your clients' data. Ask for the subprocessor list, whether data stays in the United States, and whether subprocessors are contractually bound to equivalent safeguards. Under the Safeguards Rule, the vendor's supply chain is effectively part of yours.

7. Breach notification terms

Establish exactly how and how fast the vendor tells you about a security incident. This is not hypothetical: as of May 2024, the FTC Safeguards Rule requires covered financial institutions to notify the FTC of a breach involving the unencrypted information of at least 500 consumers as soon as possible and no later than 30 days after discovery. To meet your own obligations, you need the vendor to notify you promptly—confirm a contractual notification window (measured in hours or days, not "reasonable time") and what information you will receive.

8. Audit logging and monitoring

The tool should record who accessed what and when, and let you review that activity. Ask whether user and admin actions are logged, whether you can access those logs, and how long they are retained. Audit trails are both a Safeguards Rule expectation (monitoring and logging authorized-user activity) and your evidence if a client, insurer, or regulator ever asks what happened to a specific return.

9. Independent attestations

Finally, ask what independent verification exists—a SOC 2 report, penetration test summaries, or comparable third-party assessment—and request to review it under NDA. The next-to-last section explains how to read these without over-reading them.

Checklist item	Question to ask the vendor	What a strong answer looks like
Encryption	Is client data encrypted in transit and at rest, and who holds the keys?	TLS 1.2+ in transit, AES-256 at rest, documented key management and rotation
MFA	Is MFA enforced by default for all accounts, including yours?	MFA required firm-wide, not optional, with multiple supported factors
Access & least privilege	Can I limit users by role, and how is vendor access to my data restricted?	Role-based access, engagement-level scoping, limited and logged vendor access
Retention & deletion	How long is data kept, and how do I export or delete it on exit?	On-demand export and a documented, timed deletion process after cancellation
Model training (§7216)	Do you use my clients' data to train or improve any AI model?	A written commitment that customer data is never used for model training
Breach notification	How fast, and how, will you notify me of a security incident?	A contractual notification window in hours/days with defined disclosures
Attestations	What independent audit or SOC 2 report can I review under NDA?	A current report you can actually read, matching the services you'll use

Model training and the §7216 consent question

Of every item on the list, model training is the one most specific to AI—and the one firms most often overlook. Traditional tax software stores and processes your data; generative AI tools can, if the vendor allows it, feed that data back into training pipelines that improve the model for everyone. For a tax practice, that is not merely a privacy preference. It is a legal question under §7216.

Section 7216 makes it a crime for a preparer to knowingly or recklessly use or disclose a taxpayer's return information for a purpose other than preparing that return, unless an exception applies or the taxpayer has given consent. The companion civil penalty in §6713 adds $250 per prohibited disclosure or use, up to $10,000 a year, and the criminal penalty under §7216 can reach a fine of up to $1,000 or up to a year of imprisonment (with steeper exposure where identity theft is involved). Using client data to train an external AI model is a use beyond preparing that client's return—so if a tool does it without proper, informed consent, the exposure lands on the firm, not the vendor.

The practical rule: prefer tools that contractually guarantee your data is never used to train models, and treat any "we may use aggregated or de-identified data to improve our services" language as a flag to investigate, not to wave through. If a vendor's business model depends on training on customer data, either walk away or build a §7216-compliant consent process with your clients before a single return flows through it. Ask the question in writing and keep the answer.

SOC 2 and third-party attestations: what to ask, not what to assume

Firms often want a single reassuring word—"Are you certified?"—and vendors are happy to supply reassuring words. Resist that shortcut. The right move is to ask specific questions about independent attestations and then read the answers critically.

What SOC 2 actually is

A SOC 2 report is an independent examination performed by a CPA firm against the AICPA's Trust Services Criteria—Security (always included) plus optionally Availability, Processing Integrity, Confidentiality, and Privacy. It is an attestation report, not a government "certification." There are two kinds, and the difference matters:

• Type 1 assesses whether controls are suitably designed at a single point in time.
• Type 2 tests whether those controls actually operated effectively over a period (commonly 6–12 months). Type 2 is the stronger evidence.

How to ask, and how to read the answer

Ask the vendor: "Do you have a current SOC 2 report, is it Type 1 or Type 2, which Trust Services Criteria does it cover, and may we review it under NDA?" Then actually read it. Check that the report is recent, that its scope covers the specific service you will use (not an unrelated part of the company), and that the auditor noted no material exceptions relevant to your data. A vendor that shares a real report and lets you read it is demonstrating security; a vendor that only offers the phrase "SOC 2 compliant" on a webpage is offering marketing.

If a tool does not have a SOC 2 report, that is not automatically disqualifying—especially for newer products—but it raises the bar on everything else. In that case, lean harder on the concrete checklist items above: encryption specifics, enforced MFA, the no-training commitment, breach-notification terms, and a data processing addendum you can sign. Independent attestations are one strong signal among several, not a substitute for the rest of the checklist. Judge each vendor on the evidence it can actually produce.

Fitting the tool into your Written Information Security Plan

Every covered tax firm is required to maintain a WISP; the IRS and Security Summit even publish Publication 5708, a WISP template, precisely because there is no small-firm exception—solo and seasonal preparers are covered too. Adopting an AI tool is not a side activity; it changes the systems your WISP is supposed to describe, so your plan has to keep up.

When you bring on a new AI tool, update your WISP to reflect it. Concretely, that means recording:

1. The data it touches. Which categories of client information flow to the vendor, and for what purpose.
2. The vendor as a service provider. Add it to your inventory of service providers, note the contractual safeguards you obtained, and set a date to reassess.
3. Access and authentication. How MFA and role-based access are configured for the tool, and who administers it.
4. Retention and disposal. How long data lives in the tool and how it is deleted, tied to your overall retention policy.
5. Incident response. How a breach at the vendor plugs into your own incident response and notification steps.

Doing this at adoption time—rather than after an examiner or insurer asks—turns the checklist above into durable documentation. A tool that makes these answers easy to record is far less friction to govern than one that leaves you guessing. If you are also rethinking how the firm tracks clients, engagements, and data centrally, our note on a practice management hub and the trade-offs of a built-in versus existing CRM covers where this documentation naturally lives.

Red flags and deal-breakers

Some answers should end the evaluation, or at least stop client data from flowing until they are resolved. Watch for these:

• Vague encryption claims. "Bank-level security" with no specifics on in-transit versus at-rest encryption or key management is a non-answer.
• Optional or absent MFA. If the tool cannot enforce MFA for all users, it is out of step with FTC and IRS expectations.
• Silence on model training. A vendor that won't commit in writing that your data is not used to train models is a §7216 problem waiting to happen.
• No data processing terms. If there is no data processing addendum, no defined breach-notification window, and no deletion commitment, you have nothing to enforce.
• Hidden subprocessors or offshore hosting you can't confirm. If the vendor won't name where data lives and who else touches it, you cannot vouch for the chain your WISP must cover.
• "SOC 2 compliant" with nothing to show. A claim you cannot read is not evidence. Ask for the report; if it never appears, treat the claim as unproven.

None of these means every strong tool must be old or enterprise-scale. A newer product can be perfectly defensible if it answers the checklist honestly and gives you the contractual commitments to back it up. The deal-breaker is not youth—it is opacity.

Running the checklist in practice

Suppose a firm is evaluating two AI tools for document extraction and drafting. The following is an illustrative walkthrough, not a claim about specific products.

Vendor A's website says "enterprise-grade, SOC 2 compliant, secure." Pushed for specifics, they confirm TLS 1.2 in transit and AES-256 at rest, enforce MFA for all users, provide a data processing addendum with a 72-hour breach-notification window, contractually commit that customer data is never used for model training, publish a subprocessor list with U.S. hosting, and share a current SOC 2 Type 2 report—covering the relevant service—under NDA. Every checklist item resolves to a written, verifiable answer.

Vendor B's website makes similar claims. But on questioning, encryption at rest is "on the roadmap," MFA is available but not enforceable firm-wide, the terms of service reserve the right to use "aggregated data to improve our models," there is no breach-notification window, and the SOC 2 reference turns out to be a Type 1 report covering a different product line. The marketing pages read almost identically; the answers do not.

The checklist is what separates them. It converts a security decision from a matter of which vendor sounds more confident into a matter of which vendor can produce evidence. That is the standard your WISP, the FTC Safeguards Rule, IRS Publication 4557, and §7216 all quietly demand—and it is exactly the standard a firm should hold any AI tool to, including this one. When you evaluate automated tax preparation or any other AI capability, ask these questions, get the answers in writing, and keep them with your records. If a tool's answers hold up under that scrutiny, you can adopt it with confidence rather than hope.

Frequently asked questions

Does adopting an AI tool transfer my firm's security obligations to the vendor?

No. Under the FTC Safeguards Rule and IRS Publication 4557, your firm is a financial institution responsible for protecting client data everywhere it goes, including inside a vendor's systems. The rule requires you to oversee service providers and require appropriate safeguards by contract—so the vendor's security becomes your compliance responsibility, not a way to offload it.

Can an AI vendor train its models on my clients' tax data?

Only with appropriate consent. Using return information beyond preparing that client's return can trigger IRC §7216, which requires specific, informed taxpayer consent and carries criminal penalties, plus a civil penalty under §6713. Prefer tools that contractually commit never to use your data for model training, and get that commitment in writing before any client data flows.

Should I require a SOC 2 report before adopting an AI tool?

Ask for one and read it, but don't treat it as a simple yes/no badge. A SOC 2 report is an independent attestation against the AICPA Trust Services Criteria; a Type 2 report (testing controls over time) is stronger than a Type 1. Confirm it's current and covers the specific service you'll use. A newer tool without SOC 2 can still be defensible if it answers the rest of the checklist with written, verifiable commitments.

What are the minimum security controls an AI tax tool must have?

At minimum: encryption in transit (TLS 1.2+) and at rest (AES-256), enforced multi-factor authentication for all users, role-based access controls, a clear data retention and deletion process, a written no-model-training commitment, named hosting and subprocessors, a defined breach-notification window, and audit logging. These mirror the FTC Safeguards Rule and the IRS Security Six baseline.

How does a new AI tool affect my Written Information Security Plan?

It becomes part of the environment your WISP must describe. Record the data the tool touches, add the vendor to your service-provider inventory with its contractual safeguards, document how MFA and access are configured, note retention and deletion, and connect a vendor breach to your incident-response steps. The IRS publishes Publication 5708 as a WISP template, and there is no small-firm exception.

How quickly must a data breach be reported?

The FTC Safeguards Rule, as amended effective May 2024, requires covered firms to notify the FTC of a breach involving the unencrypted information of at least 500 consumers as soon as possible and no later than 30 days after discovery. To meet that, you need your AI vendor to notify you promptly—confirm a contractual notification window measured in hours or days, not vague 'reasonable time' language.

Sources and methodology

This article is based on published IRS guidance, the Internal Revenue Code preparer provisions, FTC rules, and the AICPA Trust Services Criteria. Any illustrative walkthroughs are labeled as such and are not claims about specific products or vendors. Rules and penalty amounts are current as of publication and should be verified for your applicable circumstances.

• IRS — Publication 4557, Safeguarding Taxpayer Data (PDF)
• IRS — Tax pros: Follow the Security Six steps to help protect taxpayer data
• IRS — Tax pros must have a Written Information Security Plan (Publication 5708)
• IRS — Section 7216 Information Center
• FTC — Safeguards Rule: What Your Business Needs to Know
• FTC — Safeguards Rule notification requirement now in effect
• FTC — Amendment requiring non-banking financial institutions to report data breaches
• Legal Information Institute — 26 CFR 301.7216-1 (penalty for disclosure or use of return information)
• eCFR — 16 CFR Part 314, Standards for Safeguarding Customer Information