Why Compliance Programs Break on People, Not Technology

Most organizations treat security and compliance as a technology problem with a technology answer. Mark-John McSheehy, a CISO with 35 years in the field, explains why the people using that technology decide whether a program holds, and how to build a remediation plan that survives contact with the business.

Key Takeaways

• Technology is usually both the cause of and the resolution to a security problem, but the people using it determine whether a control actually works.
• Controls, policies, and procedures are written by people, and they are also ignored, misunderstood, or deliberately subverted by people.
• Remediation should be planned across one, three, and five-year horizons, with the five-year view treated as a baseline rather than a commitment.
• Executive agreement is a prerequisite for a remediation plan, not a formality. Without it, known risks stay unaddressed.
• Meeting a framework requirement is not the same as being secure. The goal is surviving a real-world test, not only a documented one.
• A pause in a certification requirement does not pause the underlying obligation, and assessor capacity remains constrained regardless.

Table of Contents

1. The Problem Technology Cannot Solve
2. What Happens When Leadership Does Not Listen
3. How to Build a Plan That Actually Holds
4. Why Checkbox Compliance Fails the Real Test
5. Working With a Young Assessor Ecosystem
6. Why This Is the Right Approach

Most security and compliance conversations start with the stack. Which tools are in place, which controls are configured, which framework the organization is working toward.

Mark-John McSheehy, CISO at Belmont Point Management and vCISO for AV3 Inc. and Indian Township Solutions, has spent 35 years working through that list. He has held nearly every seat along the way, from part-time database administrator at a not-for-profit theater to interim CIO. His view is that the stack is the easier half of the problem.

The harder half is the people using it. As he puts it, the biggest issue you have to resolve in most compliance and security areas is the people question. That framing shapes how he assesses an organization, how he sequences remediation, and how he handles the moment an assessor gets something wrong.

The Problem Technology Cannot Solve

Ask MJ where technology helps and where it does not, and the first thing he does is complicate the question. Technology sits on both sides of nearly every security problem. It is frequently the cause, and it is almost always part of the cure.

What it cannot do is close the gap between a control as written and a control as lived.

"It is the people that are using the technology that are the impetus for problems. And it is the people that are using technology that are the resolution to the problems."

— Mark-John McSheehy

That cuts in both directions, and the second direction is the uncomfortable one. People author the compliance controls, the policies, and the procedures. People are also the ones who do not follow them, who misunderstand them, or who work around them deliberately because the control is inconvenient or because there is something in it for them.

The practical consequence is that every control has two versions. There is the version in the documentation, and there is the version your staff actually operates. When those two versions diverge, an organization does not have a control. It has a document describing one.

What Happens When Leadership Does Not Listen

MJ's clearest example of the people problem is not an end user clicking a link. It is a leadership team declining to act on a warning.

At one organization he had spent years flagging a legacy file server. It held the company's major work product, it lacked appropriate controls, and it needed to be retired with the data moved into a properly governed environment. The recommendation did not land. Two weeks after he left, someone clicked a link in a phishing email and the file server went down with it.

The phishing email was the trigger. The unaddressed risk was the cause.

The cost was not confined to IT. The company lost roughly a month and a half of work hours and several hundred thousand dollars in revenue while the data was recovered into a usable state. Accounting staff could not meet client needs. The IT team stopped working on everything else in order to run the incident, which pushed unrelated projects back. The company then spent more than it needed to in order to satisfy what its insurer required to maintain coverage.

This organization was fortunate in one specific way. It sat inside a larger, well-diversified parent company, so the event did not damage the group's reputation or finances beyond recovery. MJ is direct that this is not the general case. For a less diversified business, an incident on that scale carries the potential to end the company.

The lesson he draws is about ownership rather than tooling. A CISO can identify a risk accurately and still watch it materialize, because acting on it required an executive decision that never came.

How to Build a Plan That Actually Holds

MJ's answer to this is a structured assessment followed by an agreed plan. He does not begin by writing policies.

He begins by understanding where the organization actually is: what the technology stack contains, how it is being used, where the risks sit, where sensitive information lives, and what could genuinely take the business down and cause significant harm.

Only then does the plan get built.

1. Work in Three Horizons

MJ plans remediation across one, three, and five years.

The one-year plan is what will actually be finished with the budget that exists. The three-year plan sequences what comes next once this year's work is holding. The five-year plan is a trajectory rather than a promise.

"Five-year plans are always a baseline. They always change based on the changes in technology, the changes in the business, and where the business is planning on going."

— Mark-John McSheehy

He is honest that not every organization can support that structure. In his current role, roughly a year is as far ahead as he can plan with confidence. His response is to go deeper inside the year rather than produce a longer document that will not survive.

2. Audit the Stack You Already Own Before Buying More

Before new spend gets approved, MJ looks at what the organization is already paying for.

He examines which components of the stack are underutilized, which do not apply to the business at all, and where redundancy exists that could be reduced. He also looks at the human resources supporting that technology and whether they are being used well.

This is frequently where the first savings and the first quick wins come from, and both matter for the next step.

3. Show Quick Wins While the Slow Work Runs

MJ deliberately splits the work into what can be delivered quickly and what will take longer.

The fast items exist to demonstrate that the investment produces a quantifiable result. That visible progress buys the time and credibility needed for the less visible work: writing the policy set, building governance, and establishing the documentation that an assessment will eventually depend on.

On that policy set, his experience is consistent to the point of being funny. Nearly every organization he has walked into had one policy, maybe two, and an employee handbook. He ends up writing what he describes as a book of policies.

4. Write Policies for the Business You Actually Have

A policy set is not a template exercise. MJ is firm that policies have to be written toward real business use cases and toward the specific technology stack in place to protect the business.

