1528 Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 

1The other criteria do not directly impact the 

development of the security requirements but are 

related to DOJ’s implementation of the Order’s 

directive via their regulations. See E.O. 14117, sec. 

2(a)(iii)—(v), 89 FR 15421, 15423 (Mar. 1, 2024). 

2Section 2(c)(iii) of the Order requires the 

Attorney General to identify, with the concurrence 

of the Secretaries of State and Commerce, countries 

State and county Location and 

case No. 

Chief executive 

officer of community 

Community map 

repository 

Date of 

modification 

Community 

No. 

Ventura (FEMA 

Docket No.: B– 

2451). 

Unincorporated Areas 

of Ventura County 

(24–09–0380P). 

Kelly Long, Chair, Ventura County 

Board of Supervisors, 1203 Flynn 

Road, Suite 220, Camarillo, CA 

93012. 

Ventura County, Public Works Agency, 

800 South Victoria Avenue, Ventura, 

CA 93009. 

Nov. 4, 2024 ......... 060413 

Hawaii: Hawaii (Interim skipped per 

FEMA’s directive). 

Unincorporated Areas 

of Hawaii County 

(24–09–0518P). 

The Honorable Mitchell D. Roth, 

Mayor, Hawaii County, 25 Aupuni 

Street, Suite 2603, Hilo, HI 96720. 

Hawaii County Department of Public 

Works, Engineering Division, 101 

Pauahi Street, Suite 7, Hilo, HI 

96720. 

Nov. 11, 2024 ....... 155166 

Idaho: Ada (FEMA 

Docket No.: B– 

2451). 

City of Boise (23–10– 

0877P). 

The Honorable Lauren McLean, 

Mayor, City of Boise, P.O. Box 500, 

Boise, ID 83701. 

City Hall, 150 North Capitol Boulevard, 

2nd Floor, Boise, ID 83701. 

Oct. 31, 2024 ....... 160002 

Oregon: Marion 

(FEMA Docket No.: 

B–2451). 

City of Salem (23– 

10–0633P). 

The Honorable Chris Hoy, Mayor, City 

of Salem, City Council, 555 Liberty 

Street Southeast, Room 220, Salem, 

OR 97301. 

City Hall, 555 Liberty Street Southeast, 

Room 325, Salem, OR 97301. 

Nov. 4, 2024 ......... 410167 

Washington: 

Kittitas (FEMA 

Docket No.: B– 

2451). 

City of Ellensburg 

(24–10–0037P). 

The Honorable Rich Elliott, Mayor, City 

of Ellensburg, City Hall, 501 North 

Anderson Street, Ellensburg, WA 

98926. 

City Hall, 501 North Anderson Street, 

Ellensburg, WA 98926. 

Oct. 16, 2024 ....... 530234 

Kittitas (FEMA 

Docket No.: B– 

2451). 

Unincorporated Areas 

of Kittitas County 

(24–10–0037P). 

Laura Osiadacz, Chair, Kittitas County 

Board of Commissioners, 205 West 

5th Avenue, Suite 108, Ellensburg, 

WA 98926. 

Kittitas County Department of Public 

Works, 411 North Ruby Street Suite 

1, Ellensburg, WA 98926. 

Oct. 16, 2024 ....... 530095 

[FR Doc. 2025–00240 Filed 1–7–25; 8:45 am] 

BILLING CODE 9110–12–P 

DEPARTMENT OF HOMELAND 

SECURITY 

[Docket No. CISA–2024–0029] 

Notice of Availability of Security 

Requirements for Restricted 

Transactions Under Executive Order 

14117 

AGENCY: Cybersecurity and 

Infrastructure Security Agency (CISA), 

DHS. 

ACTION: Notice of availability 

SUMMARY: CISA is announcing 

publication of finalized security 

requirements for restricted transactions 

pursuant to Executive Order (E.O.) 

14117, ‘‘Preventing Access to 

Americans’ Bulk Sensitive Personal 

Data and United States GovernmentRelated Data by Countries of Concern.’’ 

In October 2024, CISA published 

proposed security requirements for 

restricted transactions which would 

apply to classes of restricted 

transactions identified in regulations 

issued by the Department of Justice 

(DOJ). CISA solicited comment on those 

proposed security requirements and 

considered that public feedback when 

developing the final security 

requirements. This notice also provides 

CISA’s responses to the public 

comments received. 

DATES: January 8, 2025. 

ADDRESSES: Docket: For access to the 

docket to read background documents 

or comments received, go to 

www.regulations.gov, and insert the 

docket number, CISA–2024–0029, into 

the ‘‘Search’’ box, and follow the 

prompts. 

FOR FURTHER INFORMATION CONTACT: 

Alicia Smith, Senior Policy Counsel, 

Cybersecurity and Infrastructure 

Security Agency, EOSecurityReqs@

cisa.dhs.gov, 202–316–1560. 

SUPPLEMENTARY INFORMATION: 

I. Background 

On February 28, 2024, the President 

issued E.O. 14117 entitled ‘‘Preventing 

Access to Americans’ Bulk Sensitive 

Personal Data and U.S. GovernmentRelated Data by Countries of Concern’’ 

(the ‘‘Order’’), pursuant to his authority 

under the Constitution and laws of the 

United States, including the 

International Emergency Economic 

Powers Act (50 U.S.C. 1701 et seq.) 

(‘‘IEEPA’’), the National Emergencies 

Act (50 U.S.C. 1601 et seq.), and section 

301 of Title 3, United States Code. In the 

Order, the President expanded the scope 

of the national emergency declared in 

E.O. 13873 of May 15, 2019, ‘‘Securing 

the Information and Communications 

Technology and Services Supply 

Chain,’’ and further addressed the 

national emergency with additional 

measures in E.O. 14034 of June 9, 2021, 

‘‘Protecting Americans’ Sensitive Data 

from Foreign Adversaries.’’ Specifically, 

Section 2(a) of E.O. 14117 directs the 

Attorney General, in coordination with 

the Secretary of Homeland Security and 

in consultation with the heads of 

relevant agencies, to issue, subject to 

public notice and comment, regulations 

that prohibit or otherwise restrict 

United States persons from engaging in 

any acquisition, holding, use, transfer, 

transportation, or exportation of, or 

dealing in, any property in which a 

foreign country or national thereof has 

any interest (‘‘transaction’’), where the 

transaction: (i) involves bulk sensitive 

personal data or United States 

Government-related data, as defined by 

final rules implementing the Order; (ii) 

is a member of a class of transactions 

that has been determined by the 

Attorney General to pose an 

unacceptable risk to the national 

security of the United States because the 

transactions may enable countries of 

concern or covered persons to access 

bulk sensitive personal data or United 

States Government-related data in a 

manner that contributes to the national 

emergency described in the Order; and 

(iii) meets other criteria specified by the 

Order.1

Among other things, the Order, at 

Section 2(c), instructs the Attorney 

General, in coordination with the 

Secretary of Homeland Security and in 

consultation with the heads of relevant 

agencies, to issue regulations identifying 

specific categories of transactions 

(‘‘restricted transactions’’) that meet the 

criteria described in (ii) above for which 

the Attorney General determines that 

security requirements, to be established 

by the Secretary of Homeland Security 

through the Director of CISA, 

adequately mitigate the risks of access 

by countries of concern or covered 

persons 2 to bulk sensitive personal data 


lotter on DSK11XQN23PROD with NOTICES1
Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 1529 

of concern and, as appropriate, classes of covered 

persons for the purposes of the Order. 

3The proposed security requirements were 

posted at https://www.cisa.gov/resources-tools/ 

resources/proposed-security-requirementsrestricted-transactions. 

