IRS Pub 1075: A Simple Guide for MSPs and CPAs

[IRS Pub 1075 Guide for MSPs and CPAs]

Learn what IRS Pub 1075 means for MSPs, CPAs, and vCISOs. See the key compliance rules, where penetration testing fits, and how white label pentesting helps you deliver affordable, fast compliance services.

If you're an MSP, you already know how this plays out. A CPA firm or tax-focused client asks whether you can support IRS Pub 1075 requirements, and suddenly the conversation shifts from help desk and backups to encryption, audit evidence, and vendor controls.

If you can't answer clearly, the client starts looking elsewhere.

That's why I don't view IRS Pub 1075 as a paperwork problem. I see it as a revenue and retention opportunity for MSPs, vCISOs, GRC firms, resellers, and compliance advisors who want to become harder to replace. The firms handling tax data need practical guidance, real testing, and clean documentation. Most of them don't need another bloated security engagement. They need a partner who can help them move fast, stay affordable, and pass scrutiny.

What Is IRS Pub 1075 and Why MSPs Should Care

A CPA client calls after receiving a security questionnaire from a bank, state agency, or enterprise customer. They ask whether your team can support IRS Publication 1075 controls, document the gaps, and prove the environment has been tested. If your answer is vague, you lose authority fast, and a compliance specialist gets invited into the account.

That is why MSPs should care.

IRS Publication 1075 sets the security and privacy expectations for organizations that receive, process, store, or transmit Federal Tax Information (FTI). For an MSP owner, the practical point is simple. If your client touches FTI, your services are part of the control environment whether you sell yourself as a compliance firm or not.

Clients do not separate patching, identity, endpoint protection, backups, vendor access, and audit evidence into neat categories. They see one provider responsible for keeping sensitive tax data safe and defensible. If you cannot explain how your stack supports Publication 1075, you create doubt. Doubt kills renewals, projects, and referrals.

Why this creates a real business opening

Publication 1075 pushes security work beyond basic IT operations. Clients need someone to identify gaps, validate controls, document findings, and help fix what matters first. That work is valuable, recurring, and easier to sell than generic “security consulting” because the trigger is concrete. A questionnaire arrived. An assessor asked for proof. A contract now requires stronger controls.

The gap for most MSPs is not intent. It is execution.

You probably already manage Microsoft 365, endpoint tools, firewalls, backups, and user access. What you may not have in house is offensive security talent that can test the environment credibly and produce evidence a CPA firm or tax-focused client can use. That is where margin disappears if you try to build everything yourself.

The better move is to add testing through a trusted partner and keep the client relationship. White-label services let you sell assessment, validation, and remediation planning without hiring a full penetration testing team. For firms serving accountants, this guide to outsourced pentesting for CPAs shows the model clearly.

My recommendation: Treat Publication 1075 as a packaged advisory offer, not a one-off support headache. Lead with a gap review, add white-label penetration testing, then sell remediation and ongoing control validation.

Some clients also face overlapping state privacy duties at the same time they are sorting out tax-data obligations. If you advise startups or growing firms with multi-state exposure, this overview of Florida startup data privacy laws is a useful reminder that compliance problems rarely arrive one at a time.

The MSPs that win here do three things well. They explain the requirements in plain English, bring in specialized testing without inflating cost, and give clients documentation they can use. That combination makes you harder to replace.

Breaking Down The Key IRS Pub 1075 Requirements

A CPA client asks a simple question: “Can you help us meet Pub 1075?” If your team cannot explain the controls in plain English and back them up with testing and evidence, you lose authority fast. Worse, you leave room for another provider to take the advisory work, the remediation work, and the long-term security relationship.

Pub 1075 centers on one thing: protecting Federal Tax Information, or FTI. The IRS defines that category broadly. It includes returns, return information, and data elements pulled into other systems, reports, and workflows. MSPs get into trouble when they treat FTI like a few tax PDFs sitting in a shared folder. That is too narrow and usually wrong.

The three control buckets

The fastest way to explain Pub 1075 to a client is to group the requirements into three buckets.

• Administrative controls cover the management side. Access approvals, background screening, training, incident procedures, vendor oversight, and documented policies.
• Physical controls cover offices, devices, and paper records. Locked areas, controlled entry, secure workstation use, media handling, and disposal.
• Technical controls cover the systems themselves. Encryption, authentication, logging, system hardening, segmentation, patching, and configuration management.

