What Belongs on a Security Page for B2B Software?

Do you need a security page if you are not selling to enterprises?

Yes, sooner than you expect. The first security questionnaire usually arrives long before your first enterprise logo, often from a mid-sized buyer whose legal team has a checklist. A public security page does not win that deal on its own, but its absence stalls the deal for a week while somebody writes an email instead.

I see this pattern constantly on B2B software sites. Everything is polished until you reach the part where a cautious buyer needs to answer one question for their boss, which is whether putting company data into your product is a defensible decision. The site has nothing to say.

So the page exists to unblock a specific human at a specific moment. That framing decides everything that goes on it.

What is a security page actually for?

It is a pre-answer to the questionnaire you have not been sent yet. A good security page lets a buyer self-serve enough confidence to keep moving, and gives their procurement or legal contact a link instead of a meeting. It is a sales asset that happens to be about infrastructure, not a compliance document.

That distinction matters because it decides who writes it. If your security page reads like it was written for an auditor, it has failed the person it was built for. The buyer champion is usually not a security specialist. They are a product manager or a head of operations who has to forward something internally and not look careless.

Everything on the page should serve that forwarding moment. Can they skim it in ninety seconds, understand what you do, and send the link onwards with a one-line summary? If yes, the page works. If they have to interpret it for their colleague, it does not.

What should sit at the top of a security page?

Three things, in this order. What you hold, where it lives, and who can reach it. Buyers want to know what categories of their data you store, which infrastructure it sits on, and how access inside your company is controlled. Everything else on the page is supporting detail for those three answers.

Most security pages open with a badge wall instead. Certification logos are useful, but leading with them answers a question nobody asked first. A buyer who cannot tell whether you store their customers' personal data will not be reassured by a logo, and the ones who understand compliance will scroll for the substance anyway.

Write those three answers in plain sentences before you add anything else. If you cannot write them plainly, that is a finding about your product rather than about your copy, and it is better to discover it on a page draft than in a procurement call.

Which certifications should you name, and how should you name them?

Name only what you actually hold, and say exactly what form it takes. There is a large difference between being certified, being audited, and being aligned with a framework. Buyers with any experience know the difference, and vague phrasing on this point reads as a warning sign rather than as confidence.

SOC 2 is the one most B2B software buyers ask about. It sits on the AICPA's Trust Services Criteria, which the AICPA describes as control criteria for security, availability, processing integrity, confidentiality and privacy, established by its Assurance Services Executive Committee. Naming which of those categories your report actually covers is more useful than the acronym alone.

ISO and ISO/IEC 27001 come up frequently too, particularly with buyers in Europe, and regulated buyers will raise frameworks specific to their sector. Whatever the framework, link to the issuing body rather than paraphrasing what it requires. If you are working with a compliance automation vendor such as Vanta or Drata, that is not itself a certification and should not be presented as one.

Can you publish your SOC report on your website?

Not a SOC 2 report, in general. There is a report designed for exactly this, though. The AICPA says SOC 3 reports address controls relevant to security, availability, processing integrity, confidentiality and privacy, that they do not provide the same level of detail as SOC 2, and that they are considered general use reports and can be freely distributed.

That last clause is the part most teams have never been told, and it changes what your security page can do. A general use report can sit behind a plain download link with no form and no non-disclosure agreement, which removes an entire round of back and forth from a deal. Your SOC 2 report stays where it belongs, available on request under the usual terms.

If you already commission a SOC 2 examination, ask your practitioner what a general use report would involve. I am not going to guess at cost or timelines for your situation, because that depends on your engagement, but it is a question worth asking rather than assuming the answer is no.

What should you write if you have no certifications yet?

The truth, in specifics. Describe your actual practices, say plainly what you have not done yet, and state what is planned without inventing a date you cannot hold. Early-stage buyers are far more forgiving of an honest gap than of a page that implies an audit which does not exist.

Specifics carry the weight here. Encryption in transit and at rest, how employee access is granted and removed, whether you run background checks, how you handle a security incident, where your backups live, and which subprocessors touch customer data. None of that requires a certificate, and all of it tells a buyer that somebody has thought about the problem.

The failure mode is the page of reassuring adjectives. Enterprise-grade, bank-level, military-grade. These phrases mean nothing, and a buyer who recognises that they mean nothing now has a reason to doubt the rest of the site. This is the same credibility problem as putting customer logos on a page and calling it proof, where the signal is decorative and the buyer knows it.

How much detail is too much on a public page?

Stop short of anything that helps somebody attack you. Naming your cloud provider and your encryption approach is standard. Publishing your internal network topology, specific software versions, or the exact configuration of your defences is not, and no buyer needs it to make a decision.

The workable line is that public pages describe categories and controls, while the detailed artefacts live behind a request process. What is our access control model is a public answer. Which version of which component runs where is a document you share under an agreement with a named buyer who asked.

Keep a trust portal or a request process for the deeper material, and make the route to it obvious on the page. A buyer who wants more should never have to ask you how to ask. One clear line saying what is available on request, and to whom, does most of that work.

Who should own the security page inside your company?

Marketing writes it, engineering verifies it, and one named person owns keeping it current. A security page that quietly goes stale is worse than none, because it makes a public claim about a state of the world that has changed. This is the failure I see most often after the page ships.

Set a review cadence and tie it to real events rather than to the calendar alone. A new subprocessor, a change of hosting region, a completed or expired audit, a new access policy. Each of those should trigger a page update, and the owner should be the person who hears about them first rather than the person who happens to have Webflow access.

The same logic applies to the sales conversation around the page. If your team answers questionnaires ad hoc with no shared source, answers drift between deals. Make the page and the questionnaire answers come from the same place, so that what a buyer reads matches what a rep later writes.

What should you do next?

Write the three opening answers first, in plain language, before touching layout. What data you hold, where it lives, who can reach it. If those three paragraphs are honest and specific, you already have more of a security page than most companies at your stage, and the rest is arrangement.

Then decide your two access paths. What is public on the page, and what is available on request to a named buyer. Publishing a general use report, if you have one, belongs in the first path, and it is the single change I would make first for most teams with an existing SOC 2 examination. The page should also connect to your other trust surfaces, including a testimonial section people actually believe, because a buyer checking security is usually checking everything else at the same time.

Be as direct on this page as you should be on pricing. The instinct to stay vague hurts you in both places, and I have argued the same case about what a pricing page should say when you do not show prices. If you are drafting a security page and are not sure where the line between useful and reckless sits, reach out and I will look at it with you.