Tax Software Vendor Breach in Filing Season: What Should Firms Do First?

By Dr. Alex Heublein, Chief Innovation and AI Officer, Netsurit

A tax software vendor breach during filing season calls for two investigations at once: determine what client data or account access may have been exposed, and verify that returns, payment instructions and filing records have not been changed. The vendor’s investigation matters, but your firm’s response cannot wait for its final report. Secure your own access, preserve evidence, establish which clients and workflows are affected, and prepare to meet your reporting and notification obligations.

If your practice is in the middle of filing deadlines, I know why that answer is uncomfortable. The operational instinct is to keep producing returns while the vendor works out what happened. But the very systems you depend on to meet the deadline are the ones whose integrity you now need to establish.

At a Glance

• Treat a vendor alert as an operational incident, even before client-data exposure is confirmed.
• Separate confirmed facts from plausible exposure; investigate filing changes and data access independently.
• Use a clean communication path to verify vendor instructions and client payment changes.
• Ask whether AI-based monitoring played a role in detecting the incident. An automated alert narrows scope, but does not confirm it.
• Coordinate with the IRS, state agencies, counsel and affected clients as the facts and applicable rules require.

What does a tax software vendor breach actually put at risk?

The phrase can describe very different events. A vendor may have lost an employee’s credentials, suffered ransomware in a support system, discovered unauthorized access to production data, or found that an attacker used a customer-facing integration. A public statement saying that the vendor is investigating an incident tells you almost nothing about which of those occurred in your environment.

Start by mapping the services your firm uses. Whether your practice runs on Intuit’s ProSeries, Lacerte or ProConnect Tax, Thomson Reuters’ UltraTax CS or GoSystem Tax RS, Wolters Kluwer’s CCH Axcess or CCH ProSystem fx, or Drake Tax, the exposure questions are the same. Does the platform store tax return data, identity documents, bank-account details, correspondence or signed authorizations? Can vendor support staff access your tenant? Are there integrations with your document repository, email system, e-signature workflow, AI-based return-review tool or payment platform? Could a compromised vendor identity authenticate to your systems through single sign-on or an application programming interface (API)?

The distinction is consequential. A theft of archived client files creates a notification and identity-fraud problem. Unauthorized account access can also create an immediate filing-integrity problem: an attacker might change a refund account, submit a return or use information to impersonate a client. The two risks overlap, but they need different evidence and controls.

The FTC’s guidance on vendor security makes a simple point: customers entrusted their information to your firm, so a vendor’s breach still demands a response from you. The National Institute of Standards and Technology’s (NIST) current incident-response guidance likewise treats response as part of an organization’s wider risk management, including communication and recovery, rather than as a task to hand entirely to someone else.

Does the vendor’s own AI create a separate exposure?

Many of the platforms above now embed AI directly into the return workflow: automated error-checking, anomaly flagging on unusual deductions or refund amounts, and auto-calculation tools that used to be manual review steps. Those features run on the same access an attacker would gain in a breach, which raises a question most breach checklists never ask: could the incident have changed what the AI evaluates or reports, not just what it can see?

Ask the vendor directly whether a compromised account or API token could have altered the platform’s AI features: retraining data, flag thresholds, or which outputs get escalated for human review. A model that behaves normally today is not proof that nothing was changed while access was open. Ask whether the vendor logs model-level changes, such as threshold edits, retraining events or configuration changes to the AI feature, with the same rigor it logs user access. Many vendors that log data access thoroughly have far thinner logging on this newer layer, because it was instrumented later and often by a different team than the one that built core access controls.

The detection-quality question matters just as much. A vendor’s AI fraud-detection tool with a high baseline false-negative rate gives an attacker room to operate even without touching the model at all. Ask the vendor to share the tool’s baseline detection performance, not just a description of the feature, so your firm can judge whether “nothing was flagged” means anything.

Treat any AI-based control in the vendor’s platform as its own item to verify during recovery. Confirm it is running the same model version, the same thresholds and the same training data lineage it used before the incident, not just that the feature is back online and producing results that look normal.

How should you respond in the first few hours?

You need one person coordinating the response, with representatives from operations, security, legal or privacy, and client service. Establish an incident record that marks what is known, what remains unconfirmed and who owns each decision. Save the vendor’s notice in its original form, record times and names, and preserve relevant access logs before retention windows roll over.

Secure access without destroying evidence

Confirm the notice through a vendor contact or portal you already trust, not a phone number or link inside the alert itself. A fake “urgent vendor breach” message is an obvious route for credential theft during an actual incident, and generative AI has made these fakes harder to spot: convincing vendor branding, correct account-manager names and matched writing style are no longer reliable signs of authenticity. Then identify affected user accounts, active sessions, API tokens, connected apps and support access. Reset or revoke credentials and sessions when justified by the threat, following the sequence your incident responders advise so they can preserve useful evidence. Do not assume that changing a password alone terminates a stolen session token.

