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

When a new cybersecurity framework or customer requirement arrives, do not automatically build a new control library, evidence process, ownership structure and compliance workstream. Start by determining what the existing cybersecurity program already satisfies.

Organizations frequently make cybersecurity more complicated every time a new requirement appears.

A company already managing SOC 2 may add ISO 27001. A government opportunity may introduce NIST or CMMC. A major customer may impose new contractual controls. A business expansion may create HIPAA, privacy or other regulatory obligations.

The common reaction is to launch another project.

That project gets its own controls, evidence, owners, spreadsheets, meetings and audit process.

Over time, the organization stops operating one cybersecurity program and starts operating a collection of compliance programs.

Hotman Group helps organizations add new cybersecurity requirements by reusing existing controls and operating capabilities wherever appropriate, then implementing the incremental work that is genuinely required.

Who Can Help Us Add a New Cybersecurity Framework Without Creating Another Silo?

Look for a cybersecurity and Cyber GRC partner that understands both the new requirement and the organization's existing control environment.

Hotman Group helps organizations evaluate new frameworks, customer requirements and contractual obligations against the cybersecurity program already in place.

HG can help determine:

• what actually applies;
• what is in scope;
• which existing controls already satisfy requirements;
• which evidence can be reused;
• which owners already perform the relevant activities;
• which requirements are genuinely new;
• what remediation or implementation remains;
• and how the new requirement should be integrated into ongoing operations.

Why Do New Frameworks Create Silos?

Frameworks often arrive through separate business events.

One may come from a customer.

Another may come from a regulator.

Another may be pursued because sales wants a certification.

Another may be required for a government opportunity.

Because the business drivers are separate, the implementation projects often become separate too.

Each project creates:

• its own requirement inventory;
• its own control statements;
• its own evidence requests;
• its own findings;
• its own project plan;
• and sometimes its own GRC workflows.

The organization may never stop to ask how much of the new requirement is already supported by the cybersecurity program.

What Should We Do First When a New Framework Arrives?

Start with applicability and scope.

Ask:

• Why does this requirement apply?
• Is it contractual, regulatory, customer-driven or voluntary?
• Which legal entities are affected?
• Which products, systems and environments are in scope?
• What information is covered?
• Which employees or third parties are involved?
• What deadlines exist?
• What evidence or independent assessment will eventually be required?

Poor scoping can make the project unnecessarily expensive or leave important obligations untreated.

Then Compare the New Requirement to What Already Exists

Do not immediately write new controls.

First inventory the existing cybersecurity program.

Determine what the organization already does around:

• identity and access management;
• asset management;
• vulnerability management;
• configuration management;
• logging and monitoring;
• incident response;
• risk management;
• security awareness;
• vendor risk;
• change management;
• data protection;
• business continuity;
• and governance.

Much of the new framework may already be supported by those capabilities.

How Much of a New Framework Can Usually Be Reused?

There is no universal percentage.

Reuse depends on:

• the frameworks involved;
• the maturity of the existing program;
• scope differences;
• technical requirements;
• documentation requirements;
• evidence expectations;
• and the effectiveness of existing controls.

An organization with a mature cybersecurity program may have substantial reuse.

An organization that has mostly maintained audit artifacts without strong underlying controls may have much less.

The right answer comes from evaluating actual controls, not estimating based only on framework crosswalks.

Does Framework Overlap Mean the Requirement Is Already Satisfied?

No.

Overlap means there may be an existing cybersecurity capability worth evaluating.

The new requirement may still differ in:

• scope;
• frequency;
• technical depth;
• documentation;
• control wording;
• evidence;
• assessment procedures;
• or governance expectations.

Reuse should be based on the substance of the control, not similarity of wording alone.

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

Usually not if the organization already has an integrated control model.

A better approach is generally:

existing organizational control → new framework requirement.

If the existing control fully satisfies the requirement, map it.

If it partially satisfies the requirement, enhance the control or identify the incremental activity.

If nothing currently satisfies it, create the new capability that is actually needed.

See what a common control framework is and whether your organization needs one.

How Do We Identify the Real Gap?

The real gap is the difference between:

what the new requirement legitimately expects

and

what the organization actually does today.

That sounds simple, but organizations frequently compare framework text to framework text instead.

A useful gap analysis should evaluate:

• current control design;
• actual implementation;
• scope;
• evidence;
• ownership;
• effectiveness;
• and framework-specific expectations.

Can We Reuse Existing Evidence?

Often.

If an existing control supports the new requirement, its normal operational evidence may also be reusable.

Examples include:

• access reviews;
• vulnerability reports;
• change records;
• training completion records;
• risk assessments;
• incident-response exercises;
• vendor assessments;
• configuration reports;
• and system-generated logs.

The organization still needs to determine whether the new framework requires additional evidence or a different period of coverage.

See how to centralize cybersecurity evidence without creating more work.

Should We Create New Control Owners for the New Framework?

Not if the existing organizational control already has an appropriate owner.

Ownership should generally follow the activity.

If IT already owns the access-review control, a new framework should not require another person to become the “framework owner” for the same operational activity.

The new requirement can be mapped to the existing control and ownership structure.

See how to create clear ownership for cybersecurity controls.

What Should We Do With Framework-Specific Requirements?

Preserve them.

Integration does not mean forcing every requirement into an artificial common denominator.

Some frameworks introduce truly distinct obligations.

Those may require:

• new technical controls;
• different scope;
• specific documentation;
• new governance;
• new evidence;
• additional testing;
• or an independent assessment.

Those incremental requirements should be implemented deliberately.

The goal is not to eliminate differences.

The goal is to avoid duplicating what does not need to be duplicated.

How Do We Reduce Duplicate Work While Adding the Framework?

Reuse should be considered across:

• controls;
• owners;
• evidence;
• testing;
• policies;
• risk processes;
• findings;
• remediation;
• and GRC workflows.

See how to reduce duplicate work across cybersecurity frameworks.

How Does This Fit Into One Multi-Framework Cybersecurity Program?

The larger model should remain:

business and cyber risk → cybersecurity capabilities → organizational controls → external requirements.

The new framework becomes another requirement layer connected to the same underlying program.

See how to build one cybersecurity program across multiple frameworks.

What If We Already Have Too Many Frameworks?

Adding another framework may expose a larger structural problem.

If every existing requirement already has its own:

• control library;
• evidence repository;
• spreadsheet;
• owners;
• assessment process;
• and findings;

the organization may need to rationalize the existing program before adding more complexity.

See what to do when you have too many cybersecurity and compliance requirements.

What If the Existing Program Is Already Fragmented?

Do not simply attach the new framework to a fragmented model.

This may be the right time to address:

• duplicate controls;
• unclear ownership;
• evidence sprawl;
• disconnected findings;
• weak GRC technology;
• and competing governance processes.

See how to fix a fragmented cybersecurity and GRC program.

How Should the GRC Platform Be Updated?

The GRC platform should reflect the integrated model.

Ideally, the new framework is mapped to existing organizational controls where appropriate.

New controls should be created only where genuine new requirements exist.

Avoid automatically enabling another framework library and creating duplicate:

• controls;
• owners;
• evidence requests;
• testing workflows;
• and findings.

See how to implement a GRC platform around the cybersecurity program rather than around disconnected frameworks.

Can Automation Help With the New Framework?

Yes, after the underlying model is designed.

Automation may help:

• collect evidence;
• track recurring controls;
• assign tasks;
• monitor findings;
• produce reports;
• and maintain framework mappings.

But automating duplicate processes simply creates faster duplication.

See how to automate compliance without automating bad processes.

What If the New Requirement Comes From a Customer?

Customer-driven frameworks or control requirements should still be evaluated against the existing program.

First determine:

• what the customer actually requires;
• what is contractually binding;
• what is in scope;
• what existing controls already support the requirement;
• what gaps remain;
• and whether any requirement should be clarified or negotiated.

See what to do when a customer gives you a new cybersecurity requirement.

What If the New Requirement Affects Product Design or Revenue?

Then the decision may no longer be primarily about framework implementation.

A major customer or market requirement can affect:

• technical architecture;
• product design;
• delivery models;
• contracts;
• pricing;
• investment;
• market eligibility;
• and future revenue.

The organization should evaluate the cybersecurity investment in the context of the business opportunity and determine which new capabilities can be reused for future customers.

See how customer cybersecurity requirements can become a broader business strategy problem.

Can SOC 2 Work Help With ISO 27001?

Often.

Organizations with established SOC 2 controls may already have many cybersecurity processes that support ISO 27001.

The organization should reuse those capabilities where appropriate and focus implementation on ISO-specific requirements and remaining gaps.

See how much work ISO 27001 may require when you already have SOC 2.

