Privacy requirements derived from IRS Privacy Principles form the basis of privacy protection within the IRS.

IRS policy:

This IRM covers Privacy Compliance and Assurance (PCA) programs, including, but not limited to:

Subordinate procedural guidance, such as Standard Operating Procedures (SOP) and Desk Procedures, must be used for detailed guidance and instructions for implementing and complying with the requirements within this IRM. For further information, refer to the Privacy, Governmental Liaison and Disclosure (PGLD) site.

IRM 10.5.1, Privacy Policy, has precedence if conflicting information is present, unless the subordinate IRM is more restrictive or otherwise noted.

The origin of privacy requirement (National Institute of Standards and Technology (NIST), Treasury, etc.) will be referenced in parenthesis at the end of the requirement.

It is acceptable to employ practices that are more restrictive than those defined in this IRM.

This IRM mirrors authority from Policy reference. Refer to the Authority section of IRM 10.5.1.1.6, Privacy Policy for applicable authorities.

The Director, Privacy Policy and Compliance (PPC) is the executive responsible for the PCA program.

The Associate Director, Privacy Compliance and Assurance (PCA), is the program manager for the PCA program.

Authorizing Officials (AOs), as defined in IRM 10.8.2, IT Security Roles and Responsibilities are required to develop and maintain additional operational documentation (e.g., action and implementation plans, standard operating procedures), necessary for implementation of the privacy controls delineated in the IRM 10.5, Privacy and Information Protection series. Therefore, implementation of privacy policy is the responsibility of the owning AO to include documentation and procedures for how their information systems are managed, administered, and monitored.

For the purpose of this IRM, the following roles for IRS personnel apply:

Program Reports

Business Entitlement Access Request System (BEARS) is used to grant access to the Privacy Impact Management System (PIAMS) based on the user’s role.

The requirements within this policy follow privacy controls within NIST SP 800-53 Rev 5.

See Exhibit 10.5.2-1 Glossary and Acronyms

See IRM 10.5.1, Privacy Policy for Related Resources.

For authoritative sources, refer to:

The purpose of a PCLIA is to demonstrate that program managers, system owners, and developers have incorporated privacy and civil liberties protections throughout the entire lifecycle of a system. This ensures privacy and civil liberties protections are built into the system from the beginning, when it is less costly and more effective to include them.

The PCLIA process should be initiated as early in the system lifecycle as possible (e.g., the planning stage) so that technical solutions can be incorporated into system design as necessary to remediate privacy and civil liberties concerns identified during the PCLIA process.

System Owners must self-certify with OneSDLC that a PCLTA or PCLIA was approved by The Office of Privacy Review. (Also see the OneSDLC section IRM 10.5.2.2.9.1, OneSolution Delivery Lifecycle (OneSDLC) Readiness and Execution State).

For more information refer to OneSDLC site.

A Privacy PCLIA is a decision tool used to identify and mitigate privacy risks that notifies the public: U.S. Department of the Treasury.

A PCLIA should accomplish these goals:

For more information about the PCLIA process (including how to determine if a PCLIA is required), refer to the Privacy Impact Assessment Management System (PIAMS) User Guide.

Protecting privacy and civil liberties is the responsibility of every IRS employee. However, specific responsibilities apply to individuals who prepare, maintain, and approve the various PCLIAs. Refer to IRM 10.8.2, IT Security Roles and Responsibilities for how these roles apply to information technology development and security.

The IRS Senior Agency Official for Privacy (SAOP) has oversight responsibility for accounting to Treasury, OMB, and other regulatory agencies regarding the IRS’ implementation of information privacy protections, including full compliance with federal laws, regulations and policies relating to information protection, as established by the Division H, Title V, section 522 of the Consolidated Appropriations Act of 2005.

The Privacy Review Analyst (PRA) must:

The Privacy Review Manager must review all PIAs/PCLIAs/PCLTAs for completeness, including the Privacy analyst findings and case notes prior to forwarding to the Associate Director of Privacy Compliance and Assurance for approval memo or report signature. The Privacy Review Manager also provides guidance and final determination regarding approving a PCLIA with risk noted.

