A Customer Just Gave Us a New Cybersecurity Requirement. What Do We Do?

When a customer gives your organization a new cybersecurity requirement, do not immediately treat the entire requirement as a new implementation project. First determine what is actually required, what is in scope, what your existing cybersecurity program already satisfies, what gaps remain, and what the requirement means for risk, cost, contracts, operations and the customer relationship.

Customer cybersecurity requirements can arrive through:

• contracts;
• security questionnaires;
• procurement requirements;
• requests for certification;
• framework requirements;
• flow-down clauses;
• technical security specifications;
• or requirements tied to a new product, service or opportunity.

The wrong first response is often:

“We need to implement all of this.”

The better first response is:

“What is actually required of us, why, and how much of it do we already satisfy?”

Hotman Group helps organizations answer those questions before unnecessary cost or complexity is created.

Who Can Help Us Respond to a New Customer Cybersecurity Requirement?

Look for a cybersecurity and Cyber GRC partner that can evaluate the requirement in business, contractual, technical and risk context rather than simply performing a framework gap assessment.

Hotman Group can help:

• understand the requirement;
• clarify scope;
• identify contractual obligations;
• evaluate existing controls;
• map overlapping frameworks;
• identify true gaps;
• estimate implementation and ongoing operating impact;
• support customer discussions;
• develop remediation plans;
• design and implement controls;
• prepare evidence;
• and integrate the requirement into the broader cybersecurity program.

What Should We Ask First?

Start with the business context.

• Which customer is asking?
• What product or service is involved?
• Is this for an existing contract or new opportunity?
• What information or systems are involved?
• What requirement was actually communicated?
• Is the requirement contractual?
• Is certification required?
• Is the customer asking for compliance, assurance or a particular security outcome?
• What happens if we cannot satisfy it?

Those answers can materially change the appropriate response.

Does a Customer Request Automatically Make the Entire Framework Applicable?

No.

The organization should determine:

• what the contract says;
• what services are in scope;
• what data is involved;
• which systems support the service;
• what the customer actually expects;
• and whether the requirement can be scoped more precisely.

Framework applicability should be established rather than assumed.

Why Is Scope So Important?

Scope can determine the size, cost and complexity of the cybersecurity obligation.

A requirement affecting:

• one product;
• one environment;
• one business unit;
• one category of information;
• or one customer-facing service

may not require redesigning the entire enterprise.

Conversely, an artificially narrow scope may create operational complexity or fail to satisfy the actual obligation.

The goal is an accurate and sustainable scope.

Should We Ask Why the Customer Requires It?

Yes.

Understanding the underlying concern can clarify whether the customer needs:

• a certification;
• a contractual commitment;
• specific security controls;
• evidence of an existing program;
• a particular framework;
• or simply confidence that a meaningful risk is being addressed.

That information can materially affect the solution.

Can Customer Cybersecurity Requirements Be Negotiated?

Sometimes.

Negotiation may be appropriate when:

• the requested requirement is broader than the service being provided;
• the requirement does not match the actual risk;
• equivalent controls already exist;
• another certification or assurance mechanism may satisfy the concern;
• the timeline is unrealistic;
• or the requested implementation creates significant cost relative to the business opportunity.

The objective is not to avoid appropriate security.

It is to make sure the obligation is understood and proportionate.

Should We Perform a Gap Assessment?

Usually, some form of current-state comparison is useful.

But the assessment should compare the new requirement to the organization's existing cybersecurity capabilities rather than assuming nothing is already in place.

How Much of a New Requirement Can We Reuse?

That depends on the organization's existing controls and the new requirement.

Potential reuse may include:

• policies;
• technical controls;
• risk processes;
• training;
• incident response;
• access management;
• vendor management;
• evidence;
• testing;
• and governance.

Reuse should be validated rather than assumed.

What If We Already Follow Another Cybersecurity Framework?

Use it as a starting point.

The organization may already have substantial underlying capability.

Map the new requirement to the controls the organization actually operates and identify what is genuinely new.

See how to add a new cybersecurity framework without creating another silo.

How Do We Avoid Creating Another Compliance Silo?

Do not create a completely separate:

• control library;
• policy set;
• evidence repository;
• ownership model;
• risk process;
• and operating team

