An IT or information security risk assessment should do more than populate a spreadsheet. For a financial institution, it should tell the Board, senior management, regulators, and auditors a clear story: what information the institution protects, where that information resides, what could go wrong, which controls reduce the risk, whether those controls work, and what residual exposure remains.
Many banks have stronger controls than their risk assessment suggests. The problem is not always the absence of firewalls, encryption, policies, backups, vendor contracts, or access reviews. The problem is often that the assessment does not connect those controls to specific technology assets, customer information systems, vulnerabilities, and business processes. When that connection is missing, management may believe risk is controlled, while auditors and examiners see an unsupported conclusion.
The regulatory expectation is direct. The Interagency Guidelines Establishing Information Security Standards implement GLBA section 501(b) establish standards for administrative, technical, and physical safeguards, including proper disposal of customer information. A compliant risk assessment must identify foreseeable internal and external threats, assess likelihood and potential damage, evaluate the sufficiency of policies, procedures, systems, and other assessments, and apply those steps to disposal of customer information. Below are five (5) common risk assessment mistakes we have seen across the industry that have repeatedly led to audit findings, regulatory criticism, and enforcement actions.
Mistake 1: The assessment is not based on technology assets
A generic risk assessment organized only by control category, access control, cybersecurity, business continuity, vendor management, usually misses the most important question: where is the risk?
A bank’s assessment should be grounded in its actual technology and information assets: core processing, online banking, mobile banking, loan origination, wire transfer, ACH, imaging, email, file shares, cloud platforms, AI, API, RPA, Active Directory, databases, endpoints, network devices, ATMs, backup environments, paper files, and third-party-hosted systems. Customer information systems include methods used to access, collect, store, use, transmit, protect, or dispose of customer information, and they include both physical and electronic facilities.
The control that protects one asset may not protect another. Multifactor authentication may reduce risk for remote access but do little for unsecured paper loan files. Encryption may protect data in transit but not excessive user privileges. A board-quality assessment starts with an inventory, assigns ownership, identifies data sensitivity, maps business processes, and connects each asset to its threats, vulnerabilities, and controls.
Mistake 2: Controls are not mapped to vulnerabilities by asset
A common deficiency is listing controls without proving what they mitigate. For example, “firewall in place” is not a meaningful risk response unless it is tied to a defined threat, asset, vulnerability, configuration standard, monitoring process, and test result.
The better approach is a risk-and-control matrix that connects each material asset to reasonably foreseeable threats and risk event, such as unauthorized access, ransomware, data leakage, vendor compromise, processing errors, destructive malware, insider misuse, failed backup recovery, physical theft, improper disposal, and unauthorized system changes.
Key controls should be specific. Examples include identity and access management, least privilege, privileged access monitoring, multifactor authentication, encryption, secure configuration, vulnerability management, patch management, change management, endpoint protection, logging and alerting, incident response, backup restoration testing, physical access restrictions, dual control, segregation of duties, user recertification, employee training, and background checks for sensitive roles. The Security Guidelines specifically identify measures such as access controls, physical access restrictions, encryption, controls over system modifications, dual control, segregation of duties, and employee background checks as controls institutions must consider where appropriate.
Mistake 3: Control effectiveness is not assessed
A policy is not the same as an effective control. A control exists only when it is designed appropriately, implemented, operating, evidenced, and monitored.
Risk assessments often state that a control is “in place” without determining whether it works. That creates false precision. For example, a bank may state that backups mitigate ransomware risk, but the real question is whether immutable backups exist, whether restoration has been tested, whether recovery time objectives are achievable, and whether backup credentials are protected from compromise. Similarly, a vendor SOC report may be on file, but management must understand the report period, scope, subservice organizations, exceptions, complementary user entity controls, and whether identified deficiencies affect the bank’s environment.
The Security Guidelines require testing of key controls, systems, and procedures, with scope, sequence, and frequency informed by the risk assessment. Vendor oversight also requires more than collecting documents; institutions must review timely and relevant audit reports, test results, or equivalent evaluations and determine whether material deficiencies are being corrected.
Mistake 4: Residual risk is calculated inappropriately
Residual risk is the risk remaining after controls are considered. It should not be a mechanical number produced by averaging likelihood, impact, and control scores without judgment. If residual risk is higher than inherent risk, the methodology is likely not measuring mitigation correctly.
A defensible residual risk methodology should distinguish between inherent risk, control design and operating effectiveness, control gaps, compensating controls, and risk acceptance. It should also consider the sensitivity of the information, the criticality of the process, customer impact, regulatory exposure, operational resilience, and the bank’s approved risk appetite.
For Board reporting, the output should not be a dense technical worksheet. It should show material residual risks, control weaknesses, risk acceptance decisions, and escalation triggers. Regulators expect the Board or an appropriate committee to approve the written information security program, oversee implementation, and receive reports from management at least annually on the status of the program and material matters.
Mistake 5: Paper records, disposal, vendors, and prior findings are excluded
Some assessments focus almost entirely on networks and applications. That is incomplete. GLBA risk assessment obligations extend to customer information disposal, and disposal requirements also apply to consumer information. Consumer information can include information about individuals who applied for but did not obtain loans, guarantors, employees, and prospective employees.
A complete assessment should include paper records, branch files, loan documentation, teller work areas, storage rooms, imaging processes, shredding bins, archived boxes, backup media, printers, copiers, removable media, and third-party disposal providers. It should also include vendors that store, process, transmit, support, or access customer information.
Third-party risk is especially important as banks rely more heavily on cloud providers, fintech partners, managed service providers, core processors, cybersecurity tools, and vendors that use automation or AI-enabled capabilities. The 2023 interagency third-party risk management guidance applies to all banks with third-party relationships and addresses the third-party life cycle, including planning, due diligence, contract negotiation, ongoing monitoring, and termination.
An IT or information security risk assessment for a financial institution is not a generic cybersecurity exercise; it requires understanding banking operations, customer information systems, GLBA expectations, FFIEC guidance, vendor risk, operational resilience, audit evidence, and regulatory scrutiny. A service provider without this combined expertise may produce a report that appears complete but fails to identify bank-specific risks, map controls properly, assess control effectiveness, or support defensible residual risk conclusions.
Another frequent mistake is lack of transparency with the consultant performing the assessment. If management withholds audit reports, regulatory findings, penetration tests, vulnerability scans, incident history, SOC report exceptions, or unresolved issues, the final assessment may look clean but will not be defensible. The Federal Reserve’s guidance is explicit that a generic consultant assessment is inadequate when it does not examine the risks specific to the institution’s customer information, systems, configurations, and disposal processes.
What a defensible assessment looks like
A strong IT and information security risk assessment is asset-based, bank-specific, control-mapped, evidence-driven, and Board-ready. It identifies material risks before auditors and examiners do. It translates technical weaknesses into business impact. It supports management decisions.
Since 2010, Mijares Consulting has helped banks address audit findings and enforcement-action deficiencies and strengthen GLBA risk assessments. Our approach is designed to make the problem manageable: build the asset-based scope, map threats and risk events to controls, evaluate control effectiveness, review vendor evidence, include paper and disposal processes, calculate residual risk correctly, and deliver a report that management can use and auditors and examiners can follow. Call us if you need a service provider with proven knowledge of banking risk, IT, information security, audit and regulatory expectations, and examination readiness. This will help you ensure the assessment is practical for management, credible to auditors and regulators, and useful to the Board in overseeing the institution’s risk profile.
The result is not more paperwork. It is a simpler, more defensible risk management process, one that gives the Board clear oversight, gives management actionable priorities, and gives regulators confidence that the institution understands and controls its information technology and information security risk.
Follow us, stay informed, stay secure, and let’s navigate the risk landscape together.