Review multifactor authentication settings and recent enrollment changes. Look for unusual logins, new devices, mailbox forwarding rules, exports and administrative changes. If the vendor cannot yet say whether an integration token was accessed, treat that as an unresolved exposure, not as proof that it was safe.

Protect the filing workflow

Reconcile recent returns against your own source records. Check submission time, preparer account, client identity, refund destination, e-signature trail and acknowledgment status. Where possible, use records independent of the affected platform. For returns ready to file, decide which steps can continue under additional verification and which need a temporary hold. Document the decision so staff do not invent different workarounds under deadline pressure.

Do not email sensitive returns back and forth simply because the portal is suspect. A rushed workaround can create a second breach. If you need an alternative exchange method, use an approved channel with access controls and retention rules you understand.

Which questions must the vendor answer?

Ask for a timeline: when access began, when it was detected, when it was contained, and whether the attacker still had access when your firm was notified. Ask which products, tenants, data fields, users, support functions and integrations are in scope. Ask whether logs can identify which client records were viewed or exported and whether return data or payment instructions were modified.

You also need to know what evidence the vendor will preserve, whether an independent forensic team is involved, how often it will update customers, and whether its recommended mitigations are tailored to your configuration. Ask how the incident was found in the first place: flagged by the vendor’s own automated or AI-based monitoring, reported by a customer, or surfaced by law enforcement or an external researcher. That answer tells you how much confidence to place in the vendor’s stated timeline. A vendor whose AI-driven detection caught the activity in near real time is describing a different exposure window than one that learned about it from a ransomware leak site. Ask for the basis behind every reassuring statement. “We have no evidence of exfiltration” means something different when detailed access logs exist than when the relevant logging was never enabled.

The vendor may not know the answers immediately. Track each unanswered question with a named owner and a next update time. Avoid turning an early estimate into a permanent fact in your client communications. Clients need accurate information, and you may need to revise the scope as the investigation develops.

When should the IRS, states and clients be told?

The answer depends on what happened, the type of data, the people affected, and the laws that apply. Your counsel and incident team should work through that assessment early, rather than waiting until the technical investigation is complete. The IRS advises tax professionals who suffer data theft to report promptly to their local Stakeholder Liaison; timely reporting may help the IRS block fraudulent returns. The IRS also points preparers toward state tax agencies and other reporting channels.

Not every vendor notice establishes that your firm has suffered client data theft. That is why scope matters. At the same time, a lack of complete proof is no excuse for doing nothing. The FTC breach-response guide recommends assembling a response team and deciding who needs notification based on the facts. For firms covered by the FTC Safeguards Rule, separate notification requirements may apply; the FTC explains its notification trigger and timing. State requirements may differ.

Prepare a client message that states what is known, what your firm has done, what the client should watch for and where a verified update will appear. Explain if a return or refund destination needs verification. Avoid speculative assurances, vague requests to “be vigilant” and links to new portals that clients have no reason to trust. Your client-facing staff need the same approved account of the incident, with an escalation route for unusual filing or identity-theft reports.

How do you keep the practice working safely?

Divide work into three queues: returns that are unaffected and can proceed, returns requiring a second verification step, and returns that must wait for a clean system or a specific answer. Set criteria for moving work between queues. That sounds bureaucratic until the deadline is close and five preparers make five different assumptions about whether the vendor’s systems are safe.

If your firm uses AI-based anomaly detection for login behavior, e-file volume or refund-destination changes, treat a spike in flagged activity as an early signal that a compromised account may already be filing on your behalf, not as noise to clear before the deadline. These tools can scan thousands of returns for pattern deviations faster than any manual review, but they are only as reliable as the data they are trained on; validate every flagged case against source records rather than dismissing it because volume is high during filing season.

If a client says a refund account changed, or your staff find an unexpected e-file acknowledgment, escalate immediately. Preserve the record before correcting it. If the incident appears to involve a compromised preparer account, audit every action performed under that identity during the relevant period, not only the returns scheduled today.

Test restored access before lifting restrictions. A vendor’s declaration that service is back online may establish availability, but availability is not proof of integrity. Confirm that the connections, permissions, user sessions and audit trails you rely on have been checked. This is also the right moment to review backup access, secondary communications and how you will meet a filing deadline if a critical vendor is unavailable again.

A recurring weakness in vendor incidents sits on the firm’s side of the relationship: a contract exists, but there is no usable inventory of what the vendor can actually access. An access map built before the event shortens the investigation considerably when time matters most.

FAQ

The operational test

The first question after a vendor alert is usually, “What did the vendor lose?” During filing season, I would add another: “Can we still prove that the return we submit is the one the client authorized?” A responsible response answers both, even if the answers arrive at different times.

Related reading: securing client tax data from ransomware, data breach insurance, and post-breach auditing.

If your firm needs to map vendor access, protect filing workflows or coordinate an incident response, speak with Netsurit about managed cybersecurity.