What is the risk of a vendor whose compliance posture is weaker than yours?

Almanac Payroll runs payroll for mid-size companies, and its onboarding flow uses a vendor's AI tool to read scanned tax documents, W-4s, I-9s, foreign tax forms, and pull out the numbers. Fionnuala Byrne owns that onboarding flow. She keeps the vendor's two most recent security bulletins printed and clipped inside her notebook.

How to answer this, stage by stage

Six stages. A tradeoff question wants your pick first, then the reasoning, never the other way around.

Let's learn

Picture every tax document your payroll tool has ever processed sitting on someone else's shelf, under someone else's lock, and ask how much you actually know about that lock.

Almanac Payroll sends scanned tax documents to a third-party vendor's AI tool, which reads them and pulls out the numbers. Years ago, when Almanac's clients were mostly small, low-sensitivity accounts, the team defaulted to the vendor's cheaper standard tier, no dedicated encryption at rest, shared access logs across the vendor's other customers.

That default was cheap and invisible for a long time, because nothing went wrong. Then, within five weeks, the vendor disclosed two separate incidents: an access-control bug that briefly exposed a slice of client logs, and a breach at their own backup subprocessor.

At its worst: an employee's Social Security number sits in a vendor's backup, at a subprocessor Almanac never chose, exposed for hours before anyone outside the vendor even knows to look.

What I would leave alone: low-sensitivity fields, an employee's name, job title, start date, don't need the same treatment. Upgrading every field equally would just slow the whole pipeline down for no real reduction in risk.

The lesson: a vendor's compliance posture isn't a box you check once at signing. It's a number that can quietly get worse, on their end, while your own controls stay exactly the same.

Now here is the same thing as a story

The short version above is what you'd say defending this call to a board asking why costs went up. Read this one for how Fionnuala actually got there.

Every Monday, Fionnuala Byrne pulls up the vendor's status page out of habit, a small routine check that had never once turned up anything worth a second look.

The habit had been paying off in the sense that it never had to. For most of a year, documents flowed straight from Almanac's onboarding flow to the vendor's standard tier, unredacted, exactly as the integration had been built years earlier.

Five steps, and the second one, for a long time, simply didn't exist.

Then, on a Monday like any other, the vendor's status page showed something new: a disclosed access-control bug, since patched, that had briefly exposed a slice of client access logs. Five weeks later, a second disclosure landed, this time about the vendor's own backup subprocessor.

Almanac's own controls hadn't moved at all. The vendor's had, twice, in five weeks.

Two in a row was the whole trigger. Fionnuala didn't wait for a third. She pulled every field the vendor ever touched and sorted them by what actually happens if the vendor's weaker posture is the reason it leaks.

One box is small and known. The other is rare, and it's shaped nothing like the first one.

She ranked every possible path by cost against risk, not just against convenience.

Pre-redacting on the cheap tier turned out to sit almost as safe as the expensive tier, for a fraction of the cost.

She also went back and read what the vendor's own attestation actually promised, closely, for the first time since signing.

The vendor's attestation had a renewal date well past due. Nobody had checked it in two years.

With the fix, Social Security numbers and foreign tax IDs get redacted before any document reaches the vendor at all, and anything too messy to redact cleanly routes through the compliance tier automatically. A second incident within six months now triggers a full move to the compliance tier for every document, no exceptions.

Four numbers, and the second one is the one that started this whole redesign.

The old pipeline asked whether the vendor's tool worked. The new one also asks what happens to the data on the vendor's own worst day, not just Almanac's.

I defaulted to the standard tier because the price gap mattered more back when the client base was small and low-risk. It took two of the vendor's own disclosures in five weeks, not an incident of our own, to see that a vendor's compliance posture isn't fixed at signing, it can quietly slip while your contract stays exactly the same.

PICK, drawn outNot a comparison table. PICK is what forces you to commit to a position, then find the one cost that actually changes behavior.

The recap, one line per letter: position is pre-redact and route through the compliance tier rather than switching vendors immediately, impact is engineering's monthly cost against an employee's rare but severe exposure, cost asymmetry is optimizing against the hidden, expensive side, and kill criteria is two incidents in six months forcing the stronger tier automatically.

And if you want to be sure it really works, try it somewhere elseSame four letters, a travel-booking marketplace instead of payroll. This time the vendor screens for fraud, not tax documents, and the tradeoff runs the same shape anyway.

Farrow Travel uses a third-party AI vendor to screen bookings for payment fraud before confirming a reservation. Kwabena Sarpong manages that fraud-screening integration.

Mapped onto PICK: position is keeping the current vendor but stopping any full card number from ever reaching their basic-tier endpoint, using a tokenized reference instead, while routing only the flagged, harder cases through the vendor's stronger, audited endpoint. Impact is the token-only approach adding a small amount of screening latency, felt by customers waiting an extra second at checkout, against a card-data breach that would be felt by customers who never see the vendor's name at all. Cost asymmetry is that the latency cost is visible and constant, while a card-data breach is rare and catastrophic, both for customers and for Farrow's own ability to keep accepting payments at all. Kill criteria is a single disclosed card-data incident, of any size, immediately moving all bookings to the tokenized path, since payment data doesn't get the two-strikes leeway a lower-sensitivity field might.

A different vendor, a different kind of sensitive field, and the same corner of the chart still wins.

Swap the trigger and it still runs.
Speed: an interviewer caps you at a minute. Say "control what reaches the vendor, upgrade what you can't control, and set the line in advance for when that's not enough," and stop.
Cost: finance says the compliance tier is too expensive to roll out broadly. Start with just the highest-sensitivity fields, since that's where almost all the real risk concentrates anyway.
The model gets better, for real: if the vendor's own OCR accuracy improves, that's no reason to relax the redaction. A more accurate reader of unredacted Social Security numbers is still an unredacted Social Security number sitting on someone else's server.

Where people run it wrong.
They treat a vendor's compliance certification as a permanent fact checked once at signing, instead of a status that can quietly change.
They panic and rip out a vendor immediately after one incident, when a real kill line, stated in advance, is usually the steadier answer.
They upgrade every field to the expensive tier equally, instead of finding the small set of fields that actually carry the real risk.

How to use it live. When this question comes up, ask yourself what specifically reaches the weaker vendor, not just how weak the vendor is in general. The fix usually lives in controlling that, not in the vendor relationship itself.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0