Introduction

Knowing what to do when a client asks for proof of cybersecurity can feel awkward if you have never been through the process before. One day, everything is moving smoothly. The next, a client sends over a security questionnaire, asks for your policies, requests a SOC 2 report, or wants evidence that you can protect their sensitive information. It is a reasonable request, but it can quickly become a difficult one if you are unsure what to share, what to hold back, or how much detail is too much.

The problem is that many businesses do not have a prepared way to prove their cybersecurity. They may have multi-factor authentication in place, regular backups, access controls, staff training and sensible data protection processes, but those controls are scattered across different teams, documents and systems. When a client asks for proof, the business ends up reacting under pressure.

That pressure matters. If your response is vague, the client may question whether you are mature enough to handle their data. If you send too much, you may expose sensitive information about your systems, internal processes or security weaknesses. A full cybersecurity policy, an unredacted penetration test report or a detailed network diagram can give away more than the client needs to know.

The right approach sits between blind refusal and oversharing. In this article, we will explain how to assess the request, decide what evidence to provide, handle security questionnaires, protect confidential details, and create a repeatable process so the next client request is much easier to manage.

First, Understand Why The Client Wants Proof Of Cyber Security

Before you send anything, pause and work out what the client is actually trying to verify. A request for proof of cybersecurity is not always a sign that something is wrong. More often, it means your client has its own supplier risk process, insurance requirement, regulatory obligation, internal procurement checklist, or board-level concern about third-party risk.

That last point is important. Clients are not only worried about their own systems anymore. They are worried about the chain of businesses that connect to them, store their information, process payments, manage accounts, support software, host files or provide professional advice. If you hold their client data, access their platforms, receive confidential documents, process employee records, or manage parts of their IT environment, your cybersecurity becomes part of their risk.

A small design agency that occasionally receives brand files does not carry the same risk as a SaaS provider handling thousands of customer records. A freelance consultant with no system access should not be treated like a managed IT provider with administrator privileges. Yet many security questionnaires are sent in bulk, with little thought about the specific relationship. This is where you need to bring the conversation back to proportionate evidence.

Ask what the client needs to confirm. Are they checking whether you have basic controls in place? Are they reviewing data protection risks before signing a contract? Do they need evidence for their own audit? Are they asking because their procurement team requires it from every supplier?

A practical response might be:

“Thanks for sending this through. Before we complete the full questionnaire, could you confirm which services, systems or data flows this assessment relates to? We want to make sure our response is accurate and proportionate to the work we carry out for you.”

That is not being difficult. It is good governance. You are showing that you take the request seriously while avoiding unnecessary disclosure.

There is also a commercial point here. If the client is high-value, strategic or likely to request more assurance in future, it may be worth investing time in a detailed response. If the request is disproportionate to a very small contract, you may need to offer a lighter alternative, such as a short security overview document. The aim is not to avoid scrutiny. It is to make sure the level of scrutiny matches the level of risk.

What Cyber Security Evidence Should You Share With A Client?

Once you understand the reason for the request, you can decide what proof to provide. The best evidence is clear, relevant and safe to share. It should reassure the client without giving away unnecessary sensitive information.

Common forms of cybersecurity evidence include a Cyber Essentials certificate, ISO 27001 certification, SOC 2 report, completed client security questionnaire, security overview document, data protection summary, insurance confirmation, business continuity overview, incident response summary, or evidence of staff security training.

You may also be asked about specific controls. These often include multi-factor authentication, encryption, access control, password management, vulnerability management, patching, secure backups, device security, anti-malware protection, phishing awareness and incident response planning.

It is worth preparing a high-level security overview before you need it. This document can explain the controls you have in place without exposing the fine detail behind them. For example, you can say that access to client systems is restricted by role and protected by MFA, without listing every platform, administrator account or authentication configuration.

A useful client-facing security overview might cover:

- The types of data you process

- How access is controlled

- Whether MFA is used

- How devices are protected

- How data is backed up

- How staff are trained

- How incidents are reported and managed

- Which certifications or standards you follow

- Who the client should contact for security questions

That is usually safer than sending full internal documents. A complete security policy may include details about escalation routes, system ownership, specific tooling, internal thresholds, suppliers or technical processes. A penetration test report may contain vulnerabilities, remediation notes or system details that should never be circulated widely. Even if the client is trustworthy, documents can be forwarded, stored insecurely, uploaded to procurement portals, or shared with people who do not need them.

