Where Your Clients’ Financial Data Lives: A Data Sovereignty Checklist for Accounting Firms

Isometric illustration of a secure vault protecting financial documents and tax records on a sovereign US cloud

An accounting firm holds some of the most sensitive data its clients will ever hand to anyone: Social Security numbers, bank and brokerage details, full income pictures, payroll records, audit working papers, and the deal documents behind mergers and acquisitions. The duty to protect that data does not stop at the office door, and it does not stop at the edge of your network. When client files live in the cloud, the obligation follows the data wherever it goes, including onto infrastructure you do not own, in datacenters you have never seen, operated by people you have never met.

That obligation is not just professional courtesy. It is law and standards stacked several layers deep:

  • Internal Revenue Code Section 7216 makes it a crime for a tax return preparer to knowingly or recklessly disclose or use tax return information without the client’s consent, with criminal penalties on top of the civil ones under Section 6713.
  • The FTC Safeguards Rule, which implements the Gramm-Leach-Bliley Act, treats accounting and tax preparation firms as “financial institutions” and requires a written information security program with a designated Qualified Individual, encryption of customer information in transit and at rest, multi-factor authentication, access controls, monitoring, and an incident response plan.
  • IRS Publication 4557 and the WISP mandate require every paid preparer, regardless of size, to create and maintain a Written Information Security Plan. The IRS now ties this to PTIN renewal, so it is an annual attestation, not a one-time exercise.
  • The AICPA Code of Professional Conduct (the confidential client information rule) binds CPAs to protect client information independently of any of the above.

None of these rules tell you which cloud to use. All of them make you responsible for the consequences of choosing badly.

This is a checklist for evaluating where your firm’s client data lives, written for the partner or IT director who has to make a defensible decision and document the reasoning behind it, because under a WISP that documentation is itself a requirement.

Why “the cloud” is not a single answer

The reflex answer is a mainstream SaaS suite: store everything in the big productivity cloud, bolt on a portal, and assume the vendor has it handled. For ordinary documents at many firms, that is genuinely fine. But the standard the Safeguards Rule sets is risk-appropriate safeguards, and the risk is not uniform. Confidentiality is heightened for certain engagements: audit and attest working papers, M&A and capital-raise due diligence, forensic accounting and litigation support, high-net-worth individuals, family offices, and any client under SEC, IRS, or DOJ scrutiny.

For those engagements, three questions that the default SaaS answer glosses over become the whole decision: where does the data physically live, who can access it, and can you prove both.

The checklist

1. Data residency: do you know where the files physically are?

Many large cloud platforms move data between regions for performance, redundancy, and cost. For a firm with a confidentiality obligation, “somewhere in the provider’s global network” is not a satisfying answer to a client who asks where their financial records are, and it is not a clean line in a WISP.

Ask: Can the provider state, specifically, the datacenters where your data is stored and processed? Can they commit that it stays within the United States? Can they put it in writing?

A provider with US-only datacenters and a contractual residency commitment lets you answer a client’s question with a sentence instead of a shrug.

2. Personnel: who can touch the data, and under what jurisdiction?

Data residency is only half the picture. If your data sits in a US datacenter but can be administered by support staff anywhere in the world, the jurisdictional clarity you were trying to buy is gone, and your Section 7216 and Safeguards exposure travels with it.

Ask: Are the people who operate the infrastructure US persons? Is administrative access restricted, logged, and auditable? Can the provider produce a record of who accessed what?

3. Access control: is it built on the firm’s identity, or the vendor’s?

Confidentiality inside the firm matters as much as confidentiality from outsiders. The staff accountant on an engagement should reach that engagement’s files; the person walled off for an independence or conflict reason should not, and you should be able to prove the wall held. For audit firms, this is also an independence-safeguard question, not only a privacy one.

Ask: Does the platform support single sign-on from your firm’s identity provider, multi-factor authentication, and role-based access scoped to the engagement or workspace level? Can you produce an access log showing who reached which files and when?

The Safeguards Rule names access controls and MFA explicitly. A platform with workspace-scoped access and a complete audit trail turns “we restrict that” into “the system enforced it, and here is the record.”

4. Audit trail: can you reconstruct who did what?

The Safeguards Rule’s breach-notification amendment requires notifying the FTC of a security event involving the unencrypted information of 500 or more consumers, as soon as possible and no later than 30 days after discovery. You cannot scope a notification, or decide whether you even have one, if you cannot tell which files were accessed.

