Federal housing law
0926 Publ 4812 (PDF)
Federal housing law as enacted — verbatim and citable.
- Edition
- 2026-10-03
- Last updated
- 2026-10-04
- Jurisdiction
- United States
Official source: IRS Forms, Instructions & Publications (https://www.irs.gov/pub/irs-pdf/p4812.pdf), retrieved 2026-10-03. U.S. Government work (17 U.S.C. § 105).
***This Publication Pertains to IT Assets and Information Systems Owned, Managed, or Operated by IRS Contractors ***
Publication 4812 (Rev. 9-2026) Catalog Number 54170T Department of the Treasury Internal Revenue Service www.irs.gov
Table of Contents 1.0 Background 12 2.0 Purpose 13 3.0 Scope 14¶
3.1. IRS Security and Privacy Controls Structure ________________________________________ 14 3.1.1 IRS Publication 4812 Applicability_____________________________________________________ 14
4.0 SBU Data 16¶
4.1 Returns and Return Information ___________________________________________________ 17
4.2 Law Enforcement Sensitive (LES) Information _______________________________________ 17
4.3 Employee Information ___________________________________________________________ 17
4.4 Personally Identifiable Information (PII) ____________________________________________ 17
4.5 Other Protected Information ______________________________________________________ 19
5.0 Information and Information Systems 20 6.0 Cloud Computing 21 7.0 Artificial…¶
12.1 IRS __________________________________________________________________________ 26 12.1.1 Contracting Officer (CO) ___________________________________________________________ 26 12.1.2 Contracting Officer’s Representative (COR) ___________________________________________ 26 12.1.3 Contractor Security Control Assessment Team (CSCA) __________________________________ 27 12.1.4 Privacy___________________________________________________________________________ 28 12.1.5 Facilities Management and Security Services (FMSS) ____________________________________ 28 12.1.6 Personnel Security (PS) _____________________________________________________________ 28
12.2 Contractor ____________________________________________________________________ 29 12.2.1 Contractor Point of Contact (POC) ___________________________________________________ 29 12.2.2 Contractor Personnel _______________________________________________________________ 30
12.3 Contractor Program Requirements _______________________________________________ 30 12.3.1 Contractor Security Policies and Procedures ____________________________________________ 30 12.3.2 Contractor Investigative Requirements ________________________________________________ 31 12.3.3 Contractor Training ________________________________________________________________ 31 12.3.4 Contractor Information Protection ____________________________________________________ 31 12.3.5 Rules of Behavior __________________________________________________________________ 32
13.0 Contractor Security Assessments 33¶
13.1 Overview _____________________________________________________________________ 33
2
13.2 Types of Assessments ___________________________________________________________ 33
13.3 Notice of Assessments ___________________________________________________________ 34
13.4 Security Control Levels _________________________________________________________ 34 13.4.1 Contractor Security Assessment ______________________________________________________ 34 13.4.2 Cyber Supply Chain Risk Management (C-SCRM) ______________________________________ 34 13.4.3 Privacy___________________________________________________________________________ 35
13.5 Scope of Assessments ___________________________________________________________ 35
13.5.1 Collaboration on Contractor Security Assessment __________________________________ 36 13.5.1.1 Before the Assessment _____________________________________________________________ 36 13.5.1.2 At the Time of or During the Assessment _____________________________________________ 36 13.5.1.3 After the Assessment ______________________________________________________________ 36
13.5.2 Continuous Monitoring of Security and Privacy Controls ____________________________ 37
14.0 Privacy and Information Protection 38¶
14.1 Security Categorization __________________________________________________________ 38
15.0 Security and Privacy Control Organization and Structure 39¶
Table 1: NIST Families of Security and Privacy Controls ______________________________________ 39
16.0 Access Control (AC) 40¶
16.1 AC-1 Access Control Policy and Procedures ________________________________________ 40
16.2 AC-2 Account Management ______________________________________________________ 40
16.3 AC-3 Access Enforcement _______________________________________________________ 42
16.4 AC-4 Information Flow Enforcement ______________________________________________ 42
16.5 AC-5 Separation of Duties _______________________________________________________ 42
16.6 AC-6 Least Privilege ____________________________________________________________ 43
16.7 AC-7 Unsuccessful Login Attempts ________________________________________________ 44
16.8 AC-8 System Use Notification ____________________________________________________ 44
16.9 AC-11 Device Lock _____________________________________________________________ 45
16.10 AC-12 Session Termination _____________________________________________________ 45
16.11 AC-14 Permitted Actions without Identification or Authentication _____________________ 45
16.12 AC-17 Remote Access __________________________________________________________ 46
16.13 AC-18 Wireless Access _________________________________________________________ 47
16.14 AC-19 Access Control for Mobile Devices _________________________________________ 47
16.15 AC-20 Use of External Systems __________________________________________________ 49
16.16 AC-21 Information Sharing _____________________________________________________ 50
16.17 AC-22 Publicly Accessible Content _______________________________________________ 51
16.18 AC-23 Data Mining Protection – C-SCRM Control _________________________________ 51
17.0 Awareness & Training (AT) 51¶
17.1 AT-1 Awareness & Training Policy and Procedure ___________________________________ 51
3
17.2 AT-2 Awareness Training _______________________________________________________ 52
17.3 AT-3 Role Based Training _______________________________________________________ 52
17.4 AT-4 Training Records __________________________________________________________ 54
18.0 Audit and Accountability (AU) 54¶
18.1 AU-1 Audit and Accountability Policy and Procedures ________________________________ 54
18.2 AU-2 Event Logging ____________________________________________________________ 55 Table 2: Required Log Events _____________________________________________________________ 55
18.3 AU-3 Content of Audit Records ___________________________________________________ 57
18.4 AU-4 Audit Log Storage Capacity _________________________________________________ 58
18.5 AU-5 Response to Audit Logging Processing Failures _________________________________ 58
18.6 AU-6 Audit Record Review, Analysis, and Reporting _________________________________ 58
18.7 AU-7 Audit Record Reduction and Report Generation ________________________________ 59
18.8 AU-8 Time Stamps _____________________________________________________________ 59
18.9 AU-9 Protection of Audit Information ______________________________________________ 59
18.10 AU-11 Audit Record Retention __________________________________________________ 60
18.11 AU-12 Audit Record Generation __________________________________________________ 60
1 8.12 AU-13 Monitoring for Information Disclosure (C -SCRM Control) _____________________ 61
1 8.13 AU-14 Session Audit (C -SCRM Control) __________________________________________ 61
18.14 AU-16 Cross Organization Audit Logging | Sharing of Audit Information (C-SCRM Control) __________________________________________________________________________ 61
20.0 Configuration Management (CM) 66¶
20.1 CM-1 Configuration Management Policy and Procedures _____________________________ 66
20.2 CM-2 Baseline Configuration_____________________________________________________ 67
20.3 CM-3 Configuration Change Control ______________________________________________ 68
20.4 CM-4 Impact Analysis __________________________________________________________ 68
20.5 CM-5 Access Restrictions for Change ______________________________________________ 69
20.6 CM-6 Configuration Settings _____________________________________________________ 69
4
20.7 CM-7 Least Functionality ________________________________________________________ 70
20.8 CM-8 System Component Inventory _______________________________________________ 71 20.8.1 Notification of Significant Changes ___________________________________________________ 72
20.9 CM-9 Configuration Management Plan ____________________________________________ 73
20.10 CM-10 Software Usage Restrictions ______________________________________________ 73
20.11 CM-11 User-Installed Software __________________________________________________ 74
20.12 CM-12 Information Location ____________________________________________________ 75
21.0 Contingency Planning (CP) 75¶
21.1 CP-1 Contingency Planning Policy and Procedures ___________________________________ 75
21.2 CP-2 Contingency Plan __________________________________________________________ 76 21.2.1 CP-2(7) Contingency Plan | Coordinate with External Service Providers (C-SCRM Control) ____ 77
21.3 CP-3 Contingency Training ______________________________________________________ 77
21.4 CP-4 Contingency Plan Testing ___________________________________________________ 77
21.5 CP-6 Alternate Storage Site ______________________________________________________ 78
21.6 CP-7 Alternate Processing Site ___________________________________________________ 79 21.6.1 Contractor Telework Requirements ___________________________________________________ 79
21.7 CP-8 Telecommunications Services ________________________________________________ 80
21.8 CP-9 System Backup ____________________________________________________________ 80
21.9 CP-10 System Recovery and Reconstitution _________________________________________ 81
22.0 Identification and Authentication (IA) 82¶
22.1 IA-1 Identification and Authentication Policy and Procedures __________________________ 82
22.2 IA-2 Identification and Authentication (Organizational Users)__________________________ 82
22.3 IA-3 Device Identification and Authentication _______________________________________ 83
22.4 IA-4 Identifier Management _____________________________________________________ 83
22.5 IA-5 Authenticator Management __________________________________________________ 84
22.6 IA-6 Authenticator Feedback _____________________________________________________ 86
22.7 IA-7 Cryptographic Module Authentication _________________________________________ 86
22.8 IA-8 Identification and Authentication (Non-Organizational Users) _____________________ 86
22.9 IA-9 Service Identification and Authentication (C-SCRM Control) _____________________ 86
23.0 Incident Response (IR) 87¶
23.1 IR-1 Incident Response Policy and Procedures ______________________________________ 87
23.2 IR-2 Incident Response Training __________________________________________________ 88
23.3 IR-3 Incident Response Testing ___________________________________________________ 88
23.4 IR-4 Incident Handling __________________________________________________________ 88 Table 3: Examples of Security and Privacy Incidents __________________________________________ 90 23.4.1 IR-4 (10) Incident Handling | Supply Chain Coordination (C-SCRM Control) ________________ 90
23.5 IR-5 Incident Monitoring ________________________________________________________ 90
5
23.6 IR-6 Incident Reporting _________________________________________________________ 91 23.6.1 IR-6 (3) Incident Reporting | Supply Chain Coordination (C-SCRM Control) ________________ 92
23.7 IR-7 Incident Response Assistance ________________________________________________ 92 23.7.1 IR-7 (2) Incident Response Assistance | Coordination with External Providers (C-SCRM Control) _______________________________________________________________________________ 92
23.8 IR-8 Incident Response Plan _____________________________________________________ 92
23.9 IR-9 Information Spillage Response (C-SCRM Control) ______________________________ 93
24.0 Maintenance (MA) 94¶
24.1 MA-1 Maintenance Policy and Procedures __________________________________________ 94
24.2 MA-2 Controlled Maintenance ___________________________________________________ 95
24.3 MA-3 Maintenance Tools ________________________________________________________ 96
24.4 MA-4 Non-Local Maintenance ____________________________________________________ 96
24.5 MA-5 Maintenance Personnel ____________________________________________________ 97
24.6 MA-6 Timely Maintenance_______________________________________________________ 97
25.0 Media Protection (MP) 97¶
25.1 MP-1 Media Protection Policy and Procedures ______________________________________ 98 25.1.1 MP-1 Return or sanitization/destruction of hard and softcopy media at the End of Performance, under the Contract. ______________________________________________________________________ 98
25.2 MP-2 Media Access _____________________________________________________________ 99
25.3 MP-3 Media Marking __________________________________________________________ 100
25.4 MP-4 Media Storage ___________________________________________________________ 100
25.5 MP-5 Media Transport _________________________________________________________ 101
25.6 MP-6 Media Sanitization _______________________________________________________ 101
25.7 MP-7 Media Use ______________________________________________________________ 105
26.0 Physical and Environmental Protection (PE) 105¶
26.1 PE-1 Physical and Environmental Protection _______________________________________ 106 26.1.1 Physical Security Program Principles ________________________________________________ 106
26.2 PE-2 Physical Access Authorization ______________________________________________ 107 26.2.1 Physical Access Credential Management ______________________________________________ 107 26.2.2 Key and Combination Control ______________________________________________________ 108
26.3 PE-3 Physical Access Control ____________________________________________________ 109 26.3.1 Two-Barrier Physical Protection Principle ____________________________________________ 109 26.3.2 Physical Security of Information Systems and Media ___________________________________ 109 26.3.3 Restricting Access _________________________________________________________________ 110 26.3.4 Locked Containers ________________________________________________________________ 110 26.3.5 Security Containers _______________________________________________________________ 111 26.3.6 Locks and Key Management ________________________________________________________ 111 26.3.7 Safes and Vaults __________________________________________________________________ 112 26.3.8 Secured Perimeters and Secured Rooms ______________________________________________ 112 26.3.9 Limited Access Areas ______________________________________________________________ 113 26.3.10 Locking Systems for Secure and Limited Areas _______________________________________ 114 26.3.11 Exterior Physical Barriers _________________________________________________________ 114 26.3.12 Inspection Criteria _______________________________________________________________ 115
6
26.4 PE-4 Access Control for Transmission Medium _____________________________________ 116 26.4.1 Telecommunications Infrastructure Protection ________________________________________ 116 26.4.2 Transporting IRS Material _________________________________________________________ 117
26.5 PE-5 Access Control for Output Devices ___________________________________________ 118 26.5.1 Physical Protection of Output Devices ________________________________________________ 118
26.6 PE-6 Monitoring Physical Access_________________________________________________ 118 26.6.1 Physical Intrusion Detection Systems _________________________________________________ 119 26.6.2 Video Surveillance Systems (VSS) ___________________________________________________ 119 26.6.3 Mail Processing Surveillance ________________________________________________________ 122 26.6.4 Monitoring Private Collection Agencies (PCA) _________________________________________ 122
26.7 PE-8 Visitor Access Records ____________________________________________________ 123 26.7.1 Visitor Management Procedures ____________________________________________________ 123
26.8 PE-9 Power Equipment and Cabling ______________________________________________ 124 26.8.1 Utility Protection _________________________________________________________________ 124 26.8.2 Data Center Utility Protection ______________________________________________________ 124
26.9 PE-10 Emergency Shutoff ______________________________________________________ 124 26.9.1 Emergency Shutoff Engineering Requirements ________________________________________ 125
26.10 PE-11 Emergency Power ______________________________________________________ 125
26.11 PE-12 Emergency Lighting ____________________________________________________ 125 26.11.1 Emergency Lighting Requirements _________________________________________________ 125
26.12 PE-13 Fire Protection _________________________________________________________ 125 26.12.1 Fire Detection and Suppression Engineering __________________________________________ 126 26.12.2 Computer Room and Data Center Fire/Environmental Protections _______________________ 126
26.13 PE-14 Environmental Controls _________________________________________________ 128
26.14 PE-15 Water Damage Protection ________________________________________________ 128
26.15 PE-16 Delivery and Removal ___________________________________________________ 128 26.15.1 Mail Processing Security __________________________________________________________ 128
26.16 PE-17 Alternate Work Site _____________________________________________________ 128
26.17 PE-23 Facility Location (C-SCRM Control) _______________________________________ 130
26.18 Data Center Controls _________________________________________________________ 130 Data Center Fire/Environmental Conditions ___________________________________________________________________ 131
27.0 Planning (PL) 133¶
27.1 PL-1 Planning Policy and Procedures _____________________________________________ 133
27.2 PL-2 System Security and Privacy Plans ___________________________________________ 133
27.3 PL-4 Rules of Behavior _________________________________________________________ 135
27.4 PL-8 Security and Privacy Architectures __________________________________________ 136
28.0 Program Management (PM) 136¶
28.1 PM-4 Plan of Action and Milestones (POA&M) Process______________________________ 136
28.2 PM-5 Inventory of Personally Identifiable Information ______________________________ 137
28.3 PM-9 Risk Management Strategy ________________________________________________ 137
28.4 PM-18 Privacy Program Plan ___________________________________________________ 137
7
28.5 PM-19 Privacy Program Leadership Role _________________________________________ 138
28.6 PM-20 Dissemination of Privacy Program Information ______________________________ 138
28.7 PM-21 Accounting of Disclosures ________________________________________________ 138
28.8 PM-22 Personally Identifiable Information Quality Management ______________________ 138
28.9 PM-24 Program Management — Data Integrity Board ______________________________ 139
28.10 PM-25 Minimization of PII Used in Testing, Training, and Research __________________ 139
28.11 PM-26 Complaint Management_________________________________________________ 139
28.12 PM-27 Privacy Reporting ______________________________________________________ 140
28.13 PM-28 Risk Framing _________________________________________________________ 140
28.14 PM-31 Program Management — Continuous Monitoring Strategy ___________________ 140
29.0 Personnel Security (PS) 140¶
29.1 PS-1 Personnel Security Policy and Procedures _____________________________________ 140
29.2 PS-2 Position Risk Designation __________________________________________________ 141
29.3 PS-3 Personnel Screening _______________________________________________________ 141 29.3.1 PS-3 Eligibility ___________________________________________________________________ 142 29.3.2 PS-3 Suitability ___________________________________________________________________ 142
29.4 PS-4 Personnel Termination _____________________________________________________ 143
29.5 PS-5 Personnel Transfer ________________________________________________________ 144
29.6 PS-6 Access Agreements ________________________________________________________ 144
29.7 PS-7 External Personnel Security ________________________________________________ 145
29.8 PS-8 Personnel Sanctions _______________________________________________________ 145
30.0 PII Processing and Transparency (PT) 145¶
30.1 PT-1 PII Processing and Transparency Policy and Procedures ________________________ 145
30.2 PT-2 Authority to Process PII ___________________________________________________ 146
30.3 PT-3 PII Processing Purposes ___________________________________________________ 146
30.4 PT-4 Consent _________________________________________________________________ 147
30.5 PT-5 Privacy Notice ___________________________________________________________ 147
30.6 PT-6 System of Records Notice __________________________________________________ 147
30.7 PT-7 PII - Social Security Numbers (SSN) _________________________________________ 148
30.8 PT-8 Computer Matching Requirements __________________________________________ 148
31.0 Risk Assessment (RA) 148¶
31.1 RA-1 Risk Assessment Policy and Procedures ______________________________________ 149
31.2 RA-2 Security Categorization ___________________________________________________ 149
31.3 RA-3 Risk Assessment _________________________________________________________ 149
31.4 RA-5 Vulnerability Monitoring and Scanning ______________________________________ 150
31.5 RA-8 Risk Assessment – Privacy Impact Assessments _______________________________ 153
8
31.6 RA-9 Critically Analysis (C-SCRM Control) _______________________________________ 153
31.7 RA-10 Threat Hunting _________________________________________________________ 154
32.0 System and Services Acquisition (SA) 154¶
32.1 SA-1 System and Services Acquisition Policy and Procedures _________________________ 155
32.2 SA-2 Allocation of Resources ____________________________________________________ 155
32.3 SA-3 System Development Life Cycle (SDLC) ______________________________________ 156
32.4 SA-4 Acquisition Process _______________________________________________________ 156
32.5 SA-5 System Documentation ____________________________________________________ 158
32.6 SA-8 Security and Privacy Engineering Principles ___________________________________ 159
32.7 SA-9 External System Services __________________________________________________ 160
32.8 SA-10 Developer Configuration Management ______________________________________ 161
32.9 SA-11 Developer Testing and Evaluation __________________________________________ 161
32.10 SA-15 Development Process, Standards, and Tools _________________________________ 162
32.11 SA-21 Developer Screening (C-SCRM Control) ___________________________________ 163
32.12 SA-22 Unsupported System Components _________________________________________ 163 32.12.1 Open-Source Software ____________________________________________________________ 163
33.0 System and Communications Protection (SC) 164¶
33.1 SC-1 System and Communications Protection Policy and Procedures ___________________ 164
33.2 SC-2 Separation of System and User Functionality __________________________________ 164
33.3 SC-4 Information in Shared System Resources _____________________________________ 165
33.4 SC-5 Denial-of-Service (DoS) Protection ___________________________________________ 165
33.5 SC-7 Boundary Protection ______________________________________________________ 166 33.5.1 SC-7 (13) Boundary Protection | Isolation of Security Tools, Mechanisms, and Support Components (C-SCRM Control) __________________________________________________________ 168
33.6 SC-8 Transmission Confidentiality and Integrity ____________________________________ 168
33.7 SC-10 Network Disconnect ______________________________________________________ 169
33.8 SC-12 Cryptographic Key Establishment and Management ___________________________ 169
33.9 SC-13 Cryptography Protection__________________________________________________ 170
33.10 SC-15 Collaborative Computing Devices and Applications ___________________________ 170
33.11 SC-17 Public Key Infrastructure (PKI) Certificates ________________________________ 171
33.12 SC-18 Mobile Code ___________________________________________________________ 171
33.13 SC-20 Secure Name/Address Resolution Services (Authoritative Source) _______________ 172
33.14 SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) _______ 173
33.15 SC-22 Architecture and Provisioning for Name/Address Resolution Service ____________ 173
33.16 SC-23 Session Authenticity _____________________________________________________ 174
33.17 SC-28 Protection of Information at Rest __________________________________________ 174
9
33.18 SC-36 Distributed Processing and Storage (C-SCRM Control) _______________________ 175
33.19 SC-39 Process Isolation ________________________________________________________ 175
34.0 System and Information Integrity (SI) 175¶
34.1 SI-1 System and Information Integrity Policy and Procedures ________________________ 176
34.2 SI-2 Flaw Remediation _________________________________________________________ 176
34.3 SI-3 Malicious Code Protection __________________________________________________ 177 34.3.1 Email Security ___________________________________________________________________ 178
34.4 SI-4 System Monitoring ________________________________________________________ 179
34.5 SI-5 Security Alerts, Advisories, and Directives _____________________________________ 180
34.6 SI-7 Software, Firmware, and Information Integrity _________________________________ 180
34.7 SI-8 Spam Protection __________________________________________________________ 181
34.8 SI-10 Information Input Validation ______________________________________________ 182
34.9 SI-11 Error Handling __________________________________________________________ 182
34.10 SI-12 Information Management, Retention, and Information Disposal __________________ 182
34.11 SI-16 Memory Protection ______________________________________________________ 183
34.12 SI-18 Personally Identifiable Information Quality Operations ________________________ 184
34.13 SI-19 De-Identification ________________________________________________________ 184
34.14 SI-20 Tainting (C-SCRM Control) ______________________________________________ 185
35.0 Supply Chain Risk Management (SR) 185¶
35.1 SR-1 Supply Chain Risk Management Policy and Procedures _________________________ 185
35.2 SR-2 Supply Chain Risk Management Plan ________________________________________ 185
35.3 SR-3 Supply Chain Controls and Processes ________________________________________ 186
35.4 SR-5 Acquisition Strategies, Tools, and Methods ____________________________________ 187
35.5 SR-6 Supplier Assessments and Reviews __________________________________________ 188
35.6 SR-8 Notification Agreements ___________________________________________________ 189
35.7 SR-10 Inspection of Systems or Components _______________________________________ 189
35.8 SR-11 Component Authenticity __________________________________________________ 190
35.9 SR-12 Component Disposal _____________________________________________________ 191
36.0 Termination of Contract 192¶
36.1 Destruction or Return of SBU Data _______________________________________________ 192
39.0 Exhibit 2 - Taxpayer Browsing Protection Act 197¶
39.1 IRC Section 7431 - Civil Damages for Unauthorized Inspection or Disclosure of Returns and Return Information. _______________________________________________________________ 197
39.1.1 Inspection or Disclosure by a Person Who is Not an Employee of the United States Government 197 39.1.2 Damages ________________________________________________________________________ 197 39.1.3 Definitions _______________________________________________________________________ 197
Appendix A: Security Controls 198¶
Table 4: Security Controls Table ____________________________________________________ 198
Appendix B: Acronyms 206 Appendix C: Glossary 211 Appendix D: Reference 225¶
1.0 Background¶
The E-Government Act of 2002 (Public Law 107-347) Title III, Federal Information Security Management Act (FISMA) of 2002, as amended by Federal Information Security Modernization Act of 2014 (Public Law 113-283), requires each agency to provide security and privacy protection for “information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source”. FISMA requires federal agencies to develop and implement policies for information security and privacy oversight of contractors and other users with access to federal information and information systems.
To ensure FISMA compliance, the National Institute of Standards and Technology (NIST) identifies specific security and privacy controls/criteria in NIST Special Publication (SP) 800- 53 Revision 5, Security and Privacy Controls for Federal Information Systems and Organizations. NIST provides a series of recommended security and privacy controls to be employed by agencies and service providers to ensure the confidentiality, integrity, and availability of federal information and information systems and guidelines for effective security controls that support federal operations and assets.
Because of requirements distinct to IRS mission objectives, as well as specific laws or rulings, such as 26 U.S.C § 6103, the Gramm-Leach Bliley (GLB) Act, the Federal Trade Commission (FTC) Financial Privacy Rule and Safeguards Rule, and the Sarbanes-Oxley Act, IRS contractors, their affiliates, subcontractors, and service providers are subject to additional requirements for protecting information and information systems, when appropriate or applicable.
By entering into a contract with the IRS, the contractor agrees to provide site access within 24 hours of receiving notification by the Contracting Officer’s Representative (COR) or Contracting Officer (CO). Failure to allow access is considered a breach of contract terms and conditions, which could result in termination of the contract or assessment of liquidated damages as agreed to within FAR clause 52.211-11 - Liquidated Damages - Supplies, Services, or Research and Development (Sept 2000).
In signing a contract, the contractor agrees to provide the COR an updated Plan of Actions & Milestones (POA&M) monthly for any open findings identified during an on-site or virtual assessment conducted by the CSCA team. Failure to provide a POA&M to demonstrate how the contractor is addressing risks is a breach of contract terms and conditions, which will result in the COR withholding invoice approval until a POA&M is provided.
Refer to CA-5 (Plan of Actions and Milestones) and RA-5 (Vulnerability Monitoring and Scanning) for additional details on POA&Ms and vulnerability scanning reporting requirements.
12
2.0 Purpose¶
This publication establishes the security and privacy requirements that apply to contractors, subcontractors, and their personnel supporting IRS contracts involving the development, operation, maintenance, processing, storage, or transmission of IRS Sensitive But Unclassified (SBU) information or access to IRS information systems. Unless otherwise specified, all requirements assigned to the Contractor also apply to subcontractors and subcontractor information systems supporting the IRS contract.
IRS Publication 4812 is based on the security and privacy control framework defined in NIST Special Publication (SP) 800-53, Revision 5, and has tailored the controls to the IRS contractor environment. While NIST SP 800-53 Rev. 5 provides the Federal baseline for security and privacy controls, this publication establishes the specific requirements contractors must implement to protect IRS SBU.
This publication also defines the framework for implementing, assessing, and maintaining security and privacy controls, including the respective responsibilities of the IRS and contractors throughout the system lifecycle. Consistent with NIST SP 800-53 Rev. 5 and OMB Circular A-130, the objective of these requirements is to ensure that IRS information and information systems are protected with security and privacy safeguards commensurate with organizational risk arising from the unauthorized access, use, disclosure, disruption, modification, or destruction of information.
13
3.0 Scope¶
The requirements in this publication and the security and privacy controls contained hereinafter are based on NIST SP 800-53 Rev. 5.
3.1. IRS Security and Privacy Controls Structure¶
NIST provides Federal agencies the flexibility to apply the privacy and security concepts and principles in NIST SP 800-53 Rev. 5 within the context of, and with due consideration to, each agency’s mission, business functions, and environments of operation.
As part of its information security program , the IRS identifies security and privacy controls for the organization’s information and information systems in IRS Publication 4812 – Contractor Security & Privacy Controls.
3.1.1 IRS Publication 4812 Applicability
IRS Publication 4812 identifies security and privacy controls specific to IRS contractor’s information systems and IT environments. These controls are based on controls established in NIST SP 800-53 Rev. 5. IRS Publication 4812 contains IRS-specific requirements that meet the standard for NIST SP 800-53 Rev. 5, and the security and privacy controls, requirements, and standards described herein are to be used in lieu of the common, at-large security control standards enumerated in NIST SP 800-53 Rev. 5.
IRS Publication 4812 defines basic security and privacy controls and requirements required of contractors, subcontractors, contractor personnel, and subcontractor personnel, in which contractor personnel or subcontractor personnel will either:
Have information systems for tax administration purposes (or provide related services) outside of IRS facilities or outside of the direct control of the Service; and/or
Have access to, compile, process, or store IRS SBU data on their own information systems or that of a subcontractor, or third-party service provider, that use their own information systems (or that of others) and Information, Communication, and Technology (ICT) (as defined in FAR Part 2) to access, compile, process, or store IRS SBU data while working at an IRS owned or controlled facility.
IRS Publication 4812 is incorporated by contract requirements language included in IRS contracts, agreements, and/or task orders (directly or through flow down provisions to subcontractors). IRS IT Security/FISMA requirements language is also included in any solicitations, contracts, or orders (directly or through flow down provisions) for IT acquisitions, which include hardware and/or software, telecommunications software or equipment, and maintenance/service (including consulting services) on any hardware and/or software products. The most up-to-date IRS Publication 4812 is applicable to the contractor and subcontractors and is available on the IRS public website, IRS.gov.
14
As used in this publication, the term “contract” unless specified otherwise, includes contracts, task/delivery/purchase orders, blanket purchase agreements, and interagency agreements in which IRS is the servicing agency and contractor services and resources, equipment, and systems are being used to support the contract, order, or agreement. This publication may also be used and incorporated into interagency agreements in which IRS is the requesting agency and the servicing agency does not have guidelines (or security and privacy controls consistent with NIST SP 800-53 Rev. 5 in place comparable to IRS Publication 4812).
As described in greater detail in subsequent sections, there are three baseline levels of security and privacy controls, Contractor Security Assessment, Cybersecurity Supply Chain Risk Management (C-SCRM), and Privacy. The specific security and privacy controls associated with each control level can be found in IRS Publication 4812 Appendix C. The use of baseline levels of security and privacy controls notwithstanding, the IRS always reserves the right to add additional controls to any given contract, order, or agreement to protect its assets and information based on the work being performed, the environment in which the work is being performed, perceived risks (threats and vulnerabilities), the suitability and effectiveness of existing controls, and other factors, as appropriate, in the best interest of the IRS.
IRS Publication 4812 also describes the framework and general processes for conducting Contractor Security Assessments (CSA’s) to monitor compliance and assess the effectiveness of security and privacy controls applicable to any given contracting action subject to IRS Publication 4812.
15
4.0 SBU Data¶
The IRS defines Sensitive But Unclassified Information (SBU) Data as; “ any information which, if lost, stolen, misused, accessed, or altered without proper authorization, may adversely affect the national interest or the conduct of federal programs (including IRS operations), or the privacy which individuals are entitled under the Privacy Act” (5 U.S.C. 552a).
SBU data includes but is not necessarily limited to:
Federal Tax Information (FTI), Personally Identifiable Information (PII), Protected Health Information (PHI), procurement sensitive information, system vulnerabilities, case selection methodologies, systems information, source code/software developed by the Contractor for the IRS, enforcement procedures, and investigation information.
Furthermore, live data, which is defined as production data in use. Live means that when changing the data, it changes in production. The data may be extracted for testing, development, etc., in which case, it is no longer live. Live data often contains SBU data.
Access to SBU data must be provided on a “need to know” basis. SBU data must never be indiscriminately disseminated, and no person must be given access to (or allowed to retain) more SBU data than is relevant and necessary for performance of their duties, and for which that individual has been authorized to receive because of having been successfully investigated, adjudicated, and trained to receive, and limited to what is strictly necessary to accomplish the intended business purpose and mission.
SBU data must only be released or accessible via access to information systems to those individuals who have been approved for interim/final staff-like access by IRS Personnel Security (see definition of staff-like access in Appendix B). Additionally, they should have a "need to know" to perform the work required under the contract.
SBU must be categorized in one or more of the following groups:
FTI,
Law Enforcement Sensitive (LES) information,
Employee information,
PII, and/or
Other protected information.
16
4.1 Returns and Return Information¶
Returns and return information includes all information covered by § 6103 of the IRC, 26 U.S.C. § 6103. This includes tax returns and return information as defined by IRC, 26 U.S.C. § 6103(b).
4.2 Law Enforcement Sensitive (LES) Information¶
Law enforcement data is often sensitive in nature. This data falls under the data category called Law Enforcement, which includes grand jury, informant, undercover operations information, and procedural guidance.
4.3 Employee Information¶
All employee information covered by the Section 552a of Title 5, United States Code (USC) (5 U.S.C. 552A). Examples include personnel, payroll, job applications, disciplinary actions, performance appraisals, drug tests, health exams, and evaluation data.
4.4 Personally Identifiable Information (PII)¶
As defined in OMB Circular A-130: “Personally Identifiable Information” is information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual.
Since there are many different types of information that can be used to distinguish or trace an individual’s identity, the term PII is broad. To determine whether information is PII, the agency must perform an assessment of the specific risk that an individual can be identified using the information with other information that is linked or linkable to the individual. In performing this assessment, it is important to recognize that information that is not PII can become PII whenever additional information becomes available in any medium and from any source that would make it possible to identify an individual.
Examples and categories of PII may include, but are not limited to the following, when used to distinguish or trace an individual’s identity, or when combined with information that is linked or linkable to an individual:
Name, such as full name, maiden name, mother’s maiden name, alias, or name control (first 4 letters of last name).
Address information, such as street address or email address.
A unique set of numbers or characters assigned to a specific individual, such as:
o Telephone numbers, including mobile, business, and personal numbers.
o SSN or Individual Taxpayer Identification Number (ITIN), including the last 4
digits.
17
o Taxpayer Identification Number (TIN) that identifies an individual, such as an
Employer Identification Number (EIN) for a sole proprietorship or partnership.
o Document Locator Number (DLN) to identify an individual’s record.
o Email or Internet Protocol (IP) address.
o Driver’s license number.
o Passport number.
o Financial account or credit card number.
o Standard Employee Identifier (SEID).
o Automated Integrated Fingerprint Identification System (AIFIS) identifier,
booking, or detention system number.
o Universally Unique Identifier (UUID), a unique random number generated for
each individual taxpayer in the electronic authentication process (eAuth).
o Any other type of identification number or card, including state ID or Alien Card
ID.
Employee and employee information, including personnel files, employment testing materials, medical information, and information concerning reasonable accommodations for disabilities.
Individual tax return information, including Adjusted Gross Income (AGI) or combinations of fields that identify an individual.
Corporate or other business tax return information that identifies an individual, such as an S-Corporation, partnership, or sole proprietorship.
Personal characteristics and data, including:
o Date of birth
o Place of birth
o Age
o Height
o Weight
o Gender
o Hair color
o Eye color
o Race
o Ethnicity
o Scars
o Tattoos
o Distinguishing features
o Religious affiliation
o Sexual orientation
o Gang affiliation
o Photographic image (especially of face or another distinguishing characteristic)
o Biometric information (such as x-rays, fingerprints, retina scan, voice, facial
geometry, DNA)
o Behavior patterns
Asset information, such as Media Access Control (MAC) address, Device ID, or other host-specific persistent static identifier that consistently links to a particular person or small, well-defined group of people.
Descriptions of events or times (information in documents, such as behavior patterns, incident reports, police reports, arrest reports, and medical records).
18
Descriptions of locations, such as Geographic Information System (GIS), Global Positioning System (GPS) data, and electronic bracelet monitoring information.
Information identifying personally owned property, such as vehicle registration number or title number and related information.
4.5 Other Protected Information¶
Other protected information includes any knowledge or facts received or created by or for the IRS in support of IRS work. This includes all information covered by the Trade Secrets Act, the Procurement Integrity Act, and similar statutes. Examples include, but are not limited to:
Records about individuals requiring protection under the Privacy Act.
Information that is not releasable under the Freedom of Information Act (FOIA).
Proprietary data.
Procurement sensitive data, such as vendor contract proposals.
Information, which if modified, destroyed, or disclosed in an unauthorized manner could cause loss of life, loss of property, or funds by unlawful means, violation of personal privacy or civil rights, gaining of an unfair procurement advantage by contractors bidding on government contracts, or disclosure of proprietary information entrusted to the Government.
Information related to the design and development of application source code.
For contractors providing IT services to the IRS, this includes specific IT configurations, where the information system security configurations could identify the state of security of that information system; IP addresses that allow the workstations and servers to be potentially targeted and exploited; and source code that reveals IRS processes that could be exploited to harm IRS programs, employees, or taxpayers.
Security information containing details of serious weaknesses and vulnerabilities associated with specific information systems and/or facilities.
Any information, which if improperly used or disclosed could adversely affect the ability of the agency to accomplish its mission; and
Information that would disclose techniques or procedures within the IRS not necessarily known to the public.
19
5.0 Information and Information Systems¶
Information requires protection whether or not it resides on an information system. Per OMB Circular A-130 (Section 6, Paragraph j), the definition of information is as follows:
The term "information" means any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual forms.
Information System, as defined by OMB Circular A-130, means “a discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual”.
In all instances, security and privacy controls apply to both information and information systems.
20
6.0 Cloud Computing¶
Cloud computing is the delivery of computing services—such as servers, storage, databases, networking, software, and analytics over the internet. This architecture differs from the widely used on premise IT model where the IT resources are physically housed, owned, and operated at contractor facilities by contractors.
A Cloud Service Provider (CSP) is the company offering cloud services (e.g., AWS, Azure), while a Cloud Service Offering (CSO) is the specific product, service, or platform they provide (e.g., AWS GovCloud). CSPs (the vendors) must get their CSOs (the tools) authorized through programs like FedRAMP so that contractors can utilize the CSO. The CSP is responsible for delivering services, they develop security packages, manage the infrastructure, and undergo audits. The CSO is the specific, authorized product or application (SaaS, PaaS, or IaaS). CSOs are evaluated for security, categorized by impact levels (Low, Moderate, High), and listed in the FedRAMP Marketplace.
In the Cloud Computing Model, IT resources are owned and operated by the CSP.
Some benefits of using a CSP include:
Cost savings: No need to buy expensive hardware.
Scalability: Easily increase or decrease resources as needed.
Accessibility: Access services from anywhere with an internet connection.
Reliability: Cloud providers offer backups and redundancy.
Faster deployment: New resources can be provisioned in minutes.
While there are many advantages to cloud computing there are some additional challenges to ensuring IRS SBU is protected in the cloud. The CSCA Team has incorporated language into IRS Publication 4812 to ensure that Contractors and subcontractors utilizing CSP’s have security and privacy controls in place and function properly to protect IRS SBU, PII, and FTI.
Contractors that would like to implement Cloud computing services within their environments that support the IRS must contact the COR who will forward the request to the Contracting Officer and IRS Cybersecurity for review and approval. Contractors must not employ Cloud computing services to support the IRS contract without approval from the Contracting Officer and IRS Cybersecurity.
FTI and PII may only be stored, processed, or handled in FedRAMP Authorized cloud environments operating at the Moderate or High impact level. Contractors must use existing FedRAMP authorized CSO’s unless there is a compelling justification to use a non-FedRAMP authorized alternative CSP. The contractor must work with the COR and IRS Business unit to initiate a (Risk Acceptance Form & tool) RAFT for the contractor to use a non-FedRAMP authorized alternative CS O. The RAFT must be approved by the IRS Business Unit before the contractor can begin utilizing n on-FedRAMP authorized alternative CSP to support the IRS contract.
21
7.0 Artificial Intelligence¶
The term “artificial intelligence” or “AI” is defined in 15 U.S.C. 9401(3) as: “a machinebased system that can, for a given set of human-defined objectives, make predictions, recommendations, or decisions influencing real or virtual environments. Artificial intelligence systems use machine and human-based inputs, to perceive real and virtual environments; abstract such perceptions into models through analysis in an automated manner; and use model inference to formulate options for information or action”.
The contractor must define an AI policy for any design, development, acquisition, or use of AI (hereafter referred to as AI use), whether a web-based online form, Commercial-off-theShelf (COTS) product or service, custom developed contractor tool, or any other use case. This policy applies to associated technologies that may not meet the IRS definition of AI. Examples of AI or associated technologies include:
Generative AI
Predictive AI
Machine Learning (ML)
Large Language Models (LLM)
Voicebots and chatbots
Robotic Process Automation (RPA)
Note: AI capabilities often appear as part of many other tools, applications or COTS products, without expressly being identified as AI.
Use of AI may create new security and privacy risks or exacerbate risks present in other systems. When using AI, contractors must consider the relationship between AI and security and privacy risks, such as collecting more data than is necessary, improper disclosure, misuse, data poisoning and even aspects of incorrect conclusions.
Contractors are strictly prohibited from disclosing Sensitive but Unclassified (SBU), to include PII and Federal Tax Information (FTI) information, to publicly available generative AI tools (e.g., ChatGPT, Google Bard/Gemini, Anthropic Claude). These open tools pose significant risks to data privacy and security, as well as the potential for biased, unpredictable, and malicious behavior. The IRS considers sharing data with such an AI or internet tool as an intentional unauthorized disclosure and data breach. Contractors must not use IRS SBU data (including PII and tax information) to train public AI models.
Contractors are responsible for the information shared when using AI, just as they are responsible for the information shared in a conversation or email. This includes considering how the AI might use the information later.
Many AI models can intake, keep, and reuse data. Under the IRS policies for minimization, minimize the collection, use, retention, and disclosure of data in AI to what is specifically relevant and necessary. The Contractor must take steps to understand how AI might redisclose data and share only what is necessary for your task. When developing an AI model, the
22
contractor must build safeguards that guide users how to minimize data and to prevent improper disclosure.
Contractors and subcontractors that would like to implement AI technologies within their environments that support the IRS must receive approval by the CO before implementing AI. Contractors and subcontractors must not employ AI technologies to support the IRS contract without consultation with IRS Cybersecurity and approval from the Contracting Officer.
8.0 Zero Trust¶
Zero Trust (ZT) is a cybersecurity strategy built on the principle of " never trust, always verify ." Unlike traditional security models that assume users and devices inside a network perimeter can be trusted, Zero Trust assumes that no user, device, application, or network connection should be automatically trusted, regardless of its location. Every access request must be continuously authenticated, authorized, and validated based on identity, device health, location, behavior, and other contextual factors.
The concept emerged in response to modern computing environments where users, applications, and data are distributed across cloud services, remote work locations, mobile devices, and partner networks. In these environments, the traditional network perimeter has become less effective. Zero Trust shifts security controls closer to the resources being protected and focuses on securing access to data, applications, and services rather than securing only the network boundary.
Contractors that process, store, transmit, or otherwise access IRS SBU, PII or FTI shall begin transitioning their security architectures and practices toward Zero Trust principles. Contractors should incorporate Zero Trust capabilities as part of system modernization, technology refreshes, architectural changes, cloud migrations, and other significant changes affecting systems that support the IRS contract. Contractors are not expected to replace existing architecture solely to achieve immediate Zero Trust maturity; however, they are expected to demonstrate measurable progress toward reducing implicit trust and implementing Zero Trust principles as systems and technologies are modernized.
9.0 IPv6¶
Internet Protocol Version 6 (IPv6) is the successor to Internet Protocol Version 4 (IPv4) and provides a substantially expanded address space using 128-bit addressing. In addition to addressing IPv4 address exhaustion, IPv6 improves network scalability, routing efficiency, and support for modern network architectures. IPv6 incorporates features such as Stateless Address Autoconfiguration (SLAAC), Neighbor Discovery Protocol (NDP), and enhanced support for end-to-end connectivity. Public and private sector organizations are transitioning toward IPv6-only network environments to improve operational efficiency, reduce complexity associated with dual-stack implementations, and ensure long-term interoperability.
Contractors that operate information systems that process, store, transmit, or otherwise provide access to IRS SBU, PII or FTI shall incorporate IPv6 considerations into system modernization, network architecture, technology refresh, and lifecycle planning activities.
23
Contractors are not required to immediately transition existing environments to IPv6-only solely to satisfy this requirement. However, contractors should demonstrate measurable progress toward IPv6 adoption and avoid introducing new technologies or architectures that unnecessarily increase dependency on IPv4 where viable IPv6-capable alternatives are available.
10.0 Quantum Computing¶
Quantum computing is a computing paradigm that uses the principles of quantum mechanics to solve certain classes of problems much more efficiently than classical computers. Unlike traditional computers, which process information as binary bits (0 or 1), quantum computers use quantum bits (qubits) that can exist in multiple states simultaneously through superposition. Qubits can also be entangled, allowing them to be correlated in ways that enable highly parallel computation.
While quantum computing has the potential to revolutionize computing and artificial intelligence, it also presents significant cybersecurity challenges because it threatens many of the cryptographic algorithms used to protect today's digital communications and data. The most significant risk posed by quantum computing is its ability to break widely deployed public-key cryptographic algorithms.
Contractors that process, store, transmit, or otherwise protect IRS SBU, PII or FTI shall incorporate Post-Quantum Cryptography (PQC) readiness and cryptographic agility into security architecture, system modernization, technology refresh, and lifecycle planning activities. Contractors shall not replace NIST approved cryptographic mechanisms with experimental or unapproved post-quantum algorithms solely to achieve quantum readiness.
Contractors shall:
Identify systems, applications, protocols, services, and technologies that rely on cryptographic mechanisms to protect IRS SBU, PII and FTI.
Identify systems and technologies that rely on cryptographic algorithms that may be vulnerable to advances in quantum computing.
Incorporate cryptographic agility into new and modernized systems so cryptographic algorithms and protocols can be replaced or upgraded without requiring significant redesign of the system.
Consider support for NIST-standardized post-quantum cryptographic algorithms when acquiring, developing, or modernizing systems, applications, products, and services.
Evaluate vendor and product roadmaps for PQC support when making technology acquisition and lifecycle decisions.
24
12.0 Roles and Responsibilities¶
The following sections define roles and responsibilities in the contractor assessment process.
12.1 IRS¶
12.1.1 Contracting Officer (CO)
Enforces the Government’s rights and remedies for all contractual matters.
Ensures compliance with the terms and conditions of the contract.
Ensures appropriate privacy and security-related clauses and language are included in applicable contracts with coordination from the CSCA Team and the Privacy Team.
Ensures the contractor affords the Government access to the contractor’s facilities, installations, operations, documentation, records, IT systems, and databases to carry out a program of inspection to safeguard against threats and hazards to the security, confidentiality, integrity, and availability of government data.
Employs all rights and remedies available to the Government to ensure contractors correct or mitigate identified security vulnerabilities.
Modifies the contract when risk level requires modification, based upon the CSCA and Privacy Team recommendations.
Assists with reporting and mitigation of incidents as appropriate. (See section 23.6 IR-6 Incident Reporting.)
12.1.2 Contracting Officer’s Representative (COR)
Facilitates CSAs and serves as the liaison between the CSCA Team and the contractor when scheduling CSAs and by being the primary IRS point of contact for the contractor.
Escalates key information to the CO related to contractor risk.
Provides a monthly status of all POA&Ms related to the CSCA, Privacy
and Facilities Management and Security Services (FMSS) Teams.
Furnishes CSCA, Privacy, and FMSS Team documents to the contractor.
Identifies to the contractor, the names of specialized IT security roles and the associated number of required hours for Specialized Security Training (SITs).
Ensures all security awareness, privacy, records management, and physical environment mandatory briefings assigned to each contractor are completed, recorded in the IRS learning system, and within the IRS required timeframe for completion.
Serves as the liaison between Privacy and the contractor. If entering into a data sharing agreement with a contractor, or vendor that involves custody of, or access to IRS-held PII that will be collected, maintained, or disseminated using IT, work with the contractor to complete a Privacy & Civil Liberties Threshold Assessment (PCLTA) to document and identify any additional privacy compliance requirements.
26
A PCLTA can be used to determine whether a full Privacy & Civil Liberties Impact Assessment (PCLIA) is required.
- Ensures (when applicable) the completion or update of a PCLIA in the Privacy Impact Assessment Management System (PIAMS). For any PCLIAs that will expire at the end of the contract, or after three years of issuance, whichever comes first, the COR must:
o Email PGLD.Contractor.Privacy.Assessment@irs.gov and
privacy.review@irs.gov for instructions on renewing a PCLIA.
o Ensure all contractors and subcontractors with staff-like access to SBU data
are properly investigated prior to being given access.
o Assist with reporting and mitigation of incidents as appropriate. (See section
23.6 IR-6 Incident Reporting.)
12.1.3 Contractor Security Control Assessment Team (CSCA)
Establishes the schedule for CSAs, in coordination with COs, CORs, and contractors.
Conducts on-site or virtual CSAs.
Coordinates with the COR to identify contractor security review timeframes to conduct assessments.
Provides CSA documents to the COR, CO, and the Security Program Management Office. The CSA documents include:
o Executive Memorandum - that includes the Contractor IT and privacy
environment, physical description of the site, and significant security, physical security, and privacy findings.
o Findings Report - which is a PDF version of the findings found during
the assessment in a tabular format listing the security control, justification for the finding, and recommendation to resolve the issue/finding, and
o Data Collection Instrument (DCI) - PDF versions of the DCI
completed during the on-site/virtual assessment which detail the observations of the CSCA Team.
Maintains and updates, as appropriate, IRS Publication 4812 and coordinates changes or updates with IRS stakeholders.
Acts as a resource for CORs/ Business Operating Divisions (BODs) in developing POA&Ms and assessing compliance, and reconciliation or mitigation efforts.
Acts as a Point of Contact (POC) for technical issues for BODs and Procurement Officials and directly or indirectly for contractors.
Alerts Computer Security Incident Response Center (CSIRC) and/or Situation Awareness Management Center (SAMC) of any potential or suspected incidents, risks, or vulnerabilities discovered while conducting a Contractor Security Assessment, that represent immediate, actionable threat intelligence, or presents an unusually urgent demand for attention, correction, or remediation. Similarly, alerts Disclosure, FMSS, Procurement, Privacy, or others, as appropriate, of issues of a pressing nature revealed while conducting a CSA that falls within each component’s areas of responsibility.
27
12.1.4 Privacy
Privacy is responsible for safeguarding and protecting sensitive taxpayer and employee information, while promoting government transparency and accountability through better access to government information. Questions about privacy can be routed through the COR and sent to Privacy.Contractor.Privacy.Assessment@irs.gov and privacy.review@irs.gov mailbox.
To accomplish its mission, Privacy:
- Preserves and enhances public confidence by advocating for the protection and
proper use of sensitive information.
Protects the sensitive information and privacy of taxpayers and IRS employees.
Reduces vulnerabilities for identity theft, which promotes identity protection.
Ensures IRS records (hard copy and electronic), including those containing PII,
are managed appropriately and in accordance with the Records Control Schedules (RCS) Document 12990 and General Records Schedules (GRS) Document 12829.
Analyzes, and resolves incidents involving the loss or theft of an IRS asset, or the loss, theft, destruction, or disclosure of PII.
Works with all IRS operations to ensure only authorized disclosures and data sharing.
Partners with federal, state, tribal, territorial, and local governmental agencies to promote privacy and protect FTI.
Exchanges FTI as authorized by law with external stakeholders.
Safeguards FTI is held by data exchange partners.
Protects IRS employees with cautionary indicators on appropriate taxpayer accounts.
Processes requests for agency records requested under the FOIA Title 5 U.S.C
Create and track POA&Ms for Privacy findings.
Collaborates with the CSCA Team to conduct the privacy assessment.
12.1.5 Facilities Management and Security Services (FMSS)
- Trains and supports IRS employees and contractors to adequately protect
locations and sensitive information where IRS work is performed (FMSS Physical Security).
Prepares and disseminates SAMC Incident Reports accordingly.
Collaborates with the CSCA Team to conduct the physical security assessment.
Creates and tracks POA&Ms for physical security findings.
12.1.6 Personnel Security (PS)
- Receives and processes all investigative requests from the COR.
28
Responsible for determining eligibility and suitability for all contractor personnel who require staff-like access to IRS facilities, systems, or SBU data.
Notifying the appropriate IRS stakeholders of any changes to access status.
Intakes and assesses Position Designation Surveys from contractors (directly or through the COR) and uses the Office of Personnel Management Position Designation Tool (PDT) to assign the position risk designation (or make adjustments/updates, as needed) prior to granting contractor personnel interim or final staff-like access to IRS information or information systems.
12.2 Contractor¶
To ensure IRS SBU and information systems are protected, it is the responsibility of IRS contractors to develop and implement effective controls and methodologies in their business processes, physical environments, and human capital or personnel practices that meet, or otherwise adhere to the security and privacy controls, requirements, and objectives described in this publication, and their respective contracts. As part of the award process, the contractor is required to include an assigned Vendor POC and alternate Vendor POC to all contracts requiring access to Treasury/Bureau information, IT, and systems, facilities, and/or assets. The Vendor POC is the contractor’s primary POC for the Government on all privacy and security-related matters and the person responsible for ensuring the security of information and information systems in accordance with the terms and conditions of the contract and all applicable security controls.
The Contractor is responsible for protecting IRS SBU data (including PII and FTI) based on the contract, the PCLIA, and the privacy and security controls defined in this publication.
12.2.1 Contractor Point of Contact (POC)
Within 5 calendar days of contract award or order issuance, the Contractor POC must submit to the COR a list of contractor personnel who will have a significant role or responsibility for IT security, in the performance of the contract, including those authorized to handle IRS SBU. The Contractor POC will identify the specific IT security role the employee will perform under the contract and will indicate whether such employee(s) has/have completed role-based training, as well as the source and title/subject of the training.
Significant responsibilities must include but may not be limited to contractor personnel who have access to either contractor-managed facilities or contractor managed systems/IT assets used to handle, process or store IRS SBU data, regardless of location or facility, to include contractors who need such access including the use of other IT resources, at contractor managed facilities.
The Contractor POC is responsible for ensuring the following responsibilities are addressed through the life cycle of the contract:
Provide monthly updates to the COR for all findings using a POA&M
Report all incidents to the IRS, as required under the Incident Reporting section of this document.
29
- Ensure all personnel undergo the necessary security screening process and receive interim or final staff-like access approval prior to beginning work under the awarded contract or order, and
• Ensure all contractor personnel take required IRS Mandatory Briefings trainings
within 10 business days of being granted interim/final staff like access and annually
thereafter for all IRS Mandatory Briefings.
12.2.2 Contractor Personnel
Ensure all required IRS training is completed within 10 business days of being granted interim/final staff like access and annually thereafter.
Ensure all privacy, physical, and security policies and procedures are followed when supporting the IRS contract.
Ensure the safeguarding of all information provided to the contractor as part of the IRS contract.
12.3 Contractor Program Requirements¶
The Contractor must develop a comprehensive security program that addresses all aspects of IT security and privacy.
12.3.1 Contractor Security Policies and Procedures
Contractors and subcontractors are responsible for developing policies and procedures to implement security and privacy controls and requirements, as established by this publication and the contract. A contractor or subcontractor who is subject to the security and privacy controls under IRS Publication 4812 does not necessarily have to develop a plan specific to each family if and when those policies and procedures are already established in some existing formal or institutional document that the contractor can readily identify (to the satisfaction of IRS), and the plan contains policies and procedures that address the material elements or requirements for that particular dash one control and security and privacy control family. For example, if the Personnel Security Policy and Procedures (PS-1) requirements for a formal documented PS policy (and procedures to implement those polices and associated personnel security controls) are already contained in the Contractor’s existing Human Resources (HR) policies, the Contractor would not have to recreate this documentation so long as the IRS determines (or is in a position to determine) these existing products or records fulfill the key, germane aspects and requirements for that particular dash one control, as specified in IRS Publication 4812.
Only when the Contractor or Subcontractor does not have standing policies and procedures that adequately and fully address each respective security and privacy control family’s dash one requirement (or the existing policies and procedures are inadequate and need to be supplemented), does the contractor need to develop specific policies and procedures to address that control family.
30
12.3.2 Contractor Investigative Requirements
Contractors, subcontractors, experts, consultants, and paid/unpaid interns, like federal employees, are subject to a security screening to determine their suitability and fitness for the Department of the Treasury or IRS work, and the security screening must be favorably adjudicated. The level to which such contractor personnel and others are screened or investigated must be comparable to that required for federal employees who occupy the same positions and who have the same position sensitivity designation. Security screening is required regardless of the location of the work. This includes contractor or subcontractor personnel who use technology for remote access to information technology systems, as well as those who have direct physical access to any IRS documents or data outside of any IRS facility.
The contractor POC, in collaboration with the COR, must ensure all contractor and subcontractor personnel performing or proposed to perform under the contract as well as those meeting the definition of the term staff-like access are identified to the IRS at time of the award (or assignment) to initiate appropriate security screening.
Working collaboratively, the Vendor POC, the COR, and the CO must ensure that any personnel who are not favorably adjudicated or otherwise pose a security risk are immediately removed from performing work under contract with the IRS, and suitable replacement personnel agreeable to the IRS are provided.
12.3.3 Contractor Training
Ensure all contractor and subcontractor personnel who require staff-like access to IRS information or information systems regardless of their physical location complete the required Mandatory Briefings prior to being granted access to SBU data.
As of July 2026, IRS has developed a methodology to assign the following mandatory briefings to all individuals supporting IRS contracts.
Contractors must maintain and furnish, as requested, records of initial and annual training and certifications. Establish additional internal training, as needed (or as required under the terms of the contract), for personnel in the organization who require access to IRS SBU or information systems to perform under the contract.
Reference AT-2 Awareness Training for time requirements to complete training.
12.3.4 Contractor Information Protection
Ensure all SBU data is protected at rest, in transit, and in exchanges (i.e., internal and external communications). Limit access to SBU data to authorized personnel (those favorably adjudicated and trained) with a need to know and ensure internal and external exchanges are conducted only through secure or encrypted channels. The Contractor and Subcontractor must employ encryption to ensure the confidentiality, integrity, and availability of the SBU data,
31
consistent with the security controls under IRS Publication 4812 and any additional security requirements specified in the contract.
12.3.5 Rules of Behavior
Contractors and subcontractors must develop and distribute a set of internal Rules of Behavior regarding access to and the use of government information and information systems. Rules of Behavior, which are required in OMB Circular A-130, Appendix III, and is a security control contained in NIST SP 800-53 Rev. 5, must clearly delineate responsibilities, and expected behavior of all individuals with access to information systems and/or government information and/or IRS SBU data. The rules must state the consequences of inconsistent behavior or noncompliance and be made available to every user prior to receiving authorization for access to the system and/or IRS SBU data. It is required that the rules contain a signature page for each user to acknowledge receipt; indicating that they have read, understand, and agree to abide by the Rules of Behavior. Electronic signatures are acceptable for use in acknowledging the Rules of Behavior. Contractors must maintain (and furnish, as requested) records of signed acknowledgements on the Rules of Behavior, Non-Disclosure Agreements (NDAs), and the completion of all required awareness training.
32
13.0 Contractor Security Assessments¶
13.1 Overview¶
Security and privacy controls are the management, operational, and technical safeguards or countermeasures employed to protect the confidentiality, integrity, and availability of an organization’s information and information systems.
Contractor Security Assessments (CSA) are on-site or virtual evaluations performed by the IRS to assess and validate the effectiveness of security and privacy controls established to protect IRS SBU data and information systems. Security control effectiveness addresses the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to protecting information and individual privacy, or meeting the security requirements for the information system in its operational environment. These assessments help to determine if additional controls or protections are necessary to protect returns, return information, personal privacy, other SBU data, and organizational assets and operations.
All contracts subject to IRS Publication 4812 requirements may be required to undergo an onsite or virtual CSA annually.
13.2 Types of Assessments¶
Current contract conditions and the stage of the acquisition lifecycle will dictate the type of CSA the IRS will perform. Qualifying events or conditions that may prompt or necessitate the IRS to perform a CSA include:
Rapid Assessments : Pending the award of a contract, an IRS Business Unit (BU) may request a Rapid Assessment to determine the security profile of a contractor. Results of such assessments may be used as an element of the contractor selection process.
Post–Award Assessments : This type of assessment is conducted within the first 30 to 90 days of award and may be performed in lieu of a rapid assessment when award is imminent and the need to make the contract award is urgent and compelling but conducting a rapid assessment is not viable. In such cases, an assessment is necessary as soon as possible after the contract is awarded to approve interim access to IRS SBU.
Periodic Assessments : Based upon the type of work being performed and the volume of SBU data being processed, the IRS may schedule an annual assessment to ensure security controls are in place, and operating as intended.
Follow-up Security Assessment : Based upon the magnitude of findings identified on an assessment, a follow-up assessment may be warranted to evaluate remedial actions taken to address identified security issues.
Contract Closeout Assessments : At contract expiration or termination, the IRS may elect to conduct a security assessment to ensure that all IT resources and SBU data have been adequately inventoried and returned or disposed of in accordance with the contract.
33
13.3 Notice of Assessments¶
For each contract the IRS selects for assessment, in any annual assessment cycle, the IRS will advise the Contractor of the intent to conduct an on-site or virtual CSA and the projected timeframe or proposed date of the assessment. The IRS will coordinate the logistics for the upcoming assessment and advance notice is as much a courtesy as it is recognition of the planning and preparations required by both the IRS and the Contractor.
Typically, an on–site or virtual CSA is three days in duration.
13.4 Security Control Levels¶
Contractor sites and work environments using IT assets to access, process, manage, or store IRS SBU data under contract to the IRS will likely vary in size, number of users, and complexity. For this reason, the IRS has established controls that are selected, depending upon the type of contract, cost, and other factors. As described in more detail in the following subparts, three control sets are categorized (within the assigned moderate impact designation) as follows:
Contractor Security Assessment
Cyber Supply Chain Risk Management (C-SCRM)
Privacy
13.4.1 Contractor Security Assessment
This control level applies to contracts in which contractors access IRS Sensitive But Unclassified (SBU) data and/or information systems, particularly when the contractor operates within a networked IT or cloud environment or provides software development, maintenance, testing, configuration, or related support services. It covers contractors where multiple personnel may access IRS SBU data or IT assets through interconnected information systems, including contractor-operated sites that support the development, testing, maintenance, or operation of information systems and software applications.
13.4.2 Cyber Supply Chain Risk Management (C-SCRM)
C-SCRM refers to the potential for harm or compromise that may arise from suppliers, their supply chains, their products, or their services. C-SCRM addresses threats that exploit vulnerabilities or exposures within products and services that traverse the supply chain or threats that exploit vulnerabilities or exposures within the supply chain itself.
Examples of these risks include:
- Insiders working on behalf of a system integrator steal sensitive intellectual property, resulting in the loss of a major competitive advantage.
34
A proxy working on behalf of a nation-state inserts malicious software into supplierprovided product components used in systems sold to government agencies. A breach occurs and results in the loss of several government contracts.
A system integrator working on behalf of an agency reuses vulnerable code, leading to a breach of mission-critical data with national security implications, and
An organized criminal enterprise introduces counterfeit products onto the market, resulting in a loss of customer trust and confidence.
The C-SCRM controls and supplemental guidance within this publication provides guidance on requirements and mitigating controls to help manage cybersecurity risks throughout the supply chain.
13.4.3 Privacy
Privacy refers to the potential for harm to individuals that may arise from the creation, collection, use, processing, storage, maintenance, dissemination, disclosure, or disposal of Personally Identifiable Information (PII). Privacy addresses risks associated with unauthorized or inappropriate handling of PII and establishes safeguards to ensure that information is processed only for authorized purposes and in accordance with applicable privacy laws, regulations, policies, contractual requirements, and IRS requirements.
The privacy controls within this publication provide requirements and safeguards to help contractors identify, assess, and manage privacy risks associated with the processing and handling of IRS Personally Identifiable Information (PII). These controls help ensure that PII is protected throughout the information lifecycle and is collected, used, maintained, shared, and disposed of only for authorized purposes and in accordance with applicable IRS privacy requirements.
13.5 Scope of Assessments¶
CSAs typically address the following key areas:
The physical environment in which the information system or systems resides, and/or where the information is handled, or processed.
Personnel who have access to or are responsible for the handling or processing of information and information systems.
Evaluation of all applicable IRS Publication 4812 security and privacy controls.
Verification of all personnel security background investigations or interim/final staff-like access determinations for all contractor personnel working on the IRS contract, including subcontractor personnel, and IT support personnel (at any tier) who have unescorted staff-like access to IRS facilities, SBU data, and/or information systems.
Validation of IT security configurations including, but not limited to, workstations, servers, routers, and switches.
Verification of employee’s completion of IRS mandated Mandatory Briefings, which is based on the completion of various information protection briefings 10 business days from being granted interim/final staff like access, and annually thereafter on
35
information system security, disclosure, privacy, physical security, and/or UNAX – commensurate with the assigned risk designations of the position for the work being performed and the category of SBU data to which the employee has access.
Vulnerability and configuration (compliance) scans, and
Preliminary identification of any weaknesses, threats, or vulnerabilities, with more details to be provided in later CSA documentation.
13.5.1 Collaboration on Contractor Security Assessment¶
13.5.1.1 Before the Assessment
Contractors must coordinate with the IRS on all aspects of preparation for the assessment to
include but not limited to; agreement on time and location of assessment, timely submission of
any pre-site visit materials, making ready for inspectio n. policies, documentation,
configurations, and records required at the time of the assessment.
13.5.1.2 At the Time of or During the Assessment
Contractors must make its facilities, installations, operations, documentation, records, databases, and personnel available to the IRS to carry out a program of inspection (in a manner not to unduly delay the work) to protect against threats and hazards to the security, confidentiality, integrity, and availability of IRS data.
Access to contractor facilities and IRS information and/or information systems by IRS representatives (e.g., CORs and CSCA Team) must be permitted, in accordance with the terms of the contract, subject to confirmation of identity, which must be based on each person presenting an active (unexpired), government issued Personal Identity Verification (PIV) card. PII such as a Driver’s License, SSN or Date of Birth (DOB) must not be requested of government personnel conducting an assessment.
A contractor facility that maintains classified information, is subject to the National Industrial Security Program, and has additional government mandated protocols for access, must identify those requirements in writing to the IRS, for its consideration, not less than 10 days before the scheduled inspection/assessment. Denial of access to the Government to conduct its inspections may violate the terms of the contract and constitute a breach of contract.
13.5.1.3 After the Assessment
Within 45 days of the completion of the CSA, the CSCA Team must furnish to the CO/COR the final CSA documents who will share the results with the Contractor
The CSA documents contain the results of the security assessment. This typically includes:
- Findings of “Not Met” or “Repeat Not Met” (with respect to not meeting individual security controls).
36
Identifying the parts of the security controls that did not produce a satisfactory result, or may have the potential to compromise IRS SBU, or the contractor’s information system.
An evaluation of the extent to which security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.
An assessment of the organization’s overall effectiveness in providing adequate security, and
Recommendations for correcting deficiencies in the security controls and reducing or eliminating identified vulnerabilities.
The Findings Report is a key element used in developing a Plan of Actions & Milestones (POA&M). The POA&M is a management process and tool developed by the IRS that outlines weaknesses or deficiencies identified in the CSA.
The contractor must provide a monthly POA&M update to the COR and the CSCA Team until all findings have been validated and closed by the CSCA Team. Each update must include supporting remediation evidence for completed corrective actions or a status update describing remediation progress for findings that remain open. Contractors must prioritize POA&M items based on risk and remediate assessment findings within IRS defined SLAs.
13.5.2 Continuous Monitoring of Security and Privacy Controls¶
Contractors must maintain ongoing awareness of their information system and related security and privacy control processes to ensure compliance with security and privacy controls and adequate security of information, and to support organizational risk management decisions.
37
14.0 Privacy and Information Protection¶
14.1 Security Categorization¶
The Federal Information Processing Standards (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems, establishes security categories for both information and information systems. The information system impact level is derived from the security category in accordance with FIPS 200, Minimum Security Requirements for Federal Information and Information Systems. FIPS 200 and NIST SP 800- 53 Rev. 5, in combination, help ensure that appropriate security requirements and controls are applied to all federal information and information systems.
As required by FIPS 199, organizations use the security categorization results to designate information systems as low, moderate, or high impact.
The IRS has determined the security impact for all contracting actions subject to IRS Publication 4812 is moderate impact, unless:
The information system in the contract to which the Contractor has staff-like access is one of the limited number of systems on the IRS FISMA Inventory (i.e., it is specifically identified as such, and/or it is a major application or general support system, as defined by OMB Circular A-130, Appendix III). In this case, IRS Publication 4812 would be replaced with the more stringent standards for a high impact system, and other requirements as may be specified by IRS.
A different impact level is specified in the contract (at time of award, or by modification).
The security impact level can only be lowered when IT Cybersecurity determines, in writing, all 3 of the security objectives (confidentiality, integrity, and availability) are low. The security impact level must only be raised if IT Cybersecurity determines, in writing, one or more of the three security objectives is high.
In the event the impact level is to be lowered or raised from moderate impact for any contract that is subject to IRS Publication 4812, the change must be reflected in the contract at time of award or by modification of the contract. At such time, security control requirements appropriate to the new impact level must be provided to the contractor (e.g., guidance on any security controls or control enhancements from the default standard (moderate-impact) that do not apply (or are lessened), if and when the impact level is being lowered to low-impact; or additional controls or control enhancements above the default standard (moderate-impact) that would apply, if and when the impact level is being raised to high-impact.)
38
15.0 Security and Privacy Control Organization and Structure¶
This document provides required controls for protecting SBU data, developed from NIST guidance. The security controls in this document are organized into families as described in NIST SP 800-53 Rev. 5. Each security control family contains security controls related to the functionality of the family. A two-character, unique identifier is assigned to each security control family.
The following table summarizes the control families and associated identifiers for developing security and privacy controls used in this publication.
Table 1: NIST Families of Security and Privacy Controls
IDENTIFIER FAMILY AC Access Control AT Awareness and Training AU Audit and Accountability CA Assessment, Authorization, and Monitoring CM Configuration Management CP Contingency Planning IA Identification and Authentication IR Incident Response MA Maintenance MP Media Protection PE Physical and Environmental Protection PL Planning PM Program Management PS Personnel Security PT PII Processing and Transparency RA Risk Assessment SA System and Services Acquisition SC System and Communications Protection SI System and Information Integrity SR Supply Chain Risk Management
The twenty security control families in NIST SP 800-53 Rev. 5 are closely aligned with the seventeen minimum security requirements for federal information and information systems in FIPS 200. One additional family, Program Management (PM), provides controls for information security programs. PM, while not referenced in FIPS 200, provides security and privacy controls at the organizational level rather than the information system level. The PM controls address the strategic level implementation of an overall security and privacy program. Contractors subject to IRS Publication 4812 are not responsible for the implementation of IRS strategic security PM but are required to abide by PM Privacy controls in IRS Publication 4812.
39
16.0 Access Control (AC)¶
The Access Control (AC) control family establishes requirements for restricting access to IRS SBU data and information systems to authorized contractor personnel. Access must be limited to contractors who have been approved by IRS Personnel Security (PS) for the appropriate level of staff-like access and who have a valid need-to-know to perform their assigned responsibilities.
16.1 AC-1 Access Control Policy and Procedures¶
Contractors, including those using a CSP, who operate IT assets or information systems must ensure that they or the CSP designate an official to manage the development, documentation, and dissemination of the AC policies and procedures for security and privacy related controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organizational Entities
Compliance
Contractors and CSP’s must review/update AC policies and procedures annually or if there is a significant change to ensure adequate AC policies and procedures are developed and implemented.
Supplemental C-SCRM Guidance: Contractors must specify and include in agreements (e.g., contracting language) AC policies for their suppliers, developers, system integrators, external system service providers, and other Information and Communication (ICT) /Operations Technology (OT) related service providers that have access control policies. These should include both physical and logical access to the supply chain and the information system. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
16.2 AC-2 Account Management¶
The Contractor or CSP must create a unique account for each user who accesses the information system.
The Contractor or CSP must assign an account manager to manage accounts and employ automated mechanisms to support the management of accounts. Automated mechanisms include helpdesk software, email, telephone, and text messaging notifications.
There must be a procedure that describes how accounts are established and reviewed at least annually (semi-annually for privileged accounts), modified, or deleted, as necessary. At a
40
minimum, the Contractor must identify all personnel authorized to access the IT asset, including information system support personnel.
The Contractor must notify account managers:
When accounts are no longer required,
When users are terminated or transferred, and
When individual information system usage or need-to-know changes.
The Contractor or CSP must automatically disable all user and privileged accounts after 60 days of inactivity. The Contractor must disable any account within one hour if the contractor determines the user poses a serious security or privacy risk, either by planning to misuse access or by being vulnerable to exploitation by adversaries.
The Contractor must disable accounts within 3 business days when the accounts have expired or are no longer associated with a user. The information system must automatically remove/terminate temporary and emergency accounts after two business days.
The information system must automatically audit account creation, modification, enabling, disabling, and removal actions and notify, as required, the appropriate individuals.
Contractors, including those using CSPs, must restrict access to call recording systems and recorded call content to authorized personnel with a documented business need. Access must be limited to personnel who initiate or receive calls, designated quality assurance personnel, and other individuals explicitly authorized to perform operational, legal, compliance, security, or administrative functions.
Supplemental C-SCRM Guidance: Contractors must ensure that accounts for contractor personnel do not exceed the period of performance of the contract. Privileged accounts must only be established for appropriately vetted contractor personnel. Contractors must also have processes in place to establish and manage temporary or emergency accounts for contractor personnel that require access to a mission-critical or mission-enabling system during a continuity or emergency event. For example, during a pandemic event, existing contractor personnel who cannot work due to illness may need to be temporarily backfilled by new contractor staff. Contractors should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
41
16.3 AC-3 Access Enforcement¶
Contractors, including those using a CSP, must ensure that they develop a process that demonstrates how personnel are approved for access, prior to being granted access to IRS SBU and information systems supporting the IRS contract. The contractor must develop policy directing taxpayers to the IRS for any inquiries, access requests, or requests to modify their PII.
Supplemental C-SCRM Guidance: Contractors must ensure that their information systems and the supply chain have appropriate access enforcement mechanisms in place. This includes both physical and logical access enforcement mechanisms, which are likely to work in coordination for supply chain needs. Contractors must ensure that a defined consequence framework is in place to address AC violations. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
16.4 AC-4 Information Flow Enforcement¶
Contractors, including those using a CSP, must ensure that they implement information flow enforcement. Contractor information systems must enforce approved authorizations for controlling the flow of information within the system and between connected systems based on applicable policies, agreements, contracts, and/or procedures. Examples of information flow control restrictions include keeping export-controlled information from being transmitted in the clear to the internet; blocking outside traffic that claims to be from within the organization; restricting web requests to the internet that are not from the web proxy server; and limiting information transfers between organizations based on data structures and content.
Supplemental C-SCRM Guidance: Supply chain information may traverse a large supply chain to a broad set of stakeholders, including the Contractor and its various clients, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Specifying the requirements and how information flow is enforced should ensure that only the required information is communicated to various participants in the supply chain. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
16.5 AC-5 Separation of Duties¶
Contractors, including those using CSPs, must establish, document, implement, and annually review separation of duties for roles and responsibilities associated with information systems supporting the IRS contract. Duties and associated access privileges must be assigned to reduce the risk of fraud, unauthorized activity, errors, misuse, or compromise by ensuring that no individual has the ability to independently perform conflicting functions or circumvent security controls without appropriate oversight or authorization.
Supplemental C-SCRM Guidance: Contractors must ensure that an appropriate separation of duties is established for decisions that require the acquisition of both information system and
42
supply chain components. The separation of duties helps to ensure that adequate protections are in place for components entering the Contractor’s supply chain, such as denying developers the privilege to promote code that they wrote from development to production environments. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
16.6 AC-6 Least Privilege¶
Contractors, including those using Cloud Service Providers (CSPs), must ensure that contractor personnel are granted only the privileges, permissions, and access necessary to perform their assigned duties. Access rights must be based on the principles of least privilege, need-to-know, and need-to-access, and must be limited to the minimum level of access required to perform authorized job functions.
The Contractor must authorize and restrict access to privileged security functions. Security functions include, but are not limited to:
Establishing and managing system accounts.
Assigning, modifying, and revoking permissions and privileges.
Configuring security settings.
Managing audit logging and monitoring capabilities.
Performing vulnerability scanning and remediation.
Managing cryptographic services and key management.
Administering cloud resources and identity services.
Managing Artificial Intelligence (AI) administrative functions where AI is used in support of the IRS contract.
Contractors must require personnel with privileged access to establish and use separate privileged and non-privileged accounts. Privileged accounts must only be used to perform administrative functions. Routine activities such as web browsing, email, and internet access must be restricted for privileged accounts.
The Contractor must prohibit non-privileged users from performing privileged functions or bypassing implemented security or privacy controls.
Privileged access rights must be reviewed at least quarterly and whenever personnel change job responsibilities, transfer positions, separate from the organization, or no longer require elevated privileges.
All privileged activities performed on contractor-managed information systems, cloud services, applications, databases, and security appliances must be logged, monitored, and protected from unauthorized modification or deletion.
The Contractor must implement technical controls to prevent unauthorized privilege escalation.
43
IRS Sensitive But Unclassified (SBU), Personally Identifiable Information (PII), and Federal Tax Information (FTI) must be physically or logically segregated from information belonging to other customers or organizations.
Workstations and information systems supporting the IRS contract must restrict users from performing the following activities unless specifically authorized:
Executing administrative tools.
Accessing command-line interfaces used for administrative purposes.
Installing, removing, or modifying software.
Changing operating system or security configurations.
Disabling endpoint protection, logging, or monitoring capabilities.
Accessing insecure protocols, including FTP or Telnet.
Obtaining local administrator privileges.
Performing system backups or restores.
Database administration functions.
Writing data to removable media unless explicitly authorized.
Using AutoRun or AutoPlay functionality for removable media.
Where Artificial Intelligence (AI) systems are used to support the IRS contract, administrative access to AI models, model configurations, prompts, training data, retrieval databases, APIs, plugins, and orchestration services must be restricted to authorized personnel. Contractors must implement controls to prevent unauthorized modification of AI models, model parameters, system prompts, or other AI security configurations.
16.7 AC-7 Unsuccessful Login Attempts¶
The Contractor must configure their information system to lock an account after 3 unsuccessful logon attempts in a 120-minute period. Once an account is locked it must remain locked for 15 minutes or until released by an administrator or password reset program.
Contractors using a CSP must ensure that, upon a 3rd unsuccessful logon attempt during a 15minute time-period, the CSP will lock the account for a minimum of 30 minutes or until unlocked by an administrator and delay the next logon prompt, at a minimum for five seconds.
16.8 AC-8 System Use Notification¶
Contractors, including those using Cloud Service Providers (CSPs), must display a system use notification containing a security and privacy notice before granting users access to information systems supporting the IRS contract.
The system use notification must be reviewed and approved by the contractor's legal counsel or designated official.
The notification must inform users that:
44
Use of the information system constitutes consent to monitoring, recording, and auditing.
Information system activities may be monitored, recorded, and audited.
Unauthorized access or use of the information system is prohibited and subject to disciplinary actions.
For publicly accessible applications or websites that require user registration or authentication the application or website must display a system use notification before granting access.
The system use notification must:
Accurately describe any monitoring, recording, or auditing activities that may occur, consistent with applicable privacy laws, regulations, and organizational privacy requirements.
Describe the authorized uses of the application or information system.
16.9 AC-11 Device Lock¶
Contractors, including those using Cloud Service Providers (CSPs), must configure information systems and applications supporting the IRS contract to automatically initiate a session lock after 15 minutes of user inactivity. When a session is locked, the information system must prevent the display of IRS Information by displaying a generic lock screen or equivalent interface. The session must remain locked until the user successfully reauthenticates using an approved authentication mechanism.
16.10 AC-12 Session Termination¶
Contractors, including those using Cloud Service Providers (CSPs), must configure information systems and applications supporting the IRS contract to automatically terminate user application sessions after no more than 30 minutes of inactivity. Following session termination, users must re-authenticate using an approved authentication mechanism to establish a new session.
Session termination applies to local, remote, virtual, and cloud-hosted application sessions and is intended to reduce the risk of unauthorized access to IRS Information resulting from abandoned or inactive sessions. Session termination is distinct from network session termination addressed by SC-10 (Network Disconnect).
16.11 AC-14 Permitted Actions without Identification or Authentication¶
Contractors, including those using Cloud Service Providers (CSPs), must identify and document any actions that users are permitted to perform on information systems supporting the IRS contract without identification or authentication. Such access must be limited to the minimum functionality necessary to support the IRS contract and must not provide
45
unauthorized access to IRS SBU, PII, FTI, administrative functions, or other protected resources.
Examples include access to publicly available information on contractor-managed websites or applications that are specifically intended for public access and does not require user identification or authentication.
16.12 AC-17 Remote Access¶
Contractors, including those using a CSP, must document usage restrictions, configuration/connection requirements, implementation guidance, and authorize each type of remote access to the information system prior to allowing connections.
Contractors, including those using a CSP, must employ automated mechanisms to monitor and control remote access methods. Monitoring and control of remote access methods allows organizations to detect attacks and help ensure compliance with remote access policies by auditing the connection activities of remote users on a variety of system components, including servers, laptop computers, workstations, smartphones, and tablets.
Anytime a contractor or CSP allows an employee or IT support personnel to remotely access the contractor’s IT environment that houses and/or processes IRS SBU data, the connection must be secured using a Virtual Private Network (VPN) using Two-factor Authentication (2FA) and FIPS 140-3 or later validated encryption modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules. 2FA requires the use of 1) something they know, (such as a password) and 2) something they possess, (such as a token card), to access the information system.
The information system must route all remote access through a limited number of managed access control points. Remote Access to contractor IT environments that support the IRS contract utilizing IRS issued laptops/equipment or contractor owned/operated laptops/equipment is forbidden from locations outside the US and its territories.
Contractors using a CSP must ensure that the CSP provides the capability to disconnect or disable remote access to the information system within 15 minutes.
Supplemental C-SCRM Guidance: Supply chains are typically accessed remotely. Whether for the purpose of development, maintenance, or the operation of information systems, contractors must implement secure remote access mechanisms and allow remote access only to vetted personnel. Remote access to a contractor’s supply chain (including distributed software development environments) must be limited to the contractor or contractor personnel and only if and as required to perform their tasks. Remote access requirements must be properly defined in agreements. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
46
16.13 AC-18 Wireless Access¶
The Contractor must authorize, document, and monitor all wireless access to the information system. Contractors must create and maintain documentation that defines wireless configurations and restrictions. Only users identified and explicitly authorized must be allowed to configure wireless networking capabilities. Contractors must perform quarterly scans for rogue wireless access points and other unauthorized wireless activity and must take action to remove rogue access points upon detection. Guest wireless networks must be physically or logically separated from information systems used to process, store, or transmit IRS SBU, PII, or FTI and must not allow direct access to those environments.
Contractors, including those using a CSP, must protect wireless access to the information system using authentication of users and devices, and require FIPS 140-3 or later validated encryption modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must implement FIPS 140-3 validated cryptographic modules. This requirement also applies to contractor personnel who use personally provided wireless network services, such as home or other non-contractor-managed networks, to remotely access contractor information systems from telework or alternate work location.
Contractors, including those using a CSP, must disable, when not intended for use, wireless networking capabilities internally embedded within information system components prior to issuance and deployment. Unapproved wireless networking capabilities of desktops, laptops, printers, copiers, fax machines, and other devices must be disabled and monitored for unauthorized changes.
16.14 AC-19 Access Control for Mobile Devices¶
A procedure must be developed to authorize, document, and monitor mobile device access to the contractor’s information system. Information must be sufficient to enable all activities to be logged.
Contractors, including those using a CSP, must develop policies for allowed portable and mobile devices, for information systems that contain SBU data. This includes the use of smartphones, tablets, etc. The policies must document the approved or disapproved use of mobile devices to connect to IT assets that house IRS SBU.
IRS issued laptops/mobile devices or contractor laptops/mobile devices containing IRS SBU data must not be taken outside of the United States or its territories.
Electronic, optical, and other removable media must be kept in a secure area under the immediate protection and control of authorized contractor personnel or locked up. When not in use, the media must be promptly returned to a proper storage area/container. For more information, please see Section 25.0 Media Protection.
47
IRS SBU data may be stored on mobile devices only if contractor-approved security access control devices (hardware/software) have been installed and are receiving regularly scheduled maintenance and security patches.
All mobile computing devices must employ full-disk encryption. This includes but is not limited to desktop/laptop computers, Compact Disk (CD), Digital Versatile Disc (DVD) media, thumb drives, external hard drives or any media that can be used to house IRS SBU data that can be easily transported by an individual. IRS SBU that resides on removable media, must be encrypted with FIPS 140-3 or later validated encryption modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program (CMVP), they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
Contractors supporting or allowing personally owned devices, also known as Bring Your Own Device (BYOD) to store, process, or access IRS SBU data must:
- Register all BYOD devices with the company and manage them via a Mobile
Device Manager (MDM) server.
- Consent to remote inspection and monitoring of the approved mobile access
solution on their approved personally owned mobile device.
- Ensure they are the only people who have access to their approved personally
owned mobile devices when being used to view or process IRS SBU information.
- Ensure a valid password is successfully entered prior to logging onto the mobile
device.
- Only approved personally owned mobile devices must be permitted to process or
store IRS SBU, including IRS email.
• The device must have sandboxing capability to segment company and/or IRS
SBU data from the personnels’ personal information.
- The MDM must have the ability to remotely erase the sand box when the BYOD
device is lost, stolen, or the employee is no longer working for the company.
• The Sandbox partition must be encrypted utilizing FIPS 140-3 or later validated
encryption modules. Where legacy FIPS 140-2 validated modules remain
authorized by the Cryptographic Module Validation Program, they may continue
to be used until replacement is required by changes in CMVP validation status.
New systems, acquisitions, implementations, and major upgrades must use FIPS
140-3 validated cryptographic modules.
- Applications stored on the corporate sandbox partition must be approved and
distributed by the company via the MDM.
- Personnels’ personal apps must not be able to communicate with containerized
apps, nor can data be copied and pasted from a containerized app to a noncontainerized application.
- BYOD users must not use administrative accounts for general tasks, such as
reading email, web browsing, and social networking, because such tasks are common ways of infecting devices with malware.
48
- The device must include anti-malware software and be configured to receive
updates automatically. The software must be configured to scan in real-time and perform full system scans at least weekly.
• The transfer of files via instant messaging platforms must be restricted. If the
software can transfer files with other instant messaging users, it should be
configured to prompt the user before permitting a file transfer to begin.
• MDM servers must be configured to detect rooted or jailbroken devices.
• Jailbreaking or installing a rootkit on BYOD devices is strictly prohibited. Doing
so disables the manufacturer’s built-in security capabilities for the device.
- The use of public WIFI hotspots is prohibited unless the device is connected via a
contractor approved VPN connection that utilizes FIPS 140-3 or later validated encryption modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
A firewall must be installed and active on all mobile devices.
BYOD participants must not store any IRS SBU data on removable media.
IRS SBU must not be viewed or discussed on mobile devices in public places
(e.g., airports, coffee shops, hospitals, malls, etc.), and
- MDM servers must be configured to detect rooted or jailbroken devices.
Contractors using a CSP must ensure that the CSP employs either full-device encryption or container encryption to protect the confidentiality and integrity of information on all mobile devices.
16.15 AC-20 Use of External Systems¶
External systems are information systems or components of systems that are outside of the authorization boundary established by the contractor and for which the contractor has no direct control over security controls or the assessment of security control effectiveness.
Contractors, including those using a CSP, must ensure that only those IT assets identified for processing of IRS SBU must be used to support the IRS contract. IT assets not identified to the IRS as being in the scope of IRS contract are considered external information systems. The contractor and subcontractor must not use other external information systems within their home or business for the purpose of conducting IRS work.
Contractors, including those using a CSP, must permit authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the contractor:
- Verifies the implementation of required security controls on the external system
as specified in the organization’s information security policy and security plan, and
49
- Retains approved information system connection or processing agreements with
the organizational entity hosting the external information system. The contractor must limit the use of organization-controlled portable storage devices media by authorized individuals on external information systems.
Contractors, including those using a CSP must ensure that they, or the CSP must establish terms and conditions consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:
• Access the information system from external information systems, and
• Process, store, or transmit IRS SBU using external information systems.
Contractors, including those using a CSP must ensure that they, or the CSP must restrict the use of Contractor or CSP-controlled portable storage devices by authorized individuals on external information systems.
Supplemental C-SCRM Guidance: Contractors’ external information systems include those suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Unlike in an acquirer’s internal Contractor where direct and continuous monitoring is possible, in the external supplier relationship, information may be shared on an as-needed basis and should be articulated in an agreement. Access to the supply chain from such external information systems must be monitored and audited. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
16.16 AC-21 Information Sharing¶
Contractors, including those using a CSP must ensure that they facilitate information sharing, as allowed by the IRS or contract. This can be done by identifying the appropriate personnel who review and authorize sharing, to determine if the information being shared with a partner organization matches the contractor access requirements for the information being shared.
Contractors, including those using a CSP must employ automated mechanisms or manual processes to assist users in making information sharing/collaboration decisions.
This requirement applies to information that may be restricted in some manner (e.g., contractsensitive information, proprietary information, IRS SBU, PII, or FTI). Depending on the information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment.
Before any PII, FTI, or SBU related to the IRS contract is shared, the Information Sharing Agreement (ISA) between the contractor and subcontractor must be approved by the COR and the Business Unit (BU). As part of the ISA review, the COR must complete a PCLTA. If the subcontractor requires SSNs to perform their work, the BU must also complete Form 14132.
50
16.17 AC-22 Publicly Accessible Content¶
Contractors, including those using a CSP, must designate and authorize personnel responsible for posting information to publicly accessible information systems as permitted by the IRS or the IRS contract. Authorized personnel must receive training in identifying and protecting non-public information to prevent unauthorized disclosure. Prior to publication, all proposed content must be reviewed to verify that it does not contain non-public information. Contractors must review publicly accessible content for non-public information, at minimum quarterly or according to the contract requirements, and promptly remove any non-public information if it is identified.
16.18 AC-23 Data Mining Protection – C-SCRM Control¶
The Contractor must employ data mining prevention and detection techniques to detect and protect against unauthorized data mining.
Supplemental C-SCRM Guidance: Contractors must implement this control as part of their insider threat activities and flow down this requirement to relevant sub-tier contractors.
17.0 Awareness & Training (AT)¶
The IRS has established security and privacy awareness policies and procedures to ensure contractor personnel complete required training and understand their responsibilities for protecting IRS Sensitive But Unclassified (SBU) data.
17.1 AT-1 Awareness & Training Policy and Procedure¶
Contractors, including those using a CSP, must designate an official to manage the development, documentation, and dissemination of the Awareness & Training policies and procedures to facilitate the implementation of the awareness training.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
Contractors, including those using a CSP, must review/update AT policies and procedures annually, or if there is a significant change to awareness and training policies or procedures.
51
17.2 AT-2 Awareness Training¶
Contractors must ensure all contractor personnel who require access to IRS SBU data or information systems housing IRS SBU complete the IRS required Mandatory Briefings.
IRS Mandatory Briefings include:
IRS Annual Cybersecurity Awareness
Privacy, Information Protection, & Disclosure (PIPD)
Records Management Awareness
Insider Threat Awareness
FMSS Physical Security
IRS CUI General Awareness
UNAX Awareness
Contractor personnel are required to provide documentation of complete IRS Mandatory Briefings within 10 business days of the date indicated on the approval of interim Staff-Like Access memorandum and prior to being granted access to IRS SBU information. Thereafter, contractors must complete IRS Mandatory Briefings on an annual basis by October 31.
Contractors with access to the IRS Integrated Talent Management (ITM) system are required to complete Mandatory Briefings within the IRS Integrated Talent Management (ITM) system. The contractor is responsible for ensuring that all training materials are received and properly distributed to contractor and subcontractor personnel. The contractor must also provide the IRS COR with a list of all personnel who have completed the required training. If a contractor does not have access to ITM, the COR will provide alternative access to the required training materials. If the training is completed outside of ITM, contractor personnel must submit a completed and signed Form 14616, Contractor Mandatory Briefings Certification, to the COR upon completion.
The COR is responsible for ensuring that all training completions are properly recorded in the IRS Integrated Talent Management (ITM) system. The COR must record manual training completions in ITM within 60 days of receiving the Approval of Staff-Like Access memorandum.
17.3 AT-3 Role Based Training¶
Contractor personnel assigned to a significant IT role or responsibility, as defined in the table below, must complete 8 hours of Specialized IT Security Training (SITS) before being granted access to IRS Sensitive But Unclassified (SBU) information. This requirement applies to new contractor personnel, including those assigned at contract award.
For existing contracts that are modified to designate contractor or subcontractor personnel in a significant IT role, the affected personnel must complete the required 8 hours of SITS training within 45 days of the contract modification.
52
After the initial training, all contractor personnel in significant IT roles must complete 8 hours of SITS refresher training annually by June 1.
There are various sources for SITS training including ITM, contractor learning systems, and free web-based training available to government contractors. IT security training completed by contractors within the last year as part of continuing education may be accepted at the discretion of the CSCA team. Evidence for SITS training must include name of course,
53
attendee name, date completed, length of course. As a convenience to contractors a website where free SITS training is available at https://niccs.cisa.gov/education-training/cisa-learning
Supplemental C-SCRM Guidance: Contractors must designate an official to manage the development, documentation, and dissemination of the training policy and procedures, including C-SCRM and role-based specific training for those with supply chain responsibilities. Contractors must integrate cybersecurity supply chain risk management training and awareness into the security training and awareness policy. C-SCRM training should target both the contractor and its contractors. The policy should ensure that supply chain cybersecurity role-based training is required for those individuals or functions that touch or impact the supply chain, such as the information system owner, acquisition, supply chain logistics, system engineering, program management, IT, quality, and incident response.
17.4 AT-4 Training Records¶
Contractors with access to the IRS Integrated Talent Management (ITM) system must ensure that all required information security, privacy awareness, and role-based training is completed, documented, and recorded in ITM. Contractors without access to ITM must provide training records to the COR for uploading them into ITM. Contractors must monitor training completion to ensure personnel remain current with all required training.
18.0 Audit and Accountability (AU)¶
The Audit and Accountability (AU) control family establishes requirements for generating, protecting, retaining, monitoring, and reviewing audit records to support the detection, investigation, and reporting of security events. These controls provide accountability for actions performed on information systems, facilitate incident response and forensic investigations, and help ensure the confidentiality, integrity, and availability of IRS Sensitive But Unclassified (SBU) data.
18.1 AU-1 Audit and Accountability Policy and Procedures¶
Contractors, including those using a CSP, must designate an official to manage the development, documentation, and dissemination of the AU policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
54
Contractors, including those using a CSP, must review/update AU policies and procedures annually. The policies and procedures must be sufficient to enable monitoring of IT assets.
18.2 AU-2 Event Logging¶
Contractors, including those using a CSP must implement a centralized event logging infrastructure integrated with a Security Information and Event Management (SIEM) platform. The SIEM must collect, retain, correlate, and analyze audit and security logs from IT assets, including, but not limited to, routers, firewalls, operating systems, databases, remote access services, file systems, cloud resources, and applications. The capability must provide continuous monitoring, alerting, and reporting to support the detection, investigation, and response to unauthorized access, suspicious activity, and cybersecurity incidents. Audit records must not include Personally Identifiable Information (PII), Federal Tax Information (FTI), or other IRS Sensitive But Unclassified (SBU) data unless required to identify, investigate, or respond to a security or privacy event. Contractors, including those using a CSP must identify and log events that allow the contractor to detect, deter, and report on suspicious activities. The required log events are listed in the tables below.
| Table 2: Required Log Events Category Authentication and Access | Required Audit Events Successful logon attempts |
|---|---|
Category |
Required Audit Events |
~~Authentication and Access ~~ |
~~Successful logon attempts ~~ Account logon events Account logoff events Authentication checks Authorization checks |
| ~~Account and Identity Management ~~ |
~~Account creation ~~ Account deletion Account management events Permission changes Group membership changes |
| ~~Privileged Activity ~~ |
~~Privileged function execution ~~ Privilege elevation events |
~~System and Process Activity ~~ |
~~System events ~~ System startup events System shutdown events Service start events Service stop events |
| ~~Object and Data Access ~~ |
~~Object access ~~ Data changes Data deletions |
| ~~Configuration and Security Management ~~ |
~~Policy changes ~~ Audit policy changes |
55
| Application authentication events API access events API authentication fail ures |
|
|---|---|
| ~~Cloud and Identity Services ~~ |
~~Cloud administrative activities ~~ Multi-Factor Authentication (MFA) success events Multi-Factor Authentication (MFA) failure events Role and permission changes Privileged Identity Management (PIM) activities Privileged Access Management (PAM) activities Cloud resource creation Cloud resource modification Cloud resource deletion API authentication events Cloud security policy changes |
| ~~Artificial Intelligence (AI) ~~ |
~~AI administrator activities ~~ AI authorization events AI model deployment AI model modification AI model replacement AI model configuration changes Prompt management changes System prompt modifications AI plugin changes AI agent changes AI orchestration changes AI-generated security alerts AI anomalous behavior events AI access to IRS SBU, PII, or FTI AI audit logging failures AI logging disabled events AI model training events (where applicable) AI model fine-tuning events (where applicable) |
Contractors, including those using a CSP, and/or using including Commercial Off-the-Shelf (COTS) solutions to store, process, and collect FTI must retain event logs to support audit analysis and investigations of unauthorized access. The system must record and retain the following information in a data transaction or event log; the user’s identity, date, and time of access to FTI, action taken, and which account was accessed.
Contractors must configure call recording systems to capture and retain call recording metadata and have the capability to search the meta-data for the purposes of play-back, quality assurance, and a record of file access.
Meta-data associated with the voice recording must include the following information:
The staff member initiating or receiving the call,
The data, time, and duration of the conversation,
A way to track the identity of the taxpayer, and
Access to voice recording (to identify UNAX violations).
56
Supplemental C-SCRM Guidance: An observable occurrence within the information system or supply chain network must be identified as a supply chain auditable event based on the Contractor’s System Development Lifecycle (SDLC) context and requirements.
Auditable events may include software/hardware changes, failed attempts to access supply chain information systems, or the movement of source code. Information on such events should be captured by appropriate audit mechanisms and be traceable and verifiable. Information captured may include the type of event, date/time, length, and the frequency of occurrence. Auditing may help detect misuse of the supply chain information systems or networks caused by insider threats. Logs are a key resource when identifying operational trends and long-term problems.
Contractors must incorporate reviewing logs at the contract renewal point for vendors to determine whether there is a systemic problem. Contractors and subcontractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
18.3 AU-3 Content of Audit Records¶
The Contractor must configure the information system to generate audit records containing enough detail to facilitate the reconstruction of events. Events may include unauthorized activity, a system malfunction, or tampering is suspected in the audit records, for audit events identified by type, location, or subject.
Examples of content that may satisfy this requirement are time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
Contractors, including those using a CSP must generate audit records containing information that establishes:
What type of event occurred,
When the event occurred,
Where the event occurred,
The source of the event,
The outcome of the event, and
The identity of any individual, subjects, or objects/entities associated with the event.
Contractors, including those using a CSP must consider how audit records can reveal information about individuals that may give rise to privacy risks and how best to mitigate such risks. For example, there is the potential to reveal PII in the audit records, especially if the records inputs or is based on patterns or time of usage.
Audit records must not include Personally Identifiable Information (PII), Federal Tax Information (FTI), or other IRS Sensitive But Unclassified (SBU) data unless required to identify, investigate, or respond to a security or privacy event. Contractors, including those using a CSP must limit PII in audit records when such information is not needed for
57
operational purposes helps reduce the level of privacy risk created by a system. Contractors must limit IRS PII contained in their audit records to only collecting the approved IRS PII data elements as listed in the PCLIA.
Supplemental C-SCRM Guidance: The audit records of a supply chain event should be securely handled and maintained in a manner that conforms to record retention requirements and preserves the integrity of the findings and the confidentiality of the record information and its sources as appropriate. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
18.4 AU-4 Audit Log Storage Capacity¶
Contractors, including those using Cloud Service Providers (CSPs), must allocate and maintain sufficient audit log storage capacity to support audit retention requirements and ensure the timely collection, retention, protection, and retrieval of audit records. Audit log storage requirements, including capacity, retention periods, and storage locations, must be documented in the system security documentation and reviewed annually to ensure they remain adequate to support operational, security, and investigative needs. Contractors must annually evaluate projected audit log growth to ensure sufficient storage capacity exists to support future operational and retention requirements.
18.5 AU-5 Response to Audit Logging Processing Failures¶
Contractors, including those using CSPs, must establish and implement procedures to detect, respond to, and recover from audit processing failures to ensure the continued generation, protection, and retention of audit records.
At a minimum, the Contractor or CSP must:
Develop and maintain documented procedures for responding to audit processing failures.
Configure information systems to generate real-time alerts when audit logging is disrupted, audit log storage approaches or reaches capacity, or other conditions could prevent the collection or retention of audit records.
Promptly investigate and restore audit logging capabilities following an audit processing failure.
Implement corrective actions to prevent the loss of audit records and maintain audit logging continuity during hardware failures, software failures, audit collection failures, storage capacity limitations, or other conditions affecting audit processing.
18.6 AU-6 Audit Record Review, Analysis, and Reporting¶
Contractors, including those using CSPs, must ensure that information systems provide automated capabilities to search, filter, analyze, and generate reports from audit records to support audit review, analysis, reporting, and investigation of security and privacy incidents.
58
Authorized personnel must be able to identify events of interest using selectable criteria, such as user or account, date and time, event type, system or resource, source, destination, or other relevant attributes.
Contractors, including those using CSPs, must ensure that they, or the CSP will review and analyze information system audit records at least weekly; for indications of inappropriate or unusual activity.
Audit record processing, reduction, analysis, and report generation must preserve the content and integrity of the original audit records.
18.7 AU-7 Audit Record Reduction and Report Generation¶
Contractors, including those using Cloud Service Providers (CSPs), must ensure that information systems provide automated capabilities to process, search, filter, analyze, and generate reports from audit records to support on-demand audit review, analysis, reporting, and post-incident investigations.
Audit record reduction and report generation capabilities must allow authorized personnel to search for and identify events of interest using selectable criteria, such as date and time, user or account, system or resource, event type, source, destination, or other relevant attributes.
The processing, reduction, analysis, or generation of audit reports must not alter, overwrite, or otherwise modify the content or integrity of the original audit records.
18.8 AU-8 Time Stamps¶
All audit records generated on contractor, or CSP information systems must contain a timestamp. Internal system clocks must generate the timestamp for audit records. Information systems must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC), or Greenwich Mean Time (GMT) and meets one second granularity of time measurement.
Contractors, including those using CSP’s must compare internal information system clocks with an authorized enterprise-wide time source and synchronize the internal system clocks to the authoritative time source when the time difference is greater than one second.
18.9 AU-9 Protection of Audit Information¶
Contractors, including those using CSP, must define all individuals who are responsible for reviewing audit information upon detection of unauthorized access, modification, or deletion. Access must be restricted so that only authorized personnel have access to audit information. The management and retention of all audit information must remain in control of the contractor identified in the IRS contract and safeguarded as SBU data. Audit logs must be protected by access controls to prevent unauthorized access to ensure events are not modified or deleted.
59
Audit records must be stored at least weekly in a repository that is part of a physically different system or system component than the system or component being audited. Cryptographic mechanisms must be implemented to protect the integrity of audit information and audit tools.
18.10 AU-11 Audit Record Retention¶
The Contractor must retain audit records for seven years if the contractor is processing/storing/or transmitting FTI. Otherwise, audit records must be retained for three years for the purpose of providing support in after-the-fact investigations of security incidents. Copies of audit records must be provided to the IRS when requested to investigate potential IRS security events. IRS contracts that are categorized as high must transmit audit records to the IRS central log repository.
The Contractor must send questions regarding IRS record retention requirements to the COR, who will forward them to Privacy.
Contractors using a CSP must ensure that audit records are retained online for a minimum of 90 days to provide support for after-the-fact investigations of security incidents and preserve audit records offline in accordance with IRS record retention requirements.
18.11 AU-12 Audit Record Generation¶
Contractors, including those using Cloud Service Providers (CSPs), must configure information systems, applications, and services to generate audit records for security- and privacy-relevant events and provide the capability to select auditable events for applicable system components.
Audit records from applicable systems, applications, networks, endpoints, data stores, cloud services, APIs, and other relevant sources must be centrally collected and integrated with the contractor's Security Information and Event Management (SIEM) or equivalent security monitoring capability to support monitoring, analysis, reporting, and incident response.
For Artificial Intelligence (AI) systems and services supporting the IRS contract, contractors must generate audit records sufficient to identify and investigate anomalous behavior, unauthorized access or use, security and privacy events, and other potentially harmful activity. AI audit records must be integrated with the contractor's security monitoring capabilities.
Audit records must be protected and retained in accordance with applicable Publication 4812 audit logging, retention, and records management requirements.
Supplemental C-SCRM Guidance: Contractors must ensure that audit record generation mechanisms are in place to capture all relevant supply chain auditable events. Examples of such events include component version updates, component approvals from acceptance testing results, logistics data-capturing inventory, or transportation information. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
60
18 .12 AU-13 Monitoring for Information Disclosure (C -SCRM Control)¶
Contractors must monitor social networking sites such as Facebook, X, Instagram and OpenSource information code sharing platforms such as GitHub, GitLab, Bitbucket, monthly for evidence of unauthorized disclosure of contractor information.
If an information disclosure is discovered, the contractor must notify the IRS COR immediately upon discovery and take actions to have the unauthorized information removed and identify the source of the unauthorized disclosure.
18 .13 AU-14 Session Audit ( C-SCRM Control)¶
Contractors must provide the Session Audit, or SAs the capability to record, view, and/or log the content of a user session as part of an investigation.
Session auditing activities must be developed, integrated, and used in consultation with legal counsel and in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.
18.14 AU-16 Cross Organization Audit Logging | Sharing of Audit Information (C-SCRM…¶
Contractors must identify, through an organizational sharing agreement, cross-organizational audit information sharing requirements.
19.2 CA-2 Control Assessments¶
Contractors, including those using CSPs, must develop and maintain a Security and Privacy Control Assessment Plan (SAP) and Security and Privacy Control Assessment Report (SAR). The SAP must be reviewed and approved by the Authorizing Official (AO) or designated Privacy Official before assessment activities begin.
The SAR must document control assessment results, identified control deficiencies, corrective actions, and the results of validation or retesting activities. Contractors must retain assessment evidence for the duration of the IRS contract and, upon request, provide SAP, SAR, and supporting assessment artifacts to the CSCA Team for review.
Security and privacy control assessments must be conducted by an independent assessment team at least annually and whenever significant changes are made to the information system, security architecture, privacy environment, supporting infrastructure, or operating environment. The assessment team must be organizationally independent of the personnel responsible for developing, implementing, operating, or managing the controls being assessed. Personnel performing independent security assessments should possess appropriate experience, technical competence, and knowledge of NIST SP 800-53 Rev. 5 security and privacy controls.
Assessments must verify that applicable security and privacy controls are implemented correctly, operating as intended, and effective in meeting IRS Publication 4812 requirements. Assessment activities must include documentation reviews, personnel interviews, and technical control testing sufficient to support an objective evaluation of the system's security and privacy posture.
Where Artificial Intelligence (AI) systems, services, models, or AI-enabled capabilities are used in support of the IRS contract, assessments must also evaluate AI-specific risks, including data protection, model integrity, unauthorized modification, prompt injection, adversarial manipulation, model poisoning, misuse, third-party dependencies, and supply chain risks.
An IRS Contractor Security Assessment (CSA) is performed independently of the Contractor's internal security control assessment program and does not replace or satisfy the Contractor's responsibility to conduct independent security and privacy control assessments or demonstrate the ongoing effectiveness of implemented security and privacy controls.
62
19.3 CA-3 Information Exchange¶
Contractors, including those using CSPs that use external information systems in support of the IRS contract, must establish and maintain documented trust relationships with each external information system. Trust relationships must be implemented through technical controls and an Interconnection Security Agreement (ISA).
Contractors must identify and document all external information systems and external system components that connect to, process, store, or transmit IRS information and provide this information to the IRS upon request. Contractors must review each Information System Agreement (ISA) at least annually to ensure it remains accurate, complete, and reflects the current operating environment. The ISA must be updated whenever changes occur that affect the interconnection, system architecture, security requirements, data exchange, ownership, or responsibilities defined within the agreement. Contractors must maintain an inventory of all external information systems and system interconnections that support the IRS contract.
Contractors must implement a deny-by-default, permit-by-exception policy for all connections to external information systems. All systems and devices connected to contractor networks that process, store, or transmit IRS information must be configured in accordance with the security and privacy requirements of IRS Publication 4812.
These requirements apply only to dedicated system-to-system interconnections and do not apply to transitory, user-controlled connections (e.g., email, web browsing) or to external telecommunications providers that solely provide transmission services.
Supplemental C-SCRM Guidance: The exchange of information or data between the information system and other systems requires scrutiny from a supply chain perspective. This includes understanding the interface characteristics and connections of those components/systems that are directly interconnected or the data that is shared through those components/systems with developers, system integrators, external system service providers, other ICT/OT-related service providers, and – in some cases – suppliers.
Proper Service-Level Agreements (SLA) must be in place to ensure compliance to system information exchange requirements defined by the contractor/subcontractor, as the transfer of information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies.
Examples of such interconnections can include:
A shared development and operational environment between the contractor and system integrator.
Product update/patch management connection to an off-the-shelf supplier, and
Data request and retrieval transactions in a processing system that resides on an external service provider shared environment.
63
Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
19.4 CA-5 Plan of Action and Milestones (POA&M)¶
Contractors must document all security and privacy findings identified through Contractor Security Assessments (CSAs) and continuous monitoring activities by creating a POA&M. The POA&M must identify corrective actions, planned remediation activities, responsible parties, milestones, and estimated completion dates for each finding. Contractors must update milestone completion dates whenever remediation schedules change and document the reason for any delays.
Within 30 business days of the issuance of the CSA Initial Findings Report, the contractor must submit an initial POA&M and supporting remediation evidence to the Contracting Officer's Representative (COR) and the CSCA Team at IT.Cyber.CSA.POAM@irs.gov.
Following the initial submission, the contractor must provide a monthly POA&M update to the COR and the CSCA Team until all findings have been validated and closed by the CSCA Team. Each update must include supporting remediation evidence for completed corrective actions or a status update describing remediation progress for findings that remain open.
Contractors must prioritize POA&M items based on risk and remediate assessment findings within the following maximum timeframes, measured from the date the CSA Initial Findings Report is issued:
High Risk: 60 calendar days
Moderate Risk: 90 calendar days
Low Risk: 120 calendar days
Failure to submit a required POA&M or maintain remediation progress in accordance with the required timelines constitutes noncompliance with the contract terms and conditions and may result in the COR withholding invoice approval until the contractor returns to compliance.
19.6 CA-7 Continuous Monitoring¶
Contractors, including those using CSPs, must establish, implement, and maintain a risk-based continuous monitoring strategy to assess the ongoing effectiveness of security and privacy controls and support the timely identification and remediation of security, privacy, and compliance issues throughout the system lifecycle.
At a minimum, the continuous monitoring strategy must:
Integrate configuration management, security and privacy impact analyses, ongoing control assessments, vulnerability management, and risk monitoring activities.
Include active and ongoing monitoring of security and privacy controls, including configuration compliance, vulnerability management, and other security monitoring activities, to verify controls remain implemented, operating as intended, and effective.
Assess the impact of significant changes to information systems, applications, cloud services, system components, or the operating environment on the security and privacy posture.
Monitor the effectiveness of implemented controls, compliance with applicable security and privacy requirements, and changes that could affect the system's risk posture.
Report the security and privacy status of the information system, identified deficiencies, and remediation activities to the Contractor Security Representative (CSR) and other designated personnel.
Continuous monitoring activities must be integrated with the Contractor's risk management, configuration management, incident response, vulnerability management, and authorization processes to support informed risk-based decisions and maintain the security and privacy posture of information systems supporting the IRS contract.
Contractors, including those using CSPs, must perform authenticated operating system (OS), database, and web application vulnerability and configuration scans at least monthly to identify security weaknesses and misconfigurations.
An independent assessor must perform a comprehensive vulnerability assessment of operating systems, databases, and web applications at least annually to validate the effectiveness of the
65
organization's vulnerability management program and identify vulnerabilities that may not be detected through routine internal scanning.
Contractors, including those using Cloud Service Providers CSPs, must continuously review risks associated with Artificial Intelligence (AI) systems and update governance, security, and privacy controls whenever significant changes occur to AI systems, models, data sources, software dependencies, or the operational environment. Significant changes must be evaluated through the contractor's continuous monitoring, risk management, and configuration management processes to ensure security and privacy controls remain effective and appropriate throughout the AI system lifecycle.
19.7 CA-8 Penetration Testing¶
Contractors, including those using CSPs, must conduct independent penetration testing before an information system is placed into production and annually thereafter. Penetration testing must also be performed following significant changes to the information system, security architecture, or operating environment that could affect the system's security posture. Penetration testing must include both external and internal attack scenarios where applicable.
19.8 CA-9 Internal System Connections¶
Contractors and subcontractors, including those using CSP’s must authorize any internal connections to IT assets processing IRS SBU data and document the interconnection characteristics, security and privacy requirements, and the type of information being transmitted between IRS assets and any other internal contractor information systems. The contractor must review connections annually to ensure connections are still needed.
20.0 Configuration Management (CM)¶
The Configuration Management (CM) control family establishes requirements for developing, maintaining, and controlling secure configuration baselines for information systems throughout the system lifecycle. These controls help ensure that authorized changes are properly evaluated, approved, documented, implemented, and monitored to maintain the security, integrity, and reliability of information systems supporting the IRS contract.
20.1 CM-1 Configuration Management Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the CM policy and procedures. Security and privacy programs must collaborate on the development of the CM policy and procedures.
The policies and procedures must address:
Purpose
Scope
Roles
66
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor or CSP must review/update CM policies and procedures annually, or if there is a significant change to ensure adequate CM policy and procedures are developed and implemented.
20.2 CM-2 Baseline Configuration¶
Contractors, including those using CSPs, must develop, document, implement, and maintain a current baseline configuration for all information system components. Baseline configurations must establish a secure, standardized configuration for hardware, software, firmware, operating systems, virtual machines, cloud resources, containers, applications, databases, network devices, mobile devices, Bios, and security appliances prior to deployment into production.
The Contractor or CSP must review and update the baseline configuration of the information system; annually, when there is a significant change, as an integral part of information system component installations and upgrades.
The contractor must implement standard BIOS settings for computers and devices to improve security.
These settings must:
Turn on security features that help prevent unauthorized changes to the system and cannot be easily bypassed (if those features can be configured).
Implement BIOS passwords and enforce the organization's password rules.
Control the order in which the device can start up (boot), such as requiring it to boot from the internal hard drive instead of allowing someone to start it from a USB drive or other external device.
The Contractor or CSP must retain at least one previous version of the baseline configuration to support rollback. The Contractor or CSP must use automated mechanisms to retain the current configuration baselines. Automated mechanisms that help organizations maintain consistent baseline configurations for systems include configuration management tools, hardware, software, firmware inventory tools, and network management tools.
The Contractor or CSP must maintain a baseline configuration for system development and test environments that are managed separately from the production baseline configuration.
Supplemental C-SCRM Guidance: Contractors must establish baseline configuration of both the production information system and the development environment, including documenting, formally reviewing, and securing the agreement of stakeholders. The purpose of the baseline is to provide a starting point for tracking changes to components, code, and/or
67
settings throughout the SDLC. Regular reviews and updates of baseline configurations (i.e., re-baselining) are critical for traceability and provenance.
The baseline configuration must take into consideration the Contractor’s production environment and any relevant supplier, developer, system integrator, external system service provider, and other ICT/OT-related service provider involvement with the organization’s information systems and networks.
If the system integrator, for example, uses the existing organization’s infrastructure, appropriate measures should be taken to establish a baseline that reflects an appropriate set of agreed-upon criteria for access and operation. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
20.3 CM-3 Configuration Change Control¶
Contractors, including those using CSP’s must develop and implement a configuration change control process that includes include a written change request to be submitted to the appropriate Change Control Board (CCB) for all changes, scheduled and unscheduled. The CCB must include information security and privacy representatives. The process must ensure that all changes are approved, tested, documented, and published; using a change control log that is available for review. The change log must be retained using automated tools, such as: change management software, spreadsheets, databases, etc. Change management logs must be retained for the life of the IRS contract.
Development and testing environments must be physically and/or logically separated from production environments. The Contractor must test, validate, and document changes to the test information system before implementing the changes on the production information system.
Configuration change control includes changes to baseline configurations, configuration items of systems, operational procedures, configuration settings for system components, vulnerability remediation and unscheduled or unauthorized changes. For changes that impact privacy risk, the contractor’s representative for privacy must update privacy impact assessments.
Supplemental C-SCRM Guidance: Contractors must determine, implement, monitor, and audit configuration settings and change controls within the information systems and networks and throughout the SDLC. This control supports traceability for C-SCRM. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
20.4 CM-4 Impact Analysis¶
Contractors, including those using Cloud Service Providers (CSPs), must analyze all proposed changes to the information system prior to implementation as part of the formal change management and approval process. The analysis must evaluate the potential security and privacy impacts.
68
Impact analysis includes reviewing security and privacy plans to understand control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security and privacy impact analysis may also include assessments of risk to better understand the impact of the changes and to determine if additional security or privacy controls are required.
If potential changes to a system create new risks to the privacy of individuals and the ability of implemented controls to mitigate those risks, then the contractor must notify and work with the COR to update the PCLIA.
20.5 CM-5 Access Restrictions for Change¶
Contractors must define, document, approve, implement, and enforce physical and logical access restrictions governing changes to the information system and its components.
Contractors must restrict the ability to modify information system components, configurations, and system-related information within the information system to authorized personnel with a documented business need. Privileged access authorizations must be reviewed and revalidated at least quarterly and updated promptly when no longer required.
Contractors must restrict configure information system devices to prevent unauthorized booting from removable media or other unapproved boot sources. Boot order settings, firmware (BIOS/UEFI) configurations, and other applicable hardware security features must be configured to ensure that systems can only boot from organization-approved devices and that controls intended to protect the information system cannot be bypassed.
20.6 CM-6 Configuration Settings¶
Contractors, including those using CSP’s, must establish and document configuration settings for information technology products employed within the information system using security configuration tools. Configuration settings are the parameters that can be changed in the hardware, software, or firmware components of the system that affect the security and privacy posture or functionality of the system. The contractor must run compliance scans on the information system at least monthly.
The contractor must use software (COTS or Open Source) compatible with the Security
Content Automation Protocol (SCAP) when monitoring security configuration settings . T he¶
Security Content Automation Protocol (SCAP) is a standardized framework that allows security tools to automatically identify vulnerabilities, assess compliance with security policies, and share security information. SCAP uses common formats and definitions so that different security products can exchange and use the same vulnerability and compliance data. Any deviations from established configuration settings for information system components must be identified, documented, and approved based on operational requirements. Changes to the configuration settings must be monitored and controlled in accordance with defined configuration change management policies and procedures.
69
Contractors, including those using CSP’s, must document all deviations from the standard security controls and ensure these are brought into compliance using a standard configuration process.
Contractors, including those using CSP’s must ensure that they or the CSP verify that the configuration settings are established and documented for information technology products employed within the information system using United States Government Configuration Baseline (USGCB). If USGCB is not available, the contractor or CSP must use the Center for Internet Security (CIS) guidelines (Level 1) to establish configuration settings.
Supplemental C-SCRM Guidance: Contractors must oversee the function of modifying configuration settings for their information systems and networks and throughout the SDLC. Methods of oversight include periodic verification, reporting, and review. Resulting information may be shared with various parties that have access to, are connected to, or engage in the creation of contractor information systems and networks on a need-to-know basis. Changes must be tested and approved before they are implemented. Configuration settings must be monitored and audited to alert designated Contractor personnel when a change has occurred. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
20.7 CM-7 Least Functionality¶
Contractors, including those using Cloud Service Providers (CSPs), must configure information systems and IT assets supporting the IRS contract to provide only the functions, ports, protocols, software, services, and capabilities necessary to support authorized operations. Unnecessary or insecure functionality must be disabled or removed.
Contractors must establish and maintain secure configuration requirements that identify prohibited or restricted functions, ports, protocols, services, and software. Configuration requirements must be based on applicable CIS Benchmarks. Legacy or insecure protocols and services must be disabled unless their use is documented, authorized, and supported by appropriate risk mitigation.
Contractors must identify software authorized to execute within information systems and implement application control mechanisms using a deny-all, allow-by-exception approach. Unauthorized, prohibited, unsupported, or unlicensed software must be prevented from executing or removed when identified.
Contractors must review system functionality, configurations, and authorized software at least annually and when significant system or technology changes occur. Reviews must identify and remove or disable unnecessary functions, ports, protocols, services, and software and verify that authorized software inventories remain current. Automated mechanisms must be used, where technically feasible, to identify unauthorized software and deviations from approved configurations.
70
Supplemental C-SCRM Guidance: Contractors must select components that allow flexibility to specify and implement least functionality. Contractors must ensure least functionality in their information systems and networks and throughout the SDLC. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
20.8 CM-8 System Component Inventory¶
Contractors including those using CSP’s must develop and maintain an inventory of all hardware, software, removable media, components, and a software allowlist/denylist for the information system that supports the IRS contract. The inventory must include: an inventory serial number, description of the inventory item, owner of the inventory item, date placed in inventory, and date inventory was validated. The inventory must not include duplicate accounting of components or components assigned to any other system. The inventory must be reviewed and reconciled annually. The inventory must be sufficient to enable recovery of IT assets that are identified as lost, stolen, or disclosed. The contractor or CSP must update the inventory of information system components as an integral part of component installations, removals, and information system updates.
Where Artificial Intelligence (AI) systems, services, models, or AI-enabled capabilities are used in support of the IRS contract, contractors, including those using CSPs, must establish, maintain, and review at least annually an inventory of all AI capabilities supporting the IRS contract. The AI inventory must be updated whenever AI capabilities are added, modified, replaced, retired, or removed from the information system and made available to the IRS upon request.
At a minimum, the AI inventory must identify:
AI system, application, service, model, or agent name.
Business purpose and authorized use.
System owner and responsible organization.
Hosting environment (on-premises, cloud service provider, or third-party service).
AI model or service provider.
AI model type (e.g., Generative AI, Large Language Model (LLM), Machine Learning (ML), Predictive AI).
IRS data classifications processed, stored, transmitted, or accessible by the AI capability (e.g., IRS SBU, PII, FTI).
Interfaces with contractor, subcontractor, third-party, and IRS information systems.
Authorization status and applicable security assessment documentation.
Data sources used for training, fine-tuning, retrieval, or inference, where applicable.
Security and privacy controls are implemented to protect the AI capability.
Associated software dependencies, plugins, APIs, orchestration services, and supporting components.
71
20.8.1 Notification of Significant Changes
Contractors, including those using CSPs, must notify to the COR and the CSCA team at IT.Cyber.CSA.POAM@irs.gov. of planned or implemented significant changes that could affect the security or privacy of IRS SBU data. Notification must be provided before implementation, or as soon as possible after emergency changes.
Significant changes include, but are not limited to:
Changes to the system authorization boundary.
Migration to or between Cloud Service Providers (CSPs).
Major hardware, software, operating systems, or platform upgrades.
Significant architectural or network changes.
Introduction of new external connections or third-party services.
Implementation of new security technologies or significant changes to existing security controls.
Introduction or significant modification of Artificial Intelligence (AI) capabilities that could impact IRS SBU.
Changes affecting the confidentiality, integrity, or availability of IRS SBU, FTI, or PII.
Upon notification, the CSCA team will determine whether the change requires a new Contractor Security Assessment (CSA) needs to be conducted.
The Contractor or CSP must employ automated mechanisms to detect the presence of unauthorized hardware, software, and firmware components within the information system and must take the following action when unauthorized components are detected:
Disable network access by such components,
Isolate the components, and
If elevated to an incident the COR must be notified immediately upon discovery.
Supplemental C-SCRM Guidance: Contractors must ensure that critical component assets within the information systems and networks are included in the asset inventory. The inventory must also include information for critical component accountability. Inventory information includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and – for networked components or devices – machine names and network addresses. Inventory specifications may include the manufacturer, device type, model, serial number, and physical location. Contractors should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
Contractors must specify the requirements and how information flow is enforced to ensure that only the required information - and no more - is communicated to the various participants in the supply chain. If information is collected and parsed downstream, there should be information about who created the subset information. Contractors must consider producing Software Bill of Materials (SBOM) for applicable and appropriate software classes, including purchased software, open-source software, and in-house software.
72
20.9 CM-9 Configuration Management Plan¶
Contractors including those using CSP’s must develop, document, and implement a CM plan for the information system that addresses roles, responsibilities, and CM processes and procedures. A process must be established for identifying configuration items throughout the SDLC and for managing the configuration of the configuration items. Configuration items for the information system must be defined, and configuration items must be placed under Configuration Management. The CM plan must be reviewed annually and approved by contractor or CSP designated personnel and protected from unauthorized disclosure and modification.
Supplemental C-SCRM Guidance: Contractors must ensure that C-SCRM is incorporated into CM planning activities. Contractors should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
20.10 CM-10 Software Usage Restrictions¶
Contractors, including those using CSPs, must implement software asset management practices to ensure that software, cloud-based services, and associated documentation are used only in accordance with applicable license agreements, contract terms, vendor usage restrictions, and copyright laws. Contractors must maintain an accurate inventory of software licenses and subscriptions, continuously track license allocation and consumption, reconcile deployed software and cloud services against purchased entitlements, promptly remediate any licensing discrepancies, and retain documentation demonstrating ongoing compliance with licensing requirements.
Contractors, including those using Cloud Service Providers (CSPs), must establish and enforce controls governing the acquisition, evaluation, deployment, and use of open-source software (OSS) used in support of IRS contracts. Contractors, including those using CSPs remain responsible for managing and securing OSS used within contractor-managed applications, workloads, development environments, software dependencies, libraries, frameworks, containers, development tools, and other system components. The use of a CSP does not transfer or eliminate the contractor’s responsibility for identifying, monitoring, and managing OSS in accordance with applicable IRS security and supply chain risk management requirements.
At a minimum, contractors must ensure the following:
A security assessment is completed before open-source software is introduced into the information system or development environment to evaluate security, privacy, operational, and supply chain risks.
A documented software support and maintenance plan is established to address version management, security updates, vulnerability monitoring, patch management, and end-of-life replacement.
The open-source software license is reviewed and approved by the contractor to ensure it permits internal use and modification without requiring the contractor or
73
the IRS to publicly disclose proprietary, contract-developed, or IRS-related source code.
Modifications, enhancements, code fixes, or other derivative works developed specifically in support of an IRS contract must not be publicly released, published, or contributed to public repositories unless expressly authorized in writing by the IRS and permitted under the applicable licensing agreement.
Contractors must monitor approved open-source software monthly for newly disclosed vulnerabilities, malicious or compromised packages, license changes, and end-of-support status, and promptly remediate identified risks in accordance with Publication 4812 vulnerability management requirements.
Contractors must maintain an inventory of approved open-source software components, including version information, licensing information, and dependency relationships, to support software asset management and software supply chain risk management.
20.11 CM-11 User-Installed Software¶
Contractors, including those using CSPs, must establish, document, and enforce policies governing the installation of software on information systems used to support IRS contracts. Software installation must be restricted to authorized personnel and approved software in accordance with the contractor's configuration management and change management processes.
At a minimum, contractors must enforce software installation policies through the following methods:
Procedural controls, such as periodic reviews of user accounts, installed software inventories, and administrative privileges to verify compliance with approved software installation policies.
Technical controls, such as application allowlisting, endpoint management solutions, privileged access management, Mobile Device Management (MDM), enterprise configuration management tools, or other automated mechanisms that prevent or restrict the installation of unauthorized software.
Continuous monitoring to detect, alert on, investigate, and remediate unauthorized software installations, configuration changes, or policy violations.
Annual reconciliation of installed software against the organization's authorized software inventory to identify and remove unauthorized, unsupported, or unlicensed software.
To maintain control over software installed on information systems used to support IRS contracts, contractors, including those using CSPs, must define and enforce permitted and prohibited software installation activities. Software may only be installed, updated, or removed by authorized personnel or through approved automated management tools.
Permitted software installation activities include the deployment of approved software, security patches, updates to existing applications, and installation of software obtained from
74
contractor-approved or vendor-authorized repositories, application stores, or software distribution services.
Prohibited software installation activities include the installation or execution of unauthorized, unapproved, counterfeit, pirated, unsupported, end-of-life, or malicious software, as well as software obtained from untrusted or unverified sources.
Contractors must prevent the installation of software with unknown provenance or software that has not undergone appropriate security, licensing, and supply chain risk reviews.
Unauthorized software must be promptly identified, investigated, and removed in accordance with established incident response and configuration management procedures.
20.12 CM-12 Information Location¶
Contractors, including those using CSP’s, must identify and document:
The location of IRS SBU data and the specific system components on which the information is processed and stored, and
The users who have access to the system and system components where the information is processed and stored.
Contractors, including those using CSP’s, must utilize automated information location tools to manage the data produced during information location activities and share information across the organization. Changes to the location where the information is processed and stored must be tracked and documented.
21.0 Contingency Planning (CP)¶
The Contingency Planning (CP) control family establishes requirements for preparing for, responding to, and recovering from disruptions that could affect the availability of information systems and SBU data. These controls help ensure that contractor operations can be restored within established recovery objectives through effective contingency planning, backup and recovery capabilities, alternate processing and storage arrangements, testing, and continuous maintenance of contingency plans.
21.1 CP-1 Contingency Planning Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the CP policy and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
75
- Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
Contractors, including those using CSP’s, must review/update CP policies and procedures annually, or if there is a significant change that defines company requirements in terms of IT CP or following certain events including: assessment or audit findings, and security or privacy incidents.
The contingency plan must be updated to address changes to the organization, system, or environment of operation, and problems encountered during contingency plan implementation, execution, or testing. Lessons learned from contingency plan testing, training, or actual contingency activities must be incorporated into contingency testing and training.
The policies and procedures must be sufficient to address the planning elements required for a contractor, subcontractor, or CSP environment. Policies and procedures must address the need to identify essential business functions supported, provide restoration priorities, and identify contingency roles and responsibilities.
Disaster recovery plans must be developed, tested, and maintained for mission or business critical systems for use if normal operations cease.
21.2 CP-2 Contingency Plan¶
Contractors, including those using CSP’s, must develop a contingency plan to address IT and physical contingency planning. Contingency plans must identify key business functions provided to the IRS, alternate work sites, alternate resources, contact information, and define the Recovery Time Objective (RTO) and the Recovery Point Objective (RPO). The defined RPO shall be equal to or less than the effective backup interval, based on the frequency of full, incremental, differential, or other approved backup mechanisms used to support data recovery. The contingency plan must document the activities associated with restoring all IT assets, including information systems and applications after a disruption or failure. The Contingency Plan must be reviewed/updated at least annually.
Contractors with contracts that support IRS Filing Season systems/processes and/or IRS Mission Essential Functions (MEFs), the RPO and RTO defined in the contractor/subcontractor CP must be the same as the RPO and RTO defined in the IRS MEF’s CP. The RPO and RTO for IRS Filing Season systems/processes and/or IRS MEFs must be obtained from the COR. Where applicable, when a contractor supports an MEF system, the Maximum Tolerable Downtime of 12-hours end-to-end must be considered in the disaster recovery plans and cloud computing requirements.
As part of CP, an Occupant Emergency Plan (OEP) must be included to address occupant safety and security procedures, in the event of an emergency. The OEP should be shared with all personnel who have work related to the IRS contract or any impacted personnel. At least
76
annually, the plan must be reviewed, updated, with OEP drills being conducted. The results must be documented, and lessons learned are incorporated into the OEP.
Contractors, including those using CSP’s, must distribute copies of the CP to key personnel who are responsible for implementing and ensuring updates are communicated. A copy of the CP must be provided annually to the COR.
The CP is considered SBU data and must be protected from unauthorized disclosure and modification.
Contractors, including those using CSP’s, must coordinate CP development with contractor groups responsible for related plans. Related plans include Business Continuity Plans (BCP), Disaster Recovery Plans, Critical Infrastructure Plans, Continuity of Operations Plans, Crisis Communications Plans, Insider Threat Implementation Plans, Data Breach Response Plans, Cyber Incident Response Plans, Breach Response Plans, and OEP.
21.2.1 CP-2(7) Contingency Plan | Coordinate with External Service Providers (C-SCRM Control)
Contractors must coordinate their CP with the CPs of their external service providers to ensure that contingency requirements can be satisfied.
21.3 CP-3 Contingency Training¶
Contractors, including those using CSP’s, must train personnel in their contingency roles and responsibilities within 30 days of assuming a contingency role or responsibility, when changes to the information system are sufficient to warrant the training, and to provide refresher training annually.
Training content must be reviewed and updated annually, when there are major system changes, or following certain events including: CP testing, security or privacy assessments, audit findings, and security or privacy incidents.
Supplemental C-SCRM Guidance: Contractors must ensure that critical suppliers are included in contingency training. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
21.4 CP-4 Contingency Plan Testing¶
Contractors, including those using CSP’s must develop and test a CP to ensure that operations can be restored. CPs must be tested annually, the contractor or CSP must review the CP testing results and initiate corrective actions. CP testing must include a tabletop exercise and functional testing. Cloud failover, backup restoration, and telework continuity must be included in CP testing. A copy of the CP testing results must be provided to the COR within 30 days of test execution along with any documentation and corrective actions to be taken by the contractor.
77
The results of each CP test must be reviewed and documented. At a minimum, the following items must be included in the CP test:
Name of Test
Name of System
Date of Test
Testing point of contact
Purpose, Type of Test, and Scope
Objectives
Methodology
Activities and Results (Action, Expected Results, Actual Results)
Action Item Assessment
21.5 CP-6 Alternate Storage Site¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and maintain one or more alternate storage sites to securely store and retrieve backup data, backup media, and system recovery information necessary to support the restoration of operations.
Contractual agreements, service-level agreements (SLAs), or other documented arrangements must be in place to ensure the availability, integrity, and timely retrieval of backup information.
Backup information, backup media, and backup data containing IRS Sensitive But Unclassified (SBU) information must be protected using FIPS 140-3 or later validated modules for data at rest and during transmission. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
The alternate storage site must be geographically or physically separated from the primary storage location to minimize the likelihood that the same natural disaster, cyber incident, infrastructure failure, or other disruptive event will affect both locations. For cloud-based backup services, contractors must ensure backups are replicated across separate availability zones, regions, or geographically distinct facilities, to provide equivalent separation and resiliency.
The alternate storage site must provide security and privacy safeguards equivalent to or greater than those implemented at the primary storage site, including controls for physical security, logical access, encryption, environmental protection, monitoring, and availability. The alternate storage capability must support the Recovery Time Objectives (RTOs), Recovery Point Objectives (RPOs), and continuity requirements established for the information system.
78
Contractors must identify potential risks that could limit access to the alternate storage site during localized or regional disruptions, including transportation outages, telecommunications failures, cloud service disruptions, and other infrastructure dependencies. Documented contingency measures must be established, maintained, and annually tested to mitigate these risks and ensure timely access to backup information and recovery resources during an emergency.
21.6 CP-7 Alternate Processing Site¶
Contractors, including those using CSP’s must establish an alternate processing site, including the necessary agreements to permit the transfer and resumption of information systems operations for essential mission and business functions within specified timeframes consistent with the RTO and RPO.
Contractors, including those using CSP’s, must ensure that the equipment and supplies required to resume operations at the alternate site are in place, or that required equipment/supplies are made available within specified timeframes, to avoid unacceptable delays in the delivery of contracted services. Alternate processing sites are locations that are sufficiently separated from the primary processing sites to reduce susceptibility to the same threats. The systems, personnel, and physical security controls must be commensurate with the sensitivity of the information being restored, and with the security of the primary processing site.
Potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster must be identified and explicit mitigation actions must be outlined.
Alternate processing site agreements must be developed that contain priority-of-service provisions (e.g., SLA) in accordance with the organization’s availability requirements (including the RTO).
The Contractor must develop policies and procedures to safeguard IRS SBU data for work performed at alternate processing sites such as approved telework locations.
21.6.1 Contractor Telework Requirements
Contractors must ensure the following eligibility requirements are met before contractor personnel are approved to telework in support of the IRS contract.
IRS Approval Contractors must receive approval in writing from the IRS COR, Business Unit, or in the IRS contract before allowing contractor personnel to support the IRS contract from an approved telework location.
Telework Training Contractor personnel that want to utilize telework to support the IRS contract must complete annual telework training. Telework training can be provided by the contractor.
79
Signed Telework Agreement A telework agreement must be utilized to confirm the employees’ understanding and acceptance of their responsibilities for protecting IRS SBU data and communicating requirements for a suitable work environment.
The telework agreement at a minimum must include the following information:
The terms and conditions of the telework arrangement between the voluntarily participating contractor and their organization.
Telework agreements must be signed/dated by the applicant and include their telework location address, and
The telework agreement must be signed/dated by the contractor’s supervisor/manager. Once signed by management, the applicant is eligible for telework; assuming all other conditions above are met.
Contractors approved to telework must only telework from the approved location and may not telework from any other location without prior contractor approval. Contractors working at an approved telework location must report all computer security and privacy incidents to contractor management immediately upon discovery. The contractor or the IRS reserve the right to terminate an employee’s ability to telework at will.
21.7 CP-8 Telecommunications Services¶
Contractors, including those using Cloud Service Providers (CSPs), must ensure that primary and alternate processing and storage sites have resilient telecommunications services sufficient to support system recovery and the resumption of operations within established recovery time objectives.
At a minimum, the Contractor or CSP must:
Establish and maintain telecommunications service agreements for primary and alternate processing locations that support business continuity and disaster recovery requirements, including priority-of-service provisions where applicable.
Implement redundant or alternate telecommunications services to eliminate single points of failure and maintain the availability of critical information systems and services during outages or disruptions.
Annually review and validate telecommunications capabilities and recovery arrangements to ensure they continue to meet operational and recovery requirements.
21.8 CP-9 System Backup¶
The Contractor must implement backup procedures for all IRS SBU data i ncluding user-level information, system-level information, including security and privacy related documentation.
80
System-level information includes system-state information, OS and application software, and licenses. User-level information includes any information other than system level information and/or IRS SBU data.
The Contractor must protect the confidentiality, integrity, and availability of backup information at storage locations. The contractor must test backup restoration semi-annually to verify backup reliability and information integrity.
The Contractor must implement FIPS 140-3 or later validated cryptographic modules to prevent unauthorized disclosure and modification of backup information. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
If a contractor stores FTI backup data in the cloud, the CSO must be FedRAMP Authorized at the Moderate or High impact level.
Contractors using a CSP must ensure that they or the CSP will conduct backups for information contained in the information system at the following frequencies:
User-level: Weekly
System level: Weekly
Information system configuration: Weekly
The Contractor or CSP must maintain:
At least three backup copies of user-level information (at least one of which is available online) or provide an equivalent alternative.
At least three backup copies of system-level information (at least one of which is available online) or provide an equivalent alternative.
At least three backup copies of information system documentation including security information (at least one of which is available online) or provide an equivalent alternative, and
Backup information must be tested to verify backup reliability and information integrity at least semiannually.
21.9 CP-10 System Recovery and Reconstitution¶
Contractors, including those using CSP’s must ensure that there are procedures in place to provide for the recovery and reconstitution of any IT assets or information system to a known state after a disruption, compromise, or failure within a timeframe consistent with contractor defined RTO and RPO.
Contractors with contracts that support IRS Filing Season systems/processes and/or IRS MEFs, the RPO and RTO defined in the Contractor CP must be the same as the RPO and RTO defined in the IRS MEF CP. The RPO and RTO for IRS Filing Season systems/processes and/or IRS MEFs must be obtained from the COR.
81
22.0 Identification and Authentication (IA)¶
The Identification and Authentication (IA) control family establishes requirements for uniquely identifying users, devices, and services and verifying their identities before granting access to information systems or IRS Sensitive But Unclassified (SBU) data. These controls help ensure that only authorized individuals and systems are authenticated using approved authentication mechanisms, supporting accountability and protecting the confidentiality, integrity, and availability of information systems.
22.1 IA-1 Identification and Authentication Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the IA policies and procedures for Security and Privacy Controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
Policies and procedures must be reviewed/updated annually, or if there is a significant change to IA security controls.
22.2 IA-2 Identification and Authentication (Organizational Users)¶
Contractors, including those using Cloud Service Providers (CSPs), must require users to be uniquely identified and authenticated before granting access to IT assets and information systems supporting the IRS contract. Identification must use a unique user or account identifier that provides individual accountability. Authentication must use authentication mechanisms such as passwords, cryptographic authenticators, smart cards, digital certificates, passkeys, biometrics, or multi-factor authentication (MFA).
Supplemental C-SCRM Guidance: Contractors must ensure that identification and requirements are defined and applied for Contractor users accessing an ICT/OT system or supply chain network. A Contractor user may include employees, individuals deemed to have the equivalent status of employees (e.g., contractors, guest researchers, etc.), and system integrators fulfilling contractor roles. Criteria such as “duration in role” can aid in defining which identification and authentication mechanisms are used. The Contractor may choose to define a set of roles and associate a level of authorization to ensure proper implementation.
82
Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
22.3 IA-3 Device Identification and Authentication¶
Contractors, including those using Cloud Service Providers (CSPs), must uniquely identify and authenticate devices before allowing them to establish local, remote, or network connections to information systems supporting the IRS contract.
Devices may be identified and authenticated individually, by device type, or through a combination of device and technology attributes.
Approved mechanisms include:
Device certificates and Public Key Infrastructure (PKI);
IEEE 802.1X network access control;
Extensible Authentication Protocol-Transport Layer Security (EAP-TLS);
RADIUS or other centralized authentication services;
Cryptographic device credentials or keys;
Mobile Device Management (MDM) or endpoint management solutions;
Device identity and posture validation associated with Zero Trust access; and
Other approved mechanisms that provide verifiable device identity and authentication.
22.4 IA-4 Identifier Management¶
Contractors, including those using Cloud Service Providers (CSPs), must establish, document, and implement processes for managing identifiers associated with users, accounts, devices, services, and other system resources supporting the IRS contract.
At a minimum, contractors must:
Change, disable, or otherwise secure default vendor- or factory-configured administrative accounts, identifiers, and authentication credentials before the system or component is placed into production.
Create and assign user identifiers only after receiving documented authorization from personnel designated to approve accounts, roles, groups, and associated access.
Assign unique identifiers to individual users to provide accountability and prevent the unauthorized sharing or reuse of identifiers.
Establish and maintain naming conventions that enable authorized personnel to identify and manage user, privileged, service, application, and other account types.
Manage identifiers throughout their lifecycle, including assignment, review, modification, disabling, and removal when no longer required.
Supplemental C-SCRM Guidance: Identifiers allow for greater discoverability and traceability. Within the Contractor’s supply chain, identifiers should be assigned to systems, individuals, documentation, devices, and components. In some cases, identifiers may be
83
maintained throughout a system’s life cycle – from concept to retirement – but, at a minimum, throughout the system’s life within the Contractor.
For software development, identifiers should be assigned for those components that have achieved configuration item recognition. For devices and operational systems, identifiers should be assigned when the items enter the Contractor’s supply chain, such as when they are transferred to the Contractor’s ownership or control through shipping and receiving or via download.
Suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers typically use their own identifiers for tracking purposes within their own supply chain. Contractors must correlate those identifiers with the Contractor-assigned identifiers for traceability and accountability. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
22.5 IA-5 Authenticator Management¶
Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time passwords, and ID badges. Device authenticators include certificates and passwords.
The Contractor information system for password-based authentication must implement the following password settings:
Passwords for Windows-based authentication must contain a minimum of 12 characters for user accounts.
Passwords for all other systems must contain a minimum of 8 characters.
Passwords for service accounts must contain a minimum of 14 characters.
• All systems enforce password complexity, to contain a combination of letters,
numbers, and special characters for all information system accounts.
For Windows-based systems, enforce a password minimum lifetime restriction of 1 day and maximum of 60 days.
For all other systems, enforce a password minimum lifetime restriction of 1 day and maximum of 90 days.
Must prohibit password reuse for 24 generations for Windows-based systems, and 10 generations for all other systems.
Encrypt passwords in storage and transmission.
New passwords selected for use must have at least 1 character changed from the previous password.
Allow the use of a temporary password for system logon, with an immediate change to a permanent password.
CSP issued/managed passwords must be:
- Changed every 60 days
84
Complex with a minimum of 14 characters; case sensitive, and at least one each of; upper-case letters, lower-case letters, numbers, and special characters.
Password enforcement must provide lifetime restrictions of 1 day minimum and 60 days maximum, and
Passwords must be prohibited from being reused for 24 generations.
For IT devices using a Personal Identification Number (PIN) as an authenticator, the PIN must meet the following requirements:
Minimum length of 8 digits,
No repeating digits (e.g., 44444444 or 12121212),
No sequential digits (e.g., 12345678, 87654321),
Not be stored with the device, and
Not be shared.
When Public Key Infrastructure (PKI) is used in the information system, it must:
Validate certificates by constructing a certification path with status information to an accepted trust anchor, including checking certificate status information.
Implement a local cache of revocation data to support path discovery and validation, and
Enforce authorized access to the corresponding private key.
The Contractor must ensure that the information system used to authenticate personnel has a backup mechanism able to assume authentication responsibilities in a timely manner if the primary authentication device fails.
The Contractor must require that the registration process to receive Homeland Security Presidential Directive-12 (HSPD-12) PIV cards be carried out in person, with a designated registration authority with authorization, by a designated contractor official (e.g., a supervisor). This only applies when contractors are also accessing IRS laptops/systems and/or facilities.
When passwords are lost, the Contractor must ensure there is a process to manage lost passwords to ensure information is not compromised. All vendor passwords or passwords issued with the information systems and applications must be changed, including any default passwords during implementation.
Personnel must be trained in the proper handling of individual passwords to prevent unauthorized use or modification.
Users must protect passwords, hardware tokens, and/or smart cards, and ensure they are not stored on, or with a laptop or portable electronic device (PED), unless encrypted or otherwise under the direct and continuous control of the authorized user.
85
Supplemental C-SCRM Guidance: This control facilitates traceability and non-repudiation throughout the supply chain. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors
22.6 IA-6 Authenticator Feedback¶
Contractors, including those using CSP’s, must ensure when using password or other authentication mechanisms, the information system or application must generate non-readable characters, such as asterisks to prevent this information from being viewed by unauthorized individuals.
22.7 IA-7 Cryptographic Module Authentication¶
Contractors, including those using Cloud Service Providers (CSPs), must use FIPS 140-3 validated cryptographic modules to protect IRS information whenever cryptographic protections are required. Cryptographic modules shall be implemented in accordance with NIST guidance and the Cryptographic Module Validation Program (CMVP). Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
When Kerberos is used for authentication, contractors must use approved AES-based Kerberos encryption types with appropriate SHA-2-based integrity protection. Deprecated, weak, or otherwise compromised encryption types, including DES, Triple-DES (3DES), RC4HMAC, and RC4-HMAC-EXP, are prohibited.
22.8 IA-8 Identification and Authentication (Non-Organizational Users)¶
Contractors, including those using Cloud Service Providers (CSPs), must ensure that publicfacing websites, portals, applications, application programming interfaces (APIs), and other externally accessible services requiring user authentication uniquely identify and authenticate each external user before granting access to protected resources or IRS Sensitive But Unclassified (SBU) data.
22.9 IA-9 Service Identification and Authentication (C-SCRM Control)¶
Contractors must ensure web applications querying a database must require unique identification and authentication before establishing communications with devices, users, or other services or applications.
Contractors must ensure that identification and authentication are defined and managed for access to services (e.g., web applications using digital certificates, services or applications that query a database as opposed to labor services) throughout the supply chain. Contractors must ensure that they know what services are being procured and the supplier of the service.
86
Services procured should be listed on a validated list of services for the Contractor or have compensating controls in place.
23.0 Incident Response (IR)¶
The Incident Response (IR) control family establishes the processes and capabilities necessary to prepare for, detect, analyze, contain, eradicate, recover from, and report security and privacy incidents. These controls help minimize the operational impact of security and privacy events, support the timely restoration of information systems, and strengthen the organization's ability to respond to and recover from future incidents while protecting IRS Sensitive But Unclassified (SBU) data.
23.1 IR-1 Incident Response Policy and Procedures¶
Contractors, including those using CSP’s, must designate an official to manage the development, documentation, and dissemination of the IR policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor, or CSP must review/update IR policies and procedures annually, if there is a significant change to IR policies and procedures, or after a security or privacy incident.
Supplemental C-SCRM Guidance: Contractors should integrate C-SCRM into IR policy and procedures, and related C-SCRM Strategy/Implementation Plans and Policies. The policy and procedures must provide direction for how to address supply chain-related incidents and cybersecurity incidents that may complicate or impact the supply chain. Individuals who work within specific mission and system environments need to recognize cybersecurity supply chain-related incidents. The IR policy should state when and how threats and incidents should be handled, reported, and managed.
Bidirectional communication with supply chain partners should be defined in agreements with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers to inform all involved parties of a supply chain cybersecurity incident. Depending on the severity of the incident, the need for accelerated communications up and down the supply chain may be necessary. Appropriate agreements should be put in place with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers to ensure speed of communication, response, corrective actions, and other related activities. Contractors should require their
87
prime contractors to implement this control and flow down this requirement to relevant subtier contractors.
23.2 IR-2 Incident Response Training¶
IR training for contractors assuming an IR role, is required within 30 days of assuming an IR role and responsibility, when required by information system changes, or when acquiring system access, and annually thereafter. Incident response training content must be reviewed and updated every three years and following significant changes. IR training must emphasize the obligation of individuals to report both confirmed and suspected breaches involving information in any medium or form, including paper, oral, and electronic. Training must include current cyber threat scenarios such as tabletop exercises that simulates a breach, ransomware, phishing, credential compromise, cloud security incidents, supply chain compromises, and AI-related security events, where applicable.
Supplemental C-SCRM Guidance: Contractors must ensure that critical suppliers are included in IR training. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
23.3 IR-3 Incident Response Testing¶
Contractors, including those using CSP’s, must annually test and/or exercise the IR capability to determine their IR effectiveness and document the results to ensure the security and privacy policies and procedures continue to function, as intended. Contractors and subcontractors must review NIST SP 800-61 Revision 3, Computer Security Incident Handling Guide for guidance on developing and maintaining their IR capabilities. Testing results must be documented, and IR policies and procedures must be updated to close any gaps found in the plan.
IR testing includes reporting phone numbers identified in contractor procedures are accurate, the use of checklists, walk-throughs, tabletop exercises, simulations, or comprehensive exercises. IR testing must include tabletop exercises that simulate a breach. IR test results, findings, and plan updates must be shared with the COR within 30 days of completion of the IR test.
23.4 IR-4 Incident Handling¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and maintain an incident response capability that enables the contractor to identify, analyze, contain, eradicate, recover from, and document security and privacy incidents affecting IRS Sensitive But Unclassified (SBU), Personally Identifiable Information (PII), or Federal Tax Information (FTI).
The incident response capability must include procedures for determining what information was accessed or could have been accessed, who accessed the information, the time of the activity, the methods and techniques used, and the initial attack vector. Incident handling
88
procedures must address preparation, detection and analysis, containment, eradication, recovery, and post-incident lessons learned.
Contractors must routinely track, document, and report security and privacy incidents and breaches involving IRS SBU, PII, or FTI. An incident involving unauthorized disclosure, loss of control, unauthorized acquisition, compromise, or similar unauthorized access to SBU, PII, or FTI must be treated as a breach.
Contractors must coordinate incident handling activities with contingency planning activities and incorporate lessons learned from incident response activities into incident response procedures, training, and testing or exercises.
Automated mechanisms must be used to support incident handling, including tools that capture live response data, perform network packet capture, and support forensic analysis and incident management.
When incidents involve cloud services or Artificial Intelligence (AI) capabilities supporting the IRS contract, contractors must identify affected cloud resources, AI models, training data, prompts, APIs, plugins, orchestration services, and relevant audit records. Incident response activities must include determining whether IRS SBU, PII, or FTI was accessed, disclosed, modified, or used to train or influence AI models.
A security incident as defined by OMB M-17-12 is an occurrence that:
Actually, or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system, or
Constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.
A data breach is the loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where:
A person other than an authorized user accesses or potentially accesses SBU, or
An authorized user accesses or potentially accesses SBU for other than authorized purposes.
A data breach is not limited to an occurrence where a person other than an authorized user potentially accesses SBU by means of a network intrusion, a targeted attack that exploits website vulnerabilities, or an attack executed through an email message or attachment (See Table 3: Examples of Security and Privacy Incidents ).
Often, an occurrence may first be identified as an incident but later identified as a data breach once it is determined that the incident involves unauthorized access and/or loss of controlled SBU, as is often the case with a lost or stolen laptop or electronic storage device. For the purposes of this section when referring to “incidents” it will include data breaches.
89
Whenever there is a compromise of IRS information, the contractor or CSP must contact the IRS COR immediately upon discovery of the incident or potential incident. The IRS must work closely with IRS contractors, and CSP’s to quickly respond to a suspected incident of unauthorized disclosure or inspection.
Types of incidents include the following (but not limited to):
Table 3: Examples of Security and Privacy Incidents
| Incident Type | Description |
|---|---|
| Denial of Service | An attack that prevents or impairs the authorized use of networks, information systems, or applications by exhausting resources. |
| Malicious Code |
A virus, worm, Trojan horse, or other code-based malicious entity that infects a host. |
| Unauthorized Access |
A person or information system gains logical or physical access without permission to a network, information system, application, data, or other resource. |
| Inappropriate Usage |
A person violates acceptable information system use policies or improper use of SBU data (e.g., IRC § 6713 and 7216). |
| Multiple Component |
A single incident that encompasses two or more incident types. |
| Theft |
Removal of information systems, data/ information system media or paper files. |
| Loss/ |
Accidental misplacement or loss of information systems, data/ |
| Disclosure of Sensitive Data |
Disclosure of sensitive data refers to the unauthorized, inadvertent disclosure of SBU/ |
23.4.1 IR-4 (10) Incident Handling | Supply Chain Coordination (C-SCRM Control)
Contractors must coordinate supply chain incident handling activities with their supply chain providers and the IRS.
23.5 IR-5 Incident Monitoring¶
Contractors, including those using Cloud Service Providers (CSPs), must document, track, and maintain records of all security incidents, privacy incidents, data breaches, and suspected compromises involving IRS Sensitive But Unclassified (SBU) data or information systems supporting the IRS contract.
Incident records must include, at a minimum, the nature of the incident, affected systems and information, incident status, response actions, corrective actions, lessons learned, and the results
90
of incident handling activities. Contractors must collect and evaluate incident information from appropriate sources, including security monitoring tools, audit logs, incident reports, incident response activities, user reports, physical security events, supply chain partners, and other relevant monitoring and detection capabilities, to identify trends, improve response capabilities, and support continuous improvement.
23.6 IR-6 Incident Reporting¶
Contractors, including those using CSP’s, must report a suspected incident or confirmed breach in any medium or form, including paper, oral, and electronic immediately upon discovery. Security, privacy and supply chain incidents related to IRS processing, SBU data, or contractor information systems must be reported immediately upon discovery to the:
CO and COR,
CSIRC Incident Response Operations Team at 833-575-9810or CSIRC@irs.gov
Within one hour of notification of the incident, the COR must complete the Computer Security Incident Reporting Form available @
https://www.csirc.web.irs.gov/incident/ and
• Within one hour of notification of the incident the COR must notify the CSCA team
@ it.cyber.csa.request@irs.gov.
Subcontractors who identify a suspected security incident or confirmed breach must report the incident immediately upon discovery to the prime contractor. The prime contractor is responsible for notifying the IRS in accordance with IR-6 Incident Reporting requirements.
Automated mechanisms must be employed to assist in the reporting of incidents. Automated reporting mechanisms include email and automated incident response tools.
Physical incidents must be referred to the Situational Awareness Monitoring Center (SAMC) at (866) 216-4809. In situations where there is a physical security incident involving IRS processing, SBU data, or contractor information systems, both CSIRC and SAMC must be contacted. CSIRC is available 24x7x365.
The COR must report the incident/data breach to the Treasury Inspector General for Tax Administration (TIGTA) hotline at (800) 366-4484 if the incident/data breach:
Involves FTI,
Threatens the safety or security of personnel or information systems, and/or
Involves a willful, unauthorized disclosure.
Failure of the Contractor to notify the IRS in the event of an incident within the required timeframe must be considered a breach of contract. The IRS reserves the right to remedies such as termination of the contract or assess liquidated damages as allowed with FAR clause 52.211-11 -- Liquidated Damages -- Supplies, Services, or Research and Development (September 2000).
91
23.6.1 IR-6 (3) Incident Reporting | Supply Chain Coordination (C-SCRM Control)
Contractors must report supply chain incident information to their supply chain providers and the IRS.
23.7 IR-7 Incident Response Assistance¶
Contractors, including those using Cloud Service Providers (CSPs), must identify and maintain incident response resources, including a help desk, incident response team, or other designated personnel, with the knowledge, training, and authority necessary to support the detection, analysis, containment, eradication, recovery, and reporting of security and privacy incidents affecting IRS Sensitive But Unclassified (SBU) data or information systems.
At a minimum, the Contractor or CSP must:
Designate personnel are responsible for providing incident response support and ensure they receive appropriate training and resources to perform their assigned responsibilities.
Implement automated tools and mechanisms to support the collection, sharing, analysis, and availability of incident response information.
Ensure incident response resources can support the timely restoration of affected systems and business operations following a security incident.
Cooperate fully with the IRS during incident response activities, including providing access to relevant personnel, systems, logs, records, and other information necessary to support inspection, investigation, forensic analysis, containment, recovery, or other authorized response activities.
Based on the severity or potential impact of a security incident, the IRS may provide incident response assistance or assume a more active role in incident handling. Contractors and subcontractors must fully support and cooperate with all authorized IRS incident response activities.
23.7.1 IR-7 (2) Incident Response Assistance | Coordination with External Providers (C- SCRM Control)
Contractors must have automated mechanisms to increase access to IR information and support.
Contractor agreements with prime contractors must specify the conditions under which a government approved or designated third-party would be available or may be required to provide assistance with incident response, as well as the role and responsibility of that thirdparty.
23.8 IR-8 Incident Response Plan¶
92
Contractors, including those using CSPs, must develop, implement, maintain, and review an Incident Response (IR) Plan at least annually and whenever significant changes occur to the information system, organizational structure, or incident response capability.
The IR Plan must be approved by the Contractor Security Representative and protected from unauthorized disclosure or modification.
At a minimum, the IR Plan must:
Define the organization's incident response strategy, objectives, governance, and organizational structure.
Identify roles, responsibilities, authorities, and designated incident response personnel or teams.
Define reportable security incidents, privacy incidents, and data breaches, including reporting and escalation procedures.
Describe incident response processes for preparation, detection, analysis, containment, eradication, recovery, and post-incident activities.
Define procedures for coordinating and sharing incident information with internal personnel, external organizations, service providers, and the IRS, as appropriate.
Identify the personnel, tools, technologies, communications, and management support necessary to maintain an effective incident response capability.
Establish performance measures or metrics to evaluate the effectiveness of the incident response program.
Include procedures for identifying the information and data elements involved in a security incident or data breach to support reporting, impact analysis, and recovery activities.
Be updated following significant system or organizational changes, testing activities, lessons learned, or actual security incidents to ensure the plan remains effective.
Supplemental C-SCRM Guidance: Contractors must coordinate, develop, and implement an IR plan that includes information-sharing responsibilities with critical suppliers, and, in a federal context, interagency partners and the FASC. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
23.9 IR-9 Information Spillage Response (C-SCRM Control)¶
Contractors must include the following in their information response activities:
Assignment of organizational roles and their responsibility for responding to information spill.
Identification of specific information involved in system contamination.
Alerting IR personnel of the information spill using a method of communication not associated with the spill.
Isolating the contaminated system or system component.
Eradicating the information from the contaminated system or component.
93
Identifying other systems or system components that may have been subsequently contaminated, and
Initial IR and subsequent update reporting to both the applicable external service providers and the IRS.
24.0 Maintenance (MA)¶
The Maintenance (MA) control family establishes requirements for the secure maintenance of information systems and system components to ensure their availability, integrity, and reliability throughout the system lifecycle. These controls help ensure maintenance activities are authorized, controlled, documented, and performed in a manner that protects IRS SBU data and maintains the continued operation of information systems supporting the IRS contract.
24.1 MA-1 Maintenance Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the MA policy and procedures.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update policies and procedures annually, or if there is a significant change in describing MA procedures to be used for that contractor site.
Supplemental C-SCRM Guidance: Contractors must ensure that C-SCRM is included in MA policies and procedures and any related SCRM Strategy/Implementation Plan, SCRM Policies, and SCRM Plan(s) for all Contractor information systems and networks. With many Maintenance contracts, information on mission-, Contractor-, and system-specific objectives and requirements is shared between the Contractor and its suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers, allowing for vulnerabilities and opportunities for attack. In many cases, the MA of systems is outsourced to a system integrator, and as such, appropriate measures must be taken. Even when MA is not outsourced, the supply chain affects upgrades, patches, the frequency of MA, replacement parts, and other aspects of system MA.
Maintenance policies should be defined for both the system and the network. The MA policy should reflect controls based on a risk assessment (including criticality analysis), such as remote access, the roles and attributes of maintenance personnel who have access, the
94
frequency of updates, duration of the contract, the logistical path and method used for updates or maintenance, and monitoring and audit mechanisms.
The Maintenance policy should state which tools are explicitly allowed or not allowed. For example, in the case of software maintenance, the contract should state the source code, test cases, and other item accessibility needed to maintain a system or components.
The Contractor should communicate applicable MA policy requirements to relevant prime contractors and require that they implement this control and flow down this requirement to relevant sub-tier contractors.
24.2 MA-2 Controlled Maintenance¶
Contractors, including those using CSP’s establish a formal information systems maintenance program, that applies to all types of Maintenance for all system components (including but not limited to; applications, servers, workstations, storage arrays, routers, switches, firewalls, scanners, copiers, and printers) conducted by any local or nonlocal entity (e.g., in-contract, warranty, in-house, software maintenance agreement).
Changes made to hardware or software during maintenance must be recorded per configuration management processes for the hardware or software.
The Contractor must maintain a log of all maintenance that includes, at a minimum:
Date and time of maintenance,
Name of individuals or group performing the maintenance,
Name of escort, if necessary,
Description of the maintenance performed, and
Information system components/equipment removed or replaced (including identification numbers, serial numbers, and/or barcodes, if applicable).
The Contractor must approve and monitor all maintenance activities, whether the equipment is serviced; on-site, remotely, or removed to another location. Maintenance policy must identify a maintenance window to obtain maintenance support for information system components in the event of failure.
When off-site maintenance or repairs are required, the CSR must explicitly approve, with an approval letter or form, the removal of system components from the Contractor’s facilities. The Contractor must sanitize equipment to remove all information from associated storage prior to removal from the contractor’s facilities for off-site maintenance repair, or replacement. Any equipment that cannot be sanitized must be destroyed using media disposal processes contained in this document.
When maintenance or repair actions are completed, on-site or off-site, the Contractor must check all potentially impacted security controls to verify the controls are still functioning properly.
95
24.3 MA-3 Maintenance Tools¶
Contractors, including those using CSPs, must establish, maintain, and review at least annually an inventory of approved hardware, software, firmware, and remote maintenance tools authorized for use on information systems supporting the IRS contract.
At a minimum, the Contractor or CSP must:
Maintain an inventory of authorized maintenance tools and update the inventory whenever tools are added, modified, or removed.
Scan maintenance tools for malicious code and verify they have not been altered or otherwise compromised before installation or use.
Authorize and control the use of maintenance tools to prevent the introduction of malicious code or unauthorized modifications to information system.
Sanitize maintenance tools or equipment with data storage capabilities using IRSapproved media sanitization methods before removal from Contractor-controlled facilities or prior to reuse or disposal.
The inventory and use of maintenance tools must be managed through the Contractor's configuration management and maintenance processes to ensure only authorized and trusted tools are used to support IRS information systems.
24.4 MA-4 Non-Local Maintenance¶
Contractors, including those using Cloud Service Providers (CSPs), must authorize, document, monitor, and control non-local maintenance and diagnostic activities performed on information systems supporting the IRS contract. Non-local maintenance includes remote administration and diagnostic activities conducted through secure remote access technologies, such as Virtual Private Networks (VPNs) or Zero Trust Network Access (ZTNA).
At a minimum, the Contractor or CSP must:
Document authorized remote maintenance methods, tools, and personnel within the System Security Plan (SSP) or other approved system documentation.
Generate and retain audit logs for all non-local maintenance sessions, including user identity, date and time, systems accessed, and maintenance activities performed.
Require Multifactor Authentication (MFA) or Public Key Infrastructure (PKI) for all remote maintenance sessions.
Use only authorized and approved remote maintenance tools and protect all remote maintenance communications using encrypted network connections.
Terminate remote maintenance sessions immediately upon completion of the authorized activity.
Annually review non-local maintenance activities, access logs, and authorized maintenance tools to verify compliance with organizational security requirements.
Supplemental C-SCRM Guidance: Nonlocal MA may be provided by contractor personnel. Appropriate protection should be in place to manage associated risks. Controls applied to
96
internal MA personnel are applied to any suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers performing a similar MA role and enforced through contractual agreements with their external service providers. The Contractor must require its prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
24.5 MA-5 Maintenance Personnel¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and maintain procedures for authorizing maintenance personnel and maintain a current list of individuals authorized to perform maintenance on information systems supporting the IRS contract.
At a minimum, the Contractor must:
Maintain a current list of authorized maintenance personnel and review it annually for accuracy.
Ensure personnel performing maintenance without an escort have interim/final IRS staff-like access approved and on file with the Contracting Officer's Representative (COR).
Designate technically qualified personnel with an interim/final IRS staff-like access approval to supervise maintenance activities performed by personnel who do not possess interim/final IRS staff-like access approval.
Restrict maintenance activities performed by personnel without IRS staff-like access approval unless under the direct supervision of personnel with an interim/final IRS staff-like access approval
24.6 MA-6 Timely Maintenance¶
Contractors, including those using Cloud Service Providers (CSPs), must identify and maintain the maintenance support, replacement components, and other resources necessary to restore critical information system components within the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) established in the Contingency Plan and Disaster Recovery Plan. Maintenance support requirements must be annually reviewed and updated to ensure they remain sufficient to meet contractor recovery objectives.
25.0 Media Protection (MP)¶
The Media Protection (MP) control family establishes requirements for protecting digital and non-digital media containing IRS SBU data throughout its lifecycle. These controls help prevent unauthorized access, disclosure, alteration, loss, theft, destruction, or improper disposal of media through secure handling, storage, transport, sanitization, reuse, and disposal practices.
97
25.1 MP-1 Media Protection Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the MP policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update policies and procedures annually, or if there is a significant change. Events that require an update to MP policy and procedures include assessments, audit findings, and security or privacy incidents.
The MP policies and procedures must describe requirements to restrict access to information system media to authorized individuals when this media contains IRS SBU data. Information system digital media includes, but must not be limited to diskettes, magnetic tapes, external/removable hard drives, flash/thumb drives, CDs, and DVDs. An inventory must be maintained and provided to the IRS, upon request, that identifies all media used to store, maintain, or process IRS SBU data. Media that is used to store, maintain, or process IRS SBU must not be commingled with non-IRS data. IRS SBU being handled or processed by the contractor must be logically and/or physically segregated from other client’s data.
25.1.1 MP-1 Return or sanitization/destruction of hard and softcopy media at the End of Performance, under the Contract.
Within three months prior to the end of the base year of a contract, the Contractor must submit to the COR a plan for the return of all hard and softcopy media (identified below) or for the destruction and/or sanitization of all hard and softcopy media used, purchased specifically by the Contractor for performance under the contract, or provided by the IRS to the Contractor for use in the performance of this contract.
The plan must address the time by which the return of the property will be completed and/or how and when the destruction/sanitization will take place. The contractor may sanitize different components using different techniques. The COR, in consultation with the CSCA Team, will review the plan and inform the Contractor within 30 days of receipt of the plan which methods are approved by the IRS. The objective of this requirement is to ensure that all IRS SBU data is no longer available to the contractor, its employees, or anyone else not authorized access to the data. The IRS has the option to perform an onsite closeout assessment, remote closeout assessment, or utilize other methods to validate the sanitization and or destruction process. The contractor must send a certification of the
98
sanitization/destruction to the COR before the end of the contract as part of the contract closeout process.
Examples of media and information system components that must be returned, sanitized, or destroyed, as applicable, include:
Backup media and backup appliances.
Hard disk drives (HDDs), Solid-state Drives (SSDs), removable storage devices (e.g., USB flash drives and external drives), memory cards, and optical media.
Mobile devices, laptops, tablets, workstations, servers, and storage arrays.
Virtual storage, virtual machine disks, cloud storage volumes, object storage, snapshots, backups, and replicas.
Network and security devices, including routers, switches, firewalls, wireless access points, load balancers, and virtual network appliances.
Infrastructure, platform, and software service configurations, including cloud configurations, virtual machine images, infrastructure-as-code templates, container images, orchestration configurations, and application programming interface (API) configurations.
Voice over Internet Protocol (VoIP) systems, multifunction printers, copiers, scanners, fax devices, and other peripherals with internal storage.
Cryptographic keys, authentication credentials, certificates, logs, configuration files, and other system artifacts containing IRS Sensitive But Unclassified (SBU) data.
Prior to return, reuse, transfer, or disposal, media and system components containing IRS SBU data must be sanitized or destroyed using IRS-approved media sanitization methods appropriate to the technology and storage media.
25.2 MP-2 Media Access¶
Contractors, including those using CSPs, must restrict access to media containing IRS Sensitive But Unclassified (SBU) data to authorized personnel and implement safeguards to prevent the unauthorized access, disclosure, loss, theft, alteration, or destruction of digital and non-digital media.
At a minimum, the Contractor or CSP must:
Restrict access to paper records, removable media, backup media, portable storage devices, and other electronic media types containing IRS SBU data to authorized personnel with need-to-know.
Protect digital media, including removable storage devices, external drives, Solidstate Drives (SSDs), optical media, mobile devices, backup media, virtual storage, and cloud-based storage, from unauthorized access or disclosure.
Ensure IRS SBU data is not left unattended or exposed in work areas where it could be accessed by unauthorized individuals, including visitors, vendors, maintenance personnel, or other non-authorized personnel.
Conduct and document after-hours inspections of work areas at least quarterly to verify that IRS SBU data and media are properly secured.
99
25.3 MP-3 Media Marking¶
Contractors, including those using Cloud Service Providers (CSPs), must label digital and nondigital media containing IRS Sensitive But Unclassified (SBU) data to clearly identify the media as "IRS Data – Sensitive But Unclassified" in accordance with IRS marking requirements.
Media that remains within Contractor-controlled areas and is protected by approved physical or logical access controls is not required to bear external media markings, provided the media remains readily identifiable as containing IRS SBU data and is protected from unauthorized access or disclosure.
25.4 MP-4 Media Storage¶
For contractors who store IRS SBU, the Contractor physically controls and securely electronic media within controlled areas. When this media contains IRS SBU data, the contractor must maintain information in a lockable, metal filing cabinet. When larger volumes of information are being maintained at a contractor site, the Contractor must use automated mechanisms (key card access, biometric access, cipher locks, etc.) to restrict access to media storage areas, and to audit access attempts and access granted.
The Contractor or CSP must employ FIPS 140-3 or later validated cryptographic modules to protect information at rest. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. Minimum physical security requirements must be met, such as keeping SBU data secured when not in use. Removable media also must be encrypted and labeled SBU data when it contains IRS SBU. For more information see Section Physical and Environmental Protections (PE).
Information system media must be protected until the media is destroyed or sanitized using IRS approved methods.
Records must be established and maintained to track all deposits and withdrawals from media storage facilities and libraries.
Business and functional units must establish management controls that ensure all electronic media is inventoried, administered, and turned in during employee separations or reassignments.
This control applies to media storage areas within organizations, where significant volumes of media are stored, and does not apply to every location where media are stored (e.g., in individual offices).
Supplemental C-SCRM Guidance: Media storage controls should include C-SCRM activities. Contractors must specify and include in agreements (e.g., contracting language) media storage requirements (e.g., encryption) for their suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers.
100
The Contractor must require its prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
25.5 MP-5 Media Transport¶
Contractors, including those using CSP’s, must document all activities associated with the transport of digital media. The contractor must protect and control digital media during transport outside of contractor-controlled areas.
Information systems must implement cryptographic mechanisms to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas. The cryptographic modules in use must be FIPS 140-3 or later validated. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules. This applies to both portable storage devices (e.g., USB memory sticks, CDs, DVDs, external/removable hard disk drives, SSDs) and mobile devices with storage capability (e.g., smartphones, tablets, E-readers).
Chain of Custody records for digital media must be secured, to prevent unauthorized access and manipulation of log information.
Vehicles used to transport media, and paper must be secured to ensure contents cannot be inadvertently removed or lost from the vehicle, (e.g., secured cabs on the back of a truck).
SBU data in hotels must be stored in a locked room safe, or secured in a safe, in the hotel management office.
25.6 MP-6 Media Sanitization¶
Contractors, including those using Cloud Service Providers (CSPs), must sanitize or destroy all digital, magnetic, optical, solid-state, removable, virtual, cloud-hosted, and paper media containing IRS Sensitive But Unclassified (SBU), Federal Tax Information (FTI), Personally Identifiable Information (PII), prior to disposal, transfer, release, return, or reuse in accordance with NIST SP 800-88 Revision 2, Guidelines for Media Sanitization .
101
| NVMe Storage Devices | Purge, Destroy | Use manufacturer-supported Secure Erase, Sanitize, or Cryptographic Erase. Physically destroy if sanitization cannot be validated. |
|---|---|---|
| USB Flash Drives / Flash Memory |
Purge, Destroy |
Use Cryptographic Erase, Secure Erase, or physical destruction. Degaussing is not permitted. |
Memory Cards (SD, microSD, CompactFlash, etc.) |
Purge, Destroy |
Use Cryptographic Erase where supported or physically destroy the media. |
Optical Media (CD, DVD, Blu-ray) |
Destroy |
Pulverize, cross-cut shred, or incinerate in accordance with NIST SP 800-88 Rev. 2. |
Magnetic Tape |
Purge, Destroy |
Degauss using approved equipment or physically destroy the media. |
| Backup Media and Backup Appliances |
Purge, Destroy |
Sanitize all stored data and cryptographic material prior to disposal, reuse, or return. |
Mobile Devices (Smartphones, Tablets) |
Purge, Destroy |
Perform cryptographic erase or approved sanitization methods. Remove organizational accounts, encryption keys, and management profiles before disposal or reassignment. |
| Laptops, Workstations, and Servers |
Clear, Purge, Destroy |
Sanitize all internal storage devices, firmware-resident information, TPM data, cryptographic keys, BIOS/ settings, and persistent security configurations prior to disposal or transfer. |
| Virtual Machines (VMs) |
Purge |
Securely delete virtual disks, snapshots, templates, and associated storage using approved virtualization platform sanitization methods. |
| Cloud Storage (Object, Block, File, Database Storage) |
Purge |
Use cryptographic erase through destruction of encryption keys and ensure the CSP sanitization process complies with NIST SP 800-88 Rev. 2 and applicable FedRAMP requirements. |
| Containers and Container Images |
Purge |
Remove container images, persistent volumes, secrets, orchestration artifacts, and associated storage containing IRS SBU data. |
| Source Code Repositories and Build Artifacts |
Purge |
Securely remove source code repositories, build artifacts, software packages, Infrastructure-as-Code templates, and associated credentials developed for the IRS contract. |
| Configuration Files and Security Artifacts |
Purge |
Remove system configurations, API keys, certificates, cryptographic keys, security logs, infrastructure templates, and authentication credentials before disposal or contract closeout. |
| Paper Records |
Destroy |
Cross-cut shred to a particle size no greater than 1 mm × 5 mm (0.04 in. × 0.2 in.), or use another IRS-approved destruction method providing equivalent protection. |
appropriate sanitization method (Clear, Purge, or Destroy) based on the media type, storage technology, sensitivity of the information, and whether the media will remain under the Contractor's control or be released outside the Contractor's control.
Contractors must apply the appropriate sanitization method (Clear, Purge, or Destroy) based on the media type, the intended disposition of the media, and whether the media will remain under the contractor's organizational control.
102
Contractors must:
- Perform Clear, Purge, and Destroy sanitization operations using tools, equipment,
and procedures appropriate for the media type and consistent with NIST SP 800-88 Rev. 2.
- Select sanitization methods appropriate for the storage technology being sanitized.
Manufacturer-supported Secure Erase, Sanitize, cryptographic erase, block erase, or equivalent media-specific sanitization commands should be used where supported and validated.
- Use degaussing only for magnetic media for which it is an approved sanitization
method. Degaussing must not be used for solid-state drives (SSDs), flash memory devices, NVMe devices, USB storage, optical media, or other non-magnetic storage technologies.
- Physically destroy media that cannot be reliably sanitized, is damaged or inoperable,
will not be reused, or contains information requiring destruction.
- Sanitize firmware-resident information and security-sensitive configuration data,
including cryptographic keys, Trusted Platform Module (TPM) data, UEFI/BIOS settings, Secure Boot keys, Baseboard Management Controller (BMC) configurations, and other persistent security information, before disposal or transfer of information systems when applicable.
- Sanitize cloud-hosted information and storage resources prior to deprovisioning,
reassignment, or release. Sanitization activities must include the secure deletion of data from virtual machine images, storage volumes, object storage, file shares, snapshots, backups, databases, containers, serverless storage, log repositories, and other cloud-hosted resources containing IRS information. Contractors must employ cryptographic erase through the secure destruction of encryption keys. Contractors must ensure that CSP media sanitization processes are consistent with NIST SP 80088 Rev. 2 and FedRAMP requirements and must obtain evidence of sanitization or destruction upon request.
- Secure media awaiting sanitization or destruction to prevent unauthorized access,
disclosure, loss, theft, or accidental release.
- Document and verify all sanitization and destruction activities. Documentation must
include, at a minimum, the date performed, media type, media identifier or serial number (when applicable), sanitization or destruction method, personnel performing the activity, and any applicable Certificate of Destruction.
- Maintain chain of custody for media throughout transportation, storage, sanitization,
and destruction. Contractors using third-party destruction services must ensure the service provider employs approved destruction methods, maintains NAID certification), and provides a Certificate of Destruction for destroyed media.
- Destroy optical media, including CDs, DVDs, Blu-ray Discs, and similar media,
using pulverization, or cross-cut shredding.
- Destroy hard copy materials and flexible media containing IRS SBU using cross-cut shredders that produce particles no larger than 1 mm × 5 mm (0.04 in. × 0.2 in.), or by another destruction method that provides an equivalent or greater level of protection.
103
Maintain a media destruction log documenting all destroyed media, including the date of destruction, media type, media identifier (if applicable), description of contents, destruction method, personnel performing the destruction, witnesses (IRScleared), and Certificate of Destruction when applicable.
Ensure personnel performing sanitization or destruction of IRS SBU have interim/final staff-like access or be under escort of an employee who has approved interim/final staff-like access.
Additional Guidance
The following guidance applies when selecting sanitization methods:
Clear applies logical techniques that sanitize user-addressable storage locations to protect against simple, non-invasive data recovery techniques.
Purge applies physical or logical techniques that render data recovery infeasible using state-of-the-art laboratory techniques.
Destroy physically renders media unusable and data recovery infeasible.
Media that remains under the contractor's control may be cleared when appropriate and consistent with NIST SP 800-88 Rev. 2. Media released outside the contractor's control should be purged or destroyed, as appropriate.
Media that cannot be reliably sanitized, including damaged or inoperable devices, must be physically destroyed.
For flash-based storage technologies, including SSDs, NVMe devices, USB flash drives, memory cards, and embedded flash storage, contractors must use manufacturer-supported Secure Erase, Sanitize, or cryptographic erase. Physical destruction must be used when these methods cannot be verified or are not supported.
Sanitization of Software Artifacts
Before disposal, transfer, or contract closeout, contractors must sanitize or securely remove software repositories, build artifacts, Software Bills of Materials (SBOMs), container images, infrastructure-as-code templates, source code repositories, CI/CD pipeline artifacts, and associated credentials containing IRS SBU or developed in support of the IRS contract.
On-Site Shredding Services
Contractors may use an on-site document destruction service in lieu of in-house shredding equipment, provided the following requirements are met:
Media and paper records awaiting destruction must be placed in locked collection containers that remain under contractor management control until destruction.
Destruction must be performed on-site under the direct observation of IRS cleared contractor personnel.
104
The destruction service provider must maintain a current National Association for Information Destruction (NAID) AAA Certification, or an equivalent industryrecognized certification approved by the IRS.
The destruction service provider must maintain chain of custody throughout the collection, handling, and destruction process.
Upon completion of the destruction activity, the service provider must provide a Certificate of Destruction documenting the date of destruction, the media or materials destroyed, and the destruction method used. The contractor must retain the certificate as evidence of media sanitization and destruction.
Supplemental C-SCRM Guidance: Contractors must specify and include in agreements (e.g., contracting language) media sanitization policies for their suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Media is used throughout the SDLC. Media traversing or residing in the supply chain may originate anywhere, including suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. It can be new, refurbished, or reused. Media sanitization is critical to ensuring that information is removed before the media is used, reused, or discarded. For media that contains privacy or IRS SBU, the Contractor must require its prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
25.7 MP-7 Media Use¶
Contractors, including those using Cloud Service Providers (CSPs), must restrict the use of removable media and portable electronic devices to prevent the unauthorized processing, storage, transmission, or disclosure of IRS Sensitive But Unclassified (SBU) data.
At a minimum, the Contractor or CSP must:
Permit the use of removable media only when authorized for official business purposes and prohibit the use of writable removable media or portable storage devices that are not owned, managed, or assigned to an authorized individual.
Prohibit the use of personally owned equipment, software, removable media, or Portable Electronic Devices (PEDs) to access, process, store, or transmit IRS SBU data or to connect to information systems supporting the IRS contract, unless specifically authorized by the IRS.
Disable or otherwise restrict recording, imaging, audio, wireless, Radio Frequency (RF), infrared (IR), Bluetooth®, Near Field Communication (NFC), and other data capture or transmission capabilities in areas where IRS SBU data is processed, discussed, or displayed, unless required for authorized business purposes.
Implement technical and administrative controls to enforce removable media restrictions and monitor compliance with organizational media protection requirements.
26.0 Physical and Environmental Protection (PE)¶
The Physical and Environmental Protection (PE) control family establishes requirements for protecting facilities, information systems, and IRS Sensitive But Unclassified (SBU) data
105
from unauthorized physical access, damage, theft, environmental hazards, and other physical threats. These controls help ensure that physical access to areas where IRS SBU data is processed, stored, or transmitted is limited to authorized personnel and that appropriate safeguards are implemented to protect information systems, media, and supporting infrastructure throughout their lifecycle. Physical and environmental protection requirements apply only to facilities, systems, and areas used to process, store, transmit, or otherwise handle IRS SBU
26.1 PE-1 Physical and Environmental Protection¶
The Contractor must designate an official to manage the development, documentation, and dissemination of the physical, environmental, and privacy protection policy and procedures.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update policies and procedures annually, or if there is a significant change to PE procedures to be used for that contractor site. Events that require an update to PE policy and procedures include assessment or audit findings, security and privacy incidents or breaches, or changes in applicable laws.
26.1.1 Physical Security Program Principles
The Contractor must establish and maintain a comprehensive physical security program to protect IRS Sensitive But Unclassified (SBU) information, information systems, personnel, and supporting infrastructure from unauthorized access, disclosure, theft, damage, destruction, or compromise.
Physical security must employ a layered, risk-based approach that integrates management, operational, technical, and physical safeguards. The Contractor must implement physical protection measures that deter, delay, detect, assess, respond to, and recover from physical security incidents.
Physical protection measures may include, as appropriate:
controlled facility access;
secured perimeters;
fences and gates;
guards;
visitor controls;
106
electronic access control systems;
intrusion detection systems;
video surveillance systems;
locked rooms;
security containers;
vaults;
environmental monitoring;
fire protection systems;
utility protection; and
other compensating physical safeguards.
Physical protection measures must be commensurate with the operational environment, facility design, sensitivity of IRS information, and assessed risk.
26.3 PE-3 Physical Access Control¶
When designating an area as limited access, it is important to ensure that management controls of the area are in place. This must apply to all areas where access may be made into a secure perimeter. Examples of areas that may require additional protection include stairwell doors and loading dock areas.
26.3.1 Two-Barrier Physical Protection Principle
IRS Sensitive But Unclassified information must be protected by a minimum of two independent physical barriers separating protected information from personnel not authorized access.
Acceptable barrier combinations include:
building perimeter;
locked exterior entrances;
limited-access corridors;
secured rooms;
locked offices;
security containers;
GSA-approved safes;
electronic access control systems;
intrusion detection systems;
guard services
26.3.2 Physical Security of Information Systems and Media
Because of the vast amount of information systems, electronic, optical, and other removable media (including paper), store, handle, and process, the physical security and control of information systems and electronic, optical, or other removable media (including paper) also must be addressed.
109
In instances where encryption is not used, the contractor must ensure that all wiring, conduits, and cabling are within the control of contractor personnel and that access to routers and network monitors are strictly controlled.
Electronic, optical, and other removable media (including paper) must be kept in a secure area under the immediate protection and control of an authorized employee or locked up. When not in use, the media must be promptly returned to a proper storage area/container. Good security practice requires that inventory records of electronic, optical, and other removable media be maintained for control and accountability.
Information systems must operate within secured areas. Electronic media, removable media, paper records, telecommunications infrastructure, and supporting equipment must remain protected from unauthorized access.
The Contractor must ensure:
removable media remain under contractor control;
media inventories are maintained;
removable media are encrypted;
conduit and cabling remain protected;
telecommunications pathways remain under contractor control.
26.3.3 Restricting Access
IRS Sensitive But Unclassified information must be clearly identified and protected from unauthorized viewing.
Warning signs, identification labels, access restrictions, and physical safeguards must prevent inadvertent disclosure.
To assist with this requirement, SBU data must be clearly labeled as SBU data and handled in such a manner that it does not become misplaced or available to unauthorized personnel.
Additionally, warning banners advising protecting requirements must be used for information system screens.
The physical security controls, implementation guidance, engineering specifications, and inspection criteria applicable to physical access control have been incorporated into the applicable Physical and Environmental Protection (PE) controls throughout Section 26.
26.3.4 Locked Containers
A lockable container is a commercially available or prefabricated metal cabinet or box with riveted or welded seams or metal desks with lockable drawers. The lock mechanism must be either a built-in key or a hasp and lock. A hasp is a hinged metal fastening attached to the cabinet, drawer, etc. that is held in place by a pin or padlock.
110
The term container includes all file cabinets (both vertical and lateral), safes, supply cabinets, open and closed shelving or desk and credenza drawers, carts, or any other piece of office equipment designed for storing files, documents, papers, or equipment. Some of these containers are designed for storage only and do not provide protection (e.g., open shelving). For purposes of providing protection, containers can be grouped into three general categories: locked containers, security containers, and safes or vaults.
26.3.5 Security Containers
Security containers are metal containers that are lockable and have a tested resistance to penetration. To maintain the integrity of the security container, key locks must have only two keys and strict control of the keys is mandatory; combinations must be given only to those individuals who have a need to access the container.
Security containers include the following:
Metal lateral key lock files.
Metal lateral files equipped with lock bars on both sides and secured with security padlocks.
Metal pull drawer cabinets with center or off-center lock bars secured by security padlocks, and
Key lock “Mini Safes” properly mounted with appropriate key control.
If the central core of a security container lock is replaced with a non-security lock core, then the container no longer qualifies as a security container.
26.3.6 Locks and Key Management
The lock is the most accepted and widely used security device for protecting installations and activities, personnel information, tax information, classified material, government and personal property. All containers, rooms, buildings, and facilities containing vulnerable or sensitive items must be locked when not in actual use.
However, regardless of their quality or cost, locks must be considered as delay devices only and not complete deterrents. Therefore, the locking information system must be planned and used in conjunction with other security measures. A quarterly inspection must be made on all locks to determine each locking mechanism’s effectiveness, to detect tampering and to make replacement when necessary.
Access to a locked area, room, or container can be controlled only if the key or combination is controlled. Compromising a combination or losing a key negates the security provided by that lock. Combinations to locks must have at least four digits and be changed when an employee who knows the combination retires, terminates employment, transfers to another position, or at least once a year.
Combinations must be given only to those who have been granted interim or final staff-like access by Personnel Security and a need to have access to the area, room, or container and
111
must never be written on a calendar pad, desk blotters, or any other item (even though it is carried on one's person or hidden from view).
Contractor management or designated employee must maintain combinations for door locks, safes, vaults, or other storage devices. An envelope containing the combination must be secured in a container with the same or a higher security classification as the highest classification of the material authorized for storage in the container or area the lock secures.
Keys must be issued only to individuals who have been granted interim or final staff-like access by Personnel Security and a need to access an area, room, or container. An inventory must be made of all keys made and keys issued. An annual reconciliation must be done on all key records.
26.3.7 Safes and Vaults
A safe is a General Services Administration (GSA) approved container of Class 5 or 6, or Underwriters Laboratories (UL) Listing of TRTL-30, TRTL-60. A vault is a hardened room with typical construction of reinforced concrete floors, walls, and ceilings, uses UL-approved vault doors, and meets GSA specifications.
26.3.8 Secured Perimeters and Secured Rooms
Secured areas are internal areas that have been designed to prevent undetected entry by unauthorized contractor personnel/persons without an IRS approved interim or final staff-like access during duty and non-duty hours.
Access to rooms or containers containing SBU information must be restricted to personnel who have an IRS approved staff-like access. Secured perimeter/secured area must meet the following minimum standards:
The area must have physical construction to enable a secure and/or limited access area, e.g., doors to prohibit unrestricted entry, construction to prevent personnel from being able to access room through windows, partitioned walls, etc. Doors that provide access to secure or protected areas must have either internal door hinges or hinges that are tamper resistant.
This area must be enclosed by slab-to-slab walls constructed of approved materials and supplemented by periodic inspection or other approved protection methods, or any lesser type of partition supplemented by UL-approved electronic intrusion detection and fire detection information systems.
Space must be enclosed by slab-to-slab walls, which reach structural floor to structural ceiling, constructed of approved materials (normal construction material, permanent in nature such as masonry brick or drywall), that would prevent easy penetration/compromise.
If walls are not structural floor to structural ceiling, the use of wire mesh or woven wire fabric at least 10-gauge chain link fence installed above ceiling and/or under the floor to prevent
112
unauthorized entry; or use of IDS (motion sensors) above ceiling or beneath floor to prevent unauthorized entry, is acceptable.
When IDS are used, procedures must be in place requiring that response time to alarms be 15 minutes or less.
Equipment and utilities must be locked to prevent tampering by unauthorized personnel. These keys will be controlled and limited to authorized personnel. Non-IRS controls and activities must not be collocated in these rooms.
Placement of cameras is largely driven by risk or potential risk. High risk areas must be effectively covered and include the following areas:
Access to data centers must be controlled using biometric devices, or other forms using two-factor authentication.
There must be a manual fire alarm and evacuation system with pull boxes at each door leading out of any encapsulated areas used within the facilities.
Unless electronic intrusion detection devices are used, all doors entering the space must be locked, and strict key or combination control must be exercised.
In the case of a fence and gate, the fence must have intrusion detection devices or be continually guarded, and the gate must be either guarded or locked and have intrusion alarms.
The space must be cleaned during duty hours in the presence of a regularly assigned employee.
If there are louvers or vents within the secured area, such as near the door; ceiling, etc. these must be protected to detect and deter unauthorized access to the room/area, using Intrusion Detection System (IDS) methods, and
The contractor must develop a clean desk policy that requires all personnel to secure SBU data after work hours, during extended absences such as lunch, or when employee is not immediately working with the SBU data. The clean desk policy must be communicated to all personnel.
26.3.9 Limited Access Areas
When designating an area as limited access, it is important to ensure that management controls of the area are in place. Examples of a limited access area include but are not limited to computer/severs rooms, telecommunication closets, processing work areas, or other areas where IRS information is readily available to any employee working within that area.
Using restricted/limited access areas is an effective method for eliminating unnecessary traffic through critical areas, thereby reducing the opportunity for unauthorized access and/or disclosure of SBU data.
The Contractor must control all access points to the limited area. The entry control monitor or escort must verify the identity of visitors by comparing the name and signature entered in the access log with the name and signature of some type of photo identification card, such as a driver’s license. When leaving the area, the entry control monitor or escort must enter the
113
visitor's time of departure. Each limited area access log must be closed at the end of each month and reviewed by the area supervisor/manager.
Whenever visitors enter the area, the contractor must capture the following information: their name, signature, assigned work area, escort, purpose of entry, and time and date of entry.
The contractor must escort visitors, including contractor personnel who do not have IRS approved interim or final staff like access, and monitor visitor activity within limited processing areas.
Entry must be approved by the supervisor responsible for the area. The monitor or escort will enter the departure time in the access log.
Management or the designee must maintain an authorized list of all contractor personnel with an IRS approved interim or final staff-like access that have access to information systems or areas where SBU data is stored or processed. In addition, the site must issue appropriate authorization credentials. This must not apply to those areas within the facility officially designated as publicly accessible.
It is recommended that a second level of management review the access log. Each access log review must include a review of the need for continued access for the employee.
26.3.10 Locking Systems for Secure and Limited Areas
Minimum requirements for locking information systems for secured areas and security rooms are high security pin-tumbler cylinder locks that meet the following requirements:
Key-operated mortised or rim-mounted high security dead bolt lock. A dead bolt-throw of one inch or longer. Double cylinder design. Cylinders are to have five or more pin tumblers, and Hardened inserts or be made of steel if bolt is visible when locked.
Both the key and the lock must be adequately controlled. Convenience type locking devices such as card keys, sequenced button activated locks used in conjunction with electric strikes, etc., are authorized for use only during duty hours. Keys to secure areas are not in the personal custody of an authorized employee and any combinations must be stored in a security container. The number of keys or people with knowledge of the combination of a secure area must be kept to a minimum. Keys and combinations must be given only to those individuals, preferably supervisors, who have a frequent need to access the area after duty hours. Electronic access control systems with after-hour alarming capability can be used to secure doors to secure areas after duty hours.
26.3.11 Exterior Physical Barriers
Facilities must establish exterior physical protection based upon operational risk.
Protective measures may include:
114
fencing;
gates;
crash-rated barriers;
bollards;
vehicle barriers;
stand-off distance;
hardened landscaping;
reinforced planters;
retaining walls.
Barrier systems must protect:
occupied facilities;
entrances;
loading docks;
pedestrian areas;
utility infrastructure.
26.3.12 Inspection Criteria
The Contractor must control all access points to the facility. This does not apply to areas officially designated as publicly accessible. The contractor must ensure that access is authorized and verified before granting access to areas where IRS SBU is processed or stored.
Prior to authorizing access to facilities and/or areas where IRS SBU is processed, visitors must be authenticated. This does not apply to areas designated as publicly accessible.
The entry control monitor must verify the identity of visitors by comparing the name and signature entered in the access log with the name and signature on types of identification such as state issued driver’s license, PIV Card, or US Passport. When leaving the area, the entry control monitor or escort must enter the visitor's time of departure. Each access log must be closed out at the end of each month and reviewed by the area supervisor/manager.
Whenever visitors enter the area, the contractor must capture the following information: their name, signature, assigned work area, escort, purpose of entry, and time and date of entry.
Contractors using a CSP must ensure that the CSP enforces physical access authorizations at entry/exit points to the facility where the information system resides by verifying individual access authorizations before granting access to the facility; and controlling ingress/egress to the facility using CSP defined physical access control systems/devices and guards.
Assessors must verify:
Two-barrier protection exists.
Slab-to-slab construction is maintained.
IDS operates properly.
115
Lock inspections are documented.
Key inventories are current.
Badge inventories are reconciled.
Visitor access logs are reviewed.
Escort procedures are followed.
Clean desk inspections are performed.
Security containers remain compliant.
Exterior barriers remain intact.
Gates operate correctly.
Emergency egress remains unobstructed.
Stand-off protection has not been compromised.
26.4 PE-4 Access Control for Transmission Medium¶
The Contractor must physically control and monitor access to transmission lines and closets within the contractor facilities using physical safeguards. Security safeguards to control physical access to information system distribution and transmission lines include, for example:
Locked wiring closets,
Disconnected or locked spare jacks,
Protection of cabling by conduit or cable trays, and/or
Wiretapping sensors.
26.4.1 Telecommunications Infrastructure Protection
The Contractor must protect telecommunications infrastructure supporting IRS information systems from unauthorized access, interception, tampering, or physical damage.
Telecommunications infrastructure includes:
telecommunications closets;
network distribution rooms;
cable trays;
conduit systems;
patch panels;
routers;
switches;
network monitoring equipment.
Telecommunications rooms must:
remain locked when unattended;
be accessible only to authorized personnel;
maintain key or electronic access accountability;
be protected against unauthorized cable interception or modification.
116
Cable supporting IRS information systems must be installed within protected pathways whenever practical.
26.4.2 Transporting IRS Material
Any time SBU data is transported from one location to another, care must be taken to provide safeguards. In the event the material is hand-carried by an individual in connection with a trip or during daily activities, it must be kept with that individual and protected from unauthorized disclosures. For example, when not in use, and when the individual is out of their hotel room, the material is to be out of view, in a locked briefcase or suitcase.
All shipments of SBU data (including electronic, optical, or other removable media and microfilm) must be documented on a transmittal form and monitored to ensure that each shipment is properly and timely received and acknowledged. All SBU data transported through the mail or courier/messenger service must be double-sealed; that is one envelope within another envelope. In addition, the address must be contained on both the outer and inner envelope. The inner envelope must be marked SBU with some indication that only the designated official or delegate is authorized to open it.
Using sealed boxes serves the same purpose as double sealing and prevents anyone from viewing the contents. All removable media must be encrypted using FIPS 140-3, or later validated encryption modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program (CMVP), they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
Computers and IT media as well as sensitive information must be secured when in hotel rooms, when hotel room is unattended.
When transporting IRS SBU material, the contractor must ensure that material must always be safeguarded during transport.
Methods to secure material must include, but are not limited to; sealed envelopes, locked/electronically secured media transport containers, etc.
Any information stored in an automobile must be stored in the trunk. If impractical, the information should be covered from view.
Ensure the courier vehicle is locked and secured when in possession of IRS data and/or remittances.
Ensure the vehicles used by the couriers are:
Maintained in good condition, appearance, and working order.
Enclosed to ensure the packages and/or containers carried by the vehicle are secure.
117
- The vehicle must be secured. Vehicle doors must be secured (doors closed and
locked) during transportation of IRS packages or containers. All windows must be up in the vehicle during the transportation of data and remittances, and
- The areas of the vehicles in which the packages and/or containers are placed must be
clear and debris-free. Other items are not to be commingled with the packages and/or containers.
26.5 PE-5 Access Control for Output Devices¶
The Contractor must control physical access to the information system devices that display IRS SBU or where IRS SBU is handled or processed to prevent unauthorized individuals from observing the display output. Output devices include monitors, printers, scanners, audio devices, fax machines, projection devices, and copiers. Controlling physical access to output devices includes placing output devices in locked rooms or other secured areas with keypad or card reader access controls and allowing access to authorized individuals only, placing output devices in locations that can be monitored by personnel, installing monitor or screen filters, covering windows into secure work areas, facing output screens away from walkways, or some combination of the above.
26.5.1 Physical Protection of Output Devices
Output devices displaying, printing, copying, scanning, transmitting, or otherwise presenting IRS Sensitive But Unclassified (SBU) information must be physically positioned to prevent unauthorized observation.
Output devices include:
computer monitors;
printers;
multifunction devices;
copiers;
scanners;
facsimile equipment;
projection systems;
electronic displays.
Contractors must:
orient monitors away from public view;
locate printers within controlled areas;
protect printed output awaiting pickup;
prevent observation through windows and public corridors;
employ privacy filters where operationally appropriate.
26.6 PE-6 Monitoring Physical Access¶
118
The Contractor must monitor physical access to SBU data and the information systems where IRS SBU is stored, to detect and respond to physical security incidents. Physical access logs must be reviewed monthly, or more frequently at the discretion of the IRS. Incidents include security violations or suspicious physical access activities. Suspicious physical access activities include access outside of normal work hours, repeated access to areas not normally accessed, access for unusual lengths of time, and out-of-sequence access.
26.6.1 Physical Intrusion Detection Systems
Physical security Intrusion Detection Systems (IDS) are designed to detect attempted breaches of perimeter areas. IDS can be used in conjunction with other measures to provide forced entry protection for after-hours security. Additionally, alarms for individual and document safety (fire) and other physical hazards (water pipe breaks) are recommended. Alarms must be announced at an on-site protection console, a central station, or local police station. Physical security IDS include, but are not limited to door and window contacts, magnetic switches and motion sensors designed to set off an alarm at a given location when the sensor is disturbed.
Intrusion detection systems may include:
door contacts;
window contacts;
motion sensors;
glass-break sensors;
magnetic switches;
electronic alarm systems.
26.6.2 Video Surveillance Systems (VSS)
Purpose: The purpose of a VSS is to reduce risk and to assist with the deterrence, detection, surveillance, and investigation of incidents or potential incidents relevant to the protection of personnel information and facilities.
Guiding VSS Principles: In planning, implementing and/or revising of the VSS system, surveillance as it pertains to deterrence, investigation and detection must be based on the following guiding principles:
- Risk: Ensure that appropriate visual coverage exists throughout the facility and
carefully consider high risk areas. For PCA’s, the area where incoming mail potentially containing remittances is opened is considered critical. Any storage of unopened mail or remittances would also be considered critical. High risk areas would include data centers/server rooms and primary ingress/egress points. Other areas would qualify as low risk. For print vendors, high risk areas would include data centers/server rooms, printing and inserting areas, primary ingress/egress points, and dock areas where large volumes of letters are stored awaiting transport. Other areas would qualify as low risk.
- High vs. Low-Risk Areas: Avoid wide angle coverage of individual work areas
where an audit trail has yet to be established. Concentrate direct coverage on
119
individual workspace such as in extraction. Use more of a broader surveillance approach or less cameras in lower risk areas.
Recognition: Structure views to the extent that an individual may be personally recognized when entering/exiting interior mail processing areas even though it may be necessary to get a full shot of the doorway to guard against paper/information being passed under or somehow through the doorway.
Illumination: Lighting for VSS functionality must remain sufficient relative to a variety of situations such as loss of commercial power, loss of interior natural/artificial light, and nighttime surveillance. Artificial and emergency lighting must be sufficient to support surveillance and playback particularly of high-risk areas.
Maintenance: Optimal operations, including actual and recorded images, are achieved through regular testing and routine maintenance. Daily checks of camera views and weekly playback of recordings are required, and any identified deficiencies in the system must be addressed as soon as possible.
Housings: All cameras and associated cabling must be protected from tampering and vandalism. External cameras must be enclosed in tamper resistant housings.
° PTZ: In general, PTZ cameras should be used to augment fixed cameras, not replace them. Parking areas may be monitored by a combination of fixed and PTZ cameras. ° Identification: Combination intercom/camera devices must be used at entry points, particularly main entry and loading dock areas to aid in establishing identity prior to opening doors and permitting access. ° Camera Call-Up: Certain cameras such as PTZ cameras must be programmed and pre-positioned to support alarm call up in response to emergency exit doors and other critical entry/exit points such as those affiliated with the loading dock and to record such events. ° Continuous Recording: In general, these guidelines require continuous recording. However, configuration may include event recording features. Event recording is prompted by motion and/or IDS alarm activation particularly during times when the site is unattended or where surveillance involves spaces where little human activity takes place. Such a configuration may save space pertinent to recording video. Critical areas where incoming mail is opened must have continuous recording. Other high risk and low risk areas can have motion activated or event recording provided that daily camera checks and weekly playback reviews are being performed. ° Access Control: System configuration may include integration with access control. For example, while attempting to use an expired badge to gain access, a pre-programmed VSS camera will record the event (if not already in a continuous recording mode).and a guard will be alerted via monitor notification at the main guard station.
- Digital Recording: The contractor is required to provide and record surveillance of the mail processing area(s) using DVR/NVR systems, including the use of DVRs and if needed, appropriate video storage units. The DVR system must have duplex capabilities (the ability to play recorded video images while recording live images)
120
and be supported by the necessary peripheral security equipment to ensure effectiveness and compatibility.
Tampering: Recording and playback equipment must always be secured to prevent tampering and unauthorized use. Restricted access and usage must be managed by contractor’s officials fully vetted under the IRS contract.
Video Cassette Recording (VCR): VCR, technology and the use of VCR tapes are not acceptable due to disadvantages such as time-lapse recording.
Virtual Real Time Recording: Recording must be conducted at a speed which will eliminate unwanted excessive stop action, or time lapse, which distracts from its usefulness including forensic value. System configuration and other factors related to digital technology may impact how well images are recorded; however, TIGTA has specified a minimum rate recording speed of 3.5 frames per second.
Retention of Video Recordings: For PCA sites, video recordings of critical areas must be retained for one year. Other areas considered high risk must be retained for 6 months. Low risk areas must be retained for 30 days. For print vendors, high risk areas must be retained for 90 days, and low risk areas for 30 days. After the end of the retention period, image media may be destroyed or recorded over. If playback is stored on separate image media such as disks or supplemental hard drive, effective and appropriate safeguards must be in place to protect recorded images.
Quality of Video Playback: Playback, of recorded video and the effectiveness and clarity of recorded images is critical to the design aspect of the VSS system and is of paramount importance to the Government for reasons that support accountability, prudent practice, and forensic value. Consideration must be given to the overall VSS design and system used, so factors that can degrade resolution or image quality (e.g., video compression, time lapse, recorder speed) will be minimized. Video must be able to be played back at or above the minimum recording speed of 3.5 frames per second.
Internal or in-house playback reviews: On a weekly basis, the Contractor must ensure VSS playback is working as designed (functionality) by examining playback from at least 25% of the camera population and must be reviewed for at least one minute. Results from this review must be documented on a log.
Weekly Video Playback Review Log must contain the following information: refer to Exhibit 6, Weekly Video Playback Review Log, for sample of log:
o Review Date.
o Review Name.
o Recording Speed (if applicable).
o DVR/NVR (if applicable) & associated camera.
o Time/Date of video playback segment.
o Clear Picture.
o Imbedded date and time correct: y/n; and
o Any other problems or concerns.
- The new Network Video Recorders (NVR) utilize “cloud computing” where video is stored on several large computer hard drives and the recording speed cannot be determined and/or is not displayed. Also, because all the cameras are input into one centralized NVR and not a traditional 16 input DVR the specific NVR cannot be determined. Therefore, these 2 required items: recording speed & specific DVR should be removed from weekly video playback review log checklist.
121
- Documentation and Remediation: Acceptable measures must be put in place to channel and resolve problems related to playback. In addition, these measures must be documented as procedures in media such as post orders, standard operating procedures, and/or roles and responsibilities.
Manual Camera Review: Daily, the contractor must manually scan through all cameras to ensure connectivity, or a picture exists. This manual review is in addition to any automated or system capability designed to detect and report connectivity communication problems. Results from this daily scan, including any significant findings, must be documented on a log. In addition, reporting and remediation efforts to timely address problems associated with this daily scan must be in place and documented.
Matrix: A document listing cameras and related accessories must be developed.
VSS Specifications: Upon request, the contractor must provide access to VSS
manufacture specifications on all VSS-related equipment and peripherals. These and other specifications, including as-built plans, diagrams, and schematics provided by the VSS design specialist or contractor, must be maintained on-site and secured by an FA official.
- Doors: Doors that permit access (e.g., ingress/egress) to the exterior must be covered
by interior cameras. Interior doors that permit access to other interior controlled areas must capture the facial view of people as they enter and leave the space.
- Controlled Rooms: Fixed camera coverage of areas such as secured storage rooms,
computer rooms, security system control rooms, and main utility closets.
26.6.3 Mail Processing Surveillance
If IRS mail is received, the contractor must ensure that IRS incoming mail be stored in a secure area, i.e., in locked containers. All mail processing areas must have Video Surveillance Systems (VSS) coverage.
The Contractor must monitor physical intrusion alarms and surveillance equipment. VSS must have monitoring and recording capabilities but are not required to be monitored in real-time. Response actions can include notifying selected organizational personnel or law enforcement personnel. Automated mechanisms implemented to initiate response actions include system alert notifications, email, and text messages, and activating door locking mechanisms.
26.6.4 Monitoring Private Collection Agencies (PCA)
PCA’s must have VSS that record all sensitive areas where Taxpayer data is present, including but not limited to mail processing rooms. PCA’s must have a secure area for mail processing and securing payments, that is separate from the contractor’s other mail processing. Physical security assessments of the mailrooms and mail processing sites must be conducted annually for PCA’s.
122
26.7 PE-8 Visitor Access Records¶
The Contractor must maintain visitor access logs to the facility where the information system resides. Visitor access logs are not required for publicly accessible areas. The contractor must limit PII in visitor access logs.
A limited access area access log will be maintained at the main entrance of each limited area, and all visitors will be directed to the main entrance. Each person entering a limited area, who is not assigned to the area, will be required to sign the visitor access log.
The visitor access log must contain the following information:
Name and organization of the visitor,
Signature of the visitor,
Form of identification,
Date of access,
Time of entry and departure,
Purpose of visit, and
Name and organization of person visited.
The limited area monitor, or escort will complete the log by adding the individual's name, assigned work area, person to be contacted, purpose for entry, and time and date of entry.
Designated officials or designees within the contractor organization must review the visitor access logs, at least monthly or more frequently at the discretion of the IRS.
Each Limited Access Area Access log will be closed out at the end of each month, reviewed by the limited area first line supervisor, and forwarded to their manager. The manager will review the access log and retain it for at least two years. The managerial review is designed to ensure that only authorized individuals with an official need have access to the limited areas
26.7.1 Visitor Management Procedures
The Contractor must establish documented visitor management procedures for all facilities and limited-access areas where IRS SBU is processed or stored.
Visitors must:
present government-issued identification;
sign the visitor access log before entry;
wear a visitor credential while inside restricted areas;
remain under escort unless specifically authorized;
return visitor credentials before departure.
The monitor or escort will identify each visitor by comparing the name and signature entered in the access log with the name and signature on some type of photo identification card (i.e., government issued ID, driver's license). Upon verification of identity, the visitor will be escorted into the Limited Area
123
The limited area monitor, or escort will complete the access log by adding the individual's name, assigned work area, person to be contacted, purpose for entry, and time and date of entry.
Visitor access logs must be closed monthly and reviewed by supervisory personnel.
Contractors using a CSP must ensure that the CSP reviews visitor access logs, at least monthly or more frequently at the discretion of the IRS.
26.8 PE-9 Power Equipment and Cabling¶
The Contractor must protect power equipment and power cabling for the information system from damage and destruction. Power equipment and cabling include internal cabling, uninterrupted power sources in offices or data centers, generators, power sources for selfcontained components such as satellites, vehicles, or other deployable systems.
26.8.1 Utility Protection
Power distribution systems supporting IRS information systems must be protected from unauthorized access, tampering, and environmental hazards.
Utility rooms must:
remain locked;
be accessible only to authorized personnel;
contain protected electrical distribution equipment;
prevent storage of unrelated materials.
26.8.2 Data Center Utility Protection
Equipment and utility systems supporting IRS processing environments must be physically protected through controlled access and routine inspection.
Utility components include:
electrical panels;
UPS systems;
generators;
power distribution units;
telecommunications equipment;
network infrastructure.
26.9 PE-10 Emergency Shutoff¶
The capability to shut off power to the information system or individual system components in emergency situations must be provided. Access to the shutoff switches or devices must be unobstructed and located in such a manner so personnel have safe and easy access to them.
124
The shutoff switches or devices are to be protected from unauthorized or inadvertent activation.
26.9.1 Emergency Shutoff Engineering Requirements
Emergency power shutoff devices must:
remain readily accessible;
remain protected from accidental activation;
be clearly identified;
receive periodic functional testing.
26.10 PE-11 Emergency Power¶
The Contractor must provide a short-term uninterruptible power supply to facilitate an orderly shutdown of the information system in the event of a loss of primary power. Emergency power can be in the form of an internal Uninterruptible Power Supply (UPS) and/or a backup generator. UPS systems must be tested semiannually and documented by contractor personnel.
26.11 PE-12 Emergency Lighting¶
The Contractor must employ and maintain automatic emergency lighting for the information system that activates in the event of a power outage that covers emergency exits and evacuation routes within the facility.
26.11.1 Emergency Lighting Requirements
Emergency lighting must illuminate:
computer rooms;
telecommunications rooms;
exits;
evacuation routes;
electrical rooms.
Lighting must activate automatically following power loss.
26.12 PE-13 Fire Protection¶
The Contractor must maintain fire suppression, detection, and notification (alarms) devices for the information and/or information systems.
Class A and Class C fire extinguishers must be prominently located within any office complex containing IT assets so that an extinguisher is available within 50 feet of travel. Devices must be supported by an independent power source and appropriate for the size of the facility being protected/safeguarded.
125
Fire Extinguishers are required to be inspected/certified every 12 months.
The Contractor must employ an automatic fire suppression capability for the information system when the facility is not staffed on a continuous basis.
When the facility is used to store large volumes of SBU data in warehouses and/or storage facilities, the contractor must ensure that sprinkler systems and/or water suppression equipment must be in place to minimize damage to critical historical files.
26.12.1 Fire Detection and Suppression Engineering Fire detection systems must continuously monitor protected spaces. Fire protection systems must include:
automatic detection;
suppression;
notification;
independent power;
appropriate extinguisher types.
Computer rooms must receive enhanced protection.
26.12.2 Computer Room and Data Center Fire/Environmental Protections
The Contractor must install a firewall to separate the main doors to computer areas and adjacent tape or other storage libraries, as necessary to protect large volumes of media.
The Contractor must control physical access to information systems telecommunications service, distribution, and or network lines within the facility that would inhibit unauthorized access, interception, or damage (Reference PE-4).
There must be an audible sounding device (alarm) that reports to a central receiving point for action/response, for each room within the firewall encapsulated area of the computer complex that will alert the complex that unauthorized persons have entered the area.
Whenever multiple devices are being tracked for any activation and/or incidents, each device must announce separately to the on-site protection console.
There must be a one-hour fire resistive separation of the computer (electronic equipment) area perimeter from adjoining areas to protect the electronic equipment from the damaging effects of a fire which may occur outside the equipment area.
There must be an approved Ionization system in each computer room/tape library and ionization detector heads installed above suspended ceilings (unless ceiling is fire rated), on suspended ceilings and below elevated floors, scaled to the size of the facility being safeguarded.
The Contractor must protect power equipment and power cabling for the information system from damage and destruction (Reference PE-9).
126
As occupants of the Contractor, the contractor must comply with all federal, state, and local codes including but not limited to National Fire Protection Association (NFPA) and National Electrical Code (NEC) requirements. Upon request, the contractor must be able to present the certification of compliance for each site (Reference PE-10).
The Contractor must provide a short-term uninterruptible power supply to facilitate an orderly shutdown of the information system, in the event of a primary power source loss (Reference PE–11).
The Contractor must employ automatic emergency lighting of computer room facilities in the event of a power outage or disruption and that cover emergency exits and evacuation routes (Reference PE-12).
Contractors must employ and maintain fire suppression equipment and detection equipment that can be activated in the event of a fire (Reference PE-13).
In addition, contractors must ensure there are systems in place to continuously monitor all electronic detection, extinguishing, and environmental and utility support systems to detect abnormal conditions.
Contractors must install separately contained/valve wet pipe, water sprinkler system (pipe scheduled or hydraulically designed type) inside the entire firewall, encapsulated computer room and tape library areas with automatic power cut-off capability. (National Fire Protection Association (NFPA) Standard No. 13 provides details on installation of acceptable sprinkler systems).
Contractors must regularly maintain, within acceptable levels, and monitor, the temperature and humidity within computer room and telecommunication facilities containing information systems and assets (Reference PE-14).
All air conditioning and ventilating systems must follow Section 301 of RP-1 and NFPA Standard No. 90A to ensure that the systems are designed to prevent the spread of fire, smoke, and fumes from exposed areas into the computer room or tape library.
Sprinkler water flows must contain alarms and supply valve controls.
There are floor drains or sump pumps to provide water drainage in the event of sprinkler head activation or a plumbing leak above the ceiling or under the floor. There is a sprinkler shut-off valve (also called OS&Y) that controls the sprinkler system to the computer and/or library.
Contractors must protect the information systems from water damage resulting from broken plumbing lines or other sources of water by ensuring that master shutoff valves are accessible, working, and known to key personnel (Reference PE-15).
The information systems must be placed to minimize damage from physical and environmental hazards and to minimize the opportunity for unauthorized access.
127
26.13 PE-14 Environmental Controls¶
The Contractor must maintain and monitor temperature and humidity levels within the facility where the information system resides. The monitoring of the temperature levels must generate alerts or notifications when changes in temperature are potentially harmful to personnel or equipment. The alarm or notification may be an audible alarm, visual message, text, or email in real time to personnel or roles defined by the organization. Such alarms and notifications can help minimize harm to individuals and damage to organizational assets by facilitating a timely IR.
26.14 PE-15 Water Damage Protection¶
The Contractor must protect the information systems from damage resulting from water leakage by ensuring that master shutoff or isolation valves are accessible, working properly and known to key personnel.
26.15 PE-16 Delivery and Removal¶
For all IT information systems that house SBU data, the contractor must authorize and control information system-related items entering and exiting the facility and maintain appropriate records of those items.
The authorization process must define individuals who are authorized to remove IT related equipment and/or other records.
If mailrooms are used, controls must be put in place to ensure mail is also controlled, once received.
26.15.1 Mail Processing Security
Mail processing areas must:
remain secured;
maintain controlled access;
separate IRS mail from non-IRS mail;
protect remittance processing.
26.16 PE-17 Alternate Work Site¶
FTI cannot be processed or stored at employee’s home or elsewhere except as otherwise approved by the IRS.
Digital assistants (sometimes called smart devices) and other devices such as smart phones that can record or transmit sensitive audio or visual information must not be allowed to compromise privacy in the work or telework environment. These devices typically contain sensors, microphones, cameras, data storage components, speech recognition, GPS options, and other multimedia capabilities. These features could put the privacy of contractor’s
128
personnel and/or Taxpayers at risk due to personal information that might be unwittingly disclosed. When working on any form of SBU data, (including PII and tax information), these rules must be followed:
Treat the device as if it were another person in the room because many such devices and applications can record and/or transmit data when activated. To protect privacy, contractors must mute or disable the listening/detecting features of the device so that SBU data is not sent to the device or anything to which it is connected.
If the device or application can take photos or record video or sound, then the contractor must not do sensitive work within visual or audio range.
These devices/applications include (but are not limited to the examples provided):
Digital assistants (such as Dot or Echo hardware using Alexa software, HomePod using Siri, etc.),
Voice-activated devices and smartphone applications (such as Siri, Google Now (“Okay Google”), or Alexa on phones, tablets, etc.),
Internet-connected toys (Cloud Pet, Smart Toy, Hello Barbie, etc.) that might record and transmit,
Security systems and webcams in the telework environment,
Smart TVs or auxiliary equipment (if includes voice activation),
Operating systems/applications (such as Windows 11, Cortana, etc.) that allow voice commands,
Home surveillance, security, and video/audio: Webcams on personal devices in the home, security cameras/microphones, and/or
Smart phones with video/audio capabilities.
Contractor personnel approved telework location must have the following features/capabilities:
A telephone,
A workspace suitable to perform work,
All SBU data in the possession of the employee must be kept in a locking file
cabinet or drawer, laptops must be locked in place or in a locked room,
Secure remote network access via a VPN, and
A work environment that is free from interruptions and provides reasonable
security and protection.
- Information system operations must be in a secure area with restricted access. In situations such as approved telework locations, remote terminals, or office work sites where all the requirements of a secure area with restricted access cannot be maintained, the equipment must receive the highest level of protection that is practical. Minimum physical security requirements must be met, such as keeping SBU data locked up when not in use. Removable media also must be labeled SBU data when they contain such information. Removable media also must be encrypted and labeled SBU data when it contains such information.
129
26.17 PE-23 Facility Location (C-SCRM Control)¶
Contractors must consider the physical and environmental hazards associated with their current location in their organizational risk management strategy.
Contractors must incorporate the facility location (e.g., data centers) when assessing risks associated with suppliers. Factors may include geographic location (e.g., Continental United States [CONUS], Outside the Continental United States [OCONUS]), physical protections in place at one or more of the relevant facilities, local management and control of such facilities, environmental hazard potential (e.g., located in a high-risk seismic zone), and alternative facility locations.
Contractors must also assess whether the location of a manufacturing or distribution center could be influenced by geopolitical, economic, or other factors.
For critical vendors or products, contractors must specifically address any requirements or restrictions concerning the facility locations of the vendors (or their upstream supply chain providers) in contracts.
26.18 Data Center Controls¶
The primary room must be a secure room/space that meets the following security requirements:
Space must be enclosed by slab-to-slab walls, which reach structural floor to structural ceiling, constructed of approved materials (normal construction material, permanent in nature such as masonry brick or drywall), that would prevent easy penetration/compromise.
If walls are not structural floor to structural ceiling, the use of wire mesh or woven wire fabric at least 10-gauge chain link fence installed above ceiling and/or under the floor to prevent unauthorized entry; or use of IDS (motion sensors) above ceiling or beneath floor to prevent unauthorized entry, is acceptable. When IDS are used, procedures must be in place requiring that response time to alarms be 15 minutes or less.
Equipment and utilities must be locked to prevent tampering by unauthorized personnel. These keys will be controlled and limited to authorized personnel. Non-IRS controls and activities must not be collocated in these rooms.
Placement of cameras is largely driven by risk or potential risk. High risk areas must be effectively covered and include the following areas:
Access to data centers must be controlled using biometric devices, or other forms using twofactor authentication.
Doors: Doors that permit access (e.g., ingress/egress) to the exterior must be covered by interior cameras. Interior doors that permit access to other interior controlled areas must capture the facial view of people as they enter and leave the space.
130
Controlled Rooms: Fixed camera coverage of areas such as secured storage rooms, computer rooms, security system control rooms, and main utility closets. Camera placement and coverage must be designed and monitored so equipment, storage goods, and/or design does not interfere, diminish, or block surveillance.
The Contractor must control all physical access points (including designated entry/exit points) to the facility where the information system resides (except for those areas within the facility officially designated as publicly accessible) and verify individual access authorizations before granting access to the facility. This requirement applies to both contractor personnel and visitors.
The Contractor must meet and control physical access to information system devices that display information to prevent unauthorized individuals from observing the display output (Reference PE-5).
The Contractor must monitor physical access to the information system to detect and respond to physical security incidents (Reference PE-6).
Access logs must be maintained to identify visitors to the computer room facilities. The log must include name & organization of the person visiting; signature of the visitor; date of access; time of entry and departure, purpose of visit. Designated officials must review logs monthly, and more frequently at the discretion of the IRS. (Reference PE-8).
The Contractors must control information system-related items, including hardware, firmware, software, from entering and exiting the facility and maintaining appropriate records of these items (Reference PE-16).
Contractor personnel must not process and/or store FTI at any sites, other than IRS approved contractor sites. Information must not be processed and/or stored from any employee's temporary and/or permanent residence, e.g., via home office or telecommuting (Reference PE17).
Data Center Fire/Environmental Conditions
The Contractor must install a firewall to separate the main doors into computer areas and adjacent tape or other storage libraries, as necessary to protect large volumes of media.
The Contractor must control physical access to information systems telecommunications service, distribution, and or network lines within the facility that would inhibit unauthorized access, interception, or damage (Reference PE-4).
There must be an audible sounding device (alarm) that reports to a central receiving point for action/response, for each room within the firewall encapsulated area of the computer complex that will alert the complex that unauthorized persons have entered the area.
131
Whenever multiple devices are being tracked for any activation and/or incidents, each device must announce separately to the on-site protection console.
There must be a one-hour fire resistive separation of the computer (electronic equipment) area perimeter from adjoining areas to protect the electronic equipment from the damaging effects of a fire which may occur outside the equipment area.
There must be an approved Ionization system in each computer room/tape library and ionization detector heads installed above suspended ceilings (unless ceiling is fire rated), on suspended ceilings and below elevated floors, scaled to the size of the facility being safeguarded.
The Contractor must protect power equipment and power cabling for the information system from damage and destruction (Reference PE-9).
As occupants of the Contractor, the contractor must comply with all federal, state, and local codes including but not limited to National Fire Protection Association (NFPA) and National Electrical Code (NEC) requirements. Upon request, the contractor must be able to present the certification of compliance for each site (Reference PE-10).
The Contractor must provide a short-term uninterruptible power supply to facilitate an orderly shutdown of the information system, in the event of a primary power source loss (Reference PE–11).
The Contractor must employ automatic emergency lighting of computer room facilities in the event of a power outage or disruption and that cover emergency exits and evacuation routes (Reference PE-12).
The Contractors must employ and maintain fire suppression equipment and detection equipment that can be activated in the event of a fire (Reference PE-13).
In addition, contractors must ensure there are systems in place to continuously monitor all electronic detection, extinguishing, and environmental and utility support systems to detect abnormal conditions.
The Contractor must install separately contained/valve wet pipe, water sprinkler system (pipe scheduled or hydraulically designed type) inside the entire firewall, encapsulated computer room and tape library areas with automatic power cut-off capability. (National Fire Protection Association (NFPA) Standard No. 13 provides details on installation of acceptable sprinkler systems).
The Contractors must regularly maintain, within acceptable levels, and monitor, the temperature and humidity within computer room and telecommunication facilities containing information systems and assets (Reference PE-14).
All air conditioning and ventilating systems must follow Section 301 of RP-1 and NFPA Standard No. 90A to ensure that the systems are designed to prevent the spread of fire, smoke, and fumes from exposed areas into the computer room or tape library.
132
Sprinkler water flows must contain alarms and supply valve controls.
There are floor drains or sump pumps to provide water drainage in the event of sprinkler head activation or a plumbing leak above the ceiling or under the floor. There is a sprinkler shut-off valve (also called OS&Y) that controls the sprinkler system to the computer and/or library.
The Contractors must protect the information systems from water damage resulting from broken plumbing lines or other sources of water by ensuring that master shutoff valves are accessible, working, and known to key personnel (Reference PE-15).
The information systems must be placed to minimize damage from physical and environmental hazards and to minimize the opportunity for unauthorized access
27.0 Planning (PL)¶
The Planning (PL) control family establishes requirements for integrating security and privacy into the planning, development, implementation, operation, and maintenance of information systems supporting the IRS contract. These controls help ensure that security and privacy requirements are identified, documented, implemented, and maintained throughout the system lifecycle, providing assurance that IRS SBU data and information systems are protected.
27.1 PL-1 Planning Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of security and privacy PL policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update policies and procedures annually or if there is a significant change.
27.2 PL-2 System Security and Privacy Plans¶
133
Contractors, including those using CSP’s must develop and maintain a system security plan to identify key information about the information system and about security and privacy controls that are implemented to ensure that IRS SBU is protected.
The SSP must:
- Describe the operational context of the information system in terms of missions and
business processes.
Explicitly define the authorization boundary for the system.
Identify the information types processed, stored, and transmitted by the system.
Identify contractor personnel that fulfill system roles and responsibilities.
Describe the specific threats that could affect the contractor's operation and
protection of the information system and the data it processes, stores, or transmits.
Identify risk determinations for security and privacy architecture and decisions.
Provide the results of a privacy risk assessment for systems processing PII.
Describe the operational environment for the information system and relationships
with or connections to other information systems.
Provide an overview of the security and privacy requirements for the system.
Describe the security and privacy controls in place or planned for meeting those
requirements
Incorporate privacy into the system development lifecycle, and
Be reviewed and approved prior to plan implementation.
Where Artificial Intelligence (AI) capabilities are used in support of the IRS contract, the Security and Privacy Plan must document, as applicable:
AI systems, models, agents, and services within the authorization boundary.
The purpose and authorized use of each AI capability.
Data classifications processed, stored, transmitted, or accessible by the AI capability.
AI model providers and hosting environments.
Security and privacy controls are implemented to protect AI capabilities.
AI-related interfaces with IRS, contractor, subcontractor, and third-party systems.
Monitoring, logging, and incident response procedures applicable to AI capabilities.
The Contractor or CSP must:
- Distribute copies of the security plan and communicate subsequent changes to the
plan to authorized personnel.
Review the SSP at a minimum annually or if a significant change occurs.
Update the SSP to address changes to the information system/environment of
operation or problems identified during plan implementation or security control assessments, and
- Protect the SSP from unauthorized disclosure and modification.
The SSP must include or reference a plan for media sanitization and disposition that addresses all system media and backups.
134
Supplemental C-SCRM Guidance: The SSP must integrate C-SCRM. The Contractor may choose to develop a stand-alone C-SCRM plan for an individual system or integrate SCRM controls into their SSP. The SSP and/or system-level C-SCRM plan provide inputs into and take guidance from the C-SCRM Strategy and Implementation Plan at Level 1 and the CSCRM policy at Level 1 and Level 2.
The Contractor must coordinate with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers to develop and maintain their SSPs. For example, building and operating a system requires significant coordination and collaboration between the contractor and system integrator personnel. Such coordination and collaboration should be addressed in the SSP or stand-alone C-SCRM plan. These plans must also consider that suppliers or external service providers may not be able to meet the acquirer’s requirements.
It is recommended that suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers also develop C-SCRM plans for contractor systems that are processing IRS SBU and flow down this requirement to relevant sub-level contractors.
27.3 PL-4 Rules of Behavior¶
The contractor must develop a set of expected rules of behavior when processing or handling IRS SBU data. For all contractor personnel who have access to IRS SBU data, the contractor must provide an approved acknowledgement indicating their understanding and expected behavior for information and system usage, security, and privacy. User acknowledgement of the rules of behavior must be made annually by contractor personnel who have access to contractor managed IT assets.
The rules of behavior:
Need to be re-approved by the users if/when they are updated.
Reviewed annually and updated as necessary by the contractor.
The contractor must include in the rules of behavior:
Restrictions on the posting of IRS SBU data on public websites, as well as the use of IRS identifiers (e.g., email addresses) and IRS authenticators (e.g., passwords) on external sites/applications.
Usage restrictions and implementation guidance for using internet-supported technologies (e.g., websites, instant messaging, social media, social networking sites,) based on the potential for these technologies to cause damage, or disruption to the information system.
The acceptable use of Artificial Intelligence (AI) systems, including restrictions on entering IRS SBU, FTI, or PII into unauthorized AI services and the use of AIgenerated content in support of the IRS contract.
Any failure to comply with the rules of behavior must be considered a security and or privacy incident and reported to the IRS COR following IRS Incident reporting requirements. If the
135
incident is deemed willful, it must be escalated to a security and/or privacy violation and is subject to disciplinary action by the contractor and the IRS.
27.4 PL-8 Security and Privacy Architectures¶
Contractors, including those using a CSP, must develop and maintain an information security and privacy architecture document that describes:
The overall security and privacy architecture of the organization.
he overall security and privacy architecture supporting the IRS contract.
The IRS SBU data flow (data flow diagram).
The requirements and approach to be taken for processing PII, to minimize privacy risk to individuals.
The overall philosophy, requirements, and approach to be taken regarding protecting the confidentiality, integrity, and availability of contractor information.
How the information security architecture is integrated into and supports the enterprise architecture
How privacy is incorporated into the system development lifecycle, and
Information security assumptions about, and dependencies on, external services.
The security and privacy architecture document must be reviewed and updated annually to reflect updates in the enterprise architecture.
Planned information security architecture changes must be reflected in the security and privacy plans, the security Concept of Operations (CONOPS), criticality analysis, organizational procedures, and organizational requirements that result in procurements/acquisitions.
Contractors must create and maintain a documented Zero Trust transition strategy that identifies current capabilities, implementation priorities, projected milestones, and risk-based improvements. The strategy must be reviewed annually and updated whenever significant changes are made to the information system or security architecture.
28.0 Program Management (PM)¶
The Program Management (PM) control family establishes requirements for developing, implementing, and overseeing an organization-wide security and privacy program that protects IRS SBU data and information systems supporting the IRS contract. These controls provide governance, risk management, policies, oversight, and organizational processes necessary to ensure security and privacy requirements are consistently implemented, monitored, and maintained across the Contractor's environment.
28.1 PM-4 Plan of Action and Milestones (POA&M) Process¶
Contractors must establish and maintain a POA&M policy and procedure that defines how the contractor identifies, prioritizes, and remediates information security, privacy, and supply
136
chain risk management weaknesses affecting contractor information systems that support the IRS contract.
28.2 PM-5 Inventory of Personally Identifiable Information¶
Contractors must establish, maintain, and update at least annually, and whenever significant changes occur, an inventory of all systems, applications, and projects that process PII. The inventory must support the mapping of data actions, the provision of privacy notices to individuals, the maintenance of accurate PII, and the limitation of PII processing to authorized operational purposes. Contractors must use the inventory to verify that systems process PII only for authorized purposes and that such processing remains relevant, necessary, and consistent with the approved PCLIA.
Supplemental C-SCRM Guidance: Having a current system inventory is foundational for CSCRM. Not having a system inventory may lead to the Contractor’s inability to identify system and supplier criticality, which would result in an inability to conduct C-SCRM activities. To ensure that all applicable suppliers are identified and categorized for criticality, contractors must include relevant supplier information in the inventory system and maintain its currency and accuracy. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
28.3 PM-9 Risk Management Strategy¶
The contractor must have a documented process to identify, assess, and manage security and privacy risks to IRS information, which must be provided to the COR upon request. The contractor must implement appropriate administrative, technical, and physical safeguards to protect IRS SBU information, FTI, and PII throughout its lifecycle.
The contractor must regularly monitor risks, address identified security and privacy risks and review the risk management process at least annually or whenever significant changes occur that could affect the security or privacy of IRS information.
28.4 PM-18 Privacy Program Plan¶
Contractors must develop, maintain, and share an organization-wide Privacy Program Plan that:
Meets the privacy requirements in the IRS contract and IRS Publication 4812.
Provides an overview of the contractor's privacy program and its requirements.
Describes how the privacy program is organized, including the roles and responsibilities of the Contractor Privacy Official and other personnel with privacy responsibilities.
Identifies the people, resources, and processes used to support the privacy program.
Describes the privacy management controls and oversight processes used to meet privacy requirements and monitor the effectiveness of privacy controls.
137
Demonstrates management's commitment to protecting privacy and managing privacy risks.
Is reviewed and updated at least annually, or whenever significant changes occur, and is approved and signed by the Contractor Privacy Official.
Supplemental C-SCRM Guidance: The privacy program plan must include C-SCRM. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
28.5 PM-19 Privacy Program Leadership Role¶
The Contractor must appoint a Privacy Officer who has, at a minimum, an active interim/final IRS background investigation and is provided with the authority, mission, accountability, and resources necessary to coordinate, develop, implement, and oversee compliance with applicable privacy requirements. The Privacy Officer is responsible for managing privacy risks through the Contractor's privacy program for all activities performed in support of the IRS contract.
28.6 PM-20 Dissemination of Privacy Program Information¶
Contractors must post a link to the relevant privacy policy on any known major entry points to the website, application, or digital service. Contractors must provide a link to the privacy policy on any webpage, mobile application or digital service that collects personally identifiable information.
Contractors must develop and post privacy policies on all external-facing websites, mobile applications, and other digital services, that:
Are written in plain language and organized in a way that is easy to understand and navigate.
Provide information needed by the public to make an informed decision about whether and how to interact with the organization, and
Are updated whenever the organization makes a substantive change to the practices it describes and includes a time/date stamp to inform the public of the date of the most recent changes.
28.7 PM-21 Accounting of Disclosures¶
The contractor must keep records of disclosures of PII and FTI that are subject to accounting of disclosure requirements when required by the contract. The contractor must provide these records to the COR or other authorized IRS representatives upon request.
28.8 PM-22 Personally Identifiable Information Quality Management¶
If the contract requires the processing, storing or transmission of PII received from the IRS or other authorized sources, the contractor must adhere to the requirements for handling that PII including using only authorized PII, maintaining the integrity and quality of the PII while it is
138
under the contractor’s control, and following the contract requirements for reporting data issues, and providing information requested by the IRS through the COR.
28.9 PM-24 Program Management — Data Integrity Board¶
If the contractor performs computer matching processes under a Computer Matching Agreement (CMA) on behalf of the IRS, the contractor must follow the requirements in the applicable CMA. Contractors must support IRS oversight and ensure the accuracy and quality of the data used in the matching process when applicable to the contract.
28.10 PM-25 Minimization of PII Used in Testing, Training, and Research¶
The Contractor must develop and implement policies and procedures that forbid the use of IRS PII for internal testing, training, and research. When the use of IRS PII is necessary in testing, training, and research, explicit permission from the IRS is required. The Contractor must coordinate with the COR complete SBU Data Use Request Form 14665 before using the data for internal testing, training, or research.
The Contractor must fictionalize taxpayer names and addresses in training and testing materials to ensure that taxpayer information is not accidentally released, and disclosure laws are not violated.
Examples of acceptable PII fictionalization:
For names use categories of objects, such as animals or minerals: Mr. Bass, Ms. Silver, etc.
For Social Security Numbers, begin fictitious numbers with “0” or “X”: 000-1234567, etc.
28.11 PM-26 Complaint Management¶
The Contractor must notify the COR within 5 business days of any privacy-related complaints from the public and cooperate with any subsequent investigation.
Contractors must implement a process for receiving and responding to complaints, concerns, or questions from individuals about the organizational security and privacy practices that include:
Mechanisms that are easy to use and readily accessible by the public.
All information necessary for successfully filing complaints.
Tracking mechanisms to ensure all complaints received are reviewed and addressed within a contractor defined time-period.
Acknowledgement of receipt of complaints, concerns, or questions from individuals within contractor defined time-period, and
Response to complaints, concerns, or questions from individuals within a contractor defined time-period.
139
Complaints, concerns, and questions from individuals can serve as valuable sources of input to organizations and ultimately improve operational models, uses of technology, data collection practices, and controls. Mechanisms that can be used by the public include telephone hotline, email, or web-based forms.
The information necessary for successfully filing complaints includes:
Contact information for the senior agency official for privacy or other official designated to receive complaints.
Privacy complaints may also include PII which is handled in accordance with relevant policies and processes.
28.12 PM-27 Privacy Reporting¶
The contractor must maintain records of privacy activities and provide required privacy information and incident reports as specified in the contract. If the contractor operates its own authorized system, it must also maintain any required privacy reports for that system and provide these records to the IRS upon request.
28.13 PM-28 Risk Framing¶
The contractor must comply with all privacy requirements specified in the contract, including identifying and reporting privacy risks, supporting required security and privacy assessments, maintaining required documentation, and promptly notifying the COR of any new or increased privacy risks related to contract performance.
28.14 PM-31 Program Management — Continuous Monitoring Strategy¶
The contractor must monitor the privacy controls assigned under the contract to ensure they remain effective and comply with contract requirements. The contractor must report identified privacy control deficiencies and privacy incidents to the COR in accordance with contract requirements, support required security and privacy assessments and provide evidence of compliance upon request.
29.0 Personnel Security (PS)¶
The Personnel Security (PS) control family establishes requirements for ensuring that contractor personnel with access to IRS SBU data or information systems are appropriately screened, authorized, managed, and monitored throughout the period of contract performance. These controls help ensure that only personnel who have received the required IRS background investigation and favorable adjudication, and who have a valid need-to-know, are granted access to IRS information or information systems.
29.1 PS-1 Personnel Security Policy and Procedures¶
140
The Contractor must designate an official to manage the development, documentation, and dissemination of the PS policies and procedures and review/update them annually, or if there is a significant change.
The policy must define the need for all contractor personnel to obtain interim or final stafflike access before beginning work on the IRS contract.
Supplemental C-SCRM Guidance: At each level, the PS policy and procedures and the related C-SCRM Strategy/Implementation Plan, C-SCRM Policies, and C-SCRM Plan(s) need to define the roles for the personnel who are engaged in acquisition, management, and execution of supply chain security activities. These roles also need to state acquirer personnel responsibilities about relationships with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers.
Policies and procedures need to consider the full SDLC of systems and the roles and responsibilities needed to address the various supply chain infrastructure activities. The contractor must require its prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
29.2 PS-2 Position Risk Designation¶
At the start of any contract, the Vendor POC will assist the COR with identifying position duties, level of access required, and preliminary assessments of the position risk designation for each type of position performing work on the contract. The POC/COR will complete the Position Designation via OPM position designation tool and will update the information in HR Connect. The Associate Director of Personnel Security has the ultimate authority for position risk designation and may adjust the risk level, if deemed appropriate. The COR must coordinate within the IRS to ensure that all positions have been appropriately risk categorized, as required.
IRS contracts where contractors process, store, or manipulate IRS SBU data must be categorized as moderate risk or high if the IRS deems appropriate, and require that all contractors with access to IRS SBU data attain IRS approved staff-like access through PS. IRS approved staff-like access (interim or final) is also required for any personnel who configure computers, IT assets, or computer systems for the contractor, manage servers in an administrative capacity, have access to maintain and manage routers, or in any other way can access IRS SBU data and facilities housing IRS SBU data. This would include contractors who design, operate, repair, and/or maintain information systems, and/or require access to IRS SBU data.
Contractors using a CSP must assign a risk designation to all positions; establish screening criteria for individuals filling those positions and ensure that the CSP reviews and updates position risk designations at a minimum every three years.
29.3 PS-3 Personnel Screening¶
141
Personnel screening must take place for all contractor personnel who work on IRS contracts. This includes contractor personnel who; perform data entry, develop, or write software, perform assessments for tax purposes, perform security or telecommunications design/administration to the information system, create and maintain information system policies or procedures, architectural diagrams, and system security documentation, or have staff-like access to IRS SBU data or information systems. This includes subcontractors who support the prime contractor.
The Contractor must identify to the COR, all contractor staff that will:
Work on the contract,
Have access to or handle IRS SBU data, or
Have access to, operate, or work with information systems containing IRS SBU data.
In addition, the Contractor will identify which contractor staff has or has not completed the current annual requirements for Mandatory Briefings.
Supplemental C-SCRM Guidance: To mitigate insider threat risk, personnel screening policies and procedures must be extended to any contractor personnel with authorized access to information systems, system components, or information system services. Continuous monitoring activities should be commensurate with the contractor’s level of access to IRS SBU, PII or FTI information and should be consistent with broader Contractor policies. Screening requirements must be incorporated into agreements and flow down to sub-tier contractors.
29.3.1 PS-3 Eligibility
Contractor personnel, who are assigned to IRS contracted work, must meet the following standards
Contractor personnel must meet minimum citizenship requirements:
Contractor personnel designated as high risk must be a US citizen.
Contractor personnel designated as moderate risk must be a US citizen or Lawful Permanent Resident (LPR), with a minimum of three years of US residency as an LPR, and no break of US residency for a year or more.
Contractor personnel designated as low risk must be a US Citizen or LPR.
Contractor personnel must be federally fully tax compliant and must remain compliant for the time they are on the contract, and
All males born after 1959 must be registered with the Selective Service.
29.3.2 PS-3 Suitability
Suitability is defined as a person’s identifiable character traits and conduct sufficient to decide whether an individual’s employment or continued employment would or would not protect the integrity or promote the efficiency of the IRS. All contractor personnel are subject to a background investigation to determine their suitability and fitness to work on an IRS contract,
142
which includes access to: Treasury/Bureau information; IT and systems; facilities; and/or assets. Investigations include a Federal Bureau of Investigations (FBI) fingerprint screening and a variety of written, electronic, telephonic, or personal contact checks to determine an individual’s suitability and eligibility to work on federal contracts. The investigation must be favorably adjudicated.
Contractors are subject to continuous vetting for suitability by IRS personnel security. Continuous Vetting continuously monitors several categories of information that may affect an individual's suitability or eligibility, including:
Eligibility
Terrorism
Criminal Conduct
Suspicious Financial Activity
Public Records
Credit
Foreign Travel
For contractor-managed resources housing IRS information outside the IRS network, stafflike access must only be granted to contractor personnel who have been deemed by IRS to be eligible and suitable. The Contractor is responsible for ensuring that only authorized personnel have access to these resources, that these authorized personnel understand how to protect the resources, that access requirements are reviewed, and adjustments are made as authorized personnel change job duties, and that access is removed for any authorized personnel who are no longer assigned to IRS contract work. The Contractor must advise the IRS of any changes made to authorized personnel access privileges.
The Contractor must screen individuals prior to authorizing access to the information system. Only individuals who have been granted interim or final staff-like access can be allowed access to IRS SBU data
29.4 PS-4 Personnel Termination¶
When contractor personnel leave the IRS contract, the Contractor POC, within one business day, is responsible for notifying the COR. The COR is then responsible for notifying IRS PS. The COR will separate the Contractor in HR Connect as required. PS will cancel any pending investigations or adjudications and update the security file. Even if the background investigation is already completed, notification is required so that the separation information can be appropriately recorded in the security file. The COR must verify that the subject’s access to contractor information system is terminated and if applicable ensure all government furnished equipment has been returned to the IRS. The COR must gather any IRS provided authenticators/credentials associated with the individual and ensure they are terminated/revoked.
Upon termination of any user who has elevated privileges, access must be immediately revoked. Contractors must remove personnel from duties supporting the IRS contract and terminate all associated physical and logical access within one hour of notification that the individual no longer requires access or no longer meets applicable IRS personnel security
143
requirements. Access termination must include, as applicable, information systems, applications, cloud services, facilities, accounts, credentials, tokens, and other resources used to support the IRS contract.
29.5 PS-5 Personnel Transfer¶
When a contractor transfers on or off the contract, the contractor POC, within one business day, is responsible for notifying the COR. The COR is then responsible for notifying IRS PS. The Contractor POC must review logical and physical access authorizations to information systems/facilities when personnel are reassigned or transferred to other positions within the contractor organization, and, when warranted, retrieve all security-related contractor information IT asset-related property; and retain access to contractor information and information systems formerly controlled by a transferred individual. The Contractor POC must work with the COR to modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer. This must include a new assessment of the risk associated with the new position. If the duties of the new position are designated at a higher risk level (moving from a low-risk position to a moderate risk, or a moderate risk to a high risk), the subject must be re-investigated at the new risk level.
Contractors using a CSP must ensure that they disable system access that is no longer required within 24 hours.
29.6 PS-6 Access Agreements¶
The Contractor must ensure that individuals requiring access to IRS SBU data and information systems containing IRS SBU data sign a Non-Disclosure Agreement (NDA) and information system access agreements prior to being granted access to IRS SBU data. In preparation for the CSA, the COR must provide a sample of NDAs for the contract to ensure they have been reviewed within the past year and are valid and accurate.
Signed NDAs include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with contractor information systems to which access is authorized. Contractors can use electronic signatures to acknowledge NDAs.
Supplemental C-SCRM Guidance: The Contractor must define and document access agreements for all contractors or other external personnel who may need to access the contractor’s data, systems, or network, whether physically or logically.
Access agreements must state the appropriate level and method of access to the information system and supply chain network. Terms of access should be consistent with the Contractor’s information security policy and may need to specify additional restrictions, such as allowing access during specific timeframes, from specific locations, or only by personnel who have satisfied additional vetting requirements.
The Contractor must deploy audit mechanisms to review, monitor, update, and track access by these parties in accordance with the access agreement. As personnel vary over time, the Contractor must implement a timely and rigorous PS update process for the access
144
agreements. When information systems and network products and services are provided by an entity within the Contractor, there may be an existing access agreement in place. When such an agreement does not exist, it should be established. The Contractor must require its prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
29.7 PS-7 External Personnel Security¶
The Contractor must establish PS requirements, including security roles and responsibilities for subcontractors. subcontractors’ PS requirements must be documented and monitored for compliance. The Contractor must monitor subcontractor compliance and require providers to notify the prime contractor, who will notify IRS COR of any personnel transfers or terminations of subcontractor personnel who possess contract credentials and/or badges, or who have information system privileges. Subcontractors providing IT support must meet the PS requirements of the prime contractor, as they have staff-like access to IRS SBU data.
29.8 PS-8 Personnel Sanctions¶
A formal sanctions process for contractor personnel failing to comply with information security and privacy policies and procedures must exist and be followed. The Contractor must notify the COR within 1 business day when a formal employee sanctions process is initiated, identifying the individual sanctioned, and the reason for the sanction.
30.0 PII Processing and Transparency (PT)¶
The Personally Identifiable Information Processing and Transparency (PT) control family establishes requirements for processing Personally Identifiable Information (PII) in a lawful, transparent, and privacy-protective manner. These controls help ensure that the collection, use, sharing, retention, and disposal of PII are limited to authorized purposes, support individual privacy rights, and protect IRS SBU data throughout its lifecycle.
30.1 PT-1 PII Processing and Transparency Policy and Procedures¶
The Contractor must develop, document, implement, disseminate, maintain, and review PT policies and procedures that govern the processing of PII in support of IRS contracts. The policies and procedures must support implementation of the PII PT control family and be communicated to contractor personnel with responsibilities for processing, protecting, or managing PII.
PT policies and procedures must address, at a minimum:
Purpose
Scope
Applicability
Roles and responsibilities
Management commitment
145
Coordination among organizational entities
Compliance with applicable federal laws, regulations, IRS requirements, and contractual obligations
The Contractor must review/update policies and procedures annually or if there is a significant change.
Supplemental C-SCRM Guidance: Contractors must ensure that supply chain concerns are included in PT policies and procedures, as well as the related C-SCRM Strategy/Implementation Plan, C-SCRM Policies, and C-SCRM Plan. The policy can be included as part of the general security and privacy policy or can be represented by multiple policies.
The procedures can be established for the security and privacy program in general and individual information systems. These policies and procedures should address the purpose, scope, roles, responsibilities, management commitment, coordination among contractor entities, and privacy compliance to support systems/components within information systems or the supply chain.
Policies and procedures need to be in place to ensure that contracts state what PII data will be shared, which contractor personnel may have access to the PII, controls protecting PII, how long it can be kept, and what happens to it at the end of a contract. When working with a new supplier, ensure that the agreement includes the most recent set of applicable security requirements. Contractors need to abide by relevant laws and policies regarding information (PII and other sensitive information). The contractor must require its prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
30.3 PT-3 PII Processing Purposes¶
Contractor must ensure that PII is processed only for the purposes identified and authorized by the IRS, and the contract, which includes authorized monitoring and auditing activities. Contractor personnel must not use or disclose IRS PII for any purpose outside the authorized contractual purpose.
The contractor must:
Describe the purposes in the public privacy notices and policies of the organization, and
Restrict the access of PII to only that which is compatible with the identified purposes.
146
Identifying and documenting the purpose for processing provides contractors with a basis for understanding why PII may be processed. The term “process” includes every step of the information life cycle, including creation, collection, use, processing, storage, maintenance, dissemination, disclosure, and disposal.
30.4 PT-4 Consent¶
The Contractor must implement IRS-approved methods to obtain an individual's consent before collecting or processing personally identifiable information (PII) when consent is required. Consent mechanisms must clearly explain why the information is being collected and how it will be used, allowing individuals to make informed decisions.
30.5 PT-5 Privacy Notice¶
The Contractor must provide clear, timely, and accessible privacy notices to individuals whenever PII is collected, used, maintained, shared, or otherwise processed on behalf of the IRS. Privacy notices must be presented upon an individual's initial interaction with the Contractor as well as on any page collecting PII from the public to ensure individuals remain informed of PII processing activities.
The Contractor must ensure that all forms, electronic applications, web pages, paper documents, and any other means of collecting PII include a Privacy Notice. If the information is collected for inclusion in a Privacy Act System of Records, a Privacy Act Statement must be provided in accordance with the Privacy Act of 1974. The statement must accompany the collection and be available for the individual to retain.
Privacy notices and Privacy Act Statements must be written in plain language and, at a minimum:
Identify the legal authority authorizing the collection and processing of PII;
Describe the purpose(s) for which the information is collected and processed;
Explain how the information will be used, maintained, shared, retained, and safeguarded, as applicable;
Include any additional IRS-required privacy information, including individual rights and available choices, where applicable; and be maintained and updated to accurately reflect current information collection and processing practices.
30.6 PT-6 System of Records Notice¶
Contracts involving PII must identify any contractor’s responsibilities for supporting the IRS's System of Records Notice (SORN) requirements.
The IRS is responsible for establishing, publishing, maintaining, and reviewing SORNs, as required by applicable law, regulation, or policy. Contractors must manage Privacy Act records in accordance with the applicable SORN(s) identified through the PCLIA process.
147
The IRS may request information regarding contractor operations involving Privacy Act records to support SORN maintenance and compliance activities. Contractors must provide this information upon request.
Contractors with questions about these requirements must work through the COR, who will coordinate with Privacy, as needed.
30.8 PT-8 Computer Matching Requirements¶
Contracts involving PII must identify any contractor responsibilities for supporting the IRS's computer matching requirements.
The IRS is responsible for determining whether computer matching requirements apply and for identifying any contractor responsibilities in the contract or related agreement documents, as required by applicable law, regulation, or policy. Contractors must fulfill those responsibilities only when identified in the contract or related agreement documents. Contractors with questions about these requirements must work through the COR, who will coordinate with Privacy, as needed.
31.0 Risk Assessment (RA)¶
The Risk Assessment (RA) control family establishes requirements for identifying, assessing, and managing risks to information systems that store, process, or transmit IRS SBU data. These controls help ensure that security and privacy risks, vulnerabilities, and threats are evaluated on an ongoing basis, and that appropriate risk response and mitigation measures are implemented to reduce the likelihood and impact of adverse events affecting information systems supporting the IRS contract.
148
31.1 RA-1 Risk Assessment Policy and Procedures¶
Contractors including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the RA policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor or CSP must review/update the policies and procedures annually, or if there is a significant change to facilitate implementing RA controls. Such RA controls include risk assessments and updates to risk assessments.
31.2 RA-2 Security Categorization¶
Contracts containing SBU data for tax administration purposes must be assigned a security categorization of Moderate, unless the IRS determines they should be categorized as High. This security categorization has been established by the IRS in accordance with federal laws, executive orders, directives, policies, regulations, standards, and specifically FIPS 199.
31.3 RA-3 Risk Assessment¶
Contractors, including those using Cloud Service Providers (CSPs), must conduct and document risk assessments to identify, analyze, and evaluate threats, vulnerabilities, and the potential impact of unauthorized access, use, disclosure, disruption, modification, or destruction of IRS Sensitive But Unclassified (SBU) data and information systems supporting the IRS contract.
Risk assessments must consider the effectiveness of administrative, technical, and physical controls, including identity and access management, privileged access, user awareness training, asset management, remote access, supply chain security, contingency planning, and other factors that may affect the confidentiality, integrity, or availability of IRS information.
Risk assessments must also evaluate applicable threat sources and events, including malicious activity, insider threats, supply chain compromise, privileged user misuse, software and hardware vulnerabilities, natural disasters, environmental failures, and other conditions that could adversely affect contractor information systems.
149
Where Artificial Intelligence (AI) systems, services, models, or AI-enabled capabilities are used in support of the IRS contract, the risk assessment must also evaluate AI-specific risks, including model bias, model drift, unauthorized use, adversarial manipulation, prompt injection, model poisoning, insecure or unreliable outputs, privacy impacts, third-party dependencies, and effects on the confidentiality, integrity, and availability of IRS information and information systems.
Risk assessment results must be integrated into the Contractor's enterprise risk management, mission and business processes, system-level risk assessments, continuous monitoring, and risk response activities.
Risk assessments must be reviewed and updated at least annually and whenever significant changes occur to the information system, operating environment, or risk posture. Significant changes include, but are not limited to:
Deployment or upgrade of operating systems, applications, middleware, hardware, firmware, or cloud services.
Changes to system architecture, security configurations, cryptographic services, ports, protocols, or services.
Migration to or between Cloud Service Providers (CSPs) or other significant infrastructure changes.
Introduction of new technologies, including Artificial Intelligence (AI), or changes to system functionality that could affect security or privacy risk.
31.4 RA-5 Vulnerability Monitoring and Scanning¶
Vulnerability monitoring and scanning help identify security weaknesses before they can be exploited and support the timely remediation of vulnerabilities affecting information systems that process, store, or transmit IRS SBU data. Contractors, including those using Cloud Service Providers (CSPs), must implement vulnerability scanning and monitoring capabilities that perform authenticated scans, detect missing security updates, patches, insecure configurations, and other known vulnerabilities, and automatically update vulnerability signatures, plugins, and detection content to maintain current coverage.
Contractors, including those using Cloud Service Providers (CSPs), must perform authenticated vulnerability scans at least monthly on information systems and components supporting the IRS contract, including workstations, servers, network devices, mobile devices, virtual machines, containers, operating systems, databases, applications, application programming interfaces (APIs), storage services, and cloud infrastructure.
Where vulnerability scanning is performed by a Cloud Service Provider as part of a managed service, the Contractor must verify that scanning is conducted in accordance with contractual and service-level requirements, review the results, and ensure identified vulnerabilities are tracked, prioritized, and remediated in accordance with IRS Publication 4812.
Contractors, including those using Cloud Service Providers (CSPs), must implement vulnerability management solutions that support interoperability, automate vulnerability
150
identification and assessment activities, and facilitate the consistent identification, prioritization, tracking, and reporting of vulnerabilities across information systems.
Vulnerability management tools must use industry-standard formats and identifiers, including the Common Vulnerabilities and Exposures (CVE) naming convention, and leverage recognized vulnerability intelligence sources, such as the National Vulnerability Database (NVD), Common Weakness Enumeration (CWE), or equivalent authoritative sources. Where supported, tools should use standardized assessment and configuration content to automate vulnerability detection, security configuration assessments, and vulnerability impact analysis.
Contractors, including those using Cloud Service Providers (CSPs), that develop, maintain, host, or provide applications or application services supporting the IRS contract must implement automated application security testing throughout the software development lifecycle to identify and remediate security vulnerabilities prior to deployment.
At a minimum, the Contractor or CSP must:
Perform Static Application Security Testing (SAST) or equivalent source code analysis before software is released to production.
Perform Dynamic Application Security Testing (DAST), or equivalent runtime security testing, before deployment and at least monthly for internet-facing or production applications.
Perform application security testing whenever changes are made to application source code, application programming interfaces (APIs), application configurations, or supporting components that could affect the application's security posture.
Identify, track, prioritize, and remediate discovered vulnerabilities in accordance with the Contractor's vulnerability management process and IRS Publication 4812 remediation requirements.
Integrate application security testing with secure software development, change management, and continuous integration/continuous deployment (CI/CD) processes, where applicable.
Application security testing should include, as appropriate, source code analysis, runtime testing, software composition analysis (SCA), dependency scanning, secrets detection, and configuration validation to identify common software vulnerabilities, insecure coding practices, and vulnerable third-party components.
At the direction of the CSCA Team, the Contractor or CSP must send monthly vulnerability scan results in comma-separated value (CSV) format, for all critical, high, and moderate vulnerabilities detected in the information system to the IRS COR who will share the results with the CSCA Team.
The CSV file must be the original information exported by the vulnerability scanning tool and include the following information: the scan summary results showing the number of critical, high, and moderate vulnerabilities and the listing of critical, high, and medium vulnerabilities that include the CVE reference.
151
The output and results of monthly vulnerability scanning, static source code analysis, and dynamic build testing must be retained for the duration of the contract to support security assessment trend analysis and provided to the COR or CSCA Team upon request.
Newly discovered vulnerabilities must be added to the list of vulnerabilities to be scanned prior to a new scan, to ensure that the contractor will take steps to mitigate those vulnerabilities in a timely manner.
Vulnerabilities must be prioritized for remediation based on risk, with remediation efforts addressing the highest-risk vulnerabilities first. Vulnerabilities identified in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog must be treated as the highest priority due to evidence of active exploitation. Contractors must continuously monitor the CISA KEV catalog and remediate vulnerabilities by the CISA mandated remediation due date. If a KEV vulnerability is identified after the mandated due date, remediation must occur within 15 calendar days of discovery.
Vulnerabilities identified on the scan reports must be remediated within the following time frames:
Critical - vulnerabilities must be mitigated within 30 days from the date of discovery,
High - vulnerabilities must be mitigated within 60 days from the date of discovery,
Medium - vulnerabilities must be mitigated within 120 days from the date of discovery, and
Low - vulnerabilities must be mitigated within 180 days from the date of discovery.
As part of the vulnerability remediation process, the contractor must identify if a vulnerability is a false positive and provide evidence to substantiate it being a false positive.
Contractors using a CSP must ensure that they or the CSP scan information systems and hosted applications (i.e., OS/infrastructure, web applications, and databases) for vulnerabilities at least monthly and when new vulnerabilities potentially affecting the system/applications are identified and reported.
Contractors using a CSP must ensure that they or the CSP remediate vulnerabilities using the following timeframes:
Vulnerabilities on the CISA KEV list -By CISA due date or within 15 days of discovery if already overdue.
Critical - vulnerabilities must be mitigated within 15 days from date of discovery.
High- vulnerabilities must be mitigated within 30 days from date of discovery, and
Medium- vulnerabilities must be mitigated within 90 days from date of discovery.
Supplemental C-SCRM Guidance: Vulnerability monitoring must cover suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers in the contractor’s supply chain. This includes employing data collection tools to maintain a continuous state of awareness about potential vulnerability to suppliers, as
152
well as the information systems, system components, and raw inputs that they provide through the cybersecurity supply chain. Vulnerability monitoring activities should take place at all three levels of the Contractor. Scoping vulnerability monitoring activities requires contractors to consider suppliers as well as their sub-suppliers. Contractors, where applicable and appropriate, may consider providing customers with a Vulnerability Disclosure Report (VDR) to demonstrate proper and complete vulnerability assessments for components listed in SBOMs. The VDR should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component or product. The VDR should also contain information on plans to address the CVE. Contractors must consider publishing the VDR within a secure portal available to customers and signing the VDR with a trusted, verifiable, private key that includes a timestamp indicating the date and time of the VDR signature and associated VDR. Contractors must also consider establishing a separate notification channel for customers in cases where vulnerabilities arise that are not disclosed in the VDR. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
31.5 RA-8 Risk Assessment – Privacy Impact Assessments¶
When contractor performance will involve the collection, creation, receipt, maintenance, use, dissemination, or disposal of IRS Sensitive But Unclassified (SBU) information, including Personally Identifiable Information (PII) or Federal Tax Information (FTI), the IRS Business Unit must initiate a Privacy and Civil Liberties Threshold Assessment (PCLTA) during acquisition planning and development of the Statement of Work (SOW) or Performance Work Statement (PWS). The PCLTA is used to determine whether a Privacy and Civil Liberties Impact Assessment (PCLIA) is required.
If a PCLIA is required, the contractor must provide information necessary to support its preparation, completion, or update. The PCLIA must be completed and approved before the contractor receives or is granted access to IRS SBU information.
The contractor must cooperate with the IRS Business Unit, Project Manager, Contracting Officer's Representative (COR), and Privacy Office by providing accurate and timely information regarding the contractor's systems, services, data flows, processing activities, privacy controls, and any other information necessary to complete or update the PCLIA.
The contractor must notify the IRS of proposed changes to systems, services, business processes, or the scope of work that may affect the collection, use, maintenance, sharing, or disposal of IRS SBU information so the IRS can determine whether the PCLTA or PCLIA must be updated.
The PCLIA must be reviewed and updated every 3 years or when there is a major change to the systems or contract in accordance with IRS policy.
31.6 RA-9 Critically Analysis (C-SCRM Control)¶
Contractors must ensure critical system components and functions are identified by performing a criticality analysis for systems, system components, or system services at
153
decision points in the SDLC, such as when an architecture or design is being developed, modified, or upgraded.
Contractors must complete a criticality analysis as a prerequisite input to assessments of cybersecurity supply chain risk management activities. First, contractors must complete a criticality analysis as part of the frame step of the C-SCRM Risk Management Process. Then, findings generated in the assess step activities (e.g., criticality analysis, threat analysis, vulnerability analysis, and mitigation strategies) update and tailor the criticality analysis. A symbiotic relationship exists between criticality analysis and other assessed step activities in that they inform and enhance one another.
31.7 RA-10 Threat Hunting¶
Threat hunting is the proactive process of searching for an information system, network, cloud environment, or endpoint for signs of malicious activity that have evaded or bypassed traditional security controls such as antivirus, EDR, firewalls, or intrusion detection systems. Unlike traditional security monitoring, which responds to alerts generated by security tools, threat hunting assumes an attacker may already be present and actively looks for evidence of compromise before an alert is generated.
Contractors, including those using CSPs, must establish, implement, and maintain a cyber threat hunting capability to proactively identify, investigate, and respond to advanced threats affecting information systems, cloud environments, and IRS data. The threat hunting capability must continuously analyze security telemetry, audit logs, endpoint activity, network traffic, identity and access events, cloud service activity, API activity, and other relevant data sources to:
Search for Indicators of Compromise (IOCs), Indicators of Attack (IOAs), and anomalous or unauthorized activity within organizational systems and cloud environments;
Detect, investigate, track, and support the containment and disruption of malicious activity that evades or bypasses preventive and detective security controls; and
Identify attacker Tactics, Techniques, and Procedures (TTPs), including evidence of persistence, privilege escalation, lateral movement, command and control activity, and data exfiltration.
Contractors must perform threat hunting on a continuous basis. Threat hunting activities must leverage centralized security telemetry (SIEM), threat intelligence, and documented procedures, and findings must be investigated and handled in accordance with the contractor's incident response procedures.
32.0 System and Services Acquisition (SA)¶
The System and Services Acquisition (SA) control family establishes requirements for integrating security and privacy into the acquisition, development, implementation, and maintenance of information systems, system components, and services supporting the IRS contract. These controls help ensure that security, privacy, and supply chain risk management
154
requirements are considered throughout the System Development Life Cycle (SDLC) and whenever information technology assets, software, hardware, cloud services, or other technologies are evaluated, acquired, developed, or deployed to protect IRS SBU data.
32.1 SA-1 System and Services Acquisition Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of the SA policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
Contractors must review/update policies and procedures annually, if there is a significant change, or following certain events including assessment or audit findings and security or privacy incidents; to ensure adequate information SA policies are developed and implemented.
Information Security must be considered a requirement for all systems used to enter, process, store, display, or transmit IRS SBU data. Information Security provides for the availability of systems, ensures the integrity and confidentiality of information, and the authentication/nonrepudiation of parties in electronic transactions.
32.2 SA-2 Allocation of Resources¶
Contractors, including those using Cloud Service Providers (CSPs), must incorporate security, privacy, and supply chain risk management requirements into the planning, acquisition, development, implementation, operation, maintenance, and modernization of information systems, applications, cloud services, and other technologies supporting the IRS contract.
At a minimum, the Contractor or CSP must:
Identify and document security, privacy, and supply chain risk management requirements during mission, business process, and system planning activities.
Assess and procure the security and privacy capabilities necessary to protect information systems, applications, cloud services, and supporting infrastructure throughout the system development life cycle (SDLC).
Determine, document, and allocate sufficient personnel, funding, technologies, and other resources to implement, operate, maintain, monitor, and continuously improve required security and privacy controls.
155
Include security, privacy, and supply chain risk management activities as discrete elements within organizational planning, budgeting, capital investment, acquisition, and resource management processes.
Ensure resources are available to support system acquisition, implementation, sustainment, continuous monitoring, incident response, contingency planning, and the management of supply chain risks throughout the SDLC.
32.3 SA-3 System Development Life Cycle (SDLC)¶
The Contractor must acquire, develop, implement, operate, and maintain information systems using a documented System Development Life Cycle (SDLC) methodology that integrates information security and privacy requirements throughout all phases of the system lifecycle.
The Contractor must define, document, and maintain information security and privacy roles and responsibilities, formally identify individuals assigned those responsibilities, and ensure they are accountable for performing their assigned duties.
Information security and privacy risk management processes must be integrated into all SDLC activities to identify, assess, document, mitigate, and continuously manage risks from system initiation through system disposal.
The SDLC must incorporate security planning, secure architecture and design, secure coding practices, security and privacy testing, vulnerability remediation, configuration management, change control, and security authorization activities to ensure appropriate safeguards are implemented prior to deployment and maintained throughout system operations.
32.4 SA-4 Acquisition Process¶
Contractors must incorporate information security, privacy, and supply chain security requirements into all acquisitions involving information systems, software, hardware, cloud services, managed services, artificial intelligence (AI) capabilities, professional services, and system components that store, process, transmit, or protect IRS Sensitive But Unclassified (SBU) information.
Acquisition documentation, including contracts, purchase orders, task orders, and statements of work, must clearly define:
Information security and privacy functional requirements
Security assurance requirements
Supply chain security requirements
Cloud security requirements
AI security requirements, when applicable
Secure software development requirements
Configuration baseline requirements
Security documentation deliverables
Security testing requirements
Vulnerability remediation requirements
156
Incident reporting requirements
Continuous monitoring requirements
Roles and responsibilities
Security acceptance criteria
Contractors acquiring Cloud Service Provider (CSP) services must ensure cloud offerings satisfy applicable IRS Publication 4812 security requirements prior to implementation. Cloud services must support secure configuration, logging, encryption, identity federation, continuous monitoring, vulnerability management, and geographic restrictions required by the IRS. Systems storing, processing, transmitting, or backing up IRS SBU data must reside only within approved U.S. geographic locations. Contractors must ensure cloud regions, disaster recovery sites, backup repositories, replication services, and storage services remain within approved U.S. locations.
Prior to acquisition, Contractors must evaluate suppliers and software providers for supply chain risks. Contractors must validate the integrity, authenticity, provenance, and supportability of software, firmware, hardware, open-source components, third-party libraries, container images, and software dependencies before deployment into production environments.
Prior to acquiring AI systems, AI-enabled services, foundation models, or machine learning capabilities, Contractors must perform security, privacy, supply chain, legal, and data protection assessments to determine whether the technology is appropriate for processing IRS SBU.
Contractor acquired systems and services must support Zero Trust Architecture principles, including strong identity verification, least privilege, multifactor authentication, continuous authorization, comprehensive logging, encryption of data in transit and at rest, API security, and granular access control.
Systems, software, hardware, cloud services, and security appliances must be delivered using secure-by-default configurations. Default passwords must be changed prior to deployment. Unnecessary services, ports, protocols, APIs, administrative interfaces, sample accounts, and demonstration content must be removed or disabled before production use.
Contractors must ensure that, prior to acquiring information systems, software, hardware, cloud services, professional services, maintenance, or other system components, prospective suppliers, vendors, manufacturers, and service providers are not prohibited, suspended, debarred, or otherwise restricted from supporting or supplying U.S. Government information systems. As part of the acquisition and supply chain risk management process, Contractors should verify supplier eligibility using the U.S. Government Consolidated Screening List. Supplier eligibility must be revalidated annually and whenever there is a significant change in the supplier relationship or acquisition.
Information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data must be hosted, operated, and maintained within the United States, its territories, and possessions. Contractors must ensure that all operational, administrative, maintenance, and
157
support activities for these systems are performed only by personnel who are physically located within the United States, its territories, and possessions. IRS SBU data must not be processed, administered, accessed for operational support, or replicated from locations outside the United States, its territories, and possessions unless explicitly authorized in writing by the IRS. The Contractor must ensure that systems intended to contain IRS SBU data (i.e., beyond commercial products used as components) must be developed physically within the United States, its possessions, and territories., by U.S. citizens, or those with lawful permanent resident status.
Administrative access, security monitoring, Managed Detection and Response (MDR), Security Operations Center (SOC) monitoring, database administration, cloud administration, DevOps support, technical support, remote maintenance, privileged access, backup administration, and incident response activities involving IRS systems must be performed only by personnel physically located within the United States, its territories, and possessions unless specifically authorized by the IRS.
32.5 SA-5 System Documentation¶
Contractors, including those using Cloud Service Providers (CSPs), must develop, maintain, and protect system and user documentation for information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data. Documentation must be reviewed annually, updated whenever significant changes occur, and made available only to authorized personnel based on the sensitivity of the information.
System documentation must, at a minimum, include:
Secure installation, configuration, hardening, operation, and maintenance procedures for the system, system components, cloud services, and supporting infrastructure.
Configuration baselines, approved security settings, and procedures for securely administering operating systems, databases, applications, network devices, cloud resources, virtualization platforms, and security appliances.
Procedures for the implementation, operation, maintenance, and monitoring of security and privacy controls, including identity and access management, encryption, logging, auditing, vulnerability management, incident response, backup and recovery, and configuration management.
Documentation of administrative and privileged functions, including associated security risks, known limitations, compensating controls, and known vulnerabilities that could affect the secure operation of the system.
Architecture diagrams, data flow diagrams, trust boundaries, external system interfaces, cloud service architecture, and interconnections with other systems.
Operational procedures for security monitoring, patch management, change management, disaster recovery, and business continuity.
User documentation must, at a minimum, include:
- Instructions for securely accessing and using the system and its security and privacy features.
158
Guidance on authentication requirements, Multifactor Authentication (MFA), password management, protection of IRS Sensitive But Unclassified (SBU) data, and appropriate handling of sensitive information.
User responsibilities for maintaining confidentiality, integrity, and availability of IRS information, recognizing and reporting security or privacy incidents, and complying with organizational security policies.
Guidance describing user-accessible security and privacy capabilities, acceptable use requirements, methods for securely interacting with the system, and practices that reduce cybersecurity and privacy risks.
Documentation containing sensitive security information, including system architecture, administrative procedures, privileged operations, security configurations, and known vulnerabilities, must be protected from unauthorized disclosure, maintained under configuration management, and distributed only to personnel with an authorized need-toknow.
32.6 SA-8 Security and Privacy Engineering Principles¶
Contractors, including those using Cloud Service Providers (CSPs), must incorporate security and privacy engineering principles into the specification, design, development, implementation, operation, maintenance, and modification of information systems and system components that store, process, or transmit IRS Sensitive But Unclassified (SBU) data. Contractors must limit the collection, processing, maintenance, and disclosure of Personally Identifiable Information (PII) to that which is relevant and necessary to support the IRS contract and implement data minimization principles throughout the system lifecycle.
Security and privacy engineering principles must, at a minimum:
Integrate security, privacy, and supply chain risk management requirements throughout the System Development Life Cycle (SDLC).
Implement layered security protections and clearly defined physical, logical, and trust boundaries.
Incorporate secure architecture, secure design, privacy-by-design, and secure coding practices into system development and maintenance activities.
Perform threat modeling and risk analysis to identify threats, attack vectors, misuse cases, design weaknesses, and appropriate mitigations.
Tailor security and privacy controls based on organizational, operational, and system-specific risks.
Ensure personnel responsible for designing, developing, testing, or maintaining information systems receive appropriate secure development and privacy engineering training.
Support informed risk-based decisions by implementing safeguards that reduce security and privacy risks to acceptable levels.
159
Security and privacy engineering principles must be applied to newly developed systems and incorporated into major system upgrades or significant modifications to existing systems, to the extent technically and operationally feasible.
32.7 SA-9 External System Services¶
Contractors, including those using Cloud Service Providers (CSPs), Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Managed Service Providers (MSPs), Managed Security Service Providers (MSSPs), Artificial Intelligence (AI) services, or other external service providers, must ensure that all external system services used to store, process, transmit, or provide access to IRS Sensitive But Unclassified (SBU) data comply with the applicable requirements of IRS Publication 4812 .
Contractors using Cloud Service Providers (CSPs) to receive, process, store, or transmit Federal Tax Information FTI and PII must ensure that the applicable Cloud Service Offering (CSO) is FedRAMP Authorized at the Moderate or High impact level. Contractors must verify and document the FedRAMP authorization and have IRS business unit approval before introducing FTI into the cloud environment and periodically verify that the authorization remains valid.
Prior to using an external system service, Contractors must document and maintain formal agreements that clearly define security, privacy, operational, and supply chain responsibilities for both the Contractor and the external service provider. Agreements must, at a minimum, address system ownership, security responsibilities, incident reporting, vulnerability management, configuration management, logging and monitoring, encryption requirements, access control, audit support, business continuity, disaster recovery, data retention, media sanitization, and secure disposal of IRS information.
Contractors must perform and document security due diligence before engaging an external service provider. At a minimum, this evaluation must assess the provider's security posture, applicable security authorizations (such as FedRAMP, when applicable), compliance with contractual requirements, supply chain risks, geographic hosting locations, administrative support locations, subcontractor relationships, and the provider's ability to protect IRS SBU data throughout the service lifecycle.
Contractors must define and document government oversight responsibilities, Contractor responsibilities, user roles, privileged access responsibilities, and external provider responsibilities for all externally provided services. Shared responsibility models applicable to cloud services must be documented and annually reviewed to ensure all required security controls are assigned, implemented, and maintained.
Contractors must implement processes to continuously monitor external service providers to verify ongoing compliance with IRS security, privacy, and supply chain requirements. Monitoring activities should include periodic security assessments, review of independent audit reports, continuous monitoring results, vulnerability and patch management status, security incident reporting, service-level performance, changes to the provider's authorization status, and significant changes to the provider's operating environment.
160
External service providers must identify, and document all required network functions, ports, protocols, services, application programming interfaces (APIs), service endpoints, and external interfaces necessary to support IRS information systems. Contractors must ensure that only approved and documented functions, ports, protocols, APIs, and services are enabled, and that unnecessary services are disabled or removed prior to production use.
Contractors remain responsible for ensuring the confidentiality, integrity, and availability of IRS SBU data processed by external service providers and must maintain sufficient oversight to demonstrate ongoing compliance with IRS Publication 4812.
32.8 SA-10 Developer Configuration Management¶
Contractors, including those using Cloud Service Providers (CSPs), must require software developers to implement configuration management and secure development practices throughout the software development life cycle (SDLC), including design, development, testing, implementation, operation, maintenance, and disposal.
At a minimum, the Contractor must ensure that:
Security and privacy requirements, vulnerabilities, deficiencies, and corrective actions are documented, tracked, and managed throughout the SDLC.
Changes to software, system components, and associated security or privacy controls are evaluated for potential security and privacy impacts, approved through the change management process, documented, tested, and verified prior to implementation.
Software developers develop and maintain a Security Test and Evaluation (ST&E) Plan that defines security testing activities, implements the planned testing, documents the results, and remediates identified security and privacy issues before deployment.
Developer testing activities must be integrated with secure software development, configuration management, vulnerability management, and change management processes to ensure software changes do not adversely affect the security or privacy posture of information systems supporting the IRS contract.
32.9 SA-11 Developer Testing and Evaluation¶
Contractors, including those using Cloud Service Providers (CSPs), that develop, customize, configure, or maintain software supporting the IRS contract must perform security and privacy testing in a dedicated development or testing environment prior to deployment into production.
At a minimum, the Contractor or CSP must:
- Develop, implement, and maintain a Security Test and Evaluation (ST&E) Plan and, where applicable, a Privacy Assessment Plan that define the security and privacy testing activities performed throughout the Software Development Life Cycle (SDLC).
161
Perform security testing throughout the SDLC using appropriate testing methodologies, including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA), configuration validation, and functional security testing, as applicable.
Evaluate the security of application functionality, external interfaces, system architecture, design, source code, third-party components, Application Programming Interfaces (APIs), and other security-relevant system components.
Identify, document, track, remediate, and verify the correction of security and privacy weaknesses discovered during testing before deployment into production.
Maintain evidence demonstrating the execution of testing activities, identified findings, remediation actions, and final testing results.
Scan all custom-developed or customized software for security vulnerabilities before deployment using automated application security testing tools appropriate to the software and operating environment.
Developer testing activities must be integrated with secure software development, configuration management, vulnerability management, and change management processes to ensure software changes do not adversely affect the security or privacy posture of information systems supporting the IRS contract.
Contractors using AI-assisted software development tools to generate, modify, or recommend source code must ensure that AI-generated code is subject to the organization's approved SDLC. AI-generated code must undergo manual review, static and dynamic security testing as appropriate, vulnerability assessment, peer review, and formal approval prior to deployment into IRS production environments. Contractors remain responsible for the security, integrity, provenance, and quality of all software delivered in support of the IRS contract, regardless of whether the software was authored by developers or generated with AI assistance.
32.10 SA-15 Development Process, Standards, and Tools¶
The Contractor must require the developer of an information system, system component, or information system service to follow a documented development process that:
Explicitly addresses security and privacy requirements.
Identifies the standards and tools used in the development process.
Documents the specific tool options and tool configurations used in the development process, and
Documents, manages, and ensures the integrity of changes to the process and/or tools used in development.
The Contractor must review the development process, standards, tools, and tool options/configurations at a minimum annually, to determine if the process, standards, tools, and tool options/configurations selected and employed can satisfy IRS security and privacy requirements as defined by IRS Publication 4812.
162
32.11 SA-21 Developer Screening (C-SCRM Control)¶
Contractors must ensure the developer of the system, system component, or system service has appropriate access authorizations necessary for their specific assigned duties; and satisfies the personnel screening criteria (e.g., clearances, background checks, citizenship, nationality) defined in the contractor personnel security policy .
Contractors must implement screening processes for their internal developers. For system integrators who may be providing key developers that address critical components, the contractor must ensure that appropriate processes for developer screening have been used. The screening of developers should be included as a contractual requirement and be a flow-down requirement for relevant sub-level subcontractors who provide development services or who have access to the development environment.
32.12 SA-22 Unsupported System Components¶
Contractors, including those using CSP’s, must replace information system components when support for the components is no longer available from the developer, vendor, or manufacturer or provide options for alternative sources for continued support for unsupported components such as extended support agreements with the vendor.
Information system components examples include mainframes, workstations, servers (e.g., database, email, authentication, web, proxy, file, domain name), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), OS, middleware, applications, and software versions. Support for information system components includes, but are not limited to, security patches, software updates, firmware updates, replacement parts, and maintenance contracts.
32.12.1 Open-Source Software
Contractors, including those using Cloud Service Providers (CSPs), must ensure that OpenSource Software (OSS), libraries, frameworks, containers, packages, and other communitydeveloped software components used to support the IRS contract are actively maintained and supported throughout their operational lifecycle.
Contractors must not deploy or continue using unsupported, abandoned, or end-of-life opensource components unless an approved risk assessment has been performed, appropriate compensating controls have been implemented, and continued use has been authorized by the contractor designated Authorizing Official.
Open-source software must be obtained only from trusted and verifiable repositories or approved internal repositories. Contractors must validate the integrity and provenance of opensource software components before use, maintain a Software Bill of Materials (SBOM) or equivalent inventory of software dependencies, and use Software Composition Analysis (SCA) or equivalent tools to identify unsupported, vulnerable, or unauthorized open-source components throughout the software development lifecycle and during continuous monitoring.
163
33.0 System and Communications Protection (SC)¶
The System and Communications Protection (SC) control family establishes requirements for protecting information and communications transmitted, processed, or stored by information systems supporting the IRS contract. These controls help prevent the unauthorized disclosure, modification, or interception of IRS Sensitive But Unclassified (SBU) data by securing network communications, system boundaries, and information flows through the use of appropriate architectural, cryptographic, and boundary protection mechanisms.
33.1 SC-1 System and Communications Protection Policy and Procedures¶
Contractors, including those using CSP’s must designate an official to manage the development, documentation, and dissemination of SC policies and procedures.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update policies and procedures annually, or if there is a significant change to SA technologies.
33.2 SC-2 Separation of System and User Functionality¶
Contractors, including those using Cloud Service Providers (CSPs), must logically and, where appropriate, physically separate user functionality from privileged system management functionality to prevent unauthorized access to administrative capabilities and reduce the risk of compromise.
At a minimum, the Contractor or CSP must:
Separate administrative interfaces, management networks, and privileged functions from user-accessible functions and production workloads using appropriate logical or physical controls.
Restrict access to system management functions to authorized privileged users using separate authentication mechanisms and role-based access controls.
Isolate administrative interfaces using dedicated management networks, subnets, or equivalent segmentation technologies, where appropriate.
Protect system management functions with additional security controls commensurate with the sensitivity and risk of the managed systems.
164
System management functionality includes the administration of operating systems, databases, applications, cloud services, virtualization platforms, network devices, security appliances, and other information system components requiring privileged access.
33.4 SC-5 Denial-of-Service (DoS) Protection¶
Contractors, including those using Cloud Service Providers (CSPs), must implement technical and operational controls to detect, prevent, and mitigate the effects of Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks affecting information systems that support the IRS contract.
At a minimum, the Contractor or CSP must:
Deploy boundary protection technologies, such as firewalls, intrusion prevention systems, Web Application Firewalls (WAFs), DDoS protection services, or equivalent capabilities, to detect and filter malicious network traffic.
Implement network segmentation, traffic filtering, rate limiting, traffic shaping, or other appropriate controls to limit the impact of DoS and DDoS attacks.
165
Design systems and network infrastructure with sufficient capacity, redundancy, failover, and resiliency to maintain the availability of critical services during denialof-service events.
Monitor network traffic for indicators of DoS or DDoS attacks and integrate detection and response activities with the Contractor's continuous monitoring and incident response processes.
Denial-of-service protections must be appropriate for the system architecture and operating environment, including on-premises, cloud, hybrid, and internet-facing services.
33.5 SC-7 Boundary Protection¶
Contractors, including those using Cloud Service Providers (CSPs), must protect information system boundaries through managed interfaces and boundary protection technologies to control communications between internal networks, external networks, and publicly accessible services.
At a minimum, the Contractor or CSP must:
Implement managed interfaces, such as firewalls, gateways, routers, encrypted tunnels, or equivalent boundary protection technologies, for all external network connections.
Establish physically or logically separated subnetworks (for example, demilitarized zones (DMZs)) for publicly accessible system components.
Limit external network connections to those necessary to support authorized business operations.
Configure managed interfaces to enforce documented traffic flow policies that deny network communications by default and permit only explicitly authorized inbound and outbound traffic.
Protect the confidentiality and integrity of information transmitted across system boundaries using appropriate security controls.
Document all traffic flow exceptions, including the business justification and approved duration, review them at least annually, and promptly remove exceptions that are no longer required.
Firewalls must be implemented, managed, and continuously monitored at network boundaries. Where packet filtering is employed, stateful inspection firewalls or equivalent technologies must be used. Internet access points must support deep packet inspection and intrusion prevention capabilities, as appropriate. Wireless networks must be protected using firewalls or equivalent boundary protection mechanisms.
The information system must prevent remote devices from simultaneously connecting to the system and external networks through split tunneling.
166
Connections from contractor systems to entertainment media download services (for example, iTunes and Netflix), and the installation of software supporting such services, are prohibited unless specifically authorized to support official contract requirements.
Contractors, including those using Cloud Service Providers (CSPs) must implement DLP controls to monitor, detect, and prevent the unauthorized transmission, storage, printing, copying, uploading, downloading, or sharing of IRS SBU data across endpoints, networks, email systems, cloud services, web applications, collaboration platforms, removable media, and other approved data transfer mechanisms.
Contractors, including those using CSPs, must ensure that network infrastructure, security technologies, and information systems supporting IRS operations are capable of securely operating in IPv6 environments. Newly developed, acquired, or significantly upgraded systems that process, store, transmit, or provide access to IRS information must implement native IPv6 capabilities in accordance with applicable Federal requirements
Where Cloud Service Providers (CSPs), Artificial Intelligence (AI) systems, or external platform services are used in support of the IRS contract, contractors must ensure that:
Communications between users, applications, APIs, cloud services, and AI services are protected using approved encryption and authentication mechanisms;
Data transmitted to and from AI systems is protected against unauthorized disclosure, tampering, or interception;
Administrative interfaces, service-to-service communications, and model access endpoints are restricted to authorized personnel and approved systems; and security controls are implemented to prevent unauthorized access to IRS SBU, PII, or FTI during transmission or processing.
Supplemental C-SCRM Guidance: The Contractor must implement appropriate monitoring mechanisms and processes at the boundaries between their systems and suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers’ systems. Provisions for boundary protections should be incorporated into agreements with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. There may be multiple interfaces throughout the Contractor, supplier systems, networks, and the SDLC.
Appropriate vulnerability, threat, and risk assessments should be performed to ensure proper boundary protection for supply chain components and supply chain information flow. Vulnerability, threat, and risk assessments can aid in scoping boundary protection to a relevant set of criteria and help manage associated costs. For contracts with external service providers, contractors must ensure that the provider satisfies boundary control requirements pertinent to environments and networks within their span of control. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
167
33.5.1 SC-7 (13) Boundary Protection | Isolation of Security Tools, Mechanisms, and…¶
Contractors must isolate information security tools, mechanisms, and support components from other internal system components by implementing physically separate subnetworks, with managed interfaces to other components of the system.
33.6 SC-8 Transmission Confidentiality and Integrity¶
Contractors, including those using Cloud Service Providers (CSPs), must protect the confidentiality and integrity of IRS SBU data transmitted across internal and external networks by implementing FIPS 140-3 or later validated cryptographic modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program (CMVP), they may continue to be used until replacement is required by changes in CMVP validation status.
At a minimum, the Contractor or CSP must:
Encrypt data in transit using NIST-approved cryptographic protocols and algorithms appropriate to the operating environment.
Implement cryptographic mechanisms that protect transmitted information from unauthorized disclosure, modification, replay, or interception.
Protect all communication paths used to transmit IRS SBU data, including communications involving servers, workstations, mobile devices, network devices, cloud services, Application Programming Interfaces (APIs), and other information system components.
Use secure communication protocols, such as Transport Layer Security (TLS) or Internet Protocol Security (IPsec)to protect network communications.
Verify the integrity of transmitted information using approved cryptographic integrity mechanisms, such as digital signatures, Message Authentication Codes (MACs), or cryptographic hash functions.
Supplemental C-SCRM Guidance: The requirements for transmission confidentiality and integrity should be integrated into agreements with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Acquirers, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers may repurpose existing security mechanisms (e.g., authentication, authorization, or encryption) to achieve contractor confidentiality and integrity requirements. The degree of protection should be based on the sensitivity of information to be transmitted and the relationship between the contractor and the suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
168
33.7 SC-10 Network Disconnect¶
The network connection associated with a communications session must be terminated at the end of the session or after 30 minutes of inactivity. Network disconnect applies to internal and external networks. Terminating network connections associated with specific communications sessions include de-allocating TCP/IP address or port pairs at the operating system level, a deallocating the networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection.
Applications requiring continuous, real-time screen display (e.g., network management products, certain call center workstations as defined by contractor policy) must be exempt from the network inactivity disconnect threshold provided the following requirements are met:
The logon session was not initiated by a privileged account (e.g., root in Linux/Unix, Master in Unisys).
The inactivity exemption is documented in the appropriate operational policy approved by the CSR, and
The workstation is in a restricted and controlled access area open only to contractors with an approved IRS clearance.
The workstation initiates a screen lock in accordance with AC-11 Device Lock.
33.8 SC-12 Cryptographic Key Establishment and Management¶
Cryptographic keys must be established and managed when cryptography is employed within the system in accordance with NIST SP 800-57, Recommendation for Key Management, for key generation, distribution, storage, access, and destruction.
Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Contractors must define key management requirements in policy including
Encryption key recovery requirements must include:
Identification of which keying material requires backup or archive for later recovery.
The location was backed up or archived keying material must be stored.
Responsibility assignment for protecting backed up or archived keying material.
Required procedures for storing and recovering the keying material.
Listing of who can request a recovery of the keying material and under what conditions.
Listing of who will be notified when a key recovery has taken place and under what conditions, and
Managing trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems.
169
The security role of an Encryption Recovery Agent must be assigned to support recovery processes. Encryption products must provide for encryption key recovery to support availability needs. Vendor-supplied default encryption keys must be changed as soon as the system or software has been installed.
33.9 SC-13 Cryptography Protection¶
Contractors, including those using Cloud Service Providers (CSPs), must use FIPS 140-3 validated cryptographic modules to protect IRS information whenever cryptographic protections are required. Cryptographic modules shall be implemented in accordance with NIST guidance and the Cryptographic Module Validation Program (CMVP). Where legacy FIPS 140-2 validated modules remain authorized by the CMVP, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules. Contractor and CSP information systems must be configured to use TLS 1.2 and support TLS 1.3, if interoperability permits, TLS 1.3 is preferred. TLS must be implemented in accordance with NIST SP 800-52 Rev 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations.
Contractors must ensure non-disclosure of their private key. Private keys must be protected using, at a minimum, a strong password. Contractors must report any suspected loss or compromise of the private keys to the Contractor IT security team.
33.10 SC-15 Collaborative Computing Devices and Applications¶
Contractors, including those using Cloud Service Providers (CSPs), must configure collaborative computing devices and applications to protect the confidentiality and privacy of IRS Sensitive But Unclassified (SBU) data.
At a minimum, remote activation of audio, video, screen sharing, recording, or other collaboration capabilities must be disabled unless explicitly authorized for operational or administrative purposes. Collaborative computing devices and applications must provide a clear visual and/or audible indication whenever microphones, cameras, screen sharing, recording, or other collaboration functions are active.
This requirement applies to collaboration technologies including video conferencing systems, web conferencing platforms, collaboration applications, digital whiteboards, conference room systems, and other devices or services that support audio, video, messaging, screen sharing, or document collaboration. Contractors must annually review collaboration platform configurations to ensure remote activation features remain appropriately restricted and that only authorized users are permitted to enable collaboration capabilities.
170
33.11 SC-17 Public Key Infrastructure (PKI) Certificates¶
Contractors, including those using Cloud Service Providers (CSPs), that create, manage, or use Public Key Infrastructure (PKI) certificates must establish and maintain documented policies and procedures governing the lifecycle of digital certificates and cryptographic keys. At a minimum, the Contractor or CSP must:
Document procedures for the generation, issuance, installation, distribution, renewal, revocation, replacement, and destruction of digital certificates.
Obtain public key certificates only from trusted Certificate Authorities (CAs) or approved PKI service providers.
Configure systems to trust only approved trust anchors and certificate authorities within organizational trust stores or certificate stores.
Generate and store subscriber key pairs using FIPS 140-3 or later validated cryptographic modules at Security Level 2 or higher, or the current FIPS-approved equivalent. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
Protect private keys from unauthorized disclosure, modification, or misuse using strong authentication, encryption, hardware-backed key storage where supported, and access controls appropriate to the sensitivity of the key.
Promptly revoke certificates when a private key is suspected or confirmed to be compromised, when directed by authorized management, when the certificate is no longer required, or when the associated identity, device, or service is no longer authorized.
Annually review certificate inventories and certificate status to identify expired, revoked, unauthorized, or unused certificates and remove or replace them as appropriate.
33.12 SC-18 Mobile Code¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and enforce policies and procedures governing the use of mobile code and mobile code technologies within information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data. The Contractor or CSP must define authorized and prohibited mobile code technologies and implement technical controls to authorize, monitor, and restrict their execution.
Mobile code includes executable content transmitted across a network and executed on a remote system, such as JavaScript, HTML5, WebGL, Java applets, VBScript, browser extensions, scripts, macros, and other client-side or server-side executable content.
At a minimum, the Contractor or CSP must:
171
Permit only approved mobile code technologies required to support authorized business functions.
Prevent the introduction and execution of unauthorized or malicious mobile code through technical and administrative controls.
Require mobile code obtained from external sources to be digitally signed or otherwise validated using trusted integrity verification mechanisms before execution, where technically feasible.
Apply appropriate security controls, including sandboxing, application control, code signing validation, browser security settings, endpoint protection, and malware scanning, to reduce the risks associated with mobile code.
Annually review authorized mobile code technologies and remove or disable those that are no longer required or present unacceptable risk.
When required by the IRS, Contractors must provide source code or other supporting artifacts for IRS review to validate that mobile code developed or deployed in support of IRS systems does not introduce unacceptable security risks or malicious functionality.
33.14 SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver)¶
The contractor information systems must request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources (e.g., DNS servers).
Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures or clients use authenticated channels to recursive resolvers that perform such validations.
Systems that use technologies other than the DNS to map between host and service names and network addresses provide some other means to enable clients to verify the authenticity and integrity of response data.
33.15 SC-22 Architecture and Provisioning for Name/Address Resolution Service¶
Contractors, including those using Cloud Service Providers (CSPs), must design, implement, and maintain name and address resolution services that provide high availability, resiliency, security, and separation of internal and external name resolution functions.
At a minimum, the Contractor or CSP must:
Implement redundant authoritative name resolution services to eliminate single points of failure and support continued operations during system failures or service disruptions.
Deploy at least two authoritative Domain Name System (DNS) servers, or equivalent redundant name resolution services, where applicable.
Separate internal and external name resolution services using dedicated infrastructure, logical separation, or split horizon (split-brain) DNS to prevent unauthorized disclosure of internal name resolution information.
Configure internal name resolution services to respond only to authorized internal clients and external name resolution services to respond only to authorized external requests.
Implement high availability and failover capabilities for critical name resolution services, including cloud-hosted or managed DNS services, to maintain service continuity.
Review and validate the configuration, redundancy, security, and resiliency of name resolution services and promptly remediate identified deficiencies.
Where cloud-hosted or managed name resolution services are used, contractors must ensure equivalent security controls are implemented to protect the confidentiality, integrity, and availability of DNS services and associated configuration data.
173
33.16 SC-23 Session Authenticity¶
Contractors, including those using Cloud Service Providers (CSPs), must protect the authenticity and integrity of communication sessions by implementing NIST-approved cryptographic protocols and mechanisms that authenticate communicating parties and protect session data from unauthorized interception, modification, hijacking, or replay.
At a minimum, the Contractor or CSP must:
Protect communications using Transport Layer Security (TLS) version 1.2 or later, or other NIST-approved secure communication protocols, as applicable.
Configure systems to use only approved cryptographic algorithms, cipher suites, key lengths, and certificate validation procedures in accordance with current federal cryptographic standards.
Validate the identity of communicating systems through trusted digital certificates or equivalent cryptographic authentication mechanisms before establishing secure sessions.
Protect session establishment, renegotiation, and termination processes against unauthorized interception, spoofing, downgrade attacks, replay attacks, and session hijacking.
Disable insecure or deprecated protocols, cipher suites, and cryptographic algorithms that are no longer approved for protecting federal information.
33.17 SC-28 Protection of Information at Rest¶
Contractors, including those using Cloud Service Providers (CSPs), must protect IRS Sensitive But Unclassified (SBU) data at rest using FIPS 140-3 or later validated cryptographic modules, to prevent unauthorized access or disclosure. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program, they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
At a minimum, the Contractor or CSP must:
Encrypt IRS SBU data stored on servers, workstations, laptops, mobile devices, databases, storage arrays, Storage Area Networks (SANs), Network-Attached Storage (NAS), virtual storage, cloud storage services, backup media, removable media, and other digital storage devices.
Implement full-disk encryption, file-level encryption, database encryption, storagelevel encryption, or equivalent technologies.
Protect encryption keys in accordance with organizational key management policies and restrict access to authorized personnel.
Ensure backups, snapshots, replicas, archives, and disaster recovery copies containing IRS SBU data remain encrypted throughout their lifecycle.
174
- Encrypt removable media and portable storage devices prior to storing or transporting IRS SBU data.
Supplemental C-SCRM Guidance: The Contractor must include provisions for the protection of information at rest into their agreements with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. The contractor must also ensure that they provide appropriate protections within the information systems and networks for data at rest for the suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers information, such as source code, testing data, blueprints, and intellectual property information. This control should be applied throughout the SDLC, including during requirements, development, manufacturing, test, inventory management, maintenance, and disposal. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
33.18 SC-36 Distributed Processing and Storage (C-SCRM Control)¶
Contractors must ensure the distribution of information processing and storage components across multiple physical and logical locations.
Processing and storage can be distributed both across the contractor’s systems and networks and across SDLC. The Contractor should ensure that these techniques are applied in both contexts.
33.19 SC-39 Process Isolation¶
Contractors must ensure the information system maintains a separate execution domain for each executing process. Each information system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, by implementing separate address spaces. Process isolation technologies, include sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. This capability is available in most commercial OSs that employ multi-state processor technologies.
34.0 System and Information Integrity (SI)¶
The System and Information Integrity (SI) control family ensures the integrity, reliability, and trustworthiness of information systems by protecting them from malicious code, unauthorized changes, software vulnerabilities, and other conditions that could compromise system operations or the confidentiality, integrity, or availability of information. These controls focus on identifying, preventing, detecting, and responding to security threats through activities such as vulnerability management, malicious code protection, system monitoring, software and firmware integrity verification, flaw remediation, and information validation. Effective implementation of SI controls helps ensure that information systems continue to operate as
175
intended while maintaining the integrity of IRS Sensitive But Unclassified (SBU) data throughout the system lifecycle.
34.1 SI-1 System and Information Integrity Policy and Procedures¶
Contractors or CSP’s must designate an official to manage the development, documentation, and dissemination of SI policies and procedures for security and privacy controls.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update the policies and procedures annually, or if there is a significant change to facilitate implementing SI security controls.
34.2 SI-2 Flaw Remediation¶
Contractors, including those using Cloud Service Providers (CSPs), must establish, document, and maintain a centralized flaw remediation and patch management process to identify, assess, prioritize, test, deploy, verify, and monitor security updates for all information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data.
At a minimum, the Contractor or CSP must:
Identify, report, assess, and remediate security vulnerabilities and information system flaws.
Evaluate, test, approve, and deploy security-relevant software and firmware updates, including patches, hot fixes, service packs, and security updates, prior to production implementation to verify effectiveness and minimize operational impact.
Install security updates within the timeframe established in IRS Publication 4812
Integrate flaw remediation activities into the organization's configuration and change management processes to ensure changes are documented, tracked, approved, and verified.
Address vulnerabilities identified through vulnerability scanning, security assessments, continuous monitoring, incident response activities, threat intelligence, vendor notifications, or system error reporting.
Use automated tools to monitor the patch and remediation status of information system components at least monthly and identify systems with missing or failed security updates.
176
- Verify that workstations, laptops, mobile devices, servers, virtual machines, network devices, cloud resources, and other managed assets meet organizational security requirements, including current security updates, before connecting or reconnecting to the production environment.
Patch management activities must be centrally managed, documented, and annually reviewed to verify the effectiveness of the flaw remediation program and maintain the security posture of contractor information systems.
Supplemental C-SCRM Guidance: The output of flaw remediation activities provides useful input into the ICT/OT SCRM processes. Contractors should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
34.3 SI-3 Malicious Code Protection¶
Contractors, including those using Cloud Service Providers (CSPs), must implement centrally managed malicious code protection capabilities to prevent, detect, quarantine, and remediate malware across information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data.
At a minimum, the Contractor or CSP must:
Deploy malicious code protection on workstations, servers, Virtual Desktop Infrastructure (VDI), mobile devices, virtual machines, and other managed endpoints.
Configure malicious code protection to automatically scan files, removable media, email, web traffic, downloads, and other applicable network communications for malicious code.
Perform automated malware scans of managed endpoints at least weekly and provide real-time protection for files and processes.
Automatically update malware detection engines, signatures, and threat intelligence as new updates become available.
Quarantine, block, or remove detected malicious code and generate alerts for suspected or confirmed malware events.
Scan authorized removable media before permitting access to organizational systems.
Centrally manage malicious code protection policies, configuration, updates, alerts, and reporting across the contractor information system.
Prevent users from disabling, bypassing, or otherwise circumventing malicious code protection mechanisms without explicit administrative authorization.
Establish procedures to evaluate and resolve false positives while minimizing disruption to system availability and business operations.
177
34.3.1 Email Security
Contractors, including those using Cloud Service Providers (CSPs), must use electronic messaging services in a manner that protects the confidentiality, integrity, and appropriate use of IRS Sensitive But Unclassified (SBU) data.
At a minimum, the Contractor must:
Encrypt email messages and attachments containing Federal Tax Information (FTI), Personally Identifiable Information (PII), or IRS SBU data using FIPS 140-3 or later validated cryptographic modules. Where legacy FIPS 140-2 validated modules remain authorized by the Cryptographic Module Validation Program (CMVP), they may continue to be used until replacement is required by changes in CMVP validation status. New systems, acquisitions, implementations, and major upgrades must use FIPS 140-3 validated cryptographic modules.
Ensure IRS SBU data is not included in email subject lines or other unencrypted message metadata.
Use only IRS-approved email accounts and collaboration services to conduct official business when such accounts are provided. Personal email accounts must not be used to conduct business in support of an IRS contract.
Prohibit automatic forwarding of official email to non-IRS or non-Treasury email accounts unless expressly authorized by the IRS.
Not transmit IRS SBU data to non-government email accounts except when specifically authorized to support official contract requirements and protected using approved security controls.
Use electronic messaging and collaboration platforms only for authorized business purposes and in accordance with IRS records management, information security, and privacy requirements.
Refrain from posting, transmitting, or otherwise disclosing IRS information through social media, public websites, forums, or other publicly accessible services without prior written authorization from the IRS.
Prohibit the use of Government-Furnished Equipment (GFE), IRS-provided accounts, or contractor resources supporting the contract for commercial activities, chain letters, unsolicited messages, or other unauthorized purposes.
Electronic messaging includes email, instant messaging, team collaboration platforms, chat services, video conferencing platforms, and other approved collaboration technologies used to conduct official business. Contractors should ensure these services are configured to support encryption, access controls, audit logging, retention, and data loss prevention (DLP) capabilities.
Supplemental C-SCRM Guidance: Because most of the code operated in contractor systems are not developed by the contractor, malicious code threats often originate from the supply chain. These controls apply to contractors with code-related responsibilities (e.g., developing code, installing patches, performing system upgrades, etc.), as well as applicable contractor information systems and networks. Contractors should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
178
34.4 SI-4 System Monitoring¶
Contractors, including those using Cloud Service Providers (CSPs), must implement a centralized, continuous monitoring capability to detect, analyze, and respond to unauthorized activity, security events, vulnerabilities, and indicators of compromise affecting information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data.
At a minimum, the Contractor or CSP must:
Implement automated monitoring capabilities, such as Security Information and Event Management (SIEM), host-based monitoring, network monitoring, cloudnative monitoring, or equivalent technologies, to provide near real-time detection, analysis, alerting, and reporting of security events.
Monitor local, network, remote, cloud, and privileged activities to identify unauthorized access, anomalous behavior, policy violations, indicators of compromise, and attempted or successful attacks.
Monitor inbound and outbound network communications for suspicious, malicious, or unauthorized activity and generate alerts for events requiring investigation or response.
Collect, correlate, and analyze security events from endpoints, servers, network devices, cloud services, applications, security tools, and other relevant information system components.
Protect monitoring systems, security logs, alerts, and related information from unauthorized access, modification, or deletion.
Retain network traffic header information at internet access points for at least one year.
Deploy host-based monitoring capabilities on information system components, where technically feasible.
Integrate vulnerability monitoring, threat intelligence, incident response, and continuous monitoring activities to support timely detection, investigation, containment, and remediation of security events.
Increase monitoring activities during periods of elevated threat or increased organizational risk in accordance with organizational incident response and continuous monitoring procedures.
Continuously monitor AI systems and services used in support of IRS contracts to detect unauthorized use, misuse, anomalous behavior, model manipulation, prompt injection attempts, unauthorized disclosure of IRS SBU data, privacy events, and other security risks. AI monitoring activities must generate auditable records and integrate with the Contractor's security operations and incident response processes.
Supplemental C-SCRM Guidance: This control includes monitoring vulnerabilities that result from past supply chain cybersecurity compromises, such as malicious code implanted during software development and set to activate after deployment. System monitoring is frequently performed by external service providers. SLAs with these providers should be structured to appropriately reflect this control. Contractors must require their prime
179
contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
34.5 SI-5 Security Alerts, Advisories, and Directives¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and maintain processes to receive, evaluate, distribute, and respond to security alerts, advisories, and directives from authoritative sources to support the timely identification and remediation of security threats and vulnerabilities.
At a minimum, the Contractor or CSP must:
Subscribe to and monitor applicable security alerts, advisories, and directives issued by software and hardware vendors, Cloud Service Providers, CISA, NIST, and other relevant authoritative sources.
Evaluate the applicability and potential impact of received alerts and advisories on contractor information systems and IRS Sensitive But Unclassified (SBU) data.
Assign primary and alternate personnel responsible for receiving, evaluating, and acting upon security alerts to ensure continuity of operations.
Track and document actions taken in response to applicable security alerts and advisories, including vulnerability remediation, configuration changes, compensating controls, or risk acceptance, as appropriate.
Supplemental C-SCRM Guidance: The contractor must evaluate security alerts, advisories, and directives for cybersecurity supply chain impacts and follow up if needed. US-CERT, FASC, and other authoritative entities generate security alerts and advisories that are applicable to CSCRM. Additional laws and regulations will impact who and how additional advisories are provided. Contractors must ensure that their information-sharing protocols and processes include sharing alerts, advisories, and directives with relevant parties with whom they have an agreement to deliver products or perform services. Contractors must provide direction or guidance as to what actions are to be taken in response to sharing such an alert, advisory, or directive. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.
34.6 SI-7 Software, Firmware, and Information Integrity¶
Contractors, including those using Cloud Service Providers (CSPs), must implement integrity verification mechanisms to detect, prevent, and respond to unauthorized modification of software, firmware, operating systems, applications, security configurations, Artificial Intelligence (AI) models, and other information system components supporting IRS Sensitive But Unclassified (SBU) data.
At a minimum, the Contractor or CSP must:
- Implement integrity verification mechanisms, such as cryptographic hashes, digital signatures, secure boot, code signing, File Integrity Monitoring (FIM), or equivalent technologies, to detect unauthorized modification of system components.
180
Perform integrity verification following system startup or restart, installation of hardware, software, firmware, or AI model updates, security-relevant events, identification of new threats, and annually thereafter based on organizational risk.
Protect system kernels, firmware (including BIOS/UEFI), operating systems, applications, middleware, configuration baselines, security settings, and other critical system components from unauthorized modification.
Establish and enforce policies governing the installation of software and restrict users from installing unauthorized software or code.
Protect AI models, training data, supporting components, and model configurations throughout their lifecycle against unauthorized modification, model extraction, prompt injection, adversarial manipulation, and other attacks that could compromise system integrity or IRS SBU data.
Ensure changes to software, firmware, AI models, and security configurations are authorized, tested, documented, and managed through approved configuration and change management processes.
Detect and report unauthorized changes to configuration baselines, security settings, privileged access, executable code, and other critical system components as part of the organization's continuous monitoring and incident response capabilities.
Integrity monitoring capabilities must generate auditable records and integrate with configuration management, vulnerability management, continuous monitoring, and incident response processes to support timely investigation and remediation of unauthorized changes.
Supplemental C-SCRM Guidance: This control applies to the contractor and applicable supplier products, applications, information systems, and networks. The integrity of all applicable systems and networks should be systematically tested and verified to ensure that it remains as required so that the systems/components traversing through the supply chain are not impacted by unanticipated changes.
The integrity of systems and components should also be tested and verified. Applicable verification tools include digital signature or checksum verification; acceptance testing for physical components; confining software to limited privilege environments, such as sandboxes; code execution in contained environments prior to use; and ensuring that if only binary or machine-executable code is available, it is obtained directly from the OEM or a verified supplier or distributer.
This control applies to contractors and applicable suppliers’ information systems and networks. When purchasing an ICT/OT product, a contractor should perform due diligence to understand what a supplier’s integrity assurance practices are. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant subtier contractors.
34.7 SI-8 Spam Protection¶
Contractors, including those using Cloud Service Providers (CSPs), must implement centrally managed email security capabilities to detect, filter, and block spam, phishing, malware, and
181
other malicious email content. Email protection mechanisms must automatically receive and apply signature, reputation, policy, and detection engine updates.
34.8 SI-10 Information Input Validation¶
Contractors, including those using Cloud Service Providers (CSPs), must ensure that software and applications developed or maintained in support of an IRS contract implement input validation controls to verify that data received from users, systems, applications, Application Programming Interfaces (APIs), and external sources is accurate, complete, conforms to expected formats, and meets defined validation criteria (e.g., character set, data type, length, numerical range, and acceptable values) before processing.
Input validation controls must prevent invalid, malformed, or malicious input that could compromise the confidentiality, integrity, or availability of the application or IRS Sensitive But Unclassified (SBU) data.
At a minimum, applications must validate input to protect against common application attacks, including injection attacks (e.g., SQL, command, and LDAP injection), Cross-site Scripting (XSS), buffer overflows, insecure deserialization, path traversal, and other input manipulation techniques. Input validation requirements must be incorporated into secure software development, testing, and change management processes.
34.9 SI-11 Error Handling¶
Contractors, including those using Cloud Service Providers (CSPs), must ensure that software and applications developed or maintained in support of an IRS contract identify, log, and handle error conditions in a timely and secure manner.
At a minimum, the Contractor or CSP must:
Configure applications to prevent error messages, debug information, stack traces, or other diagnostic information from disclosing system details, sensitive information, or implementation details that could be used to compromise the application or information system.
Present only sanitized error messages to users while recording detailed diagnostic information in protected logs accessible only to authorized personnel.
Error handling mechanisms must support secure software development practices and integrate with the Contractor's logging, monitoring, vulnerability management, and incident response processes.
34.10 SI-12 Information Management, Retention, and Information Disposal¶
Contractors or CSP’s must manage and maintain IRS SBU data within the information system, according to record retention standards. The IRS COR must identify the record retention standards to the contractor. Contractors must minimize both security and privacy
182
risks by disposing of IRS SBU data when it is no longer needed. The disposal or destruction of information applies to original information as well as copies and archived records, and backups including audit logs that may contain PII.
The Contractor must limit PII being processed in the information life cycle to the following elements identified within the PCLIA.
The Contractor records must maintain and manage records in accordance with an approved PCLIA, General Records Schedule Document 12829, Records Control Schedules (RCS) Document 12990, and additional requirements defined in the contract.
When receiving physical IRS records or other accountable information from the IRS, the Contractor must acknowledge receipt in accordance with the Form 3210 requirements. The acknowledgment must be completed and returned to the IRS to verify receipt and maintain chain-of-custody accountability for all records transferred
The Contactor must destroy documents with IRS SBU data (including PII and tax information) by properly shredding, burning, mulching, pulping, or pulverizing beyond recognition and reconstruction. If other guidance is issued for document destruction, the Contractor must use the most stringent requirement.
The Contractor must work with the IRS COR to complete Form 11671 disposal record when records have reached their final disposition and are eligible for destruction.
In addition, once the contract expires, all data must be returned to the IRS, unless specifically identified otherwise in the contract. Records must not be maintained by the Contractor in paper or electronically, unless approved by the IRS COR.
Contractors must ensure that all IRS data and IRS-derived data are in commercially available or open and non-proprietary format for transition in accordance with the National Archives and Records Administration (NARA) disposition guidance.
NIST Special Publication 800-88, Revision 2: Guidelines for Media Sanitization, specifies the minimum required sanitization techniques to Clear, Purge, or Destroy various media and IRS SBU.
34.11 SI-16 Memory Protection¶
Contractors, including those using Cloud Service Providers (CSPs), must implement memory protection mechanisms on information systems that store, process, or transmit IRS Sensitive But Unclassified (SBU) data to prevent unauthorized code execution and protect the integrity of system memory.
At a minimum, the Contractor or CSP must enable operating system and hardware-supported memory protection features, such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and other equivalent technologies.
183
34.12 SI-18 Personally Identifiable Information Quality Operations¶
Contracts processing, transmitting or storing PII must identify any contractor responsibilities for supporting the IRS's personally identifiable information quality operations requirements.
The IRS is responsible for maintaining the quality, accuracy, relevance, timeliness, and completeness of PII throughout the information lifecycle, as required by applicable law, regulation, or policy.
When the contract identifies PII quality operations responsibilities, contractors must fulfill those responsibilities. This may include verifying the accuracy of PII received from the IRS or other authorized sources, maintaining its quality and accuracy throughout the information lifecycle under the contractor's control, and correcting or deleting inaccurate or outdated PII when verified or otherwise reliable information is received from the IRS or, when authorized by the contract, directly from the individual.
Upon request, contractors must provide the IRS with information needed to support PII quality operations, including responding to inquiries about specific records or individuals and documenting, correcting, or deleting inaccurate or outdated PII, as required by the contract. Contractors with questions about these requirements must work through the COR, who will coordinate with Privacy, as needed.
34.13 SI-19 De-Identification¶
The contractor must remove unnecessary PII elements from statistical datasets requiring synthetic data in place of PII and tax information where possible.
Contracts involving PII must identify any contractor responsibilities for supporting the IRS's de-identification requirements.
The IRS is responsible for determining when de-identification is required and for identifying any contractor responsibilities in the contract, as required by applicable law, regulation, or policy. When the contract assigns de-identification responsibilities, contractors must perform those responsibilities. This may include removing or transforming PII elements, evaluating the effectiveness of those activities, and supporting IRS review and oversight, as required by the contract.
Contractors must provide information needed to support IRS review and oversight of deidentification activities, including responding to inquiries regarding the methods used and the effectiveness of the de-identification. Contractors with questions about these requirements must work through the COR, who will coordinate with Privacy, as needed.
184
34.14 SI-20 Tainting (C-SCRM Control)¶
The Contractor has embedded data or capabilities in their development systems or system components to determine if organizational data has been exfiltrated or improperly removed from the organization.
Suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers may have access to the sensitive information of a contractor and IRS SBU.
35.0 Supply Chain Risk Management (SR)¶
The Supply Chain Risk Management (SR) control family helps ensure that risks associated with third-party suppliers, products, software, hardware, cloud services, and external service providers are identified, assessed, managed, and monitored throughout the system lifecycle. These controls support the protection of IRS Sensitive But Unclassified (SBU) data by reducing risks arising from the acquisition, development, integration, operation, maintenance, and disposal of information systems and their components.
35.1 SR-1 Supply Chain Risk Management Policy and Procedures¶
Contractors must designate an official to manage the development, documentation, and dissemination of the SR policies and procedures.
The policies and procedures must address:
Purpose
Scope
Roles
• Responsibilities
Management Commitment
Coordination among Organization Entities
Compliance
The Contractor must review/update the SR policies and procedures annually, or if there is a significant change.
35.2 SR-2 Supply Chain Risk Management Plan¶
Contractors, including those using Cloud Service Providers (CSPs), must establish, implement, and maintain a Supply Chain Risk Management (SCRM) Plan to identify, assess, manage, and monitor supply chain risks associated with the acquisition, development, integration, operation, maintenance, and disposal of information systems, services, software, hardware, and other system components used in support of the IRS contract.
185
The Contractor must designate personnel responsible for implementing and overseeing the SCRM program and ensure appropriate coordination among acquisition, security, engineering, privacy, and operational functions.
The SCRM Plan must:
Define the organization's supply chain risk tolerance and risk management strategy.
Establish processes to identify, assess, mitigate, monitor, and report supply chain risks throughout the System Development Life Cycle (SDLC).
Describe security, privacy, resiliency, and trustworthiness requirements for systems, services, and system components acquired, developed, or maintained in support of the IRS contract.
Document the supply chain controls, risk mitigation measures, and monitoring activities implemented to manage identified risks.
Be reviewed and updated at least annually and whenever significant changes occur to the system, supply chain, operational environment, or risk posture.
35.3 SR-3 Supply Chain Controls and Processes¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and implement processes to identify, assess, manage, and remediate weaknesses and deficiencies within the supply chain that could adversely affect the confidentiality, integrity, or availability of IRS Sensitive But Unclassified (SBU) data or information systems supporting the IRS contract.
At a minimum, the Contractor or CSP must:
Identify and assess supply chain risks associated with suppliers, subcontractors, Cloud Service Providers, managed service providers, software, hardware, firmware, open-source software, third-party components, Artificial Intelligence (AI) models and services, datasets, development tools, libraries, Application Programming Interfaces (APIs), and other products or services supporting the IRS contract.
Implement administrative, technical, and physical controls to prevent, detect, and mitigate supply chain threats, including counterfeit or unauthorized components, malicious code, unauthorized modifications, compromised software dependencies, insecure development practices, model tampering, and other supply chain-related risks.
Verify the integrity, authenticity, and provenance of software, firmware, hardware, AI models, datasets, and other critical system components before deployment using appropriate mechanisms such as digital signatures, cryptographic hashes, code signing, Software Bills of Materials (SBOMs), model documentation, or equivalent verification methods, where applicable.
Vet third-party AI models, datasets, libraries, tools, and AI service providers before acquisition or use and assess upstream and downstream dependencies that could affect the confidentiality, integrity, or availability of IRS information or information systems.
186
Evaluate supply chain risks throughout the System Development Life Cycle (SDLC), including acquisition, development, integration, deployment, operation, maintenance, updates, and disposal of systems and system components.
Coordinate supply chain risk management activities with acquisition, security, engineering, privacy, and operational personnel to ensure identified risks are appropriately addressed.
Document implemented supply chain controls, identified risks, mitigation measures, and monitoring activities within the Supply Chain Risk Management (SCRM) Plan.
Annually review supply chain risks and reassess suppliers, service providers, AI components, and system components whenever significant changes occur to the system, supplier, operational environment, or threat landscape.
35.4 SR-5 Acquisition Strategies, Tools, and Methods¶
Contractors, including those using Cloud Service Providers (CSPs), must establish and implement acquisition strategies, tools, and processes to identify, assess, and mitigate supply chain risks associated with the procurement, development, integration, operation, maintenance, and disposal of information systems, software, hardware, cloud services, Artificial Intelligence (AI) technologies, and other system components used in support of the IRS contract.
At a minimum, the Contractor or CSP must:
Incorporate supply chain risk management requirements into acquisition, procurement, contracting, and vendor management processes.
Evaluate suppliers, products, and services for supply chain risks prior to acquisition and annually thereafter based on organizational risk.
Implement acquisition controls to reduce the risk of counterfeit products, malicious code, unauthorized modifications, compromised software dependencies, insecure development practices, and other supply chain threats.
Verify the integrity and provenance of acquired software, hardware, firmware, AI models, third-party libraries, and other critical system components using appropriate validation mechanisms, where applicable.
Provide periodic supply chain risk management awareness training to personnel with responsibilities for acquisition, procurement, software development, vendor management, system administration, and supply chain management.
Annually review acquisition strategies and risk mitigation measures and update them to address changes in technology, suppliers, the threat environment, or organizational risk.
Acquisition strategies should be informed by the Contractor's Supply Chain Risk Management (SCRM) Plan and supply chain risk assessments to ensure security, privacy, resiliency, and trustworthiness requirements are considered throughout the system development life cycle (SDLC).
187
35.5 SR-6 Supplier Assessments and Reviews¶
Contractors, including those using Cloud Service Providers (CSPs), must assess and review supply chain risks associated with suppliers, subcontractors, service providers, and the products or services they provide in support of the IRS contract.
At a minimum, the Contractor or CSP must:
Conduct and document supplier risk assessments at least annually and whenever significant changes occur to the supplier, services provided, operational environment, or threat landscape.
Evaluate supplier security, privacy, and Supply Chain Risk Management (SCRM) practices, including organizational governance, secure development practices, vulnerability management, incident response capabilities, and compliance with contractual security requirements.
Assess the risks associated with subcontractors and other upstream suppliers, including the supplier's ability to manage and monitor its own supply chain.
Consider Foreign Ownership, Control, or Influence (FOCI), geographic risk, and other factors that could affect the confidentiality, integrity, or availability of IRS Sensitive But Unclassified (SBU) data or information systems.
Use multiple sources of information to evaluate supplier risk, including independent assessments, audit reports, security certifications, contractual documentation, threat intelligence, publicly available information, and other relevant sources.
Examples of independent assessment evidence include:
o FedRAMP authorizations
o SOC reports
o ISO certifications
o vulnerability management practices
o security questionnaires
- Document identified risks, required mitigation actions, and decisions regarding supplier acceptance, continued use, or remediation within the Supply Chain Risk Management (SCRM) Plan or other organizational risk management documentation.
Supplier assessments must include providers of software, hardware, firmware, cloud services, managed services, open-source software, third-party libraries, Artificial Intelligence (AI) models and services, and other critical system components supporting the IRS contract.
Examples of assessment evidence, such as:
Independent assessment reports
FedRAMP authorizations
SOC reports
ISO certifications
Vulnerability management practices
Security questionnaires
188
35.6 SR-8 Notification Agreements¶
The Contractor and must notify the IRS COR and CSIRC Incident Response Operations Team at 833-575-9810 or CSIRC@irs.gov which is available 24x7x365, immediately upon discovery of a potential Supply Chain Attack/Compromise that effects an information system and/or system component that supports the IRS contract. Within one hour of notification of a possible Supply Chain Attack/Compromise, the COR must notify the CSCA team at it.cyber.csa.request@irs.gov.
The Contractor must ensure that agreements and procedures are established with entities involved in the SR for the system, system components, or system services for notification of SR compromises and results of assessments or audits.
The establishment of agreements and procedures facilitates communication among SR entities. Early notification of compromises and potential compromises in the SR that can potentially adversely affect or have adversely affected information systems or system components is essential for organizations to effectively respond to such incidents. The results of assessments or audits may include open-source information that contributed to a decision or result and could be used to help the SR entity resolve a concern or improve its processes.
35.7 SR-10 Inspection of Systems or Components¶
Contractors, including those using Cloud Service Providers (CSPs), must inspect information systems, system components, and associated media for evidence of tampering, unauthorized modification, counterfeit components, or other supply chain risks when equipment is received, removed from Contractor-controlled areas, returned to service, or when a security incident or other circumstance indicates a potential compromise.
At a minimum, the Contractor or CSP must:
Inspect systems and components for physical or logical signs of tampering before installation, deployment, or return to operational use.
Verify the integrity and authenticity of hardware, firmware, software, and other critical system components following maintenance, repair, transportation, storage, or other events that increase supply chain risk.
Investigate anomalies that could indicate a potential supply chain compromise, including changes in packaging, labeling, shipping methods, supplier, manufacturing location, component specifications, chain of custody, or other unexpected conditions.
Document inspection results, identified deficiencies, and corrective actions, and report suspected tampering or supply chain compromises in accordance with established incident reporting procedures.
Inspection procedures must be integrated with the Contractor's asset management, configuration management, incident response, and supply chain risk management processes to ensure suspected compromises are promptly investigated and remediated.
189
Supplemental C-SCRM Guidance: Contractors must inspect critical systems and components, at a minimum, for assurance that tamper resistance controls are in place and to examine whether there is evidence of tampering. Products or components must be inspected prior to use and periodically thereafter. Inspection requirements should also be included in contracts with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Contractors must require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors and flow down to subcontractors, when relevant.
35.8 SR-11 Component Authenticity¶
Contractors, including those using Cloud Service Providers (CSPs), must establish, implement, and maintain anti-counterfeit policies and procedures to prevent, detect, and respond to counterfeit or unauthorized hardware, software, firmware, and other system components used in support of the IRS contract.
At a minimum, the Contractor or CSP must:
Implement processes to detect and prevent counterfeit or unauthorized components from entering the information system or supply chain.
Procure system components only from authorized manufacturers, developers, distributors, resellers, vendors, contractors, or other trusted sources, and maintain documentation sufficient to verify the authenticity, integrity, and provenance of critical system components.
Verify the authenticity and integrity of hardware, software, firmware, and other critical system components prior to acquisition, installation, deployment, and return to operational service.
Train personnel involved in the acquisition, development, system administration, security, maintenance, and configuration management of IRS information systems to recognize indicators of counterfeit or tampered hardware, software, firmware, and other system components, and to report suspected counterfeit components in accordance with established incident response and supply chain risk management procedures.
Maintain configuration control and chain of custody for system components awaiting maintenance, repair, storage, transportation, or return to operational service to prevent unauthorized modification, substitution, or tampering.
Remove, quarantine, investigate, and report suspected counterfeit or unauthorized components in accordance with established incident response and supply chain risk management procedures.
Anti-counterfeit controls must be integrated with the contractor's acquisition, asset management, configuration management, maintenance, and supply chain risk management processes to reduce the risk of introducing counterfeit components, unauthorized modifications, malicious code, or other supply chain threats into information systems supporting the IRS contract.
190
35.9 SR-12 Component Disposal¶
Contractors, including those using Cloud Service Providers (CSPs), must dispose of software, firmware, source code, documentation, development tools, system components, storage media, and other information system assets containing IRS Sensitive But Unclassified (SBU) data using IRS-approved sanitization and disposal methods.
At a minimum, the Contractor or CSP must:
Sanitize or destroy software, firmware, source code, documentation, cryptographic keys, storage media, and system components before disposal, reuse, transfer, return, or release from organizational control.
Dispose of system components throughout the system development life cycle (SDLC), including during development, testing, deployment, maintenance, modernization, and retirement, as applicable.
Use approved media sanitization techniques appropriate to the type of media or technology, including secure erasure, cryptographic erasure, physical destruction, or equivalent methods.
Remove or securely erase IRS SBU data, authentication credentials, cryptographic keys, configuration information, logs, and other sensitive information from physical, virtual, and cloud-based storage before disposal or reuse.
Maintain records of component disposal and media sanitization activities, to demonstrate compliance with IRS Publication 4812.
Component disposal activities must be integrated with the Contractor's asset management, media protection, configuration management, and supply chain risk management processes to prevent unauthorized disclosure or recovery of IRS SBU data.
191
36.0 Termination of Contract¶
At the end of the contract period, or if the contract is terminated within the contract period, the contractor must coordinate with the IRS to ensure contractor and contractor employee access privileges to IRS information, IRS systems, and facilities are revoked in a timely manner, as necessary.
A completed Form 14604, Contractor Separation Checklist is required. This checklist is used to separate a contractor from an IRS contract, and to document the return of all security items, Government property, and information/records to the appropriate office.
Contractors must confirm to IRS officials that information furnished under the contract has been properly returned, disposed of, or destroyed. This includes assuring the IRS that all IT assets, including laptops, information systems, servers, routers, printers, faxes, switches, voice recordings, and all removable and fixed media have been sanitized of all IRS information prior to returning to production for other uses.
Contractors required to return IRS information and property (as a part of the contract requirements) must use a process that ensures that the confidentiality of the SBU data is always protected during transport.
A log must be maintained to ensure that all media destroyed has been identified by the date of destruction, content of media, serial number, type of media (CD, DVD), etc.) destruction performed, personnel performing destruction, and witness.
All VoIP must be sanitized prior to returning to production, when SBU data is stored on these devices.
All hard drives and removable media must be inventoried, sanitized, and logged to demonstrate data destruction for all IT assets used to handle SBU data.
All hard copies must be returned using double-wrapped envelopes and traceable mail.
36.1 Destruction or Return of SBU Data¶
When the contract is officially closed out, SBU data provided to the contractor or created by the contractor must be returned to the IRS or destroyed as directed in writing by the IRS. This includes copies of reports, extra copies, photo impressions, information system printouts, carbon paper, notes, stenographic notes, and work papers.
See Section MP-6 Media Sanitization, concerning media sanitation and Section SI-12 Information Management, Retention, and Information Disposal, concerning the transfer of data to the IRS.
Contractors must follow the IRS RCS, Document 12990 and General Records Schedules (GRS), Document 12829 for NARA approved records retention and destruction authorization
192
applicable to their IRS business use. The contract owner must have the records retention schedules available and be incorporated into the contract.
Destruction of media is the ultimate form of sanitization. After the destruction of the media, they cannot be reused as originally intended. Physical destruction can be accomplished using a variety of methods, including disintegration, cross-cut shredding, incinerating, pulverizing, and melting.
Either an IRS employee or a contractor with IRS approved interim/final staff-like access must be present during the incineration and/or destruction of SBU data. The employee must be present and observe the destruction process.
193
38.0 Exhibit 1 - Legal Requirements¶
39.0 Exhibit 2 - Taxpayer Browsing Protection Act¶
Appendix A: Security Controls¶
All contractors are required to implement Security Controls to ensure the protection of IRS SBU data and information systems, including contracting actions using simplified acquisition procedures. When additional controls are required, these must be defined in the solicitation/contract. If security controls other than what is described here, or in applicable clauses to the contract as the norm or default level is to be used, then that security controls will be identified in the contract.
Table 4: Security Controls Table¶
NIST CONTROL Contractor Cyber Security Privacy
Security Supply Chain
Assessment Risk
Management (C-
SCRM)
| AC-1 Access Control Policy and Procedures |
X |
X |
X |
|---|---|---|---|
AC-2 Account Management |
X |
X |
|
AC-3 Access Enforcement |
X |
X |
X |
AC-4 Information Flow Enforcement |
X |
X |
|
AC-5 Separation of Duties |
X |
X |
|
AC-6 Least Privilege |
X |
||
AC-7 Unsuccessful Login Attempts |
X |
||
AC-8 System Use Notification |
X |
||
AC-11 Device Lock |
X |
||
AC-12 Session Termination |
X |
||
AC-14 Permitted Actions without Identification or Authentication |
X |
||
AC-17 Remote Access |
X |
X |
|
AC-18 Wireless Access |
X |
||
AC-19 Access Control for Mobile Devices |
X |
||
AC-20 Use of External Systems |
X |
X |
|
AC-21 Information Sharing |
X |
X |
|
AC-22 Publicly Accessible Content |
X |
X |
|
AC-22 Data Mining |
X |
||
AT-1 Awareness and Training Policy and Procedure |
X |
X |
|
AT-2 Awareness Training |
X |
X |
|
AT-3 Role Based Training |
X |
X |
|
AT-4 Training Records |
X |
X |
198
| AU-1 Audit and Accountability Policy and Procedures |
X | X | ||
|---|---|---|---|---|
AU-2 Event Logging |
X |
X |
X |
|
AU-3 Content of Audit Records |
X |
X |
X |
|
AU-4 Audit Log Storage Capacity |
X |
|||
AU-5 Response to Audit Logging Processing Failures |
X |
|||
AU-6 Audit Record Review, Analysis, and Reporting |
X |
|||
AU-7 Audit Record Reduction and Report Generation |
X |
|||
AU-8 Time Stamps |
X |
|||
AU-9 Protection of Audit Information |
X |
|||
AU-11 Audit Record Retention |
X |
X |
||
AU-12 Audit Record Generation |
X |
X |
||
AU-13 Monitoring for Information Disclosure |
X |
|||
AU-14 Session Audit |
X |
|||
AU-16 (2) Cross- Organizational Audit **Logging |
Sharing of Audit** Information |
X |
||
CA-1 Assessment, Authorization, and Monitoring Policies and Procedures |
X |
X |
||
CA-2 Control Assessments |
X |
X |
||
CA-3 Information Exchange |
X |
X |
||
CA-5 Plan of Action and Milestones |
X |
X |
||
CA-6 Authorization |
X |
X |
||
CA-7 Continuous Monitoring |
X |
X |
||
CA-8 Penetration Testing |
X |
|||
CA-9 Internal System Connections |
X |
|||
CM-1 Configuration Management Policy and Procedures |
X |
X |
||
CM-2 Baseline Configuration |
X |
X |
||
CM-3 Configuration Change Control |
X |
X |
||
CM-4 Impact Analysis |
X |
X |
||
CM-5 Access Restrictions for Change |
X |
|||
CM-6 Configuration Settings |
X | X |
199
| CM-7 Least Functionality | X | X | ||
|---|---|---|---|---|
CM-8 System Component Inventory |
X |
X |
||
CM-9 Configuration Management Plan |
X |
X |
||
CM-10 Software Usage Restrictions |
X |
|||
CM-11 User-Installed Software |
X |
|||
| CM-12 Information Location |
X |
|||
| CP-1 Contingency Planning Policy and Procedures |
X |
|||
| CP-2 Contingency Plan |
X |
|||
**CP-2 (7) Contingency Plan |
** Coordinate with External Service Providers |
X |
||
CP-3 Contingency Training |
X |
X |
||
CP-4 Contingency Plan Testing |
X |
|||
CP-6 Alternate Storage Site |
X |
|||
CP-7 Alternate Processing Site |
X |
|||
CP-8 Telecommunications Services |
X |
|||
CP-9 System Backup |
X |
|||
CP-10 System Recovery and Reconstitution |
X |
|||
IA-1 Identification and Authentication Policy and Procedures |
X |
|||
IA-2 Identification and Authentication (Organizational Users) |
X |
X |
||
IA-3 Device Identification and Authentication |
X |
|||
IA-4 Identifier Management |
X |
X |
||
IA-5 Authenticator Management |
X |
X |
||
IA-6 Authenticator Feedback |
X |
|||
IA-7 Cryptographic Module Authentication |
X |
|||
IA-8 Identification and Authentication (Non- Organizational Users) |
X |
|||
IA-9 Service Identification and Authentication |
X |
|||
IR-1 Incident Response Policy and Procedures |
X |
X |
X |
|
IR-2 Incident Response Training |
X |
X |
X |
|
IR-3 Incident Response Testing |
X | X |
200
| IR-4 Incident Handling | X | X | ||
|---|---|---|---|---|
IR-4 (10) Incident Handling ** |
Supply Chain** Coordination |
X |
||
IR-5 Incident Monitoring |
X |
X |
||
IR-6 Incident Reporting |
X |
X |
||
**IR-6 (3) Incident Reporting |
** Supply Chain Coordination |
X |
||
IR-7 Incident Response Assistance |
X |
X |
||
IR-7 (2) Incident Response **Assistance |
Coordination** and External Providers |
X |
||
IR-8 Incident Response Plan |
X |
X |
X |
|
| IR-9 Information Spillage Response |
X |
|||
MA-1 Maintenance Policy and Procedures |
X |
X |
||
MA-2 Controlled Maintenance |
X |
|||
MA-3 Maintenance Tools |
X |
|||
MA-4 Non-Local Maintenance |
X |
X |
||
MA-5 Maintenance Personnel |
X |
|||
MA-6 Timely Maintenance |
X |
|||
MP-1 Media Protection Policy and Procedures |
X |
X |
||
MP-2 Media Access |
X |
|||
MP-3 Media Marking |
X |
|||
MP-4 Media Storage |
X |
X |
||
MP-5 Media Transport |
X |
|||
MP-6 Media Sanitization |
X |
X |
X |
|
MP-7 Media Use |
X |
|||
PE-1 Physical and Environmental Protection |
X |
X |
||
PE-2 Physical Access Authorizations |
X |
X |
||
PE-3 Physical Access Control |
X |
|||
PE-4 Access Control for Transmission Medium |
X |
|||
PE-5 Access Control for Output Devices |
X |
|||
PE-6 Monitoring Physical Access |
X |
|||
PE-8 Visitor Access Records |
X |
X |
||
PE-9 Power Equipment and Power Cabling |
X |
|||
PE-10 Emergency Shutoff |
X |
|||
PE-11 Emergency Power |
X |
|||
PE-12 Emergency Lighting |
X |
|||
PE-13 Fire Protection |
X |
201
| PE-14 Environmental Controls |
X | ||
|---|---|---|---|
PE-15 Water Damage Protection |
X |
||
PE-16 Delivery and Removal |
X |
||
PE-17 Alternate Work Site |
X |
||
PE-23 Facility Location |
X |
||
PL-1 Planning Policy and Procedures |
X |
X |
|
PL-2 System Security and Privacy Plans |
X |
X |
X |
PL-4 Rules of Behavior |
X |
X |
|
PL-8 Security and Privacy Architectures |
X |
X |
|
PM-4 Plan of Action and Milestones (POA&M) Process |
X |
||
PM-5 Inventory of Personally Identifiable Information |
X |
X |
X |
PM-9 Risk Management Strategy |
X |
||
PM-18 Privacy Program Plan |
X |
X |
X |
PM-19 Privacy Program Leadership Role |
X |
X |
|
PM-20 Dissemination of Privacy Program Information |
X |
X |
|
PM-21 Accounting of Disclosures |
X |
||
PM-22 Personally Identifiable Information Quality Management |
X |
||
PM-24 Program Management — Data Integrity Board |
X |
||
PM-25 Minimization of PII used in testing, training, research |
X |
X |
|
PM-26 Complaint Management |
X |
X |
|
PM-27 Privacy Reporting |
X |
||
PM-28 Risk Framing |
X |
||
PM-31 Program Management — Continuous Monitoring Strategy |
X |
||
PS-1 Personnel Security Policy and Procedures |
X |
X |
X |
PS-2 Position Categorization |
X |
X |
|
PS-3 Personnel Screening |
X |
X |
|
PS-4 Personnel Termination |
X |
X |
|
PS-5 Personnel Transfer |
X | X |
202
| PS-6 Access Agreements | X | X | X |
|---|---|---|---|
PS-7 External Personnel Security |
X |
||
PS-8 Personnel Sanctions |
X |
||
PT-1 PII Policy and Procedures |
X |
X |
X |
PT-2 Authority to Process PII |
X |
X |
|
PT-3 PII Processing Purposes |
X |
X |
|
PT-04 Consent |
X |
||
PT-5 Privacy Notice |
X |
X |
|
PT-06 System of Records Notice |
X |
||
PT-7 PII - Social Security Numbers |
X |
X |
|
PT-08 Computer Matching Requirements |
X |
||
RA-1 Risk Assessment Policy & Procedures |
X |
X |
|
RA-2 Security Categorization |
X |
||
RA-3 Risk Assessment |
X |
X |
|
| RA-5 Vulnerability Monitoring and Scanning |
X |
X |
|
RA-8 Risk Assessment – Privacy Impact Assessments |
X |
||
RA-9 Criticality Analysis |
X |
||
RA-10 Threat Hunting |
X |
||
SA-1 System and Security Acquisition Policy and Procedures |
X |
X |
|
SA-2 Allocation of Resources |
X |
X |
|
SA-3 System Development Life Cycle (SDLC) |
X |
X |
|
SA-4 Acquisition Process |
X |
X |
|
SA-5 System Documentation |
X |
||
SA-8 Security and Privacy Engineering Principles |
X |
X |
|
SA-9 External System Services |
X |
X |
|
SA-10 Developer Configuration Management |
X |
||
SA-11 Developer Testing and Evaluation |
X |
X |
|
SA-15 Development Process, Standards, and Tools |
X |
||
SA-21 Developer Screening |
X |
||
SA-22 Unsupported System Components |
X |
203
| SC-1 System and Communications Protection Policy and Procedures |
X | |||
|---|---|---|---|---|
SC-2 Separation of System and User Functionality |
X |
|||
SC-4 Information in System Shared Resources |
X |
|||
SC-5 Denial of Service Protection |
X |
|||
SC-7 Boundary Protection |
X |
X |
||
SC-7 (13) Boundary **Protection |
Isolation of** Security Tools, Mechanisms, and Support Components |
X |
||
SC-8 Transmission Confidentiality and Integrity |
X |
X |
||
SC-10 Network Disconnect |
X |
|||
SC-12 Cryptographic Key Establishment and Management |
X |
|||
SC-13 Cryptography Protection |
X |
|||
SC-15 Collaborative Computing Devices and Applications |
X |
|||
SC-17 Public Key Infrastructure Certificates |
X |
|||
SC-18 Mobile Code |
X |
|||
SC-20 Secure Name/ Service (Authoritative Source) |
X |
|||
SC-21 Secure Name/ Service (Recursive or Caching Resolver) |
X |
|||
SC-22 Architecture & Provisioning for Name/ Service |
X |
|||
SC-23 Session Authenticity |
X |
|||
SC-28 Protection of Information at Rest |
X |
X |
||
SC-36 Distributed Processing and Storage |
X |
|||
SC-39 Process Isolation |
X |
|||
SI-1 System and Information Integrity Policy and Procedures |
X |
X |
||
SI-2 Flaw Remediation |
X |
X |
||
SI-3 Malicious Code Protection |
X |
X |
||
SI-4 System Monitoring |
X | X |
204
| SI-5 Security Alerts, Advisories, and Directives |
X | X | |
|---|---|---|---|
SI-7 Software Firmware, and Information Integrity |
X |
X |
|
SI-8 Spam Protection |
X |
||
SI-10 Information Input Validation |
X |
||
SI-11 Error Handling |
X |
||
SI-12 Information Management, Retention, and Information Disposal |
X |
X |
|
SI-16 Memory Protection |
X |
||
SI-18 Personally Identifiable Information Quality Operations |
X |
||
SI-19 De-Identification |
X |
||
SI-20 Tainting |
X |
||
SR-1 Supply Chain Risk Management Policy and Procedures |
X |
||
SR-2 Supply Chain Risk Management Plan |
X |
||
SR-3 Supply Chain Controls and Process |
X |
||
SR-5 Acquisition Strategies, Tools, and Methods |
X |
||
SR-6 Supplier Assessments and Reviews |
X |
||
SR-8 Notification Agreements |
X |
||
SR-10 Inspection of Systems or Components |
X |
X |
|
SR-11 Component Authenticity |
X |
||
SR-12 Component Disposal |
X |
205
Appendix B: Acronyms¶
| Acronym | Acronym Description |
|---|---|
| AC |
Access Control |
| AIFIS |
Automated Integrated Fingerprint Identification System |
| AGI |
Adjusted Gross Income |
| AI |
Artificial Intelligence |
| ASLR |
Address Space Layout Randomization |
| AT |
Awareness Training |
| AU |
Audit and Accountability |
| BMC |
Baseboard Management Controller |
| BOD |
Business Operating Division |
| BYOD |
Bring Your Own Device |
| CA |
Certificate Authority |
| CCB |
Change Control Board |
| CD |
Compact Disc |
| CD-R |
Compact Disc Recordable |
| CD-ROM |
Compact Disc - Read Only Memory |
| CD-RW |
Compact Disc - Rewritable |
| CISA |
Cybersecurity and Infrastructure Security Agency |
| CM |
Configuration Management |
| CMA |
Computer Matching Agreement |
| CMVP |
Cryptographic Module Validation Program |
| CO |
Contracting Officer |
| CONUS |
Continental United States |
| COR |
Contracting Officer’s Representative |
| COTS |
Commercial Off the Shelf Software |
| CP |
Contingency Planning |
| CSA |
Contractor Security Assessment |
| CSCA |
Contractor Security Controls Assessment |
| C-SCRM |
Cyber-Supply Chain Risk Management |
| CSIRC |
Computer Security Incident Response Center |
| CSO |
Cloud Service Offering |
| CSP |
Cloud Service Provider |
| CVE |
Common Vulnerabilities and Exposures |
| CWE |
Common Weakness Enumeration |
| DAST |
Dynamic Application Security Testing |
| DDoS |
Distributed Denial-of-Service |
| DEP | Data Execution Prevention |
| DLN | Document Locator Number |
|---|---|
| DNSSEC |
Domain Name System Security Extensions |
| DOB |
Date of Birth |
| DVD |
Digital Video Device |
| EIN |
Employer Identification Number |
| FAR |
Federal Acquisition Regulation |
| FDE |
Full-Disk Encryption |
| FIPS |
Federal Information Processing Standard |
| FISMA |
Federal Information Security Modernization Act 2002. Amended 2014 |
| FMSS |
Facilities Management and Security Services |
| FOIA |
Freedom of Information Act |
| FTC |
Federal Trade Commission |
| FTI |
Federal Tax Information |
| FTP |
File Transfer Protocol |
| GIS |
Geographic Information System |
| GLB |
Gramm-Leach Bliley |
| GMT |
Greenwich Mean Time |
| GPS |
Global Positioning System |
| GRS |
General Records Schedules |
| GSA |
General Services Administration |
| HDD |
Hard Disk Drive |
| HIDS |
Host-Based Intrusion Detection System |
| HSPD-12 |
Homeland Security Presidential Directive-12 |
| HR |
Human Resources |
| IA |
Identification & Authentication |
| IaaS |
Infrastructure as a Service |
| IDS |
Intrusion Detection Systems |
| IP |
Internet Protocol |
| ICT |
Information, Communication, and Technology |
| IR |
Incident Response |
| IRC |
Internal Revenue Code |
| IRM |
Internal Revenue Manual |
| IRS |
Internal Revenue Service |
| ISA |
Information Sharing Agreement |
| IT |
Information Technology |
| ITIN |
Individual Taxpayer Identification Number |
| ITM |
Integrated Talent Management |
| KEV | Known Exploited Vulnerabilities |
| LAN | Local Area Network |
|---|---|
| LES |
Law Enforcement Sensitive |
| LLM |
Large Language Model |
| LPR |
Lawful Permanent Resident |
| MA |
Maintenance |
| MAC |
Media Access Control |
| MDM |
Mobile Device Manager |
| MEF |
Mission Essential Function |
| MFA |
Multifactor Authentication |
| ML |
Machine Learning |
| MP |
Media Protection |
| MSP |
Managed Service Providers |
| MSSP |
Managed Security Service Providers |
| NAID |
National Association for Information Destruction |
| NARA |
National Archives and Records Administration |
| NAT |
Network Address Translation |
| NDA |
Non-Disclosure Agreement |
| NDP |
Neighbor Discovery Protocol |
| NEC |
National Electrical Code |
| NFPA |
National Fire Protection Association |
| NIDS |
Network-Based Intrusion Detection System |
| NIST |
National Institute of Standards and Technology |
| NVD |
National Vulnerability Database |
| OEP |
Occupant Emergency Plan |
| OMB |
Office of Management & Budget |
| PaaS |
Platform as a Service |
| PCLIA |
Privacy and Civil Liberties Impact Assessment |
| PDT |
Position Designation Tool |
| PE |
Physical & Environmental Protection |
| PED |
Personal Electronic Device |
| PCLTA |
Privacy & Civil Liberties Threshold Assessment |
| PHI |
Protected Health Information |
| PKI |
Public Key Infrastructure |
| PIAMS |
Privacy Impact Assessment Management System |
| PII |
Personally Identifiable Information |
| PIN | Personal Identification Number |
208
| PIPD | Privacy, Information Protection, & Disclosure |
|---|---|
| PIV |
Personal Identity Verification |
| PL |
Planning |
| PM | Program Management |
| POA&M |
Plan of Actions and Milestones |
| POC |
Point of Contact |
| PS |
Personnel Security |
| RA |
Risk Assessment |
| RAC |
Risk Assessment Checklist |
| RAFT |
Risk Acceptance Form & Tool |
| RCS |
Records Control Schedules |
| RIM | Records and Information Management |
| ROM | Read Only Memory |
| RPA |
Robotic Process Automation |
| RPO | Recovery Point Objective |
| RTO | Recover Time Objective |
| SA | System and Services Acquisition |
| SaaS | Software as a Service |
| SAR | Security and Privacy Control Assessment Report |
| SA&A | Security Assessment & Authorization |
| SAMC | Situational Awareness Management Center |
| SAST | Static Application Security Testing |
| SBOM |
Software Bill of Materials |
| SBU |
Sensitive But Unclassified |
| SC | System and Communication Protection |
| SCAP |
Security Content Automation Protocol |
| SDLC |
System Development Lifecycle |
| SI |
System and Information Integrity |
| SIEM |
Security Information and Event Management |
| SITS |
Specialized IT Security Training |
| SLA |
Service-Level Agreement |
| SLAAC |
Stateless Address Autoconfiguration |
| SOFT |
Software Application Development or Maintenance |
| SORN |
Service-Level Agreements |
| SP | Special Publication |
| SQL | Structured Query Language |
| SR | Supply Chain Risk Management |
| SSD | Solid-state Drive |
209
| SSP | System Security Plan |
|---|---|
| TCP | Transmission Control Protocol |
| TIN | Taxpayer Identification Number |
| TLS | Transport Layer Security |
| TPM | Trusted Platform Module |
| UNAX | Unauthorized Access |
| USB |
Universal Serial Bus |
| USC |
United States Code |
| USGCB | United States Government Configuration Baseline |
| UTC |
Coordinated Universal Time |
| UUID | Universally Unique Identifier |
| VDI | Virtual Desktop Infrastructure |
| VDR |
Vulnerability Disclosure Report |
| VoIP | Voice over Internet Protocol |
| VPN |
Virtual Private Network |
| VSS | Video Surveillance Systems |
| WAF |
Web Application Firewalls |
| WAN |
Wide Area Networks |
| XSS |
Cross-site Scripting |
| ZT |
Zero Trust |
| ZTNA | Zero Trust Network Access |
210
Appendix C: Glossary¶
Access Control: The process of granting, restricting, monitoring, and revoking logical and physical access to information systems, applications, cloud services, APIs, facilities, and IRS Sensitive But Unclassified (SBU) data based on identity, authorization, business need, and least privilege.
Account Manager: The individual or process responsible for requesting, approving, provisioning, modifying, reviewing, disabling, and removing user, privileged, service, application, cloud, and API accounts while maintaining accountability for assigned access privileges.
Accountability: A process of holding users responsible for actions performed on an information system.
Adequate Security: Security commensurate with the risk and magnitude of harm resulting from the loss, misuse, unauthorized access to, or modification of information.
Artificial Intelligence (AI): A machine-based capability that performs functions associated with human intelligence, such as learning, reasoning, perception, language understanding, prediction, decision-making, or content generation. AI systems may include machine learning models, generative AI, large language models, expert systems, or other technologies used to automate or augment human tasks.
AI Model: A computational model trained or configured to perform a specific task, such as prediction, classification, recommendation, reasoning, or content generation, using algorithms, statistical methods, or machine learning techniques.
AI-Enabled Capability: A software application, service, or system that incorporates Artificial Intelligence (AI) or machine learning functionality to perform or assist with tasks such as decision support, content generation, data analysis, prediction, automation, or user interaction. AI-enabled capabilities may include embedded AI features within commercial software, cloud services, applications, or business processes supporting the IRS contract.
Alternate Work Site: A designated location, other than the primary work site, from which authorized personnel can securely perform assigned duties during planned or unplanned disruptions.
Application Programming Interface (API): A defined set of rules, protocols, and interfaces that enables software applications or services to communicate, exchange data, and invoke functionality securely
Application Security Testing: The process of evaluating software applications to identify security vulnerabilities, insecure coding practices, configuration weaknesses, and other conditions that could adversely affect confidentiality, integrity, or availability of information.
211
Audit: An independent examination of security controls associated with a representative subset of contractor IT assets to determine the operating effectiveness of information system controls; ensure compliance with established policy and operational procedures; and recommend changes in controls, policy, or procedures where needed.
Audit Trail: A chronological record of system activities, security events, and user actions that enables the reconstruction, review, analysis, and investigation of transactions, system operations, security incidents, and administrative activities. Audit trails may include operating system logs, application logs, database logs, cloud service logs, API logs, authentication records, and other security-relevant events.
Authentication: The process of verifying the identity of a user, device, application, service, or process before granting access to information systems or resources. Authentication may use one or more authentication factors, including passwords, cryptographic tokens, digital certificates, passkeys, biometrics, or other approved authentication mechanisms
Authenticator: The means used to confirm the identity of a user, processor, or device (e.g., user password or token).
Authorization: Access privileges granted to a user, program, or process.
Availability: Timely, reliable access to information and information services for authorized users.
Banner: Display of an information system outlining the parameters for information system or information use.
Baseline Security Requirements: A description of the minimum-security requirements necessary for an information system to enforce the security policy and maintain an acceptable risk level.
Breach: The loss of control, compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or any similar occurrence where (1) a person other than an authorized user accesses or potentially accesses personally identifiable information or (2) a person accesses or potentially accesses personally identifiable information for an unauthorized purpose (i.e., a purpose unrelated to their official duties/functions).
Classified Information: National security information classified pursuant to Executive Order 12958.
Cloud Service Provider: An organization that delivers cloud computing services and capabilities, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), serverless computing, storage, networking, artificial intelligence services, managed services, and other cloud-based technologies.
Cloud-Native Application: An application designed and developed to operate within cloud computing environments using technologies such as containers, microservices, orchestration platforms, serverless computing, and automated deployment pipelines.
212
Compromise: The disclosure of sensitive information to persons not authorized to receive such information.
Confidentiality: Preserving authorized restrictions on information access and disclosure.
Configuration Management: A disciplined process for establishing, documenting, implementing, maintaining, and controlling the configuration of information systems throughout their lifecycle. Configuration management includes hardware, software, firmware, operating systems, cloud resources, Infrastructure as Code (IaC), containers, virtual machines, applications, security configurations, documentation, and related system components.
Continuous Monitoring: A risk-based process of maintaining ongoing awareness of the security, privacy, and operational posture of information systems through the continuous or periodic assessment of security and privacy controls, vulnerabilities, configuration changes, threats, and other risk indicators.
Contingency Plan: A documented plan that establishes the strategies, procedures, roles, responsibilities, and resources necessary to respond to and recover from disruptions affecting information systems and business operations.
Contracting Officer: means an individual, designated, and authorized responsible for managing contracts/acquisitions and overseeing their implementation.
Contracting Officer’s Representative: As defined in FAR Part 2, the COR means an individual, designated, and authorized in writing by the CO to perform specific technical or administrative functions.
Contractor Security Assessments: Contractor Security Assessments are evaluations performed by the IRS to assess and validate the effectiveness of security & privacy controls established to protect IRS SBU and information systems that support the IRS contract.
COTS: Commercial off the shelf.
Counter Measures: Actions, devices, procedures, mechanisms, techniques, or other measures that reduce the vulnerability of an information system.
Cryptography: The science and practice of protecting information through encryption, decryption, hashing, digital signatures, key management, and related cryptographic techniques that support confidentiality, integrity, authentication, and non-repudiation of information.
CSIRC: Computer Security Incident Response Center.
Data: A representation of facts, concepts, information, or instruction suitable for communication, processing, or interpretation by people or information systems.
Data At Rest : Information that is stored on physical or virtual media and is not actively being transmitted or processed. Data at rest includes information stored on servers, workstations,
213
laptops, mobile devices, databases, storage arrays, backup media, removable media, virtual machines, cloud storage services, snapshots, and other storage technologies that contain IRS Sensitive But Unclassified (SBU) data.
Data Loss Prevention (DLP): A combination of policies, processes, and technologies used to detect, monitor, and prevent unauthorized access, disclosure, transmission, modification, or removal of sensitive information. DLP capabilities help protect IRS Sensitive But Unclassified (SBU) data by monitoring data at rest, in transit, and in use across endpoints, networks, cloud services, email systems, applications, and collaboration platforms.
Disaster Recovery Plan : A documented plan that defines the procedures, resources, roles, and responsibilities required to restore information systems, applications, infrastructure, and data following a disruption or disaster
Decryption: The process of converting encrypted information into a readable form. This is also called deciphering.
De-militarized Zone: A physically or logically segmented network that separates an organization's internal network from external or untrusted networks, such as the Internet. A DMZ hosts publicly accessible systems and services while limiting direct access to internal information systems.
Denial of Service: An attempt to impair or prevent authorized access to an information system, network, application, or service by exhausting or disrupting the availability of system resources, network bandwidth, processing capacity, or other critical services.
DevSecOps: A software development approach that integrates security, privacy, and compliance activities into all phases of the software development lifecycle through automated processes, continuous integration, continuous delivery, and continuous monitoring.
Digital Certificate: A digital representation of information used in conjunction with a public key encryption system, which at a minimum: 1) Identifies the certification authority issuing it; 2) Names or identifies its subscriber; 3) Contains the subscriber’s public key; 4) Identifies its operational period. 5) Is digitally signed by the certification authority issuing it.
Digital Storage Media: Any portable or fixed electronic device capable of storing, transporting, or transferring digital information in large quantities.
Disclosure: The making known to any person in any manner whatever a return or return information. See IRC 26 U.S.C. § 6103(b)(8) for the statutory definition of disclosure.
Discretionary Access Control: A method of restricting logical access to information system objects (e.g., files, directories, devices, permissions, rules) based on the identity and need to know of users, groups, or processes.
Domain Name System: A hierarchical naming system that translates domain names into Internet Protocol (IP) addresses and supports network communications through authoritative name servers, recursive resolvers, DNS resource records, DNS Security Extensions
214
(DNSSEC), cryptographic keys, and other components necessary for secure name resolution. A hierarchical naming system that retains artifacts related to the lookup, including cryptographic keys, DNS resource records, etc.
Encryption: The process of transforming plaintext into ciphertext using FIPS-approved cryptographic algorithms and key management techniques to protect information from unauthorized access while supporting the confidentiality and integrity of information..
Encryption Algorithm: A formula used to convert information into an unreadable format.
Endpoint Detection and Response (EDR): A security capability that continuously monitors endpoint devices to detect, investigate, contain, and respond to malicious activity and other cybersecurity events.
External Information System: An information system, service, application, cloud environment, Software as a Service (SaaS) offering, managed service, or system component that resides outside the contractor's authorization boundary and over which the contractor does not have direct authority to implement or assess required security controls. External Network: Any network residing outside the security perimeter established by the telecommunications information system.
Federal Tax Information: Any return or return information received from the IRS or secondary source, such as SSA etc. FTI includes any information created by the recipient that is derived from return or return information. (Internal Revenue Code (IRC) § 6103, confidentiality and disclosure of returns and return information).
File Integrity Monitoring: A security capability that detects unauthorized or unexpected changes to files, software, firmware, operating systems, security configurations, and other critical system components.
File Permissions: A method of implementing discretionary access control by establishing and enforcing rules to restrict logical access of information system resources to authorized users and processes.
File Server: A physical, virtual, or cloud-based system that provides centralized storage, management, protection, and controlled access to files and directories for authorized users, applications, and information systems over a network.
Firewall: A hardware appliance, software application, virtual appliance, host-based firewall, cloud-native firewall, or managed security service that monitors, filters, and controls inbound and outbound network traffic based on defined security policies and rules.
Firmware: Low-level software embedded within hardware devices that controls system initialization, hardware functionality, and device operations. Firmware includes software embedded in BIOS, UEFI, network devices, storage devices, embedded controllers, and other computing components.
FMSS: Facilities Management and Security Services
215
General Support System: An interconnected set of information resources under the same direct management control that shares common functionality. It normally includes hardware, software, information, data, applications, communications, and people.
HOST: An information system dedicated to providing services to many users. Examples of such information systems include mainframes, mini-information systems or servers providing Dynamic Host Configuration Protocol (DHCP) services.
Infrastructure as Code (IAC) : The practice of provisioning, configuring, and managing infrastructure through machine-readable configuration files or code rather than manual processes.
Identification: A mechanism used to request access to information system resources by providing a recognizable unique form of identification such as a login-id, user-id, or token. Also, see Authentication.
Incident: An Incident is an event that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information it processes, stores, or transmits, or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
Incident Response Plan: The documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of malicious cyber-attacks against an organization’s systems.
Interconnection Security Agreement: An agreement established between organizations that own and operate connected IT systems to document the technical requirements of the interconnection.
Information System Security: The protection of information systems and information against unauthorized access, use modification or disclosure – ensuring, privacy, confidentiality, integrity and availability of information systems and information.
Integrity: Protection of information systems and information from unauthorized modification; ensuring quality, accuracy, completeness, non-repudiation, and authenticity of information.
Intranet: An Intranet is a private, internal network that uses Internet technologies and protocols to provide authorized users within an organization with secure access to information, applications, services, and communication resources.
Key: Information used to establish and periodically change the operations performed in cryptographic devices for the purpose of encrypting and decrypting information.
Large Language Model (LLM) : A type of Artificial Intelligence (AI) model trained on large volumes of text and other data to understand, generate, summarize, translate, or otherwise process natural language. Large Language Models may be used to support conversational
216
interfaces, content generation, code generation, document analysis, and other language-based tasks.
Least Privilege: A security principle stating users or processes are assigned the most restrictive set of privileges necessary to perform routine job responsibilities.
Malicious Code: Software, scripts, macros, executable content, or other code intentionally designed to compromise confidentiality, integrity, or availability of information systems or information. Malicious code includes viruses, worms, ransomware, Trojan horses, spyware, rootkits, malicious scripts, cryptominers, and other forms of malware.
Malware: Software or executable content intentionally designed to disrupt operations, gain unauthorized access, disclose sensitive information, or otherwise compromise the confidentiality, integrity, or availability of information systems or information. Malware includes viruses, worms, ransomware, Trojan horses, spyware, rootkits, malicious scripts, cryptominers, and other malicious software.
Managed Detection and Response (MDR): A managed security service that provides continuous monitoring, threat detection, investigation, and incident response capabilities using security analysts and advanced detection technologies.
Media: Physical or electronic devices used to store, process, transmit, or archive information. Media includes paper records, storage devices, hard disk drives, solid-state drives, removable media, backup media, virtual disks, cloud storage, object storage, snapshots, mobile devices, and other technologies capable of storing information.
Memorandum of Understanding (MOU)/Memorandum of Agreement (MOA ) : A document established between two or more parties to define their respective responsibilities in accomplishing a particular goal or mission. In this guide, an MOU/MOA defines the responsibilities of two or more organizations in establishing, operating, and securing a system interconnection.
Mobile Code: Software or executable content transmitted from a remote system and executed on a local information system without permanent installation. Examples include scripts, browser extensions, JavaScript, Java applets, PowerShell scripts, Python scripts, HTML5 components, ActiveX controls, and other downloadable executable content.
Multi-factor Authentication: An authentication method that requires a user to successfully present two or more authentication factors from different categories to verify their identity before access is granted to an information system, application, or service.
Multi-Cloud: An information technology environment that uses cloud services from two or more Cloud Service Providers (CSPs) to host, process, store, or manage applications, data, or infrastructure. Multi-cloud environments may be implemented to improve resiliency, availability, performance, or to satisfy operational or regulatory requirements.
217
Network: A collection of interconnected information systems, devices, applications, and communication resources that exchange data and share services using wired, wireless, or virtual communication technologies and standard network protocols.
NIST: National Institute of Standards and Technology
Non-Repudiation: The ability to provide evidence that an action, event, or transaction occurred and to prevent an individual or entity from successfully denying having performed that action.
Object Reuse: The practice of ensuring that information contained in a storage object, memory location, file, buffer, or other reusable system resource is not inadvertently disclosed to unauthorized users or processes when the object is reallocated or reused.
Object Storage: A storage architecture that manages data as discrete objects rather than files or blocks. Object storage is commonly used by cloud service providers to store unstructured data, backups, archives, logs, and other large datasets.
Open-Source Software (OSS): Software whose source code is made available under a license that permits its use, modification, and distribution. Open-source software may include operating systems, applications, libraries, frameworks, containers, and development tools and should be managed in accordance with the Contractor's secure software development, vulnerability management, and supply chain risk management processes.
Password: A memorized secret composed of a string of characters that is used to authenticate the identity of a user or process before granting access to an information system, application, service, or device. Passwords may be used alone or in combination with one or more additional authentication factors as part of multi-factor authentication (MFA).
Penetration Testing: A controlled security assessment that simulates real-world attack techniques to identify and exploit vulnerabilities in an information system, application, network, or cloud environment.
Personally Identifiable Information: Per OMB Circular A-130: “Personally identifiable information means information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual”.
Because there are many different types of information that can be used to distinguish or trace an individual’s identity, the term PII is necessarily broad. To determine whether information is PII, the agency (in this case, the contractor on behalf of the IRS) shall perform an assessment of the specific risk that an individual can be identified using the information with other information that is linked or linkable to the individual. In performing this assessment, it is important to recognize that information that is not PII can become PII whenever additional information becomes available – in any medium and from any source – that would make it possible to identify an individual. Circular A-130, page 33:
218
https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf
Plan of Actions and Milestones: A formal management document used to identify, prioritize, track, and remediate known security and privacy weaknesses affecting an information system.
Potential Impact: The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect, a serious adverse effect, or a catastrophic adverse effect on contractor operations, contractor assets, or individuals.
Prompt Injection: A technique used to manipulate an Artificial Intelligence (AI) system by providing crafted inputs intended to alter the model's behavior, bypass security controls, disclose sensitive information, or generate unauthorized outputs
Privileged Access Management (PAM): A combination of policies, processes, and technologies used to control, monitor, and audit privileged accounts and administrative access to information systems. PAM capabilities help enforce least privilege, protect privileged credentials, manage privileged sessions, and provide accountability for administrative activities performed on information systems.
Protocol: A set of rules and standards governing the communication process between two or more network entities.
Privacy and Civil Liberties Impact Assessment: Is an analysis conducted to identify, assess, and mitigate privacy and civil liberties risks associated with the collection, use, maintenance, sharing, transmission, or disposal of personally identifiable information (PII) by an information system, program, technology, or business process. The assessment ensures that privacy and civil liberties protections are incorporated throughout the system lifecycle and that the system complies with applicable Federal laws, regulations, policies, and IRS requirements.
Privileged Account: An account with elevated privileges.
Privacy &Civil Liberties Threshold Assessment: An initial screening process used to determine whether an information system, technology, program, or business process collects, maintains, uses, shares, or disposes of personally identifiable information (PII), and whether additional privacy compliance activities, such as a Privacy and Civil Liberties Impact Assessment (PCLIA), are required.
Public Key Infrastructure: A framework consisting of hardware, software, policies, procedures, personnel, and cryptographic services used to create, manage, distribute, validate, store, revoke, and protect digital certificates and public/private cryptographic key pairs.
Recovery Point Objective: The maximum acceptable amount of data loss, measured in time, that an organization can tolerate following a disruption before the restoration of data from backups or other recovery mechanisms. The established RPO shall be equal to or less than the effective backup interval, based on the frequency of full, incremental, differential, or other approved backup mechanisms used to support data recovery.
219
Recovery Time Objective: the maximum acceptable period of time that an information system, service, or business process may remain unavailable following a disruption before unacceptable operational impacts occur.
Remnants: Residual information remaining on storage media after reallocation or reassignment of such storage media to different contractors, organizational elements, users, or processes. See Object Reuse.
Remote Maintenance: Maintenance activities conducted by individuals communicating external to a system security perimeter.
Removable Media: Portable storage devices that can be connected to and removed from an information system to store or transfer digital information. Examples include encrypted USB flash drives, external hard drives, solid-state drives, memory cards, optical media, and other portable storage devices.
Residual Risk: Portions of risk remaining after security controls or countermeasures are applied.
Returns and Return Information: Any information defined by IRC, 26 U.S.C. § 6103(b). Tax information from IRS business processes come under many names, such as FTI, IRC § 6103-protected information, taxpayer data, taxpayer information, tax return information, return information, case information, SBU data, and PII. See FTI.
Risk: The potential adverse impact to the operation of information systems affected by threat occurrences on contractor operations, assets, and people.
Risk Assessment: The process of identifying threats, vulnerabilities, likelihood, potential impacts, and existing safeguards affecting information systems, information, business operations, individuals, supply chains, cloud environments, and other organizational assets to determine and prioritize risk.
Risk Level: The security impact risk level is the low, moderate, or high impact level assigned to an information system in accordance with FIPS 199 and FIPS 200 based on the types of information processed, stored and/or transmitted by the information system.
Risk Management: The routine process of identifying, analyzing, isolating, controlling, and minimizing security risk to achieve and maintain an acceptable risk level. A risk assessment is an instrumental component of the risk management life cycle.
Safeguards: Protective measures prescribed to enforce the security requirements specified for an information system. This is synonymous with security controls and countermeasures.
Sanitization: Process to remove information from media such that information recovery is not possible. It includes removing all labels, markings, and activity logs.
SCADA: Supervisory Control and Data Acquisition.
220
Security Content Automation Protocol: A method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation against a standardized set of security requirements.
Security Information and Event Management: A tool/application that provides the ability to gather security data from system components and present that data as actionable information via a single interface.
Security Policy: The set of laws, rules, directives, and practices governing how contractors protect information systems and information.
Security Requirement: The description of a specification necessary to enforce the security policy. See Baseline Security Requirements.
Secure Software Development Framework (SSDF): A risk-based framework published by the National Institute of Standards and Technology (NIST SP 800-218) that defines recommended practices for integrating security into software development throughout the software development lifecycle.
Sensitive But Unclassified: Any information, the loss, misuse, or unauthorized access to or modification of which could adversely affect the national interest or the conduct of Federal programs, or the privacy to which individuals are entitled under Section 552a of Title 5, United States Code (the Privacy Act of 1974), but which has not been specifically authorized under criteria established by an Executive Order or Congress to be kept secret in the interest or national defense for foreign policy.
Serverless Computing: A cloud computing model in which the cloud service provider automatically provisions, manages, and scales computing resources, allowing applications to execute without requiring customers to manage the underlying infrastructure.
Service Level Agreement: Defines the specific responsibilities of the service provider and sets the customer expectations.
Security Information and Event Management (SIEM): A security capability that collects, normalizes, correlates, analyzes, and stores security-relevant event data from information systems, cloud services, applications, networks, endpoints, and security technologies to support threat detection, investigation, incident response, compliance, and continuous monitoring.
Significant Change: A modification to an information system, operating environment, architecture, software, hardware, cloud environment, security controls, privacy controls, system functionality, or business processes that may materially affect the security, privacy, or risk posture of the system and requires analysis to determine whether reassessment or reauthorization activities are necessary
221
Security Orchestration, Automation, and Response (SOAR): A security platform that integrates security tools and automates workflows to support incident detection, investigation, response, and remediation.
Software Bill of Materials (SBOM): A formal inventory that identifies the components, libraries, dependencies, and other software elements contained within an application or software product.
Software Composition Analysis (SCA): An automated process for identifying and evaluating open-source software, third-party libraries, software dependencies, and known vulnerabilities within software applications.
Staff-Like Access: Staff-Like Access is the authority granted to perform one or more of the following:
Enter IRS facilities or space (owned or leased) unescorted (when properly badged),
Possess login credentials to information systems (IRS or vendor-owned systems that store, collect, and/or process IRS information),
• Possess physical and/or logical access to (including the opportunity to see, read,
transcribe, and/or interpret) Sensitive but Unclassified (SBU) data, wherever the
location,
• Possess physical access to (including the opportunity to see, read, transcribe, and/or
interpret) security items and products (e.g., items that must be stored in a locked
container, security container, or a secure room, wherever the location. These items
include, but are not limited to security devices/records, computer equipment,
Identification media, and
- Enter physical areas, wherever the location, that store/process SBU data (unescorted).
Staff-Like Access is granted to an individual who is not an IRS employee (and includes, but is not limited to: contractors/subcontractors, whether procured by IRS or another federal agency, vendors, courier and printing services, outside experts, consultants, paid/unpaid interns, sign language interpreters, document recovery services, other federal employees, delivery services, cleaning/maintenance employees, etc.), and is approved upon required completion of a favorable suitability/fitness determination conducted by IRS PS.
Suitability: A person’s identifiable character traits and conduct sufficient to decide whether an individual’s employment or continued employment would or would not protect the integrity or promote the efficiency of the service.
System Development Life Cycle: A structured process for planning, designing, acquiring, developing, testing, implementing, operating, maintaining, modifying, and retiring information systems while integrating security, privacy, and supply chain risk management throughout the system lifecycle. Modern SDLC methodologies may include Agile, DevSecOps, Continuous Integration/Continuous Delivery (CI/CD), and other iterative development practices.
222
System Security Plan: An official document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.
Threat: Any circumstance, event, actor, or activity with the potential to exploit vulnerabilities and adversely affect the confidentiality, integrity, availability, authenticity, or privacy of information, information systems, business operations, individuals, or organizational assets. Threats may originate from malicious actors, insider activity, nation-state adversaries, supply chain compromises, natural disasters, environmental hazards, equipment failures, or human error.
Threat Hunting: A proactive cybersecurity activity that involves systematically searching information systems, networks, cloud environments, endpoints, and security telemetry for indicators of compromise, malicious activity, or threats that have evaded existing security controls. Threat hunting uses intelligence, analytics, and hypothesis-driven investigation techniques to identify, contain, and remediate potential threats before they result in a security incident.
User: A person or process authorized to access an information system.
User Identifier: A unique string of characters used by an information system to identify a user or process for authentication.
Vendor Point of Contact: The POC is the contractor’s primary point of contact for the Government on all security-related matters and the person responsible for ensuring the security of information and information systems in accordance with the terms and conditions of the contract and all applicable security controls.
Virtual Machine (VM) : A software-based emulation of a physical computer that provides an isolated operating environment capable of running operating systems and applications independently of the underlying hardware.
Virtual Private Network: A virtual network, built on top of existing physical networks that provide a secure communications tunnel for data and other information transmitted between networks.
Vulnerability: A weakness or deficiency in hardware, software, firmware, cloud services, applications, configurations, processes, personnel, or security controls that could be exploited by a threat to adversely affect confidentiality, integrity, availability, or privacy of information or information systems.
Vulnerability Assessment: An automated assessment that identifies known vulnerabilities, missing patches, insecure configurations, or other security weaknesses within information systems, networks, cloud environments, applications, containers, databases, APIs, operating systems, and other technology assets. Vulnerability scanning is typically less intrusive than penetration testing and supports ongoing vulnerability management and risk assessment.
223
Vulnerability Scan: A scan of the network environment, less invasive than a penetration test that can be used to identify information system vulnerabilities to a contractor’s management.
Web Application Firewall (WAF) : A security technology that monitors, filters, and blocks malicious HTTP and HTTPS traffic to and from web applications to protect against application-layer attacks such as SQL injection, cross-site scripting (XSS), and other webbased threats.
Whitelist: A list of hosts or applications that are known to be benign and are approved for use within an organization and/or system.
Zero Trust Architecture (ZTA) : A cybersecurity architecture based on the principle of never implicitly trusting any user, device, application, or network connection. Access is continuously verified using identity, device health, context, and risk before authorization is granted.
Zero Trust Network Access (ZTNA) : A secure remote access technology that provides application-specific access based on continuous verification of user identity, device posture, and organizational policy rather than network location .
224
Appendix D: Reference¶
CIRCULAR NO. A-108 Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act https://www.whitehouse.gov/wp- content/uploads/legacy_drupal_files/omb/circulars/A108/omb_circular_a-108.pdf
CIRCULAR NO. A-130 Managing Information as a Strategic Resource https://www.whitehouse.gov/wpcontent/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf Computer Security Act of 1987 http://csrc.nist.gov/groups/SMA/ispab/documents/csa_87.txt
Federal Acquisition Regulation Part 2, refer to: http://www.gpo.gov/fdsys/pkg/CFR-2011-title48-vol1/pdf/CFR-2011-title48-vol1-sec2- 101.pdf
Federal Acquisition Regulation Subpart 24.3—Privacy Training https://www.acquisition.gov/far/subpart-24.3
Federal Information Security Management Act, refer to: http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf
Federal Information Processing Standards 140-3, Security Requirements for Cryptographic Modules, refer to: https://doi.org/10.6028/NIST.FIPS.140-3
Federal Information Processing Standards 199, Standards for Security Categorization of Federal Information, and Information Systems, refer to: http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
Federal Information Processing Standards 200, Minimum Security Requirements for Federal and Information Systems, refer to: http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf
Federal Trade Commission Financial Privacy Rule and Safeguards Rule, refer to: http://www.gpo.gov/fdsys/pkg/FR-2000-03-01/pdf/00-4881.pdf
Gramm-Leach Bliley Act, refer to: http://www.gpo.gov/fdsys/pkg/PLAW-106publ102/pdf/PLAW-106publ102.pdf
Internal Revenue Code Section 26 U.S.C. § 6103, refer to: https://www.govinfo.gov/content/pkg/USCODE-2011-title26/html/USCODE-2011-title26- subtitleF-chap61-subchapB-sec6103.htm
Internal Revenue Code Section 26 U.S.C. § 7213, refer to: 26 U.S.C. 7213 - Unauthorized disclosure of information - Content Details - USCODE-2005- title26-chap75-subchapA-partI-sec7213
225
Internal Revenue Code Section 26 U.S.C. § 7213A, refer to: https://www.govinfo.gov/content/pkg/USCODE-2021-title26/html/USCODE-2021-title26- subtitleF-chap75-subchapA-partI-sec7213A.htm
Internal Revenue Code Section 26 U.S.C. § 7431, refer to: https://www.govinfo.gov/app/details/USCODE-2023-title26/USCODE-2023-title26-subtitleF- chap76-subchapB-sec7431?
Internal Revenue Manuals 1.15, Records, and Information Management series https://www.irs.gov/irm/part1/irm_01-015-001
OMB M-23-22: Delivering a Digital-First Public Experience https://www.whitehouse.gov/wp-content/uploads/2023/09/M-23-22-Delivering-a-Digital- First-Public-Experience.pdf?utm_source=chatgpt.com
OMB M–17–12 – Preparing for and Responding to a Breach of Personally Identifiable Information https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2017/m-17- 12_0.pdf
National Institute of Standards and Technology Special Publication 800-18 Revision 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems., refer to: https://doi.org/10.6028/NIST.SP.800-18r2
National Institute of Standards and Technology Special Publication 800-53 Rev. 5, Recommended Security and Privacy Controls for Federal Information Systems and Organizations, refer to NIST Special Publication (SP) 800- 53 Rev. 5, Security and Privacy Controls for Federal Information Systems and Organizations
National Institute of Standards and Technology Special Publication 800-88r2, Guidelines for Media Sanitization, refer to: SP 800-88 Rev. 2, Guidelines for Media Sanitization | CSRC
Office of Management and Budget Memorandum 07-16 https://whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2007/m07- 16.pdf
Office of Management and Budget Memorandum 08-23: https://www.whitehouse.gov/wp- content/uploads/legacy_drupal_files/omb/memoranda/2008/m08-23.pdf
Office of Management & Budget OMB Circular A-130 – Management of Federal Information Resources, refer to https://www.whitehouse.gov/wp- content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf
Privacy Act of 1974, refer to:
226
https://www.dodig.mil/Portals/48/Documents/Programs/Privacy%20Program/pa1974.pdf?utm_so urce=chatgpt.com
Sarbanes-Oxley Act, refer to: http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/pdf/PLAW-107publ204.pdf
227