1. Introduction: The FFIEC Cybersecurity Assessment Tool (CAT)
The Federal Financial Institutions Examination Council (FFIEC) Cybersecurity Assessment Tool, universally abbreviated to FFIEC CAT, is a structured, repeatable methodology that helps United States financial institutions identify their inherent cyber risk and measure their cybersecurity maturity. First published in June 2015 and updated in May 2017, the CAT translated the National Institute of Standards and Technology (NIST) Cybersecurity Framework and the existing FFIEC Information Technology (IT) Examination Handbook into a self-assessment that a board, a chief information security officer (CISO) and an examiner could all read from the same page.
The FFIEC is not a single regulator. It is the interagency body that prescribes uniform principles and standards for the federal examination of financial institutions. Its member agencies are the Office of the Comptroller of the Currency (OCC), the Board of Governors of the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Consumer Financial Protection Bureau (CFPB) and the State Liaison Committee (SLC). Because these agencies examine banks, thrifts, credit unions and their technology service providers, the CAT became a de-facto expectation across the US banking sector even though its use was formally voluntary.
This guide is written for two audiences at once. The implementer, meaning the CISO, the IT risk officer and the third-party service provider, will find a phased build-out, an evidence catalogue and a control-by-control checklist. The assessor, meaning the internal auditor, the external examiner or the CERT-In empanelled reviewer supporting a US-facing subsidiary, will find verification questions, expected evidence and a mapping to adjacent frameworks so that a single body of testing can satisfy multiple mandates.
2. What is FFIEC CAT
The FFIEC CAT is a two-part diagnostic. The first part, the Inherent Risk Profile, measures the amount of cyber risk an institution carries before considering the controls it has deployed. The second part, Cybersecurity Maturity, measures how well the institution's controls, processes and governance are actually performing across five domains. The assessment is completed by mapping the institution against a large library of declarative statements; each statement is either met or not met, and the pattern of met statements determines a maturity level for each domain.
The governing principle of the CAT is alignment. Management is expected to read the Inherent Risk Profile alongside the Cybersecurity Maturity results and satisfy itself that maturity is commensurate with risk. A community bank with a Least or Minimal inherent risk profile might reasonably sit at Baseline or Evolving maturity, whereas a large, internet-facing institution processing high transaction volumes and offering many delivery channels is expected to demonstrate Intermediate, Advanced or Innovative maturity. A material mismatch, high inherent risk paired with low maturity, is the finding the CAT is designed to surface.
The CAT is deliberately declarative rather than prescriptive. Each maturity statement describes an observable condition ('The institution has a formal, documented incident response programme...') rather than a technology mandate. This lets institutions of very different sizes use the same instrument, and it lets examiners compare answers consistently. The trade-off is that a naive self-assessment can overstate maturity, which is why an evidence-backed, assessor-grade approach, the subject of this guide, matters.
How CAT relates to the FFIEC IT Handbook and NIST CSF
Every maturity declarative statement in the CAT is cross-referenced back to the FFIEC IT Examination Handbook booklets (for example the Information Security, Business Continuity and Outsourcing Technology Services booklets) and to the NIST Cybersecurity Framework subcategories. An institution that has mapped its control catalogue to NIST CSF can therefore populate a large fraction of the CAT automatically, and vice versa. This dual lineage is why the CAT translated so cleanly into its successor, the FS-ISAC / Cyber Risk Institute (CRI) Profile.
3. Who must comply and scope of applicability
Use of the CAT was voluntary, but examination against the underlying expectations was not. In practice the following entities were, and their successors remain, in scope for FFIEC-style cybersecurity supervision.
| Entity type | Primary federal supervisor | CAT applicability |
|---|---|---|
| National banks and federal thrifts | OCC | Expected to complete or use an equivalent assessment |
| State member banks and bank holding companies | FRB | Expected; examiners referenced CAT domains |
| State non-member banks | FDIC | Expected; supervisory expectation |
| Federally insured credit unions | NCUA | Used the NCUA ACET, a CAT-derived tool |
| Technology service providers (TSPs) to the above | FFIEC (interagency) | Assessed under the same domains via TSP examinations |
| Bank holding and savings-and-loan holding companies | FRB | In scope at consolidated level |
| Fintechs and third parties operating as service providers | Indirect via bank oversight | Flowed down through vendor risk management |
Scope of applicability is not limited to the regulated bank itself. Because the Cybersecurity Maturity domains include an entire domain on External Dependency Management, the CAT effectively pulls affiliates, cloud providers, managed security service providers and core banking vendors into scope through contractual flow-down. A vendor that cannot answer the External Dependency and Threat Intelligence statements about itself creates a gap in the bank's own assessment.
- Enterprise scope: all business lines, delivery channels and legal entities under the institution's charter.
- Technology scope: on-premise systems, cloud services, mobile and internet banking, ATMs, wire and ACH rails, and end-user computing.
- Third-party scope: core processors, cloud infrastructure providers, MSSPs, fintech partners and downstream fourth parties.
- Governance scope: the board of directors, executive management and the three lines of defence (business, risk, audit).
4. Structure of FFIEC CAT
The CAT has a fixed two-part architecture. Part one, the Inherent Risk Profile, spans five risk categories. Part two, Cybersecurity Maturity, spans five domains, each of which contains assessment factors, components and, ultimately, declarative statements graded across five maturity levels. The table below sets out the complete top-level structure.
| Part | Category / Domain | What it measures |
|---|---|---|
| Inherent Risk Profile | Technologies and Connection Types | Volume and type of connections, devices, and legacy systems |
| Inherent Risk Profile | Delivery Channels | Online, mobile and third-party delivery channels offered |
| Inherent Risk Profile | Online / Mobile Products and Technology Services | Products such as P2P payments, wire, ACH and card issuance |
| Inherent Risk Profile | Organisational Characteristics | Mergers, staffing, changes and locations affecting risk |
| Inherent Risk Profile | External Threats | Volume and sophistication of attacks targeting the institution |
| Cybersecurity Maturity | Domain 1: Cyber Risk Management and Oversight | Governance, risk management, resources, training and culture |
| Cybersecurity Maturity | Domain 2: Threat Intelligence and Collaboration | Threat intelligence, monitoring and information sharing |
| Cybersecurity Maturity | Domain 3: Cybersecurity Controls | Preventive, detective and corrective controls |
| Cybersecurity Maturity | Domain 4: External Dependency Management | Connections and relationship management with third parties |
| Cybersecurity Maturity | Domain 5: Cyber Incident Management and Resilience | Incident detection, response, mitigation and resilience |
Each of the five maturity domains decomposes into Assessment Factors, and each factor into Components. Every component carries a set of declarative statements arranged across the five maturity levels: Baseline, Evolving, Intermediate, Advanced and Innovative. An institution attains a level for a domain only when it meets all statements for that level and every level beneath it. The full assessment-factor decomposition is the subject of the master checklist below.
5. Master assessment checklist
This is the operative section. It enumerates every Inherent Risk category and every Cybersecurity Maturity domain, factor and component. For each grouping the table states what an assessor should verify and the typical evidence that substantiates a met declarative statement. No control area is omitted.
5.1 Inherent Risk Profile - all five categories
| What to verify | Typical evidence |
|---|---|
| Total number and type of internet-facing connections, ISP relationships and unsecured external connections are inventoried | Network diagram, connection inventory, ISP contracts |
| Count of end-of-life / unsupported systems and open-source components in use | Asset inventory with lifecycle status, SBOM, EOL register |
| Delivery channels offered: internet banking, mobile banking, ATM/ITM and third-party channels | Product catalogue, channel list, mobile app store listings |
| High-risk products offered: wholesale/retail wire, ACH origination, P2P, card issuance, merchant acquiring | Product risk assessments, transaction-volume reports |
| Organisational change indicators: recent mergers, IT staff turnover, direct employees vs contractors | HR reports, org charts, M&A records |
| External threat volume: attempted attacks, DDoS, and threat-intel indicating targeting | SIEM attack dashboards, threat-intel reports, DDoS logs |
| Resulting Inherent Risk rating (Least, Minimal, Moderate, Significant, Most) documented and board-reviewed | Signed Inherent Risk Profile, board minutes |
5.2 Domain 1 - Cyber Risk Management and Oversight
Factors: Governance (Oversight, Strategy/Policies, IT Asset Management, Resource/Culture); Risk Management (Risk Management Programme, Risk Assessment, Audit); Resources; Training and Culture.
| What to verify | Typical evidence |
|---|---|
| Board and senior management provide oversight, approve the cyber strategy and receive regular reporting | Board charter, minutes, cyber strategy sign-off, MI packs |
| Cybersecurity roles, responsibilities and accountability are formally assigned | RACI matrix, job descriptions, CISO reporting line |
| A written, board-approved information security programme and policy suite exists and is reviewed at least annually | Policy set with approval dates and version control |
| IT asset management maintains a complete inventory of hardware, software and data classification | CMDB / asset register, data classification scheme |
| A cyber risk management programme performs periodic risk assessments feeding the risk appetite | Risk assessment reports, risk register, appetite statement |
| Independent audit (internal or external) tests the cyber programme and tracks remediation | Audit plan, audit reports, issue-tracking log |
| Adequate budget, staffing and skills are provisioned for the cyber programme | Budget approvals, staffing plan, skills matrix, training spend |
| A security awareness and training programme covers all staff, with role-based content and phishing tests | Training records, phishing simulation results, completion rates |
5.3 Domain 2 - Threat Intelligence and Collaboration
Factors: Threat Intelligence (Threat Intelligence and Information); Monitoring and Analysing (Monitoring and Analysing); Information Sharing (Information Sharing).
| What to verify | Typical evidence |
|---|---|
| The institution subscribes to and operationalises threat-intelligence sources relevant to its sector | FS-ISAC membership, feed subscriptions, intel platform |
| Threat intelligence is analysed, prioritised and translated into detective and preventive action | Intel triage records, IOC ingestion into SIEM, tickets |
| Security monitoring correlates events across the environment to detect anomalous activity | SIEM/SOC dashboards, correlation rules, alert volumes |
| The institution shares indicators and participates in industry information-sharing groups | FS-ISAC submissions, ISAC participation, law-enforcement contacts |
| Threat data flows to the incident response and risk teams for continuous tuning | Feedback loops, threat briefings to IR, rule-tuning history |
5.4 Domain 3 - Cybersecurity Controls
Factors: Preventive Controls (Infrastructure Management, Access and Data Management, Device/End-Point Security, Secure Coding); Detective Controls (Threat and Vulnerability Detection, Anomalous Activity Detection, Event Detection); Corrective Controls (Patch Management, Remediation).
| What to verify | Typical evidence |
|---|---|
| Network is segmented, hardened and defended with firewalls, IPS and secure configuration baselines | Firewall rulebase, segmentation diagram, hardening standards |
| Access management enforces least privilege, unique IDs, MFA and periodic recertification | IAM policy, MFA coverage report, access recertification logs |
| Data is classified, encrypted in transit and at rest, and protected by DLP where warranted | Encryption inventory, DLP policy, key-management records |
| End-point security includes anti-malware, EDR, disk encryption and mobile device management | EDR console coverage, MDM enrolment, AV deployment reports |
| Secure software development lifecycle includes code review, testing and change control | SDLC policy, SAST/DAST results, change tickets, peer reviews |
| Vulnerability management scans, prioritises and remediates within defined SLAs | Scan reports, vulnerability register, remediation SLA metrics |
| Detective controls include logging, FIM, anomaly detection and continuous monitoring | Log retention policy, FIM alerts, monitoring coverage map |
| Patch management applies vendor patches and mitigates within risk-based timeframes | Patch compliance dashboards, exception register |
| Corrective controls remediate identified weaknesses and confirm closure | Remediation tracker, retest evidence, closure sign-off |
5.5 Domain 4 - External Dependency Management
Factors: Connections (Connections); Relationship Management (Due Diligence, Contracts, Ongoing Monitoring).
| What to verify | Typical evidence |
|---|---|
| All third-party and network connections are identified, inventoried and risk-rated | Connection inventory, third-party register, data-flow maps |
| Due diligence is performed before onboarding vendors, sized to inherent risk | Vendor due-diligence files, SOC 2 reports, security questionnaires |
| Contracts include security, breach-notification, right-to-audit and subcontractor clauses | Executed contracts, MSAs, addenda with security schedules |
| Ongoing monitoring re-assesses vendor security posture on a defined cadence | Vendor scorecards, periodic reviews, continuous-monitoring feeds |
| Fourth-party (subcontractor) risk and concentration risk are understood and managed | Subcontractor disclosures, concentration analysis, exit plans |
5.6 Domain 5 - Cyber Incident Management and Resilience
Factors: Incident Resilience Planning and Strategy (Planning, Testing); Detection, Response and Mitigation (Detection, Response and Mitigation); Escalation and Reporting (Escalation and Reporting).
| What to verify | Typical evidence |
|---|---|
| A documented incident response plan defines roles, severities, playbooks and communication paths | IR plan, playbooks, contact tree, RACI |
| Business continuity and disaster recovery plans integrate cyber scenarios with defined RTO/RPO | BCP/DRP documents, RTO/RPO register, dependency mapping |
| Incident detection triggers timely triage, containment and eradication | Detection use-cases, incident tickets, containment timelines |
| Response actions are tested through tabletop and technical exercises at least annually | Exercise reports, after-action reviews, remediation actions |
| Escalation and regulatory / customer notification occur within required timeframes | Notification templates, regulator filings, breach-notice records |
| Resilience is validated through backups, failover testing and recovery drills | Backup test logs, failover results, recovery drill evidence |
6. Scoping and materiality / tiering
The CAT's own scoping mechanism is the Inherent Risk Profile. Rather than applying a fixed control baseline to every institution, the CAT expects the depth of maturity to scale with the five-band inherent risk rating: Least, Minimal, Moderate, Significant and Most. Materiality is therefore built into the model - a control gap that is immaterial for a Least-risk community bank may be a critical finding for a Most-risk money-centre institution.
| Inherent risk rating | Typical institution profile | Expected minimum maturity emphasis |
|---|---|---|
| Least | Very limited technology, few connections, no online products | Baseline across domains |
| Minimal | Limited products and channels, small footprint | Baseline, moving to Evolving in controls |
| Moderate | Diverse products, multiple channels, moderate connections | Evolving to Intermediate |
| Significant | High transaction volumes, many delivery channels | Intermediate to Advanced |
| Most | Complex, internet-facing, high-value, heavily targeted | Advanced to Innovative |
Scoping the assessment itself means agreeing the assessment perimeter (which legal entities, systems and third parties), the assessment period, and the assurance level (self-attested versus independently validated). Assessors should confirm that the Inherent Risk Profile reflects current business - a recent merger, a new mobile wallet or an expanded ACH origination service all raise inherent risk and should trigger re-scoping.
7. Implementation approach
A defensible CAT programme is built in phases. Each phase below lists the activities and the deliverables an assessor will look for.
Phase 1 - Mobilise and govern
- Activities: secure board sponsorship, appoint an accountable owner, define scope, and stand up a steering group.
- Activities: confirm the CAT (or successor CRI Profile) as the operating framework and align policy language.
- Deliverables: programme charter, RACI, approved scope statement, project plan.
Phase 2 - Determine inherent risk
- Activities: inventory technologies, connections, delivery channels, products and external-threat data; complete the five risk categories.
- Activities: derive and document the overall Inherent Risk Profile band and secure management challenge.
- Deliverables: signed Inherent Risk Profile, supporting inventories, board briefing.
Phase 3 - Assess current maturity
- Activities: work through all declarative statements across the five domains, gathering evidence for each 'Yes'.
- Activities: record the achieved maturity level per domain and identify statements not yet met.
- Deliverables: completed maturity assessment, evidence library, current-state heat map.
Phase 4 - Analyse alignment and gaps
- Activities: compare inherent risk against maturity to confirm alignment or expose mismatch.
- Activities: prioritise gaps by risk exposure, effort and regulatory expectation.
- Deliverables: gap analysis, prioritised remediation backlog, risk-acceptance log.
Phase 5 - Remediate and uplift
- Activities: execute remediation projects, tune controls, and close declarative-statement gaps.
- Activities: update policies, deploy or reconfigure technology, and retrain staff.
- Deliverables: remediation tracker, updated control evidence, re-tested statements.
Phase 6 - Sustain and re-baseline
- Activities: embed the assessment into an annual cycle; refresh inherent risk on material change.
- Activities: transition legacy CAT artefacts to a successor framework (CRI Profile v2.0 / NIST CSF 2.0) given the 2025 sunset.
- Deliverables: annual assessment calendar, continuous-monitoring metrics, mapping to successor framework.
8. Maturity model
The CAT uses a five-level maturity model applied per domain. Levels are cumulative: an institution must satisfy every declarative statement at a level and all lower levels to claim that level.
| Maturity level | Characteristics | Illustrative indicator |
|---|---|---|
| Baseline | Minimum expectations, largely driven by regulatory requirements and stated policy | Compliance-driven; documented but reactive controls |
| Evolving | Additional formality of documented procedures beyond baseline; some risk-driven objectives | Procedures formalised; risk assessments performed |
| Intermediate | Detailed, formal processes; controls validated and consistent across the enterprise | Metrics tracked; controls tested and consistent |
| Advanced | Cybersecurity practices are integrated, automated and continuously improved | Automation, near-real-time analytics, integrated risk |
| Innovative | Driving innovation in people, process and technology; may develop new controls and share with sector | Predictive analytics, novel controls, sector leadership |
Assessors should resist self-reported inflation. A statement is only 'met' at Intermediate and above when the control is not just documented but demonstrably operating and, where relevant, measured. This is where evidence quality separates a credible assessment from a paper exercise.
9. Assessment and audit approach
- Agree scope, assessment period and assurance level with the sponsor and audit committee.
- Validate the Inherent Risk Profile against current inventories, products and threat data.
- Plan testing: sample declarative statements per domain, weighting higher-risk components.
- Request evidence using the categorised evidence list and set a response deadline.
- Perform walkthroughs and control operation testing, not just design review, for Intermediate-plus claims.
- Independently re-perform or observe key controls (MFA enforcement, patch SLA, backup restore, IR tabletop).
- Record each declarative statement as met, partially met or not met with evidence references.
- Reconcile achieved maturity per domain against the inherent risk band and flag mismatches.
- Draft findings with risk rating, root cause, and recommended remediation and owner.
- Report to management and the board; agree remediation dates and schedule re-testing.
- Track issues to closure and confirm through re-test before marking resolved.
- Feed results into the annual re-baseline and successor-framework transition plan.
10. Evidence request list
The following evidence, organised by domain, substantiates a defensible assessment.
- Governance: board minutes, cyber strategy, approved policies, RACI, CISO reporting line, budget approvals.
- Risk management: risk assessments, risk register, risk-appetite statement, audit plans and reports.
- Asset and data: CMDB/asset inventory, data classification scheme, SBOM, EOL register.
- Threat intelligence: FS-ISAC membership, feed subscriptions, intel triage records, IOC ingestion logs.
- Monitoring: SIEM/SOC dashboards, correlation rules, log-retention policy, alert-volume reports.
- Preventive controls: firewall rulebase, segmentation diagram, hardening standards, IAM/MFA reports, encryption and key-management records, EDR/MDM coverage, SDLC and SAST/DAST results.
- Detective/corrective controls: vulnerability scans and register, patch-compliance dashboards, FIM alerts, remediation tracker and retest evidence.
- External dependency: vendor register, due-diligence files, SOC 2 reports, contracts with security schedules, vendor scorecards, concentration and fourth-party analysis.
- Incident and resilience: IR plan and playbooks, BCP/DRP with RTO/RPO, exercise and after-action reports, backup-restore and failover test logs, breach-notification templates and any regulator filings.
- Training: awareness training records, role-based content, phishing simulation results and completion rates.
11. Roles and responsibilities
| Role | Responsibility under FFIEC CAT |
|---|---|
| Board of Directors | Approves cyber strategy and risk appetite; receives reporting; ensures alignment of maturity to risk |
| Chief Executive Officer | Owns enterprise accountability; ensures adequate resourcing |
| Chief Information Security Officer | Owns the assessment, control operation and remediation programme |
| Chief Risk Officer | Integrates cyber risk into enterprise risk; challenges the inherent risk rating |
| IT / Infrastructure teams | Operate preventive, detective and corrective controls; supply evidence |
| Internal Audit | Independently validates the assessment and tests control operation |
| Third-Party / Vendor Management | Owns External Dependency Management factors and vendor evidence |
| Incident Response / SOC | Operate detection, response and resilience capabilities |
| Compliance / Legal | Manage regulatory notification, contracts and right-to-audit clauses |
12. KPIs and metrics to track
- Domain maturity level achieved versus target, tracked over time.
- Percentage of declarative statements met per domain, with evidence coverage.
- Inherent-risk-to-maturity alignment index (mismatches flagged).
- MFA coverage across privileged and remote access.
- Patch compliance and mean time to remediate critical vulnerabilities.
- Percentage of critical vendors with current due diligence and SOC 2 reports.
- Phishing simulation click and report rates; training completion percentage.
- Mean time to detect and mean time to respond to incidents.
- Backup restore success rate and DR failover test pass rate.
- Open remediation actions past due, by risk rating.
13. Readiness checklist
- Board has approved the cyber strategy and risk appetite.
- Inherent Risk Profile completed across all five categories and signed off.
- All five maturity domains assessed with evidence for each met statement.
- Inherent risk and maturity reconciled and mismatches documented.
- Asset and data inventories complete and classified.
- MFA, encryption and least-privilege access verified in operation.
- Vulnerability and patch SLAs defined and being met.
- Third-party due diligence and contracts with security clauses in place.
- Incident response plan tested via tabletop in the last 12 months.
- Backups and DR failover successfully tested.
- Remediation backlog prioritised with owners and dates.
- Transition plan to a successor framework (CRI Profile v2.0 / NIST CSF 2.0) documented given the 2025 sunset.
14. Common gaps and findings
- Inherent Risk Profile is stale and does not reflect a recent merger, new product or channel.
- Maturity is self-reported at Intermediate-plus without evidence of controls actually operating.
- MFA is deployed inconsistently, leaving remote or legacy access uncovered.
- End-of-life and unsupported systems are present but absent from the risk register.
- Third-party monitoring is one-time due diligence with no ongoing reassessment or fourth-party visibility.
- Incident response plan exists but has never been exercised, or exercises lack after-action follow-through.
- Patch and vulnerability SLAs are defined but not met, with a growing exception backlog.
- Threat intelligence is subscribed to but not operationalised into detection rules.
- Board reporting lacks the inherent-risk-to-maturity alignment view.
- No transition plan away from the sunset CAT to a successor framework.
15. FFIEC CAT mapped to other frameworks
| FFIEC CAT domain | NIST CSF 2.0 | CRI Profile v2.0 | ISO/IEC 27001:2022 | Relevant US regulation |
|---|---|---|---|---|
| Domain 1: Risk Management and Oversight | Govern, Identify | Governance (GV) | Clauses 4-9, A.5 | GLBA Safeguards, 12 CFR Appendix B |
| Domain 2: Threat Intelligence and Collaboration | Identify, Detect | Identify, Detect | A.5.7 Threat intelligence | FFIEC IT Handbook - Information Security |
| Domain 3: Cybersecurity Controls | Protect, Detect | Protect (PR) | A.8 Technological controls | GLBA Safeguards Rule |
| Domain 4: External Dependency Management | Govern (Supply Chain), Identify | Supply Chain / Third Party | A.5.19-A.5.22 | OCC/FRB/FDIC Third-Party Risk Guidance (2023) |
| Domain 5: Incident Management and Resilience | Respond, Recover | Respond, Recover | A.5.24-A.5.30, A.17 | Computer-Security Incident Notification Rule (36-hour) |
Note the adjacent US reporting obligation: the interagency Computer-Security Incident Notification Rule (effective 1 May 2022) requires a banking organisation to notify its primary federal regulator as soon as possible and no later than 36 hours after determining a notification incident has occurred. Successor frameworks and any live CAT programme should carry this 36-hour trigger into the Domain 5 escalation statements.
16. How CyberSigma helps
Frequently asked questions
Need help with FFIEC CAT?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.