CRI Profile: A Practical Guide for Vendors Selling to US Banks

Short answer: The CRI Profile is a cybersecurity assessment framework for the financial sector, maintained by the Cyber Risk Institute, a nonprofit coalition of financial institutions and trade associations. It is built on the NIST Cybersecurity Framework and mapped to financial regulatory expectations. Banks use it internally and increasingly lean on it when reviewing the security of fintech and SaaS vendors.

Related guides:

• NIST CSF 2.0 Overview
• NIST CSF Maturity Model
• Best GLBA compliance software for 2026

Key takeaways

• The CRI Profile extends the NIST Cybersecurity Framework with financial sector detail, and version 2.0 aligns with NIST CSF 2.0, including the new Govern function.
• It is written as diagnostic statements, and each institution completes an impact tiering step that decides which statements apply to it.
• Banks often use the Profile's structure to organize vendor due diligence, so vendors see its language in questionnaires even when the Profile itself is not named.
• You do not need a new program to respond. Most SOC 2 or ISO 27001 controls map cleanly to CSF functions, and the work is mostly mapping, evidence and clear answers.
• Honest, evidence-backed answers move reviews faster than claims of full alignment.

---

What is the CRI Profile?

The CRI Profile is a financial sector version of the NIST Cybersecurity Framework that turns high-level outcomes into specific, assessable statements.

It is maintained by the Cyber Risk Institute (CRI), a nonprofit coalition made up of financial institutions and financial trade associations. The Profile grew out of an industry effort, originally published as the Financial Services Sector Cybersecurity Profile, to solve a long-standing problem: banks were being examined against many overlapping sets of cybersecurity expectations from different regulators, each with its own terminology.

The idea is simple. If a bank documents its cybersecurity program once, against a common structure that already maps to the major regulatory expectations, it can reuse that work across exams and internal audits instead of answering the same question several different ways. The Profile maps to sources such as FFIEC guidance, the GLBA Safeguards requirements and the NYDFS Cybersecurity Regulation (23 NYCRR Part 500), among others.

For vendors, the key point is that the Profile is written for financial institutions. You will not be "certified" against it, but its concepts and wording show up in the questions banks send you.

CRI Profile vs NIST CSF: how are they related?

The CRI Profile sits on top of the NIST CSF, using the same functions and categories while adding financial sector specifics and regulatory mappings.

NIST CSF is deliberately general and does not tell a bank exactly what a regulator expects to see. The CRI Profile fills that gap with more granular statements and regulatory references.

	NIST CSF	CRI Profile
Maintained by	NIST (US federal agency)	Cyber Risk Institute (nonprofit industry coalition)
Audience	Any organization, any sector	Financial institutions, and by extension their suppliers
Level of detail	Outcome-based functions, categories and subcategories	Adds diagnostic statements beneath CSF outcomes
Regulatory mapping	General informative references	Mapped to financial regulatory expectations
Scoping	Organizational profiles and tiers chosen by the user	Impact tiering determines which statements apply

Version 2.0 of the CRI Profile was released to align with NIST CSF 2.0. The biggest visible change is the Govern function, which CSF 2.0 introduced to cover cybersecurity strategy, roles, policy, oversight and supply chain risk management. For vendors, that shift matters: third-party and supply chain risk now sits inside governance, which is exactly where a bank will look when it evaluates you.

If you are new to the underlying framework, our NIST CSF 2.0 overview explains the six functions in more depth.

How is the CRI Profile structured?

The Profile is organized by CSF function, then by category and subcategory, with diagnostic statements underneath that an institution answers and supports with evidence.

Three building blocks are worth understanding:

1. Functions and categories. These follow NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond and Recover. If you already know the CSF, you already know the map.
2. Diagnostic statements. Each statement describes a specific practice, for example that access rights are reviewed periodically or that incident response plans are tested. An institution responds to each applicable statement and records supporting evidence or rationale. Response options generally allow for full implementation, implementation through compensating or risk-based approaches, not applicable, or not implemented.
3. Impact tiering. Before answering, an institution completes a short tiering questionnaire that looks at factors such as its size, interconnectedness and importance to the wider financial system. The resulting impact tier scopes which diagnostic statements apply. A small community institution answers fewer statements than a large, systemically important bank.

The tiering concept is useful for vendors to understand. The expectations a bank places on you will often reflect its own tier and how critical your service is to it. A payment processor or claims platform handling sensitive customer data will face a deeper review than a low-risk marketing tool.

Why are banks asking vendors about the CRI Profile?

Banks are expected by their regulators to manage third-party risk, and many use the CRI Profile's structure to organize that oversight consistently.

US supervisory guidance makes clear that a bank can outsource a service but not the responsibility for managing its risk. When a bank relies on your platform for payments, lending, claims or customer data, it needs evidence that it has assessed you.

In practice, vendors run into the CRI Profile in a few ways:

• Directly named questionnaires. Some institutions ask vendors to self-assess against selected CRI Profile statements.
• Profile-shaped questionnaires. More often, a bank's vendor questionnaire is organized by CSF function and borrows the Profile's language without naming it.
• Contract and exam follow-ups. After an internal audit or regulatory exam, a bank may come back asking for evidence tied to specific practices in the Profile.

This applies beyond pure fintech. HealthTech vendors that process payments, handle claims or manage member billing for bank-affiliated or bank-partnered programs frequently find themselves in the same due diligence process, alongside their HIPAA obligations. If you work in regulated finance more broadly, our guide to fintech compliance in 2026 covers the surrounding landscape.

