Rule2023-27102
Cyber Risk Management
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
December 11, 2023
Effective
January 1, 2025
Issuing agencies
Farm Credit Administration
Abstract
The Farm Credit Administration (FCA, we, or our) rescinds and revises its regulations to reflect developments in cyber risk and continuously evolving business practices. We rename the regulations "Cyber Risk Management." The final rule requires each Farm Credit System (System or FCS) institution to implement a comprehensive, written cyber risk management program consistent with the size, risk profile, and complexity of the institution's operations.
Full Text
<html>
<head>
<title>Federal Register, Volume 88 Issue 236 (Monday, December 11, 2023)</title>
</head>
<body><pre>
[Federal Register Volume 88, Number 236 (Monday, December 11, 2023)]
[Rules and Regulations]
[Pages 85825-85833]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2023-27102]
=======================================================================
-----------------------------------------------------------------------
FARM CREDIT ADMINISTRATION
12 CFR Part 609
RIN 3052-AD53
Cyber Risk Management
AGENCY: Farm Credit Administration.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: The Farm Credit Administration (FCA, we, or our) rescinds and
revises its regulations to reflect developments in cyber risk and
continuously evolving business practices. We rename the regulations
``Cyber Risk Management.'' The final rule requires each Farm Credit
System (System or FCS) institution to implement a comprehensive,
written cyber risk management program consistent with the size, risk
profile, and complexity of the institution's operations.
DATES: This regulation is effective January 1, 2025.
FOR FURTHER INFORMATION CONTACT:
Technical information: Dr. Ira D. Marshall, Senior Policy Analyst,
Office of Regulatory Policy, Farm Credit Administration, McLean, VA
22102-5090, (703) 883-4414, TTY (703) 883-4056;
or
Legal information: Jane Virga, Assistant General Counsel, Office of
General Counsel, Farm Credit Administration, McLean, VA 22102-5090,
(703) 883-4020, TTY (703) 883-4056.
SUPPLEMENTARY INFORMATION:
I. Objectives
The objectives of this final rule are to:
<bullet> Delete references to the requirements of ``Electronic
Signatures in Global and National Commerce Act'' (E-SIGN) (Pub. L. 106-
229), which became effective on October 1, 2000. E-SIGN is a statutory
requirement that governs electronic transactions relating to the
conduct of electronic business, consumer, or commercial affairs. E-SIGN
continues to apply to System institutions as statutory requirements.
<bullet> Revise part 609 to codify our existing expectations, as
well as ensure the relevance and adequacy of risk management practices,
corporate governance, and internal control systems at System
institutions conducting business in an electronic environment.
<bullet> Require each System institution to develop and implement a
comprehensive, written cyber risk management program consistent with
the size, risk profile, and complexity of the institution's operations.
II. Background
The regulations at 12 CFR part 609 were enacted in 2002 and
repeated the statutory requirements of E-SIGN. Our existing
information-technology (IT)-related regulations primarily focus on E-
commerce terminology and the concept of conducting business in an E-
commerce environment. Since then, there have been significant changes
and advancements in IT and the System's use of technology to conduct
business.
We are responsible, as the System's regulator, to ensure the
System's use of IT is consistent with safe and sound operations and
complies with the law.
We amend the current E-commerce regulations at part 609 to revise
the rules for a broader cyber risk focus and to codify our existing
expectations on risk management practices, corporate governance, and
internal control systems for conducting business in an electronic
environment. The final regulations set forth core principles that serve
as the foundation for creating a comprehensive cyber risk management
program and framework.
Key definitions include: \1\
---------------------------------------------------------------------------
\1\ FFIEC IT Examination Handbook InfoBase--Glossary, <a href="https://www.ithandbook.ffiec.gov/glossary">https://www.ithandbook.ffiec.gov/glossary</a>.
---------------------------------------------------------------------------
<bullet> Information security refers to the policies, procedures,
and technologies used to protect information and information systems
from unauthorized access, use, disclosure, disruption, modification, or
destruction.
<bullet> Cyber security is the process of protecting information
assets and data by preventing, detecting, and responding to cyber
attacks.
<bullet> Cyber risk is any risk associated with financial loss,
disruption, or damage to the reputation of an organization due to the
failure or unauthorized or erroneous use of its information systems.
A System institution's policies, procedures, and internal controls
that manage cyber risk must incorporate information security and cyber
security concepts and sound business practices.
[[Page 85826]]
Appropriate governance and controls over cyber risk can help guide
future decision-making about how to mitigate risk while focusing on an
institution's strategic goals and objectives.
These cyber risk management regulations allow System institutions
to innovate. We recognize that innovation in the System may create
different opportunities, challenges, and risks for different
institutions. Accordingly, we considered the needs and constraints of
all institutions, regardless of size, risk profile, or complexity. We
understand cyber risk management programs will vary and there is no
one-size-fits-all approach; however, these cyber risk management
regulations provide the flexibility for System institutions to innovate
based on the institution's unique needs and operations.
System institutions can mitigate challenges and risks through good
governance and effective risk management. Strong governance principles
and appropriate risk management practices, implemented through sound
internal controls, can safeguard against a variety of risks, including
those stemming from adopting new technology. However, an institution
should never sacrifice safety and soundness for innovation.
These cyber risk management regulations encourage System
institutions to implement and develop effective and sound cyber risk
management program solutions. We continually communicate these
expectations to System institutions in our role as examiner of the
System. This rule also considers the role our examinations play in
ensuring safe and sound operations of the System.
III. Comments and Our Responses
We received 26 comment letters, all of which came from System
institutions or persons affiliated with the System, except one that
came from the Independent Community Bankers of America (ICBA). Of the
comment letters received, one came from the Farm Credit Council
(Council), acting on behalf of its membership. Each of the four Farm
Credit banks submitted a letter, as did the Federal Agricultural
Mortgage Corporation (Farmer Mac). Many comment letters from System
associations expressed support for the Council's letter, with several
raising specific issues. The following is a description of the issues
raised and our responses.
A. General Comments
Principles-Based Approach
Most of the commenters stated that the proposed rule does not align
with a principles-based approach to rule-making. As discussed below, we
disagree. As an initial matter, we considered that System institutions
vary dramatically in terms of size, risk profile, and complexity of
business model. Accordingly, during the rule-making process, we focus
on the right blend of principles and specific requirements to achieve a
safe and sound System.
Principles-based regulations set forth broad objectives and goals
for which System institutions should strive. Thus, this rule does not
address every circumstance. The rule attempts to balance an
institution's need to develop a cyber risk management program against
our mission to promote and protect the safety and soundness of each
institution and the System, as a whole. The rule provides flexibility,
where appropriate, and establishes minimum standards, where needed.
Thus, the rule provides System institutions with parameters and our
expectations for the System to establish, among other things, internal
controls consistent with a principles-based rule. The regulation
provides flexibility for both the FCA and the System to adapt to market
developments and evolving technology. We believe we have achieved the
correct regulatory balance.
While commenting on this principles-based approach, one institution
asked us to minimize examination inconsistency by recognizing and
clarifying the appropriate role of management and the board of
directors in selecting the appropriate cyber security approach from
among the many that may satisfy the overarching principles of the rule.
An institution has the flexibility to determine its risk profile and
identify appropriate cyber risk management practices. The institution
should document its analysis to provide examiners with an opportunity
to assess its choices.
This approach acknowledges that there is more than one way to
comply with the regulation. We will take a risk-based approach, and not
a one-size-fits-all approach, in our examination of each System
institution.
Ambiguous, Unclear, or Unfeasible
Several institutions commented that portions of the proposed
regulation are unclear or unfeasible. In response, we reviewed the
proposed regulation in its entirety to ensure it is written in
accordance with plain language principles and to clarify any
potentially confusing language.
The rule requires System institutions to develop a program
consistent with the size, risk profile, and complexity of the
institution's operations. This provides flexibility, consistent with a
principles-based approach, to allow each System institution to
customize its cyber security program for its particular risk
environment. However, to address commenters' concerns, we are adding
the term ``risk profile,'' as appropriate throughout the preamble and
regulation, to clarify that an institution's program must be based on
size, complexity, and risk. Adding the term ``risk profile'' will allow
each System institution to customize its cyber risk management program
for its unique risk environment.
User Experience
One commenter stated that perfect security is neither possible nor
desirable, and there is often a fundamental tradeoff between security
and convenience (or user experience). The commenter further stated that
while clients appropriately value the security of their information,
they are often willing to accept some security risk in exchange for a
better user experience.
Although convenience and user experience could compromise security,
we believe a risk assessment, including a determination to mitigate or
accept certain risks, is critical to an institution's cyber risk
management program. Thus, an institution must document why it accepts,
transfers, or mitigates the risk. The board has a fiduciary
responsibility to ensure a safe and sound operating environment. If the
board chooses to accept a risk for convenience or customer experience,
the board's approval must be documented.
Leveraging Modern Frameworks
Several commenters suggested the proposed regulation should
leverage standard frameworks based on industry standards (e.g., Federal
Financial Institutions Examination Council (FFIEC) or National
Institute of Standards and Technology (NIST)), which would allow the
regulation to remain relevant for rapidly changing technologies.
We agree. As this is a principles-based regulation, in part,
linking to standard frameworks will encourage innovation,
implementation, and compliance. Referencing industry standards promotes
conformity with the cyber risk management rule as institutions innovate
and apply rapidly evolving technology and attendant controls.
[[Page 85827]]
We also direct System institutions to the June 27, 2017,
Informational Memorandum (IM) on ``Reporting Security Incidents and
Business Continuity Events to FCA.'' This guidance will assist System
institutions to identify and define an incident under 12 CFR
609.930(c)(3)(i) and help determine reporting requirements. The Office
of Examination periodically releases informational memoranda to update
the System on expectations. We anticipate the continued issuance of
such guidance documents in the future, despite the publication of this
rule.
Requests To Define Key Terms
Several commenters requested that we define key terms, such as
``effective,'' ``ensure,'' or ``appropriate.'' However, as this is a
principles-based rule, we will not define such terms here.
FCA and the institutions it regulates must interpret these terms
considering the institution's unique circumstances. What may be
``effective'' or ``appropriate'' at one institution or at one time may
not be ``effective'' or ``appropriate'' at another institution with a
different risk profile, where there is a different size or complexity,
or at a different time. FCA's decision to not define the terms allows
an institution to determine what is effective or appropriate at its
institution. During the supervisory and examination process, we will
apply the regulatory requirements based on the institution's current
circumstances, which is consistent with a principles-based rule.
Moreover, these terms currently are used without definition throughout
our regulations, and we do not believe it appropriate to define the
terms in this regulation.
FCS institutions may want to refer to the NIST Computer Security
Resource Center's Glossary \2\ and FFIEC IT Examination Handbook
InfoBase--Glossary \3\ as additional resources in defining terms. For
further guidance, please refer to our IM dated June 27, 2017, entitled,
``Reporting Security Incidents and Business Continuity Events to FCA,''
for terms like ``Security Event'' and ``Security Incident.''
---------------------------------------------------------------------------
\2\ Glossary [verbar]<radical> CSRC, <a href="https://www.csrc.nist.gov/glossary">https://www.csrc.nist.gov/glossary</a>.
\3\ FFIEC IT Examination Handbook InfoBase--Glossary, <a href="https://www.ithandbook.ffiec.gov/glossary">https://www.ithandbook.ffiec.gov/glossary</a>.
---------------------------------------------------------------------------
Conformity With Other Federal Financial Regulators
The ICBA recommends that we harmonize the proposed regulation and
guidance with that of the other federal financial regulatory agencies
to ensure System institutions operate in a safe and sound manner. In
drafting this regulation, we reviewed the cyber security regulations of
the federal financial regulatory agencies and included some of the
elements of those regulations. We believe the review process was
comprehensive and have been unable to identify any other provisions we
should include. Nevertheless, we refer System institutions to the FFIEC
IT Handbook \4\ and NIST \5\ for additional guidance and as examples of
industry standards.
---------------------------------------------------------------------------
\4\ FFIEC IT Handbook, <a href="https://www.ithandbook.ffiec.gov">https://www.ithandbook.ffiec.gov</a>.
\5\ Cybersecurity [verbar] NIST, <a href="https://www.nist.gov/cybersecurity">https://www.nist.gov/cybersecurity</a>.
---------------------------------------------------------------------------
Reproposing the Proposed Rule
Two System institutions stated that the proposed rule should be
pulled back, reworked, and reproposed in the future to allow for
additional comments. We disagree. FCA has not updated our technology
regulations in years. We believe this updated regulation will help
institutions strengthen their cyber security and cyber risk management
practices. We provide, through this principles-based rule, flexibility
for institutions to develop cyber risk management programs based on
institution size, risk profile, and complexity.
Regulatory Burden
One commenter suggested the proposed rule is excessively burdensome
and inconsistent with modern industry accepted and dynamic cyber
security program standards that System institutions already implemented
as part of their cyber security programs. The commenter further stated
that the proposed rule would adversely impact the ability and
capability of System institutions to establish effective and relevant
cyber security programs. Additionally, the commenter said the language
was prescriptive and vague. The commenter stated that we should defer
to industry standards and not attempt to create competing, duplicative,
and non-conforming regulatory requirements.
We agree, in part, and FCA intends through this rulemaking to
leverage standard frameworks based on industry standards, such as FFIEC
and NIST, as discussed herein. However, consistent with principles-
based rulemaking, we reiterate that an institution must develop a
program consistent with the size, risk profile, and complexity of the
institution's operations. An institution should customize and document
the cyber risk management program for its risk environment.
Examination Approach
Several commenters asked how FCA examiners would examine cyber risk
management programs at System institutions of different sizes and
complexities. Commenters were also concerned the rule does not have
specific definitions and thresholds that may lead to inconsistencies in
examinations.
Examiners will review cyber risk management programs much like
other internal controls programs. There is no one-size-fits-all
approach. We know cyber risk management plans will differ based on an
institution's size, complexity, and risk profile. The rule outlines
items institutions must consider, such as a written cyber risk
management program, documented incident response plan, and documented
risk assessments, which examiners may review as part of the examination
process. We will provide consistency and clarity in our supervision and
regulation of the System as it pertains to, among other things, cyber
risk management.
B. Comments on Specific Provisions
Mitigating Vulnerabilities (Sec. 609.905)
Several commenters recommended that we allow each System
institution to define the term ``vulnerability'' in proposed Sec.
609.905 based on a modern framework and remove the requirement that
``any'' vulnerability must be remediated. They asserted that System
institutions should be allowed to rank and prioritize vulnerabilities
based on their defined risk-based program, including allowing known
unmitigated vulnerabilities to be assessed and addressed based on that
risk assessment. There was also a comment that human capital presents
the greatest risk or vulnerability to an institution.
We do not agree that the regulation should include the suggested
terminology ``based on a modern framework.'' We believe the commenter's
suggested language of ``based on a modern framework'' is vague and
could be misinterpreted to allow a System institution to use any modern
framework, which could lead to further inconsistencies among System
institutions. However, we do agree that an institution should rank and
prioritize vulnerabilities based on its cyber risk management program
and cyber risk assessment. The vulnerability management program should
be commensurate with the size, risk profile, and complexity of the
institution and based on sound industry standards and practices.
[[Page 85828]]
A System institution board should identify and document the
institution's appetite for risk. Then, the board, with management,
should assess the institution's vulnerabilities. Although an
institution cannot mitigate every vulnerability, each System
institution's board must assess the risk of a vulnerability, decide
whether the vulnerability exposes the institution to any undue risk,
and document its analysis and conclusions. In some cases, a System
institution may assess and identify its risk appetite and accept the
risk, which should be documented to allow FCA to examine for safety and
soundness, as well as compliance with law.
Mitigating vulnerabilities involves taking steps to implement
internal controls that reduce risk. Remediation is the act of removing
or eradicating a vulnerability from an IT system. Mitigation, on the
other hand, is creating strategies to minimize the potential threat of
a vulnerability when it cannot be eliminated immediately. Some
vulnerabilities are more difficult to remediate and may require some
time to address.
An institution could refer to the FFIEC IT Handbook or NIST
Cybersecurity Framework for guidance on how to identify, document, and
address a vulnerability within its risk profile.
Privacy and Compliance (Sec. 609.930(a))
Several commenters disagreed with the second sentence in proposed
Sec. 609.930(a), which provided as follows: ``The program must ensure
the security and confidentiality of current, former, and potential
customer and employee information, protect against reasonably
anticipated cyber threats or hazards to the security or integrity of
such information, and protect against unauthorized access to or use of
such information.'' The commenters were concerned that the phrase
``must ensure'' created an unattainable standard as to the security and
confidentiality of information, as any information loss, no matter how
insignificant, would appear to violate the rule as drafted. The
commenters suggested that we revise this language so the program ``must
be designed to protect'' or ``manage the risk'' of protecting the
security and confidentiality of information.
We strongly believe there must be controls in place to protect the
security and confidentiality of information. Thus, we revise the second
sentence of Section 609.930(a) as follows: ``The program must ensure
controls exist to protect the security and confidentiality of current,
former, and potential customer and employee information, protect
against reasonably anticipated cyber threats or hazards to the security
or integrity of such information, and protect against unauthorized
access to or use of such information.'' The revision to the second
sentence of Section 609.930(a) addresses the commenters' concerns and
will ensure that an institution has strong controls in place to protect
the security and confidentiality of information.
Size and Complexity (Sec. 609.930(a))
We received numerous comments suggesting that we clarify
expectations related to ``size and complexity'' in proposed Sec.
609.930(a). There was a concern that a lack of guidance on ``size and
complexity'' will lead to inconsistent expectations of examiners and
place additional regulatory burden on smaller institutions. It was also
suggested that we acknowledge the role of IT service providers to avoid
examination inconsistencies and to reference ``a modern risk management
framework.'' Section 609.930(a) requires, in part, each institution to
implement a comprehensive, written cyber risk management program
consistent with the size, risk profile, and complexity of the
institution's operations.
Consistent with our intent for a principles-based rulemaking, we do
not define ``size and complexity.'' However, to provide clarity, we
include ``risk profile'' and change the phrase to ``size, risk profile,
and complexity.'' We do not believe it appropriate to reference ``a
modern risk management framework.''
An institution must assess its risk profile. The regulation
requires a cyber risk management program to be consistent with size,
risk profile, and complexity of an institution. A smaller institution
may not be required to assess as many risks as or the same types of
risks as a larger institution. However, depending on an institution's
complexity, size, and risk profile, it is possible for a smaller
institution to have a similar cyber risk management plan range as
compared to a larger institution.
Each institution should document its risk-based approach to
establishing a cyber risk management plan and scope.
As noted above, to add clarity in response to the size and
complexity concerns, we revise the first sentence in this section to
insert the phrase ``risk profile'' to help align the regulation with
the requirement of providing strong controls commensurate with an
institution's size and complexity.
Role of Board and Management (Sec. 609.930(b))
One commenter stated that although the heading of proposed Sec.
609.930(b) refers to the role of management, the text of this section
does not appear to contemplate a defined role for management. The
commenter further stated that although management has a significant
role in managing cyber risk, the rule assigns many responsibilities to
an institution's board of directors, with management providing the
services.
We believe that a board of directors must provide appropriate
oversight of management to develop, implement, and maintain a cyber
risk management program consistent with the board's fiduciary duties
and oversight obligations. This section provides that the board must
decide who will do what without FCA specifying or telling them what to
do step-by-step. We do not want to create a prescriptive rule.
For clarity, we modified the language of this section to remove
``and management'' from the heading. This should clarify that the
institution board has oversight responsibility but may delegate day-to-
day tasks to management and other employees, as appropriate.
Timely Remediation (Sec. 609.930(c)(2))
Proposed Sec. 609.930(c)(2) requires institutions to ``perform
timely remediation.'' Several commenters stated the regulation does not
define the term ``timely,'' which could lead to inconsistencies and
misaligned expectations between examiners and institutions. One
commenter recommended we define ``timely'' by directing System
institutions to leverage modern frameworks based on industry standards,
customized for its institution's risk environment, and aligned with its
documented risk-based approach.
This is a principles-based rule. Institutions have an opportunity
to be innovative and develop their own metrics and identify material
matters relevant and specific to their institutions. Metrics will vary
from System institution to System institution depending on risks,
threats, and cyber risk management program.
As to defining ``timely,'' we understand the commenters' concerns.
However, remediation evaluation should begin immediately after the
vulnerability has been identified. The word ``timely'' is intended to
provide institutions some flexibility. A minor vulnerability, depending
on the circumstances presented, may not need to be addressed
immediately, but a
[[Page 85829]]
major vulnerability must be addressed immediately.
Thus, we finalize this section as proposed.
Incident Response Planning (Sec. 609.930(c)(3))
One institution stated that ``incident response planning'' as
required by proposed Sec. 609.930(c)(3) varies greatly by institution
and by incident. The technologies used and available expertise also
vary greatly. The commenter stated that broad-based incident responses
provide the flexibility needed to adapt to constantly changing
technology and threats to technology. The commenter added that
requiring specific incident plan responses to individual potential
threats is both time consuming and ultimately not satisfactory,
especially for new threats that may not be envisioned when the plan is
created. The commenter recommended that the final rule be revised to
allow institutions more flexibility in defining incident response
planning.
We believe that proposed Sec. 609.930(c)(3) included the necessary
components and flexibility for an incident response plan. An
institution should view an incident response plan as the steps that
should be taken when a security incident occurs. Procedures do not need
to be specific to any one type of event and can be written to ensure
the right people are involved in the incident response and the process
remains consistent. Further, we believe incident response plans will
likely need to change over time in response to new threats. Thus, we
revise this section to include language that the documented cyber risk
management program, risk assessments, and incident response plans
should be reviewed and updated periodically, but at least annually, to
address new threats, concerns, and evolving technology. This is
consistent with existing FFIEC, NIST, and FCA guidance.
Detailed Procedures for Security Events (Sec. Sec. 609.930(c)(3)(i)
Through (iii))
Proposed Sec. Sec. 609.930(c)(3)(i) through (iii) require each
institution to document its procedures on forensics, containment, and
business resumption. Several commenters stated that the requirements in
proposed Sec. Sec. 609.930(c)(3)(i) through (iii) are not feasible
because of the lengthy and numerous ways System institutions identify
and contain security events, and later, resume business. The commenters
recommended that we revise this section to focus less on specific
procedures, and more on an adaptable and scalable framework to assess
the nature and scope of an incident, contain the incident, and how to
safely resume business activities. Some commenters stated that an
institution should act in accordance with state and federal law.
We disagree with the commenters' statements. A System institution
must document its procedures for, among other things, ensuring each
employee follows the same protocol for forensics, containment, and
business resumption. Also, documentation will assist with staff
continuity within the institution and can serve as a training tool for
institution employees. Furthermore, FCA examiners must be able to
examine for compliance. Compliance with only state and federal laws is
not appropriate because it does not assess an institution's size,
complexity, and risk profile.
We will finalize this section as proposed.
Board Notice of a Cyber Incident (Sec. 609.930(c)(3)(iv))
One commenter recommended that we modify proposed Sec.
609.930(c)(3)(iv) to permit each institution's board of directors to
determine when it should be notified by management of a cyber incident,
consistent with the board notification protocols in the institution's
approved incident response plan. The commenter suggested revising the
proposal to include an incident escalation matrix that would provide
the board and management with a clear and specific action plan in the
event of a cyber incident and identify when an incident should be
brought to the attention of the board and/or other stakeholders (e.g.,
regulators and law enforcement).
Proposed Sec. 609.930(c)(3)(iv) requires board notice when there
is a cyber incident involving unauthorized access to or use of
sensitive or confidential customer or employee information.
We believe this section already includes an escalation concept, in
that it applies only to sensitive or confidential information. The
section does not apply to all information. We believe that when there
has been a cyber incident involving sensitive or confidential
information, the board must be notified. The board should not be caught
off guard when it comes to hearing about cyber incidents.
After further consideration, we now also include a clause that
requires notification when there is ``unauthorized access to financial
institution information, including proprietary information.'' Financial
institution information must also be protected. An institution must
guard its institution's reputation in every instance.
Reporting an Incident (Sec. 609.930(c)(3)(v))
Proposed Sec. 609.930(c)(3)(v) requires an institution to notify
FCA as soon as possible, or no later than 36 hours after an institution
determines a cyber security incident occurs. A few commenters stated
that incidents can occur in an environment without discovery for longer
than 36 hours. Additionally, one commenter stated that 36 hours will
not allow an institution sufficient time to review evidence and
determine whether a reportable incident has occurred. The commenter
recommended extending the deadline to 72 hours. Another commenter
suggested extending the reporting requirement to four business days
after the date of a materiality determination, rather than the date of
discovery.
The proposed rule requires ``notifying FCA as soon as possible or
no later than 36 hours after the institution determines that an
incident has occurred.'' We believe it reasonable that an institution
be required to notify its regulator as soon as possible and no later
than 36 hours after it identifies such an incident. We do not believe
that a materiality standard should be introduced. Notification does not
require a detailed report with findings and recommendations.
Notification provides us with timely information on a cyber security
incident. This is consistent with the other federal financial
regulatory agencies' requirement promulgated in a joint regulation that
a banking organization notify its primary federal regulator of any
significant security incident as soon as possible and no later than 36
hours after it has been determined that a cyber incident has
occurred.\6\ Thus, we believe the notification requirements of this
section are reasonable and remain unchanged.
---------------------------------------------------------------------------
\6\ See. Computer-Security Incident Notification Requirements
for Banking Organizations and Their Bank Service Providers, 86 FR.
66,424 (November 23, 2021).
---------------------------------------------------------------------------
Former, Current, or Potential Customers (Sec. 609.930(c)(3)(vi))
Some commenters recommended proposed Sec. 609.930(c)(3)(vi) be
amended and revised to provide notice to customers, employees, and
website visitors in accordance with state and federal laws. Another
commenter was concerned that there was no definition of ``customer,''
especially as it relates to potential customers exploring available
loan products online. Another
[[Page 85830]]
commenter was concerned the section was overly broad and vague. Another
commenter recommended deleting this phrase in its entirety.
This section requires institutions to notify former, current, or
potential customers and employees, and known visitors to an
institution's website, of an incident, when warranted, and in
accordance with state and federal laws. For example, notification would
be required when sensitive or confidential information has been
compromised. The section does not define ``known visitor'' or
``potential customer.'' Overall, the commenters are concerned System
institutions will interpret these terms differently.
We do not believe we should change this section as the requirements
are consistent with a principles-based rule. Each System institution
will determine and document what these terms mean. Providing notice,
when warranted, provides flexibility to institutions. Nevertheless, all
confidential information related to ``former, current, or potential
customers and employees and known visitors to a website'' must be
protected. System institutions may not allow others to inappropriately
view or access this information without proper authorization. Our
regulations at part 618 support this conclusion.
Training (Sec. 609.930(c)(4))
Proposed Sec. 609.930(c)(4) requires institutions to ``describe
the plan to train employees, vendors, contractors, and the institution
board to implement the institution's cyber risk program.'' Several
commenters argued that the requirement to train contractors and vendors
is impractical and that many contractors and vendors will simply refuse
to submit to institution-specific training based on their own business
requirements.
As a principles-based rule, this section requires an institution to
describe its plan to train employees, vendors, and contractors.
However, we do not prescribe a particular plan. If an institution does
not provide training, the institution must describe its plan and state
why and what actions it is taking to mitigate the risk of not having
institution-provided training. We require such documentation to enable
FCA examiners to review the training plan.
As to vendors, System institutions should be able to confirm,
either contractually or otherwise, that vendors have some acceptable
level of training, as well as understand sound cyber risk management
practices and protocols. We acknowledge that it is unrealistic for an
institution to train all contractors and vendors.
We finalize this section as proposed.
Third-Party Vendors (Sec. 609.930(c)(5))
Several institutions commented generally that they did not own or
manage any IT systems that they currently use. They stated that these
IT systems may be owned by third-party vendors, technology service
providers, or by another System institution, such as a Farm Credit Bank
that provides services like a third-party service provider.
As to specific comments, one commenter asked that the term
``vendor'' be clarified. Another commenter stated that proposed Sec.
609.930(c)(5)(i) is impractical as it requires an institution to
require its vendors, by contract, to implement appropriate due
diligence in selecting vendors. The commenter provided an example of
its inability to comply with proposed Sec. 609.930(c)(5)(i) when a
vendor may refuse to negotiate its standard terms and conditions, due
to its size and bargaining position.
We also received a comment on proposed Sec. 609.930(c)(5)(iii)
(now Sec. 609.930(c)(5)(iv)) concerning institutions monitoring and
reviewing vendor audits or summaries of test results. The commenter
stated that some vendors will not provide these audits or test results.
The commenter stated that requiring institutions to negotiate the right
to an audit with every vendor will greatly hinder an institution's
choice of vendors. Moreover, for many vendors, this is not practical.
The commenter added that it is not necessary for an institution to
review audits or summaries of test results for a vendor contracted to
provide catering or lawn maintenance services, or other non-IT
contracts. Another commenter suggested a risk-based approach.
A ``vendor'' is a third party and includes third-party service
providers or a System institution providing services to another System
institution. A System institution should assess the risk of using a
vendor, i.e., complete a vendor risk assessment.\7\ Completing a vendor
risk assessment helps an institution understand risks when using vendor
products or services. An institution cannot delegate its due diligence
responsibilities.
---------------------------------------------------------------------------
\7\ A vendor risk assessment is the process of identifying and
evaluating potential risks or hazards associated with a vendor's
operations and products and its potential impact on your
organization. When an institution performs a third-party vendor risk
assessment, it determines the most likely effects of uncertain
events, and then identifies, measures, and prioritizes them.
Potential risks include the accuracy and reliability of operational,
customer, and financial information; security breaches; operation
effectiveness; and legal and regulatory compliance.
---------------------------------------------------------------------------
Conducting a risk assessment is particularly important when a
vendor handles a critical business function, accesses sensitive
customer data, and/or interacts with customers. An institution must
have controls to ensure that the vendor, even if it is another System
institution, has appropriate security in place for IT systems. Whether
a vendor is a System service provider or external service provider, an
institution should never put its trust in any IT service provider
without doing its own due diligence.
An institution has a responsibility to its customers and
shareholders. Accordingly, each association must be aware of the risks,
even if it outsources its IT services. We will hold the institution
accountable for ensuring it has appropriate controls to ensure the
continued safety and soundness of the institution. An institution must
know its own complexity, including the role of technology service
providers. Although services may be outsourced, an institution cannot
delegate or shift the requirement for due diligence or accountability
from the institution's board and management to service providers.
Institutions are required to ensure service providers/vendors are
providing adequate and effective services.
Nevertheless, we agree that negotiating the right to audit need not
apply to every vendor. Accordingly, to address these concerns we added
a new paragraph (iii), requiring institutions to conduct a vendor risk
assessment on all vendors.
An institution will be able to assess the level of detail needed
for their vendor risk assessment. For example, a vendor risk assessment
of a catering vendor may need a statement indicating very little risk
because of the nature of the service and type of information provided
to the vendor. A vendor risk assessment for IT services would require
an institution evaluate cyber risk as part of its vendor management
process. A vendor risk assessment helps an institution understand the
risks that exist when it uses vendors' products or services. Conducting
a vendor risk assessment is particularly important when a vendor
handles a critical business function, accesses sensitive customer data,
or interacts with customers.
An institution must document the vendor risk assessment and may
address whether a large vendor already has appropriate security
measures. This way, an institution can determine if it
[[Page 85831]]
will accept, mitigate, transfer, or avoid the risk. It is possible that
a vendor risk assessment could address the reputation of a vendor and
conclude that there is a low risk.
Just because a smaller or less complex institution may rely on its
funding bank for technology services does not mean that institution
would not be required to have a cyber risk management program. If a
cyber event occurred at a small or less complex institution that relies
on the bank for services, we would still expect the institution to work
with the bank to follow a cyber security framework (e.g., identify,
protect, detect, respond, and recover).
Additionally, to be more consistent with a principles-based
approach, we revise proposed Sec. 609.930(c)(4)(iii) (now Sec.
609.930(c)(4)(iv)) to identify what an institution may monitor, rather
than prescribing what an institution must monitor. This would provide
an option for the institution to receive some type of report, audit, or
summary. The institution must exercise appropriate due diligence in
selecting any vendor. Any such assessment must include appropriate
documentation for examiner review.
Internal Controls Frequency (Sec. 609.930(c)(6)(i))
A few commenters stated that proposed Sec. 609.930(c)(6)(i), which
requires an institution to determine the frequency and nature of
internal controls testing, provides no substantive guidance on the
frequency and nature of internal controls testing. No recommendation
was provided.
As this is a principles-based rule, we provide institutions the
autonomy to decide the frequency and nature of their internal control
tests. Based on the risk assessment, each institution should decide the
frequency and nature of internal control tests. If we were to mandate
every element, this rule would no longer be principles-based, as
appropriate, but a prescriptive rule. The type and amount of risk an
institution faces should determine the nature and frequency of testing.
An institution may want to consult the FFIEC IT Handbook, NIST, and FCA
guidance documents.
We finalize this section as proposed.
Independent Third-Party Testing (Sec. 609.930(c)(6)(ii))
A commenter stated that proposed Sec. 609.930(c)(6)(ii) requires
an independent party to perform testing but does not address the size
and complexity of the institutions when performing testing. The
commenter asserted that, to minimize examination inconsistencies, the
rule should address the unique service provider relationship and
structure between some System entities.
We disagree. The regulation provides that an independent party can
include institution staff who are independent of the cyber risk
management program. This will allow an institution, regardless of size,
risk profile, or complexity, to conduct its own testing and due
diligence, which the institution should document. Institution
documentation will promote consistency in the examination process.
Reasonable Assurances and Material Deficiencies (Sec.
609.930(c)(6)(iii))
Several commenters stated that there is no indication how to
measure the term ``material.'' One commenter added that ``reasonable
assurances'' seem to refer to an auditor's degree of satisfaction that
the evidence obtained during the audit supports the assertions in the
financial statements. The commenter added ``reasonable assurances'' do
not include ``remediation'' in the definition, as a situation with
material deficiencies (situations requiring remediation) would not
allow an auditor to arrive at a level of reasonable assurances. The
commenter suggested separating this section into a testing element and
a remediation element. The commenter stated that a testing element
related to ``reasonable assurances'' would assess the cyber
capabilities of the organization to detect and prevent cyber incidents
of a material nature, while a remediation element related to incident
responses would assess the effectiveness of timely remediation of cyber
incidents that have a material impact on the entity.
Proposed Sec. 609.930(c)(6)(iii) indicates that ``internal systems
and controls must provide reasonable assurances that System
institutions will prevent, detect, and remediate material deficiencies
on a timely basis.''
``Material'' in this context means to exclude small or de minimis
deficiencies. Thus, System institutions may interpret ``material'' to
mean anything that could potentially impact the safety and soundness of
an institution or the accuracy of financial reporting. Internal
controls should provide reasonable assurances that information and IT
is reliable, accurate, and timely.
Internal controls are intended to prevent errors and
irregularities, identify problems, and ensure corrective action.
Internal controls can be expected to provide only reasonable, not
absolute, assurances to an institution's management and board.
We continue to believe internal controls must provide reasonable
assurances to prevent, detect, and remediate material deficiencies. We
do not believe any change to the proposal is necessary. The regulation,
as proposed, is clear on the need for adequate internal controls.
Privacy Framework (Sec. 609.930(d))
With respect to proposed Sec. 609.930(d), commenters were
concerned that this section does not provide expectations on the
privacy framework, or other legal or compliance requirements. This
section requires, in part, that an institution ``consider privacy and
other legal compliance issues.''
We have decided not to specify a uniform privacy framework. Privacy
frameworks can vary from state-to-state and from institution-to-
institution. System institutions may consult the privacy framework
established by NIST at <a href="https://www.nist.gov/privacy-framework/privacy-framework">https://www.nist.gov/privacy-framework/privacy-framework</a>.
We finalize this section as proposed.
Reporting to the Board (Sec. 609.930(e))
As proposed, Sec. 609.930(e) requires an institution to ``report
quarterly to its board or an appropriate committee.'' One commenter
suggested that quarterly reporting may not be the correct frequency to
report to an institution's Board.
We concur with the suggestion that quarterly reporting may not be
the correct reporting frequency. We revise this section to provide,
``[a]t a minimum, each institution must report quarterly to its board
or an appropriate committee of the board.'' This will ensure that there
is at least quarterly reporting to the board. Depending on the risk or
information that must be communicated to the board, the frequency of
reporting may need to increase, and conversely, a quarterly report to
the board may be brief, as appropriate and in accordance with the
institution's situation. The institution should have appropriate
documentation to support the frequency of board reporting.
Cyber Risk Management Metrics (Sec. 609.930(e))
Section 609.930(e), as proposed, requires the report to the board
to ``contain material matters and metrics related to the institution's
cyber risk management program, including specific risks and threats.''
One commenter was concerned that the section does not provide a
framework or expectation for the metrics presented to the board, or
consider institutions
[[Page 85832]]
providing cyber metrics through another avenue, such as an entity-wide
risk management report. The commenter believed that their concerns
could lead to inconsistencies and misaligned expectations between
examiners and institutions. The commenter suggested the rule should
refer System institutions to modern frameworks based on industry
standards, customized for its institution's risk environment, and
aligned with its documented risk-based approach.
Upon further review, we delete the phrase ``and metrics'' from the
final rule, but we decline to reference modern frameworks based on
industry standards. Removing ``metrics'' should alleviate confusion
from the proposed language. We continue to believe management should
timely report on cyber risk management practices to the board or a
committee of the board.
Technology Budget (Sec. 609.935(b))
One commenter stated that requiring an institution, per proposed
Sec. 609.935(b), to detail the technology budget in the technology
plan could lead to unnecessary duplication. Some institutions present
their technology budget to their boards with the overall operating
expense budget. Another commenter objected to the requirement on how
and when the information is to be presented.
We are not revising the proposed language. We believe there is
little to no burden for institutions to include the technology budgets
in the overall operating expense budgets, even if duplicative to other
reports the boards might receive. Having a separate technology budget
could benefit the board of directors by identifying the expenses
incurred within the technology area. A separate technology budget is
especially important as money spent in the technology area helps keep
systems secure and adds more transparency to the technology area.
Business planning is very important as institutions identify specific
areas that should be reviewed, assessed, and evaluated. Board and
management can use the technology budget to initiate discussions on
spending for cyber risk management.
Identify and Assess Business Risk (Sec. 609.935(c))
One commenter stated proposed Sec. 609.935(c) is unclear. Proposed
Sec. 609.935(c) requires institutions to identify and assess the
business risk of proposed technology changes and assess the adequacy of
the institution's cyber risk program. The commenter did not know
whether the requirement in proposed Sec. 609.935(c) is intended to
assess the adequacy of the program as a whole or solely assess the
proposed technology changes. No recommendation was provided.
To alleviate any confusion, we modify this section, so that the
plan ``[i]dentifies and assesses the adequacy of the institution's
entire cyber risk management program, including proposed technology
changes.''
Records Retention (Sec. 609.945)
Several commenters stated that the proposed rule does not provide
guidance on maintaining electronic records. Proposed Sec. 609.945
requires ``records stored electronically must be accurate, accessible,
and reproducible for later reference.'' The commenters stated that this
section is silent on the scope and extent of the records and does not
consider the institutions' data retention policies. The commenters
recommended that we revise the rule to refer System institutions to
modern frameworks based on industry standards, which would be
customized for the institution's risk environment when defining the
scope and extent of its electronic records retention program.
We are not revising the proposed language. This is the same
language from the prior regulation on E-SIGN. This section will
continue to hold institutions accountable for records retention in
general. Institutions are still required to comply with E-SIGN, which
is a statutory provision. Our existing E-SIGN regulations were
educational and a reminder to institutions of their applicability.
As this is not a prescriptive rule, we have decided not to impose
specific records retention schedules here. System institutions must
continue to maintain their records to document their business decisions
and to allow examiners to review such documents. Moreover, System
institutions must have records retention programs that comply with
their respective state and federal laws.
IV. Regulatory Analysis
A. Regulatory Flexibility Act
Pursuant to section 605(b) of the Regulatory Flexibility Act (5
U.S.C. 601 et seq.), FCA hereby certifies that the Cyber Risk
Management final rule will not have a significant economic impact on a
substantial number of small entities. Each of the banks in the FCS,
considered together with its affiliated associations, has assets and
annual income more than the amounts that would qualify them as small
entities. Therefore, FCS institutions are not ``small entities'' as
defined in the Regulatory Flexibility Act.
Under the provisions of the Congressional Review Act (5 U.S.C. 801
et seq.), the Office of Management and Budget's Office of Information
and Regulatory Affairs has determined that this final rule is not a
``major rule'' as the term is defined at 5 U.S.C. 804(2).
List of Subjects in 12 CFR Part 609
Agriculture, Banks, Banking, Electronic commerce, Reporting and
recordkeeping requirements, Rural areas.
0
For the reasons stated in the preamble, revise part 609 of chapter VI,
title 12 of the Code of Federal Regulations to read as follows:
PART 609--CYBER RISK MANAGEMENT
Subpart A--General Rules
Sec.
609.905 In general.
Subpart B--Standards for Boards and Management
Sec.
609.930 Cyber risk management.
609.935 Business planning.
609.945 Records retention.
Authority: Sec. 5.9 of the Farm Credit Act (12 U.S.C. 2243); 5
U.S.C. 301; Pub. L. 106-229 (114 Stat. 464).
Subpart A--General Rules
Sec. 609.905 In general.
Farm Credit System (System) institutions must engage in appropriate
risk management practices to ensure safety and soundness of their
operations. A System institution's board and management must maintain
and document effective policies, procedures, and controls to mitigate
cyber risks. This includes establishing an appropriate vulnerability
management program to monitor cyber threats, mitigate any known
vulnerabilities, and establish appropriate reporting mechanisms to the
institution's board and the Farm Credit Administration (FCA). The
vulnerability management programs should be commensurate with the size,
risk profile, and complexity of the institution and based on sound
industry standards and practices.
Subpart B--Standards for Boards and Management
Sec. 609.930 Cyber risk management.
(a) Cyber risk management program. Each System institution must
implement a comprehensive, written cyber risk management program
consistent with the size, risk profile,
[[Page 85833]]
and complexity of the institution's operations. The program must ensure
controls exist to protect the security and confidentiality of current,
former, and potential customer and employee information, protect
against reasonably anticipated cyber threats or hazards to the security
or integrity of such information, and protect against unauthorized
access to or use of such information.
(b) Role of the board. Each year, the board of directors of each
System institution or an appropriate committee of the board must:
(1) Approve a written cyber risk program. The program must be
consistent with industry standards to ensure the institution's safety
and soundness and compliance with law and regulations;
(2) Oversee the development, implementation, and maintenance of the
institution's cyber risk program; and
(3) Determine necessary expertise for executing the cyber risk
management plan and, where practical, delegate day-to-day
responsibilities to management and employees.
(c) Cyber risk program. Each institution's cyber risk program must,
at a minimum:
(1) Include an annual risk assessment of the internal and external
factors likely to affect the institution. The risk assessment, at a
minimum, must:
(i) Identify and assess internal and external factors that could
result in unauthorized disclosure, misuse, alteration, or destruction
of current, former, and potential customer and employee information or
information systems; and
(ii) Assess the sufficiency of policies, procedures, internal
controls, and other practices in place to mitigate risks.
(2) Identify systems and software vulnerabilities, prioritize the
vulnerabilities and the affected systems based on risk, and perform
timely remediation. The particular security measures an institution
adopts will depend upon the size, risk profile, and complexity of the
institution's operations and activities.
(3) Maintain an incident response plan that contains procedures the
institution must implement when it suspects or detects unauthorized
access to current, former, or potential customer, employee, or other
sensitive or confidential information. An institution's incident
response plan must be reviewed and updated periodically, but at least
annually, to address new threats, concerns, and evolving technology.
The incident response plan must contain procedures for:
(i) Assessing the nature and scope of an incident, and identifying
what information systems and types of information have been accessed or
misused;
(ii) Acting to contain the incident while preserving records and
other evidence;
(iii) Resuming business activities during intrusion response;
(iv) Notifying the institution's board of directors when the
institution learns of an incident involving unauthorized access to or
use of sensitive or confidential customer, and/or employee information,
or unauthorized access to financial institution information including
proprietary information;
(v) Notifying FCA as soon as possible or no later than 36 hours
after the institution determines that an incident has occurred; and
(vi) Notifying former, current, or potential customers and
employees and known visitors to your website of an incident when
warranted, and in accordance with state and federal laws.
(4) Describe the plan to train employees, vendors, contractors, and
the institution board to implement the institution's cyber risk
program.
(5) Include policies for vendor management and oversight. Each
institution, at a minimum, must:
(i) Exercise appropriate due diligence in selecting vendors;
(ii) Negotiate contract provisions, when feasible, that facilitate
effective risk management and oversight and specify the expectations
and obligations of both parties;
(iii) Conduct a vendor risk assessment on all vendors; and
(iv) Monitor its IT and cyber risk management related vendors to
ensure they have satisfied agreed upon expectations and deliverables.
Monitoring may include reviewing audits, summaries of test results, or
other equivalent evaluations of its vendors.
(6) Maintain robust internal controls by regularly testing the key
controls, systems, and procedures of the cyber risk management program.
(i) The frequency and nature of such tests are to be determined by
the institution's risk assessment.
(ii) Tests must be conducted or reviewed by independent third
parties or staff independent of those who develop or maintain the cyber
risk management program.
(iii) Internal systems and controls must provide reasonable
assurances that System institutions will prevent, detect, and remediate
material deficiencies on a timely basis.
(d) Privacy. Institutions must consider privacy and other legal
compliance issues, including but not limited to, the privacy and
security of System institution information; current, former, and
potential borrower information; and employee information, as well as
compliance with statutory requirements for the use of electronic media.
(e) Board reporting requirements. At a minimum, each institution
must report quarterly to its board or an appropriate committee of the
board. The report must contain material matters related to the
institution's cyber risk management program, including specific risks
and threats.
Sec. 609.935 Business planning.
The annually approved business plan required under subpart J of
part 618 of this chapter, and Sec. 652.60 of this chapter for System
institutions and the Federal Agricultural Mortgage Corporation,
respectively, must include a technology plan that, at a minimum:
(a) Describes the institution's intended technology goals,
performance measures, and objectives;
(b) Details the technology budget;
(c) Identifies and assesses the adequacy of the institution's
entire cyber risk management program, including proposed technology
changes;
(d) Describes how the institution's technology and security support
the current and planned business operations; and
(e) Reviews internal and external technology factors likely to
affect the institution during the planning period.
Sec. 609.945 Records retention.
Records stored electronically must be accurate, accessible, and
reproducible for later reference.
Dated: December 6, 2023.
Ashley Waldron,
Secretary, Farm Credit Administration.
[FR Doc. 2023-27102 Filed 12-8-23; 8:45 am]
BILLING CODE 6705-01-P
</pre></body>
</html>Indexed from Federal Register on December 11, 2023.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.