Can Existing Controls Be Reused for CMMC?

Potentially.

An organization pursuing CMMC should evaluate its existing cybersecurity controls against the applicable requirements before assuming the entire environment must be rebuilt.

Existing work may provide significant reuse while CMMC-specific scope, documentation, evidence or technical gaps still need to be addressed.

See how existing security controls can be evaluated for reuse in CMMC.

How Should Remediation Be Managed?

New framework gaps should become part of the organization's broader remediation model rather than a completely separate findings process.

Prioritize based on:

• risk;
• contractual deadlines;
• assessment requirements;
• dependencies;
• implementation effort;
• and business importance.

Several new framework findings may also trace back to one underlying program weakness.

See how to approach cybersecurity remediation.

How Do We Keep the New Framework From Becoming Another Annual Fire Drill?

Integrate recurring requirements into normal operations.

Controls should operate throughout the year.

Evidence should be generated and maintained as part of those operations.

Findings should be managed continuously.

Ownership should remain clear.

Governance should review material changes.

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

How Hotman Group Approaches New Cybersecurity Frameworks

Hotman Group does not assume that a new framework requires a new cybersecurity program.

HG begins by understanding:

• the business driver;
• applicability;
• scope;
• the current cybersecurity program;
• existing controls;
• existing evidence;
• existing ownership;
• and the actual incremental requirements.

Hotman Group can then help:

• map reusable controls;
• identify gaps;
• design new controls where needed;
• remediate weaknesses;
• update GRC technology;
• prepare for assessment;
• and integrate recurring requirements into the existing operating model.

The objective is to satisfy the new requirement while strengthening the broader cybersecurity program.

Why This Approach Matters Beyond Compliance

Every new framework creates an opportunity to either strengthen the cybersecurity program or fragment it further.

If the organization builds another isolated control set, it may increase:

• administrative burden;
• duplicate ownership;
• evidence collection;
• GRC complexity;
• and audit effort.

If the organization integrates the new requirement into existing cybersecurity capabilities, the same investment can support broader risk reduction and future requirements.

The Larger Philosophy Behind Framework Integration

Frameworks are useful mechanisms for defining and evaluating cybersecurity expectations.

They become counterproductive when each framework becomes a separate version of cybersecurity.

Cheri Hotman's forthcoming book, Rebuilding Cybersecurity: How to Restore Trust, Leadership, and Real Protection in a Broken System, examines how cybersecurity can become fragmented around compliance activities, assurance mechanisms and disconnected ownership.

Integrating new requirements into the underlying cybersecurity program is one practical way to prevent that fragmentation.

Frequently Asked Questions

Should every new cybersecurity framework become a separate program?

Usually not. Organizations should first determine which existing controls, owners and evidence already support the new framework and then implement the genuinely new requirements.

How do we know what can be reused from an existing framework?

Compare the new requirements to the organization's actual controls, scope, implementation and evidence rather than relying only on framework-to-framework mappings.

Can we reuse evidence when adding a new cybersecurity framework?

Often, yes. If existing controls support the new requirement, their operational evidence may also be reusable, subject to framework-specific evidence expectations.

Should we create new control owners for every framework?

Generally no. Ownership should follow the actual organizational control and operating responsibility rather than being duplicated simply because another framework contains a related requirement.

Does overlap mean the new framework will be easy?

Not necessarily. Overlap reduces unnecessary rebuilding, but the framework may still introduce significant new scope, technical, documentation, evidence or assessment requirements.

Can Hotman Group help us add another cybersecurity framework?

Yes. Hotman Group can evaluate the new framework against the existing cybersecurity program, identify reusable controls and evidence, determine genuine gaps, implement and remediate new requirements, update GRC technology and help integrate the framework into ongoing operations.

Can Hotman Group help if we already have several separate compliance programs?

Yes. HG can help rationalize existing frameworks, consolidate duplicate controls, clarify ownership, redesign evidence and integrate requirements into a more coherent cybersecurity and Cyber GRC operating model.

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.

HG helps organizations add new cybersecurity frameworks and customer requirements without unnecessarily rebuilding existing controls, evidence and operating processes.

Hotman Group can help evaluate overlap, identify incremental requirements, design and implement controls, remediate gaps, enable the model through GRC technology and sustain the resulting cybersecurity program.

Learn more about what Hotman Group is and the cybersecurity and Cyber GRC problems HG solves.