How to see which subcontractor workers use your accounts

You can’t tell from your own records whether a subcontractor’s workers are in your systems. Your records show the user or shared login each person signed in with, and those carry the vendor’s name. Three habits narrow the gap. Have the vendor name your accounts when it reports a subcontractor. Give each subcontractor worker their own user. And compare your user lists with the vendor’s roster on a schedule. What subcontracting is, and what the rules ask of the vendor, is covered in What is subcontracting?

Why your records don’t show subcontractors

Subcontractor access stays hidden in two ways. A subcontractor’s worker signs in with a user you created for one of the vendor’s employees. Or the vendor passes a shared login you gave it to the subcontractor’s workers. In both cases, your app records the vendor’s user or the shared login. Nothing in the record says a third company was involved.

So everything you know about subcontractor access comes from the vendor. The rules give you a few hooks for getting that information. Under the CCPA, a vendor that engages another person to help process your consumers’ data must notify you and bind that person by written contract (Civil Code 1798.140(ag)(2)). Under HIPAA, your business associate agreement must require the vendor to report security incidents to you (45 CFR 164.314(a)(2)(i)(C)). NIST SP 800-53 control PS-7 asks you to require outside providers to report transfers and departures of their staff who hold your logins. The 2023 Interagency Guidance on Third-Party Relationships suggests that bank contracts settle when and how the vendor tells you it is using a subcontractor.

What to ask for in the subcontracting notice

The CCPA and the bank guidance say you should hear about a subcontractor. Neither says what the notice should contain. Add the account details yourself, in the contract or in your vendor questionnaire. Ask for these items:

1. The subcontractor’s company name and the names of the people who will do the work. You need names to match against your user lists.
2. The scope of the work. It tells you which permissions and data the subcontractor needs and which it doesn’t.
3. Which of your systems the subcontractor’s workers will use, and with which accounts. This is the starting point for every later check. If it is blank, you have nothing to compare.
4. How they get in: their own user, a vendor employee’s user, or a shared login. This decides whose name shows up in your records.
5. The start and end dates. The end date tells you what to shut off and when.
6. How the subcontractor records who used each account and when. If your records show only a shared login, this record is what you compare against.
7. How the subcontractor reports incidents to the vendor, and on to you, and whether it will cooperate with your investigation.

Ask for the notice before the subcontractor starts. If it arrives afterward, you can’t tell who was in your accounts during the gap.

Give each subcontractor worker their own user

In any app that lets you add users, create a user for each subcontractor worker. Don’t let them borrow a vendor employee’s user. Take requests through the vendor and create users only for the names you’ve approved. Your records then show the subcontractor worker by name, and at the end you can disable that person’s user without touching anyone else.

Shared logins are harder. Once a shared password has been passed on, you have little way to find out how far it went. Add one question to what you ask the vendor about each shared login: does anyone at a subcontractor know this password? The full set of questions is in What to check when a vendor says its team uses one shared login.

Compare your user lists with the roster

Put each app’s user list next to the roster the vendor gave you, covering both its own staff and the subcontractor’s workers. Each mismatch points somewhere:

• A user who is on your list but not on the roster: a subcontractor or staff change the vendor didn’t report.
• A name on the roster with no user of their own: that person may be signing in with a vendor employee’s user or a shared login.

Treat either one as unconfirmed until the vendor explains it.

Then look at sign-in records. A sign-in on a user you disabled means the shutdown didn’t take. A sign-in on a shared login outside the working hours the vendor reported may mean someone off the roster is using it. Covered financial institutions already have to monitor and log what authorized users do under the FTC Safeguards Rule (16 CFR 314.4(c)(8)). This comparison is one use of those records.

No rule covered here sets how often to compare. The FTC rule asks you to assess vendors periodically, based on their risk (314.4(f)(3)). The CCPA regulation gives audits or testing “at least once every 12 months” as an example of the checks your contract can allow (11 CCR 7051(a)(6)). One workable pattern is a check each time the vendor reports a new or changed subcontractor, plus a yearly check at renewal.

The vendor’s audit and your own check

Bank guidance looks at the vendor’s side. In due diligence, it suggests assessing how the vendor selects and oversees its subcontractors and makes sure they keep effective controls. A vendor’s audit of its subcontractor looks at the subcontractor’s practices and policies.

Your own check looks at something else. The vendor holds its roster, but only you hold your apps’ user lists and sign-in records. So the vendor’s audit can’t tell you who signed in to your accounts, and your comparison can’t tell you how the subcontractor runs its shop. You need both.

Under HIPAA, the vendor’s duties reach the subcontractor through a contract with the same terms as yours (45 CFR 164.504(e)(5)). Under the CCPA, a business that never enforces its contract or uses its audit rights may lose a defense it would otherwise have (11 CCR 7051(c)). Your user lists and sign-in records are the evidence you’d point to when you enforce those terms.