How IRS Publication 1075 uses NIST 800-53 for federal tax information
If your agency or company receives, stores, processes or transmits federal tax information (FTI), Publication 1075 builds its electronic FTI control catalog on NIST SP 800-53 Rev. 5 and requires an annual Safeguard Security Report (SSR). The SSR documents how the controls protecting FTI are implemented and records significant changes, such as moving FTI systems into a cloud environment. Your organization owns those controls and the SSR. An implementation partner such as DeployOpen can help prepare systems, configurations, logs and evidence that map to the catalog, but DeployOpen does not validate compliance. Only the IRS review, which checks the SSR against Publication 1075 and SP 800-53 using Safeguards Computer Security Evaluation Matrices, produces that outcome. Scope is wider than many teams expect. Assessments cover any technology used to receive, process, store, access, protect or transmit FTI, whether the system is run by the agency, a state's consolidated IT organization, a contractor, a sub-contractor or a constituent county. Start by listing every system, service and third party that touches FTI, including backups, support tooling and administrative access paths. Confirm with the IRS Office of Safeguards which of these must appear in the SSR before you rely on a narrower boundary.
Cost and timeline depend on the number of FTI systems, how much of the environment is already documented, the cloud or data center model, and how many contractors must be assessed. No figures for either are supplied here, so ask any partner for a fixed-scope written proposal that separates one-time work (architecture review, control implementation, evidence collection, first SSR) from recurring work (annual SSR updates, monitoring, change notifications and re-testing). Ask the IRS Office of Safeguards for current submission dates, and check the IRS Safeguards Program page for the current guidance before you commit to a schedule. Before engaging help, decide three things: which team owns each Publication 1075 control, which systems fall inside the FTI boundary, and whether your cloud provider's FedRAMP authorization and onshore data handling can be documented for the IRS notification. Those decisions shape the statement of work far more than tooling does.
What the Publication 1075 cycle looks like from start to IRS review
The cycle moves from scoping every system that touches federal tax information through control implementation, reporting and cloud notification to an IRS review that tests what the Safeguard Security Report says against what the systems actually do. Each phase produces an artifact the next phase depends on.
Scope every system that touches FTI
The agency or recipient inventories every technology that receives, processes, stores, accesses, protects or transmits federal tax information. The inventory must include systems managed by the agency, a state's consolidated IT organization, contractors, sub-contractors and constituent counties, since Publication 1075 assessments reach all of them. The output is a boundary document that names each system, its owner, where FTI flows and which organization is responsible for each control. Confirm the boundary with the IRS-facing owner before implementation starts, because a system missed here will be missed in the SSR.
Map Section 4.0 controls to each system
Section 4.0 of Publication 1075 lists the NIST SP 800-53 Rev. 5 controls that must protect electronic FTI, along with IRS-defined requirements and adapted digital identity requirements. For each in-scope system, the team assigns every control to an owner, marks whether it is implemented by the system, inherited from a provider, or handled by a manual process, and records the gap. The output is a control implementation matrix per system. Ask for this matrix from every contractor and sub-contractor, not only the prime.
Implement and configure the controls
Engineers and administrators configure systems to meet each control, such as access enforcement, audit logging, encryption, configuration baselines and patching. Self-hosted open-source platforms in the client's own infrastructure can generate much of the configuration and log evidence, but each setting must be tied to a control and reviewed by the control owner. The output is configuration baselines, change records and test results that show each control is operating, not only designed. Where a control depends on a cloud provider, record which parts the provider covers and which parts remain with the agency or contractor.
Assess controls and document the results
Before reporting, the organization tests its own controls against the assessment procedures in SP 800-53A, using examination of documents, interviews and technical testing. Gaps are recorded with owners and remediation plans. The output is an internal assessment record that ties each control to the evidence reviewed and the date of review. This record is what makes the next step accurate, because the SSR should describe what was tested, not what was intended.
Update and submit the Safeguard Security Report
Publication 1075 requires an annual Safeguard Security Report that documents how the controls protecting FTI are implemented and records any significant changes, such as moving FTI systems to a FedRAMP authorized cloud. The SSR covers every system in the scoped boundary, including contractor systems. The output is the submitted SSR, supported by the implementation matrix and assessment record from earlier steps. Confirm the current submission requirements and format with the IRS Office of Safeguards, since the report is the document reviewers test against.
Notify the Office of Safeguards before cloud use
Before any FTI is placed in a cloud environment, Publication 1075 requires notifying the IRS Office of Safeguards at least 45 days in advance. The notice must document that FTI stays onshore, the provider's FedRAMP authorization, how encryption prevents provider staff from seeing FTI, and all agency-managed controls. The output is the notification package and a record of the date it was sent. Plan the cloud migration schedule backward from this requirement, because a late notice affects go-live rather than only paperwork.
Prepare evidence for the IRS review
IRS cybersecurity reviewers assess compliance using manual and automated procedures defined in Safeguards Computer Security Evaluation Matrices (SCSEMs). They validate the SSR against Publication 1075 and SP 800-53, so each SSR statement must be traceable to a configuration, log, record or interview answer. The output is an evidence binder organized by control, with named owners who can explain each system during the review. Run a dry walkthrough of a sample of controls before the review, and confirm with the IRS which SCSEM versions apply to the scope.
Close review findings and feed them back
Review findings become corrective actions tracked in the plan of action and milestones, with owners and evidence of closure. Significant changes found during the review or made during remediation are reflected in the next SSR, which restarts the annual cycle. The output is a closed findings register and an updated boundary and control matrix. Publication 1075 treats the SSR as a living record, so the organization should verify that each corrective action changed the system, not only the document.
What Section 4.0 of Publication 1075 asks for
Section 4.0 of IRS Publication 1075 is the part of the document that sets the technical bar for electronic federal tax information (FTI). It works as a catalog of NIST SP 800-53 Rev. 5 security and privacy controls that must be implemented to protect FTI held in electronic form. Treasury Directive 85-01 requirements appear in the same catalog, but they are shown as IRS-defined requirements, so a Treasury requirement and a NIST control can sit side by side in one row. Digital identity requirements from SP 800-63 are adapted into the catalog as well, which means the authentication expectations in Publication 1075 are not a straight copy of the NIST digital identity guidelines. Read the adapted wording as the binding version.
The November 2021 revision also changed how privacy is handled. Privacy controls that sat in Appendix J of SP 800-53 Rev. 4 are now integrated into the Rev. 5 control set, and Publication 1075 aligned its own control section to Rev. 5 to match. For a team that mapped Rev. 4 Appendix J language into a previous Publication 1075 program, this means the privacy evidence now sits inside the families you already maintain. Confirm which Rev. 5 control identifiers your current control matrix uses, and check that each IRS-adapted row still points to the right Rev. 5 control before you reuse an old matrix.
For family-level detail, use the control catalog and baselines in the NIST 800-53 pillar of this site, which explain what each control requires and the evidence that passes. That material is a study aid. The controlling text is the Publication 1075 PDF from the IRS, and wording in your contract, your Safeguard Security Report or an IRS review follows that document, not a summary. Download the current revision from the IRS, record its revision date in your control matrix, and have your legal or compliance lead confirm which version your contract cites before any control is marked as met.
Which systems and contractors fall inside the assessment scope
Publication 1075 assessments do not stop at the agency's own data center. They reach any technology that touches federal tax information (FTI), whoever owns it. The four components below define the boundary, and each one needs a documented data flow behind it.
Agency-managed technology
Systems the receiving agency owns or runs directly, including servers, databases, applications, endpoints and network devices that receive, process, store, access, protect or transmit FTI. Scope starts here because the agency is the party that submits the Safeguard Security Report and answers for every control in Section 4.0. Confirm with the agency which internal systems hold FTI copies, reports or extracts, since these are often missed in inventories built only from production application lists.
State consolidated IT organization
When a state runs IT through a central consolidated organization, the platforms, hosting and shared services it operates for the agency can fall inside the assessment even though the agency does not manage them. Agencies should confirm in writing which controls the consolidated IT organization implements, which the agency implements, and how evidence moves between the two. Ambiguity here usually surfaces during the review, not before it.
Contractors and sub-contractors
Any contractor or sub-contractor whose technology touches FTI is in scope, including hosted platforms, managed service providers, backup vendors and offshore support tools that have access. Each contract should name the systems, the controls the contractor implements and the evidence it provides for the annual Safeguard Security Report. Map sub-contractors one tier down, because a vendor that stores encrypted backups still holds FTI.
Constituent counties
Where a state's program is delivered through county offices, the technology those counties use to handle FTI is part of the assessment. Counties often run their own file shares, case management tools and printers or scanners that store images of FTI. Inventory county systems separately, assign an owner to each one and confirm that county staff follow the same access and retention rules as state staff.
What counts as FTI technology
Scope turns on function, not ownership. A system is in scope if it receives, processes, stores, accesses, protects or transmits FTI, even briefly or as a copy. This includes email gateways, print servers, log platforms that capture FTI in records, backup repositories and the identity systems that grant access. Treat every technology that performs one of those five functions as in scope until a documented analysis shows otherwise.
Map data flows before scoping
Build a data flow diagram that traces FTI from the point of receipt through every processing step, storage location, transmission path and disposal event. Mark each hop with the system, the owner and the control that protects it. Scoping from org charts or asset lists alone tends to omit integrations, exports and support tooling. A current flow map also feeds the Safeguard Security Report and any cloud notification the agency must send to the IRS Office of Safeguards.
What the annual Safeguard Security Report must document
The Safeguard Security Report (SSR) is the agency's annual document to the IRS Office of Safeguards. Publication 1075 requires the agency to update and submit it each year, describing how the security and privacy controls protecting federal tax information (FTI) are implemented across the systems that receive, process, store, access, protect or transmit it. It must also record significant changes since the last report, such as moving FTI systems to a FedRAMP authorized cloud. The report covers technology managed by the agency, its contractors and sub-contractors, and any constituent counties or state consolidated IT organization in scope, so a contractor's environment has to be described in the agency's report even when the contractor runs it.
The SSR is the agency's document and the agency's signature. A consultant or implementation partner can help gather system descriptions, control narratives and evidence, and can check the draft against the Publication 1075 control catalog, but the agency owns each statement in the report and is accountable for its accuracy. Every statement should point to evidence the agency can produce on request, such as configuration exports, access review records, encryption settings, backup test results and change tickets. Reviewers use Safeguards Computer Security Evaluation Matrices (SCSEMs) to test both manual and automated procedures, so an untraceable claim is a finding waiting to happen. Before drafting, confirm with the agency's Safeguards contact which systems are in the report boundary and which contractor records the agency will need to request.
For a contractor, the practical task is to prepare evidence in a form the agency can file without rework. Ask the agency which control narratives and artifacts it expects from you, how often it wants them refreshed between annual cycles, and how changes to hosting, such as a new cloud region or a migration, must be reported and when. Keep the evidence set versioned alongside the system security plan so that each year's report can be traced back to what was true at the time. Those artifacts are what a partner typically helps build; the agency's submission remains the agency's decision.
Cloud notification rules for FTI
Publication 1075 requires the agency to notify the IRS Office of Safeguards at least 45 days before placing federal tax information (FTI) in a cloud environment. The agency compliance lead owns that notice and the decision it reports. The notice must document that FTI will stay onshore, identify the provider's FedRAMP authorization, explain how encryption prevents provider staff from viewing FTI, and describe every control the agency manages itself. The lead should treat the notice as a summary that points to evidence held elsewhere, not as the evidence.
- Onshore data location: Name the regions and facilities where FTI will be stored, processed and backed up, and confirm the provider can restrict placement to those locations.
- FedRAMP authorization: Record the authorization level, the package identifier and the date of the most recent continuous monitoring deliverable, and confirm the authorization covers the specific service.
- Encryption and key custody: Describe who holds the keys and how provider personnel are kept from reading FTI in plaintext.
- Agency-managed controls: List the controls the agency retains, such as user access, logging review and incident handling for its tenant.
- SSR update: Confirm the change is reflected in the annual Safeguard Security Report.
Before sending, check that the notice matches the contractor's system security plan and the provider's authorization documents, because the IRS can compare them.
A contractor that hosts, processes or transmits FTI on behalf of an agency is inside the assessment scope of Publication 1075, including its subcontractors. In practice the contractor prepares the technical material the agency relies on for the notice. The contractor should not assume the agency will reconstruct its architecture. The documents must describe the actual data flows, the administrative paths into the environment and the boundaries where FTI could leave the approved region.
- Data flow diagrams: Show where FTI enters, is stored, is processed, is backed up and exits, including support and logging paths.
- Personnel access map: Identify which roles can reach FTI, how they authenticate, and how their access is reviewed.
- Subcontractor inventory: List every subcontractor with access to the environment and its location, so the notice covers the whole chain.
- Encryption design: Document algorithms, key management service configuration and the FIPS-validated modules in use.
- Monitoring and incident path: Describe how security events are logged, retained and escalated to the agency.
Before the notice goes out, walk the data flow diagram against the notice text and confirm that no subcontractor or support path is missing.
The provider's FedRAMP package is the primary source the agency cites for the authorization claim. Publication 1075 asks the notice to document the provider's FedRAMP authorization, so the agency and contractor need current, accurate extracts from the provider's package. The IRS will examine whether the authorization covers the specific service and boundary used for FTI, not only the provider's general authorization. Customer responsibility matrices and inherited control statements show which controls the agency and contractor must still implement.
- Authorization scope: Confirm the authorized service offerings and the boundary include every service that will touch FTI.
- Customer responsibility matrix: Extract the controls assigned to the customer and map each one to the agency or contractor owner.
- Continuous monitoring reports: Obtain the latest ongoing assessment deliverables and any open findings that affect FTI services.
- Data residency commitments: Obtain the provider's documented commitments on onshore storage and the controls that enforce them.
- Version currency: Verify that the package reflects the current authorization status, since a lapsed or changed authorization invalidates the notice.
Ask the provider to confirm in writing that the authorization and responsibility matrix you hold are current on the day you send the notice.
How IRS cybersecurity reviews test compliance
IRS cybersecurity reviewers test Publication 1075 compliance with Safeguards Computer Security Evaluation Matrices, using both manual and automated procedures. The review checks that the Safeguard Security Report matches what the agency actually runs, measured against Publication 1075 and the SP 800-53 Rev. 5 controls it adopts. The cards below cover what reviewers examine and the evidence to have ready before they arrive.
Safeguards evaluation matrices
Reviewers work through Safeguards Computer Security Evaluation Matrices, known as SCSEMs, which turn Publication 1075 requirements into test steps. Each matrix pairs a control with procedures that combine manual inspection, such as reading configurations and interviewing administrators, with automated checks run against the systems. Before a review, walk the matrices yourself and confirm each step has a named owner and a current artifact.
Manual and automated procedures
Manual procedures cover policy, roles, rules of access and how staff follow them, while automated procedures check settings and logs on the systems that receive, process, store or transmit FTI. A control can pass the manual check and fail the automated one when the running configuration drifts from the documented baseline. Run the same checks internally on a schedule so the reviewers do not find the gap first.
SSR validated against both documents
The review validates the Safeguard Security Report against Publication 1075 and the SP 800-53 Rev. 5 controls it adopts. Every control statement in the SSR must describe how the control is implemented on the systems in scope, including contractor and sub-contractor systems. An SSR that describes intent rather than a verifiable implementation is the most common source of questions, so tie each statement to a configuration, record or test result.
Scope of in-review systems
Reviewers test any technology used to receive, process, store, access, protect or transmit FTI, whether managed by the agency, a state consolidated IT organization, contractors, sub-contractors or constituent counties. Confirm the inventory of FTI systems is complete before the review, including backup systems, administrative tools and cloud accounts. Missing a contractor-managed component from the scope is a finding that is easy to avoid with a current data flow diagram.
Cloud and change evidence
Significant changes such as moving FTI systems to a FedRAMP authorized cloud must appear in the SSR, and the Office of Safeguards must receive notice at least 45 days before FTI goes into a cloud environment. Reviewers will ask for the notification package, the provider's FedRAMP authorization, proof that FTI stays onshore and the encryption design that keeps provider staff from viewing FTI. Keep these documents dated and linked to the change record.
Evidence to keep ready
Keep current access reviews, configuration baselines, audit log samples, vulnerability scan results, patch records, incident response test reports, plans of action and milestones and signed agreements for information exchanges in one indexed location. Each item should show the date it was produced and the system it covers. Pull the evidence from the self-hosted tooling where possible so it reflects the live environment instead of a snapshot prepared for the review.
What compliance with Publication 1075 costs and who is paid
This table lists who is paid for each part of Publication 1075 work, whether the cost is one-time or recurring, and what drives it up. No price or effort figure is supplied for this topic, so use the table to shape a written scope and quote request rather than to estimate budget.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| Agency or contractor internal staff | Your own payroll or existing staff time | Recurring. Covers SSR preparation, control ownership, access reviews and responses to IRS reviewers. Driven by how many FTI systems and sub-contractors are in scope. |
| Implementation partner for controls and evidence | Outside firm paid under a written scope | Mostly one-time for build and hardening, then recurring for upgrades and evidence refresh. Driven by number of systems, existing gaps and whether controls are rebuilt or documented. |
| Tooling and platform licenses | Software vendors, or open-source tools at no license fee | Both. Commercial licenses recur; open-source tools carry hosting, maintenance and staff time. Driven by logging volume, scanner coverage and self-hosting choices. |
| Independent assessment support | Independent assessor or consultant, if you engage one | Recurring per review cycle. Confirm with the assessor what is in scope, what evidence they request and whether pre-assessment readiness work is separately priced. |
| Cloud provider documentation and authorizations | Cloud provider (typically included in service terms, confirm) | Recurring access to compliance documentation. Confirm which FedRAMP authorization packages, inherited control mappings and notification support apply to your region and services. |
| IRS notification and SSR process | Internal staff and any outside advisor you retain | Annual SSR and at least 45 days advance notice before placing FTI in a cloud environment. Driven by the number of significant changes in the year. |
What makes the FTI program larger or slower
Most of the effort in an IRS Publication 1075 program comes from how many systems touch federal tax information (FTI), who else handles it, and where those systems run. Evidence quality and legacy technology then decide how quickly the Safeguard Security Report can be produced and defended.
Number of FTI systems
Every technology that receives, processes, stores, accesses, protects or transmits FTI falls within the assessment scope, including supporting tools such as backup, logging and ticketing. Start with a data flow inventory that traces FTI from intake to disposal, then list each system on it with an owner and a boundary. Ask whether the inventory is produced from the data flows or from memory, because an incomplete inventory forces rework later in the SSR.
Contractors and sub-contractors
Publication 1075 assessments reach technology operated by the agency's contractors and sub-contractors, not only the agency's own systems. Each party that touches FTI adds documentation, control evidence and review time. Map every contractor and sub-contractor to the systems and data they handle, and confirm contract language requires them to support IRS reviews before work starts.
Cloud versus on-premises hosting
Moving FTI into a cloud environment requires notifying the IRS Office of Safeguards at least 45 days in advance, along with evidence that FTI stays onshore, the provider's FedRAMP authorization and how encryption keeps provider staff from viewing FTI. On-premises systems avoid that notice but carry their own physical and environmental evidence. Decide hosting early, because a late change to cloud hosting resets notification timing and documentation.
Evidence maturity
IRS reviewers test controls with manual and automated procedures, so an assertion without a repeatable record will not satisfy them. Evidence that is generated on a schedule, such as access reviews, scan results and change tickets, is faster to produce each year than evidence assembled for each review. Ask which controls already produce logs or reports automatically and which depend on someone remembering to collect them.
Legacy systems
Older systems often cannot support current authentication, logging, encryption or patching requirements, and the SP 800-53 control set expects each gap to be documented, risk-accepted or remediated. A legacy application that stores FTI may need compensating controls, isolation or a retirement plan that appears in the plan of action and milestones. Identify unsupported components early so the remediation schedule does not surface during the review.
Who owns what in a Publication 1075 program
The agency, or the contractor operating under it, owns the Publication 1075 program. Its leadership decides which systems receive, process, store, access, protect or transmit federal tax information (FTI), implements the controls in the Section 4.0 catalog for those systems, and accepts the residual risk. The organization also signs the annual Safeguard Security Report (SSR) and is accountable for what the SSR says about how controls operate.
- Control ownership: Named owners for each control family, including controls that are agency-managed rather than inherited from a provider.
- Scope decisions: Identifying every technology in the FTI environment, including contractor and sub-contractor systems and any constituent county systems.
- Cloud notification: Notifying the IRS Office of Safeguards at least 45 days before placing FTI in a cloud environment.
- SSR accuracy: Signing an SSR that reflects the controls as they actually run, and reporting significant changes.
- Corrective action: Tracking findings from IRS reviews and funding the remediation.
Before engaging any outside party, confirm in writing which of these decisions remain with your own staff.
An implementation partner such as DeployOpen works for the agency or contractor to prepare the systems, controls and evidence that the organization will rely on. It configures self-hosted open-source platforms inside the client's own infrastructure, documents how each control is implemented, and assembles the artifacts an assessor will request. The partner does not own the controls, does not sign the SSR and does not issue any report or certification.
- System preparation: Hardening, configuration, logging and backup of the platforms that handle FTI, inside the client's cloud accounts, data centers or air-gapped networks.
- Control documentation: Drafting implementation statements mapped to the Publication 1075 control catalog for the client to review and approve.
- Evidence production: Setting up collection of configuration baselines, access reviews, audit logs and scan results that the organization can present during an IRS review.
- Testing support: Running security testing in the agreed scope and reporting findings to the client.
- Fixed scope: Deliverables, boundaries and timelines agreed in writing before work starts.
When you review a proposal, check that each deliverable names the artifact the client will own afterward.
IRS cybersecurity reviewers assess Publication 1075 compliance. They use Safeguards Computer Security Evaluation Matrices (SCSEMs) to test both manual and automated procedures, and they validate the SSR against Publication 1075 and NIST SP 800-53. Their role is to test what the agency or contractor says and shows, not to design the program. The IRS Office of Safeguards publishes the program details and the reviewer process on its Safeguards Program page.
- Procedure testing: Checking that manual and automated procedures operate as documented.
- SSR validation: Comparing the report against the Publication 1075 control catalog and the underlying SP 800-53 controls.
- Cloud review: Evaluating the onshore storage statement, the provider's FedRAMP authorization and how encryption keeps provider staff from viewing FTI.
- Findings: Issuing review results that the agency must address, which become part of its corrective action work.
- Limits: Reviewers do not prepare the organization's controls or evidence.
Before a review, ask your Office of Safeguards contact which SCSEM procedures apply to your environment.
How to get ready before the next SSR and IRS review
Start with the boundary. Before anything else, the agency or contractor needs a current inventory of every system that receives, processes, stores, accesses, protects or transmits federal tax information (FTI), including systems run by contractors, sub-contractors and, where applicable, a state's consolidated IT organization or constituent counties. Publication 1075 assessments reach all of that technology, so an inventory that covers only the agency's own data center will not survive review. For each entry, record the owner, the hosting model, where the FTI flows, and whether the system is in an onshore cloud environment. Confirm the inventory against the current Publication 1075 PDF from the IRS Publication 1075 document and the IRS Safeguards Program page, because the reviewers' expectations on scope are set there and in the Safeguards Computer Security Evaluation Matrices, not in your own assumptions.
Next, map each control in Section 4.0 to a named implementation and a named owner. A control statement that says what the system does is not enough. For each one, record the configuration key, the tool or log source, the responsible role and the date of the last test, so the Safeguard Security Report (SSR) can describe how the control is implemented and what changed in the year. Then run a dry-run evidence collection against the controls most likely to be sampled, such as access reviews, audit log retention, encryption settings and change records. Check whether an assessor can reproduce each result from the artifact alone. The NIST 800-53 documentation and evidence and NIST 800-53 tools and automation pages in this series list the plans, plans of action and milestones, and tooling that produce those artifacts.
Finally, prepare the change and flow-down packages. If FTI is moving to or expanding within a cloud environment, Publication 1075 requires notifying the IRS Office of Safeguards at least 45 days before the change, with documentation of onshore storage, the provider's FedRAMP authorization, how encryption keeps provider staff from seeing FTI, and every agency-managed control. Confirm the provider's current authorization status and its boundary with your counsel and assessor, since the notice must match the actual environment. On the contractor side, check that the contract flows down the Publication 1075 requirements, that each sub-contractor's systems appear in the inventory, and that their evidence arrives on the same schedule as yours. Ask outside help for the gap review and evidence walkthrough only if it is scoped in writing, and remember that the IRS review validates the SSR, and independent assessors, not your implementation partner, issue any formal attestation.
Questions agencies and contractors ask about Publication 1075
Does a contractor have to comply with Publication 1075 directly?
Yes, if the contractor receives, processes, stores, accesses, protects or transmits federal tax information on the agency's behalf. Publication 1075 assessments cover technology managed by the agency, a state's consolidated IT organization, the agency's contractors and sub-contractors, and its constituent counties. The contract is the usual way the requirements reach you, so the agency's contract language, data flow diagrams and the list of systems touching FTI determine which of your environments fall in scope. Confirm the scope in writing with the agency before you size any work, because a system that only holds metadata or non-FTI records may sit outside the boundary.
What drives the effort to produce the Safeguard Security Report?
The Safeguard Security Report (SSR) is an annual document that describes how the security and privacy controls protecting FTI are implemented, and it must call out significant changes such as moving FTI systems to a FedRAMP authorized cloud. The main drivers are the number of systems and data flows that touch FTI, how current your control documentation and system security plan are, how much evidence already exists for each Section 4.0 control, and how many changes occurred during the reporting period. Organizations with mature change records and centralized logging usually spend less time assembling evidence than those reconstructing it from memory. Ask any provider for a written list of the artifacts they will produce and the systems each one covers.
Can DeployOpen certify that our systems comply with Publication 1075?
No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares controls and evidence for assessment. It does not issue audit reports, attestations or certifications. The organization owns its controls and its SSR, and IRS Office of Safeguards reviewers validate the SSR against Publication 1075 and NIST SP 800-53 using Safeguards Computer Security Evaluation Matrices. Any statement that a system is compliant should come from the agency and its reviewers, and your engagement scope should say which outputs DeployOpen delivers and which are yours to submit.
What does the organization have to provide to start an engagement?
The organization must supply the inputs that only it can know. These include a list of systems and data flows that handle FTI, the current SSR and prior review findings, existing policies and procedures, network diagrams, identity and access arrangements, cloud account structure, and the names of the people who own each control. You also need to decide who approves the SSR content and who speaks with IRS reviewers. Missing inputs are the most common cause of delayed scope decisions, so ask the provider to list every input it needs before work begins and to confirm which ones it will not check on your behalf.
Can open-source tools produce the evidence Publication 1075 reviews need?
Many open-source tools can produce evidence for individual controls, such as log collection, configuration baselines, vulnerability scan output, access reviews and backup test records, provided they run in your environment and their output is retained and traceable. Self-hosting matters here because the evidence stays inside your boundary and you control its integrity. Tools do not satisfy a control by themselves, though. Each control still needs a defined procedure, an owner, and records showing it operated over the period the SSR covers. Confirm with each tool's vendor or project which capabilities it actually provides, and test whether its output would satisfy an examiner using the control's assessment procedure in SP 800-53A.
What must a cloud notification to the IRS Office of Safeguards include?
Publication 1075 requires notice to the IRS Office of Safeguards at least 45 days before FTI is placed in a cloud environment. The notice must document that FTI will remain onshore, the provider's FedRAMP authorization, how encryption prevents provider staff from viewing FTI, and all controls the agency manages itself. Prepare the notice with your cloud provider's authorization documents and a clear division of responsibilities, and confirm the current submission process with the agency and the IRS Safeguards Program, since the review timing and format are set by the IRS.
How do IRS reviewers test whether our controls work?
IRS cybersecurity reviewers assess compliance with both manual and automated procedures, using Safeguards Computer Security Evaluation Matrices. They check whether the controls described in the SSR exist, operate as described, and are supported by evidence. Reviewers typically ask to see configurations, logs, access records, policies and sample outputs, and they compare what they find against the SSR. Practical preparation means keeping the SSR consistent with your actual systems, tracking changes, and being ready to show how each control was tested over the review period. Ask the agency which SCSEM versions apply to your environment before the review begins.
How DeployOpen prepares Publication 1075 systems and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the systems that handle federal tax information can be assessed against Publication 1075 and its SP 800-53 Rev. 5 control catalog. We prepare the systems, controls and evidence; the agency or contractor owns its controls, and only the IRS review and the independent assessment process reach conclusions about compliance.
How we scope
- We define which systems, data flows and contractor or sub-contractor environments fall inside the Publication 1075 assessment boundary.
- We map each in-scope system to the Section 4.0 control catalog and record which controls the client, its cloud provider or a third party implements.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy and harden the self-hosted platforms in the client's accounts, data centers or air-gapped networks, with encryption and access controls set to the required configuration.
- We configure audit logging, identity and multi-factor authentication, and configuration baselines so that each control produces records an assessor can examine.
- We test controls against the assessment procedures in SP 800-53A and document gaps in a plan of action and milestones before handover.
How we hand over
- We prepare control implementation descriptions, system security documentation and evidence packages that feed the annual Safeguard Security Report.
- We document cloud notification inputs where FTI moves to a cloud environment, including onshore storage, FedRAMP authorization status and encryption key ownership, for the client to verify and submit.
- We train the client's staff to run, update and collect evidence from the platforms, so the organization can answer IRS reviewer questions itself.
How we support
- Ongoing support, upgrades, backups and continuous testing are available as retainers after handover.
- We keep documentation and configuration evidence current when systems change, such as a platform upgrade or a move to a new hosting environment.
- Security testing of applications, APIs, infrastructure and AI systems can be scoped separately to test the controls that the SSR describes.
