It Worked as Designed. That Was the Problem: A Lesson in Cross-Functional Controls

This is a real example from my role as Director of People Operations at LogicManager. We’re sharing it because risk management isn’t theoretical here. It shows up in how we evaluate processes, challenge assumptions, and work across teams to strengthen controls before issues escalate.

At LogicManager, risk management isn’t just something we deliver to customers. It’s how we operate.

Recently, while reviewing a payroll-related process with a third-party provider, we came across something that looked completely fine on the surface.

The process worked.
The system accepted the input.
Nothing was technically “broken.”

And yet, there was still risk.

Because the control wasn’t designed to catch a very normal, very human mistake.

In a standard transaction scenario, we saw that the system validated the input as acceptable, but didn’t verify that it was actually correct.

From a People Ops perspective, that immediately goes beyond payroll. It becomes a trust issue.

And it also became a cross-functional conversation with Finance to understand the exposure and where stronger controls were needed.

As the Assistant Controller at LogicManager put it: “The real concern wasn’t just the input itself. It was that there wasn’t a secondary check in place to catch it before it moved forward.”

That’s the real risk.

Because in practice, most operational risk doesn’t come from bad intent. It comes from small, human mistakes moving through systems that weren’t designed to catch them.

Where Risk Actually Shows Up

This is where cross-functional ownership matters.

From a People Ops perspective, the priority is simple: employees need to be paid accurately and on time. When that’s at risk, even briefly, it becomes a trust issue.

From a Finance perspective, the focus is on making sure controls actually work, not just that processes run.

When those perspectives come together, you start to see risk more clearly:

• where processes rely too heavily on manual input
• where validation confirms something is possible, but not necessarily correct
• where recovery paths are unclear or don’t really exist
• where third-party workflows quietly become part of your own control environment

These aren’t edge cases. This is where risk shows up day-to-day.

Controls should be designed for how people actually behave, not how we expect them to behave.

What This Reinforced

A few things became very clear.

1. Human Error Is a Given, Not an Exception: If a process depends on perfect input, it is fragile by design. Controls need to assume mistakes will happen and prevent them from creating downstream impact.
2. Validation Needs to Go Beyond Format: Just because something is valid does not mean it is correct. Effective controls validate intent, not just structure.
3. Recovery Is Part of the Control Environment: When something goes wrong, the speed and clarity of recovery matters. Without defined recovery paths, minor issues can escalate quickly.
4. Vendor Controls Are Still Part of Your Risk Environment: When you rely on a third-party system, you are not outsourcing risk. You are inheriting a dependency. If their controls miss something, you still own the outcome.

Turning Insight Into Action

What matters here is not that a control weakness could exist in a critical workflow. What matters is recognizing it early enough to do something meaningful about it.

That’s where the cross-functional partnership between People Operations and Finance mattered. Glenn and I were aligned from the start that this was not just a process observation. It was a risk management issue with broader implications for control integrity, employee trust, and third-party accountability.

Rather than treating it as an isolated scenario, we evaluated it through a risk-based lens: what control should exist, what exposure remained if it did not, and what the downstream consequences could be if the gap were left unaddressed.

That conversation extended beyond our own review. We engaged directly with the third-party provider to share the control concern and outline the type of verification and secondary review mechanisms that best practice would call for in a high-trust process like payroll. That conversation contributed to discussions around enhancing validation and secondary review mechanisms in line with industry best practices. 

The point was not simply to flag an issue. It was to advocate for a stronger control environment.

Because when a vendor supports critical financial and employee-facing workflows, weak validation does not just create the possibility of an isolated error. Left unaddressed, it can create broader operational exposure, damage client trust, and introduce reputational and legal risk that is far more difficult to recover from later.

That is what a proactive, risk-based culture looks like in practice.

It means identifying exposure before it escalates, evaluating it from multiple functional perspectives, and using that visibility to push for stronger controls, even when the process sits partly outside your own walls.

Why This Matters

This kind of risk isn’t rare.

Most organizations relying on payroll systems, vendors, or operational workflows are exposed to it in some form. And it usually doesn’t show up as a major failure. It shows up as a small breakdown at exactly the wrong moment.

Payroll control weaknesses are not trivial. Research cited by payroll providers and industry studies shows that 1 in 5 U.S. payrolls contains errors, with each correction costing an average of $291 per correction. Alight’s 2024 Company Payroll Complexity Report also found that 53% of surveyed companies incurred payroll penalties in the last five years for non-compliance. And when it comes to payroll tax deposits, the IRS makes clear that penalties apply when employment taxes are not deposited on time, in the right amount, and in the right way. In other words, even a small validation gap can create operational, compliance, and trust exposure.

From a People Ops perspective, this is where it becomes real.

Employees are counting on payroll to work every time. When it doesn’t, even once, it raises a simple question:

Can I rely on this organization to get the basics right?

That’s what makes this more than operational. It’s personal.

Bringing It Back to Risk Management

What this reinforced for me is simple.

Risk management isn’t theoretical. It shows up in everyday processes, in vendor relationships, and in the moments your teams rely on most.

At LogicManager, we apply that mindset across teams, processes, and third-party relationships so issues are identified earlier and addressed before they escalate.

Because strong risk programs don’t just document risk.

They make sure things actually work.

Learn how LogicManager helps teams turn risk insights into action →