That requires understanding what the business does and where it is going, which leads to the skill he considers non-negotiable for anyone in security, compliance, or privacy.

"You've got to understand the business. You've got to speak the business language. You can't be at odds with what the business needs."

— Mark-John McSheehy

A security leader who cannot translate business language into technical requirements, and technical risk into business consequence, will lose the argument that matters most. That is how legacy file servers stay online.

5. Get the Plan Agreed, Not Just Written

The final step is the one that failed in his cautionary example. A plan of action has to be agreed by executive management before it means anything.

That requires leadership to trust that the plan in front of them is the plan that gets the business to the best position. When executives second-guess it, or decide a named risk is not imminent, the outcome is predictable: the risk stays, and everyone finds out how imminent it was later.

Why Checkbox Compliance Fails the Real Test

MJ's current organization works heavily in the government sector, particularly with the Department of Defense, which puts CMMC and NIST 800-171 Rev 2 at the center of its compliance obligations. The technology decisions and the risk register are both organized around that requirement.

He is explicit that meeting the requirement is not the same as being secure.

"You can't just make it a checkbox of, well, we met that requirement that's in NIST 171 R2, we're good."

— Mark-John McSheehy

The framework tells you what to implement. It does not tell you whether your organization is actually protected. So the technology you deploy to satisfy a control has to do two jobs at once: satisfy the assessor, and protect the business.

His formulation of the goal is worth keeping:

"Not only can you be tested on it, but you are never in a situation where a real-world test is going to put you in the hot seat."

— Mark-John McSheehy

This is the same argument in different language as BEMO's own operating stance. Build genuine security and the certification becomes a byproduct. Build to the checklist and you have a certificate protecting a program that has never been stress-tested.

Working With a Young Assessor Ecosystem

MJ has taken three companies through assessment at the same time, which gives him an unusually direct read on the assessor community.

His observation is that many of the auditors working today earned their certification within the last 12 to 18 months. Plenty came from project management or audit backgrounds rather than engineering. Some came straight out of school, took the classes, and are in their first assessment role. They are auditors by training, and many are not deeply technical.

Two things follow. Assessors will occasionally make mistakes, and they will occasionally hold an organization to a standard they do not fully understand.

The instinct in that moment is to win the argument. MJ advises against it. The task is to help the assessor understand where the mistake sits without making them feel stupid and without backing them into a corner, because the relationship is not adversarial.

"At the end of the day, they're a partner of yours. They're gonna help you meet your needs so that you can continue to do business."

— Mark-John McSheehy

That posture also shaped how he engaged with the pause in the CMMC rollout. When the Department of Defense opened the process to input from assessors and the organizations being assessed, his team wrote an exhaustive response covering what going through three simultaneous assessments actually looked like, including the difficulties of working with a C3PAO and auditors new to a new space.

On the pause itself, his read is practical. The pause applies to the phase two requirement and nothing else. The C3PAOs are still in business and still conducting audits, there is a limited number of them able to certify an organization, and that capacity constraint has not changed. The work continues.

Why This Is the Right Approach

MJ's guidance works because it puts the effort where the failures actually happen. Organizations that follow it gain several advantages:

• They stop treating tooling as the whole program, which is where most false confidence originates.
• They identify and sequence risk before spending, which reduces both cost and rework.
• They build policy sets tied to real business use cases, so the documentation matches what people do.
• They secure executive agreement in advance, which is what turns a recommendation into an action.
• They prepare for a real-world test rather than only a documented one.

His advice to an earlier version of himself was to be patient, be tolerant, be understanding, try not to lose your temper, and not sweat the small stuff. That reads like temperament advice. In a discipline where every control depends on someone choosing to follow it, and every remediation plan depends on someone choosing to fund it, it is closer to a method.

Compliance is not a technology purchase. It is an operating agreement between the people who write the controls and the people who have to live with them, and the program only holds when both sides are actually bought in.

Frequently Asked Questions

Is security and compliance primarily a technology problem?

No. As Mark-John McSheehy explains, technology is usually both the cause of and the resolution to a security problem, but the people using it determine whether a control functions. Controls are written by people and they are also ignored or worked around by people.

What should an organization assess before starting remediation?

MJ starts with the technology stack and how it is actually being used, where the risks sit, where sensitive information lives, and what could take the business down and cause significant harm. The remediation plan comes after that picture is clear.

How far ahead should a security roadmap be planned?

MJ works in one, three, and five-year horizons, with the five-year view treated as a baseline that will change as technology and the business change. When an organization can only support a one-year view, he recommends going deeper inside that year rather than producing a longer plan that will not hold.

Why does executive buy-in matter so much?

Because a plan that leadership has not agreed to does not get executed. MJ describes an organization where a legacy file server was flagged for years, the recommendation was not acted on, and a single phishing click later cost roughly a month and a half of work hours and several hundred thousand dollars in revenue.

Is meeting NIST 800-171 the same as being secure?

No. MJ is direct that satisfying a control on paper does not mean the organization is protected. The technology implemented to meet a requirement should also stand up when a real-world attack tests it, not only when an assessor reviews it.

Does a pause in the CMMC requirement mean compliance work can stop?

No. According to MJ, the pause applies to the phase two requirement only. The C3PAOs are still operating and still conducting audits, and there is a limited number of them able to certify an organization, so the practical guidance is to keep implementing and keep documenting.

How should organizations handle an assessor who gets something wrong?

Correct the record without making the assessor feel stupid or backing them into a corner. MJ notes that many auditors certified within the last 12 to 18 months and are not deeply technical, so mistakes happen. The assessor is a partner in the process, not an opponent.