12 CFR 609.930(c)(6) requires each Farm Credit System institution to regularly test key controls, systems and procedures in its cyber risk management program. The institution's risk assessment determines the frequency and nature of those tests, and the work must be conducted or reviewed independently. The provision does not use the term penetration testing. A Farm Credit buyer can still choose a penetration test when a risk assessment calls for evidence that an attacker could cross a specific application, identity or network boundary.
Quick answer. 12 CFR 609.930(c)(6) requires regular, risk-based testing of key cyber controls, with independent conduct or review. It does not prescribe an annual penetration test. Use the annual risk assessment under paragraph (c)(1) to decide which assets and attack paths merit a human-led test, then preserve the independence decision, findings, remediation and board reporting evidence. Stingrai can scope one-time or continuous web, API, cloud and network testing to that approved risk decision and include retesting of remediated findings.
This guide is for a security leader, procurement owner or board committee at a Farm Credit System institution. It separates the legal testing requirement from a recommended pentest statement of work, so a vendor quote can be judged against the institution's risk and governance obligations. The institution's own program, risk assessment and contracts determine the final coverage.
Who the provision covers
Section 609.930(a) says each System institution must implement a comprehensive written cyber risk management program consistent with its size, risk profile and complexity. This is a Farm Credit System rule. It is not a statement that every agricultural lender, commercial bank or rural technology vendor is directly regulated under this section. Procurement should name the regulated institution and distinguish its own controls from systems operated by a service provider.
The Farm Credit Administration's corporate activity record lists 59 banks and associations as of October 1, 2026. That figure describes banks and associations in that FCA listing, not the full universe of every kind of System institution or every organization serving farm borrowers. The buying point is that a standardized vendor package can be useful, but the rule still scales the written program and testing decisions to each institution's risk and complexity.
The board of directors or an appropriate committee must approve the written program each year under section 609.930(b). That annual approval is a governance clock. It should not be recast as an annual penetration-test rule. The annual risk assessment under paragraph (c)(1) is the source for deciding what kind of technical test is necessary and how often.
What the testing text says, line by line
Paragraph (c)(6) requires an institution to maintain robust internal controls by "regularly testing the key controls, systems, and procedures" of the cyber risk management program. Paragraph (c)(6)(i) says the frequency and nature of those tests are to be determined by the institution's risk assessment. Paragraph (c)(6)(ii) says tests must be conducted or reviewed by independent third parties or by staff independent of the people who develop or maintain the program. All three clauses matter to a purchase.
First, the subject is broader than a vulnerability scan or a penetration test. Identity approvals, backups, incident procedures, application authorization, endpoint defenses, network separation and vendor access can all be key controls or systems depending on the institution's risk assessment. A pentest may be an effective method for testing an attack path through some of them. It may be a poor way to prove that a board policy was approved or a recovery exercise was run. The test program should combine methods as the institution's risks require.
Second, "regularly" does not supply a fixed interval on its own. The annual risk assessment is a separate explicit requirement under paragraph (c)(1). It should justify the test frequency and nature. A high-risk public member portal with frequent releases may warrant more frequent application testing than a stable isolated system. That is a buyer judgment based on documented risk, not a numeric interval supplied by 609.930(c)(6).
Third, independence can be met by an outside third party or independent staff. A vendor is not automatically required. Conversely, a team that built or maintains the cyber program cannot simply mark its own test independent because it used a commercial scanner. The institution needs a clear separation or independent review that satisfies the clause. If internal testers conduct work, the SOW or internal charter should identify who reviews it and how conflicts are handled.
Figure 1: Suggested test selection maps the institution's risks to methods and evidence; the regulation leaves frequency and nature to the risk assessment. Source: 12 CFR 609.930(c)(1) and (c)(6).
Read testing alongside the rest of the cyber program
An isolated pentest purchase will miss important obligations in the same section. Paragraph (c)(2) requires the institution to identify systems and software vulnerabilities, prioritize them and affected systems by risk, and perform timely remediation. A vendor report is therefore the start of a decision trail. The institution should record which findings were fixed, which need compensating action and who accepted any residual risk. The provision does not give a universal number of days for every fix.
Paragraph (c)(5) requires appropriate diligence when selecting vendors, a vendor risk assessment on all vendors, and monitoring of IT and cyber risk management vendors against agreed expectations and deliverables. That applies to selection and oversight of a pentest provider. It also matters when a tested system is hosted or operated by another vendor. The institution should verify its permission to test that system and identify what evidence the service provider must supply.
At a minimum, paragraph (e) requires quarterly reporting of material cyber matters, including specific risks and threats, to the board or an appropriate committee. The board report need not reproduce every technical screenshot. It should explain material findings, remediation progress, unresolved exposure and any reason the planned test coverage changed. That is a proposed evidence presentation, grounded in the reporting requirement rather than a mandated report template.
These sections form one workflow: risk assessment selects the work, independent testing checks controls, findings enter prioritization and remediation, vendor oversight checks delivery, and material outcomes reach the board. A quote that promises "609.930 compliance" merely because it includes one annual external scan does not show that workflow. Ask bidders to state precisely which technical evidence they will deliver and what stays with institution management.
When a penetration test is the right method
The rule does not prescribe penetration testing, but a risk assessment may identify questions that require a human-led technical test. A member portal may need proof that one authenticated user cannot view another borrower's records. A cloud system may need a test of whether a service identity can cross account or workload boundaries. An internal network may need evidence of whether a compromised workstation can reach a privileged service. A vendor connection may need validation of its trust boundary and permissions. These are example buyer questions, not statements that every System institution has these exact assets or weaknesses.
Select a test because its result will answer a documented risk question. If an institution's risk assessment identifies a new public application, a major migration, a change in third-party access or a pattern of unresolved authorization findings, the SOW can name that trigger and the intended coverage. If the risk is mainly a control process that cannot be validated through adversarial access, choose a different independent test or review. A defensible program says why each method was used.
For a web application, ask for authenticated roles, API endpoints, business logic and authorization boundaries rather than a public-page scan. For a cloud system, ask which accounts, identity paths and workloads are in scope. For a network, identify external entry points, internal segments and privileged directories. A broad enterprise test may join those surfaces, but it needs a data flow and explicit exclusions. The web application testing service, cloud testing service and network testing service describe the corresponding types of work.
Keep the institution's risk decision attached to the quote
A short test authorization memo can include the risk-assessment date, risk owner, systems selected, test purpose, independence route, planned interval and excluded systems. It is a useful internal procurement artifact; the regulation does not prescribe that memo by name. Attach it to the RFP so bidders understand whether the goal is a portal authorization test, a segmentation test, an independent review of internal work or a broader control validation.
The memo also guards against a common cadence error. A vendor may sell a convenient annual subscription. The institution can choose it, but its own risk assessment must explain whether that frequency and nature are suitable. A contract renewal date should not replace the regulatory decision process. The same risk assessment may justify a one-time test after a major change and a different recurring method for stable controls.
An independent testing SOW a buyer can issue
Use the statement of work to make four promises reviewable: the chosen risk will be tested, the tester or reviewer will be independent, the evidence will support remediation, and the institution can connect results to its program and board reporting. The fields below are recommendations for procurement, not extra regulatory text.
SOW field | What the buyer supplies | What the vendor or independent reviewer returns |
|---|---|---|
Risk and objective | Risk-assessment finding and decision owner | Method mapped to that risk, with coverage and limits |
Asset boundary | Application, API, cloud account, network segment and vendor dependencies | Target inventory, data flow and exclusions confirmed before work |
Independence | Program developers, maintainers and proposed review chain | Named test or review personnel and conflict statement |
Permission and safety | System owner approval, test accounts, windows and stop conditions | Signed rules of engagement and contact path |
Evidence | Classification and handling rules for member or borrower data | Redacted proof, severity rationale and report handling record |
Remediation | Owners and risk-prioritization process | Findings mapped to affected system and practical fix guidance |
Verification | Fix acceptance criteria and available retest window | Retest result or documented reason verification was limited |
Governance | Board-report schedule and management audience | Executive summary of material risks and open decisions |
The penetration testing SOW template provides general target and deliverable fields. For a System institution, add the regulatory decision trail: the risk assessment that chose the method, the independence choice under paragraph (c)(6)(ii), and the vendor-diligence record under paragraph (c)(5). That makes a proposal easier to compare than a claim that a provider "covers FCA."
Define independence with names and reporting lines
If an outside tester is selected, ask who performs the work and whether the same firm designed or maintains the control being tested. If internal staff will test, name the independent reviewer and show why that reviewer is separate from program developers or maintainers. A mixed approach can be useful: internal teams gather configuration evidence, while independent staff or an outside provider reviews and technically validates the conclusion. The regulation allows conduct or review by the independent party, so the buyer should state which route it selected.
Independence is not synonymous with ignorance of the environment. A tester needs architecture, roles and access rules to answer the risk question. The distinction is whether the people testing or reviewing are independent of program development or maintenance. Do not hide context from them to create an artificial appearance of objectivity.
Specify data and vendor permissions
Farm Credit institutions handle sensitive financial and borrower information. The SOW should identify production versus test data, account creation, evidence redaction, storage location, retention and deletion. Those are prudent engagement safeguards; section 609.930(c)(6) does not prescribe a specific redaction tool or storage term. If a vendor owns an application or a cloud tenancy, obtain contractual permission for the intended methods and define what the vendor will monitor during the test.
The institution's vendor oversight duty also applies after award. Establish a contact for status, an escalation route for material findings and a clear acceptance process for the final report. A provider's sample report can show whether it distinguishes verified findings from scanner output, gives affected assets and supports remediation without copying sensitive records into unnecessary files.
Figure 2: Suggested evidence chain for the institution's risk-based independent testing and governance program. Source: 12 CFR 609.930(c) and (e).
Build the first procurement and reporting cycle
Begin with the annual risk assessment required by paragraph (c)(1). Identify the key controls, systems and procedures with the greatest exposure and decide which require independent technical testing, independent review of internal tests or another method. Record the test frequency chosen for each based on risk. The rule asks for regular testing; the institution should be able to explain what "regular" means in its program.
Next, map the work to vendor procurement. For each proposed pentest, specify asset owners, authorization, independence, access, timing, deliverables and retest. Conduct vendor diligence and assess the vendor under paragraph (c)(5). Run the technical work only after rules of engagement and data handling are approved. When the report arrives, route findings into the vulnerability-prioritization and timely-remediation process under paragraph (c)(2).
Finally, place material risks and remediation decisions in the quarterly board or committee report required by paragraph (e). The following calendar is a suggested operating order, not a fixed set of pentest dates in the regulation:
Program point | Regulation | Suggested purchase or evidence decision |
|---|---|---|
Annual risk assessment | 609.930(c)(1) | Identify which technical questions need testing and how often |
Annual program approval | 609.930(b) | Show the board the written program and its test method choices |
Regular independent testing | 609.930(c)(6) | Commission or review work with documented independence |
Findings and remediation | 609.930(c)(2) | Prioritize affected systems and record timely corrective action |
Vendor oversight | 609.930(c)(5) | Check agreed scope, milestones, evidence and performance |
Quarterly board report | 609.930(e) | Summarize material risks, threats, open fixes and decisions |
This sequence can overlap. A newly discovered issue may require immediate remediation while a broader test continues. A quarterly board meeting may occur before retesting is finished. The report should say what is known, what is unresolved and who owns the next decision rather than delay all communication until a perfect final state exists.
Cost and vendor comparison
The regulation does not set a test budget or vendor rate. Price depends on the chosen surface, number of applications and roles, network size, cloud accounts, depth, access, reporting and independent review. Ask each bidder to price the same risk question and list assumptions. A quote for only one public website is not equivalent to one covering authenticated member roles, APIs, supporting identity and a connected cloud environment.
For a narrow web application, distinguish the fixed package boundary of one web application and associated APIs from a larger enterprise program. The cost calculator can help organize the surfaces, but a multi-asset Farm Credit program needs a custom scope and quote. The cheapest offer can cost more later if its exclusions require another test to answer the risk question or if it omits retesting needed to verify a fix.
Ask vendors to answer these questions:
Which risk-assessment finding does each test objective address?
Which controls, systems and procedures are directly tested, and which are reviewed through other evidence?
Who is independent of the program developers and maintainers, and is that independence through conduct or review?
Which authenticated roles, APIs, cloud identities, network segments and vendor connections are included?
What proof will support a finding without exposing more borrower data than necessary?
How will every verified issue reach an owner for risk prioritization and timely remediation?
What retest or independent review is included after a fix?
What concise material-risk summary can management use for quarterly board reporting?
The answers should give the institution a test it can defend as a chosen method within its program. They should not promise that buying the test alone fulfills every paragraph of 609.930.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing service provider headquartered in Toronto, with a London office. Two named penetration testers staff each human-led engagement, from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications. They can test authenticated web and API roles, cloud identity and workloads, internal and external network paths, and Active Directory boundaries. Confirmed findings appear in the PTaaS portal as they are found, with prioritized guidance; retesting of remediated findings is included. Human-led and hybrid reports include an attestation letter.
For a Farm Credit institution, Stingrai can deliver a one-time test or a continuous program selected by the institution's risk assessment. The proposal should name the independent testers or reviewers, system boundaries and report recipients. Snipe, Stingrai's autonomous agent, applies only to one web application and associated APIs, either alone or testing together with human testers in a Hybrid engagement. It does not replace the institution's risk assessment, board approval, vendor oversight or wider network testing decision.
Frequently Asked Questions
Does 12 CFR 609.930 require a penetration test?
No. Section 609.930(c)(6) requires regular testing of key controls, systems and procedures, with the risk assessment determining frequency and nature. A penetration test can be an appropriate method when the documented risk calls for technical validation of an attack path.
Does the rule require an annual pentest?
No. The rule requires an annual risk assessment and annual board approval of the written program, but it leaves the frequency and nature of testing to the institution's risk assessment. It does not specify an annual penetration test.
Must an outside firm conduct the testing?
No. Section 609.930(c)(6)(ii) allows tests to be conducted or reviewed by an independent third party or by staff independent of the people who develop or maintain the cyber risk management program.
What should a Farm Credit System institution test?
It must regularly test the key controls, systems and procedures identified within its cyber risk management program. Its risk assessment should determine which application, identity, network, cloud, vendor or process controls need which test method and interval.
Can a vulnerability scan satisfy the testing requirement?
A scan can contribute evidence for some controls, but the institution's risk assessment must determine whether it answers the relevant control question. Section 609.930(c)(6) does not equate scanning with every required test or specify one universal method.
How should a pentest provider's independence be documented?
Identify who built or maintains the program, who conducts the test, who independently reviews it if needed, and any conflict. The rule permits independent conduct or independent review, including by properly separate internal staff.
What happens to findings after testing?
Section 609.930(c)(2) requires vulnerability identification, risk-based prioritization and timely remediation. Material cyber risks and threats also belong in the institution's at least quarterly board or committee reporting under paragraph (e).
Do vendor-hosted systems belong in scope?
They may, when the institution's risk assessment identifies them as relevant and testing is authorized. Section 609.930(c)(5) separately requires vendor diligence, vendor risk assessment and monitoring of agreed deliverables; testing does not replace that oversight.
Related reading
References
Talk to Stingrai
Turn the risk assessment into an independent testing scope with named assets, authorized methods and useful remediation evidence. Get a Quote or book a free discovery call.
