When we began our compliance journey, the conversation naturally focused on requirements: What does the framework require? Which controls apply? What technology, policies, and evidence will an assessor expect?
Those questions matter, and during assessment preparation they can consume a lot of attention. They certainly did during our own CMMC journey.
But after the assessment, when you start maintaining the program, a different question becomes more important.
How do we make sure all of this continues to work?
That question is also the starting point for this next chapter of Compliance Workshop Wednesday.
Over the past several months, we have looked at CMMC topics such as control ownership, inheritance, evidence, assessment readiness, and the cadence needed to keep a program running. As those conversations build on one another, one point becomes clear.
CMMC isn’t the only set of requirements companies may have to worry about.
A government contractor may be pursuing CMMC and NIST SP 800-171 while also managing customer security requirements. Others may face SOC 2, ISO/IEC 27001, HIPAA Security Rule, PCI DSS, cyber insurance, contractual obligations, or some combination of them.
These obligations are not interchangeable; each has its own purpose, scope, assessment model, and evidence expectations. Still, many rely on the same underlying business and security processes, which creates an important opportunity.
If every new requirement leads to a separate compliance program, complexity grows quickly. Before long, the organization is managing another policy set, spreadsheet, control list, evidence repository, and validation effort. The result is less integrated governance and more disconnected silos.
The Framework Isn’t the Program
Strong compliance starts with understanding how the business actually operates: what information it protects, where that information lives, which systems support it, who has access, who owns responsibility, what could go wrong, which controls manage those risks, whether those controls work, and whether the organization can prove it.
Only then does mapping activities to specific requirements become useful. Many organizations do this backward. They start with a requirements spreadsheet and try to make the business fit it. A healthier approach is to build strong, repeatable business and security processes first, then map applicable requirements to them.
Consider access control. If the organization already provisions users through a defined workflow, enforces multifactor authentication, limits privileged access, removes access during offboarding, reviews access periodically, documents exceptions, and retains evidence, the first question should not be whether to create a new process for every requirement.
The better question is: Does our existing process satisfy the requirement, and can we prove it?
Employee termination works the same way. HR may start the termination workflow, IT may disable accounts and revoke access, and security may confirm that higher-risk access was removed. Different obligations may emphasize timeliness, approval, documentation, privileged access review, or revocation, but the underlying process does not need to be recreated each time.
Instead, the core process should be well designed, consistently performed, clearly owned, periodically validated, and capable of producing evidence.
That distinction matters. The goal is not to treat NIST SP 800-171, SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, or other obligations as the same. Each has its own scope, evidence, and assessment expectations. The goal is to avoid reinventing the organization every time a new compliance obligation appears.
Govern the control once, then map it where appropriate.
Governance Is the Layer Above Compliance
This is where organizations should move beyond managing individual compliance activities and focus on the governance structure that keeps those activities effective over time.
Controls remain effective when ownership is clear, their operation is reviewed, and supporting policies continue to reflect how the organization actually works.
Evidence should show that required activities occurred and that the organization can support the conclusions it draws from that evidence.
Risks, vendor dependencies, and exceptions also require active governance. Each one needs assigned ownership, documented decisions, appropriate follow-up, and deliberate approval when normal practices must change.
These issues are not solved by adopting another framework. They are managed through accountability, decision-making, validation, and oversight.
Effective governance defines who is responsible, how decisions are made, how activities are validated, and how the organization responds when conditions change.
That is the focus of this next Compliance Workshop Wednesday series.
Moving From Compliance Projects to Compliance Governance
Over the next several weeks, we’re going to step back from looking at compliance through the lens of a single framework and talk about what it takes to govern a compliance program continuously.
We’ll look at control ownership and how an operational control may support requirements across multiple frameworks. We’ll talk about creating a compliance calendar, producing evidence through normal operations, keeping policies aligned with reality, governing vendors and inherited controls, managing exceptions, measuring program health, and making compliance considerations part of organizational change.
We’ll also get into something I think gets overlooked far too often: leadership’s role in all of this. Because ultimately, compliance isn’t just an IT project, a document project, or something that should wake up three months before an assessment and go back to sleep afterward.
It is an ongoing business process.
A Simple Model for What Comes Next
For this series, I’m going to organize many of these conversations around six ideas that I think make continuous compliance easier to understand:
Governance. Ownership. Validation. Evidence. Risk. Navigate Change.
Or simply:
GOVERN
Governance establishes how decisions are made.
Ownership makes responsibility clear.
Validation determines whether controls actually work as intended.
Evidence proves that the processes are operating.
Risk helps the organization decide where attention and resources belong.
Navigate Change recognizes that compliance must evolve as the business, technology, risk, and regulatory environment change.
None of those concepts belong exclusively to CMMC, SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST standards, or any other compliance requirement. They belong to the organization and that is the real point.
The Next Stage of the Journey
One of the biggest lessons from our own CMMC journey was realizing that the assessment wasn’t the finish line. In some ways, it was the starting line. An assessment evaluates the organization against defined requirements at a point in the compliance lifecycle. Governing the program is what keeps the practices, responsibilities, evidence, and risk decisions functioning afterward.
That requires a different mindset.
Instead of asking: Are we ready for the assessment? Where is the evidence we need?
Ask: Is our program working today? Did our process produce the evidence it should have produced?
Most importantly, instead of immediately asking: “How do we build another compliance program for this new requirement?”
Ask: “How does this requirement fit into the governance program we already operate?”
In some cases, an existing control and its evidence will satisfy the requirement. In others, the control may need to be strengthened, or the new obligation may require something genuinely new.
The key is to make that determination intentionally, rather than creating another compliance silo by default.
That is where sustainable compliance begins.
Over the next several Compliance Workshop Wednesdays, we’re going to explore exactly what that looks like in practice. Because the longer I work in this space, the more convinced I become of one simple idea:
Compliance isn’t something you finish. It’s something you govern.
Up Next: October 28
One Control, Many Frameworks
Next Wednesday, we’ll look at how organizations can build strong operational controls first and then map those controls against multiple compliance requirements without unnecessarily duplicating processes, responsibilities, and evidence.
Questions about certification, compliance or governance? Contact Hill Tech Solutions.
