Last week, we wrote about the difference between managing individual compliance frameworks and governing the compliance program as a whole. Every new customer requirement, contract, or framework should not automatically create another program, spreadsheet, policy set, and evidence repository. That approach may seem organized, but over time it creates duplicated work, conflicting processes, and uncertainty about which version is authoritative. Instead, ask: How does this requirement fit into the governance program we already operate?
To make that work, we must stop treating controls as if they belong exclusively to a framework. Instead of asking, “How do we implement access control for CMMC?” ask, “How does our organization govern access?” That change can reshape how you build and maintain compliance.
Start With the Control, Not the Framework
Consider access control. When someone joins the company, they need an account. When they change roles, their access may need to change. Administrative privileges should be justified and managed. When someone leaves, access must be removed, and the organization should periodically review whether existing access remains appropriate.
These are business and security processes before they are compliance processes. The organization should establish a strong process for provisioning, multifactor authentication, privileged access, offboarding, access reviews, exceptions, and evidence retention, then map requirements to it. That process should be understandable, repeatable, and resilient when personnel, systems, or obligations change.
Do not build one identity lifecycle for CMMC, another for SOC 2, and a third for ISO/IEC 27001. The organization needs an access-control process because controlling access is essential to secure operations. Frameworks provide different ways to evaluate that process. The framework does not own the control. The organization does.
One Control Doesn’t Mean One Requirement
“One control, many frameworks” does not mean the requirements across CMMC, NIST SP 800-171, SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, or other obligations are identical. They have different purposes, scopes, assessment methods, and evidence expectations. The goal is not to flatten those differences into one generic control.
The goal is to avoid unnecessary operational duplication. Think of the control as the foundation and each requirement as a lens through which it is examined. One requirement may already be covered, while another exposes a gap, requires different evidence, or adds a contractual obligation. A third may apply only to a specific system, business unit, data type, or customer environment. Often, the right response is to strengthen the existing process rather than create another one.
Govern the Control Once
For every important control, an organization should know who owns it, what systems and processes it covers, how often it operates, how effectiveness is validated, what evidence it produces, and which requirements map to it. The compliance requirement becomes part of the governance structure rather than the starting point for the entire process.
Someone must be accountable for keeping the control effective, and its scope must be clear. A strong access-control process does little good if sensitive systems sit outside it. The organization must also understand whether the control operates continuously, is triggered by events such as onboarding or termination, or requires periodic review.
Documentation alone does not prove a control works. The organization needs to validate that the process is performed as intended and produces reliable evidence. Terminated access should leave a record, account reviews should be documented, and approved exceptions should capture the decision and authorization. Leaders should also know whether reviews happened on schedule, issues were corrected, and exceptions remain necessary.
Only then should we map requirements to the control. That order is fundamentally different from starting with a large requirements spreadsheet and trying to build the organization around it.
Think About the Employee Lifecycle
Access control is only one example. When someone joins the company, HR may initiate equipment, accounts, applications, permissions, training, and access to sensitive information. Managers approve what the employee needs, IT provisions the technology, security applies appropriate safeguards, and the employee completes required acknowledgments or training. That process touches cybersecurity, privacy, contracts, and multiple frameworks, but the organization does not need five onboarding processes. It needs one well-governed onboarding process that addresses the applicable requirements.
The same applies when employees change roles or leave. Old permissions should not remain while new access accumulates. Role changes should trigger a review of existing privileges, and departures should initiate a coordinated process for disabling accounts, recovering equipment, transferring ownership, and preserving needed records. Unless a specific obligation truly requires something different, the organization needs one effective transition and termination process, with a clear understanding of how it satisfies each applicable obligation.
This distinction is operationally significant because it turns compliance from a set of framework-specific activities into an integrated part of how the organization operates.
What Happens When a New Requirement Arrives?
This model pays off when something changes. If a customer introduces a new security requirement, the reactive approach asks what new policies, tools, procedures, and evidence are needed. The governance approach starts with: “Which existing controls already address this requirement?”
Then determine whether the control satisfies the requirement, a gap exists, the process or evidence must change, or ownership needs adjustment. Document the analysis so leaders understand the decision and teams can implement it consistently. If something new is required, build it intentionally rather than create another compliance silo.
Not everything can be mapped away. A new obligation may create real work or require significant changes. The value of governance is that the organization identifies the actual gap deliberately instead of rebuilding everything around another framework.
The Evidence Gets Easier Too
As the program matures, evidence also becomes easier to manage. If one access-control process supports multiple requirements, its evidence should come from that operational process, not from separate collection exercises created for each framework.
An approval should exist because the process requires it. A review record should exist because a review occurred. A ticket should document work because that is how work is managed, and a log should exist because the system records the activity. Ideally, the evidence should identify who performed the action, when it occurred, what was reviewed or changed, and how any issues were resolved. The assessment should not be the reason evidence suddenly appears. Good controls should naturally create evidence that demonstrates they are operating.
We will return to evidence later in this series because it is one of the biggest differences between continuously maintained compliance and compliance reconstructed before an assessment. When evidence is a natural result of the process, the organization can demonstrate what happened without scrambling to recreate the story months later.
This Is How Compliance Starts to Scale
This approach matters even more as an organization grows. Customers, contracts, technology, regulations, and markets change, and new certifications or assessments follow. Acquisitions, new locations, cloud services, and evolving supply-chain expectations can add even more complexity. If every change becomes an independent compliance project, the organization may spend more time managing overlap than managing risk.
When controls are governed as organizational processes, a new obligation is more manageable. Map it into what exists, identify gaps, and decide what must change. Sometimes the existing control covers most of the requirement; sometimes it clearly does not. Both answers are valuable because the goal is not to force every framework into the same box, but to understand exactly what the box contains.
The Bigger Shift
This is one of the most important shifts a maturing compliance program can make. Framework-focused compliance asks, “What do we need to do for this requirement?” Governance-focused compliance asks, “How do we manage this risk or process today, and does that approach satisfy the requirements that apply to us?”
That second question requires us to understand the business, control, owner, systems, process, evidence, and gaps. It creates more useful conversations with executives, auditors, assessors, customers, and service providers because everyone can discuss the same operational reality. Frameworks, expectations, technology, people, and obligations will continue to change. Your core processes should not have to start over every time they do.
Govern the control once. Map it many times. Validate it continuously. This does not eliminate differences between frameworks. It gives the organization a better way to manage them and moves compliance from a collection of projects into the way the organization actually operates.
Because compliance isn’t something you finish. It’s something you govern.
Up Next: November 4
Someone Has to Own It
Next Wednesday, we will focus on one of the most important parts of sustainable compliance governance: ownership. A policy does not own a control, a tool does not own it, and hiring a consultant or service provider does not automatically transfer accountability. We will look at responsibility from executive oversight through control operation and evidence ownership, and why every organization must answer one deceptively simple question: Who owns this?
Questions about certification, compliance or governance? Contact Hill Tech Solutions.
