The law stack
A CPA firm that prepares tax returns or runs payroll is legally a “financial institution,” which pulls Lazar — and any vendor that touches client data — under three federal regimes plus California law.
- GLBAGramm-Leach-Bliley Act
- The root federal law. Classifies tax/financial firms as financial institutions that must protect nonpublic personal information (NPI).
- FTC Safeguards Rule16 CFR Part 314
- The enforceable controls under GLBA: written security program, a named Qualified Individual, risk assessment, encryption, universal MFA, incident response, training, and written vendor-oversight contracts. ~$50,000+ per violation.
- IRS WISPIRS Pub. 4557 / 5708
- The IRS-facing version — a Written Information Security Plan, mandatory before tax season, universal MFA now required. Non-compliance risks PTIN suspension.
- CCPA / CPRACal. Civ. Code §1798
- California privacy law. Adds a Data Processing Agreement (DPA) requirement. GLBA data is partly carved out — the DPA must handle that overlap cleanly.
Who owns what
Compliance obligations legally rest on Lazar — they can't be transferred. But the law requires Mulholland to do its part as a vendor. Gusto runs the actual payroll; Mulholland just handles the data — but under the Safeguards Rule, accessing client data (not running payroll) is what makes a vendor a service provider with its own obligations, so Mulholland qualifies all the same.
| Obligation / document | Owner |
|---|---|
| WISP / written security program | Lazar |
| Named Qualified Individual (security lead) | Lazar |
| Universal MFA on all client-data systems | Lazar |
| Risk assessment, incident response, encryption, training | Lazar |
| Vendor-oversight contracts with Mulholland & Gusto | Lazar |
| SOC 2 / Vanta trust posture | Mulholland |
| Own internal security program (handling NPI) | Mulholland |
| Sub-processor list + data-flow diagram | Mulholland |
| Cyber liability + E&O insurance | Mulholland |
| MSA + DPA (drafting, breach terms, CCPA carve-out) | Both |
| IT-team sign-off on Mulholland as a tool | Both |
Part 1
What Ian / Lazar needs to do
Required compliance items
Get a current WISPLazar
A Written Information Security Plan is the document that states, in writing, how Lazar protects client data — who’s responsible, what safeguards exist, and how incidents are handled. Both the IRS (Pub. 4557/5708) and the FTC Safeguards Rule require one, and it must be reviewed at least annually — anything older than 12 months reads as stale.
How: Start from the IRS Pub. 5708 template (built for small tax firms), fill in Lazar’s specifics, and date it. Sections to cover: data inventory, access controls, MFA, encryption, incident response, training, and vendor oversight.
Turn on MFA everywhereLazar
Multi-factor authentication on every system that touches client data — email, tax software, file storage, payroll, remote access. The latest IRS/FTC rules make this mandatory with no exceptions, even on in-office machines.
Why: Stolen passwords are the #1 breach vector, so this is the single highest-leverage control. How: Enforce it (admin-required, not optional) and prefer an authenticator app or hardware key over SMS.
Name one Qualified IndividualLazar
The Safeguards Rule requires a single named person accountable for the security program — the Qualified Individual. One human, by name, not “the IT vendor” in the abstract.
Example: For a firm this size that’s usually a principal — likely Ian for now. Write the name into the WISP. They can lean on outside help, but the accountability stays with that person.
Complete a written risk assessmentLazar
A documented walk-through of where client data lives, how it flows, and what could go wrong (theft, ransomware, lost laptop, vendor breach, insider error), paired with the control that addresses each risk.
Example: A simple table — Asset (“client returns in [software]”) → Threat (“unauthorized access”) → Likelihood/Impact → Control (“MFA + role-based access + encryption”). Cover email, file storage, laptops, payroll, and each vendor.
Write an incident response planLazar
A written playbook for “we’ve been breached”: who’s notified, who does what, how you contain it, and the clock for legal / IRS / client notifications. Lazar has a 30-day federal reporting clock, so it has to move fast.
Example steps: 1) contain (disable accounts, isolate machines); 2) call the QI, your lawyer, and the insurer; 3) assess scope; 4) notify IRS / clients / states per the deadlines; 5) document everything.
Encrypt client data and train staff annuallyLazar
Two safeguards in one: client data encrypted at rest and in transit, plus documented security-awareness training for every staff member, refreshed yearly. Both are explicit Safeguards Rule requirements.
How: Encryption is usually on by default in Google Workspace / modern tax software — confirm and document it. For training, a short annual course (phishing, passwords, data handling) with a sign-off sheet is enough to evidence it.
Required for working with Mulholland
Sign the MSA + DPA with MulhollandBoth
The Master Services Agreement (commercial terms) and Data Processing Agreement (how Mulholland may handle client data, with security and breach-notification obligations). The Safeguards Rule requires written contracts with vendors that touch client data.
Note: This is the hard gate of the whole project — Mulholland gets no live client data until it’s executed.
Get written IT-team sign-off on MulhollandBoth
Lazar’s IT/security reviewers formally approve Mulholland as an authorized tool — the same vendor-approval path they ran for Copilot. It’s how Lazar evidences vendor due diligence.
How: Hand IT the Mulholland trust package (SOC 2 / Vanta link, sub-processor packet, data-flow diagram, insurance certificates) and get their approval in writing.
Confirm Gusto is covered by a vendor agreementLazar
Gusto processes payroll and holds the most sensitive data (SSNs, bank numbers), so it’s a data-handling vendor too — it needs the same written oversight as Mulholland. Vendor oversight applies to every vendor touching client data.
How: Confirm Lazar’s Gusto agreement includes security and breach-notification terms (use Gusto’s DPA if not), and list Gusto as a sub-processor in Mulholland’s packet.
Part 2
What Mulholland needs to do
Trust and paperwork
Finish Vanta / obtain SOC 2RecommendedMulholland
SOC 2 is the independent audit report proving Mulholland’s security controls actually work; Vanta is the platform automating the evidence toward it. It’s the first artifact Lazar’s IT will ask for — how a vendor proves it’s safe without the client auditing it directly.
Status: In motion. Share the live Trust Center now — app.vanta.com/mulholland.ai/trust — and deliver the Type II report when complete.
Get the MSA + DPA drafted and signedBoth
The same MSA + DPA, from Mulholland’s side — drafting and executing it. Must include a data-protection covenant, a fast breach-notification clause (so Lazar can hit its 30-day federal clock), and CCPA/CPRA language.
Key: align the breach-notice timeline so Lazar’s reporting clock is protected.
Resolve the CCPA ↔ GLBA overlap in the DPABoth
GLBA-regulated financial data is partly carved out of CCPA/CPRA, so the DPA has to handle both regimes cleanly without contradicting itself. Get it wrong and the contract is either over-broad or leaves a gap.
How: Get the carve-out language drafted specifically — don’t freelance it.
Insurance
Bind $1M cyber liability + $1M E&ORecommendedMulholland
Two policies — cyber liability (covers breach costs) and errors & omissions (covers professional mistakes), $1M each. A standard vendor-diligence requirement.
Status: Being shopped with HUB International; coverage effective in ~2 weeks. Share certificates of insurance (COIs) with Lazar’s IT once bound.
What the IT team will ask for
Build a sub-processor packetMulholland
A sub-processor is any outside company Mulholland uses to store or handle Lazar’s data — Google Cloud (Cloud Run, Vertex, Cloud SQL), Anthropic (the model), Cloudflare (network), and Gusto (payroll). The packet is the inventory of all of them, listing for each: what data it touches, where it’s physically stored, and its compliance certs.
Why: Lazar stays responsible for every link in the chain under GLBA, so its IT needs to see the whole chain is covered — this is usually the document that unblocks approval. Example columns: Sub-processor · Purpose · Data touched · Region · Certifications (SOC 2 / ISO 27001). Pairs with the data-flow diagram.
Create a one-page data-flow diagramMulholland
A single picture of how a client’s data moves through the system — from source, through Mulholland’s services, to storage, and to any sub-processor. IT reviewers think in data flows; one clear diagram answers half their questions.
Example: Client data → agent (Cloud Run) → model (Vertex / Anthropic) → database (Cloud SQL) → Gusto (payroll). Mark where data is stored vs. transient, and where it crosses a boundary.
Prepare the managed-GCP defenseRecommendedMulholland
A ready answer for why running on managed Google Cloud is safe and appropriate — because the same IT team rejected Claude Cowork, so they’re skeptical and will push on infrastructure. Better to walk in with the rationale than get caught flat-footed.
Points to make: per-tenant isolation, GCP’s compliance certifications, data residency, no training on client data, encryption, and how managed GCP differs from the thing they rejected.
Mulholland's own exposure
Confirm with Marijn what data crosses the boundaryMulholland
A precise answer to: exactly which data fields cross into Mulholland’s systems, and whether they’re stored or just passed through. Does the agent ever retrieve or display SSNs or bank numbers — even a last-4?
Why it matters: this single fact sets how heavy the DPA terms and security controls must be. “We don’t store socials” is very different from “we display last-4 transiently.” Enumerate the fields with Marijn and write it down — it feeds the DPA and the data-flow diagram.
Architect for the endpoint, not today's scopeRecommendedMulholland
Design as if Mulholland will eventually touch the most sensitive data, even if today’s scope is narrow. Don’t bake “we don’t have socials for now” into the architecture as a permanent assumption.
Why: scope creep is normal; if the design quietly assumes low-sensitivity data, it breaks — and opens a compliance gap — the moment scope expands. Build encryption, access controls, and audit logging to handle SSN/bank data from day one.
Decide on the Qualified Individual roleRecommendedMulholland
Decide whether Mulholland will ever fill or support Lazar’s named security-lead (Qualified Individual) role. Recommendation: don’t volunteer for it yet.
Why: taking on the QI role pulls real liability onto Mulholland and must be written into the contract if it happens. Keep the accountability with Lazar (Ian) at launch; revisit only deliberately, with counsel.
Part 3
The order to do it in
Lazar
- WISP
- MFA everywhere
- Sign MSA / DPA
Mulholland
- Vanta + bind insurance
- MSA / DPA signed
- Sub-processor packet + data-flow diagram
- Onboard
Where this is headed
Payroll is the first workflow, not the whole relationship. The same law stack governs every piece of client financial data, so the compliance posture scales with scope. Two things stay constant: the system of record (Gusto today) is the processor that stores the sensitive data; Mulholland is the automation layer on top. The more data Mulholland touches, the heavier its paperwork.
Payroll automationToday
Mulholland automates the payroll workflow; Gusto processes and stores the socials and bank numbers. Mulholland orchestrates without storing that data for now. Covered by the MSA + DPA once signed.
Bookkeeping automationNext
Ian wants this next. It touches financial records, transactions, bank feeds, and categorization — sensitive, but not a new legal regime: the same GLBA / FTC Safeguards obligations already apply.
To stay compliant: the existing vendor agreement covers it; expand the sub-processor packet and data-flow diagram to include the new sources, and re-confirm with Marijn whether any new sensitive fields (e.g. full account numbers) cross Mulholland’s boundary. If they do, the DPA terms get heavier. No new law — just broader data.
Tax-prep automationLater
The biggest jump — and the reason “tax isn’t quite there yet” isn’t only about capability. Tax-return information triggers IRC §7216, the federal rule on how a preparer may use or disclose return info.
To stay compliant: Lazar must bring Mulholland in as an authorized auxiliary service provider under §7216 — US-based, used only to prepare the return, no secondary use such as model training — or obtain written taxpayer consent. Offshoring restrictions apply, and the data (full returns, SSNs) is the most sensitive in the relationship. The §7216 path has to be in place before any live tax data flows.
“Do we have to run it locally?”Open
Short answer: no, not strictly. GLBA, the FTC Safeguards Rule, and the IRS WISP require safeguards — encryption, access control, vendor contracts, US data residency, breach response — not a specific location. Properly safeguarded cloud is compliant.
The real concern behind “run it locally” is usually don’t expose sensitive data to third parties — especially AI model providers — without the right terms. That’s handled contractually and architecturally: per-tenant isolation, no-training / no-secondary-use clauses in the sub-processor DPAs (Anthropic, Google), and keeping data in-region. §7216 separately limits who tax data can go to, which is another reason to lock those terms down. So local compute is a legitimate trust choice, not a legal mandate.
Verify before acting
Open items that need a confirmed answer from counsel or the team before they can be relied on.
Confirm the tax-season WISP deadline + current FTC penaltiesBoth
Get the precise, current figures — the tax-season WISP deadline and the FTC Safeguards penalty amounts (~$50k+/violation is the working number, but confirm). Don’t quote stale figures to Lazar or in planning.
Lock the precise CCPA-GLBA carve-out languageBoth
The actual contract language for the CCPA ↔ GLBA overlap. The DPA can’t be finalized without it.
Marijn confirms the exact data fields crossing the boundaryMulholland
The definitive field-level answer (ties to “Confirm with Marijn what data crosses the boundary”). Everything downstream — DPA weight, security design — depends on it.
Confirm HUB binds the policies (~2 weeks) + get COIsMulholland
Verify the cyber + E&O policies actually bind on schedule and get the certificates in hand. IT approval depends on real, in-force coverage — not “being shopped.”
Confidence: high on the steps and the law stack; moderate on the exact contract wording; unknown on whether IT clears managed GCP until you see their WISP.