What Federal Tax Information is and where it reaches state systems
Federal Tax Information is defined under IRC Section 6103: it includes tax returns, return information, and any data derived from those returns. The IRS shares FTI with state agencies under specific statutory authorities within IRC 6103(l) covering programs including Medicaid eligibility verification, unemployment insurance, SNAP, TANF, and child support enforcement. Disclosure to these agencies is made upon written request under IRC 6103(l)(6) (child support) and 6103(l)(7) (benefit programs), so receipt depends on the agency's data-exchange arrangement with the IRS.
The practical reach is wider than many state IT leaders initially assume. An eligibility worker running an income verification query against IRS wage data is handling FTI. A system that stores employment or income data originally sourced from IRS transcripts continues to handle FTI even after the data has been reformatted or processed downstream. Any intermediary system through which that data flows—even a messaging queue or API gateway—is within the FTI boundary.
IRS Publication 1075, "Tax Information Security Guidelines for Federal, State and Local Agencies," is the authoritative security standard for this data. It applies to every agency that receives, processes, stores, or transmits FTI—state agencies, county agencies acting as state agents, and contractors operating systems on their behalf. These requirements are not optional program guidance: they are conditions of receiving IRS data under the IRC 6103 authorities.
The core compliance obligations
Publication 1075 aligns its security requirements to the NIST Special Publication 800-53 control catalog, with IRS-specific requirements layered on top at each control family. The key obligations for state agencies:
Annual Safeguard Security Reports. Agencies receiving FTI must submit an annual Safeguard Security Report (SSR) to the IRS Office of Safeguards describing the processes, procedures, and security and privacy controls in place to protect FTI, as Publication 1075 Section 2.E.4 requires. The SSR is how the agency's current posture and planned improvements reach the IRS, so it needs to reflect the environment actually in use.
Safeguard Reviews. The IRS Office of Safeguards conducts periodic safeguard reviews, which Publication 1075 Section 1.6 describes as on-site, remote, or hybrid evaluations. Reviewers assess whether technical, physical, and administrative controls meet Publication 1075 requirements, using the Safeguard Computer Security Evaluation Matrices (SCSEMs) for technical testing. A review that finds deficient controls generates a corrective action requirement, and under Section 1.7.2 the IRS may suspend or terminate disclosure if an agency does not satisfactorily maintain its safeguards and has no adequate plan to improve.
Incident reporting. Agencies must report a possible improper inspection or disclosure of FTI, including breaches and security incidents, to the Treasury Inspector General for Tax Administration (TIGTA) immediately, and no later than 24 hours after identification, per Publication 1075 Section 1.8.2, and concurrently notify the IRS Office of Safeguards (safeguardreports@irs.gov) per Section 1.8.3. State incident response procedures need to be calibrated to that window rather than to an equivalent from another framework.
Access control and need-to-know. FTI access must be limited to individuals whose official function requires it. Background investigation requirements apply to employees and contractors with FTI access, and annual recertification of access rights is required. These controls are commonly documented in policy but frequently drift in execution—particularly for contractor and vendor accounts established during system implementations and never removed.
Contractor and third-party obligations. When a state agency engages a contractor to operate a system handling FTI, that contractor is subject to the same Publication 1075 requirements. The state agency bears responsibility for ensuring contractor compliance, including requiring specific contractual provisions that acknowledge the obligations and preserve IRS inspection rights. One restriction matters most for benefits agencies. Per Publication 1075, agencies that receive FTI under IRC 6103(l)(7) (human services agencies, including Medicaid, SNAP, TANF and unemployment compensation programs) may not disclose FTI to contractors for any purpose, and Publication 1075 lists cloud computing providers among those contractors. For these agencies, a cloud migration is permissible only if the provider has no logical access to FTI. Publication 1075 Section 3.3.1 treats FIPS 140-certified encryption in transit and at rest, with the agency holding sole ownership of the encryption keys, as the logical barrier that allows (l)(7) data into a cloud environment.
Why cloud migration expands the compliance surface
Moving a system that handles FTI to a cloud platform does not change the data's legal status—it remains FTI, with all Publication 1075 obligations intact. But cloud migration introduces compliance dimensions that on-premises environments did not create.
Cloud service provider agreement scope. Where FTI may be shared with a contractor, the contract needs the Exhibit 7 safeguarding language. Publication 1075 Exhibit 7 covers performance requirements (including IRS prior written approval before any subcontracting of FTI work), written notice to contractor staff of the criminal and civil sanctions for unauthorized disclosure, and IRS and agency inspection rights on 24 hours' notice. Standard cloud master services agreements do not include these terms, so procurement teams need them negotiated before any FTI-bearing workload moves, not added once the migration is underway. For every agency, Sections 3.3.1(d), (e) and (g) require that the cloud contract or SLA establish Publication 1075-based controls, including FIPS 140 encryption, regardless of the provider's own security posture. For (l)(7) agencies, contract language does not authorize provider access to FTI; the architecture must keep the provider from any logical access.
Data residency and onshore access. Publication 1075 Section 3.3.1 requires that all FTI physically reside in systems located within the United States and that all access to and support of those systems be performed from the United States, its possessions and territories. Section 2.C.7 adds that FTI may not be received, processed, stored, accessed, or transmitted to systems located offshore, nor sent offshore for disposal. Standard commercial cloud tiers often replicate data across regions by default, so agencies need to verify the residency configuration of the service tier, including backup destinations and provider support access. The data center addresses must be listed in the 45-day notification. This is a procurement and architecture decision made before migration, not discovered at the first safeguard review.
Shared responsibility documentation. Cloud platforms operate on a shared responsibility model: the provider secures the infrastructure layer; the customer owns data, identity, and application configuration. For FTI environments, that division must be documented in a way that maps to Publication 1075's NIST 800-53 controls. Publication 1075 permits FTI only in cloud environments that have a FedRAMP authorization from the Joint Advisory Board or a federal agency (Section 3.3.1(a)), and the IRS cloud computing guidance requires a cloud service offering FedRAMP authorized at the moderate impact level. Under Section 3.3.1, Safeguards leverages the provider's FedRAMP authorization for controls inside that boundary and assesses agency-managed components outside it with its own SCSEMs, so the agency's configuration remains in scope. Publication 1075 does not reference a SOC 2 report as a substitute for FedRAMP authorization. The reviewer will look at the agency's configuration, not only the provider's certification.
Audit logging continuity. Publication 1075 requires audit logging of FTI access. Cloud platforms generate extensive native logs, but those logs are not automatically configured to capture what a safeguard review requires. The configuration needed to record FTI access at the required granularity, and to retain those logs for seven years as Publication 1075 (AU-11) requires, must be established before the migration—not retrofitted after the first audit inquiry.
The failure modes that actually cause program disruption
Most compliance failures under Publication 1075 are not the result of dramatic security incidents. They are documentation and procedural gaps that accumulate until a safeguard review exposes them.
The pattern looks like this: an agency migrates a benefits eligibility system to a cloud platform. The technical controls are largely correct. But the cloud provider agreement lacks the required FTI language. Audit logs are configured for a different compliance framework, not for FTI-specific access events. Contractor accounts that were current in the on-premises environment were migrated as-is, some with broader access than needed for their current role. The most recent SSR reflects the previous infrastructure rather than the cloud configuration. None of these individually disables the system. Together, they produce a safeguard review finding that requires documented corrective action.
The disruption to program operations is indirect but serious: if an agency does not satisfactorily maintain its safeguards and has no adequate plan to improve, the IRS may suspend disclosure (Publication 1075 Section 1.7.2). In practice, Spartan X's assessment is that the consequence is operational. An unemployment insurance agency that cannot verify claimant income through IRS transcripts must extend manual processing time and rely more heavily on self-reported income—increasing both processing burden and improper payment exposure. Medicaid eligibility workers face similar constraints if FTI-sourced income verification data becomes unavailable.
An alternative approach and its conditions
Some agencies address the cloud migration compliance problem by designing a FTI-free architecture: they keep the components that receive and initially process IRS data in a dedicated on-premises or dedicated-cloud enclave, and pass only derived outputs—an eligibility determination, not the underlying transcript—into the broader cloud environment.
This approach is architecturally viable and can meaningfully contain the Publication 1075 surface area. It works well when data flows are clean, the derived outputs genuinely do not retain FTI characteristics under the Publication 1075 definition, and the agency has the capacity to operate and maintain the enclave as a distinct environment.
The conditions under which it makes sense: the agency's legal counsel and IRS Safeguards coordinator have reviewed the proposed data boundary and confirmed that the derived outputs fall outside the FTI definition (a high bar, because Publication 1075 defines FTI to include any information the agency creates that is derived from return information and prohibits masking data to change its character); the enclave can be enforced at the application layer, not just by policy; and the agency has considered long-term operational costs of maintaining two infrastructure environments rather than one.
It is not a compliance shortcut. A poorly defined boundary that permits FTI to flow beyond the enclave extends Publication 1075 obligations to the entire path, whether or not that was the intent.
Before migration: what state CIOs need to confirm
A Publication 1075 pre-migration assessment should address, at minimum:
- Map the FTI boundary. Identify every system being migrated that receives, processes, stores, or transmits FTI or data derived from FTI. Review data flow diagrams with the agency's IRS Safeguards coordinator; do not rely on the original system design documents, which may not reflect current data flows.
- Verify the cloud agreement and the (l)(7) architecture. Confirm that the agreement or a binding addendum includes the Publication 1075 Exhibit 7 provisions and the Section 3.3.1(g) controls. For (l)(7) programs, confirm the architecture keeps the provider from any logical access to FTI (FIPS 140 encryption at rest and in transit, agency-held keys). Contract language alone does not authorize provider access. This is a legal review requirement, not an IT security check.
- Confirm onshore storage and access. Verify that storage, replication, backup, and provider support and administrative access are all onshore, and obtain the data center addresses, which must be listed in the 45-day notification. Get this in writing from the provider.
- Confirm FedRAMP authorization and document shared responsibility. Confirm the specific service offering holds a FedRAMP Moderate (or higher) authorization. Map each Publication 1075-required NIST 800-53 control to either the provider's managed responsibility or the agency's configuration responsibility. Identify gaps.
- Configure FTI-specific audit logging before migration. Test that logging captures FTI access events at the required granularity and is retained for seven years. Do not migrate production FTI data until logging is validated.
- File the 45-day cloud notification. Notify the IRS Office of Safeguards (SafeguardReports@irs.gov) at least 45 days before transmitting FTI into the cloud, per Section 3.3.1(f) and Section 2.E.6. Document data center locations, the provider's FedRAMP authorization, how encryption will prevent disclosure to provider employees, and all agency-managed security and privacy controls. If the provider will have logical access to FTI, a contractor-disclosure notification is also required, and for (l)(7) agencies that access is not permitted.
- Update the SSR. Ensure the next annual SSR reflects the cloud configuration, not the prior on-premises posture.
- Review all accounts with FTI access. Audit contractor, vendor, and agency user accounts against current need-to-know and background investigation status before migration. Remove or restrict accounts that no longer qualify.
Publication 1075 obligations follow FTI wherever it goes. A cloud migration that resolves those obligations for the new environment is a migration that can proceed. One that defers them to a future compliance cycle creates a standing deficiency that a safeguard review will find.
Sources and further reading
- IRS Publication 1075 (Rev. 11-2021), Tax Information Security Guidelines for Federal, State and Local Agencies (IRS)
- IRS Cloud Computing Environment guidance (IRS)
- IRS Office of Safeguards (IRS)
- IRC Section 6103, Confidentiality and Disclosure of Returns and Return Information (Cornell LII)
- NIST Special Publication 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (NIST)
Spartan X designs cloud architectures, security requirements and pre-migration plans for public-sector systems where federal data-protection obligations and state modernization goals have to be met together, and that intersection shapes how we approach agencies handling sensitive program data.