Ask: Does the platform log every access and administrative action? How long is the log retained? Can you export it? Is the log itself protected from tampering?

A complete, retained, exportable, tamper-resistant audit trail is the difference between a defensible incident response and a guess, and it is the evidence your WISP’s incident response plan assumes exists.

5. Encryption: in transit, at rest, and who holds the keys?

The Safeguards Rule requires encryption of customer information in transit and at rest, so this is not optional. The detail that decides real exposure is key custody. If the provider holds the only keys, your clients’ confidentiality ultimately depends on the provider’s own access controls and on lawful-access demands made to the provider rather than to you.

Ask: Is data encrypted in transit and at rest? What standard? Can the firm hold or control its own keys? Is the cryptography validated, not just claimed?

6. Legal hold and retention: can the platform hold records immutably?

Accounting firms live under long retention clocks: audit documentation retention rules, the seven-year working-paper retention that applies to issuer audits, IRS recordkeeping expectations, and litigation holds when a dispute is reasonably anticipated. The storage layer should support all of this natively.

Ask: Can the platform place content under a hold that prevents deletion or alteration? Does object storage support write-once-read-many (WORM) retention for records that must be immutable? Can retention policies be set per engagement or client?

7. Portability and exit: can you take the data and leave?

A firm’s relationship with a cloud provider should not become its own form of data-hostage situation. If changing providers means a painful, expensive, lossy extraction, that cost will eventually pressure a confidentiality or continuity decision in the wrong direction.

Ask: Are the storage and access APIs open and standard? Can you export everything without penalty or egress fees? If you leave, do you leave clean?

8. The breach plan: does the provider cooperate, and is it contractual?

When something goes wrong, the clock and the obligations are yours: the FTC’s 30-day window, state breach-notification laws, client and possibly regulator notice. Meeting those obligations depends partly on the provider.

Ask: Will the provider notify you of an infrastructure-layer incident, and on what timeline? Will they preserve evidence and cooperate with an investigation? Is that cooperation a contractual term or a hope? Your Safeguards Rule program also requires you to oversee service providers by contract, so this belongs in writing regardless.

How Open Edge maps to the checklist

We are a managed cloud built on open standards, and our Managed OpenCloud product is a file-sharing and collaboration platform designed for exactly this kind of confidentiality-sensitive use. Against the checklist:

  • Data residency: US-only datacenters, with a residency commitment you can put in front of a client or write into your WISP.
  • Personnel: US-person operators, with administrative access restricted, logged, and auditable.
  • Access control: single sign-on from your firm’s identity provider, MFA including hardware keys, and role-based access scoped to the workspace level, which is the technical backstop for engagement walls and independence safeguards.
  • Audit trail: a complete, retained, exportable, tamper-resistant log of access and administrative activity, sized to support a real notification decision inside the 30-day window.
  • Encryption: in transit and at rest, against a FIPS 140-3 validated cryptographic module, with customer-managed key options.
  • Legal hold and WORM: object storage with object-lock for write-once-read-many retention, and retention policies you control per engagement.
  • Portability: open standard APIs, no egress fees, clean exit. We say this knowing it lets you leave, because a firm should never be locked in by the thing it trusted with its most sensitive files.
  • Breach cooperation: an incident process that surfaces infrastructure-layer events to you, with evidence preservation and cooperation as part of how we operate, and as a contract term your Safeguards program can point to.

Managed OpenCloud also gives the firm the practical collaboration features that make this usable day to day: web-based document editing, cross-platform sync, persistent client and engagement spaces, full-text search, and an architecture in which the platform administrators cannot read user content.

One honest note on language: we follow SOC 2 and ISO 27001 control frameworks and our architecture supports the obligations described here. We do not claim certifications we do not hold, and for a firm documenting its Safeguards program, a provider that is precise about what it is and is not should be a feature, not a red flag.

The defensible decision

Your WISP is, in the end, a documentation exercise that the IRS now makes you attest to every year. If a security question is ever raised, by a client, the FTC, or a court, you want a file that shows you asked where the data lives, who can touch it, how access is controlled and logged, how it is encrypted, how records are held, and how you would respond to a breach, and that you chose a provider whose answers were specific and in writing.

This checklist is part of that file. Whether or not you choose us, run your current and prospective providers through it. The engagements that need it most, the audits and the deals and the disputes, are exactly the ones where a vague answer will not hold up later.

Want to walk the checklist against Managed OpenCloud for your firm, including the engagement-wall and WORM-retention specifics? Reach out at https://open-edge.io/contact.