Before signing with any mortgage platform, run one test: ask for a written risk assessment, an independent penetration test or SOC 2 Type II report, and documented restore exercises from the last twelve months. If a vendor cannot produce all three, the platform's encryption, multifactor authentication, role-based access controls, and audit logs are just marketing claims until proven otherwise.
TL;DR:
- Vendors must provide recent independent penetration test reports, documented restore exercises, and a current risk assessment before signing a mortgage platform contract.
- Encryption requires TLS 1.2+ with SHA-256 certificates and AES 128 or 256-bit keys at rest, with clear key ownership and management.
- Multi-factor authentication for all users and tenant separation verified through architecture diagrams and authorization testing are essential controls.
- Vendors must adhere to regulations like the FTC Safeguards Rule and Freddie Mac guidance, providing audit reports, encryption specs, and testing schedules as proof.
- Due diligence includes reviewing specific evidence such as restore test results, subcontractor lists, and incident response plans during demos and annually thereafter.
Table of Contents
- What technical controls should a mortgage platform actually have?
- Which regulations govern mortgage data security and what do they require?
- What should your vendor contract require and prove?
- How do you know a vendor can actually recover from an attack?
- What questions should you ask in a security-focused demo?
- Where do most mortgage security reviews go wrong?
- How should mortgage data be classified and handled?
- What secure development practices should mortgage software vendors follow?
- How does employee training reduce mortgage data security risk?
- What physical security should mortgage data centers have?
- Balancing strict security with usability that originators can actually work with
- What to ask for when you request a 1 Solution demo
- Sources
- FAQ
What technical controls should a mortgage platform actually have?
Encryption is the baseline, not the finish line. Data in transit needs TLS certificates signed with SHA-256, TLS 1.2 or higher, and minimum 2048-bit RSA keys, while data at rest should run on AES with 128-bit or 256-bit session keys, standards drawn directly from Freddie Mac's eMortgage security guidance. Ask who holds the encryption keys and whether that responsibility sits with the vendor, a cloud provider, or a shared arrangement, because unclear key ownership is one of the most common gaps in mortgage software contracts.
Authentication comes next. Every user touching borrower data should need multifactor authentication, not just an option buried in settings, and the platform should support single sign-on for firms with existing identity systems. The NMLS data security overview describes two-factor authentication at assurance level 3 alongside annual independent penetration testing, a combination worth matching in any vendor you evaluate. Our guide to configuring user permissions covers how role-based access should look in daily practice.
Tenant separation matters just as much in shared cloud environments. Ask for architecture diagrams and authorization test results proving one brokerage's loan files cannot surface in another tenant's account. NIST's zero-trust guidance recommends verifying every access request against identity, device health, and resource sensitivity rather than assuming a network boundary keeps data safe.
- Encryption: TLS 1.2+, SHA-256 certificates, AES 128 or 256-bit keys at rest.
- Authentication: mandatory MFA, SSO support, session timeouts matching NIST SP 800-63B.
- Access separation: documented tenant isolation with authorization test evidence.
- Application security: endpoint protection and secure coding practices addressing OWASP-listed risks.
- Logging: immutable audit trails covering logins, exports, admin actions, and API calls.
Two-factor authentication at assurance level 3 and annual third-party penetration testing are part of the layered protections described in NMLS technical security protocols, a baseline worth holding every mortgage vendor to.
Which regulations govern mortgage data security and what do they require?
The FTC Safeguards Rule applies to mortgage brokers and lenders as financial institutions under GLBA, requiring a written information security program with administrative, technical, and physical safeguards. It also defines notification events: unauthorized acquisition of unencrypted customer information affecting 500 or more consumers must be reported to the FTC within 30 days of discovery. Outsourcing loan processing to a software vendor does not outsource that responsibility. Your firm remains accountable even when a third party holds the data.
Freddie Mac's eMortgage guidance adds specifics that regulators leave general: NIST and FIPS-aligned encryption, role-based access, logging and auditing, physical security at data centers, and backup and disaster recovery testing at least annually. NIST's own zero-trust architecture work and its ransomware risk management profile reinforce the same themes from a different angle: continuous verification of access requests and backups that are protected from compromise and actually tested for restoration.
Translating these rules into vendor evidence looks like this:
- Written information security program aligned with the FTC Safeguards Rule.
- SOC 2 Type II or SSAE audit reports covering the data centers or cloud infrastructure in use.
- Documented encryption specifications matching Freddie Mac's NIST/FIPS-aligned recommendations.
- A testing schedule showing when penetration tests, risk assessments, and recovery exercises last occurred.
For a broader walkthrough of GLBA and Safeguards Rule obligations, see our regulatory compliance overview.
What should your vendor contract require and prove?
A security feature list means little without contract language that holds the vendor to it. The clauses that matter most:
- Breach escalation timelines, specifying how quickly the vendor notifies you after discovering an incident, not after confirming impact.
- Audit and penetration-test rights, giving your firm or its auditors the ability to review security evidence on a set schedule.
- Subcontractor flow-down, requiring any subprocessor to meet the same security obligations as the primary vendor.
- Data return and deletion terms, defining what happens to borrower records if the relationship ends.
- Encryption and liability responsibilities, stating clearly who is accountable if encryption is misconfigured or keys are mishandled.
Beyond the contract, ask for SOC 2 Type II reports, SSAE audit documentation for physical data centers, recent penetration-test summaries, and a current subprocessor list. Review these annually, not just at signing. A vendor that refuses audit access or gives vague answers about subcontractors is showing you the relationship's biggest risk before you have even signed.
Pro Tip: Put a calendar reminder on your vendor's attestation renewal date. Security postures change, and a report from three years ago tells you nothing about today.
Our piece on managing outsourced mortgage vendors walks through these contract essentials in more detail.
How do you know a vendor can actually recover from an attack?
Encryption and access controls protect data day to day, but recovery is the test that reveals whether a vendor's security program works under pressure. NIST's ransomware guidance is direct on this point: backups are not a recovery plan by themselves. They have to be protected from compromise and restoration has to be tested, with recovery objectives documented in writing.
Ask vendors for:
- Evidence that backups are immutable or isolated from the production network, not just copied to another folder.
- Geographic separation between primary data and backup storage.
- A recent, dated restore test report showing actual recovery time and how much data was recovered.
- An incident response playbook naming escalation contacts and a communications plan for affected borrowers and regulators.
Recovery testing at least annually, paired with at least two backup copies, is part of Freddie Mac's eMortgage disaster recovery guidance, a standard that applies whether the platform serves five loan officers or five hundred.
Ransomware resilience specifically depends on immutable snapshots that attackers cannot encrypt alongside production data, plus out-of-band communication channels so your team can coordinate if email and chat go down together. Regulatory notification timing under the FTC Safeguards Rule starts at discovery, not confirmation, so a vendor's incident response speed directly affects your compliance exposure.
What questions should you ask in a security-focused demo?
Walk into any vendor demo with a short document list and a handful of direct questions. The list first:
- Written risk assessment, current within the last twelve months.
- SOC 2 Type II or equivalent audit report covering the platform's infrastructure.
- Penetration-test summary from an independent third party, not an internal scan.
- Restore-test report showing recovery time and data scope from an actual exercise.
- Subprocessor list naming every subcontractor with access to borrower data.
- Incident response playbook with named escalation contacts.
Then ask these directly: Who manages the encryption keys, you or a third party? How are backups protected from the same attack that might hit production systems? Can you show a penetration-test summary from the past year? Can you demonstrate that one client's loan files are isolated from another's?
Score the answers by specificity. A vendor with real evidence points to dates, scopes, and named frameworks. A vendor without it hedges: "we take security seriously," "that's handled by our cloud provider," or "we haven't needed to test that yet." Vague timelines, outsourced key management with no contractual accountability, and refusal to share test summaries are the three clearest red flags in any RFP process.
Where do most mortgage security reviews go wrong?
Omar Khamisa has spent over 20 years in mortgage operations as a processor, underwriter, loan originator, and systems consultant before founding 1 Solution Mortgage Software. That vantage point exposes a pattern: firms often check the encryption box and stop there, never asking whether backups have been restored recently or whether tenant isolation has been tested at all.
The priorities that matter most in practice: verify restore tests before anything else, confirm tenant isolation has been independently checked, and insist on immutable logs with documented change control. A platform that cannot show you a recent restore report has not proven its backups work, no matter how strong its encryption looks on paper.
— Omar Khamisa
How should mortgage data be classified and handled?
Not every piece of borrower information carries the same risk, and treating it all the same way creates unnecessary exposure. Social Security numbers, bank statements, tax returns, and credit reports belong in the highest sensitivity tier, requiring encryption at rest, restricted access logs, and retention limits tied to regulatory requirements rather than convenience. Loan status updates and general correspondence can sit in a lower tier with lighter controls, though they still need encryption in transit.
A clear classification policy tells your team what data can move through email versus what must stay inside an encrypted portal, and it tells your software vendor what handling standard applies to each data type. Mortgage platforms that store everything in one undifferentiated database make it harder to prove compliance and easier for a single breach to expose the most sensitive records alongside routine notes.
Handling policies should also define retention and disposal. Loan files carry recordkeeping requirements that outlast the loan itself, but old marketing lists or expired pre-approval requests do not need to sit in active systems indefinitely. A platform that supports automated retention rules and secure deletion gives your compliance team a way to enforce these policies without manual cleanup, and it narrows the amount of exposed data if a breach does occur. Ask vendors directly how their system tags sensitive fields and whether classification rules can be customized to match your firm's own risk assessment rather than a generic template.
What secure development practices should mortgage software vendors follow?
How software is built shapes how secure it stays after launch. Vendors following a secure development lifecycle build security checks into every stage, from design through testing to deployment, rather than treating security as a final review before release. That means code review practices aimed at catching common vulnerabilities, staging environments that mirror production without exposing real borrower data, and a defined process for patching vulnerabilities once they are discovered.
Ask vendors how frequently they release security patches and whether critical vulnerabilities get expedited fixes outside the normal release cycle. A platform still running months-old patches when a critical flaw is public knowledge is a warning sign regardless of how strong its marketing claims are.
Secure coding practices addressing common web application risks, the kind cataloged by the OWASP project, should apply to every borrower-facing portal and internal tool alike. This matters more as mortgage platforms add features quickly: pricing engines, e-signature workflows, and communication tools each introduce new code that needs the same scrutiny as the core loan origination system. Ask whether new features go through the same security review as the original platform or whether they ship faster with lighter oversight. A vendor that treats every release, not just the initial platform, with equal rigor is managing risk the way a mortgage-specific system should.
How does employee training reduce mortgage data security risk?
The strongest technical controls fail if a processor clicks a phishing link or a loan officer emails a borrower's tax returns as an unencrypted attachment. Training specific to mortgage operations needs to go beyond generic cybersecurity awareness modules and address the situations your team actually faces: verifying wire instruction changes by phone before releasing funds, recognizing business email compromise attempts that impersonate title companies or borrowers, and knowing which systems are approved for storing sensitive documents.
New hires should complete this training before they get system access, not sometime in their first quarter, and refreshers should happen at least annually given how quickly phishing tactics evolve. Track completion the same way you track any other compliance requirement, because an untrained employee with full system access is effectively an open door regardless of how well the platform itself is secured.
Training also needs to cover what to do when something goes wrong. Employees who suspect a phishing attempt or notice unusual account activity should know exactly who to contact and how quickly, since early reporting shortens the window between compromise and containment. This connects directly to the incident response plan: a playbook is only useful if the people who first notice a problem know it exists and know their role in it.
What physical security should mortgage data centers have?
Cloud infrastructure does not remove physical security from the equation, it just moves the responsibility to the data center operator. Freddie Mac's eMortgage guidance lists physical security alongside encryption and access controls as a core requirement, and for good reason: a server rack with no access controls undermines every software-level protection built on top of it.
Ask vendors where their infrastructure is hosted and what physical safeguards apply, including badge-controlled entry, monitored surveillance, and environmental controls protecting against fire and power loss. Reputable cloud providers publish this information through their own compliance documentation, and a mortgage software vendor should be able to point you to it rather than shrugging off the question as someone else's problem. If a vendor cannot answer where your data physically lives, that is itself worth treating as a gap.
Balancing strict security with usability that originators can actually work with
Security controls that loan officers and processors find cumbersome get worked around, not followed. MFA prompts that interrupt every five minutes or permission structures that block legitimate work push people toward risky shortcuts. The fix is a phased rollout: introduce new controls in stages, gather feedback from the people using them daily, and adjust before requiring firm-wide adoption. Assign a qualified individual to own security decisions, with procurement acting as a checkpoint before any new tool touches borrower data.
What to ask for when you request a 1 Solution demo
Independent brokers evaluating any mortgage platform deserve evidence, not assurances, and that applies to us the same way it applies to every vendor in this guide. The platform was built by mortgage professionals with real industry experience, emphasizing the importance of procurement scrutiny as recommended in this article.
When you schedule a demo, ask us directly for:
- Our current risk assessment documentation.
- Independent penetration-test summaries.
- Restore-test results showing recovery time and scope.
- Details on how encryption keys and subprocessors are managed.
Request the evidence, compare it against what other platforms provide, and decide from there. You can schedule a demo or request documentation directly through our site.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
Sources
- FTC Safeguards Rule: What Your Business Needs to Know | Federal Trade Commission
- eMortgage systems security best practices (Freddie Mac)
- Implementing a Zero Trust Architecture (NIST SP 1800-35)
- Ransomware risk management: A Cybersecurity Framework 2.0 Community Profile (NIST IR 8374r1)
FAQ
What is the best mortgage servicing software?
There is no single best mortgage servicing software for every firm, since the right choice depends on loan volume, compliance requirements, and whether you need origination features bundled in or a standalone servicing tool. Evaluate any candidate against the security evidence described in this guide, including SOC 2 reports and documented restore testing, before comparing feature lists.
What is the 3-7-3 rule for a mortgage?
The 3-7-3 rule refers to older Truth in Lending Act timing requirements around disclosure delivery and waiting periods before closing, though TILA-RESPA Integrated Disclosure rules have since changed much of that timing framework. Brokers should confirm current disclosure timing requirements with compliance counsel rather than relying on the older rule as a complete standard.
What software do mortgage brokers use?
Mortgage brokers typically use a combination of a loan origination system, a customer relationship management tool, a pricing engine, and a borrower-facing point-of-sale portal, sometimes from separate vendors and sometimes bundled into one platform. Security requirements, including encryption, MFA, and vendor oversight, apply to every one of these tools since each handles sensitive borrower data.
What is the best CRM software for mortgage professionals?
The best CRM for mortgage professionals depends on how tightly it needs to integrate with your loan origination and pricing systems, since a disconnected CRM creates extra data handling points that each need their own security review. Look for role-based access controls and audit logging in any CRM the same way you would for a loan origination system.
How do I secure mortgage application data end to end?
Securing mortgage application data end to end means encrypting it in transit and at rest, requiring multifactor authentication for every user, enforcing role-based access, and logging every action taken on a file. It also means verifying your software vendor can prove these controls work through independent testing and documented restore exercises, not just describe them in a sales conversation.