Key takeaways

  • The Interagency Guidelines Establishing Information Security Standards require regular testing of key controls, set by risk, by independent parties or independent staff.
  • The same guidelines require at least annual reporting to the board, and the report should cover results of testing.
  • The FFIEC Information Technology Examination Handbook is the guide examiners use to judge your program. Read its security and audit booklets.
  • Scope the test to your real risks: internet-facing systems, online banking, internal network, staff phishing and key vendors.
  • Examiners look for follow-through. Findings need an owner, a date and proof of the fix.

Start with the answer: examiners expect a community bank to test its security controls regularly, to use independent testers, to base the depth and frequency on its own risk assessment, and to report results to the board, which then tracks the fixes. A penetration test is one of the clearest ways to meet that expectation. It is not the only test, and a report that sits unread does not count as a control.

What the rule actually says

The federal banking agencies issued the Interagency Guidelines Establishing Information Security Standards under the Gramm-Leach-Bliley Act and the Federal Deposit Insurance Act. They require each institution to run an information security program with administrative, technical and physical safeguards. Among the controls, the guidelines call for regular testing of key controls, systems and procedures. They say the frequency and nature of the tests should follow the institution's risk assessment, and that tests should be conducted or reviewed by independent third parties, or by staff independent of those who develop or maintain the security program.

The guidelines also say management must report to the board or a board committee at least annually on the overall status of the program and compliance with the guidelines. They list the topics the report should cover, and results of testing is one of them. Read the exact text for your regulator; the agencies publish the same standard in their own regulations.

Where the FFIEC IT Handbook fits

The Federal Financial Institutions Examination Council publishes the IT Handbook, a set of booklets that describe how examiners assess information security, audit, management, operations and vendor oversight. It is general guidance, not a checklist, and examiners apply it in proportion to your size and complexity. In practice, they look for a board that understands technology risk, management that identifies threats and tests controls, and evidence that weaknesses are tracked to closure. The council's site blocks some automated requests, so read the booklets directly from the official handbook site.

What boards should expect to see

Directors do not need to read technical detail. They need a clear picture and a record that they asked the right questions. A good board package includes:

  • A plain-language summary of what was tested and who tested it, with proof of independence.
  • The overall result: how far a skilled attacker got, and what stopped them.
  • The top findings ranked by business impact, such as exposure of customer records or the ability to move money.
  • Management's response for each: owner, target date and status.
  • A comparison with the previous test, so the board can see progress.
  • Any limits on the test, such as systems left out of scope and why.

How to scope the test

Base scope on your risk assessment, not on a template. For most community banks, a sensible program covers these areas over a planning cycle.

  • External testing: everything an outsider can reach, including online banking, remote access, email and cloud services.
  • Internal testing: what an attacker can do after reaching one employee workstation, including privilege escalation in the directory and reach to core systems.
  • Social engineering: phishing and phone pretexting against staff who handle wires and account changes.
  • Web and mobile applications: the customer-facing channels and the interfaces behind them.
  • Wireless and branch networks: guest access, teller networks and remote branches.
  • Vendor-hosted systems: test only with the vendor's written permission, and review the vendor's own test summaries.

Pair penetration testing with regular vulnerability scanning. They answer different questions: scanning finds known weaknesses broadly, while a penetration test shows how weaknesses chain together into a real compromise.

Choosing and managing the tester

Independence means the tester did not design or run the controls being tested. Ask for written authorization terms, rules of engagement, named testers and a safe-testing method for production systems. Make sure the contract covers confidential handling of customer data found during the test and a final report you can give to examiners. Request a retest of the serious findings so you can show they were fixed.

Close the loop

Examiners often find that a bank commissioned a test but let the findings drift. Put each finding in your risk register or issue tracker with an owner and a date. Report status to the board at each meeting until closed. If you accept a risk rather than fix it, record who accepted it and why. That record shows a working program.

Our team can scope a test to your risk assessment, deliver a board-ready report and retest the fixes.

Sources

This article is general information, not legal advice. Standards and vendor documentation change; confirm current requirements with your regulator, counsel and IT provider. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity