Why an access register matters
Carrier portals and agency systems hold client data, commission records, and policy documents behind a login. When several people share that access, no one can say who still has it or when it was last reviewed. A simple register, kept current, is the difference between a controlled handoff and a guess.
This register is administrative. It contains no passwords or secret values, and it does not replace your agency's written security procedures or the judgment of licensed staff.
What belongs in the log
Build the register as a plain table with one row per person and portal. Each row should name the portal, the person, their role, the date access was granted, and the date it was last reviewed. Do not record the password itself anywhere in the register or in a shared file.
- Portal or system name.
- Person and role.
- Date access was granted.
- Date of last review.
- Status, such as active, suspended, or removed.
Keep the same column order on every tab so a reader can move from one portal to the next without relearning the layout. A register that only one person understands is a register that will not be maintained. Record the business reason for the access, such as service, billing, or claims, so a reviewer can tell whether the level still matches the role. A person who changed desks may keep a login they no longer need.
Recording the MFA method
For each person, record which second factor the portal uses, without writing down any secret value. Note whether it is an authenticator app, a hardware key, or a code sent to a registered device. Then note who holds the recovery method for that account so a locked-out user is not stranded.
Keep the register in a location with restricted access and a record of who opened it. It should never become a single list that makes every portal easier to reach at once. If a portal offers role-based permissions, record the level each person holds.
Password rotation without shortcuts
Rotation is a calendar task, not a memory task. Set a review date for each portal and rotate shared access when the review comes due or when a role changes. Change one portal at a time and confirm the new login works before moving on.
Never send a password through a shared inbox or a group message, and never reuse the same password across carriers. The register records that rotation happened and when, not the value itself. If a portal supports personal accounts rather than a shared login, prefer that and record the individual holder.
Rotate after any event that might expose a password, such as a departing team member or a notice from the carrier. Do not wait for the calendar when there is a reason to believe the login is no longer private. Record the event and the rotation date together so the reason is clear.
The review cadence
Review the register on a fixed schedule, such as quarterly, and after any staffing change. For each row, confirm the person still needs the access, the second factor still works, and the review date is refreshed. Mark rows that are dormant so they can be closed rather than left open.
Assign one owner for the review so it does not become everyone's job and therefore no one's. A short written note of what changed during the review is enough. The point is a dated trail, not a long report.
Write the review date on the row even when nothing changed, because an unchanged row still needs a fresh date. An empty cell cannot tell a reader whether the row was checked or forgotten.
Offboarding a VA or staff member
Offboarding starts before the last day, not after it. Pull the register, list every portal the person can reach, and suspend each one as the replacement takes over. Record the offboarding date and the person who confirmed it.
- Suspend the login on every portal listed in the register.
- Remove the person's second factor from agency-held accounts.
- Transfer shared mailbox or document ownership to a named replacement.
- Confirm the suspension on the next review pass.
If the person held the only recovery method for a portal, name a new holder and test the recovery path before the account is needed in a hurry. A closure that is assumed is the same as an open door.
An assistant can keep this register current and run the reminders that keep it reviewed. If carrier access is scattered across shared logins, tell us how your agency tracks portal access and we will help you build the routine. To see how a trained assistant supports the rest of the desk, review our services.
Shared versus individual logins
A shared login is the fastest thing to hand out and the hardest thing to trace. Whenever a portal permits it, give each person a named account so the activity history points to a person rather than a group. Where a carrier still requires one shared sign-in, record who is expected to use it and treat rotation as an urgent task. Note the change in the register the same day it happens.
Keep a short record of every edit to the register, including who made it and why. When a portal adds a new permission level, update the register that same day. A register that lags behind the portals it describes gives the team false confidence. On a quarterly review, sample a few rows and confirm the access in the register still matches the access in the portal.
Scope and limitations
- This article is a practical administrative guide. It offers no legal, coverage, or tax advice, and it does not describe any real portal, product, or login.
- No passwords, recovery codes, or secret values appear in this article, and none should appear in an access register.
- Research limitation: no single authoritative source prescribes one access-register format. The structure here is a synthesis of common security practice, not a regulatory requirement.
Sources
- U.S. Federal Trade Commission - Safeguards Rule. https://www.ftc.gov/legal-library/browse/rules/safeguards-rule
- National Association of Insurance Commissioners. https://content.naic.org/
- Cybersecurity and Infrastructure Security Agency - Cybersecurity best practices. https://www.cisa.gov/