4CISA also participated in several stakeholder 

engagement sessions organized by DOJ. While CISA 

did not receive written feedback during these 

sessions, many points raised by stakeholders in 

these sessions were echoed in the written 

comments received in response to the October 29 

Request for Comment. 

5Other aspects of question 3 related to the clarity 

and specificity of the security requirements are 

addressed separately below. 

6See, e.g., Comment submitted by Information 

Technology Industry Council, CISA–2024–0029– 

0015; Comment submitted by ACT|The App 

Association, CISA–2024–0029–0001. 

7See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011. 

8See, e.g., Comment submitted by U.S. Chamber 

of Commerce, CISA–2024–0029–0017. 

9See, e.g., Comment submitted by Consumer 

Technology Association, CISA–2024–0029–0013. 

10See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011. 

or United States Government-related 

data. In turn, Section 2(d) directs the 

Secretary of Homeland Security, acting 

through the Director of CISA, to 

propose, seek public comment on, and 

publish those security requirements. 

Section 2(e) delegates to the Secretary of 

Homeland Security the President’s 

powers under IEEPA as necessary to 

carry out Section 2(d). 

On October 29, 2024, CISA published 

a Federal Register notice, Request for 

Comment on Security Requirements for 

Restricted Transactions Under 

Executive Order 14117 (the ‘‘October 29 

Request for Comment’’), announcing the 

release of the ‘‘Proposed Security 

Requirements for Restricted 

Transactions’’ 3 directed by E.O. 14117 

Section 2(d) and requesting public 

comment on the proposal. See 89 FR 

85976. The proposed security 

requirements were developed to apply 

to the classes of restricted transactions 

identified in DOJ’s notice of proposed 

rulemaking (NPRM), ‘‘Provisions 

Pertaining to Preventing Access to U.S. 

Sensitive Personal Data and 

Government-Related Data by Countries 

of Concern or Covered Persons,’’ and 

published in the Federal Register on the 

same day as the proposed security 

requirements. See 89 FR 86116. 

The DOJ NPRM proposed to require, 

consistent with E.O. 14117, that United 

States persons engaging in restricted 

transactions must comply with the final 

security requirements by incorporating 

the standards by reference. See 

proposed 28 CFR 202.248, 202.401, 

202.402. 

The security requirements were 

divided into two sections: 

organizational- and covered systemlevel requirements (Section I) and datalevel requirements (Section II). The 

listed requirements were selected with 

the intent of directly mitigating the risk 

of access to covered data, with 

additional requirements included to 

ensure effective governance of that 

access, as well as approaches for 

establishing an auditable basis for 

compliance purposes. The security 

requirements further included a 

definitions section. To the extent the 

requirements used a term already 

proposed to be defined in the DOJ 

rulemaking, CISA’s use of that term in 

the security requirements would carry 

the same meaning. The October 29 

Request for Comment described the 

proposed security requirements and 

definitions, and further provided a nonexhaustive list of twelve questions to 

assist members of the public in 

formulating their comments. 

CISA received 24 comments on the 

proposed security requirements and 

considered them while developing the 

final security requirements. Comments 

submitted in response to the October 29 

Request for Comment are available in 

the docket associated with this notice 

available at https://www.regulations.gov 

(Docket CISA–2024–0029). DOJ’s NPRM 

received 75 comments, which are 

available in the docket associated with 

that NPRM at https://

www.regulations.gov (Docket DOJ–NSD– 

2024–0004–0001). DOJ shared 

comments with CISA that DOJ received 

in response to the NPRM that provided 

feedback that could impact the security 

requirements. These comments include 

one confidential comment that 

contained CISA equities and was 

provided to DOJ by a foreign 

government. 

II. Response to Public Comments 

A. In General 

CISA reviewed and considered all 

comments received in response to the 

October 29 Request for Comment. 

Overall, many commenters appreciated 

the flexibility that CISA provided 

regarding implementation of the 

security requirements as well as the use 

of existing frameworks. Some 

commenters, however, felt that 

application of the security requirements 

as proposed may be burdensome. Others 

requested clarification of certain 

definitional terms and the scope of the 

security requirements. Some 

commenters also provided specific 

feedback on technical elements of the 

proposed security requirements. CISA 

addresses those comments in the 

following sections and explains where 

CISA made changes to its proposal to 

address the feedback received.4

B. Specific Topics 

1. Responses to Questions in CISA’s 

Notice 

In the October 29 Request for 

Comment, CISA included a nonexhaustive list of twelve questions to 

assist the public in providing comments 

in response to the notice. See 89 FR 

85980. The comments CISA received on 

those questions, and CISA’s 

adjudication of those comments, are 

summarized below. 

Robustness, Burden, and Flexibility of 

Proposed Security Requirements 

In the October 29 Request for 

Comment, CISA solicited comments on 

whether the proposed security 

requirements were sufficiently robust to 

mitigate the risks of access to 

Americans’ bulk sensitive personal data 

or government-related data by countries 

of concern (question 1). CISA also asked 

whether the security requirements 

provided sufficient flexibility for the 

types of restricted transactions typically 

engaged in by U.S. entities to avoid 

overburdening commercial activities not 

involving covered data (question 3).5

Many commenters either suggested or 

explicitly stated that the security 

requirements were sufficiently robust to 

mitigate the risk of access to covered 

data by countries of concern, but may be 

too prescriptive or burdensome to 

implement.6 For instance, while 

commenters generally appreciated 

CISA’s use of established frameworks 

like the National Institute of Standards 

and Technology (NIST) Cybersecurity 

Framework (CSF), a small number of 

commenters questioned whether CISA’s 

security requirements extend beyond 

those frameworks and suggest more 

prescriptive mandates that may be 

difficult to implement.7 Other 

commenters acknowledged that 

organizations that will be required to 

comply with this rule already employ 

some level of sophisticated cyber 

defense measures, but it will take time 

for organizations to understand, 

interpret, and fully implement the 

requirements,8 particularly for smalland medium-sized businesses.9 One 

financial sector association noted that, 

for financial institutions with large, 

diverse networks, implementation 

would be resource-intensive and may 

not be feasible in some circumstances.10

Several commenters expressed 

appreciation for the flexibility 

embedded in the data-level 

requirements in Section II, noting that 

flexibility encourages a risk-based but 


lotter on DSK11XQN23PROD with NOTICES1
1530 Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 

11See, e.g., Comment submitted by Workday, 

CISA–2024–0029–0019. 

12See, e.g., Comment submitted by U.S. Chamber 

of Commerce, CISA–2024–0029–0017; Comment 

submitted by Workday, CISA–2024–0029–0019; 

Comment submitted by Information Technology 

Industry Council, CISA–2024–0029–0015; 

Comment submitted by ACT|The App Association, 

CISA–2024–0029–0001. 

13See, e.g., Comment submitted by Information 

Technology Industry Council, CISA–2024–0029– 

0015. 

14See, e.g., Comment submitted by CTIA—The 

Wireless Association and NCTA—The internet & 

Television Association, CISA–2024–0029–0021; 

Comment submitted by USTelecom—The 

Broadband Association, CISA–2024–0029–0018. 

15See, e.g., Comment submitted by Information 

Technology Industry Council, CISA–2024–0029– 

0015; Comment submitted by U.S. Chamber of 

Commerce, CISA–2024–0029–0017; Comment 

submitted by Workday, CISA–2024–0029–0019; 

Comment submitted by Oracle, CISA–2024–0029– 

0014. 

16See, e.g., Comment submitted by U.S. Chamber 

of Commerce, CISA 2024–0029–0017. 

17See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011. 

tailored approach to securing 