The Business Owner, Survey Owner, Site Owner or System Owner (SO) or accrediting official, must be a senior management/executive official government employee with the authority to formally assume responsibility for operating a system, contractor system, M365, RPA, AI, survey, and social Media site at an acceptable level of risk. As the approver, the SO attests that the PCLIA correctly documents substantial facts about the system, contractor system, M365, RPA, AI, survey, and social media site. The SO must ensure the PCLIA process begins in the early stages of the development of a project and complete it as part of the system's required OneSDLC review. Additionally, the SO must mitigate privacy findings or complete a Risk Acceptance Findings Tool (RAFT), as necessary. The System Owner may designate someone to approve the PCLIA.

System Developer, Contractor System Developer, M365 Developer, RPA Developer, AI Developer, Survey Administrator, Social Media Site Administrator, Project Manager, and Subject Matter Expert (SME) are terms applied to the individuals who carry out the development and implementation of the project. They must answer the PCLIA questions and those posed by Privacy Analysts. In PIAMS, the Project Manager approves the PCLIA for submission to Privacy Review.

The PCLIA Preparer may be anyone designated by the SO, including the SO, who completes the applicable form and works with the Privacy Analyst to identify and address any risks. This role includes responsibility to:

A Privacy and Civil Liberties Threshold Assessment (PCLTA) is a written risk assessment a Business Owner, System Owner, Contractor System Owner, M365 Project Owner, RPA Project Owner, AI Project Owner, Survey Owner, and Social Media Site Owner is required to complete when:

Generally, agencies must update or file new PCLIAs when a system change creates new privacy risks. The IRS requires PCLIA updates every three years, or sooner for new privacy risks.

Major changes requiring PCLIA updates include:

The IRS posts PCLIAs with PII on members of the public in compliance with the E-Government Act of 2002:

The E-Government Act of 2002 allows agencies to make decisions to determine what information in a government system should be redacted, or if for compelling security or privacy reasons, a PCLIA should not be posted. SOs (business owners and systems developers) will be instructed to remove certain information within PCLIAs that could cause harm to systems or processes or is not in the best interest of the agency to have published, such as:

SOs will be notified when a PCLIA is approved and if the PCLIA is designated to post to IRS.gov. The SO will have 10 business days to provide redaction recommendations from the PCLIA prior to posting and return to PCA.

PCA must:

The E-Government Act of 2002 requires redactions, as allowed by FOIA. The Disclosure Analyst must use available FOIA exemptions to redact information from the PCLIA.

If a business owner believes that their PCLIA is exempt in its entirety from being posted to IRS.gov, the business owner will be directed to provide the authority for not posting and work with the Office of Disclosure to resolve the matter. Office of Disclosure may require a ruling from the Office of Chief Counsel. However, if the information is discloseable per FOIA, PCA will be required to post the PCLIA to IRS.gov, and will work with the business owner and Disclosure to determine if a summary of the PCLIA would be allowed.

An expired PCLIA must be updated to reflect how changes may affect the sensitive information in a system, contractor system, M365, RPA, AI, survey, or social media.

