Let’s just say “ba da ba ba ba, not lovin’ it.”

What the Paradox Hiring Bot Hack Teaches Us About Vendor Security

I want to start with a bit of snark because sometimes you need to grab attention.  Now, let’s be clear. I have no reason to think the actual auditors who conducted Paradox’s SOC 2 audit were incompetent; this isn’t about the auditor’s skills.  Does it call into question the skill of the developers and QA at Paradox who developed and tested the portal, clearly? The real lesson here is the scope of the SOC 2 audits.

A SOC 2 audit is only as strong as what the company includes in it. If you leave something out, like a custom-built portal for a giant customer, then no one reviews that part. No one asks hard questions about its security. That is the real lesson here.

What Went Wrong at Paradox

Security researchers found a serious vulnerability in the hiring platform Paradox, built specifically for McDonald’s, as published in an article from WIRED.

Inside that custom portal was an admin account with the username and password both set to “123456”. There was no multi-factor authentication at all.

Paradox said it was an old account they hadn’t used since 2019. But it was still live on the system. Anyone who tried “123456” could have logged in and seen millions of job applications containing names, emails, phone numbers, and entire chat logs.

To put this in context, even AOL in 2003 required users to pick stronger passwords. Back then, you needed at least six characters with both letters and numbers. “123456” wouldn’t have passed.

And it wasn’t just the password. Researchers found other weaknesses that made it easy to browse through all the applicant records once you were in.

This wasn’t one small mistake. It showed sloppy design, poor maintenance, and a clear lack of security reviews.

Why This Was So Dangerous

In this case, the vulnerable McHire portal seems to have been built just for McDonald’s. Other Paradox customers were likely unaffected. Paradox moved quickly to fix the problem, which probably kept the damage limited to McDonald’s data.

But there is a bigger question here. What if Paradox hadn’t properly separated McDonald’s data from other customers’ data?

Many vendors use multi-tenant systems. That means they store data for many customers in shared databases or infrastructure. If strong separation is missing, one security failure can open the door to everyone’s data.

And think about who this happened to. This wasn’t a small company. This was McDonald’s, one of Paradox’s biggest and most important customers.

You would think their top-tier client would get the highest level of attention. Every detail would be checked. Every risk would be reviewed.

If a vendor can deliver this level of sloppy security to McDonald’s, what does that say about how carefully they will handle your data if you are a smaller customer?

This is why even when something is built just for one customer, you still need to ask tough questions about how your vendor is isolating and protecting data.

A Lesson About Custom-Built Software

Here’s the other key point.

When a vendor says they are “SOC 2 compliant,” they usually mean their main, standard platform passed an audit. That is the product they sell to everyone.

But what about a custom-built system they create just for you?

That part is often outside the scope of their SOC 2 audit entirely.

SOC 2 auditors only examine the systems and controls that the vendor includes in the audit scope and system description. If the McHire portal wasn’t part of that defined “system,” then no one independently reviewed its security controls during the audit.

A separate audit of that custom portal likely would have caught a hard-coded “123456” admin password with no MFA.

This is not just a Paradox problem.

Any time a vendor writes custom code for you, it might skip all the security reviews and controls they built for their main product.

This is why buyers need to pay extra attention to anything custom-built.

Multi-Tenant Systems Need Strong Isolation

Even though this breach affected only McDonald’s data, it is a clear warning about why multi-tenant systems need strong isolation.

Vendors often store data for many customers in the same database or infrastructure. This approach saves money and is easier to manage, but it creates real risk.

If strong controls aren’t in place, one customer or an attacker can see another customer’s data.

The most common method to prevent that is Row-Level Security. This ensures that every database query or API call filters data by tenant ID so users only see their own records.

But smart vendors don’t stop there. They use multiple layers of isolation techniques to reduce risk even further.

Schema or Database per Tenant means instead of mixing all customers’ data in the same tables, each customer gets their own separate set of tables or even an entirely separate database. This lowers the chance of accidental data leaks across tenants.

Containerization or Virtual Machine Isolation means vendors can run each customer’s app in its own container or VM. This isolates the runtime environment so one customer’s app cannot interfere with or see another’s.

Encryption-Based Isolation means data can be encrypted using tenant-specific encryption keys. Even if data is stored together, separate keys keep one customer’s data private if another is compromised.