transactions, and would help ensure the 

requirements stay up-to-date as 

standards are updated and technology 

advances.11 For that reason, many 

commenters encouraged CISA to extend 

such flexibility to the organizationaland system-level requirements in 

Section I.12

Some commenters suggested that 

organizations be permitted to employ 

alternative compensating controls on 

covered systems where requirements are 

otherwise infeasible.13 Others urged 

CISA to model the security 

requirements on existing regulatory 

regimes administered by other U.S. 

government agencies (e.g., the Federal 

Communications Commission and the 

Department of Commerce), which direct 

organizations to develop cyber risk 

management plans aligned with the 

CSF, or create avenues for reciprocity in 

instances where U.S. entities entering 

into restricted transactions are subject to 

and have demonstrated compliance 

with certain existing data or 

cybersecurity regulatory regimes.14

Commenters suggested that not 

providing the requested flexibility, 

modeling, or reciprocity would increase 

the burden on parties engaged in 

restricted transactions.15

CISA considered these options but 

ultimately concluded that the overall 

structure and approach of the original 

security requirements provide as much 

flexibility as reasonably practicable 

while still addressing the national 

security risks identified by DOJ. CISA 

assesses that granting reciprocity where 

U.S. entities entering into restricted 

transactions are subject to and have 

demonstrated compliance with certain 

existing data or cybersecurity regulatory 

regimes is not a workable solution to 

address the national security risks 

associated with restricted transactions. 

Other regulatory regimes are not 

necessarily designed to address the 

specific risks at issue here. Therefore, 

CISA cannot assume that a cyber risk 

management plan developed to comply 

with another regulatory regime will 

necessarily be designed in a way that 

mitigates the risk of covered persons or 

countries of concern gaining access to 

covered data. Further, even if CISA were 

to do a comparison to map the security 

requirements against the requirements 

in other regulatory regimes and identify 

existing regulatory regimes that cover all 

of the security requirements today, CISA 

could not control for the possibility that 

those regulations may be changed to no 

longer align with the security 

requirements, particularly in light of the 

different goals of these regulations. 

That said, CISA is taking a number of 

steps to make the final security 

requirements less burdensome and 

address specific concerns about 

technical feasibility or ease of 

implementation with respect to 

individual requirements. Specifically in 

the following sections of the security 

requirements: 

• I.A.1.a: CISA acknowledges the 

challenge of maintaining an accurate 

asset inventory in dynamic 

environments, and revises I.A.1.a to 

require documented inventories only 

‘‘to the maximum extent practicable,’’ 

and eliminated the requirement to 

inventory MAC addresses, which is not 

possible in some situations such as 

cloud environments. CISA also clarified 

that these inventories can themselves be 

dynamically curated. 

• I.A.3: CISA addresses commenters’ 

concerns about the rigidity, utility, and 

feasibility of the proposed vulnerability 

remediation timelines, and substantially 

revises the vulnerability remediation 

timelines to prioritize critical assets and 

allow entities engaged in restricted 

transactions to remediate vulnerabilities 

within a risk-informed span of time. 

CISA assesses that these new 

requirements appropriately balance the 

risks of exploitation of vulnerable 

covered systems with the operational 

burden of patching systems. 

• I.A.5: In response to comments 

about the level of effort required to 

implement the security requirements 

across large enterprises,16 CISA revises 

the requirement for any network 

interfacing with a covered system to 

facilitate visibility into connections 

between assets to be implemented ‘‘to 

the extent technically feasible’’ instead 

of ‘‘to the maximum extent practicable.’’ 

• I.A.6: To grant organizations 

additional flexibility in how they 

choose to perform change management, 

CISA significantly reduces the burden 

around installation of new hardware 

and/or software by removing the 

reference to ‘‘firmware’’ and 

requirements for either allowlists or 

approvals to address specific software 

versions.17

• I.B.2: CISA seeks to introduce 

flexibility and alleviate confusion 

around the meaning of the term 

‘‘immediately’’ by revising the 

requirement to revoke access to covered 

systems for terminated employees or 

employees with changed roles from 

‘‘immediately’’ to ‘‘promptly,’’ with 

clarifying examples of what would be 

considered ‘‘promptly.’’ CISA 

recognizes the ambiguity of 

‘‘immediately’’ and assesses that the 

clarifying examples appropriately 

balance operational complexity and the 

security benefits of promptly revoking 

access to covered data upon termination 

or change of an employee’s role. 

• I.B.3: Acknowledging the term 

‘‘disabled’’ is ambiguous and that 

commenters requested CISA clarify that 

the requirement was to implement a 

process, CISA clarifies language around 

security log retention to state that 

organizations are required to implement 

a notification process when security 

logs are not being produced and/or 

retained as expected rather than 

referring to logs being disabled. 

• I.B.4 [removed]: To reduce burden 

on implementing organizations, CISA 

removes the requirement to maintain 

organizational policies and processes to 

ensure that unauthorized media and 

hardware are not connected to covered 

assets. CISA assesses that in light of 

CISA’s updates to the definition of the 

term ‘‘covered system,’’ the other 

requirements are sufficient to protect 

covered systems, and this requirement 

is no longer necessary. [Note that, as a 

result of this deletion, requirements 

I.B.5 and 6 are now I.B.4 and 5.] 

• I.B.5 [renumbered I.B.4] CISA 

clarifies that deploying ‘‘deny by 

default’’ is not as burdensome as some 

commenters assumed by noting the idea 

of ‘‘deny by default’’ does not only 

include the use of network firewalls but 

may also be implemented in other ways, 

such as via authentication of users and 

other information systems to the 

covered system. CISA assesses that, as 

clarified, this requirement is important 

to ensure that unauthorized systems and 

users do not inappropriately have access 

to data within covered systems. 


lotter on DSK11XQN23PROD with NOTICES1
Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 1531 

18See, e.g., Comment submitted by U.S. Chamber 

of Commerce, CISA–2024–0029–0017. 

19Comment submitted by U.S. Chamber of 

Commerce, CISA–2024–0029–0017. 

20See, e.g., Comment submitted by WorkDay, 

CISA–2024–0029–0019. 

21See, e.g., Comment submitted by Information 

Technology Industry Council, CISA–2024–0029– 

0015; Comment submitted by ACT|The App 

Association, CISA–2024–0029–0023. 

22See, e.g., Comment submitted by Infoblox, 

CISA–2024–0029–0020. 

23See, e.g., Comment submitted by U.S. Chamber 

of Commerce, CISA–2024–0029–0017; Comment 

submitted by the Consumer Technology 

Association, CISA–2024–0029–0013; Comment 

submitted by National Foreign Trade Council, 

CISA–2024–0029–0022. 

24See, e.g., Comment submitted by U.S. Chamber 

of Commerce, CISA–2024–0029–0017. 

25See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011. 

At the same time, when crafting the 

proposed security requirements, CISA 

did so with the goal of balancing 

regulatory burden, technical feasibility, 

and flexibility with the underlying 

national security needs. As such, CISA 

determined that certain 

recommendations, such as extending 

the flexible implementation approach in 

the data-level requirements to the 

organizational- and system-level 

requirements, would undermine 

security to the detriment of the overall 

regime. CISA notes that the 

organizational- and system-level 

requirements are scoped only to a 

limited subset of covered systems that 

interact with data of particular 

sensitivity (per the DOJ rule) and are 

neither considered nor intended to 

comprise the entirety of an effective 

cybersecurity program; rather, they are a 

selected set of practices and 

preconditions that CISA concluded are 

necessary to effectively implement the 

data-level requirements. 

Clarifying Terms and Applications 

CISA asked whether the security 

