CPA firm software security: twelve questions to ask a vendor

Agree on the evidence before scoring the vendor

Record the answer, responsible person, supporting document and date for each question. Distinguish a feature demonstrated now from a contractual undertaking and a planned improvement. A test should include a denied action as well as a permitted one. Otherwise a polished demonstration only shows the happy path.

IRS Publication 4557 offers guidance on safeguarding taxpayer information. The FTC’s Safeguards Rule guidance identifies tax preparation firms among potentially covered financial institutions and describes a written security program for covered organizations. The firm determines its applicable obligations; a vendor questionnaire is one input to that work, not a declaration of compliance.

1. Who can create, invite and recover an account?

Ask who authorizes a new account, how an invitation reaches the intended person and what happens when an email address changes. Include administrators, temporary staff and support access. Recovery can bypass otherwise strong authentication if the requester’s identity is not checked appropriately.

• Request: the invitation, identity-check and recovery procedure, demonstrated with a fictional user.
• Warning sign: shared accounts or an account reset based solely on knowing a client name.

2. How does MFA work, including device loss?

Identify the authentication method, where it is required, who can turn it off and how a lost device is handled. CISA recommends MFA wherever possible and the strongest available option, favoring phishing-resistant methods. An authenticator app and a security key are not interchangeable security claims.

• Request: the enrollment and recovery flow, administrative settings and stated exceptions.
• Warning sign: “MFA available” without explaining whether sensitive users can bypass it.

3. Which records and operations does each role control?

Separate seeing a page from reading or changing the underlying record. Ask for the permissions matrix by operation and the method used to enforce it. A hidden button is insufficient evidence that the corresponding request is refused. Include imports, exports, reassignment and approval in the scenarios.

• Request: role documentation and demonstrations of permitted and denied actions on sample records.
• Warning sign: rights described only through menus or screen colors.

4. What happens to sensitive rights when someone leaves?

Identify who can approve, mark filing or payment milestones, delegate authority and change another user’s rights. Then test offboarding: accounts, active sessions and connected services can have separate lifetimes. Ask when each access stops and who confirms completion, rather than assuming one disabled field revokes everything.

• Request: an offboarding checklist and the actual effect of disabling or revoking a sample account.
• Warning sign: immediate revocation promised without testing existing sessions or delegated access.

5. What does the audit trail actually cover?

List recorded objects and events, author information, timestamps and before-and-after values where relevant. Ask how long records remain accessible and who can alter or remove them. An edit history for jobs does not automatically establish logs of every login, download or administrative action.

• Request: sample event records, coverage boundaries and retention terms.
• Warning sign: “everything is traced” without a defined list of events.

6. Can the firm reuse its data when it exits?

Define which records, attachments, relationships and history are exported, in which formats and on what timetable. Open the files and try to reconstruct a small fictional engagement outside the service. A readable spreadsheet may still omit supporting documents or identifiers needed to interpret its rows.

• Request: a sample exit package and a documented export procedure.
• Warning sign: an export called a backup without a supported restoration process.

7. How are imports, backups and restoration controlled?

For imports, inspect preview, duplicate handling, overwrites and error reporting. For recovery, ask which data is backed up, how restoration is tested and what loss window or recovery objective is contractually stated. A successful upload is not proof of import completeness; a scheduled backup is not proof of recoverability.

• Request: sample import errors and dated recovery-test evidence appropriate to the service.
• Warning sign: “daily backups” offered as the entire answer to recovery.

8. Where do the application and subprocessors handle data?

Map the marketing website, application hosting, support services, storage and AI processing separately. Ask for each provider’s role, processing region and applicable transfer arrangements. A region named for one service does not describe the others. Include updates to the processor list and the notice procedure.

• Request: the service-specific processor inventory and applicable data-processing terms.
• Warning sign: “no third party receives data” when hosted services or AI providers are used.

9. What is encrypted, and who controls the keys?

Distinguish transport protection, storage encryption and application-level protection of secrets. Ask about the exact data categories covered, key management and access to decrypted information. Encryption of integration tokens does not establish end-to-end encryption of every document or prevent every authorized person from reading data.

• Request: an architecture-level explanation identifying protected data and secret-management controls.
• Warning sign: “everything is encrypted” without scope or key-access details.

10. What can an integration read or change?

Review the permissions requested from the connected service and the operations the application actually performs. Authorization scope and implemented behavior are different questions. Ask who can connect an account, how tokens are protected, and how to revoke the connection from both sides.

• Request: a fictional connection, an operation inventory and the disconnect procedure.
• Warning sign: broad authorization described as a guarantee of read-only behavior.

11. Which information reaches the AI service?

Inventory automatic context, free-text questions and any attachments. Ask for the provider, processing region and the written terms governing retention and model training. A user can introduce identifying information into a question even when a structured extract is limited. Check how professional approval fits the workflow.

• Request: representative transmitted fields and the service-specific processing commitment.
• Warning sign: anonymous processing claimed without examining free text.

12. What do external assurance and incident commitments cover?

If a SOC 2 report or ISO 27001 certification is supplied, examine its scope, entity, period, exceptions and any customer responsibilities. A badge is not a substitute for the document. Separately clarify incident contacts, contractual notification, support and any service-level commitments actually offered.

• Request: the applicable assurance document and signed incident and service terms.
• Warning sign: a subcontractor’s badge presented as certification of the whole application.

Use TAXFINAI’s security information as the starting record

The published TAXFINAI security page describes roles and permissions, two-factor authentication, defined categories of change history and protected QuickBooks connection tokens. It also describes US-only AI processing under the provider’s written commitment to zero retention and no model training. Keep each statement within its stated scope.

Use the security questionnaire to record your firm’s requirements, then ask for a demonstration on fictional data and the applicable contractual documents. Give the resulting assessment an owner and a follow-up date. A software choice, a new integration or a changed engagement can justify revisiting the answers.

Common questions