A lending platform isn't one website. It's often a staff app plus separate portals for borrowers, brokers, and investors, with public pages for applications, term sheet signing, and payment requests behind them. Each of those groups should see very different things, and all of it sits close to bank details and loan files.
That changes what you should ask for in a pen test. Here's what I'd put on the list. This is general information, not legal advice.
Are you required to test?
Maybe. The FTC's Safeguards Rule covers non-bank financial institutions, and its examples include mortgage lenders, mortgage brokers, and finance companies. Unless you have effective continuous monitoring, the rule calls for annual penetration testing, plus vulnerability assessments at least every six months and after material changes to your operations.
There are two big catches:
- Business-purpose lending. The rule's definition of a consumer is about products used primarily for personal, family, or household purposes. If you only make business-purpose loans, it may not reach you the same way. That's a question for your lawyer.
- Size. If you hold customer information on fewer than 5,000 consumers, the testing requirement doesn't apply.
Even if you're exempt, you may still want the test. Clients, brokers, and capital partners can ask for proof of it whether a regulator does or not.
What to test
Separation comes first. A broker shouldn't see another broker's deals. An investor shouldn't see borrower documents they have no stake in. If you run more than one company on the platform, one must never see another's data. Testing this takes real logins for every role, and two test companies.
The public pages. Applications, signing links, and payment requests work without a normal login, so they get less attention and more exposure. Can someone guess a link? Can they change the amount or the payee on a payment request? Can they view a term sheet meant for somebody else?
Sign-in. Two-step codes, lockout, and password reset, for each portal. Separate portals often mean separate sign-in flows, and a weak one is all an attacker needs.
File upload and download. Lending runs on documents like tax returns, bank statements, and IDs. Check what can be uploaded, and whether a file can be fetched by someone who shouldn't have it.
The API behind all of it. The portals are only the front end. Test the API and server functions directly, since that's where an attacker will go.
What to ask for on paper
- Hands-on testing against a named standard like OWASP, not only an automated scan.
- The tester's name and qualifications. Ask for them before you sign and judge the answer yourself.
- A report with severity ratings, steps to reproduce, and fixes.
- One retest after your fixes, with an updated report.
- An attestation letter you can share with clients and partners, so the full report stays private.
- Written rules of engagement and an NDA, and whether the tester carries professional liability or cyber insurance.
None of that is unreasonable, even on a small budget. A straight answer to each is a good sign about the firm. So is a straight no.
Test before you launch
If you're launching a new platform, test on staging with fake data. It keeps real borrower files out of the test, and it lets the tester try things you wouldn't want tried in production.
Just make sure staging really matches what you're shipping, and work back from your launch date so there's room for fixes and a retest. If you need a hands-on test, here's how our authenticated pen test works. If you're still working out what you need, start with what a security questionnaire is really asking.