requirements were sufficiently clear for 

organizations to verify compliance 

(question 3) and/or sufficient to provide 

U.S. persons engaged in restricted 

transactions confidence that the logical 

and physical access controls are 

sufficiently managed to deny access to 

covered persons or countries of concern 

(question 2). CISA also asked about 

areas where additional interpretive 

guidance would be helpful to U.S. 

entities in determining which data-level 

requirements should be applied based 

on the nature of the transaction and the 

data at hand (question 6). 

Some commenters requested that 

CISA clarify the definition of ‘‘covered 

system,’’ specifically as it relates to 

endpoints (e.g., workstations/laptops), 

to make clear that the definition only 

applies to systems that handle covered 

data qualified as bulk under DOJ’s 

definition.18 One commenter observed 

that ‘‘this interpretation is of critical 

importance as it represents the 

difference between organizations 

considering how they secure a 

collection of specific systems as 

opposed to an enterprise-wide retooling, 

the latter of which would be extremely 

challenging and unnecessarily 

burdensome.’’ 19

In response, CISA revises the 

definition of ‘‘covered system’’ to reflect 

that a covered system is limited to 

systems that interact with covered data 

in bulk form and not user endpoints that 

ordinarily read or view sensitive 

personal data (other than sensitive 

personal data that constitutes 

government-related data) but do not 

ordinarily interact with sensitive 

personal data in bulk form. Of note, 

because government-related data is not 

subject to any bulk data threshold in the 

DOJ rulemaking, any system that 

interacts with government-related data 

would still be considered a covered 

system. Organizations implementing the 

security requirements need to carefully 

consider how this clarification applies 

to their particular information systems, 

transactions, and manners of interacting 

with covered data. 

CISA also received comments 

requesting that, in defining ‘‘covered 

systems’’ and ‘‘covered data,’’ CISA 

include an explicit reference to exempt 

transactions by specifically exempting 

data that is subject to an exemption 

from the definition of covered systems 

and covered data.20

CISA notes that both definitions in 

the security requirements require the 

system and/or data to be used ‘‘as part 

of a restricted transaction.’’ Per the 

definitions in the DOJ rulemaking, an 

exempt transaction is definitionally not 

a restricted transaction and thus an 

information system that exclusively 

participates in transactions with 

covered persons that are exempt (e.g., an 

internal human resources system that 

only deals in data subject to the 

corporate group exemption) would not 

be considered a covered system under 

the definition. Because CISA assesses 

that the definition already excludes 

such systems, CISA does not make any 

changes to the definition in response to 

these comments. However, consistent 

with changes to the DOJ rulemaking to 

switch the order of the terms 

‘‘government-related data’’ and ‘‘bulk 

U.S. sensitive personal data’’ to avoid 

the possibility of confusion as to 

whether the bulk thresholds apply to 

government-related data, CISA has 

revised the definition of ‘‘covered data’’ 

to switch the order of these terms in the 

definition. 

Mapping to Other Frameworks 

In the October 29 Request for 

Comment, CISA inquired about the 

utility of mapping requirements to other 

standards, such as ISO/IEC 27001 or 

NIST Special Publication 800–171 

(question 12). Some commenters 

recommended this approach, noting that 

such mapping would be helpful to allow 

organizations to better understand how 

existing processes or controls they are 

already using can be applied and 

understood in the context of the security 

requirements.21 Other commenters 

suggested additional candidates (e.g., 

CISA’s Encrypted DNS Implementation 

Guidance).22

CISA determined additional mapping 

is better suited to interpretive guidance 

because these frameworks include 

detailed security control sets, and such 

guidance will need to further clarify the 

intent and extent of the mapping to 

these controls. CISA decided not to 

include additional mapping in the final 

security requirements themselves but 

remains open to providing additional 

mapping through future interpretive 

guidance. 

2. Other Comments on the Security 

Requirements 

Extent to Which Covered Persons May 

Access Covered Data 

Several commenters inquired if 

CISA’s security requirements were 

intended to prevent all access to 

covered data by covered persons or to 

prevent unauthorized or unmitigated 

access.23 That is, commenters sought 

clarity on whether any degree of access 

by covered persons to covered data is 

permissible when implementing the 

security requirements. Commenters 

noted, for instance, that the chapeau of 

Section II of the security requirements 

indicated that entities were required to 

prevent covered persons or countries of 

concern from gaining access to covered 

data, which would appear to render the 

transaction no longer covered by DOJ’s 

rule.24 Commenters explained that 

under their reading, the requirement to 

prevent access to covered data by 

covered persons or countries of concern 

arguably takes the transaction out of the 

DOJ rule’s definition of restricted 

transaction altogether.25 Commenters 

noted, however, that CISA’s security 

requirements were developed to suggest 

the efficacy of controls such as data 

minimization, masking, and privacyenhancing techniques in mitigating the 


lotter on DSK11XQN23PROD with NOTICES1
1532 Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 

risk of access to covered data by covered 

persons or countries of concerns. 

To address the feedback raised in 

these comments, CISA affirms that the 

security requirements are meant to 

prevent access to covered data by 

countries of concern unless specific 

efforts outlined in the security 

requirements are taken to mitigate the 

national security risks associated with 

such access. 

More specifically, in the chapeau to 

the data-level requirements in Section 

II, CISA proposed that U.S. persons 

should ‘‘implement a combination of 

the following mitigations that, taken 

together, is sufficient to fully and 

effectively prevent access to covered 

data by covered persons and/or 

countries of concern.’’ CISA proposed 

that this approach would mitigate the 

national security risks associated with 

access to covered data by covered 

persons and/or countries of concern. As 

described in the Order, DOJ’s NPRM, 

and CISA’s proposed security 

requirements and the October 29 

Request for Comment, access to covered 

data by covered persons and/or 

countries of concern poses a range of 

threats to national security and foreign 

policy, including providing countries of 

concern with information they need or 

can use to engage in malicious cyberenabled activities and malign foreign 

influence; blackmail and espionage 

against U.S. persons; intimidate 

activists, academics, journalists, 

dissidents, political figures, or members 

of non-governmental organizations or 

marginalized communities; curb 

political opposition; limit freedoms of 

expression, peaceful assembly, or 

association; or enable other forms of 

suppression of civil liberties. See 89 FR 

85978. In the security requirements, 

CISA proposed to address these risks at 

the data level by requiring that covered 

persons be denied access to the 

underlying covered data—either by 

denying access outright or by only 

allowing covered persons access to 

covered data that had been manipulated 

in a way (e.g., encryption, deidentification) that would effectively 

mitigate the risks from permitting direct 

access to the underlying data. 

In response to comments on this 

issue, CISA clarifies the chapeau 

language for the data-level requirements 

in the final security requirements to 

state that U.S. persons should 

‘‘implement a combination of the 

following mitigations that, taken 

together, is sufficient to fully and 

effectively prevent access to covered 

data that is linkable, identifiable, 

unencrypted, or decryptable using 

commonly available technology by 

covered persons and/or countries of 

concern.’’ This clarification establishes 

that the adoption of the data-level 

requirements does not mean no access 

to covered data is permissible, but that 

certain data-level requirements must be 

implemented to achieve a level of 

minimization of that access and/or 

covered data sufficient to mitigate the 

national security risks identified by 

DOJ. 

Under the DOJ regulation, covered 

data transactions include regulated 

categories of transactions that involve 

covered person or country of concern 

access to covered data, regardless of 

whether the data is encrypted, 

anonymized, pseudonymized, or deidentified. As DOJ explains in its 

rulemaking, encryption, 

pseudonymization, and deidentification are not completely 

effective in all cases and can in some 

