The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Evaluate mortgage software as a regulated third-party service, not as an ordinary business application. The lender remains accountable for protecting nonpublic personal information and loan data even when a vendor hosts, processes, or supports the system. A defensible review maps every data flow, rates the sensitivity and operational criticality of each workflow, verifies control evidence, and puts security, notification, audit, resilience, and exit obligations in the contract.
The practical test is whether you can demonstrate what borrower data the product touches, who can access it, how it is protected and monitored, what happens during an outage or breach, and how the data will be returned or securely deleted when the relationship ends.
What does a security and compliance evaluation of mortgage software cover?
A complete evaluation connects the software’s technical controls to the lender’s legal duties and actual mortgage operations. Review the product, its hosting environment, support model, integrations, subprocessors, and contract together; a strong application control cannot compensate for an unknown data processor or an impossible exit plan.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Data: borrower identity and contact details, credit information, income and asset documents, disclosures, underwriting outputs, communications, audit records, exports, backups, and logs.
- Workflows: origination, underwriting, document collection, disclosures, servicing handoffs, APIs, reporting, administrator functions, and customer support.
- People and systems: lender employees, contractors, vendor personnel, privileged administrators, integration accounts, identity providers, cloud infrastructure, and subprocessors.
- Lifecycle: collection, generation, transmission, storage, use, sharing, retention, backup, archival, return, and deletion.
- Business impact: confidentiality, integrity, availability, consumer harm, regulatory reporting, and the ability to continue lending if the service is unavailable.
The output should be a written risk assessment that names each material risk, the control that addresses it, the evidence supporting that control, the owner responsible for monitoring it, and the residual risk accepted by management.
#1 Best Overall
How do I map borrower data and critical mortgage workflows?
Start with a current data-flow and architecture description from the vendor, then validate it against your own implementation. Do not accept a generic diagram that omits support tools, analytics, backups, or subprocessors.
1. Build the inventory
For every field or file, record its source, purpose, classification, destination, retention period, and deletion method. Include data created by the software, not only data uploaded by a borrower. Credit decisions, audit trails, generated disclosures, and administrator logs can be sensitive even when they are not obvious personally identifiable information.
2. Trace every transfer
Document browser and mobile connections, lender-to-vendor APIs, credit-bureau or verification connections, email and messaging channels, batch exports, reporting feeds, support-session transfers, and subprocessors. Identify the hosting regions and whether data crosses national or state boundaries.
3. Identify access paths
List employee roles, customer administrators, vendor support staff, service accounts, emergency accounts, and automated integrations. For each path, specify authentication, authorization, approval, logging, review frequency, and revocation triggers.
4. Rate workflow criticality
Classify systems that originate, store, or transmit a complete loan file or underwriting decision as higher criticality than a low-risk marketing tool. Consider the effect of inaccurate data, unauthorized disclosure, or downtime on borrowers, closing deadlines, fair-lending obligations, and regulatory reporting.
5. Record retention and deletion
Ask how production records, replicas, snapshots, archived files, logs, and support exports are retained and deleted. Confirm how legal holds override routine deletion and how the vendor certifies completion.
Which regulations and frameworks should guide the review?
No single certification proves compliance. Use the applicable rules and frameworks to define the questions your institution must answer and the evidence it must retain.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
| Authority or framework | What it contributes to a mortgage-software review |
|---|---|
| Federal Reserve interagency information-security guidelines | Require institutions to identify and evaluate threats, assess likelihood and potential damage, determine whether controls are sufficient, mitigate risks, test the program, and update it. Contracts with service providers that access customer information must require confidentiality and proper disposal. |
| FTC Safeguards Rule | Requires a written information-security program with administrative, technical, and physical safeguards appropriate to the institution’s size, complexity, activities, and data sensitivity. The 2023 amendment added certain breach-reporting duties effective May 2024. |
| CFPB CMS-IT examination procedures | Focus examiner attention on board and management oversight, the compliance program, service-provider oversight, violations of law, consumer harm, and examination conclusions. A vendor failure can therefore become a consumer-compliance issue. |
| FFIEC Development, Acquisition, and Maintenance booklet | The September 29, 2024 update addresses governance, risk management, secure and resilient business services, and change management across the technology life cycle. |
| NIST SP 800-37 Rev. 2 Risk Management Framework | Provides a repeatable sequence: categorize systems and information, select and implement controls, assess controls, authorize operation, and continuously monitor. |
| New York Department of Financial Services Part 500 | For covered New York-regulated entities, requires risk-based third-party policies addressing provider identification, minimum practices, due diligence, periodic assessment, multifactor authentication, encryption, and event notification. |
| NYDFS third-party guidance, October 21, 2025 | Recommends examining access, data sensitivity, provider criticality, encryption, segmentation, SOC 2 or ISO 27001 attestations, penetration-test summaries, vulnerability remediation, subcontractors, data location, incident response, continuity, and secure offboarding. |
Use the framework that applies to your institution and document why a control is proportionate to the data and workflow. A smaller lender may use a simpler process, but it still needs evidence that the safeguards match the risk.
What evidence should a mortgage-software vendor provide?
Request evidence that is current, scoped to the service you will use, and detailed enough to reveal exceptions. A logo, slide deck, or unqualified statement that the vendor is “compliant” is not evidence of your control environment.
Independent assurance reports
Obtain the latest SOC 2 Type II report or ISO 27001 certification and its supporting statement of applicability where available. Read the covered services, facilities, control period, testing exceptions, complementary user-entity controls, management responses, and remediation plan. Confirm that the report includes the production region, support operation, and subprocessors relevant to your deployment.
Architecture and data-flow material
Require a current system diagram, data inventory, hosting locations, tenant-isolation design, backup locations, integration list, subprocessor list, retention schedule, and deletion process. Ask the vendor to identify which data is visible to support personnel and which tools are used for troubleshooting.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesSecurity testing and engineering records
Request a penetration-test executive summary, vulnerability-management policy, severity definitions, patch service-level objectives, dependency-management process, secure-development lifecycle, code-review practices, and evidence that critical findings were remediated. Ask how emergency changes are approved and reviewed afterward.
Operational and recovery evidence
Review incident-response playbooks, monitoring coverage, alert-triage procedures, forensic-preservation steps, customer-notification process, tabletop results, disaster-recovery test results, recovery-time and recovery-point objectives, backup immutability, and geographic redundancy.
How can I test identity, access, and tenant isolation?
Access controls should enforce least privilege and produce records you can review. Test both the vendor’s personnel controls and the controls available to your administrators.
- Role design: Separate borrower-facing, lender operations, support, developer, security, and billing privileges. Verify that a user cannot approve a transaction and administer the controls governing that transaction without an independent check.
- Joiner, mover, leaver process: Ask for documented approval, timely provisioning, role-change review, and prompt disablement when employment or assignment ends.
- Privileged access: Require just-in-time or otherwise limited elevation where feasible, approval for emergency access, session logging, and periodic entitlement reviews.
- Multifactor authentication: Confirm MFA for vendor and customer administrators, support access, remote access, and any path to customer information. New York requirements and FTC safeguards specifically identify MFA or equivalent protection for relevant access.
- Customer controls: Check whether your administrators can enforce SSO, MFA, password rules, session timeouts, IP restrictions, role approval, and rapid account suspension.
- Tenant isolation: Ask how database, object-storage, cache, search, analytics, logs, and backups prevent one lender’s data from appearing in another tenant. Request test or assurance evidence rather than relying on a product description.
- Logging: Verify immutable or otherwise protected records for sign-ins, privilege changes, exports, document views, configuration changes, support sessions, and failed access attempts.
How should encryption and key management be evaluated?
Confirm protection for every copy and channel, not merely the primary database.
- Require encryption in transit for browser, API, service-to-service, administrative, and support connections.
- Require encryption at rest for databases, object stores, file systems, backups, snapshots, exports, logs, and portable media.
- Ask who owns and administers keys, how keys are stored, how often they rotate, how access is separated, and how compromised keys are revoked and replaced.
- Verify that secrets, tokens, certificates, and integration credentials are stored in a managed secrets system rather than source code or ordinary configuration files.
- Determine whether your organization can supply or control keys for especially sensitive data, and understand the operational consequences of that choice.
- Ask how printed documents and paper records are protected and destroyed if the service or its support process creates them.
Encryption does not replace authorization, monitoring, or sound tenant isolation. It limits exposure when implemented across the full data lifecycle.
What secure-development and change controls matter?
Mortgage platforms change frequently through code releases, configuration updates, integrations, and model or rules changes. The vendor should show that changes are authorized, tested, traceable, and reversible.
Questions to ask
- Is there a documented secure-development lifecycle with threat modeling, code review, testing, and separation of development, test, and production environments?
- How are open-source and third-party dependencies inventoried, monitored, and updated?
- What are the patch deadlines for critical, high, and exploited vulnerabilities, and how are missed deadlines escalated?
- Are production changes approved by an independent person, logged, tested, and accompanied by a rollback plan?
- How are changes to underwriting rules, disclosures, integrations, or data schemas communicated to customers and tested for consumer impact?
- Does the vendor provide a summary of penetration testing and track remediation to closure?
The FFIEC development, acquisition, and maintenance guidance places governance, secure and resilient services, risk management, and change management in the same life-cycle conversation. Evaluate them together rather than treating a penetration test as a standalone answer.
What should the incident-response and breach process include?
Obtain a practical description of detection, containment, investigation, communication, and recovery. Contract language should cover incidents at the vendor and relevant subprocessors.
- Detection: Identify monitored systems, alert coverage, triage responsibilities, and escalation thresholds.
- Containment: Confirm how accounts, tokens, integrations, hosts, or tenants can be isolated without destroying evidence.
- Investigation: Require forensic preservation, access to relevant logs, root-cause analysis, and cooperation with your investigators and regulators.
- Notification: Define a deadline, communication channel, minimum content, update cadence, and responsibility for regulatory and consumer notices. Align the obligation with the FTC’s breach-reporting duties effective May 2024 and any state requirements that apply to your institution.
- Recovery: Establish restoration priorities, validation of data integrity, customer support, and a post-incident corrective-action report.
- Testing: Review tabletop exercises and recovery tests, including scenarios involving a subprocessor, compromised administrator, ransomware, corrupted backups, and loss of a hosting region.
Ask what evidence the vendor can provide after an event and how quickly it can identify affected borrowers, files, systems, and time periods. A vague promise to “notify promptly” leaves the lender unable to meet its own obligations.
How do I evaluate availability, backup, and business continuity?
Match resilience commitments to the mortgage workflow’s consequences. An uptime percentage alone does not tell you whether a loan file can be recovered or whether the service can be used during a regional failure.
Rank #4
| Area | Evidence and decision questions |
|---|---|
| Recovery-time objective | How long may the service be unavailable before a closing, disclosure, underwriting, or servicing obligation is missed? |
| Recovery-point objective | How much recently entered borrower data can be lost, and how is the stated point measured? |
| Backups | Are backups encrypted, immutable or otherwise protected from alteration, separated from production credentials, and regularly restored in tests? |
| Geographic redundancy | Can a regional outage affect both production and recovery copies? Which regions hold the data? |
| Manual fallback | What documented process lets staff continue critical work, reconcile later changes, and avoid duplicate or stale disclosures? |
| Communications | How are customers informed about an outage, estimated restoration, workarounds, and data-integrity validation? |
Require test dates, results, unresolved findings, and management ownership. Continuity planning is also compliance planning because an outage can cause missed notices, inaccurate records, or consumer harm.
Which privacy, retention, and AI-use terms belong in the contract?
Define permitted processing narrowly enough that the lender knows where borrower information goes and what the vendor may do with it.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Specify the services and purposes for which data may be used.
- Prohibit sale, unrelated marketing use, or use to train general models unless expressly authorized after a documented risk review.
- List hosting and support locations, cross-border transfers, and every material subprocessor.
- Require advance notice of subprocessor changes and a right to object or obtain an equivalent remedy when risk materially increases.
- Set retention periods for production, backups, logs, exports, and support copies, with a process for legal holds.
- Require return in a usable, documented format, migration assistance, access revocation, deletion of remaining copies, and written deletion certification at termination.
Ask whether data remains in disaster-recovery copies after a deletion request and when those copies expire. “Deleted from the application” is not the same as deleted from all controlled copies.
What security and compliance terms should I negotiate?
Make the vendor’s actual control environment a contractual commitment, with remedies when it changes.
- Security representations tied to identified controls and the service scope, rather than a generic compliance statement.
- MFA, encryption, key-management, logging, vulnerability-remediation, and secure-development obligations.
- Incident notice deadlines, required content, continuing updates, investigation cooperation, evidence preservation, and regulator access.
- Audit rights proportionate to risk, including access to assurance reports, penetration-test summaries, remediation updates, and relevant policies.
- Subprocessor disclosure, flow-down obligations, approval or objection procedures, and responsibility for subprocessor incidents.
- Data-location transparency and restrictions on transfers that affect legal or operational risk.
- Availability, recovery-time, recovery-point, backup, testing, service-credit, and termination rights when resilience fails.
- Cyber-insurance evidence where appropriate to the institution’s risk and the service’s criticality.
- Defined migration format, transition support, return and deletion deadlines, access revocation, and certification at exit.
Include a process for reviewing material changes to the vendor’s controls, ownership, hosting, subprocessors, or use of data. A contract that was adequate at implementation can become inadequate after an acquisition or architecture change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How can I compare mortgage-software vendors consistently?
Use a weighted scorecard before demonstrations or price negotiations. Weight security and resilience most heavily when a product handles complete loan files, underwriting decisions, or critical disclosures.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match| Scoring axis | What to compare |
|---|---|
| Assurance scope and exceptions | Report or certification scope, control period, exceptions, complementary user controls, and remediation quality. |
| Identity and tenant isolation | MFA, least privilege, privileged-access review, customer-admin controls, support logging, and segregation between lenders. |
| Encryption and key control | Coverage of transit, storage, backups, exports, logs, secrets, rotation, and ownership. |
| Secure engineering | Development lifecycle, dependency management, penetration testing, patch targets, change approval, and critical-finding closure. |
| Incident response | Monitoring, notification deadline, forensic cooperation, subprocessor coverage, exercises, and regulator support. |
| Recovery and resilience | Recovery objectives, immutable backups, geographic redundancy, test results, and manual fallback. |
| Privacy and location | Permitted use, AI or model-training restrictions, retention, deletion, hosting regions, and legal holds. |
| Subprocessor governance | Complete list, risk review, change notice, flow-down controls, and accountability. |
| Integration and auditability | API permissions, service-account controls, export logs, configuration history, and evidence access. |
| Contract flexibility | Audit, notice, remediation, service-level, insurance, termination, migration, and deletion terms. |
| Implementation effort and total cost | Security configuration, migration, training, monitoring, contingency work, and ongoing assurance effort. |
| Exit portability | Format, completeness, metadata, migration support, timing, and deletion certification. |
Score evidence quality as well as the claimed capability. “Planned,” “roadmap,” or “available on request” should not receive the same score as a tested, contractually committed control.
What are the most common red flags?
- A SOC 2 or ISO badge without the report scope, period, exceptions, or management response.
- A data-flow diagram that excludes backups, support tooling, analytics, APIs, or subprocessors.
- Shared administrator accounts, optional MFA, unlogged support access, or no documented leaver process.
- Encryption claims that omit exports, logs, backups, paper records, or key rotation.
- Penetration-test findings with no severity-based remediation target or evidence of closure.
- Incident language that says only “prompt notice,” with no deadline, content, investigation duty, or subprocessor coverage.
- Recovery objectives that are stated but never tested, or backups that share production credentials.
- No documented process to return all data, preserve metadata, revoke access, and certify deletion.
- Contract terms that let the vendor change subprocessors, hosting regions, or data uses without notice.
Escalate unresolved red flags to risk management and legal counsel. If the vendor cannot provide evidence for a critical control, record the gap explicitly and decide whether compensating controls or a different product are appropriate.
How often should the evaluation be repeated?
Perform the initial review before production use and refresh it according to risk. At minimum, reassess after a material architecture, ownership, hosting, subprocessor, data-use, incident, or regulatory change.
- Maintain the inventory, data-flow diagram, risk rating, contract, evidence register, and control owners.
- Review assurance reports and remediation updates when new periods become available.
- Monitor incidents, material outages, critical vulnerabilities, subprocessor changes, and failed recovery tests.
- Re-test customer-side controls such as MFA, role reviews, integration permissions, exports, and termination procedures.
- Report significant residual risks to the board or management committee responsible for information security and compliance.
- Update the written program and vendor requirements when the institution’s activities, size, technology, or data sensitivity changes.
This continuous approach follows the risk-management logic of the Federal Reserve guidance and NIST’s authorization and continuous-monitoring steps rather than treating vendor due diligence as a one-time questionnaire.
What should the final approval package contain?
Before approving the software, assemble a concise record that another reviewer can understand without repeating the entire diligence exercise.
- Approved architecture and data-flow map, including regions and subprocessors.
- Data classification and workflow-criticality assessment.
- Control matrix mapped to applicable regulations and internal policy.
- Assurance reports, test summaries, exceptions, management responses, and remediation commitments.
- Completed vendor questionnaire with evidence links or document references.
- Contract, security addendum, service levels, incident terms, and exit procedure.
- Open issues, compensating controls, risk acceptance, owners, and due dates.
- Monitoring plan stating what will be reviewed, by whom, and at what frequency.
That package demonstrates not only that the vendor was reviewed, but that the lender made a reasoned decision and can continue to supervise the relationship.
Frequently Asked Questions
Does a SOC 2 report mean mortgage software is compliant with GLBA?
No. SOC 2 describes controls tested against defined criteria and a specific period; it does not certify compliance with the Gramm-Leach-Bliley Act. The lender must map the report, exceptions, and its own responsibilities to the written safeguards program and document any gaps.
Where should borrower data be stored?
There is no single location that is right for every lender. Require the vendor to disclose production, backup, support, and subprocessor locations, then assess those locations against your legal, contractual, operational, and recovery requirements.
Recommended Free Tools
What should we do if a mortgage-software vendor refuses an audit right?
Ask for a risk-based alternative such as current independent reports, penetration-test summaries, remediation evidence, and regulator-access language. If the substitute cannot establish control effectiveness for a critical workflow, escalate the residual risk before approval.
How can a lender prove data was deleted after leaving a vendor?
Include a defined deletion schedule covering production, replicas, backups, logs, exports, and support copies. Require written certification identifying the systems covered, the completion date, legal-hold exceptions, and the process by which remaining backup copies expire.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
