When a community bank or credit union outsources IT, the institution stays accountable for every control the provider touches. Examiners are unambiguous about this. You can delegate the work. You cannot delegate the responsibility.
That one fact should reshape how you evaluate providers. Most MSP sales conversations run on response times, per-seat pricing, and a tour of the security stack. All of that matters and none of it is the real question. The real question is whether this provider can operate inside your regulatory perimeter without you dragging them through it, because your examiner will treat their work as your work.
Having sat on both sides of exam prep with Minnesota financial institutions, here is the list I would hold any provider against, ours included.
What makes IT different for banks and credit unions?
Financial institutions operate under continuous examination: FDIC, OCC, or Federal Reserve supervision for banks, NCUA for credit unions, plus the Minnesota Department of Commerce for state-chartered institutions. An IT provider serving them has to produce examiner-ready evidence of its controls, participate in the institution’s vendor management program, and operate within incident reporting clocks measured in hours. A generalist MSP can be excellent at IT and still fail all three.
Require exam experience, not industry adjacency
“We serve financial services clients” can mean a wealth advisory office with nine laptops. What you need is a provider who has sat in exam prep, fielded document requests, and heard an examiner ask follow-up questions about their monitoring coverage.
Concrete ways to test this. Ask how many of their clients are examined institutions. Ask which frameworks they map controls to now that the FFIEC has retired its Cybersecurity Assessment Tool, because “we still fill out the CAT” is a dated answer; institutions have moved to NIST CSF, the CRI Profile, or the CIS Controls, and your provider should be able to speak to whichever one your board adopted. Ask a credit union prospect’s provider what an NCUA information security exam requested last cycle. Fumbling any of these does not make them a bad MSP. It makes them a bad MSP for you.
Require them to fit your incident reporting clocks
The reporting windows are tight and they are yours, not the provider’s. Banks operate under the 36-hour computer-security incident notification rule to their primary federal regulator. Federally insured credit unions must report reportable cyber incidents to the NCUA within 72 hours. Minnesota-chartered institutions layer state notification duties on top.
Now trace the chain backward: you cannot start a 36-hour clock on an incident your provider noticed but sat on. The provider’s contractual notification duty to you has to be dramatically shorter than your regulatory duty, defined in hours, with a named escalation path and a definition of “incident” that matches the regulatory one, not just “P1 outage.” This belongs in the contract, not in good intentions. If a provider resists putting a notification SLA on paper, that is your answer.
This is also where genuine 24/7 security operations coverage stops being a brochure line. A reporting clock that starts at 2 a.m. Saturday does not wait for Monday’s ticket review, and what examiners check increasingly includes how detection actually reaches a decision-maker.
Require clean vendor due diligence paperwork
Your vendor management program will need, at minimum: a current SOC 2 Type II report on the provider’s own operations, evidence of their cyber insurance, financial statements or another basis for judging their viability, their incident response and business continuity plans, and clarity about their subcontractors, because their downstream vendors become your fourth parties.
The tell here is friction. A provider who serves examined institutions has this package assembled and hands it over in a day. A provider who has never been through real vendor due diligence will treat the request as unusual, and that friction repeats at every annual review and every exam cycle. Institution-side IT risk management is hard enough without a vendor who resents participating in it.
One more paperwork item people forget: right-to-audit language. Examiners expect your critical vendor contracts to include it. Ask for it up front and watch how they respond.
Require core and fintech vendor coordination
Community institutions live and die by their core: Fiserv, Jack Henry, FIS, or one of the credit union cores, plus the constellation of digital banking, card, and payments vendors around it. Your IT provider does not run the core, but they run everything it touches: the network paths to it, the workstations that access it, the identity layer in front of it, the backups around it.
Ask specifically how they handle a problem that sits between their scope and the core vendor’s, because those seams are where multi-day outages are born. The answer you want involves opening the ticket with the core vendor themselves and owning it to resolution, not “we would let you know so you can call Fiserv.”
Require documentation as a deliverable, not a promise
Every exam cycle consumes evidence: network diagrams, access reviews, patch reporting, backup test results, incident logs, training records. If your provider produces these continuously, exam prep is an assembly job. If they produce them on request, exam prep is archaeology, on your payroll.
Make the reporting package part of the contract. Quarterly at minimum: patch compliance, access review attestation, backup restore test results, and a summary of security events with disposition. Institutions that get this from their provider walk into exams calm. It shows.
Frequently asked questions
Can a community bank or credit union use a generalist MSP? There is no rule against it, but the institution absorbs the gap. Every framework mapping, evidence request, and reporting obligation the provider does not understand becomes internal staff work. Most institutions under 500 employees outsource IT precisely because they lack that internal capacity, which makes a provider fluent in examination the whole point.
Is cloud, including Microsoft 365, acceptable for regulated institutions? Yes, and most examined institutions run on it today. What examiners look for is that the institution understood the risk: due diligence on the provider, data residency and encryption decisions on record, and access controls that hold up. The technology is accepted. Undocumented adoption of it is the finding.
What does the 36-hour or 72-hour reporting rule mean for our provider contract? It means the provider’s duty to notify you must be faster than your duty to notify the regulator, with enough margin for your team to assess and decide. In practice that means a notification SLA in single-digit hours for suspected security incidents, a shared definition of what counts, and an escalation path with names on it.
How do we evaluate a provider’s own security? The same way your examiner evaluates yours: evidence over assertions. A current SOC 2 Type II, their own MFA and privileged access story, how they segment client environments from each other, and their incident history with clients. A provider is a concentration risk, and post-incident transparency is worth more than a clean marketing narrative.
If you are running this diligence now, our financial services practice serves examined institutions across Minnesota and is comfortable being held to every item on this list, in writing.
