Information Security Policy Template: A Fintech and Community Bank Walkthrough

TL;DR

• The FTC Safeguards Rule requires nine specific program elements — most information security policies miss at least three of them.
• Community banks face FFIEC Information Security Handbook requirements; fintechs face both FTC/GLBA and sponsor bank TPRM questions. The overlaps are bigger than you’d expect.
• Your information security policy should be 5–12 pages max. If it’s longer, you’ve merged policy with standards — and examiners will notice.
• The most common gap isn’t missing controls — it’s failing to document the Qualified Individual’s qualifications or not linking the policy to a current written risk assessment.

Got an MRA on information security in your last exam cycle? You’re in good company. The OCC’s 2025 Cybersecurity and Financial System Resilience Report flagged information security governance as a recurring deficiency at community banks. Not for lack of technology — for lack of paper. Banks with solid controls and inadequate written policies still fail exams.

At fintechs, the trigger is usually different: sponsor bank TPRM onboarding. The bank asks for your information security policy on day one of due diligence, and “we have controls in Notion” doesn’t close the loop.

This walkthrough covers what the policy document needs to contain, how it maps to the FTC Safeguards Rule and FFIEC requirements, what examiners actually look for, and how to structure a document that survives both an exam and an audit.

The Policy Hierarchy — Get This Wrong and the Rest Doesn’t Matter

Most organizations conflate policy, standards, and procedures. Regulators don’t.

The information security policy sits at the top of this stack. It shouldn’t contain specifics like “passwords must be 12 characters” — that belongs in an Access Control Standard. What it should say is: “Access to systems must be controlled through role-based access controls, with minimum requirements defined in the Access Control Standard.” That reference structure lets you update technical specifics without triggering a board re-approval every time NIST issues new guidance.

The Nine Elements the FTC Safeguards Rule Requires

Under 16 CFR Part 314.4, your information security program must include all nine of the following. Your policy should either address each element directly or reference the standard that does.

The 2023 Safeguards Rule amendments added technical requirements on top of these structural elements: multi-factor authentication (MFA) for all access to systems containing customer information, encryption of data at rest and in transit, and — for organizations where a breach affects 500 or more customers — a breach notification obligation to the FTC within 30 days. These requirements apply to non-bank financial institutions including mortgage brokers, money service businesses, digital lenders, and any company “significantly engaged in” financial activities under the Bank Holding Company Act definition.

What FFIEC Expects from Community Banks

If you’re a nationally chartered bank, state-chartered bank, or credit union, the FFIEC IT Examination Handbook’s Information Security booklet is the primary reference. The OCC uses its Cybersecurity Supervision Work Program (Bulletin 2023-22) as the examiner evaluation guide.

The FFIEC framework aligns with NIST CSF 2.0’s six functions: Govern, Identify, Protect, Detect, Respond, Recover. The OCC retired the FFIEC Cybersecurity Assessment Tool in 2024 — banks can now self-assess against NIST CSF 2.0, CIS Critical Security Controls v8, or the Cyber Risk Institute Profile. Any of these is acceptable; what isn’t acceptable is having no documented self-assessment at all.

Common policy gaps examiners flag at community banks:

Encryption language that’s vague. “We encrypt sensitive data” isn’t sufficient. The policy should reference which data types require encryption at rest versus in transit, with specific standards pointing to acceptable algorithms (AES-256, TLS 1.2+).

Mobile device and remote access policy missing. BYOD and remote work arrangements are chronically under-documented. If your employees access systems from personal devices, the policy needs to address that.

Third-party language that’s too thin. The FFIEC and OCC expect the policy to address evaluation and monitoring of service providers with access to customer information. Many community bank policies reference contracts without specifying minimum security requirements.

Fintech-Specific Considerations

If you’re subject to the FTC Safeguards Rule, write your information security policy to satisfy both FTC requirements and FFIEC expectations — even if you’re not a bank. That’s one document that covers your regulatory baseline and your sponsor bank’s TPRM review simultaneously.

Fintechs on BaaS models should specifically address three areas most policies skip:

Data segregation. Who owns what data, what the bank’s access rights are, and how customer data is isolated from operational and analytics data.

Incident notification obligations. The bank’s contract almost certainly requires notification within 24 to 72 hours of a security incident — even if you’re below the FTC’s 500-customer reporting threshold. The policy should reference this obligation.

Vendor chain coverage. If your stack runs on AWS and Snowflake and three SaaS tools, the bank wants evidence that you’ve evaluated each of those for security, not just your own internal systems. Your vendor management provisions need to extend to the full service provider chain.

