The compliance conversation is missing the people who could actually fix it

We'll be an hour into a conversation about a compliance requirement. The security team is walking through a control, everybody's tracking, and then somebody says "well, we'd have to check with the mainframe team on that one." Or the cloud team. Or whoever owns the file shares now. And you can feel the whole thing go sideways, because the people who could actually answer the question aren't on the call.

Banks, insurers, healthcare systems. Different companies, different sizes, same moment.

That's nobody's fault. No one sat down and designed it this way. But it's expensive, and I've watched it turn a straightforward compliance project into an eighteen-month conversation more than once.

So I want to lay out what I think is really going on, because I don't think it's a communication problem and I don't think another meeting fixes it.

Let's skip the acronym for a minute

Governance is who decides and who's accountable. Risk is what could go wrong and how much of it you're willing to live with. Compliance is proving both of those to somebody outside your company who has the authority to fine you.

Here's the part I think gets lost. GRC doesn't secure anything. It produces evidence that something was secured. The framework says a control needs to exist. Somebody else still has to go make it true, on a real system, in production, on a Tuesday afternoon when three other things are already on fire.

That distance between the control on paper and the control in the environment is what people mean by the GRC compliance gap. In most organizations it's wider than the audit report suggests.

Why it always lands on the security team

Three reasons, and honestly none of them are wrong.

The auditor knocks on the CISO's door. External audits, regulator correspondence, customer security questionnaires, the remediation plan — all of it routes through security. So security becomes the office of record whether or not that was ever the plan.

Frameworks are also written in control language, and security is the team trained to read it. PCI DSS, HIPAA, GLBA, ISO 27001, NIST, CMMC. These are documents about control objectives. They are not documents about how to configure a storage array or schedule a batch job.

And a security team can attest that a control exists without owning the system that control runs on. That's the quiet part, and it's the one that matters. An attestation is a statement about somebody else's environment.

Put those three together and you get a security leader holding complete accountability with almost none of the authority. They own the finding. They don't own the fix. I've met a lot of those people and I have enormous respect for how they carry it.

The infrastructure team is in scope. They just weren't invited.

Every control statement, underneath all the framework language, is a fact about a system that somebody else runs.

Take the PCI requirement that account numbers be unreadable anywhere they're stored. That isn't something a security leader can do from a desk. That's a DBA, a storage admin, a systems programmer, a cloud engineer. Four people, four reporting lines, four different sets of priorities this quarter.

The GLBA Safeguards Rule is the one I'd point to if I could only pick one. It calls for encryption of customer information at rest and in transit. It also says that if you determine encryption is infeasible somewhere, you can use an effective alternative control instead, as long as your Qualified Individual reviews and approves it.

Read that twice, because it's where a lot of older systems quietly come to rest. The exception is legitimate and it exists for good reasons. But the written justification is what the auditor actually reads, and the person signing it is almost never the person who could have made encryption feasible in the first place. One team documents the exception. A different team owns the system that created the need for it. They rarely meet.

HIPAA has the same shape, and it's the one that surprises people. Encryption there is addressable, not required, which means an organization can implement it or document why an alternative is reasonable for their environment. Guess which team writes that memo, and guess which team would have had to build the alternative.

And here's the piece I'd want every security leader to sit with for a second. Infrastructure teams get measured on uptime and delivery speed. Not on audit findings. So a compliance requirement shows up on their board as work handed down by a leader they don't report to, competing against a release date somebody is already unhappy about. That work loses. It loses every time. Not because anybody's careless, but because we asked them to care about something we never put on their scorecard.

The mismatch nobody designed on purpose

Everybody calls this a silo problem, which makes it sound like it gets solved with a standing meeting on Thursdays. It doesn't, and I think I finally understand why.

Compliance is written about data. Companies are organized around systems.

Read any framework. They name data types. Cardholder data. Protected health information. Customer financial information. Controlled unclassified information. Not one of them says "protect the mainframe" or "protect the storage buckets."

Now look at an org chart. It's built by platform. An endpoint team. A cloud team. A database team. A mainframe team. An applications team. So one obligation about one data type gets split across five groups who share a leader somewhere up around the CIO and share almost nothing below that. Different tools, different vocabulary, different definition of done.

Then the data moves, because that's what data does. A record leaves the mainframe as an extract. The extract becomes a CSV. The CSV lands on a file share. The file share syncs to OneDrive. Somebody attaches it to an email. One copy seeds a test environment and another feeds an analytics pipeline.

That's six handoffs, and every one of them crosses a team boundary. The control almost always stops at the first one. The data doesn't stop at any of them.

Which means you can have an organization where every single team is doing its job correctly and the obligation still isn't met, because nobody owns the thing the regulation is actually about.

What changed, and why I'm writing this now

None of this is new. Org charts have looked like this for thirty years, and companies have muddled through, because data used to move slowly and mostly by hand. Somebody had to decide to make the copy. That gave governance time to catch up, or at least time to look like it had.

