Security questionnaires now arrive before, during and after the pitch. Your website needs to answer the questions buyers and machines already ask.

A few weeks ago I wrote about your website being your biggest asset in an RFP. That piece ended on the unglamorous tier: security posture, certifications, compliance, and the information nobody in marketing owns.

Since then, it has sparked conversations inside Made by ON about how security shows up in RFPs and in other purchasing scenarios.

Those conversations kept returning to three core questions. They come from our collective experience across procurement processes in aviation, banking, retail, telecoms, medical technology and more.

What has changed is the variation and stage at which those questions arrive:

• inside the RFP as scored sections
• after the pitch as onboarding
• mid-relationship, when your client’s own customers push due diligence down the chain

Forrester found that 94% of B2B buyers used AI in their most recent purchase¹, which means the research that used to arrive as a questionnaire increasingly starts with a machine reading whatever your site says.

Start with the questions procurement will ask first: who has access, where data lives, and how protection is handled.

So what are the three big questions your site should cover? Who can access it, what you stand behind, and what happens when it breaks.

Who can access our data, and where does it live?

84% of organisations use security questionnaires² to get answers that give them comfort in the companies they buy from. This is not just for use inside the buyer’s procurement department. It is increasingly required by regulators across the globe.

Rules like DORA, the EU’s Digital Operational Resilience Act³, now force enterprise buyers to prove due diligence across their whole supply chain. That touches data access and hosting, which is why the ask increasingly comes from your customer’s customer.

The right answer depends on what you are.

• SaaS answers in architecture: tenancy, residency, encryption, and a subprocessor list that is published and current.
• An AI company answers the training question: where inference happens, which providers sit underneath, and whether customer data trains anything. That last one is now the crucial point for enterprise buyers.
• A services business answers in people: who touches client material, how access is granted and revoked, and what contractors see.

What certifications do you hold?

Certification pages need to do more than display badges; they should make the claim, scope and evidence easy to verify.

Sales teams often treat certifications as tick-box essentials, but there is depth to earning them and to highlighting them on your website in a meaningful way.

For SaaS, past a certain deal size, System and Organisation Controls 2 (SOC 2)⁴ is table stakes. It is a voluntary auditing framework created by the American Institute of Certified Public Accountants (AICPA) that evaluates how well a service provider protects customer data. The key information to surface through your website is how easily a buyer can access the report.

For AI companies, the ground is shifting underneath them. The International Organisation for Standardisation has created the first international standard for Artificial Intelligence Management Systems, ISO 42001⁵. In around two years, it has moved from novelty to a procurement requirement in regulated sectors⁶, providing a formal framework for organisations to responsibly develop, provide or use AI systems.

Our advice: publishing the certification logo is good practice, but the information architecture needs to give space to a dedicated certifications page that explains your position and why these certifications matter to you.

The watch-out, as our Chief Digital Officer Guanglun Wu puts it, is that “certified”, “audited” and “working to the standard of” are three different claims. The one person guaranteed to know the difference is the security reviewer reading your answer. State what you hold, what you do not, and what stands behind the gap. The honesty is itself the signal.

What happens when something goes wrong?

Incident response is part of the trust story: buyers want to know what happens, who acts, and how quickly they hear.

Safety engineers have a name for how bad days happen: the Swiss cheese model⁷. Every defence is a slice of cheese with holes in it, and disaster is the day the holes line up.

The three questions are really asking about your slices. The first measures how big the holes are: who has access. The second asks whether a badge is a whole slice or just the label on one. The third asks what happens on the day the holes align.

A good answer has four parts:

1. How you would know: detection, because uptime monitoring is not compromise detection. A hacked site can still be up.
2. Who acts: named by role, not “the team”.
3. How fast the client hears: and what they see while it is in progress.
4. What recovery covers: agreed before anything happens, not negotiated mid-incident.

Following the theme of the first two questions, celebrate your incident response approach. Incidents happen. Buyers want to know that you have handled them before and managed them effectively.

The quiet advantage

Industry research suggests up to 75% of vendors⁸ either do not respond to security questionnaires or fail to do so on time. Most competitors are still deprioritising what is becoming a crucial area of concern for buyers.

A published answer on your website gets ahead of the race before it starts, regardless of the stage those questions now arrive: scored in the RFP, checked at onboarding, or scanned mid-relationship.

Do not underestimate the internal benefit either. When the sales team asks, “What’s our position on this?”, you can educate through the content already published on your website.

Security is arguably the crucial question procurement asks, but it is not the only one. Accessibility has quietly moved from a feature request to a warranty clause in client contracts, and will be the next topic of conversation in an upcoming Field Note.