IRC §7216: Sharing Client Tax Data With a Financial Advisor
Sending a client's tax return information to their wealth advisor is a disclosure, and under IRC §7216 it requires the taxpayer's prior written consent in a separate document naming the recipient and the information. For an individual client that means a standalone consent, not a clause in the engagement letter. The provision is criminal, carrying up to $1,000 and one year per violation, with civil penalties under §6713 on top. Almost every firm in the country does this by hand with a Word template, because until now nothing connected the signed consent to the system that actually moves the data.
What this looks like for your client → · See how CPA Hub enforces it →
What counts as a disclosure
More than most practitioners assume. Treas. Reg. §301.7216-1(b)(3) defines tax return information to include figures derived or computed from the return, so all of the following are covered:
- the return itself, or any part of it
- source documents — a K-1, a 1099, a brokerage statement
- an adjusted gross income estimate, a marginal bracket, an IRMAA tier, a Roth conversion headroom figure, a capital-loss carryforward
- any of those numbers typed into an email or a message thread to the advisor
The rule attaches to the information, not the container. A figure in a message is a disclosure exactly as an attachment is.
The three rules that catch people out
Consent must come first. There is no retroactive consent. A signature obtained after the fact does not cure the disclosure that already happened.
For an individual client, it cannot live in your engagement letter. Rev. Proc. 2013-14 requires a separate document whose text pertains solely to the consent. (A business client that does not file a Form 1040 is the exception: under Treas. Reg. §301.7216-3(a)(3)(iii) its consent may be in any format, including an engagement letter.) Folding an individual's consent into the engagement letter is the single most common implementation error, and it is the one that makes an otherwise careful firm's paperwork worthless.
Use and disclosure are different consents. A single document cannot authorize both. Permission to disclose your client's information to their advisor is not permission to use it for anything else, and the two cannot be combined onto one page.
What a valid consent has to contain
Rev. Proc. 2013-14 — still operative, modified once by Rev. Proc. 2013-19 and never superseded — prescribes the format and specific mandatory sentences. In substance the document must:
| Requirement | Detail |
|---|---|
| Be a separate document | Its text pertains solely to the disclosure. |
| Name the recipient | The specific party receiving the information. |
| Describe the information | The particular information being disclosed, not a general grant. |
| Carry a signature and date | Electronic signature is permitted, by PIN, typed name, or five or more unique characters. |
| State a duration | If unspecified, the default is one year from the date of signature. |
| Be given to the taxpayer | A copy goes to the client. |
On a joint return, the information belongs to both spouses — so one signature does not authorize disclosing the other's information, and a properly built consent produces one signed document per spouse.
The gap between having a consent and enforcing one
Almost every firm can produce a consent form. Very few can stop a disclosure.
The reason is architectural. Practice management platforms model sharing as a permissions problem — who has a login, which folder they can open, which tab is visible. That answers an identity question. §7216 asks a different one: what was authorized, to whom, and for how long. Because consent is not represented in those systems as an object at all, there is nothing to attach to a share event and nothing to enforce against.
So the signed PDF sits in a folder, invisible to the system that actually controls the advisor's access, and three things follow:
- Nothing blocks an unauthorized disclosure. A staff member grants folder access in three clicks and no consent is consulted.
- Expiry is nobody's job. A one-year consent lapses silently while the advisor's login keeps working.
- Withdrawal depends on memory. A client withdraws, and honouring it means someone remembering which folders, which shares, and which portal accounts to unwind.
Where enforcement does exist in tax software, it solves a different problem — gating internal or offshore staff access to a binder, or blocking an e-file until a bank-product consent is signed. Those are real and they work. Neither covers an ongoing, expiring, revocable relationship with a third party your client names. No practice platform we have found treats consent as an object at all.
What enforcement actually looks like
CPA Hub's Advisor Bridge treats the signed consent as the thing that governs, not paperwork filed alongside it.
The consent is a real object. It names the advisory firm, lists the exact items authorized, carries a duration the taxpayer sets, and stores the signed text with a cryptographic digest so it can be proven unaltered afterwards. A joint return produces one signed document per spouse, and every one of them must be signed and live before anything moves.
It is checked at the moment of disclosure, not once at setup. Publishing a figure, sharing a document and sending a message each consult the consent as they happen. If none exists, or it has expired, been withdrawn, or does not cover that item or that tax year, the action is refused and the specific uncovered items are named. There is no override — an override is the feature that would make everything else here worthless.
It fails closed, in both directions. The advisor's continuing view of an already-published snapshot stops too, because reading it is itself a continuing disclosure. And when something is withheld, the advisor is told so rather than shown an empty list — "nothing was shared" and "something was shared that you may not see" must never look identical.
Every disclosure and every refusal is recorded. Who saw what, when, and under which signed consent. Access grants, permission escalations and revocations are logged too. If a client, a successor firm or an examiner asks what left your office and on whose authority, that is a report rather than a search of your sent folder.
Two levers when a relationship ends
They answer different questions, and neither implies the other.
| Lever | What it ends | Use when |
|---|---|---|
| Revoke the consent | The taxpayer's legal authorization, and all disclosure with it — including continuing access to material already published. | The client withdraws, or the purpose has ended. |
| Revoke the access grant | The advisor's ability to reach that client at all. | The advisor leaves, the client changes advisors, or the engagement ends. |
A revoked consent with a live access grant leaves a relationship that still looks active in your client's file. A revoked grant with a live consent leaves an authorization outstanding that nobody is using. When a relationship ends, close both.
Where §7216 sits next to the FTC Safeguards Rule
Firms tend to treat client data protection as one obligation. It is two, and they are unrelated in law.
The FTC Safeguards Rule governs how you protect the data you hold — your WISP, your risk assessment, your encryption and access controls. Failure is civil.
IRC §7216 governs whether you were permitted to hand it over. Failure is criminal, and no amount of security makes an unauthorized disclosure lawful. A firm with an immaculate WISP that emails a K-1 to an advisor without consent has satisfied the first obligation and breached the second.
Covering one has never covered the other. Read the WISP guide →
Frequently asked questions
What counts as a disclosure under IRC 7216?
More than most practitioners assume. Tax return information includes figures derived or computed from the return, so an AGI estimate, a marginal bracket, an IRMAA tier or a capital-loss carryforward all qualify — as does any of those numbers typed into an email or message thread. The rule attaches to the information, not the container.
Can the 7216 consent be part of my engagement letter?
For an individual client, no. Rev. Proc. 2013-14 requires a separate document whose text pertains solely to the consent, and folding it into an engagement letter is the single most common implementation error. The one exception is a business client that does not file a Form 1040: under Treas. Reg. §301.7216-3(a)(3)(iii) its consent may be in any format, including an engagement letter.
What must a valid 7216 consent contain?
It must be a separate document, name the specific recipient, describe the particular information disclosed, carry the taxpayer's signature and date, and state a duration. Electronic signature is permitted. If no duration is stated the default is one year from signature, and a copy must be provided to the taxpayer.
How long does a section 7216 consent last?
For the period stated on the document. If the consent does not specify one, federal regulations set the default at one year from the date of signature. The taxpayer may withdraw at any time, after which disclosure must stop.
Is IRC 7216 the same thing as the FTC Safeguards Rule?
No, and covering one has never covered the other. The FTC Safeguards Rule governs how you protect the data you hold and failure is civil. IRC §7216 governs whether you were permitted to hand it over and failure is criminal. A firm with an immaculate WISP that emails a K-1 to an advisor without consent has satisfied the first obligation and breached the second.