These buckets work together. A client can have decent endpoint tools and still fail in practice because access reviews never happen, shared credentials are common, or FTI sits in places nobody documented.

What the IRS expects in practice

Pub 1075 maps closely to NIST security control families. If your team already understands how NIST SP 800-53 control families work, the structure will feel familiar. The difference is the operational pressure. Tax-focused clients need those controls applied specifically to FTI, documented clearly, and enforced consistently.

For MSPs, the day-to-day requirements usually come down to six jobs:

• Find FTI everywhere it lives across servers, endpoints, cloud apps, file shares, backups, and exported reports.
• Restrict access tightly so only approved users can reach that data, and only for a valid business reason.
• Use approved encryption and secure transmission methods where policy requires them.
• Collect and review logs so failed access attempts, suspicious behavior, and policy violations do not go unnoticed.
• Harden systems and configurations instead of leaving risky defaults in place.
• Produce evidence in the form of policies, approvals, inventories, diagrams, test results, and remediation records.

That last point matters more than many MSP owners expect. Clients do not just need controls. They need proof that the controls exist, that someone validated them, and that gaps are being tracked to closure.

Consequently, Pub 1075 conversations often overlap with SOC 2, HIPAA, PCI DSS, and ISO 27001 work. The frameworks are different, but the sales opportunity is the same. Clients want one trusted advisor who can translate requirements, bring in specialized testing, and hand them documentation they can use with confidence.

That is where many MSPs and CPA firms hit the same wall. They can manage infrastructure and draft policies, but they cannot always validate whether controls around FTI would hold up under real attack conditions. A white-label penetration testing partner closes that gap without forcing you to hire a full offensive security team. That lets you sell the assessment, keep the client relationship, and add margin on remediation and retesting instead of passing the work to someone else.

Mapping Penetration Testing To IRS Pub 1075 Controls

A lot of teams make the same mistake. They assume a vulnerability scan equals a pentest. It doesn't.

A scanner finds known technical issues. A real penetration test puts a human in the attacker's seat and asks a harder question. Can someone use these weaknesses to reach sensitive systems or data? That distinction matters when you're trying to validate access controls, segmentation, exposed services, weak workflows, or bad assumptions around FTI.

Where a manual pentest helps most

Pub 1075 requires contractors to report breaches within 24 hours and establish a Plan of Action & Milestones (POA&M) to fix vulnerabilities. It also requires encrypting FTI sent over the internet with FIPS 140 validated cryptography, according to Microsoft's IRS 1075 compliance overview.

That's exactly where manual pentesting earns its keep.

A certified tester with OSCP, CEH, or CREST credentials won't just dump a list of scanner output into a PDF. They'll test whether an exposed path, weak control, or poor configuration can be chained into something meaningful. That matters for external portals, internal networks, cloud workloads, web apps, and remote access paths.

Manual testing vs automated scanning

Use this rule with clients.

That difference is why penetration testing supports more than one framework. A good pen test helps support audit readiness for SOC 2, HIPAA, PCI DSS, and ISO 27001, while also giving the client evidence that controls are working in a realistic way.

If your team already works with NIST-based control mapping, this reference on NIST 800-53 helps connect the control language to actual validation steps.

A cheap automated scan can create paperwork. A real penetration testing engagement can create evidence.

A Pub 1075 Compliance Checklist For MSPs

Most compliance failures don't happen because the client ignored security. They happen because nobody checked the provider chain carefully enough.

That's a serious problem in the MSP channel. 68% of MSPs lack formal processes to vet vendor compliance with Pub 1075 background check and encryption rules, and the IRS Office of Safeguards increased non-compliance findings by 42% in 2025, often tied to vendor failures, according to Lazarus Alliance.

Ask these questions before you promise anything

Use this checklist on your own practice and on any third-party provider you bring into the deal.

• Do we know where FTI resides? Inventory the systems, devices, apps, shares, and workflows that store or process tax-related data.
• Can we prove access is controlled? Review user access, external access paths, and whether access decisions are documented.
• Is encryption handled correctly? Don't assume the cloud provider solved this for you.
• Do we perform a real risk assessment? Not a generic template. An actual review tied to systems in scope.
• Are logs collected and reviewed? Logging without review doesn't help much in an audit or incident.
• Do we have annual manual pentesting in scope? A real penetration test should validate controls, not just generate findings.
• Can our provider deliver fast, clean reporting? If reporting drags, remediation drags with it.
• Will our partner stay behind the scenes? A channel-only model matters if you don't want to be disintermediated.

