Daniel Elice

I’ve had the opportunity to see cybersecurity assessments from both sides of the table.

I’ve been the person helping organizations prepare for assessments and remediate findings. I’ve also been on the assessment side, evaluating whether organizations are actually meeting security requirements.

Throughout my career, I’ve worked with frameworks and regulatory requirements including NIST SP 800-171/CMMC, NIST SP 800-53/FedRAMP, and HIPAA.

While these frameworks address different industries, systems, and types of information, they share a common objective: protecting information and reducing organizational risk.

And across these different environments, I’ve noticed a recurring problem:

An organization can be compliant and still not be secure.

My statement isn’t meant to diminish the value of these frameworks or independent assessments. Frameworks such as CMMC, FedRAMP, NIST, and HIPAA provide valuable structure and give organizations a measurable baseline.

As I alluded to in my previous article, the problem is what happens when the assessment becomes the destination.

The Audit Is a Snapshot

A security assessment provides a point-in-time evaluation.

An assessor comes in, examines the environment, reviews evidence, interviews personnel, tests controls, and determines whether requirements are being met.

That’s valuable.

But what happens the next day?

A firewall rule changes.

A new system is deployed with an insecure configuration.

A software update introduces a vulnerability.

An administrator changes a security setting, knowingly or accidentally, back to what they had before the audit.

The organization may still have the same assessment report documenting that the controls were effective. The environment, however, has changed. That’s the fundamental limitation of treating an assessment or audit as the finish line.

NIST itself recognizes the importance of continuous monitoring and ongoing assessment. The challenge isn’t necessarily that our frameworks don’t understand this concept.

The challenge is putting it into practice.

When Consultants Don’t Understand Security

Or, even worse, when the consultants don’t understand the security they’re supposed to be advising on.

Another issue I’ve encountered is organizations relying on consultants who simply don’t have the level of cybersecurity or compliance expertise their clients believe they’re paying for.

I’ve seen consultants miss what should be considered low-hanging fruit: basic security gaps that should have been identified early in an engagement.

What’s particularly concerning is that these organizations can spend significant amounts of money on consulting services and still walk away with:

• Unaddressed vulnerabilities
• Misconfigured systems
• Incomplete or inaccurate documentation
• Controls that aren’t actually implemented
• A false sense of security

This creates a difficult question:

What exactly is an organization paying for?

A consultant shouldn’t simply know how to interpret a framework. They should understand the security principles behind it and how those requirements translate into a real-world environment.

If you’re advising an organization on CMMC, you should understand NIST SP 800-171.

If you’re working with FedRAMP, you should understand NIST SP 800-53 and how those controls translate into cloud environments.

If you’re advising on HIPAA, you should understand not only the regulatory requirements, but also the technologies, processes, and risks involved in protecting health information.

A framework shouldn’t be treated as a collection of statements to map against a spreadsheet. It should be understood well enough to identify when something doesn’t make sense.

And this leads to an uncomfortable question that organizations should be asking before hiring a consultant:

When something goes wrong, who ultimately bears the consequences?

If an organization pays a consultant to help build or assess its security program, discovers later that obvious vulnerabilities were overlooked, and then suffers a breach, the consequences don’t disappear because a consultant was involved.

The organization still has to deal with the breach, the operational disruption, the financial consequences, and the loss of trust.

Consultants have a responsibility to provide competent guidance. Organizations have a responsibility to understand their own risk and validate the advice they’re receiving. And this is why it is so important that organizations choose the right consultant to help with their security and compliance programs.

Compliance Doesn’t Equal Security

Compliance tells us that an organization has met a defined set of requirements or demonstrated that certain controls are implemented at the time of assessment.

Security is a much broader question: Are we actually reducing risk?

Whether we’re talking about CMMC protecting Controlled Unclassified Information (CUI), FedRAMP securing federal cloud environments, or HIPAA protecting sensitive health information, the same principle applies.

An organization could satisfy the requirements of its applicable framework and still have vulnerabilities.

It could have excellent policies but poor configurations.

It could have a beautifully documented incident response plan but be unable to detect an attacker in its environment.

It could pass an assessment and then revert a security setting, intentionally or accidentally, creating a significant vulnerability the following week.

CMMC, FedRAMP, HIPAA, and the Bigger Picture

Programs such as CMMC and FedRAMP, along with regulatory requirements like HIPAA, serve an important purpose.

They establish security expectations, create accountability, and give organizations a structured way to evaluate and demonstrate their security practices. But none of them should be viewed as a permanent declaration that an organization is secure.

From Compliance to Continuous Security

I don’t think the answer is to eliminate audits.

We need independent assessments.

We need accountability.

We need frameworks.

We need standards.

But we also need to stop treating an assessment as proof that an organization is secure indefinitely.

Once an assessment is complete, the goal shouldn’t be to prepare for the next assessment. The goal should be to maintain a security program that is ready for assessment because security is being practiced every day. That means continuously monitoring our environments, validating that controls remain effective, identifying changes, addressing vulnerabilities, and reassessing risk as the organization evolves.

That’s the difference between compliance-driven security and security-driven compliance.

The latter is what we should be striving for.

Compliance should be the benchmark. Security should be the ongoing mission.