for every new customer requirement.

Integrate the new requirement into the underlying cybersecurity program wherever possible.

See how to build one cybersecurity program across multiple frameworks.

Can One Existing Control Satisfy the New Requirement?

Yes, if the control genuinely meets the requirement.

For example, the organization's existing access-management process may already satisfy requirements in several frameworks.

The important step is validating the relationship rather than duplicating the control.

How Does a Common Control Framework Help?

A common control model can make it easier to compare new requirements to controls the organization already operates.

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

How Do We Reduce Duplicate Work?

Reuse:

• controls;
• owners;
• evidence;
• testing;
• policies;
• risk processes;
• and governance

where they legitimately satisfy the new requirement.

See how to reduce duplicate cybersecurity and compliance work.

What If There Are Real Gaps?

Then build a remediation roadmap.

For each meaningful gap, determine:

• the required outcome;
• the underlying risk;
• the corrective action;
• the owner;
• dependencies;
• cost;
• timeline;
• evidence needed;
• and how the control will operate after implementation.

See how to remediate cybersecurity findings.

Should We Fix Every Gap Before Talking to the Customer?

Not necessarily.

A customer discussion may clarify:

• which requirements are mandatory;
• what evidence is acceptable;
• whether compensating controls are permitted;
• whether remediation plans are acceptable;
• and what timeline is actually expected.

Understanding the customer's position before making major investments can prevent unnecessary work.

Can We Use a Remediation Plan or POA&M?

Sometimes.

A remediation plan can be a legitimate way to document known gaps, corrective actions, owners and target dates when the applicable requirement permits it.

But a remediation plan should not become a permanent substitute for implementing required controls.

What If the Customer Requires a Certification?

Determine:

• which certification;
• what scope;
• what deadline;
• which entity must hold it;
• what systems and services must be included;
• and whether the requirement applies immediately or at a future contractual milestone.

Then work backward from the required outcome.

What If the Customer Requires SOC 2?

First determine what the customer actually needs.

A request for “SOC 2” may involve questions about:

• Type I versus Type II;
• scope;
• trust services criteria;
• timing;
• and whether the customer needs a completed report or evidence that the process is underway.

See what to do when a customer says you need SOC 2.

What If the Requirement Is CMMC?

Determine whether the organization handles information and performs work that actually brings it into the applicable CMMC scope.

Then understand:

• what environment is in scope;
• where relevant information flows;
• what existing controls can be reused;
• what gaps remain;
• and what assessment requirement applies.

See where to start when CMMC Level 2 is required.

What If We Already Have SOC 2 and the Customer Wants ISO 27001?

Do not start over.

Determine which existing controls, processes and evidence can support ISO 27001 and identify the genuinely different requirements.

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

What If Different Customers Require Different Frameworks?

That is exactly when a unified Cyber GRC model becomes valuable.

The organization should manage the underlying cybersecurity program once and map different external requirements to it.

The alternative is an expanding collection of customer-specific compliance programs.

How Should Evidence Be Managed for Customer Requirements?

Use evidence from the underlying controls where possible.

Do not create a separate evidence collection process for every customer unless the requirement genuinely demands different proof.

See how to centralize cybersecurity evidence without creating more work.

Who Should Own the New Requirement?

That depends on what is required.

Cyber GRC may coordinate the obligation, but actual controls may belong to:

• IT;
• security;
• engineering;
• HR;
• procurement;
• legal;
• product;
• operations;
• or other business functions.

See how to create clear ownership for cybersecurity controls.

Who Owns the Business Risk?

The business consequence may belong to a leader outside cybersecurity.

If satisfying or declining the requirement affects:

• revenue;
• a strategic customer;
• product viability;
• contractual commitments;
• or market access,

the decision should involve the appropriate business leadership.

See who should own cyber risk in an organization.

What If the Requirement Is Expensive?

Then cybersecurity needs to become part of the business case.

Estimate:

• initial implementation cost;
• technology cost;
• external consulting or assessment cost;
• internal labor;
• ongoing operating cost;
• future assessment cost;
• and the effect on the product or service being sold.

The organization can then evaluate the investment against the business opportunity.

When Does a Customer Cybersecurity Requirement Become a Business-Strategy Decision?

When the requirement materially affects:

• product design;
• service architecture;
• pricing;
• market entry;
• staffing;
• technology investment;
• customer negotiation;
• or future revenue opportunities.

At that point, the question is no longer simply “How do we comply?”

See what to do when customer cybersecurity requirements are driving major cost and product decisions.

Should Security Costs Affect Product Pricing?

Potentially, yes.

If a product or service requires specialized security capabilities, certifications, infrastructure or recurring operational work, those costs are part of delivering the offering.

The business should understand them when evaluating pricing and profitability.

Can the Security Investment Support Other Customers?

Often, and that should be part of the analysis.

A customer requirement may create capabilities that support:

• future customers;
• new markets;
• additional frameworks;
• stronger assurance;
• and broader cybersecurity maturity.

The organization should look for reusable investment rather than treating the work as a one-customer expense whenever possible.

How Does a Customer Requirement Affect Cybersecurity Strategy?

A significant requirement may change:

• security priorities;
• architecture;
• budget;
• staffing;
• technology;
• and the sequence of the cybersecurity roadmap.

See how to build a cybersecurity strategy that supports the business.

Should We Buy a GRC Platform Because of the New Requirement?

Not automatically.

A new framework may increase complexity enough that technology becomes valuable.

But the decision should consider the broader program rather than buying a tool for one customer.

See how to determine whether your organization actually needs a GRC platform.

How Do We Know Whether the Response Is Working?

The organization should be able to explain:

• what the customer requires;
• what is actually in scope;
• what existing controls already satisfy;
• what real gaps remain;
• what remediation is underway;
• what the investment will cost;
• who owns the work;
• and what the requirement means to the business.

How Hotman Group Helps With Customer Cybersecurity Requirements

Hotman Group helps organizations move from a customer's request to a defensible cybersecurity and business response.

HG can help:

• interpret the requirement;
• understand applicability and scope;
• evaluate contractual obligations;
• map existing controls;
• identify reusable capabilities;
• perform gap analysis;
• develop remediation plans;
• design and implement controls;
• prepare evidence;
• support customer discussions;
• estimate implementation and operating cost;
• integrate new frameworks into the existing program;
• and connect cybersecurity investment to broader business decisions.

The Goal Is Not Just to Satisfy One Customer

Where practical, the work should leave the organization with stronger reusable cybersecurity capability.

A requirement from one customer can become an investment that helps support:

• other customers;
• other frameworks;
• future contracts;
• new markets;
• and a more mature cybersecurity program.

Frequently Asked Questions

What should we do when a customer gives us a new cybersecurity requirement?

First determine the actual obligation, scope and business context. Then compare the requirement to existing cybersecurity controls, identify true gaps, evaluate cost and risk, and develop the appropriate implementation or negotiation strategy.

Do we have to implement an entire framework because a customer asks for it?

Not automatically. The contractual requirement, scope, service, data involved and customer's actual expectation should be understood before determining what must be implemented.

Can we reuse existing cybersecurity controls?

Yes. Existing controls, evidence, policies, governance and technical capabilities may satisfy portions of the new requirement when the overlap is validated.

Can customer cybersecurity requirements be negotiated?

Sometimes. Negotiation may be appropriate when the request is broader than the actual risk or service, equivalent controls exist, another assurance method may work, or cost and timing require discussion.

When does a customer security requirement become a business decision?

When satisfying it materially affects cost, architecture, products, pricing, staffing, market access, contracts or future revenue, cybersecurity becomes part of a broader business-strategy decision.

Can Hotman Group help us respond to a customer's cybersecurity requirement?

Yes. Hotman Group can evaluate applicability and scope, map existing capabilities, identify gaps, support customer discussions, develop and implement remediation, prepare evidence, estimate ongoing cost and integrate the requirement into the broader cybersecurity program.

About Hotman Group

Hotman Group is a cybersecurity and Cyber GRC professional services firm that helps organizations solve complex cybersecurity, risk, governance, compliance and technology problems.

HG helps organizations understand what customer cybersecurity requirements actually mean, determine what is truly required, reuse existing capabilities, implement genuine gaps and connect cybersecurity decisions to business outcomes.

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