That's over.

Every AI initiative in your company is, underneath the demo, a data movement project. Pipelines pull records across every one of those team boundaries at machine speed, make copies nobody requested, and land them in stores nobody inventoried. A model doesn't stop to ask who owns the file share. And each of those copies is a new place your regulated data lives, created faster than any quarterly review can find it.

So the structure didn't get worse. The traffic through it did. A mismatch you could live with when data moved at human speed is a different thing entirely when it moves at machine speed, and I think that's why this is landing on so many people's desks at once right now.

Where I watch it cost the most

Every enterprise has one silo that runs deeper than the rest, and in regulated industries it's usually the IBM Z or IBM i team.

They report through infrastructure or operations, not security. They speak RACF and JCL and datasets to a security team that speaks IAM and buckets and endpoints. The bench is small and often partly outsourced. And they are sitting on the most regulated data in the company. Core banking records. Claims history. Policy administration. Payment files.

Most modern data security tooling never reaches them. So when the CISO pulls the coverage dashboard, the mainframe doesn't show up as risk. It shows up as nothing at all.

A blank reads as compliant right up until an auditor asks the question directly. Then it reads as a finding, and usually one that's been sitting open for years.

What I've actually seen work

Three things, in this order. The first two cost less than people expect.

Agree on the data before you argue about the controls. Security and infrastructure will argue about controls forever, because a control is a judgment about somebody's environment and nobody enjoys being told about their own environment. They won't argue about a map. Where the regulated data actually lives, what type it is, and how much of it there is, is a fact. Facts end meetings a lot faster than opinions do. Run discovery across every surface at once, including the ones with no modern dashboard, and put the output in front of both teams. Half the time the map itself is the intervention, because the mainframe team has never seen what happens to their data after it leaves them.

Measure compliance by data, not by team. Most compliance reporting is organized by control and by owner, which quietly turns every review into a performance review. Report by data type and location instead. Cardholder data: covered on the mainframe, partly covered on file shares, unknown in the cloud analytics environment. Now nobody's on trial, everybody's looking at the same picture, and the gaps are specific enough that an infrastructure lead can put them on a sprint.

Attach the control to the data, not to the platform. This is the one that holds. If protection lives in the platform, it has to be rebuilt by every team that touches the data, and it fails at the first handoff where somebody forgot. If protection lives in the data itself, through encryption and masking and classification that travel with the file, it survives every handoff automatically. The file doesn't care whose server it's sitting on or which budget paid for the storage.

Which is the whole point, really. You don't have to merge the silos. You have to stop asking the org chart to carry the control.

You don't have to merge the silos. You have to stop asking the org chart to carry the control.

That's a much smaller project than reorganizing a company. It's also the only version of this that works when one of your silos is a mainframe team that isn't going anywhere.

And to answer the question I get asked most

Where does that conversation actually happen?

The organizations I've watched do this well have a standing review, usually quarterly, where security sits down with every infrastructure owner and they all look at the same map. Not a status meeting. One artifact on the screen, updated since the last time, and two questions: what moved, and what's still uncovered.

It works because nobody has to arrive with a position to defend. The map is the agenda. And it turns out people who've been talking past each other for years get along fine when they're looking at the same picture instead of at each other's decisions.

What this doesn't fix

I want to be straight about the limits, because I've been on the other side of a pitch that promised everything.

Attaching protection to the data closes the control families that are actually about the data: encryption, masking, retention, exposure, what a copy is worth to somebody who shouldn't have it. It does not patch a server. It does not clean up an over-permissioned access role, segment a network, or write your incident response plan. Those stay exactly where they are, and they still need the cross-team conversation.

What it does is take the largest single category of findings permanently off the table, instead of re-fighting it every time the data moves somewhere new. That's not everything. In my experience it's the difference between a compliance program that's gaining ground and one that's running to stay in place.

Why this one matters to me

PKWARE is a data security company. Not a GRC platform, not a dashboard, and not a consultancy that hands you a findings deck. We find sensitive data wherever it lives and protect the data itself, across endpoint, cloud, servers, IBM Z and IBM i, under one policy.

That last part is what matters for everything above. The security team writes the requirement once. Every infrastructure team inherits the same definition of sensitive and the same definition of protected. Nobody has to translate at the boundary, and the boundary is where translation errors turn into findings.

Discovery without protection is just a list of problems. Anybody can hand you the list. The work is in fixing it.

For context on the stakes, IBM put the average breach at 4.44 million dollars globally in 2025, 10.22 million in the United States, and 6.08 million in financial services. Those numbers have never once asked which team owned the control.

If you're the person carrying a control you can't personally enforce, I'd like to hear how you're handling it. And if you want to see what that map looks like in your own environment, that's a conversation we have most weeks. Worth the half hour.