IRS 1075 compliance: what safeguard reviews actually test for
Julian ThorneApril 29, 2026
Key takeaways
IRS safeguard reviews test live technical controls — audit log samples, access event records, encryption configurations — not just documentation. Organizations that prepare SSPs without validating live systems routinely fail on controls they believed were implemented.
FTI designation follows derived data. A cloud data warehouse that ingests IRS-sourced records alongside other data sources does not lose FTI scope for the records containing tax information. Shadow IT instances that process derived data are in scope.
Background checks under IRS Publication 1075 must meet IRS-specific suitability criteria and be repeated at minimum every five years. Standard HR onboarding checks do not satisfy this requirement.
Audit logging failures are the most common technical finding in IRS 1075 assessments. Platforms like Microsoft Purview can log session events by default but require deliberate configuration to log actions performed on FTI — the level of granularity IRS reviewers actually request.
Third-party vendor obligations run continuously. An organization that completed vendor due diligence at contract signing and has not re-validated since is carrying unassessed FTI exposure through every infrastructure change the vendor has made since then.
Unauthorized FTI disclosure carries criminal liability under 26 U.S. Code Section 7213 and civil liability under Section 7431 — up to $1,000 per unauthorized disclosure plus punitive damages for willful violations.
TL;DR
IRS Publication 1075 compliance fails in predictable places: audit logs configured at the session level instead of the action level, FTI scope undercounted because derived data is excluded, vendor agreements signed once and never re-validated, and background checks that satisfy HR policy but not IRS suitability criteria. The organizations that pass safeguard reviews are the ones that have validated their live controls against what IRS reviewers actually request — not the ones with the most complete documentation.
What the IRS reviewer asks for first
A state benefits agency had been handling Federal Tax Information for eleven years. They had a System Security Plan, a current third-party agreement with their cloud provider, and a SIEM that had been running for three years without a major incident. The IRS safeguard review request came in with a standard evidence list. Item three on that list: audit log samples showing access events for FTI datasets over the prior 90 days, at the action level. The agency pulled the logs. They showed session initiation and session termination. Nothing in between.
The SIEM was logging. The platform was generating events. The configuration that translated those events into action-level records — who accessed which FTI record, what query was run, what data was returned — had never been enabled. Three years of compliance posture, one missing configuration toggle. The IRS reviewer noted it as a deficiency. The agency had 30 days to remediate before the follow-up review. The senior security officer's first comment in the debrief: 'We assumed the platform handled this automatically.'
How IRS safeguard reviews actually work
IRS Publication 1075 is enforced through the Safeguard Review program, administered by the IRS Office of Safeguards. Reviews combine document examination, personnel interviews, and technical testing. The frequency depends on agency risk tier — annual for high-risk agencies, less frequent for lower-risk — but the methodology is consistent. Reviewers request specific evidence categories: background check records with dates, training completion logs, third-party agreement text, network diagrams showing FTI data flows, encryption configuration documentation, and audit log samples. The audit log samples are where live technical validation diverges most sharply from documented posture.
Example
Publication 1075 Section 4 specifies audit logging requirements that go beyond what most organizations configure by default. The requirement is not that access attempts are logged — it is that successful access events are logged at a granularity sufficient to identify what data was accessed, by whom, and when. In Microsoft Purview, the default configuration logs user sign-in events. Logging data access actions — queries run against FTI datasets, files opened, exports initiated — requires deliberate configuration of audit policies that are not enabled out of the box. Organizations that check 'audit logging enabled' on their compliance checklist without verifying what is actually being logged will find this gap during the safeguard review rather than before it.
The same gap exists in AWS CloudTrail, Splunk default configurations, and most SIEM deployments. The platform has the capability. The specific data access event logging requires configuration. The configuration is the control.
What the assessments show
Assessment base: Vulnox assessment data, 2024-2025, state agency and government contractor engagements involving FTI handling
FTI scope undercounted due to derived data misclassification
In assessments of state agencies and government contractors handling FTI, Vulnox consistently finds data systems that are excluded from the IRS 1075 scope inventory because they do not directly receive IRS data. The most common pattern: a data analytics environment that ingests production database exports, some of which contain FTI fields. The analytics team treats the environment as internal data science infrastructure. The security team does not include it in the FTI inventory because it is not a 'tax system.' IRS Publication 1075 is explicit — FTI retains its designation regardless of where it moves after initial receipt. The analytics environment is in scope.
Every system excluded from the FTI scope inventory is a system where encryption, access controls, audit logging, and background check requirements are not being applied. Derived data environments are frequently less hardened than production systems because they were built for analytical access, not controlled access. They are also frequently accessible to a broader set of internal users.
Third-party agreements that specify requirements but do not validate them
Across assessments of organizations that share FTI with cloud providers, managed service providers, and software vendors, Vulnox finds a consistent pattern: the agreement exists, specifies security requirements, and has never been followed up with a technical validation of whether those requirements are being met. The contract says the vendor will encrypt FTI at rest using AES-256. No one has verified the encryption configuration since the contract was signed. The vendor's infrastructure has changed. The FTI is in a new storage tier. The contract clause still says AES-256. The actual configuration is unknown.
IRS Publication 1075 requires ongoing oversight of third-party compliance, not one-time due diligence. An organization that cannot demonstrate periodic re-validation of vendor controls — not just re-attestation by the vendor, but actual evidence — has a gap that IRS reviewers will find. The vendor's self-certification does not satisfy the requirement.
SIEM tuning gaps specific to FTI exfiltration patterns
In one engagement with a tax software vendor handling FTI for multiple state clients, Vulnox reviewed the SIEM deployment and found that alerting rules were built around the vendor's generic security templates. The rules flagged bulk data movement above a defined threshold, failed authentication attempts, and privilege escalation events. They did not flag: off-hours queries against FTI datasets by authenticated users with legitimate access, repeated access to specific taxpayer records by a single user over a compressed time window, or data exports in FTI-adjacent file formats below the bulk threshold. The SIEM had been running for 26 months without a significant alert. The assessment found three patterns consistent with insider data collection.
Generic SIEM rules are built to detect attacker behavior. FTI exfiltration by insiders with legitimate access looks different. It looks like normal access at abnormal times, or normal access at normal times to abnormal data. Catching it requires alerting rules built around FTI access patterns, not generic threat signatures.
Passing the safeguard review is not the signal you think it is
Common belief
Organizations that have passed an IRS safeguard review treat it as confirmation that their FTI controls are working. The review happened. The reviewer found no deficiencies. The compliance posture is validated.
What we found
In assessments conducted within 24 months of a clean IRS safeguard review, Vulnox found material FTI control gaps in the majority of engagements. The most common: audit logging configurations changed during a platform upgrade without security review, and new FTI data flows created for a new program that were not added to the scope inventory or covered by the existing third-party agreement.
Safeguard reviews examine a point-in-time snapshot of documented controls, sampled evidence, and interviewed personnel. They do not continuously monitor the live environment between review cycles. Configuration drift — changes to audit logging settings, encryption configurations, access control policies, or network segmentation — accumulates between reviews without triggering any IRS notification or re-review. An organization that passed a review 18 months ago and has since migrated to a new cloud region, onboarded a new data vendor, and expanded FTI access to a new business unit may have passed every review it has ever faced and still be carrying significant active exposure.
What organizations say before the assessment
'We use a FedRAMP-authorized platform. That should cover most of the IRS 1075 requirements automatically.'
Root cause:FedRAMP authorization confirms that a cloud platform's infrastructure meets a defined set of NIST 800-53 controls at the time of authorization. It does not configure those controls for the specific data types the customer is storing. FTI-specific requirements — audit log granularity, encryption of derived data, access controls tied to IRS-defined need-to-know — require customer-side configuration on top of the authorized platform. FedRAMP is a floor for platform security. IRS 1075 requirements are tenant-level obligations that the platform does not fulfill on the customer's behalf.
'Our background check process is handled by HR. We run checks on everyone at hire.'
Root cause:IRS Publication 1075 specifies background investigation criteria that exceed standard employment background checks. The investigations must assess suitability for FTI access specifically, must be repeated at minimum every five years, and must meet IRS-defined standards rather than general employment standards. Organizations that route FTI access authorization through HR's standard onboarding check are not meeting the Publication 1075 requirement — they are meeting a different, less specific requirement and assuming equivalence.
'We have a BAA with our cloud provider that covers data protection. That's our third-party agreement.'
Root cause:A Business Associate Agreement is a HIPAA instrument covering protected health information. It is not a substitute for an IRS 1075 third-party agreement, which must specifically address FTI handling requirements: permissible uses, access controls, encryption standards, incident notification timelines, and the provider's obligation to allow IRS audit access. A BAA does not contain these provisions. An organization that has a BAA but no IRS-specific third-party agreement with their cloud provider has an undocumented FTI sharing relationship under Publication 1075.
What IRS 1075 programs consistently miss
Development and test environments containing production FTI
Publication 1075 applies to FTI across the full data lifecycle, including development, test, and staging environments. Organizations routinely copy production data into development environments to support realistic testing conditions. If that production data includes FTI, the development environment is in scope. Development environments typically have broader access, less restrictive network controls, and lighter audit logging than production systems. They are also frequently accessible to contractors and third-party developers who are not covered by the organization's FTI access controls.
Incident notification timelines under Publication 1075
IRS Publication 1075 requires notification to the IRS Office of Safeguards within 24 hours of identifying a suspected FTI breach. This is a significantly shorter window than most organizations's incident response plans are built around — many IR plans specify 72-hour internal escalation timelines before external notification decisions are made. An organization whose IR plan triggers IRS notification at hour 48 of an FTI incident has already violated the publication's notification requirement. The 24-hour clock starts at identification, not confirmation.
Remote access to FTI and the endpoint security gap
Publication 1075 requires that remote access to FTI occur through approved, encrypted channels with MFA enforced. It does not specify requirements for the endpoint device used to initiate that access. Organizations with bring-your-own-device policies or contractor-provided laptops frequently have IRS-compliant remote access infrastructure — VPN, MFA, encrypted tunnel — and unmanaged endpoints on the other side of it. The FTI travels through a compliant channel to a device with no endpoint management, no disk encryption verification, and no assurance that the session is not being recorded or cached.
Where IRS 1075 enforcement pressure increases
IRS Office of Safeguards will begin requiring technical validation artifacts — specifically audit log samples and encryption configuration exports — as standard submission requirements for scheduled safeguard reviews, rather than requesting them selectively during on-site examination. This will expose configuration gaps that currently survive document-only review phases.
The IRS has been moving toward evidence-based assessment methodology in line with broader federal audit modernization. The current variability in what reviewers request during on-site visits creates inconsistent enforcement. Standardizing the evidence request list removes that variability and surfaces the configuration gaps that organizations are currently not catching before the review. The audit log configuration gap, specifically, is predictable enough at scale that requiring log samples as a standard submission item would surface it consistently.
Confidence: mediumA published update to the IRS safeguard review evidence request standard that includes mandatory audit log sample submission, before Q1 2028.At least one state agency will face IRS suspension of FTI access specifically due to a cloud migration that moved FTI data to a new region or storage tier without updating the scope inventory, third-party agreement, or encryption validation. The finding will originate from a safeguard review, not a breach.
Cloud migrations are frequent, often managed by IT or infrastructure teams with limited visibility into compliance obligations, and rarely trigger a compliance review before cutover. The scope inventory and third-party agreement updates that a FTI migration requires are organizational process steps that infrastructure teams are not trained to initiate. The gap between migration completion and compliance update is a predictable window. IRS reviewers who request current network diagrams and compare them against the prior review's scope inventory will find it.
Confidence: highA public record of IRS FTI access suspension citing scope inventory failure following a cloud migration, before Q4 2027.
The 24-hour notification requirement changes how IR plans need to be built
Most incident response plans are built around a decision tree that prioritizes internal confirmation before external notification. Confirm the incident. Assess scope. Escalate internally. Then decide on external notification. That sequence is reasonable for most incident types. It is incompatible with IRS Publication 1075's 24-hour notification requirement, which starts at identification — not confirmation. An organization that identifies a potential FTI breach at 9am and runs a 12-hour internal investigation before concluding that notification is warranted has 12 hours left to notify the IRS Office of Safeguards. An organization that runs a 48-hour internal investigation before external notification has already violated the requirement before making the call. IR plans that handle FTI need to be rebuilt with the 24-hour clock as the constraint, not the investigation timeline.
Counterargument
The counterargument is that requiring notification within 24 hours of identification — before the scope and nature of the incident is understood — creates noise for IRS investigators and may trigger regulatory response to incidents that turn out to be non-events. That is a legitimate concern. It does not change the requirement. Organizations that disagree with the notification timeline have the option to raise it through formal comment processes. They do not have the option to apply their preferred timeline instead of the published one.
One thing to do this week
Pull the audit logging configuration for every system in your FTI scope inventory. For each system, verify that access events are being logged at the action level — not just session initiation and termination, but what data was accessed, by whom, and when. If you are using Microsoft Purview, check the audit policy settings specifically. If you are using a SIEM, verify that FTI data access events are reaching it and that alerting rules are configured to detect access patterns, not just generic threat signatures. This is the single control that IRS safeguard reviewers request evidence for most consistently, and it is the control that most organizations have not validated since initial deployment.
Further Reading
Gap Analysis
gap analysis processNIST
NIST cybersecurity frameworkNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkNational Vulnerability Database NIST
NIST National Vulnerability DatabaseUnderstanding Compliance Gap Analysis
compliance gap analysis guide
Frequently Asked Questions
What data counts as FTI under IRS Publication 1075?
FTI is any return or return information received directly from the IRS or derived from IRS data, as defined under 26 U.S. Code Section 6103. This includes individual and business tax returns, taxpayer identification numbers, financial figures, and any data produced by combining IRS-sourced information with other datasets. The derived data point is where most organizations undercount scope — a data warehouse that ingests FTI alongside other sources does not lose its FTI designation for the records that contain tax data.
What does the IRS actually examine during a safeguard review?
IRS safeguard reviews combine document examination, interviews, and technical testing. Reviewers will request audit log samples and verify that access events are being logged at the action level, not just the session level. They will examine background check records and verify recency. They will review third-party agreements and check whether security requirements are specified in writing. Organizations that have prepared documentation without validating the live technical controls routinely find that what the SSR examines and what they have ready to show are two different things.
How often do background checks need to be repeated for employees with FTI access?
IRS Publication 1075 requires background investigations at initial access and at a minimum every five years thereafter. The standard HR onboarding check does not meet IRS criteria — the investigation must meet specific suitability standards defined in the publication. For roles with elevated FTI access, annual re-verification is defensible and increasingly expected. Organizations that treat the five-year cycle as a maximum rather than a floor create unnecessary exposure between review cycles.
Where do SIEM deployments typically fail for FTI breach detection?
The most common failure is deploying a SIEM with vendor default alerting rules and assuming FTI access events are covered. Default rules are built around generic threat patterns — failed logins, privilege escalation, bulk data movement. They do not alert on unusual access to FTI-specific datasets, off-hours queries against tax data tables, or data transfers involving FTI file types at volumes just below the threshold that generic rules flag. A SIEM that is not tuned to FTI data patterns will miss the exfiltration events that matter most during an IRS investigation.
What are the vendor obligations under IRS 1075 for organizations that share FTI with third parties?
Any entity that receives FTI from a covered organization inherits the same protection obligations under Publication 1075. The originating organization is responsible for ensuring that vendor agreements specify encryption requirements, access control standards, incident response obligations, and audit rights. Periodic validation — not just initial due diligence — is required. A vendor who passed a security questionnaire two years ago and has since changed infrastructure configurations is not a validated vendor. The obligation runs continuously.
What is the IRS penalty exposure for a safeguard failure involving FTI?
Unauthorized disclosure of FTI carries criminal penalties under 26 U.S. Code Section 7213, including fines and imprisonment. Civil liability under Section 7431 allows affected taxpayers to bring suit for actual damages or $1,000 per unauthorized disclosure, whichever is greater, plus punitive damages if the disclosure was willful. Beyond the legal exposure, agencies that fail IRS safeguard reviews face suspension of FTI access — which for a state tax agency or benefits administrator means operational shutdown of core functions.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.