cases be reversed or undermined. At the 

same time, the transactions identified by 

DOJ as restricted have important 

economic value relative to their national 

security risk and are allowed to proceed 

if they meet the CISA-developed 

security requirements. CISA was thus 

tasked with determining an appropriate 

balance on mitigating the national 

security risks associated with such 

access to covered data. 

While CISA considered whether it 

could adopt other options for data-level 

requirements that would still permit 

access to at least some unmitigated 

covered data to covered persons, CISA 

ultimately determined that allowing 

covered persons or countries of concern 

access to covered data without 

application of an effective combination 

of techniques identified in the data-level 

requirements (such as 

pseudonymization, de-identification, 

aggregation, and encryption) would not 

effectively mitigate the unacceptable 

national security risks identified by DOJ 

resulting from enabling access to such 

data by covered persons and countries 

of concern. Thus, the final security 

requirements permit organizations to 

undertake restricted transactions either 

by directly denying covered person/ 

country of concern access to covered 

data itself or by applying techniques 

such as pseudonymization, deidentification, aggregation, and 

encryption in the manner prescribed in 

the security requirements to reduce the 

risks to national security while still 

allowing for a form of access to an 

appropriately mitigated version of the 

covered data (in conjunction with 

implementation of the organizationaland system-level requirements). 

As noted in the DOJ regulation’s 

definition of access, the implementation 

of data processing techniques (as 

outlined in the data-level requirements) 

before sharing data is irrelevant to the 

determination of whether a transaction 

involves ‘‘access’’ and is thus a covered 

data transaction. However, restricted 

transactions are explicitly permitted to 

proceed through application of the 

security requirements, effectively 

mitigating the national security risks 

identified by DOJ. 

The following examples discuss 

several applicable scenarios. In all cases 

(with the exception of example 4), these 

examples assume that the organization 

has conducted the required data risk 

assessment required in Section I.C of the 

security requirements and determined 

that the specific requirements 

implemented are sufficient to ‘‘fully and 

effectively prevent access to covered 

data that is linkable, identifiable, 

unencrypted, or decryptable using 

commonly available technology by 

covered persons and/or countries of 

concern.’’ The examples (with the 

exception of example 4) also assume 

that the organization complies with 

other applicable requirements in the 

DOJ’s rule. 

Example 1: A U.S. person retains a 

cloud provider headquartered in a 

country of concern to store encrypted 

covered data through a vendor 

agreement. Per the DOJ rulemaking, the 

cloud provider is a covered person, and 

such a transaction would constitute a 

covered data transaction. The U.S. 

person implements the security 

requirements, including the 

requirements around encryption and 

encryption keys. Such a transaction 

could proceed if the U.S. person fully 

implements the security requirements. 

Example 2: A U.S. business that deals 

in covered data is executing an 

investment agreement with a covered 

person. The investment agreement 

provides that the U.S. business will 

share with the covered person investor 

sensitive personal data about individual 

consumers that meets DOJ’s relevant 

bulk threshold. The organization 

implements the security requirements 

before sharing data with the covered 

person investor (for example by 

aggregating data and/or de-identifying it 

along with implementing the other 

security requirements). Such data is still 

considered covered data. The sharing of 

data in the investment agreement is still 

a restricted transaction but can proceed 

due to the implementation of the 

security requirements. 

Example 3: A U.S. organization hires 

a covered person in a country of 

concern (or retains their services by 

contract) into a role whose duties 

include access to covered data. As part 


lotter on DSK11XQN23PROD with NOTICES1
Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 1533 

26See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011; Comment 

submitted by Consumer Technology Association, 

CISA–2024–0029–0013; Comment submitted by 

USTelecom, CISA–2024–0029–0018; Comment 

submitted by Information Technology Industry 

Council, CISA–2024–0029–0015. 

27See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011 

28See, e.g., Comment submitted by Consumer 

Technology Association, CISA–2024–0029–0013. 

29See, e.g., Comment submitted by the Bank 

Policy Institute, CISA–2024–0029–0011. 

30See generally Cybersecurity and Infrastructure 

Security Agency, Reducing the Significant Risk of 

Known Exploited Vulnerabilities, https://

www.cisa.gov/known-exploited-vulnerabilities (last 

visited Dec. 1, 2024) (listing CISA’s requirements 

for listing a KEV). 

31See, e.g., Comment submitted by Workday, 

CISA–2024–0029–0019; Comment submitted by 

USTelecom—The Broadband Association, CISA– 

2024–0029–0018. 

of entering into the employment 

agreement (or vendor agreement), the 

organization implements the security 

requirements (including the 

organizational- and system-level 

requirements) and only shares deidentified covered data with the covered 

person in a way that minimizes 

linkability in accordance with the 

security requirements. Such a restricted 

transaction would be allowed to 

proceed. 

Example 4: Same as Example 3, 

except that instead of de-identifying the 

covered data, the organization 

knowingly authorizes the employee or 

vendor to have access to covered data 

(e.g., to bulk U.S. sensitive personal 

data) without applying efforts to deidentify, pseudonymize, encrypt, or 

otherwise implement the data-level 

security requirements. In this example, 

the U.S. organization knowingly gave a 

covered person access to covered data 

through an employment or vendor 

agreement without implementing the 

security requirements. As such, the U.S. 

organization knowingly engaged in a 

restricted transaction that fails to 

comply with the requirements of 

subpart D of 28 CFR part 202 and thus 

is engaged in a covered data transaction 

that is not authorized pursuant to 28 

CFR 202.401. 

Example 5: Same as Example 3, 

except the employee or vendor’s duties 

do not require access to covered data 

but do include general access to the 

organization’s networks and information 

systems, including potentially covered 

systems, within which covered data 

may be stored. The organization 

implements the security requirements, 

including the data-level requirement of 

denying access to covered data for that 

covered person. Because the transaction 

could afford a covered person access to 

covered data, but the organization 

employed controls to prevent it, such an 

employment or vendor agreement could 

proceed as a restricted transaction. 

Vulnerability Management (I.A.3) 

In the proposed security 

requirements, CISA proposed that 

organizations should patch 

vulnerabilities that are known to be 

exploited, critical, or high within an 

outlined timeframe. CISA proposed this 

approach for consistency with the 

standard to which Federal Agencies are 

held under Binding Operational 

Directives (BOD) 22–01 and 19–02. 

CISA received several comments on this 

subject suggesting that CISA’s approach 

was technically challenging to 

implement and not sufficiently riskbased.26 One commenter, for instance, 

stated that the remediation timelines 

proposed were too aggressive, and noted 

that NIST Special Publication 800–53 

directs remediation to occur in 

accordance with a risk-assessment 

rather than prescribing specific 

timelines.27 Another commenter 

recommended that CISA change the 

timelines for remediation to no shorter 

than 30 days, stating that CISA’s 

proposed timeframes of 14 and 15 days 

were unreasonable and impracticable.28

Commenters indicated that this 

requirement may cause organizations to 

expend their limited resources 

addressing vulnerabilities that do not 

necessarily pose the greatest risk to their 

organizations.29

CISA considered this feedback 

carefully and concluded that an 

alternate approach to vulnerability 

management could effectively respond 

to the identified risks while being less 

burdensome in implementation. In the 

final security requirements, CISA adopts 

a new approach that requires 

organizations to remediate known 

exploited vulnerabilities (KEVs) in 

internet-facing systems in a risk-based 

manner that prioritizes the most critical 

assets first, with all such vulnerabilities 

remediated within 45 calendar days. 

This approach is based on the approach 

to patching outlined in the CISA CrossSector Cybersecurity Performance Goals 

(CPGs) and the CSF. To compensate for 

