The BPO Data Access Checklist Every Agency Should Use

The real risk is the access model, not the org chart

Ask an agency principal who can view a client's declarations page and the answer is usually "our service team." Ask which named account each person signs in with, what it can delete, and how fast it can be switched off, and the answer gets vague.

That gap is where most outsourcing risk sits. It is rarely a dramatic breach. It is a shared EZLynx login three people use, a loss run in someone's Downloads folder, a former contractor whose carrier portal password still works four months after their last shift.

Most of that gap closes with plain operational discipline, before the remote team's first shift rather than after. Below is the diligence checklist to run on any BPO partner, and the standards worth writing into the agreement instead of assuming. This is operational guidance, not legal advice: have your own counsel and your errors and omissions carrier review final contract language.

Step 1: Inventory the data before you scope the role

You cannot apply least privilege to a job description. You can apply it to a list of records. Write down what the remote team will touch in a normal week, then scope access to that list and nothing wider. For a commercial lines servicing pod, the list usually includes:

• Policy documents: declarations pages, endorsements, binders, certificates of insurance, change requests
• Underwriting inputs: ACORD 125, 126 and 140 applications, loss runs, supplementals, driver and vehicle schedules
• Personal identifiers: dates of birth, driver license numbers, and on personal lines applications, sometimes Social Security numbers
• Financial data: payment history, direct bill and agency bill balances, premium finance agreements
• Claims material: first notice of loss submissions, adjuster correspondence, photos and estimates
• Credentials: carrier portal logins, rater logins, client-owned tooling accounts

Two categories deserve separate treatment. Card and bank details should never route through a servicing inbox, and Social Security numbers should appear only in fields an application genuinely requires. If your intake puts either into email, fix that before you fix vendor access.

Step 2: Least privilege inside the agency management system

Every major agency management system supports role-based permissions. The problem is that most agencies have two roles in practice: administrator and administrator. Build a servicing role that matches the work. Permission names differ across AMS360, Applied Epic, EZLynx, HawkSoft, QQCatalyst and NowCerts, but the shape of the role is consistent:

Three rules matter more than the grid itself. Deletion, merging and anything financial stays in-house. Bulk export rights are a separate decision from view rights, and most servicing roles do not need them. Review the role quarterly, because permissions accumulate every time someone gets unblocked in a hurry.

Named accounts, always

Each remote team member gets their own AMS account under their own name and email address. No shared logins, no "temp1" accounts, no reusing a departed employee's credentials because the license was already paid for.

Named accounts make every other control work. Without them, your audit log says a certificate was reissued incorrectly but not by whom, and offboarding one person means changing a password for six.

Require multi-factor authentication on every account that reaches client data: AMS, email, CRM, password manager. Authenticator apps or hardware keys beat SMS codes.

If you cannot revoke a person's access to every client system within one business day and produce a log showing what they touched last, you do not have an access model. You have a habit.

Step 3: Decide where the data is allowed to live

The most useful architectural decision is whether client data ever lands on the remote workstation. Two patterns are common, and both are defensible if chosen deliberately.

Browser-based access into your systems. The team works inside your AMS, email tenant, and ticketing tool through a managed browser profile. Data stays in your systems and the local machine is only a window. Simpler to run, and it fits most servicing work.

Virtual desktop access. The team connects to a hosted desktop where downloads, clipboard, and local printing are restricted at the session level. Heavier to administer, and worth it for high volumes of sensitive personal lines data or when a client contract requires it.

Either way, workstation standards belong in the agreement:

• Company-provided or company-managed devices only, with full-disk encryption enabled
• Screen lock after a short idle period, and a written ban on local storage of client documents
• Endpoint protection and current operating system patch levels, verified rather than promised
• No personal cloud storage, personal email, or personal messaging apps used for client work
• Private workspace during shift hours: no screens visible to others, no photography of screens, headsets for calls
• Physical documents avoided entirely; if printing is ever required, name the exception and the disposal method