What a strong testing partner should look like

Not every firm selling penetration testing is built for the MSP channel.

Look for a partner that offers:

• Manual pentesting rather than just tool output
• Certified testers with credentials such as OSCP, CEH, and CREST
• White label pentesting for reseller and vCISO delivery
• Affordable pricing that works for recurring compliance work
• Fast turnaround so the project doesn't stall for weeks

If your current provider is expensive, slow, and vague about methodology, that provider is hurting your margins and your client experience.

Simple Remediation Steps And Sample Policy Language

Most clients don't panic when a penetration test finds an issue. They panic when the report is confusing, expensive to fix, or disconnected from the compliance rule that triggered the test in the first place.

A common Pub 1075 problem is bad handling of shared workstations. Recent Safeguards Review data shows 55% of corrective action plans failed because vendors misunderstood the dual-function workstation rule, which requires FTI to be encrypted even on secure systems if the workstation performs other tasks, according to the IRS guidance on encryption requirements in Publication 1075.

A simple before and after example

Before: A staff workstation is used for general office work and also accesses or stores FTI during tax workflows. The team assumes the machine is “secure enough” because it sits in a controlled office.

After: The workstation is classified correctly as dual-function, FTI on the device is encrypted as required by the rule, access is restricted, and the client documents the control in policy and procedure.

That's the kind of fix MSPs should aim for. Clear scope, clear control, clear evidence.

Sample policy language you can adapt

Use simple language your client can maintain.

Sample encryption policy
All systems that access, process, store, or transmit Federal Tax Information must use organization-approved encryption controls where required by IRS Publication 1075. Workstations that perform both general business functions and FTI-related functions will be treated as dual-function systems and protected accordingly. Access to FTI will be limited to authorized personnel, and system configurations will be reviewed regularly to confirm continued compliance.

Remediation that doesn't stall the project

When a finding lands, move in this order:

1. Confirm scope so you know which users, devices, and workflows are affected.
2. Fix the exposure by changing configuration, access, or encryption handling.
3. Document the change in policy, ticketing, and remediation notes.
4. Retest the issue so the client has evidence the weakness is closed.

For clients juggling tax records and retention rules, this guide to document retention for tax compliance can help support the broader governance side of the conversation.

A good report doesn't just tell the client what's wrong. It gives them a clean path to close the issue without turning every finding into a consulting marathon.

Partner With Us For Affordable White Label Pentesting

A CPA client calls after landing a contract that involves Federal Tax Information. They need proof their environment has been tested, their controls hold up, and their findings will be fixed fast. Your team can manage systems and policy. What you probably do not want is to hire full-time offensive security staff just to cover a narrow but high-stakes compliance gap.

That gap is where margin lives.

MSPs that serve tax, accounting, and finance clients should add white-label penetration testing instead of passing the work out or treating it like a one-off referral. Pub 1075 compliance creates recurring demand for testing, evidence, and retesting. If you own the client relationship and bring in a channel-only testing partner, you keep the account, expand your compliance offering, and avoid the cost of building an internal pentest bench.

The model is simple. You stay in front of the client. Your partner performs the manual testing, documents findings clearly, and supports remediation validation under your brand. The client gets one accountable provider. You get a service line that fits your existing security and compliance work.

If you want to add delivery capacity without adding headcount, review our white labeled pentesting services for MSPs and compliance providers. It gives you a practical way to sell manual pentesting to Pub 1075 clients without slowing your team down or crushing margin.

Choose a partner that stays channel-only, writes reports your client can act on, and understands how compliance buyers think. Certifications matter. Clear scoping matters more. Fast retesting matters most when a CPA firm or tax-focused client is trying to close findings before an audit, renew a contract, or prove due diligence to a regulator.

Need a fast, affordable way to deliver manual pentests under your brand? MSP Pentesting helps MSPs, vCISOs, GRC firms, and resellers offer white label pentesting with certified testers, quick turnaround, and no channel conflict. Contact us today to learn more.