the additional flexibility being provided 

through the revised requirement, CISA 

determined that it was necessary to 

require that entities engaged in 

restricted transactions establish a 

process to evaluate, after patching, 

whether any internet-facing covered 

systems with KEVs were compromised 

prior to the patch being applied. Based 

on its operational experience, CISA 

notes that KEVs on internet-facing 

systems are commonly exploited with 

access persisting beyond the time of 

patching. A KEV is a vulnerability that 

is currently being exploited, based on 

information known to CISA.30 Through 

this change, CISA intends to reduce the 

operational burden of vulnerability 

management and maximize its impact 

on addressing known cybersecurity 

risks to covered systems. 

Multi-Factor Authentication and 

Password Length (I.B.1) 

In the proposed security 

requirements, CISA proposed that 

organizations should implement multifactor authentication (MFA) for access 

to covered systems or, if not technically 

feasible and/or enforced, implement 

passwords of a minimum of 16 

characters. CISA proposed this 

approach based on the CSF and the 

CISA CPGs. Commenters suggested that 

CISA’s approach would be clearer if 

CISA incorporated NIST Special 

Publication 800–63B (SP 800–63B)’s 

definition of Authentication Assurance 

Levels (AALs) and only required 16- 

character passwords if technically 

feasible.31

In the final security requirements, 

CISA added a reference to NIST’s AAL 

definition to clarify that CISA considers 

any authenticator that implements 

AAL2 or AAL3 (as defined in the latest 

version of SP 800–63B or any of its 

supplements) as qualifying as MFA for 

purposes of this requirement. This 

includes syncable cryptographic 

authenticators (colloquially known as 

‘‘passkeys’’). However, CISA notes that 

‘‘Multi-factor authentication’’ is a 

broadly understood term in the industry 

and declines to remove its use from the 

security requirements. CISA also 

updates the requirement for 16- 

character passwords to instead require 

15-character passwords in situations 

without MFA. This change reduces 

burden on organizations and aligns 

CISA’s requirement with the CPGs. 

However, CISA declines to further 

reduce the number of required 

characters, even where 15-character 

passwords are not technically feasible. 

This requirement is taken from the CISA 

CPGs where sufficiently strong 

passwords are suggested for all 

password-protected IT assets, with an 

understanding that some operational 

technology (OT) assets may not be able 

to technically support such passwords. 

CISA does not believe such OT assets 

are likely to host covered data and did 

not receive any comments suggesting 

otherwise. CISA concludes that 

information systems that host covered 

data be required to either implement 


lotter on DSK11XQN23PROD with NOTICES1
1534 Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 

32See Comment submitted by The Business 

Software Alliance, CISA–2024–0029–0024. 

33See, e.g., Comment submitted by The 

Consumer Technology Association, CISA–2024– 

0029–0013. 

34CISA defers to DOJ regarding whether such a 

risk assessment may be subject to audit or other 

review as part of compliance aspects of the DOJ 

rulemaking. 

35See, e.g., Comment submitted by Bank Policy 

Institute, CISA–2024–0029–0011. 

MFA (including ‘‘passwordless’’ 

methods) or have 15-character 

minimum passwords in instances where 

MFA is not technically feasible and/or 

enforced (such as when MFA is partially 

enforced due to technical limitations). 

CISA believes that organizations should 

implement MFA in all situations where 

it is technically feasible to do so and 

where it is not, must ensure 15- 

character passwords are used in covered 

systems. CISA assesses that this 

approach is a reasonable requirement 

that is well grounded in industry best 

practices. Technologies such as 

password managers may be used to 

reduce the operational burden of such 

passwords. 

Access To Log Systems (I.B.3) 

One commenter 32 requested that 

CISA clarify whether authorized access 

to the security logging system is 

intended to be limited to those users 

who are authorized to access the 

covered system itself or, more generally, 

users performing security duties in the 

organization. 

CISA declines to make any changes to 

the text of the final security 

requirements in response to this 

comment, but notes that the security 

requirements specify that users who 

access or modify such log data are only 

required to be ‘‘authorized and 

authenticated.’’ CISA does not intend 

that individuals who are ‘‘authorized 

and authenticated’’ to access or modify 

collected logs must also be authorized to 

access covered systems. 

Data Risk Assessment (I.C) 

Several commenters raised questions 

and concerns about the data risk 

assessment. Some commentors were 

concerned about whether the risk 

assessment was to be shared with DOJ 

or CISA, while others had some 

concerns about the potential cost impact 

and compliance burden of developing it. 

Others also noted that DOJ included 

audit and reporting requirements in its 

rule and that the addition of another 

compliance report under CISA’s 

requirements would be too 

burdensome.33

In response to these comments, and to 

deconflict with DOJ’s audit and 

reporting requirements, CISA makes 

minor changes to this requirement, 

specifically clarifying this risk 

assessment is intended for internal use 

only as a tool to inform data protection 

(not for documentation or disclosure to 

a government agency), and, to further 

reduce implementation burden, that 

documenting the assessment is not 

required.34 CISA also supplies 

additional detail specifying that the 

plan be reviewed internally by the 

organization. 

Data-Level Requirements and What 

Constitutes ‘‘Sufficiency’’ (II, Chapeau) 

Comments pertaining to the data-level 

requirements were largely positive, 

noting an appreciation for the level of 

flexibility that was perceived by many 

to be in contrast with the system-level 

requirements. For instance, one 

commenter said that allowing 

organizations flexibility to determine 

which combination of data-level 

requirements are sufficient to address 

risks, based on their unique risk profile 

‘‘presents the best chance of achieving 

Executive Order 14117’s ultimate 

objective to secure’’ sensitive U.S. 

data.35 However, some commenters took 

issue with the requirement to fully and 

effectively prevent access to covered 

data, and requested guidance and/or 

clarification about what constitutes a 

‘‘sufficient’’ combination of data-level 

requirements to prevent access. CISA 

also received some feedback from 

interagency partners on further 

clarifying the specific encryption 

requirements. 

Given that commenters generally 

agreed that the data-level requirements 

as written achieved their intended aim, 

CISA made only minor revisions. 

Commenters asked CISA to clarify that 

requirements around the version of 

Transport Layer Security (TLS) used 

were limited to connections that were 

already using TLS, which CISA clarified 

by including requirements for the 

version of TLS in II.B.1 rather than as 

a separate requirement (II.B.2). CISA 

also consulted with other federal agency 

partners on the topic of encryption and 

is adding an explanation of what level 

of encryption CISA considers sufficient 

for the purposes of these security 

requirements based on these 

consultations. CISA recognizes the 

appeal of a prescriptive (and 

predictable) standard but maintains 

there is no one-size-fits-all solution 

given the varied nature of restricted 

transactions. Additionally, the question 

of what is sufficient to prevent access is 

a compliance matter and not a technical 

implementation matter. E.O. 14117 sec. 

2(d)(ii) gives the Attorney General 

authority to issue enforcement guidance 

regarding these security requirements, 

in consultation with the Director of 

CISA. CISA will coordinate with DOJ if 

it determines further guidance on the 

meaning of ‘‘sufficient’’ is appropriate. 

Framework Mapping 

Many commenters expressed 

appreciation for the fact that CISA 

leveraged existing, well-known 

cybersecurity and privacy frameworks, 

and found the mapping between 

frameworks and specific requirements 

especially helpful. However, some 

commenters expressed concern that 

CISA’s approach was not conducive to 

harmonizing cyber regulations to the 

greatest degree practicable across the 

government and suggested that CISA’s 

mapping to the CSF, NIST’s Privacy 

Framework (PF), and CPGs may be 