For a detailed breakdown of your FTC Safeguards Rule obligations, see the FTC Safeguards Rule compliance guide for non-bank financial institutions.

Information Security Policy: A Working Structure

Here’s how to build the document. This structure satisfies FTC Safeguards Rule element requirements and FFIEC examiner expectations.

Section 1 — Purpose and Scope

Define what the policy governs (all information systems, all data types, all employees and contractors) and why (regulatory obligation, risk management, customer protection). One page maximum.

Section 2 — Roles and Responsibilities

Name the Qualified Individual by title, not name — policies shouldn’t require amendment every time someone changes roles. Define board responsibilities (approve policy, receive program reports), executive responsibilities (resource allocation, escalation), employee responsibilities (comply, report suspected incidents), and vendor responsibilities (minimum security requirements, with specifics referenced from your Vendor Management Standard).

Section 3 — Information Classification

Define your data tiers and the baseline protections required for each. At minimum: Public, Internal, Confidential, and Restricted. Customer financial information (NPI under GLBA) sits at Restricted. This section can reference a Data Classification Policy if one exists separately.

Section 4 — Access Control Principles

State the principles: least privilege, need-to-know, role-based access control, MFA required for all access to systems containing customer information. Technical specifics belong in an Access Control Standard.

Section 5 — Risk Assessment Requirement

State that a written risk assessment must be completed at least annually and whenever material operational changes occur. Reference where the current risk assessment is maintained.

Section 6 — Safeguards and Controls

High-level statement that controls exist across physical, technical, and administrative domains. Reference subordinate standards: Encryption Standard, Network Security Standard, Endpoint Security Standard, Vulnerability Management Standard.

Section 7 — Vendor and Third-Party Security

State the obligation: all service providers with access to customer information must be evaluated prior to engagement, required to implement appropriate safeguards by contract, and monitored throughout the relationship. See our vendor risk tiering guide for how to structure that oversight program.

Section 8 — Incident Response

Reference your Incident Response Plan. State that the plan must be tested at least annually and that the Qualified Individual is responsible for initiating response to confirmed incidents.

Section 9 — Training and Awareness

State the requirement: all employees receive security awareness training at hire and at least annually. Specify that the program includes phishing simulation and that completion records are maintained.

Section 10 — Testing and Monitoring

State that the program includes continuous monitoring of systems and networks, and that penetration testing is performed at least annually by a qualified party. Results are reviewed by the Qualified Individual and reported to leadership.

Section 11 — Reporting to Leadership

State that the Qualified Individual reports to the board or senior leadership committee at least annually on program status, material risks, and test results. Meeting minutes documenting that reporting must be maintained.

Section 12 — Exceptions and Waivers

Define how an exception to policy is requested, who has authority to approve it, what documentation is required, and how long an exception is valid. Unmanaged exceptions are a recurring audit finding.

Section 13 — Review and Update Cycle

The policy is reviewed at least annually by the Qualified Individual, updated as needed, and reapproved by the board. The effective date on the document must reflect the most recent board approval.

What Examiners Actually Check

When an OCC examiner or a sponsor bank’s vendor management team reviews your information security policy, they’re doing five things:

1. Checking the approval date. A policy last approved 18+ months ago is a finding before the examiner reads a single word.
2. Locating the Qualified Individual designation. Is it there? Are qualifications documented? Is there a reporting structure defined?
3. Testing for risk assessment linkage. Is there a current risk assessment on file, and does the policy reference it?
4. Verifying MFA and encryption language. Post-2023 Safeguards Rule amendments, these are non-negotiable and specific — not general principles.
5. Asking for board reporting evidence. Meeting minutes, not verbal assertions. Examiners will request meeting minutes showing the report was presented and the policy was approved at the board level.

For a detailed look at building the testing and monitoring program that supports your policy, see our compliance monitoring and testing guide.

So What?

An information security policy isn’t a bureaucratic checkbox. It’s the document that proves your controls aren’t accidental — that someone with authority made deliberate decisions about what to protect, how to protect it, and who’s responsible. When an examiner asks “how do you govern your information security program?”, this document is the answer. When a sponsor bank asks how employees know what to do with customer data, this document sets the rules.

The gap most organizations have isn’t technology — it’s paper. A modern stack with MFA, encryption, and robust endpoint protection, run by a team that has no governing policy, is still a program without governance. Write the policy. Get board approval. Date it. Link it to a current risk assessment. Review it annually. That’s the minimum — and it’s ahead of where most organizations are when the first examiner question arrives.