Before you let an AI tool touch a single client tax return, one question outweighs the demo: is it safe? Make the stakes concrete first. A CPA firm in Albany paid New York's Attorney General $60,000 in October 2025 — client SSNs left unencrypted on shared drives, two ransomware hits a year apart, and no notice to the people whose data walked out the door for more than sixteen months [R1]. That breach had nothing to do with AI. But it's exactly the failure mode you're weighing the moment you wire an automation into client data.
So is AI safe for accounting firms? The honest answer is that it depends entirely on three things: where your client data actually goes, who's contractually on the hook when something breaks, and whether the AI runs inside the security controls you already have — or bolts a new gap onto the side. Get those three right and AI automation is no riskier than the tax software you already trust. Get them wrong and you've built yourself a Wojeski. This piece walks the whole question, end to end.
Picture the morning the second envelope arrived. Wojeski & Co. had already been hit by ransomware in July 2023. They were hit again in May 2024 [R1]. About 4,993 New York residents had their data exposed, and the firm didn't notify them until November 2024 — more than sixteen months after the first breach [R1]. The Attorney General settled at $60,000 [R1].
Sixty grand isn't the lesson. The lesson is the chain of small operating choices the AG's office wrote down: SSNs sitting on shared drives without encryption, no clean notification process, no enforced timeline [R1]. None of that is exotic. Most firms reading this have at least one of those three conditions live in their environment right now. The Wojeski penalty is what it looks like when the framework you're already inside finally asks you to show your work.
Before you can judge whether an AI tool is safe, you need to know what "safe" is measured against. And here's the part nobody tells you when you ask a vendor about "compliance": you're already inside a stack of overlapping rules, and most of the updates landed in 2024 while you were closing the prior year. Any AI automation you add doesn't get its own rulebook — it has to satisfy this one. Put simply, CPA firm cybersecurity compliance is the set of obligations that govern how your firm protects client financial data — and almost none of it is optional.
Wherever your firm practices — the US, the UK, the EU, Australia — the shape is identical: a layered set of rules about guarding client data, each layer added by a different authority, almost none of it optional. The names and dates below are the US versions. If you're outside the US, read them as the worked example and swap in your own regulator; the trap doesn't change with the acronyms.
Start with the FTC Safeguards Rule. The US Federal Trade Commission classifies tax preparers and accountants as "financial institutions" — the same legal bucket as a bank — which means the Rule applies to your firm regardless of size [R4]. The breach-notification amendment took effect May 13, 2024. If a breach touches 500 or more people, you have 30 days to notify the FTC. Civil penalties run up to $51,744 per violation per day [R3]. That's the clock that turned the Wojeski sixteen-month gap into an enforcement story.
Layer on the second rule: in the US, every tax firm is expected to keep a written plan for how it protects client data. The August 2024 update made two concrete demands — turn on multi-factor authentication everywhere (that second login step beyond a password), and report breaches on the same 30-day / 500-person clock as the FTC [R2]. If your security plan still reads like it did in 2022, your auditor — or your insurer — will notice.
Then local law sits on top. Several US states now require "reasonable safeguards" for residents' data, and California finalized formal cybersecurity-audit rules on September 23, 2025 [R5]. The detail matters less than the pattern, and European readers will recognize it instantly: it's the same logic as GDPR sitting over each country's own rules. The smaller the jurisdiction, the more likely it has bolted on its own layer.
There's also a professional-standards layer — your own industry's rulebook, not the government's. Since January 1, 2024, the US tax-standards rules explicitly name AI: you have to check a tool's track record before relying on it, verify what it produces, confirm it isn't inventing citations, and never let it replace your own judgment [R6]. That last duty is the one that turns a careless ChatGPT paste into a professional-conduct problem, not just a security one. Every accounting body — US, UK, EU — has some version of this duty of care; the US just wrote AI into it early.
A few more layers only kick in for certain work, and most small firms never touch them. Handle health-related data for a client and you pick up US medical-privacy obligations [R7]. Audit publicly traded companies and a separate federal regime applies — but that's a big-firm world most practices never enter [R9]. Take card payments and the card networks' security rules apply, though your payment processor does most of that work for you [R10]. Do security-sensitive advisory work for defense contractors and a newer certification regime is phasing in through late 2026 [R11]. If none of those describe your firm, set them aside.
That's the stack. None of it is SOC 2.
So why does every AI vendor pitch lead with SOC 2? Because SOC 2 Type II is what your firm demands from vendors, not what your firm operates under day-to-day [R8]. IRS Pub 4557 says it plainly — request the vendor's SOC 2 report and keep it in your vendor file [R14].
Outside the large-client and outsourced-accounting segment, most small and mid CPA firms don't need their own SOC 2 report [R8]. They need to know which of their vendors have one, what's in it, and who signs the breach SLA. Confusing the two is how firms end up paying $40K for an audit they didn't need while their actual FTC exposure sits unaddressed.
Two categories of vendor, two different questions.
For off-the-shelf SaaS — tax software, document portal, hosting, BPO partner — the question is: "Where's your current SOC 2 Type II report?" That's the report you forward to your auditor and put in your vendor file [R14].
For an engineering partner building software for your firm — custom workflow tools, AI automation that runs inside your environment, anything bespoke — the question is different. The right question is: "Is the software you write SOC 2 ready? When it runs inside my environment, will it hold up under my auditor's checklist without introducing a new control gap?"
Both kinds of vendor still owe you the same two follow-ups: what's your breach-notification SLA, and does it match my FTC 30-day clock? And is my client data used to train your models, ever? [R12, R13]
If a vendor can't answer those four questions cleanly, the answer isn't more diligence. It's a different vendor.
Strip the marketing off and the mechanics are simple. When an AI tool is wired up under SOC 2-style controls, the data takes three trips: prompt in, model response out, and both logged under your retention policy. Each trip is encrypted, logged, and scoped to the people who are supposed to see it.
Three places it goes wrong, mechanically.
First, the AI provider has no business contract — the firm is using the free, consumer version of ChatGPT or Claude. The security controls you're counting on don't reach the free tier; the paid business tier is where the written agreement about how your data is handled actually lives [R12].
Second, the prompt contains the client's real name, SSN, or account number when it doesn't have to. The model "sees" identifying details that should have been replaced with safe tokens first [R13].
Third, the prompt log is sitting somewhere outside your normal audit perimeter. If your auditor can't find it, neither can you when the FTC asks [R13].
Fix those three and the AI is operating inside your existing controls, not around them.
SOC 2 ready, not SOC 2 attested. We don't sell you a SaaS with its own SOC 2 Type II report. We build software that runs inside your firm's environment, and we build it to be SOC 2 ready — meaning it follows the control patterns your auditor expects: encryption in transit and at rest, scoped access logging, retention policy enforced, no client data retained for model training. When your firm gets its own audit, or when a client's vendor questionnaire lands on your desk, the software we wrote sits on the right side of the line. No new control gap. No new piece of infrastructure your auditor hasn't already approved.
Anonymize, mask, redact. Client identifying data — names, SSNs, account numbers — is replaced with safe tokens before the AI ever sees the prompt, and re-mapped only inside your environment [R13].
Piggyback on existing infrastructure. The AI runs in or alongside your current tax software, document portal, and accounting platform. Your VPN, your access controls, your audit logs stay in charge.
The owner-facing version: you don't move data anywhere new. Your staff doesn't get a new system to log into. Your existing backups, your existing security controls, your existing audit trail all extend to cover the AI. The compliance posture you already paid for does the work.
That's the point of doing it this way. Every new system is a new control gap, a new vendor questionnaire, a new line in next year's WISP. Adding AI shouldn't add any of those.
What we won't promise: zero residual risk. Nobody can. The vendors who do are the ones who end up in OCR press releases [R13]. What we will tell you: which controls operate, who audits them, what our breach-notification SLA is, and what happens when something fails.
For context on why that matters right now — SitusAMC, a third-party provider used across the financial sector, was hit by a cyberattack uncovered on November 12, 2025, with data theft affecting major banks including JPMorgan Chase, Citi, and Morgan Stanley [R15]. That's the recent named third-party failure CPAs are now expected to vet for during vendor due diligence. The pattern is consistent: the breach almost never starts in your office. It starts at a vendor you forgot you depended on.
Yes — when three conditions hold. The AI runs on a paid business tier with a real contract (not the free consumer version), client identifiers are stripped out before the prompt is ever sent, and the whole thing operates inside the security controls and audit trail your firm already has [R12, R13]. Miss any of the three and you've added a gap, not a safeguard. The risk lives in the setup, not in the AI itself.
It's the federal rule that treats your CPA firm as a "financial institution" and requires you to protect client financial data with written security controls. Since May 13, 2024, if a breach touches 500 or more people, you have 30 days to notify the FTC, and penalties run up to $51,744 per violation per day [R3, R4].
Probably not, outside the large-client or outsourced-accounting segment [R8]. The report matters most as something you collect from vendors — but be careful what you ask for. From an off-the-shelf SaaS (tax software, document portal), request their SOC 2 Type II report for your file [R14]. From an engineering partner who builds software that runs inside your environment, a company-wide SOC 2 report is the wrong ask — what matters is whether the software they write is built compliant: SOC 2 ready, sitting inside the controls you already have, adding no new gap. Different vendor, different question.
Not the free, consumer version. There's no business contract behind it and no agreement about how your data is handled, and using it conflicts with the accounting profession's own vendor-vetting and confidentiality duties [R6, R12]. Paid enterprise tools with the right contracts and with client details stripped out before the prompt is sent are a different conversation [R13].
Your clock starts when you know. That's why the vendor's breach-notification SLA matters: if they take 25 days to tell you, you have 5 days left on the FTC clock [R3]. Negotiate this in the contract, not in the incident.