Ask how each is enforced and checked. "We tell our team not to" is not enforcement. A managed device policy, a monthly attestation, or a supervisor spot check is.

Step 4: Solve the carrier portal credential problem honestly

Carrier portals are the weakest link in most agency access models, because many still issue one login per agency rather than per user. That conflicts with named accounts, and pretending otherwise is how credentials end up in spreadsheets.

Practical handling:

1. Request individual portal users wherever the carrier supports it, even if it takes a service request.
2. Where only a shared login exists, store it in a password manager vault with per-user access and no plaintext copies anywhere else.
3. Grant vault access by role, so a team member sees the five carriers they work in, not all thirty.
4. Log who holds which vault items, and rotate shared credentials when someone leaves or changes assignments.
5. Keep the password manager under your agency's ownership, not the provider's, so you can revoke access without asking anyone.

Step 5: Put the standards in writing

Confidentiality language should sit at two levels: with the provider as an entity, and with each individual assigned to your account. Ask to see both, and ask whether the individual agreement survives that person leaving.

Clauses worth negotiating:

• Confidentiality and nondisclosure covering client data, with obligations that survive the engagement
• A named data handling standard referencing the access model, device rules, and prohibited storage locations agreed above
• Notification obligations: who tells you, within what window, and with what detail if a device is lost or an account may be compromised
• Subcontracting restrictions, so work is never passed to a party you did not diligence
• A return-and-destroy obligation at termination covering documents, credentials, and local copies
• Cooperation with your audits, including the right to request access logs and evidence of offboarding
• Clear allocation of responsibility for insurance coverage relating to data incidents, reviewed with your own broker

Do not treat security marketing as diligence. Ask for the specific practice, the person accountable for it, and the record that proves it happened.

Step 6: Evidence, from monthly review to offboarding

Two controls turn everything above into something you can prove.

Audit trails you will actually read

An audit log nobody opens is documentation, not a control. A monthly review covers four things: user list versus current roster, permission changes since the last review, failed login spikes, and bulk export events. As an illustrative sizing exercise, assume 30 system users across the AMS, email and CRM, and 90 seconds per user to confirm each account is valid and correctly scoped. That is about 45 minutes, plus perhaps 20 minutes to scan permission-change and export events. Treat those as planning assumptions for your own estimate, not measured results from any engagement.

Book it as a recurring calendar item with a named owner. Reviews that depend on someone remembering do not happen.

Offboarding within one business day

Departures are where access controls are actually tested. Write the sequence down once so it is never improvised.

1. Disable, do not delete, the AMS account, so audit history stays intact and attributable.
2. Revoke email and single sign-on sessions, and force-expire active tokens rather than only changing the password.
3. Remove password manager vault access and rotate every shared carrier credential the person could reach.
4. Reassign open activities, tickets, and pending endorsement requests to a named person the same day.
5. Confirm device return or remote wipe, with written confirmation that local copies were destroyed.
6. Record the date, the actions taken, and who performed them, where an auditor or client could be shown it.

Ask what your provider's standard offboarding window is, who initiates it, and what happens when someone leaves on a Friday afternoon.

Where to start

You do not need a full security program to be materially better protected in a week:

1. Pull your user lists this week. Export current users from your AMS, email tenant, and CRM, and flag every account that is shared, unnamed, or belongs to someone who no longer works with you.
2. Build one servicing role. Define it using the grid above, apply it to a single remote team member, and adjust for two weeks before rolling it wider.
3. Move shared credentials into an agency-owned password manager. Start with carrier portals, then delete the spreadsheet.
4. Write the offboarding sequence on one page. Assign an owner, and test it the next time anyone changes assignments.
5. Send your provider the five hardest questions. How access is provisioned, how devices are verified, who initiates offboarding, what gets logged, and who you call at 6 p.m. on a Friday.

A provider that answers those precisely is showing you their operating discipline. One that answers with adjectives is showing you something too.