Introduction
Federal banking regulators routinely flag security risk assessments during examinations—and for good reason. Financial institutions face breach costs averaging $6.08 million, 22% higher than the global average across all industries.
An information security risk assessment is a structured process banks use to identify, evaluate, and prioritize threats to their IT systems, customer data, and financial infrastructure. Done correctly, it's a strategic tool. Treated as a compliance checkbox, it consistently leaves the most damaging risks unaddressed.
TL;DR
- Identifies what could go wrong, how likely it is, and what the impact would be—covering systems, processes, vendors, and people
- Mandated by FFIEC, FDIC, OCC, and NCUA through GLBA Safeguards Rule requirements
- Follows a repeatable cycle: scope, asset inventory, threat mapping, risk scoring, remediation, and ongoing monitoring
- Draws on internal controls, third-party relationships, access management, and incident response readiness
- Banks that treat it as a checkbox exercise consistently miss the risks that cause the most damage
What Is an Information Security Risk Assessment for Banks?
A bank information security risk assessment is a systematic evaluation of threats, vulnerabilities, and controls across an institution's IT environment—designed to produce a prioritized view of risk that supports both security decisions and regulatory compliance.
Three Core Questions Every Assessment Must Answer
Every effective assessment answers:
- What could go wrong? Identify potential security incidents across all technology assets
- How likely is exploitation? Evaluate probability based on the current threat landscape and existing controls
- What would the impact be? Quantify financial, operational, reputational, and regulatory consequences
This process differs from adjacent activities. A penetration test simulates technical exploits, an IT audit verifies control effectiveness, and a BSA/AML risk assessment focuses on financial crimes. The information security risk assessment is broader—examining the entire technology ecosystem to anticipate future threats rather than validate past ones.
Comprehensive Scope Across the IT Ecosystem
The assessment covers:
- Core banking platforms
- Digital and mobile banking applications
- Cloud services and APIs
- Third-party fintech integrations
- Employee endpoints
- Data storage environments
Many community banks and fintech-bank partnerships lack the in-house CRO or CISO capacity to run this process end-to-end. Fraxtional's fractional compliance leadership model addresses this directly, providing director-level CRO and CISO oversight without the cost or commitment of a full-time hire.
Why Banks Cannot Afford to Skip This Process
Regulatory Exposure Is Real and Enforceable
Virtually every major U.S. banking regulator—FFIEC, FDIC, OCC, NCUA, NYDFS—requires a formal information security program grounded in documented risk assessment. Banks that cannot produce one during an examination face enforcement actions, consent orders, and reputational damage.
Recent enforcement actions illustrate exactly what's at stake:
- The Federal Reserve cited Evolve Bank & Trust (June 2024) for failures in risk management frameworks covering fintech partnerships, including information security deficiencies.
- The OCC ordered Blue Ridge Bank to implement an acceptable written program to assess and manage IT activities through third-party relationships.
Operational Risk: Financial Services Is the Top Target
The financial services sector consistently ranks among the highest-targeted industries for cyberattacks. According to the 2025 Verizon Data Breach Investigations Report, the sector experienced 3,336 incidents with 927 resulting in confirmed data disclosure. Financial services is also the top target for Denial of Service attacks, accounting for 35% of such incidents.
Many of these incidents trace back to vulnerabilities a proper risk assessment would have caught: unpatched systems, misconfigured access controls, and overprivileged user accounts that attackers exploit before anyone notices.
Strategic Exposure for BaaS and Sponsor Banks
Banks sponsoring fintechs or operating Banking-as-a-Service (BaaS) programs face heightened regulatory scrutiny. The FDIC issued a consent order against Thread Bank in May 2024, requiring updates to the Enterprise Risk Management Framework specifically around BaaS and fintech partners. Without one that covers third-party and embedded finance partners, BaaS programs are a liability waiting to surface in the next examination cycle.
Key Regulatory Requirements Banks Must Satisfy
GLBA Safeguards Rule: The Baseline Requirement
Under the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule (16 CFR Part 314), financial institutions must implement a written information security program that includes:
- Regular risk assessments evaluating internal and external threats
- Designated personnel with accountability for the program
- Technical safeguards commensurate with identified risks
- Oversight of service providers
- Notification to the FTC within 30 days for breaches affecting 500+ consumers
This applies to banks, credit unions, and non-bank financial institutions overseen by the FTC.
FFIEC IT Examination Handbook: The Operational Standard
The FFIEC Information Security Booklet (September 2016) outlines what examiners look for: how risk is identified, how controls are selected and tested, how vendors are managed. While not a regulation itself, it's the standard examiners apply in every federal banking examination.
Important update: The FFIEC Cybersecurity Assessment Tool (CAT) was officially retired on August 31, 2025. Institutions should now align with NIST Cybersecurity Framework 2.0, CISA Cybersecurity Performance Goals, or the Cyber Risk Institute (CRI) Profile.
Regulator-Specific Requirements
FDIC (Appendix B to Part 364):
- Active threat monitoring and incident response programs
- Documentation of unauthorized access detection and response procedures
OCC (12 CFR Part 30):
- Operational resilience standards
- Vendor oversight and control frameworks, per the Interagency Guidelines Establishing Information Security Standards
NCUA (12 CFR Part 748):
- 72-hour incident reporting for reportable cyber incidents (effective September 1, 2023)
- Risk assessment requirements in Appendix A
NYDFS 23 NYCRR 500:
- Annual certification of compliance
- Periodic risk assessments informing program design (Section 500.9)
- 72-hour incident reporting for covered entities (Section 500.17(a))
NIST SP 800-30: The Process Framework
NIST Special Publication 800-30 Revision 1 is the most widely accepted methodology for conducting risk assessments. It organizes the process into four continuous phases:
- Prepare for the assessment
- Conduct the assessment
- Communicate results
- Maintain the assessment over time
Financial regulators accept this as a structured, defensible methodology. Many banks pair it with NIST CSF or the CRI Profile to satisfy both process rigor and maturity benchmarking.
The Multi-Framework Challenge
Banks regulated by multiple agencies — for example, a national bank with NYDFS obligations — must map assessments to overlapping requirements. The CRI Profile, developed specifically for financial services, consolidates requirements from FFIEC, GLBA, and NYDFS into a single assessment structure to reduce duplication.
The table below maps the core requirements across regulators at a glance:
| Source | Written Risk Assessment | Vendor Oversight | Incident Reporting | Board Reporting |
|---|---|---|---|---|
| GLBA (16 CFR 314) | Required; evaluate criteria and categorize risks | Assess providers based on risk | 30 days for ≥500 consumers | Annually in writing |
| NYDFS (23 NYCRR 500) | Required periodically | Policies for third-party security | 72 hours after determining incident | Annual certification |
| NCUA (12 CFR 748) | Assess internal/external threats | Require providers to implement measures | 72 hours after reasonable belief | At least annually |
| OCC/FDIC (App B) | Assess likelihood/damage of threats | Exercise due diligence and monitor | Notify regulator as soon as possible | At least annually |
How to Conduct a Bank Information Security Risk Assessment
Banks typically follow the NIST SP 800-30 cycle adapted to their regulatory environment. This section walks through each phase with bank-specific guidance.
Prepare and Scope
Define the purpose and boundaries:
- Annual GLBA review
- FFIEC examination preparation
- New fintech partner onboarding
Set the scope: which systems, business units, and third parties are included.
Assign clear ownership: Regulators consistently flag assessments where IT owns the entire process without executive involvement. The CRO, BSA Officer, or equivalent compliance leader should own accountability for outcomes—not just participate. For institutions without a dedicated executive in that role, a fractional CRO or BSA Officer can fill that accountability gap without a full-time hire.
Identify Assets and Map Threats
Build a comprehensive asset inventory:
- Core banking systems
- Online and mobile banking platforms
- Cloud services
- APIs
- Endpoints
- Third-party integrations
For each asset, document associated threats and known vulnerabilities:
- Ransomware targeting core systems
- Credential phishing targeting online banking
- Misconfigured APIs in fintech integrations
- Insider misuse of privileged access
The FFIEC Information Security Booklet defines a "Critical system" as one whose incapacity or destruction may have a debilitating impact on operations.
Evaluate Controls and Assess Likelihood and Impact
Review existing controls for each threat-asset pair:
- Multi-factor authentication (MFA)
- Encryption (in transit and at rest)
- Patch management processes
- Access controls and least-privilege enforcement
- Vendor SLAs and monitoring
Score the likelihood of exploitation and the impact if it occurs—financially, operationally, reputationally, and from a regulatory standpoint. Use a consistent scoring model (such as a high/medium/low matrix) that can be replicated across teams and audit cycles.
Record Findings in a Risk Register
Document every identified risk in a centralized register with:
- Risk description
- Affected asset
- Likelihood score
- Impact score
- Overall risk rating
- Control gaps
- Assigned owner
- Remediation due date
The register is the primary artifact examiners will review. It should reflect the institution's current risk posture—not just a point-in-time snapshot.
Report, Remediate, and Monitor
Produce outputs tailored to different audiences:
- Board and executive summaries covering material risk and resource decisions
- Control owner reports with specific remediation actions and timelines
- Auditor-facing documentation with evidence packages and framework mappings
Establish a monitoring cadence:
- Minimum annual full reassessment
- Triggered reviews when systems change, vendors are onboarded, or incidents occur
- Interim updates when regulators issue new guidance or material business changes occur
What Should a Bank's Information Security Risk Assessment Include?
Asset and Data Inventory
The assessment must cover all systems that store, process, or transmit sensitive customer data:
- Legacy systems
- Cloud-hosted applications
- Mobile banking platforms
- API connections to fintech partners
NIST FIPS 199 establishes security categories based on potential impact. A "High" impact classification means the loss of confidentiality, integrity, or availability could have a severe or catastrophic adverse effect on organizational operations or individuals.
Third-Party and Vendor Risk
Third-party involvement in breaches doubled year-over-year, accounting for 30% of all breaches in the 2025 Verizon DBIR. Assessments must evaluate:
- Vendor access to systems and data
- Security controls documented in contracts and SLAs
- Audit results (SOC 2 reports, penetration tests)
- Incident notification procedures
- What happens if a vendor fails
This is especially important for banks in BaaS or embedded finance arrangements where fintech partners may access core systems.
The June 2023 Interagency Guidance on Third-Party Relationships issued by the Federal Reserve, FDIC, and OCC emphasizes that a bank's use of third parties does not diminish its responsibility to operate safely and soundly.
| Lifecycle Stage | Required Controls/Tests | Evidence Sources |
|----------------|------------------------|------------------|
| Due Diligence | Assess third-party security posture and risk level | Security questionnaires, SOC 2 reports, penetration test summaries |
| Contracting | Mandate security responsibilities and incident notification | Contractual clauses, SLAs, nondisclosure agreements |
| Ongoing Monitoring | Verify controls and monitor for cyber threats | Audit reviews, continuous monitoring alerts, joint IR testing |
Insider Risk and Access Control Review
Human error, misconfiguration, and overly broad access privileges are among the most common root causes of security incidents — and among the easiest for examiners to spot. The assessment should document:
- Who has access to what systems and data
- Whether access follows least-privilege principles
- Access rights reviewed when roles change or employees leave
- Segregation of duties for critical functions
Incident Response and Recovery Readiness
A complete assessment evaluates not just preventive controls but response capability. Regulators want to see:
- Incident response plans that are documented, tested, and current
- Recovery time objectives (RTOs) defined for critical systems
- Tabletop exercises conducted — with results on file
- Evidence that past incidents produced documented lessons learned
Examiners routinely cite gaps in IR testing during safety and soundness reviews, making response readiness as scrutinized as preventive controls.
Common Mistakes Banks Make With Security Risk Assessments
Treating It as an Annual Checkbox Rather Than a Living Program
Many banks complete the assessment, file the report, and make no meaningful updates until the next exam cycle. This approach misses:
- Changes in the threat landscape
- New vendor relationships
- Technology upgrades introduced throughout the year
Assessments should be event-triggered as well as scheduled. Update them when material changes occur — not just when the calendar says so.
Keeping Ownership Entirely Within IT
Regulators and auditors consistently flag programs where IT is solely responsible for the risk assessment without executive or compliance oversight. IT professionals don't always have visibility into business risk, regulatory obligations, or strategic decisions. Ownership must sit at the executive level — not delegated entirely to technology teams.
Banks and fintechs without a dedicated CRO or CISO should consider whether fractional compliance leadership, like Fraxtional's CRO and CISO services, can provide that director-level oversight without the cost of a full-time hire.
Underscoping Third-Party and Fintech Relationships
Institutions routinely assess their internal systems rigorously but apply minimal scrutiny to vendor and fintech partner controls. Regulatory enforcement in sponsor bank and BaaS programs has made this gap costly. Actions against Evolve Bank, Blue Ridge Bank, and Thread Bank all involved breakdowns in third-party oversight.
Any vendor or fintech partner with access to customer data or core systems must be treated as part of the institution's own risk surface. That means applying the same rigor to:
- Fintech partners operating under a sponsor bank arrangement
- Core system vendors and data processors
- BaaS providers and embedded finance platforms
- Any third party handling customer PII or transaction data
Frequently Asked Questions
What is an information security risk assessment for banks?
It is a structured process to identify, evaluate, and prioritize threats across a bank's IT environment—covering systems, data, vendors, and people—with the goal of informing security controls and satisfying regulatory requirements.
What should an information security (IT) risk assessment for banks include?
Core components include an asset and data inventory, threat and vulnerability mapping, third-party vendor evaluation, control assessment, and risk scoring. These feed into a centralized risk register with assigned ownership and reporting tailored to examiners and leadership.
How do you perform an information security risk assessment for banks?
Follow the NIST SP 800-30 cycle: define scope, inventory assets, map threats (including ransomware, phishing, and API exploits), evaluate controls, and score risk by likelihood and impact. Assign remediation ownership, report findings, and schedule ongoing monitoring with triggered reviews for material changes.
What is the IT risk management framework for banks?
Most banks use NIST Cybersecurity Framework 2.0 or the CRI Profile as their primary framework, aligned with the FFIEC IT Examination Handbook. The FFIEC CAT was retired in August 2025, and institutions should transition to one of these alternatives.
How do you perform a cybersecurity risk assessment for a bank?
How often should a bank perform an information security risk assessment?
Most regulators expect at least an annual review, but assessments should also be triggered by material events—new system deployments, mergers, significant vendor changes, or a breach. FFIEC guidance treats continuous monitoring as the baseline, with formal reassessments calibrated to the institution's risk profile.