A PCLTA questionnaire is used to determine if a new PCLIA is needed. For more information, see the section PCLTA in this IRM (IRM 10.5.2.2.4, Privacy and Civil Liberties Threshold Assessment (PCLTA).

If an updated or amended PCLIA is approved prior to the 3-year expiration date, the previous PCLIA is superseded as it has been replaced with a newer version.

It is the responsibility of the SO, project owner and the SME to update a PCLIA before the PCLIA expires. PCA will contact the SO, project owner and the SME 90 days prior to the expiration date giving notification that a new PCLIA is due. Two more attempts will be made at 60 days (second notice) and 30 days (third and final notice) prior to PCLIA expiration.

Because the PCLIA process could take up to 30 business days (preparation, review, and approval), the SO, project owner and SME must be mindful of the time frames needed to complete the PCLIA and remain compliant with the E-Government Act of 2002. The new approved PCLIA will replace the expired PCLIA, restarting the 3-year cycle.

A PCLTA questionnaire is required for systems, contractor systems, M365, RPA, AI, surveys, and social media sites that have been retired. For systems The Office of Privacy Review will work with the As-Built Architecture (ABA) to identify retired systems. For more information, see IRM 10.5.2.2.9.2 Reconciliation with As-Built Architecture (ABA). The retired PCLIA will be stored in PIAMS for the appropriate retention period.

A system is included in the definition of Information Technology (IT). The Clinger-Cohen Act of 1996 describes IT as any equipment, software or interconnected system or subsystem that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information.

A System PCLIA is a process analyzing how SBU Data (including PII and tax information) are used, collected, received, displayed, stored, maintained, protected, shared, managed, and disposed.

A PCLIA should be submitted to The Office of Privacy Review in the Initial Production Deployment process of OneSDLC. The PCLIA helps identify privacy or civil liberties issues early on, thereby facilitating the development of technical solutions necessary to remediate and/or mitigate any potential privacy and civil liberties concerns.

Submit a System PCLIA at least 30 business days prior to the date needed for releases or to begin production and use of the PII contained in the system.

Include supporting documents with the System PCLIA to corroborate your answers. For information about the supporting documents see the PIAMS User Guide. Projects must follow the Enterprise Architecture (EA) IRS Privacy Requirements in IRM 2.15.1, Enterprise Architecture (EA) Overview which are based on mandated NIST SP privacy controls.

For more information about PCLIA requirements and the PCLIA process (including how to determine if a new or updated PCLIA is required), refer to the following IRM references:

A system owned by a contractor with IRS data has the same PCLIA requirements as an IRS owned system.

For information about System PCLIAs see IRM 10.5.2.2.9, System PCLIAs.

For more information about PCLIA requirements and the PCLIA process (including how to determine if a new or updated PCLIA is required), refer to the following IRM references:

Dedicated environments and visualization tools are information technology and an M365 PCLIA is used to analyze privacy risk in dedicated environments and the use of visualization tools.

An M365 PCLIA is a process analyzing how SBU Data (including PII and tax information) are used, collected, received, displayed, stored, maintained, protected, shared, managed, and disposed.

Submit a M365 PCLIA at least 30 business days prior to the date needed for milestones, releases, or to begin production and use of the PII contained in the system.

Include supporting documents with the M365 PCLIA. For information about the supporting documents see the PIAMS User Guide.

For more information about PCLIA requirements and the PCLIA process (including how to determine if a new or updated PCLIA is required), refer to the following IRM references:

Robotic Process Automation (RPA) is a software technology that makes it easy to build, deploy, and manage software robots that emulate human actions interacting with digital systems and software. Software robots can do things like understand what’s on a screen, complete the right keystrokes, navigate systems, identify and extract data, and perform a wide range of defined actions. RPAs can have an AI or machine learning component.

There are two types of RPAs used by the IRS.

An RPA PCLIA is a process analyzing how SBU Data (including PII and tax information) are used, collected, received, displayed, stored, maintained, protected, shared, managed, and disposed.

Submit an RPA PCLIA at least 30 business days prior to the date of deployment, releases, and use of the PII by the RPA.

Include supporting documents with the RPA PCLIA. For information about the supporting documents see the PIAMS User Guide.

An RPA PCLIA may be completed to cover multiple RPAs if their uses are for the same business unit and system and use the same SBU Data, PII, and FTI.

For more information about PCLIA requirements and the PCLIA process (including how to determine if a new or updated PCLIA is required), refer to the following IRM references:

Artificial Intelligence is information technology.

Examples of AI or associated technology include, but are not limited to:

For an overarching IRS AI policy and definition, refer to the internal Enterprise AI site.

An AI PCLIA is a process analyzing how SBU Data (including PII and tax information) is used, collected, received, displayed, stored, maintained, protected, shared, managed, and disposed of by AI.

Submit an AI PCLIA at least 30 business days prior to the date of deployment, releases, and use of the PII by AI.

Include supporting documents with the AI PCLIA. For information about the supporting documents see the PIAMS User Guide.

For more information about PCLIA requirements and the PCLIA process (including how to determine if a new or updated PCLIA is required), refer to the following IRM references:

For privacy policy on AI, refer to IRM 10.5.1.6.22, Artificial Intelligence (AI), and its subsections.

IRS developed unique PCLIAs, referred to as "adaptive," to address the specific issues and privacy concerns for non-conventional data and collaborative environments that were not addressed in the general PCLIA used for systems. Doing this complies with OMB M-03-22 and M-10-23, as well as the Title II Section 208 of the E-Government Act of 2002. Other adaptive PCLIAs may be developed in the future to proactively focus on privacy concerns identified with other uses of non-conventional data or collaborative environments. Currently, the IRS utilizes two adaptive PCLIAs to cover surveys and social media sites.

A System PCLIA that addresses all issues included in an adaptive PCLIA usually overrides the need for the adaptive PCLIA.

The Federal Information Security Modernization Act (FISMA) requires agencies to conduct periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices (including management, operational, and technical controls). As such, agencies are required to certify and accredit each system prior to it being placed in the production environment, as well as every three years or when a significant change has occurred. The Privacy and Civil Liberties Impact Assessment (PCLIA) is one of these artifacts.

Information Technology Cybersecurity owns the Enterprise FISMA Dashboard, an Enterprise level report that provides system-by-system and Business Unit level views of the state of FISMA compliance for the current FISMA year. System level data includes the current status of FISMA artifacts to include the PCLIA, along with multiple other areas. The primary data source for the Dashboard is the Treasury FISMA Inventory Management System (TFIMS), which is supplemented by additional sources as necessary. The Dashboard is used by senior management to proactively manage the progress of key FISMA metrics.

The FISMA cycle begins on July 1 of each year, and ends on June 30 of the following year.

PCA is responsible for uploading current FISMA PCLIAs to TFIMS. PCA contacts system owners and SMEs of the requirement to prepare a new PCLIA 90 days prior to PCLIA expiration.

Once PCLIAs are approved by PCA, expired PCLIAs are archived and current PCLIAs uploaded. The FISMA goal for PCLIAs is 90% compliance.

Pursuant to Section 803 of the Implementing Recommendations of the 9/11 Commission Act of 2007 (Public Law 110-53), Treasury requires each bureau, including IRS, to provide a privacy and civil liberties report on recent activities on a periodic basis.

These reports may be requested bi-annually and generally include the following information:

The reports from each Treasury bureau are rolled into one Agency report and published on the Treasury public web site:
Public Law 110-53-Implementing Recommendations of the 9/11 Commission Act of 2007.

The Privacy Act of 1974 (5 U.S.C. 552a(e)(10))requires each agency to establish appropriate administrative, technical, and physical safeguards to ensure the security and confidentiality of records and to protect against any anticipated threats or hazards to their security or integrity which could result in substantial harm, embarrassment, inconvenience, or unfairness to any individual on whom information is maintained.

OMB M-17-12 sets forth the policy for Federal agencies to prepare for and respond to a breach of personally identifiable information (PII). It includes a framework for assessing and mitigating the risk of harm to individuals potentially affected by a breach, as well as guidance on whether and how to provide notification and services to those individuals. This Memorandum is intended to promote consistency in the way agencies prepare for and respond to a breach by requiring common standards and processes.

OMB M-16-24 establishes the Senior Agency Official for Privacy (SAOP) role to ensure the agency complies with applicable privacy requirements in law, regulation, and policy.

OMB M-06-15 states the agency’s Senior Official for Privacy should conduct a review of the policies and processes and take corrective action as appropriate to ensure the agency has adequate safeguards to prevent the intentional or negligent misuse of, or unauthorized access to, PII. This review shall address all administrative, technical, and physical means used by the agency to control such information, including but not limited to procedures and restrictions on the use or removal of personally identifiable information beyond agency premises or control.

OMB M-05-08 – Senior Agency Official for Privacy (SAOP) designation: Agencies have the authority to conduct periodic reviews (e.g., as part of their annual FISMA reviews) to promptly identify deficiencies, weaknesses, or risks. When compliance issues are identified, agencies must take appropriate steps to remedy them.

OMB Circular A-130 policy for the planning, budgeting, governance, acquisition, and management of Federal information, personnel, equipment, funds, IT resources, and supporting infrastructure and services. The appendices to this Circular also include responsibilities for protecting Federal information resources and managing personally identifiable information (PII).

OMB Circular A-108 – agency responsibilities for implementing the review, reporting, and publication requirements of the Privacy Act of 1974 (“the Privacy Act”), and related OMB policy.

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 AU-3, AU-6, CA-7 – To promote accountability, organizations identify and address gaps in privacy compliance, management, operational, and technical controls by conducting regular assessments (e.g., internal risk assessments).

IRM 10.5.1 - outlines additional authorities and roles and responsibilities for executives, managers, and employees regarding BPRAs.

IRM 10.5.2.4 outlines the BPRA PII Risk Assessment process, authority, privacy compliance and roles and responsibilities.

For more information about authorities and resources, refer to the BPRA site.

Privacy Compliance and Assurance (PCA) conducts BPRAs on IRS processes to determine how IRS handles and safeguards PII throughout a specific process.

BPRAs are not normally conducted during the data lifecycle stages of design, but are conducted after deployment or in the operations and maintenance stages of existing processes.

The criteria are designed to identify diverse processes enabling the BPRA team to obtain a broader view of how IRS protects PII across the IRS landscape.

PGLD Executive responsibilities include:

PGLD Associate Director, PCA responsibilities include:

PGLD Chief, Privacy Risk responsibilities include:

BPRA Coordinator responsibilities include:

PGLD BPRA Case Lead responsibilities include:

PGLD BPRA Support Analysts (Internal PGLD) responsibilities include:

Business Process Stakeholders responsibilities include:

PGLD Enterprise Risk Management (ERM) Liaison responsibilities include:

Vulnerability Owner responsibilities include:

Authorizing Official (AO) or approving official (who may be different from the Vulnerability Owner) responsibilities include:

For more information on BPRAs and the related procedures, refer to the BPRA site.

PCA conducts BPRAs on processes, as opposed to systems. PCA assesses privacy risks in systems through PCLIA and SORN review.

The BPRA team must apply criteria to identify processes for potential BPRAs in the upcoming year.

The BPRA categories and what they entail are:

In addition to the BPRAs that PCA plans for annually, circumstances may warrant ad hoc BPRAs. These circumstances include: executive requests, high profile breaches, emerging trends, etc.

The BPRA team must review the work components, assign Vulnerability Risk levels to the relevant privacy risks, and identify Vulnerability Owners.

The vulnerability owner must respond to assigned vulnerabilities within the time frame associated with the vulnerability’s assigned risk level.

PCA must report to PGLD and BU executives and other impacted management quarterly regarding the important activities.

For more information about the response process or reports, send email to *Privacy Review or refer to the BPRA site.

E-Government Act of 2002.

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Federal Information Systems and Organizations, September 2020.

M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002.

OMB A-130, Management of Federal Information Resources.

TD 25-07, Privacy and Civil Liberties Impact Assessment.

Compliance:

Treasury issues a data call every odd year (i.e., 2013, 2015, etc.). For more information, see the following Treasury PII Holdings Report Program Requirements section (IRM 10.5.2.5.3), Treasury PII Holdings Report Program Requirements.

Privacy analyst coordinates and submits the PII holding report to Treasury.

PGLD leadership reviews and approves final submission.

Business Unit Security Program Managment Office (SPMO) reviews prior PII holding report and provides updated or new information.

Treasury’s PII Holdings application was developed by the Office of Privacy, Transparency, and Records (OPTR) with help from the Chief Information Officer (CIO). The application acts as a library of all of the Department of Treasury’s PII holdings. It describes the different data elements and uses of all the Treasury systems that hold PII. The application itself does not contain the PII maintained in the systems documented.

Treasury is mandated by Congress to maintain a listing of all systems that contain personally identifiable information (PII). The Treasury data call requests information for some specific areas; however, the information requested may vary from data call to data call:

The IRS must provide responses to Treasury for each applicable system. Most of these answers may be gleaned from the systems PCLIAs with additional support from Disclosure and the Business Unit SPMOs.

The general program requirements are to: