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, CHIP, TANF, and child support enforcement.
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 Activity Reports. Agencies receiving FTI must submit an annual Safeguard Activity Report (SAR) to the IRS Office of Safeguards. The SAR documents the agency's current security posture, any incidents in the past year, control implementation status, and planned improvements. Missing or materially incomplete SARs trigger IRS follow-up and can affect the agency's standing for continued FTI access.
Computer Security Evaluations. For agencies receiving ongoing FTI, the IRS Office of Safeguards conducts periodic Computer Security Evaluations (CSEs)—on-site reviews where IRS personnel assess whether technical, physical, and administrative controls meet Publication 1075 requirements. A CSE finding of deficient controls generates a corrective action requirement; if the agency cannot demonstrate timely remediation, FTI access can be restricted pending resolution.
Incident reporting. Agencies must notify the IRS within a defined window of discovering any security incident—loss, theft, unauthorized access, or unauthorized disclosure—that affects FTI. State incident response procedures need to be calibrated to this requirement; the timeframe is specified in the current version of Publication 1075 and agencies should verify the current requirement directly rather than assuming an equivalent from other frameworks.
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. This applies directly to cloud service providers.
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. Publication 1075 requires that agreements with third parties handling FTI include specific provisions: acknowledgment that Publication 1075 applies, agreement to IRS inspection rights, and acceptance of liability for unauthorized disclosures. Standard cloud master services agreements do not include these terms. State procurement teams need FTI-specific contractual language negotiated before migrating any FTI-bearing workload to a cloud platform—not added as an afterthought once the migration is underway. Without that language in place, the state is in violation of Publication 1075 regardless of the cloud provider's own security posture.
Data residency and IRS oversight. Publication 1075 requires that FTI be stored and processed in environments where the IRS can exercise its oversight rights. Standard commercial cloud tiers often replicate data across multiple geographic regions by default, including regions outside the United States. State agencies need to verify the specific data residency configuration of their chosen service tier and ensure replication and backup destinations are consistent with IRS requirements. This is a procurement and architecture decision that must be made before migration, not discovered at the first CSE.
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 explicitly in a way that maps to Publication 1075's NIST 800-53 controls. A cloud provider's SOC 2 Type II report establishes that the provider's internal controls met audit criteria; it does not demonstrate that the state agency's specific configuration satisfies Publication 1075 requirements. The CSE examiner will look at the agency's configuration, not 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 CSE review requires. The configuration needed to record FTI access at the required granularity, and to retain those logs for the required period, 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 CSE 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 SAR reflects the previous infrastructure rather than the cloud configuration. None of these individually disables the system. Together, they produce a CSE finding that requires documented corrective action.
The disruption to program operations is indirect but serious: if corrective action cannot be demonstrated within the required timeframe, FTI access can be suspended. 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; 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 language. Confirm that the cloud service provider agreement—or a binding addendum—includes the specific Publication 1075 contractor provisions. This is a legal review requirement, not an IT security check.
- Confirm data residency configuration. Verify that the service tier in use restricts data storage and replication to locations consistent with IRS oversight jurisdiction. Get this in writing from the provider.
- Document the shared responsibility allocation. 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. Do not migrate production FTI data until logging is validated.
- Update the SAR. Submit a SAR that reflects the cloud configuration, not the prior on-premises posture. Notify the IRS Office of Safeguards of significant infrastructure changes consistent with the current Publication 1075 notification requirements.
- 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 CSE will find.
Sources and further reading
- IRS Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies (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 has worked on systems where federal data-sharing authorities and detailed security safeguarding requirements operate together—including platforms built for state programs that receive federal program data under statutory access agreements. That experience with the technical and compliance intersection of federal data governance and state modernization informs how we approach cloud architecture design, security requirements, and pre-migration planning for agencies handling sensitive program data.