confusing, noting that the CSF is the 

primary risk management framework 

used by some organizations. 

After considering these comments, 

CISA continues to assess that its method 

of mapping the security requirements to 

the CSF, PF, and CPGs is the optimal 

way to minimize the burden on 

organizations while still allowing as 

much flexibility in implementation as 

possible. 

First, as noted in the proposed 

security requirements and as CISA has 

preserved in the final security 

requirements, references to these 

frameworks are intended to help readers 

understand which aspects of existing 

frameworks, guidance, or other 

resources the security requirements are 

based upon; understanding and 

applying the security requirements does 

not require a reader to understand and 

apply those references. As such, the 

references should only serve to be a 

helpful reference where readers find 

them useful, while those who find the 

references confusing or who do not use 

these other resources as part of their 

organizational compliance structure can 

disregard the mapping. 

Second, the Order requires CISA to 

base its security requirements on the 

CSF and the PF. CISA has evidenced 

compliance with this requirement by 

reference to these frameworks explicitly. 

This means that the only framework 

CISA could eliminate the mapping to is 

the CPGs. Given that many commenters 

expressed appreciation for the CPG 

mapping and that the CPGs are, 

themselves, based on the CSF, CISA 

assesses that the inclusion of the CPGs 

should not be overly difficult or 

confusing, especially for the 

cybersecurity personnel and designated 

accountable officials responsible for 

ensuring that U.S. entities engaging in 


lotter on DSK11XQN23PROD with NOTICES1
Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 1535 

36See, e.g., Comment submitted by The Business 

Software Alliance, CISA–2024–0029–0024. 

37Terms used in CISA’s security requirements 

that are defined in the DOJ rulemaking have the 

same meaning in the security requirements as 

provided in the DOJ rulemaking. 

38CISA notes that the security requirements are, 

as required by the Order, designed to ‘‘address the 

unacceptable risk posed by restricted transactions, 

as identified by the Attorney General.’’ E.O. 14117 

Sec. 2(d). They are not intended to reflect a 

comprehensive cybersecurity program. For 

example, several areas addressed in CISA’s CPGs, 

available at https://www.cisa.gov/cross-sectorcybersecurity-performance-goals, are not reflected 

in the proposed data security requirements, even 

though the CPGs themselves are a common set of 

protections that CISA recommends all critical 

infrastructure entities voluntarily implement to 

meaningfully reduce the likelihood and impact of 

known risks and adversary techniques. As the 

operational lead for federal cybersecurity and 

national coordinator for critical infrastructure 

security and resilience, CISA recommends that all 

U.S. persons implement cybersecurity best practices 

in light of the risk and potential consequence of 

cyber incidents. 

restricted transactions adhere to the 

final security requirements. 

3. Out of Scope or Related to DOJ’s 

NPRM 

Several commenters raised questions, 

concerns, or feedback that were outside 

of the authorities and direction 

provided to CISA in E.O. 14117. 

Commenters also raised issues that were 

related to the implementation of DOJ’s 

regulations rather than the proposed 

security requirements themselves. 

While CISA reviewed this feedback 

and shared relevant comments with DOJ 

to consider as they drafted their final 

rule, issues specific to the DOJ rule itself 

are beyond the scope of this notice. 

Conversely, in some instances, DOJ 

received comments on its NPRM that 

more directly related to CISA’s 

proposed security requirements. Where 

DOJ shared such comments with CISA, 

CISA reviewed and considered this 

feedback as part of developing the final 

security requirements, as reflected 

above. 

4. Continued Stakeholder Engagement 

CISA also received a few comments 

requesting additional stakeholder 

engagement on the development of 

these security requirements. For 

example, one comment requested an 

extension of the comment period by 17 

days to provide stakeholders extra time 

to provide robust and considered input. 

CISA appreciates the commenters’ 

desire to provide the most useful, 

robust, and thoughtful feedback possible 

in the time allotted for comments. 

However, CISA decided not to extend 

the comment period given the pressing 

national security interests underlying 

the need for DOJ’s rule, and E.O. 

14117’s requirement that the rule 

incorporate CISA’s security 

requirements. 

Other commenters requested that 

CISA establish an ongoing stakeholder 

engagement process to receive 

continued feedback on the security 

requirements even after they have been 

finalized. Some of the commenters 

noted that these security requirements 

could be burdensome to implement 

effectively, and others emphasized that 

experience applying the security 

requirements could lead stakeholders to 

identify areas for improvement. 

CISA appreciates stakeholder interest 

in ensuring that the security 

requirements remain current and 

applicable over time and will consider 

the best way to receive and incorporate 

relevant feedback in the future to the 

extent changes to the security 

requirements become necessary or 

desirable. However, at this time, CISA 

does not intend to establish a formal 

process for receiving additional 

feedback on the security requirements 

given that the comment period has 

closed, and CISA must finalize the 

security requirements so that they can 

be incorporated by reference into DOJ’s 

final rule. 

One commenter expressed concern 

about the security requirements being a 

‘‘quasi-rule,’’ indicating that CISA could 

change the security requirements at any 

point in the future without ‘‘procedural 

protections’’ for impacted entities.36

CISA appreciates the concern raised 

by the commenter and confirms that 

CISA has no intention of changing these 

security requirements without providing 

the public notice of any future changes. 

As discussed above, CISA notes that 

while the Order directed DOJ to propose 

a rule and finalize that rule to 

implement its directive, the Order did 

not provide the same direction to CISA 

for promulgating the security 

requirements. By design, the security 

requirements themselves are not a rule 

governed by the process laid out in the 

Administrative Procedure Act, 5 U.S.C. 

553. While this allows CISA to update 

the security requirements quickly, 

tracking new developments in 

technology and data security, such 

updated security requirements will not 

be enforceable against entities regulated 

by DOJ’s rule unless DOJ updates its 

rule to change the version of the 

security requirements incorporated 

therein by reference. In other words, 

commenters can be assured that they 

will not be subjected to new security 

requirements without receiving 

requisite procedural protections for 

implementing the change, as required 

by law. 

III. Description of Final Security 

Requirements 

The security requirements are 

intended to address national-security 

and foreign-policy threats that arise 

when countries of concern 37 and 

covered persons access U.S. 

government-related data or bulk U.S. 

sensitive personal data that may be 

implicated by the categories of restricted 

transactions. Additional background on 

the purpose for these security 

requirements was included in CISA’s 

notice announcing the release of the 

proposed security requirements. See 89 

FR 85978. The DOJ Final Rule requires, 

consistent with E.O. 14117, that United 

States persons engaging in restricted 

transactions comply with the final 

security requirements by incorporating 

the security requirements by reference 

into the regulations. 28 CFR 202.401. 

The security requirements remain 

divided into two sections: 

organizational- and covered systemlevel requirements (Section I) and datalevel requirements (Section II). The 

listed requirements were selected with 

the intent of directly mitigating the risk 

of access to covered data, with 

additional requirements included to 

ensure effective governance of that 

access, as well as approaches for 

establishing an auditable basis for 

compliance purposes. Requirements 

that directly mitigate the risk of access 

include I.B.1–2, I.B.4–5, and all datalevel requirements (II.A, II.B, II.C, and 

II.D). Requirements included as a 

mechanism for ensuring proper 

implementation and governance of 

those access controls include all 

controls in I.A. Additional requirements 

incorporated as a mechanism for 

ensuring auditable compliance of the 

aforementioned access controls include 

I.B.3 and I.C. These requirements reflect 

a minimum set of practices that CISA 

assesses are required for effective data 

protection, as informed by CISA’s 

operational experience. These 

requirements were designed to be 

representative of broadly accepted 

industry best practices and are intended 

to address the needs of national security 

without imposing an unachievable 

burden on industry. 

The final security requirements 

largely maintain the same design as the 

proposed security requirements. The 

security requirements are designed to 

mitigate the risk of sharing U.S. 

government-related data or bulk U.S. 

sensitive personal data with countries of 

concern or covered persons through 

restricted transactions.38 They do this 

by imposing conditions specifically on 

the covered data that may be accessed 


lotter on DSK11XQN23PROD with NOTICES1
1536 Federal Register / Vol. 90, No. 5 / Wednesday, January 8, 2025 / Notices 

39As noted above, for the purposes of the security 

requirements, to the extent CISA uses a term that 

is defined in the DOJ rulemaking, CISA uses that 

definition. Therefore, CISA is using the term U.S. 

persons as defined by the DOJ Final Rule. That 

definition reads ‘‘any United States citizen, 

national, or lawful permanent resident; any 

individual admitted to the United States as a 

refugee under 8 U.S.C. 1157 or granted asylum 

under 8 U.S.C. 1158; any entity organized solely 

under the laws of the United States or any 

jurisdiction within the United States (including 

foreign branches); or any person in the United 

States.’’ 28 CFR 202.256. 

40 6 U.S.C. 650(14) (which applies to all of Title 

XXII of the Homeland Security Act of 2002, which, 

in turn, contains most of CISA’s authorities) defines 

Information System as having the meaning given 

the term in the Paperwork Reduction Act, 44 U.S.C. 

3502, and specifically includes ‘‘industrial control 

systems, such as supervisory control and data 

acquisition systems, distributed control systems, 

and programmable logic controllers.’’ 6 U.S.C. 

650(14). However, given CISA’s assumption that 

this type of operational technology is unlikely to be 

implicated by DOJ’s regulations, CISA is not 

including the operational technology-related prong 

here. 

as part of a restricted transaction, on the 

covered systems more broadly (both 

terms CISA defines within the security 

requirements), and on the organization 

as a whole. While the requirements on 

covered systems and on an 

organization’s governance of those 

systems apply more broadly than to the 

data at issue and the restricted 

transaction itself, CISA continues to 

assess that implementation of these 

requirements is necessary to validate 

that the organization has the technical 

capability and sufficient governance 

structure to appropriately select, 

successfully implement, and continue to 

apply the data-level security 

requirements in a way that addresses 

the risks identified by DOJ for the 

restricted transactions. For example, to 

ensure and validate that a covered 

system denies covered persons access to 

covered data, it is necessary to maintain 

audit logs of accesses as well as 

organizational processes to utilize those 

logs. Similarly, it is necessary for an 

organization to develop identity 

management processes and systems to 

establish an understanding of which 

persons may have access to different 

data sets. 

In addition to requirements on 

covered systems, applying security 

requirements on the covered data itself 

that may be accessed in a restricted 

transaction is also necessary to address 

the risks. The specific requirements that 

are most technologically and logistically 

appropriate for different types of 

restricted transactions may vary. For 

example, some transactions may be 

amenable to approaches that minimize 

data or process it in such a way that 

does not reveal covered data to covered 

persons. In other cases, techniques such 

as access control and encryption may be 

more appropriate to deny any access by 

covered persons to unmitigated covered 

data. The security requirements provide 

multiple options to mitigate risk, though 

all the options build upon the 

foundation of the requirements imposed 

on covered systems and the organization 

as a whole. While U.S. persons 39

engaging in restricted transactions will 

be required to implement all the 

organizational- and system-level 

requirements, such persons will have 

some flexibility to determine which 

combination of data-level requirements 

are sufficient to fully and effectively 

prevent access to covered data that is 

linkable, identifiable, unencrypted, or 

decryptable using commonly available 

technology by covered persons and/or 

countries of concern, based on the 

nature of the transaction and the data at 

issue. 

Finally, the security requirements 

include a definitions section. To the 

extent the requirements use a term 

already defined in the DOJ rulemaking, 

CISA’s use of that term in the security 

requirements would carry the same 

meaning. For the purpose of these 

security requirements, CISA includes 

definitions for five terms used 

exclusively in the security 

requirements: 

• Asset. CISA defines the term to 

mean data, personnel, devices, systems, 

and facilities that enable the 

organization to achieve business 

purposes. This definition is derived 

from the CSF version 1.1, which defined 

asset as ‘‘[t]he data, personnel, devices, 

systems, and facilities that enable the 

organization to achieve business 

purposes.’’ 

• Covered data. CISA defines the 

term to mean the two categories of data 

identified by the Order and that DOJ is 

regulating through its rulemaking— 

government-related data or bulk U.S. 

sensitive personal data. 

• Covered system. CISA defines this 

term as a specific type of information 

system that is used to conduct a number 

of activities related to covered data as 

part of a restricted transaction. These 

activities are drawn from a combination 

of the activities in the definition of 

information system in the security 

requirements and the activities in the 

DOJ rulemaking’s definition of access. 

See 28 CFR 202.201. The term means an 

information system used to obtain, read, 

copy, decrypt, edit, divert, release, 

affect, alter the state of, view, receive, 

collect, process, maintain, use, share, 

disseminate, or dispose of (collectively, 

‘‘interact with’’) covered data as part of 

a restricted transaction, regardless of 

whether the data is encrypted, 

anonymized, pseudonymized, or deidentified. ‘‘Covered system’’ does not 

include an information system (e.g., an 

end user workstation) that has the 

ability to view or read sensitive personal 

data (other than sensitive personal data 

that constitutes government-related 

data) but does not ordinarily interact 

with such data in bulk form. 

• Information system. CISA defines 

this term consistent with the definition 

in the Paperwork Reduction Act (PRA), 

44 U.S.C. 3502.40 The term means a 

discrete set of information resources 

organized for the collection, processing, 

maintenance, use, sharing, 

dissemination, or disposition of 

information. 

• Network. CISA defines this term, 

which CISA developed consistent with 

the definition of the term in NIST 

Special Publication 800–171 rev. 3, 

Protecting Controlled Unclassified 

Information in Nonfederal Systems and 

Organizations. The term would mean a 

system of interconnected components, 

which may include routers, hubs, 

cabling, telecommunications 

controllers, key distribution centers, and 

technical control devices. 

The publication of the finalized 

security requirements for restricted 

transactions pursuant to Executive 

Order (E.O.) 14117, ‘‘Preventing Access 

to Americans’ Bulk Sensitive Personal 

Data and United States GovernmentRelated Data by Countries of Concern’’ 

can be found on CISA’s website: https:// 

www.cisa.gov/resources-tools/resources/ 

EO-14117-security-requirements. The 

Director of CISA, Jennie M. Easterly, has 

delegated the authority to approve and 

electronically sign this document to 

Nitin Natarajan, who is the Deputy 

Director of CISA, for purposes of 

publication in the Federal Register. 

Nitin Natarajan, 

Deputy Director, Cybersecurity and 

Infrastructure Security Agency, Department 

of Homeland Security. 

[FR Doc. 2024–31479 Filed 1–3–25; 8:45 am] 

BILLING CODE 9111–LF–P 

DEPARTMENT OF HOUSING AND 

URBAN DEVELOPMENT 

[Docket No. FR–7080–C–64] 

30-Day Notice of Proposed Information 

Collection: Application for the 

Community Development Block Grant 

(ICDBG) Program for Indian Tribes and 

Alaska Native Villages; Correction; 

OMB Control No.: 2577–0191 

AGENCY: Office of Policy Development 

and Research, Chief Data Officer, HUD. 


lotter on DSK11XQN23PROD with NOTICES1