What evidence maps to each CSF function?

Most of the evidence a bank wants already exists in a well-run SOC 2 or ISO 27001 program, it just needs to be organized by CSF function.

The table below gives examples of what vendors commonly provide. It is a starting point, not a complete list, and the exact requests will depend on the bank and on your service.

CSF function	What the bank wants to understand	Example vendor evidence
Govern	Who owns security, how risk is managed, how you oversee your own suppliers	Information security policy, board or leadership reporting, risk management policy, roles and responsibilities, vendor risk management procedure and subprocessor list
Identify	Whether you know your assets, data and risks	Asset inventory, data flow diagrams, data classification policy, risk assessment and risk register, vulnerability scan results
Protect	How you prevent unauthorized access and data loss	Access control policy, MFA configuration, quarterly access review records, encryption standards, secure SDLC documentation, security awareness training completion
Detect	How quickly you notice something wrong	Logging and monitoring configuration, SIEM or alerting rules, intrusion detection coverage, log retention settings
Respond	What happens during an incident, including customer notification	Incident response plan, tabletop exercise records, incident tickets and post-incident reviews, customer notification commitments
Recover	How you restore service and data	Business continuity and disaster recovery plans, backup configuration, restore test results, recovery time and recovery point objectives

A current SOC 2 Type II report or ISO 27001 certificate often supports many statements but rarely answers everything. Expect follow-ups on governance, fourth-party oversight and incident notification timelines.

How can a vendor prepare for CRI Profile questions?

Treat preparation as a mapping exercise: start from the controls you already operate, align them to CSF functions, collect evidence, then answer statements honestly.

A practical sequence for an SMB vendor:

1. Inventory your existing controls. Pull the control list from your SOC 2 scope, ISO 27001 Statement of Applicability or internal security program. This is your raw material.
2. Map controls to CSF 2.0 functions and categories. Many SOC 2 common criteria and ISO 27001 Annex A controls have natural CSF counterparts. Pay special attention to Govern, since older mappings built for CSF 1.1 may not cover it well.
3. Identify gaps against the areas banks care about. Typical gaps for smaller vendors include formal board or leadership oversight of cyber risk, documented oversight of your own critical suppliers, tested recovery plans and defined incident notification timelines.
4. Gather evidence into a reusable library. Store policies, screenshots, configuration exports, review records and reports so you can attach them to answers without searching each time.
5. Draft standard answers to common diagnostic statements. Write concise responses that state what you do, how often and where the evidence lives. Reuse them across banks, adjusting for scope.
6. Be explicit about compensating controls and not applicable items. If a statement does not fit your service model, explain why. If you meet the intent in a different way, describe the alternative.
7. Set a review cadence. Update your mapping and evidence when controls change, and at least ahead of each renewal cycle with your major bank customers.

If you are also working to show maturity rather than just coverage, our NIST CSF maturity model guide can help you frame where each function stands today.

Mistakes that slow down bank due diligence

The most common delays come from vague answers, missing evidence and overstated claims, not from missing controls.

• Answering "yes" without evidence. A bare yes invites a follow-up request. Pair every affirmative answer with a pointer to evidence.
• Claiming full CRI Profile compliance. The Profile is designed for financial institutions. Saying you are "CRI compliant" signals that you may not understand it. Say instead that you have mapped your controls to it.
• Ignoring Govern. Vendors with strong technical controls often have thin documentation on leadership oversight and supplier management. CSF 2.0 made this area impossible to skip.
• Forgetting fourth parties. Banks want to know which of your providers touch their data and how you assess them.
• Vague incident notification terms. Banks have their own notification obligations, so commitments like "promptly" often get pushed back.

How SecureSlate helps

SecureSlate gives you a single control library mapped across frameworks, so the controls you already run for SOC 2, ISO 27001 or HIPAA can be mapped and tracked against NIST CSF functions when a bank sends a CRI Profile style questionnaire. Automated evidence collection from your cloud and SaaS stack keeps access reviews, configuration exports and monitoring records current, and policy templates help you close common Govern gaps such as risk management and supplier oversight.

The built-in risk register and vendor risk management module document how you manage your own third parties, which banks ask about directly. Audit-ready exports and a trust center let you share evidence with bank reviewers in an organized way, cutting down the back-and-forth that stalls deals.

Start your free SecureSlate trial

FAQ

Do vendors need to be certified against the CRI Profile?

No. There is no vendor certification for the CRI Profile. It is a self-assessment framework designed for financial institutions. Vendors are typically asked to answer selected statements or a questionnaire based on it, supported by evidence such as a SOC 2 report or ISO 27001 certificate.

Will my SOC 2 report satisfy a bank's CRI Profile questions?

It will usually cover a significant share of them, especially for Protect, Detect and parts of Identify. Banks often still ask about governance, supplier oversight, recovery testing and incident notification, so plan to supplement your report with policies and specific evidence.

What changed in CRI Profile version 2.0?

Version 2.0 aligned the Profile with NIST CSF 2.0. The most notable change is the Govern function, which brings cybersecurity strategy, oversight, policy and supply chain risk management together. Institutions using earlier versions need to update their mappings to reflect the new structure.

Does the CRI Profile apply to insurtech and HealthTech vendors?

It applies to anyone whose service a financial institution relies on, if that institution uses the Profile for vendor oversight. Insurtech vendors working with bank partners and HealthTech vendors handling payments or claims for financial institutions often receive Profile-based questions alongside their other compliance requirements.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.