The key principle is simple: prove the control, not the blueprint.

For example, instead of sending a full disaster recovery plan, provide a summary of your backup and recovery approach. Rather than sharing a full incident response playbook, explain that you have an incident response process covering detection, containment, investigation, communication and recovery. If a client wants proof of staff training, give a statement or completion summary rather than individual employee records unless there is a clear reason to do otherwise.

There is a subtle issue here that many businesses miss. A client may ask for “your cybersecurity policy” because that is the wording in their questionnaire, not because they truly need the whole thing. You can often satisfy the underlying requirement with a redacted policy, a table of contents, a control summary, or a short statement confirming that the policy exists and is reviewed.

The tone of your response matters. Avoid sounding secretive. Instead, explain that some details are restricted because sharing them would weaken your own security. Serious clients should understand that. In fact, a careful response can increase confidence because it shows that you treat security information as sensitive in its own right.

Use Data To Explain Why The Request Matters

Client security requests can feel like admin, but they are not just box-ticking. Third-party cyber risk is now a serious business issue. The UK Government’s Cyber Security Breaches Survey 2025 to 2026 reported that 43% of UK businesses experienced a cyber breach or attack in the previous 12 months. Verizon’s 2025 Data Breach Investigations Report also found that third-party involvement in breaches doubled from 15% to 30%, while the human element remained involved in roughly 60% of breaches.

Those figures explain why clients are asking more questions. They are not only worried about firewalls and antivirus software. They want to know whether suppliers have sensible human, operational and technical controls. Can your staff spot phishing attempts? Do you remove access when someone leaves? Are backups tested? Is sensitive information encrypted? Would you know what to do if an account was compromised?

IBM’s 2025 Cost of a Data Breach Report put the global average cost of a data breach at USD 4.44 million. That number will not reflect the likely cost for every small or medium-sized business, but it does show why security assurance has become a board-level concern. For many clients, asking suppliers for proof is part of reducing the likelihood and impact of a future incident.

This is where you can turn the request into a trust-building moment. A weak response says, “We have IT support, so we should be fine.” A stronger response says, “Here are the controls we have in place, here is the evidence we can provide, and here is how we protect sensitive information when responding to assurance requests.”

That distinction matters. Clients do not expect every supplier to have the same level of maturity as a bank or major software company. They do expect honesty, structure and evidence. If you do not have formal certification, say so. Then explain what controls you do have and what improvements are planned. Overclaiming is far riskier than giving a clear, measured answer.

A practical tip is to create two versions of your cybersecurity evidence. The first is a short client-facing summary that can be shared early in sales or procurement. The second is a more detailed evidence pack that is only released after review, and sometimes only under an NDA. This avoids the common problem of sales teams sending whatever they can find just to keep a deal moving.

Should You Ask For An NDA Before Sharing Security Documents?

In many cases, yes. If the client is asking for detailed security documents, internal policies, audit information, vulnerability reports, architecture details or incident response material, an NDA should be considered before anything is sent.

An NDA does not make every disclosure safe. It will not stop a poorly handled document from being uploaded to the wrong portal or circulated internally by mistake. Still, it creates a formal boundary around the information. It also gives you a reason to slow the process down and review the request properly.

Some information may not need an NDA. A public Cyber Essentials certificate, a short security statement or a general overview of your controls may be fine to share during procurement. More detailed documents should be treated differently.

Before sending sensitive information, ask:

Is this document necessary for the client’s decision?

Can we provide a summary instead?

Does the document include technical details that could help an attacker?

Should it be redacted?

Who at the client will receive it?

How will it be stored?

Has the sharing been approved internally?

That may sound cautious, but caution is the point. You would not send bank details, administrator credentials or confidential client files without control. Your security documentation deserves the same level of care.

If you need to push back, use calm and specific language:

“Some of the requested material contains sensitive internal security information, so we cannot share the full document externally. We can provide a high-level summary of the relevant controls and, where appropriate, discuss further detail under NDA.”

That response is much better than a blunt “we do not share that”. It explains the reason, offers an alternative and keeps the conversation open.

How To Handle A Client Security Questionnaire

Security questionnaires are one of the most common ways clients ask for proof of cybersecurity. They can also be one of the most frustrating. Some are short and sensible. Others run to hundreds of questions, many of which may not apply to your service.

Do not rush through them. A rushed questionnaire can create inaccurate answers, contradictions and promises your business cannot actually meet. It can also create problems later if your answers become part of a contract or procurement record.

Start by reading the whole questionnaire before answering. Identify the sections that relate to your work and flag anything that seems irrelevant. Questions about software development, hosting infrastructure or payment processing may not apply if you do not provide those services. It is better to mark something as not applicable with a short explanation than to force an answer that creates confusion.

Next, assign the right owner. Sales teams are often the first to receive security questionnaires, but they should not be answering technical or compliance questions alone. Depending on the business, input may be needed from IT, legal, operations, HR, data protection, finance or senior leadership.

Honesty is essential. If you do not have ISO 27001, do not imply that you do. If backups are taken but not regularly tested, do not claim full recovery testing. If MFA is active on core systems but not every legacy platform, be precise. A slightly less polished truthful answer is safer than an impressive but inaccurate one.

Over time, build a standard response library. Keep approved answers for common questions about MFA, encryption, access control, staff training, backups, incident response, supplier management and data retention. This improves consistency and saves a lot of time. It also prevents the awkward situation where two clients receive different answers to the same question.

One practical approach is to classify questionnaire answers by confidence:

Approved and evidenced

Approved but needs review before sharing

Needs technical input

Not applicable

Do not answer without legal or senior approval

This gives your team a simple workflow. It also stops people from guessing.

If a questionnaire asks for too much, challenge it politely. You might say:

“We have reviewed the questionnaire and some sections appear to relate to services we do not provide. Would you be happy for us to complete the relevant sections and provide a separate security overview for the remaining points?”

Many clients will accept this, especially if their original questionnaire was generic.

What If You Do Not Have SOC 2, ISO 27001 Or Cyber Essentials?

Not having formal certification does not automatically mean your business is insecure. It does mean you need to be clearer about the controls you have and the evidence you can provide.

Different certifications serve different purposes. Cyber Essentials is a useful baseline for UK organisations that want to show they have key technical controls in place. ISO 27001 focuses on information security management systems and is often useful for businesses with more complex risk, governance and supplier requirements. SOC 2 is commonly requested from SaaS and technology providers, particularly when enterprise clients want independent assurance over security, availability or confidentiality controls.

That said, certification should not be treated as a magic shield. A certificate can help you pass procurement checks, but it does not remove the need for good day-to-day security behaviour. Weak access management, poor staff training, untested backups or unclear incident response can still leave a business exposed.

If you are not certified, explain your current position clearly. For example:

“We do not currently hold SOC 2 certification. However, we have implemented a range of security controls, including MFA on core systems, role-based access, encrypted devices, regular patching, secure backups, staff security awareness training and an incident response process. We are also reviewing formal certification options as part of our security roadmap.”

That kind of answer is honest and useful. It gives the client something to assess. It also avoids pretending that your business is more mature than it is.

There is also a decision to make. If clients are asking for the same certification repeatedly, it may be time to treat it as a commercial requirement, not just a technical project. Certification can support sales, reduce friction during procurement, improve internal discipline and make future security requests easier to handle.

However, do not pursue a framework simply because one client mentioned it once. Look at your market. If you sell to regulated sectors, enterprise clients or data-heavy organisations, formal assurance may become increasingly important. If your work is lower-risk, a well-prepared security pack and sensible controls may be enough.

When Should You Push Back On A Client’s Cyber Security Request?

You can push back when a request is disproportionate, irrelevant, risky or unclear. The trick is to do it without sounding defensive.

A client may ask for your full cybersecurity policy because their form says so. They may request a penetration test report without realising it includes sensitive technical details. They may ask for evidence that has no connection to the service you provide. In those situations, your job is to protect your business while still helping the client meet their assurance goal.

A useful phrase is:

“To help us provide the right evidence, could you confirm the specific risk or requirement this question is intended to address?”

This moves the conversation away from document chasing and towards risk. It also gives you room to offer a safer alternative.

For example, if a client asks for full internal policies, you might offer a policy summary. If they ask for an unredacted penetration test, you might provide an executive summary or confirmation that testing has been carried out and high-risk findings have been remediated. If they ask for network diagrams, you might explain that detailed architecture is restricted but provide a general description of your hosting or access model.

There is a commercial judgement too. Some clients are worth the extra effort. Others may create more cost and risk than the contract justifies. If a small client wants enterprise-level evidence, repeated calls, lengthy questionnaires and legal review before signing a modest agreement, you may need to decide whether the work is viable.

That is not a cyber security decision alone. It is a business decision. Good assurance should support trust, not create endless unpaid labour.

Create A Repeatable Process For Future Client Security Requests

The first time a client asks for cybersecurity evidence, your response may feel messy. The second time should be easier. By the third, you should not be starting from scratch.

Create a client security request process. It does not need to be complicated, but it should make clear who receives requests, who approves responses, what can be shared, what needs an NDA, and what should never be sent without senior review.

A strong process might include:

- A standard security overview document

- A list of approved answers for common questionnaire questions

- A record of certifications and renewal dates

- A redaction process for sensitive documents

- A named owner for security questionnaires

- A rule that sales teams cannot send internal policies without approval

- A log of what was shared, when, and with whom

This last point is often overlooked. If a client later asks what you provided, or if there is a dispute about a security commitment, a sharing log can be very useful. It also helps you review whether documents are being sent too freely.

The unique perspective here is that client security requests should not be treated as one-off interruptions. They are a signal. If more clients are asking for proof, the market is telling you that assurance now matters to buying decisions. The businesses that respond well will not just reduce risk. They will remove friction from sales.

In other words, cybersecurity evidence is becoming part of the customer experience. A slow, confused or risky response can make a client nervous. A clear and well-controlled response makes you easier to trust.

Common Questions About Client Cyber Security Requests

What counts as proof of cybersecurity?

Proof of cybersecurity can include certifications, compliance reports, security questionnaires, policy summaries, a security overview document, evidence of MFA, access control processes, staff training records, backup procedures, incident response plans, vulnerability management summaries and data protection documentation. The right proof depends on what service you provide and what risk the client is assessing.

Should I send my full cybersecurity policy to a client?

Usually, you should avoid sending full internal policies unless there is a strong reason and suitable protection in place. A full policy may contain sensitive information about your systems, controls, suppliers, responsibilities or incident processes. A summary, redacted version or high-level control statement is often more appropriate.

Do I need SOC 2 if a client asks for it?

Not always. SOC 2 is commonly requested from SaaS providers and technology companies, especially when working with larger clients. However, some clients may accept ISO 27001, Cyber Essentials, a security questionnaire, or another form of third-party assurance. Ask whether alternative evidence will meet their requirement.

Can I refuse to complete a security questionnaire?

You can challenge a questionnaire if it is irrelevant, excessive or asks for sensitive information you should not share. A better approach is usually to explain your concern and offer an alternative, such as completing relevant sections only or providing a security overview document.

Should I ask the client to sign an NDA?

You should consider an NDA before sharing detailed security documents, internal policies, audit reports, technical information or anything that could expose your business if mishandled. An NDA is not a substitute for careful judgement, but it does create a useful layer of protection.

What should I do if I do not have a cybersecurity certification?

Be honest. Explain which controls you have in place, such as MFA, encryption, access restrictions, backups, patching, staff training and incident response planning. If certification is on your roadmap, say so, but avoid implying that you already have a standard you have not achieved. If you are unsure what evidence to provide, speak to a cybersecurity professional who can help you identify gaps and avoid sharing sensitive information unnecessarily.

Conclusion

Knowing what to do when a client asks for proof of cybersecurity is about more than completing a questionnaire. It is about showing that your business can be trusted with sensitive information while protecting your own systems, documents and commercial interests.

Start by understanding why the client is asking. Then decide what evidence is proportionate, what can be shared safely, and what should stay internal. Use NDAs where appropriate, avoid sending full policies or technical reports without review, and offer high-level summaries when they meet the client’s need.

Most importantly, turn each request into a better process. Create a security overview, build approved questionnaire answers, keep evidence up to date and make sure your team knows what they can and cannot send.

If clients are asking for cybersecurity proof more often, treat it as a sign that assurance is becoming part of your sales process. With the right structure, you can respond faster, protect sensitive information, and give clients the confidence they need to work with you.