Every preparer I know treats §7216 as a signature. It's the consent language you paste into the engagement packet, the checkbox the client initials before you e-file, the paragraph your software vendor assured you covers everything. Handle the form, and the rule is handled. For most of my career that's exactly how I treated it too — as paperwork, not architecture.

But §7216 isn't really a rule about forms. It's a rule about disclosure. It says that a tax return preparer who knowingly or recklessly discloses or uses a client's return information, outside of what the law and the client's consent permit, has committed a crime — a misdemeanor carrying a fine of up to $1,000, up to a year in prison, or both, per violation. Its civil twin, §6713, stacks a $250 penalty on each unauthorized disclosure or use, up to $10,000 in a year, and it applies whether or not you meant to do anything wrong. That is a striking amount of exposure to hang on a checkbox.

So the real question §7216 asks is not "did you collect a consent form." It's did this client's information go somewhere it wasn't supposed to go. And the honest answer to that question, for most firms, depends entirely on plumbing they've never looked at.

The rule was written for a world of paper

When §7216 was drafted, disclosure meant something physical. It meant a preparer handing a file to someone across town, mailing a copy, reading numbers aloud. The information moved because a person moved it, and consent was the mechanism that governed the person.

That mental model still runs underneath how we think about the rule — which is why it feels satisfied once the client has signed. But the way return information actually moves today has almost nothing to do with a person carrying a file. It moves the instant you upload a W-2 into a shared-cloud tool. That upload is a disclosure — your client's information leaving your control and arriving on a server owned by someone else, to be stored and processed there. The consent form you collected may well permit it. But the compliance now rests on something you can't see and don't control: what that vendor does with the data once it has it.

Policy is a promise; architecture is a fact

The §7216 regulations do leave room for this. A preparer is generally allowed to route return information to an "auxiliary service provider" — a processing service, a cloud platform — in the course of preparing the return, and those providers are bound by the same restrictions. This is the legal foundation the entire shared-cloud model stands on. It is real, and it is permitted.

But look closely at what it is. It is compliance by policy. Your protection is that the vendor is contractually bound, that its terms say the right things, that its people follow those terms, and that none of that changes in a way that quietly widens how your clients' data can be used. Every one of those is a promise. Good vendors keep their promises. The point is that you are trusting them to — and that trust, not the architecture, is what stands between your clients' information and an improper disclosure.

There is a different way to satisfy the same rule. If the return information never leaves the environment your firm already controls — if the documents are processed inside your own cloud tenant, the same place that already holds your firm's email and files, and no vendor-side copy is ever created — then there is no disclosure to a third party to consent to, govern, or police. You are not promising to satisfy the disclosure restriction. You are structurally unable to violate it, because the information never went anywhere it could be improperly disclosed from.

That's the whole distinction. Privacy by policy asks a vendor to behave. Privacy by architecture removes the need to ask, because the thing the rule is worried about — the data leaving your hands — simply doesn't happen.

Why this stops being abstract

Three things are turning this from a philosophical difference into a practical one.

The first is AI. The moment a tool "reads" a return, the data has to be processed somewhere, and the location question becomes unavoidable. A firm that can't say where its clients' documents get processed can't really say whether §7216 is being satisfied by architecture or only by a chain of promises.

The second is scrutiny. Professional-responsibility enforcement is sharpening, not easing, and data handling is squarely inside it. When an examiner or a board asks how your firm protects return information, "our vendor is certified and we have consent on file" is a policy answer. "The data never leaves our environment" is an architectural one. The second is much harder to argue with, because there's nothing to audit about a disclosure that can't occur.

The third is your clients. They've started asking where their information goes, in plain language, across the desk. §7216 has always been the profession's answer to that question. The firms that will answer it well are the ones for whom the answer is a fact about their systems, not a paragraph about their vendor's.

What this asks of you

None of this removes the preparer, and none of it is about doing less. The machine's job is to do the mechanical work of moving and reading documents inside an environment you control; every value still gets checked before it becomes part of a return, and the licensed human still keeps the judgment and the signature. What changes is the ground the whole thing stands on. Your §7216 posture stops being a maintenance task — a form to keep current, a vendor relationship to manage, a policy to trust — and becomes a property of where your data lives.

I'm not telling anyone their consent forms are wrong or that shared-cloud tools are breaking the law. They aren't. What I'm saying is narrower and, I think, more useful: there are two ways to keep this rule, and they are different in kind. One depends on a promise you can't verify. The other depends on an arrangement you can. In a year when the location of your clients' data is about to become the question everyone asks, it's worth knowing which one your firm is actually relying on.

If the answer is "a promise," the good news is the same as it always is with architecture. It's fixable — not with a better consent form, but with a better place to put the data.

— Yatin Miglani

Enrolled Agent · Phoenix, Arizona
Founder, Sophicor · sophicor.com