Federated Third-Party Risk

This is the newest of the three methodologies. It grew out of the dependency tracking in Federated Cyber Risk: a vendor sits in the same dependency graph as everything else, and its changes are flagged the same way. Three things set the work apart:

• The other party is outside the organization. A vendor cannot be asked to take part the way a resource team or a shared service can. It is assessed from outside, on the assurance it is willing to provide.
• The work ends in a decision, not a plan. The result is a record of what the vendor does, where it falls short, and the conditions under which it is approved.
• You cannot fix the vendor's gaps. You can only offset them with controls of your own, or accept them.

1. Assess

   Use an assessment written for that type of vendor. The type carries the scope, including how sensitive the information involved is, so a low-impact software service is not assessed like a critical one.

2. Find the gaps and choose compensating controls

   For each gap, compensating controls are suggested. The assessor chooses among them and can add instructions specific to the organization.

3. Decide

   The vendor is approved, or approved with conditions. The conditions are the compensating controls, and the record keeps them together with their instructions.

4. Link the vendor to the resources that use it

   Each team that depends on the vendor inherits the assessment. The compensating controls arrive in that team's own plan as work to be done and tracked.

5. Watch for drift

   If a team's controls drift away from the compensations it was given, or the vendor's assessment changes, the plans that depend on it are flagged.

As elsewhere in the family, approval is a record and not a gate. Whoever carries out the assessment names the approver, or approves it themselves.

A compensating control is your own action to offset a gap a vendor leaves. After the agreement is signed you cannot add controls on the vendor's side, and anything the vendor already does is part of how serious the gap is. So the compensation is always yours.

• Suggested, not prescribed. Some controls are more likely than others to make up for a gap in another. Those known relationships produce the suggestions, and the assessor makes the choice.
• A starting set, extended locally. The security office supplies a default set of compensating controls and can add its own.
• The gap stays with the vendor. The compensating work lands in the plan of each team that depends on the vendor. The gap itself remains attributed to the vendor, so it is counted once and in the right place.

The same idea serves inside the organization, when a team cannot implement a control for technical or other reasons.

The vendor and the team that uses it are assessed separately, and neither assessment repeats the other.

A shortfall on the vendor's side never excuses a control. If a product lacks a capability, the team compensates for it or accepts the risk on the record.

The team that chooses to use a vendor owns the risk of that choice. It cannot pass that risk to the vendor, or to the security office.

A vendor is a node in the same graph as the organization's shared services. Linking a vendor to a resource is the same kind of link by which a plan inherits a common control.

• Assessed once, inherited many times. A vendor's assessment becomes a building block, like a verified shared service.
• Vendors behind services. A shared service can itself depend on a vendor, and a gap there reaches every plan that inherits from the service.
• Different ways in, one way of reading. A shared service documents its own inventory and is verified by the security office. A vendor is assessed from outside. Once in the graph, both are analyzed alike.

The graph itself is described under dependency tracking in Federated Cyber Risk.

• Before. Assess the vendor, decide, and record how security responsibilities are split between the vendor and the team.
• During. Follow the vendor's security advisories and act on them, keep the compensating controls in place, and keep the team's plan current as the service changes.
• After. When the agreement ends, see that information is returned or confirmed destroyed, and that connections to the service are removed.

All five principles of participation apply. Three do most of the work here:

• Automating the tedious. A vendor is assessed once and that assessment is inherited, not repeated by every team that uses the vendor.
• Knowledge at the point of decision. Compensating controls are suggested at the gap they answer, and a change at the vendor is flagged on the plans that depend on it.
• Psychological safety. A vendor's gap is recorded and compensated for in the open. “Approved with conditions” is an honest answer, and a better one than a clean approval nobody believes.

• Federated Cyber Risk. Compensating controls become tracked work in each team's plan, and Compliance Checkups treat a linked vendor as its own layer so that its gaps are assigned to it.
• Federated Practice Monitoring. The security office sees where vendors are concentrated, which assessments are aging, and where compensations have lapsed.

What is still being learned

Each organization that applies the methodology adds to what is known about it, especially about which compensating controls hold up in practice. That experience is folded back in as it arrives. If you put it to use, tell us what you find at inquiries@federatedcybersecurity.com.