Dedicated Application Instances are sometimes used for big or regulated customers. This means completely separate app environments just for them.

Attribute-Based Access Control is another layer. Instead of relying only on user roles, ABAC policies check which tenant a user belongs to for every action they perform. This ensures even complex workflows or APIs enforce tenant separation.

The best vendors combine these methods. For example, Row-Level Security in the database, containerization for runtime isolation, encryption with tenant-specific keys, and ABAC policies in the application.

Each layer is designed to catch mistakes that the others might miss. Even if one control fails or is misconfigured, others reduce the risk of a full-blown data breach.

Plan for the future too. When evaluating a vendor, don’t just look at what data they access on day one. Vendors often expand their services over time and may handle much more sensitive data later. Their security needs to keep up with that growth.

Custom Software Means New Risk

When vendors build something custom for you, they are not just changing settings. They are writing new code.

That new code often has not gone through the same reviews, testing, or audits as the main platform. Even if the vendor’s main system is SOC 2 compliant, your custom solution may not be.

That is why you should treat custom software like a brand-new product.

You may need to require security reviews, penetration testing, code reviews, and independent third-party audits.

Don’t assume your vendor’s existing SOC 2 certification automatically covers the new custom system they build for you.

Matching Security to the Sensitivity of Your Data

Another important point is that the level of security you require should match how sensitive the data is.

For example, a recruitment marketing system at the top of the hiring funnel might only hold candidate names, email addresses, phone numbers, and resumes. That is personal data and deserves protection, but it is less sensitive than other types of data.

Now think about a system used for onboarding new employees. That might include Social Security Numbers, bank account details, tax forms, and legal IDs.

A breach in a system with that kind of data often triggers legal notification requirements, fines, and high costs to make things right, like paying for credit monitoring.

You cannot use a one-size-fits-all approach.

You should match security requirements to the risk.

Low-sensitivity data might need strong but simpler controls.

High-sensitivity data demands much stronger controls, such as encryption, multi-factor authentication, detailed logging, and strict access reviews.

And remember, it is not just about the data a vendor accesses today.

Many vendors start out handling only top-of-funnel recruiting work. Over time, they may expand into background checks or onboarding, suddenly gaining access to much more sensitive data.

You need to regularly review your vendor relationships. As their role grows, their security needs to grow with it.

Plan for the most sensitive data a vendor might handle in the future, not just what they handle today.

So What’s the Solution?

Does this mean you should never let a vendor build custom code for your company?

No.

Custom software can be valuable and even necessary. But you must make sure it is secure.

The solution is to make it clear in your contract that any custom code they build for you will be included in their SOC 2 audit.

You can require that any new custom work be added to the scope of their existing SOC 2 audit through an amendment or an additional audit. And you can make sure this cost is included in their proposal from the start.

That way, you are not just trusting that their main software is secure. You are making sure any custom code and security practices they use for you are also reviewed and audited to the same standard.

You may also want to think about setting up a tiered vendor security approval process based on the level of data sensitivity involved.

For example, you might treat basic candidate contact information as Level One. That would include things like names, emails, and phone numbers. The security requirements for those vendors might be strong but simpler.

If a vendor is handling more sensitive data, such as dates of birth, Social Security Numbers, bank account details, insurance information, or even 401(k) accounts, that would be a higher tier. Those vendors would need to meet much stricter security requirements.  If they are touching drug screen results or benefits information, then HIPAA audits come into play.

This kind of tiered approach is common in many companies. It helps you match your vendor security reviews to the actual risk.

By defining clear levels and requirements up front, you can make sure the security you expect scales appropriately with the sensitivity of the data involved.

Conclusion

The Paradox software vulnerability is a clear lesson in what can go wrong if you don’t ask the right questions.

“SOC 2 compliant” sounds great on paper, but it is only as good as what is actually in scope.

Ask vendors:

What exactly was included in the audit? How do you protect data in shared systems? How do you secure any custom-built solutions?

Do not assume. Do not skip these questions.

Making sure your contract explicitly covers custom code in the SOC 2 scope can save you from big headaches, high costs, and big breaches down the road. If you are going through software selection, we can help at StratTech Talent Consulting and Advisory.

Contributions to this article came from AI and Cluff, Jared, founder at Genkins Forge.