Table of contents
Lender portals are the front door to pricing, conditions, disclosures, and status. When the person who owns a portal login leaves, the team often discovers the problem during a closing week. The password is in a personal password manager, the recovery email belongs to a former employee, and nobody knows which user account is the admin. A written handoff prevents that scramble.
The handoff is not a list of passwords in a shared document. It is a record of who has access, which role they hold, how access is recovered, and when it was last reviewed. The record should live in an approved access system, not in a spreadsheet on a shared drive. This guide explains what to capture and how to test the handoff before it is needed.
Inventory every portal and its owner
Start with a complete list of the portals the team uses. Include the lender portals, the loan origination system, the document platform, the e-signature tool, and any vendor sites that hold file data. For each one, record the business owner, the technical contact, and the person who can approve a new user. Sort the list by how often the portal is used so the highest-risk accounts are reviewed first.
Do not stop at the portals the team uses every day. The rarely used portals are the ones most likely to lose their owner. A home equity investor site or a state housing program portal can sit untouched for months and then become urgent. The inventory should include every site that can change a file or expose borrower data.
Review the inventory with the operations lead and the security owner. Confirm that each portal has a named backup and an approved recovery path. A portal with no listed owner should be treated as an open risk. The mortgage operations support lead can maintain the inventory as part of the access review.
Record roles instead of passwords
The handoff record should describe roles, not secrets. Name the account type, the permissions it holds, and the tasks it supports. A processor account may submit conditions but not change bank details, while an admin account may manage users. The role tells the next person what the account can do and why it exists.
Passwords belong in the approved password manager with sharing controls, not in the handoff document. The handoff should say where the credential is stored and who can release it. It should also name the recovery contact and the approved method for a reset. A document that contains a password becomes a permanent liability.
Use individual accounts whenever the portal allows it. Shared logins make it impossible to tell who submitted a document or changed a setting. If a lender requires a shared account, document the reason and the compensating control. The control might be a named operator log that records who used the account and when.
Capture recovery details before they are needed
Recovery is where most handoffs fail. The recovery email may point to a former employee, the phone number may be a desk line that no longer exists, and the security questions may reference a pet nobody remembers. Capture the recovery email, the phone number, and the person who controls them. Test the recovery path during a quiet week, not during a closing.
If a portal supports multi-factor authentication, record which device or method is enrolled and who holds it. Do not enroll a personal phone without a plan for transfer. Use a team-owned method where possible, and document how a new user is added. The recovery plan should survive a lost phone as well as a departing employee.
Store the recovery record with the access inventory, not in the portal notes. Limit who can read it to the people who administer access. Review it whenever a role changes. A recovery detail that is six months old is a guess, not a plan.
Define the transfer steps for a departure
Write a short checklist for the day a team member leaves or changes roles. The checklist should list the portals to review, the accounts to disable, the credentials to rotate, and the owner who confirms each step. It should also name the person who will take over each portal. A departure checklist turns a vague worry into a sequence.
Start the transfer before the last day when possible. Ask the departing person to walk through each portal with the new owner and to confirm the recovery details. Record the walkthrough and the date. If the departure is sudden, use the inventory and the recovery record to reconstruct access.
Rotate credentials that the departing person could access. Do not assume that disabling the account is enough, especially for shared logins or API keys. Check the portal's audit log for recent changes and confirm that no pending user invitations remain. The security owner should sign off on the completed checklist.
Test the handoff with a dry run
A handoff that has never been tested is a hypothesis. Pick one portal and ask the backup to complete a routine task using only the written record. The task might be downloading a condition list or submitting a status update. Watch where the backup gets stuck and update the record.
Run the dry run at least twice a year and after any major portal change. A lender can change its login flow, its multi-factor method, or its user roles without much notice. The record should be checked against the current portal, not against last year's screenshot. A short test is cheaper than an outage.
Keep a log of the dry run, including the portal, the task, the tester, and the result. Note any step that required a call to support. Those calls are the gaps the record should close. The loan processing support team can run the dry run as part of a quarterly access review.
Review access on a fixed cadence
Access drifts when people change roles and nobody removes the old permissions. Review the portal inventory every quarter and confirm that each user still needs the role they hold. Remove access that is no longer required and document the removal. A quarterly review is easier to maintain than a yearly cleanup.
Pair the access review with a review of the handoff record. Check that the owner, backup, recovery contact, and password manager entry are still current. Update the record and note the date. A record that is reviewed but never updated is a false comfort.
Report the review result to the operations lead in a short summary. Include the number of portals reviewed, the number of access changes, and any open gaps. Set a date for each gap and name the owner. A visible follow-up keeps the review from ending with a list of intentions.
The Federal Trade Commission's data security guidance explains why access should be limited and monitored. A portal handoff supports that principle when it records roles and recovery without exposing credentials. It also gives the team a calm path through turnover. Recheck the handoff after any portal change, because a new login flow can invalidate the recovery steps.