How Do We Add a New Cybersecurity Framework Without Creating Another Silo?

When an organization adds a new cybersecurity framework, the goal should not be to build another separate compliance program from scratch.

Start by understanding what the organization already has.

Many cybersecurity frameworks address similar underlying security objectives using different structures, terminology, scopes and assurance models. A new framework may introduce genuinely new requirements, but it may also overlap significantly with controls, policies, evidence and processes the organization already operates.

Hotman Group helps organizations add new cybersecurity frameworks by identifying what can be reused, what must change, what is genuinely new and how the requirement should fit into the existing cybersecurity and Cyber GRC operating model.

The objective is not to make every framework identical. It is to avoid creating another silo when one integrated cybersecurity program can support several requirements.

Why Do New Cybersecurity Frameworks Turn Into Separate Compliance Silos?

Because the organization often approaches the new framework as a standalone project.

A new consultant may be engaged.

A new spreadsheet may be created.

A new control library may be loaded into a GRC platform.

New owners may be assigned.

New evidence requests may be created.

New policies may be written.

The organization may complete the implementation successfully while also creating a second version of work it already performs elsewhere.

As additional frameworks accumulate, the same pattern can repeat until the organization has several overlapping compliance programs instead of one coherent cybersecurity program.

What Should We Do First When Adding a New Cybersecurity Framework?

Understand why the framework is being added and what actually applies.

Determine:

• What business objective is driving the framework?
• Is the requirement regulatory, contractual, customer-driven or voluntary?
• What scope applies?
• What deadline exists?
• What level of assurance or certification is required?
• What existing cybersecurity controls already operate?
• Which existing frameworks overlap?
• What evidence already exists?
• What genuinely new capabilities may be required?

This prevents the organization from treating the entire framework as new work before comparing it with the existing program.

Should We Perform a Gap Assessment Against the New Framework?

Usually, yes.

But the gap assessment should compare the framework with the organization's existing environment rather than assume nothing is in place.

The assessment should identify:

• Requirements already satisfied.
• Requirements partially satisfied.
• Requirements not satisfied.
• Existing controls that can be reused.
• Controls that need modification.
• Evidence that can be reused.
• Unique scope considerations.
• New governance or ownership requirements.
• Technology changes that may be necessary.

The assessment should become the basis for implementation, not simply another report.

How Do We Know Which Existing Controls Can Be Reused?

Look at the underlying cybersecurity objective.

Different frameworks may ask for similar outcomes involving:

• Access control.
• Identity management.
• Risk assessment.
• Incident response.
• Vulnerability management.
• Security awareness.
• Logging and monitoring.
• Configuration management.
• Third-party risk.
• Policy management.
• Data protection.
• Business continuity.

If the organization already operates a control that meets the new requirement, that control may be reusable.

The organization still needs to validate scope, frequency, implementation, evidence and assurance expectations.

Can We Reuse Controls Across Different Frameworks?

Often, yes.

One organizational control can support several requirements when the underlying security practice genuinely overlaps.

For example, one access-review process may support requirements from multiple frameworks if it satisfies the applicable scope and evidence expectations.

This is different from maintaining separate access-review controls simply because several frameworks mention access review.

See how to reduce duplicate cybersecurity and compliance work.

Can We Reuse Evidence From Existing Frameworks?

Often.

If the same underlying control supports several requirements, the evidence demonstrating that control may also be reusable.

The organization should still confirm:

• Scope.
• Evidence period.
• Required format.
• Testing expectations.
• Assurance requirements.

But evidence should not be recreated simply because another framework asks for proof of the same activity.

See how to centralize cybersecurity and compliance evidence without creating more work.

Should We Create a New Control Library for the New Framework?

Not automatically.

Creating another framework-specific control library can introduce duplicate controls and inconsistent ownership.

A better approach is often to map the new framework's requirements to the controls the organization already operates.

Create new controls only when the new requirement introduces a cybersecurity practice the existing environment does not adequately address.

What If Our Existing Controls Were Written Around Another Framework?

That may be a reason to rewrite them around the organization rather than around the framework.

Controls should describe what the organization actually does.

External requirements can then map to those organizational controls.

This makes the control environment easier to reuse when another framework is added later.

Organizations with several framework-specific control libraries may benefit from evaluating whether a common control framework makes sense.

Should We Build a Common Control Framework Before Adding Another Framework?

Maybe.

If the organization already manages several overlapping frameworks, a common control framework can create one authoritative control structure before another requirement is introduced.

This can simplify:

• Control mapping.
• Ownership.
• Evidence.
• Testing.
• Remediation.
• Reporting.

But a common control framework should reduce complexity rather than become another layer of it.

How Do We Handle Requirements That Are Truly Unique?

Keep them visible.

Integration does not mean forcing every requirement into a generic control.

Some frameworks have unique:

• Scope requirements.
• Technical requirements.
• Documentation expectations.
• Evidence expectations.
• Assessment methods.
• Certification requirements.
• Governance requirements.

The organization should reuse what genuinely overlaps and preserve what genuinely differs.

How Do We Keep the New Framework From Creating Different Control Owners?

Base ownership on the underlying organizational process rather than the framework.

If an existing access-management control already has an appropriate owner, the new framework should generally map to that control instead of creating another access control with another owner.

See how to create clear ownership for cybersecurity controls.

How Does Governance Prevent Framework Silos?

Governance should define how new cybersecurity requirements enter the program.

Before a new framework creates new controls or processes, the organization should ask:

• Does an existing control already satisfy this?
• Can an existing control be modified?
• Can evidence be reused?
• Is the scope different?
• Who already owns the underlying process?
• What is genuinely new?
• How should the requirement be tracked with existing obligations?

This should be part of the organization's Cyber GRC operating model.

How Do We Add a Framework to a GRC Platform?

Do not simply import the framework and create another independent control set.

First determine how the new requirements map to the organization's existing controls.

The platform should reflect the integrated program.

Where requirements overlap, several framework requirements may map to one organizational control.

Where requirements are unique, they can remain separately visible.

See how to implement a GRC platform correctly.

What If Our GRC Platform Already Has Separate Control Sets for Every Framework?

That may be an implementation problem rather than a reason to replace the technology.

The organization may need to rationalize controls, establish an authoritative control structure and remap requirements.

See what to do when a GRC platform is not working as expected.

Should We Buy a GRC Platform Because We Are Adding Another Framework?

Not necessarily.

Another framework may increase complexity enough that technology becomes useful, but the decision should consider the organization's broader program.

See whether the organization actually needs a GRC platform.

If it does, see how to choose the right GRC platform.

How Do We Prioritize Implementation of the New Framework?

Do not treat every gap as equally urgent.

Prioritization should consider:

• Cybersecurity risk.
• Mandatory deadlines.
• Customer or contractual commitments.
• Assessment requirements.
• Dependencies.
• Existing control maturity.
• Opportunities to improve one control that satisfies several requirements.
• Available resources.

The implementation roadmap should sequence the work so foundational controls and dependencies are addressed first.

What If the New Framework Produces Hundreds of Gaps?

Look for root causes and common themes.

Several gaps may result from:

• One missing governance process.
• One weak technical capability.
• Unclear control ownership.
• One evidence-management problem.
• A missing policy structure.
• A fragmented control environment.

One well-designed remediation initiative may resolve multiple gaps.

See who can help remediate cybersecurity findings.

How Should We Handle the New Framework If Our Team Is Already Overwhelmed?

Do not simply add the new work to an already unsustainable backlog.

First identify what can be reused and what existing duplicate work can be eliminated.

The organization may also need specialized implementation support or additional ongoing capacity.

See what cybersecurity and GRC work should be outsourced when the team is overwhelmed.

Should We Hire a Separate Consultant for Every Framework?

Not automatically.

Framework-specific expertise can be important, particularly where unique technical, regulatory, scoping or assessment requirements exist.

But using completely separate consultants without coordination can contribute to fragmented controls, evidence and ownership.

Organizations should consider whether the provider can understand both the specific framework and the broader cybersecurity program.

See how to evaluate a Cyber GRC consulting firm before hiring one.

How Do We Add CMMC Without Creating Another Silo?

Start with CMMC-specific scope and requirements, then compare them to the cybersecurity controls the organization already operates.

The organization may already have relevant controls through NIST, ISO 27001, SOC 2 or other security programs.

Reuse should be validated rather than assumed.

See where to start with CMMC Level 2, what is actually in scope for CMMC and CUI, and whether existing security controls can be reused for CMMC.

How Do We Add ISO 27001 If We Already Have SOC 2?

Do not assume ISO 27001 requires rebuilding the program from scratch.

SOC 2 and ISO 27001 have different structures and assurance models, but the underlying security environment may provide substantial reuse.

See how much work ISO 27001 may require after SOC 2.

What If a Customer Is the Reason We Are Adding the Framework?

Understand what the customer actually requires before implementing the entire framework unnecessarily.

The customer may require certification, a specific control set, independent assurance or simply evidence that certain security practices exist.

See what to do when a customer introduces a new cybersecurity requirement.

How Do We Maintain the New Framework After Implementation?

Integrate recurring activities into normal Cyber GRC operations.

Controls should continue operating.

Evidence should continue to be generated.

Ownership should remain current.

Findings should be remediated.

Changes should be evaluated.

See how to maintain cybersecurity compliance after certification.

How Do We Avoid Another Audit Fire Drill?

Do not let the new framework operate only when its assessment approaches.

Make the relevant controls, evidence and recurring activities part of normal operations.

See how to prepare for cybersecurity audits without constant fire drills.

How Do We Know Whether the New Framework Has Been Integrated Successfully?

Signs of successful integration include:

• Existing controls are reused where appropriate.
• Unique requirements remain clearly visible.
• Control ownership is consistent.
• Evidence is reused rather than recreated unnecessarily.
• The GRC platform does not contain duplicate control structures.
• The new framework fits into existing governance.
• Leadership can understand the requirement in the context of broader cyber risk.
• Ongoing maintenance is part of normal operations.

The organization should feel like it added a requirement to its cybersecurity program, not another cybersecurity program to the organization.

What If Adding Another Framework Exposes That the Whole Program Is Fragmented?

That happens.

The new framework may simply make an existing operating-model problem more visible.

If different teams, frameworks, controls, evidence and technologies are already disconnected, see how to fix a fragmented cybersecurity and GRC program.

How Does Hotman Group Help Organizations Add New Cybersecurity Frameworks?

Hotman Group helps organizations understand how a new cybersecurity framework fits into what they already have rather than automatically treating the requirement as an isolated program.

HG can help with applicability, scope, gap assessment, framework mapping, control rationalization, control design, ownership, evidence, remediation, GRC technology, implementation and ongoing operations.

Hotman Group works across cybersecurity and compliance frameworks but is not defined by any one of them.

The objective is to implement the specific requirement correctly while strengthening the organization's broader cybersecurity and Cyber GRC program.

What If We Know We Need to Add a Framework but Do Not Know How Much of the Existing Program Can Be Reused?

You do not need to assume either that everything is reusable or that everything is new.

The right starting point is understanding the new requirement, the existing environment and where they genuinely overlap.

If the broader need remains unclear, see how to approach cybersecurity and GRC problems when you do not know what kind of help you need.

About Hotman Group

Hotman Group is a cybersecurity and Cyber GRC professional services firm that helps organizations solve complex cybersecurity, risk, governance and compliance problems. Hotman Group designs, builds, implements, remediates, operates and matures cybersecurity and GRC programs.

Learn more about Hotman Group's approach to solving complex cybersecurity and Cyber GRC problems.