Website Builder Security Questionnaire: 50 Questions for Vendors | How-to Guide

By the We.Inc editorial team · Editorial policy

A security questionnaire written for website builders and site platforms, not generic SaaS: separation between client sites, publishing control, domains and dangling DNS, third-party scripts, form data, AI features, email sent on your behalf, logs, incidents and exit. With what a good answer looks like, how to weigh evidence, and our own answers where they are true.

Most security questionnaires were written for software that stores your records: payroll, CRM, ticketing. A website platform is a different animal. Its main job is to publish things to the whole internet under your name, often on domains you own, often edited by people outside your organisation, increasingly with AI writing the first draft. The risks that matter are about who can put what in front of the public, and what the platform does with the data visitors type into your forms. This questionnaire covers those risks. Use it alongside your standard one, not instead of it.

Start with the standard questionnaires, then add this one

Several free or widely used questionnaires already exist, and a serious vendor will have answered at least one of them:

None of these asks what happens when a client's sub-account publishes a page on your domain without approval, or when a domain you retired still points at the vendor. The questions below do. They are numbered so you can reference them in a contract or a scoring sheet.

Decide how much to ask before you send anything

Fifty questions for a brochure site wastes everyone's week; five for a site that takes health enquiries is negligent. Pick the sections by what the sites will actually hold:

What the sites will doSections to send
Public information only, no forms, no loginsA, C, D, E, J, K
Contact or enquiry formsAdd F and H
Outside parties (clients, franchisees, departments) edit their own sitesAdd B and I
AI generates or edits contentAdd G
Forms collect sensitive data (health, finances, children's details)All sections, plus your full standard questionnaire and a legal review of whether the platform should hold that data at all

The questionnaire

Under each section, a note on what a good answer looks like. Copy the questions; keep the notes for whoever scores the replies.

A. Separation between sites and between customers

  1. Are our sites and data logically separated from other customers' on shared infrastructure? How is that separation enforced: in the application, the database, or both?
  2. If we run several client or department accounts under our organisation, can one of them see or change another's sites, form submissions or settings?
  3. Can your support staff view or edit our sites? Under what conditions, and is that access recorded?
  4. Do published sites share a domain or cookies with the editing application?

Good answer: specific about the mechanism (for example, row-level access rules in the database as well as checks in the application), and honest that support access exists with limits, rather than claiming nobody can ever see anything.

B. Accounts, roles and leaving staff

  1. Which roles exist, and what can each do? Please send the list rather than describing it.
  2. Can we restrict what each client or sub-account is allowed to do (publish, connect a domain, add scripts, view code)?
  3. Which sign-in methods are supported for our staff and for our clients? Is multi-factor authentication available, and can we require it?
  4. When someone leaves, how quickly is their access removed, and does it remove access to every site at once?
  5. Are sessions ended when a password is changed or an account is removed?

Good answer: a short, fixed list of roles you can verify in a demo. Be cautious of "fully customisable permissions" that nobody can show you.

C. The publishing path

  1. Who can make a change live on the public internet? Can we require approval before a site or a change is published?
  2. Is there a record of who published what and when?
  3. Can we roll a site back to a previous version, and how far back?
  4. Can a sub-account publish to a domain we own without our involvement?
  5. What stops someone publishing a page that impersonates another organisation, or a login form that collects passwords?

Good answer: describes the actual control, including its limits. "Single approval by the account owner" is a perfectly fine answer if it is true; "configurable multi-stage workflows" should be demonstrated, not accepted.

D. Domains, certificates and DNS

  1. How are custom domains verified as ours before a site is attached to them?
  2. How are TLS certificates issued and renewed, and what happens if renewal fails?
  3. When we remove a domain or close a site, what happens to DNS records that still point at you? Could someone else claim that domain on your platform?
  4. Whose name is the domain registered in when you register it for us?

Good answer: question 17 is the one most vendors have not thought about. A domain still pointing at a platform after the site is gone can be taken over by another customer of that platform if the platform does not check ownership. You want to hear how ownership is re-checked, not just that it is checked once.

E. Third-party scripts and embeds

  1. Who can add scripts, tracking tags or embedded widgets to a site? Can we restrict that per account?
  2. Does the platform itself add any third-party scripts to published sites? Which ones, and can we remove them?
  3. Do you support a Content Security Policy on published sites, and can we set our own?
  4. If a third-party script on one site is compromised, could it affect other sites in our organisation?

Good answer: a list. Platform-added scripts on your public site are your accessibility, privacy and performance problem as much as theirs.

F. Forms and what visitors submit

  1. Where are form submissions stored, and for how long?
  2. Who can see submissions: our staff, our clients, your staff?
  3. Can submissions be sent straight to our own systems instead of being stored with you?
  4. Can we export and delete submissions ourselves?
  5. What spam and abuse protection do forms have, and does it involve another third party?
  6. Do you prevent or warn against collecting sensitive categories of data in ordinary forms?

G. AI features

  1. Which AI provider or providers process our prompts, content and uploaded files?
  2. Is any of our content, or our visitors' data, used to train models? Point us to the provider terms that say so.
  3. Do form submissions or other visitor data ever get sent to the AI provider?
  4. Can AI-made changes be published without a human seeing them? Can we require approval?
  5. Can we switch AI features off for some accounts?

Good answer: names the provider and points to that provider's terms. "Our proprietary AI" with no named model or terms is a reason to ask again.

H. Email sent in our name

  1. Which emails does the platform send to our clients or users, and from which address?
  2. Can we send from our own domain? Which DNS records do we add, and do they cover SPF, DKIM and DMARC alignment?
  3. If we do not set up our own domain, what will recipients see in the From line and where do replies go?
  4. Do marketing-type emails carry a working unsubscribe, and is it honoured automatically?

I. Logs and records

  1. What actions are recorded in an audit log, and who can read it?
  2. How long are logs kept? Can we export them?
  3. Do you log access by your own staff to our data?
  4. If we receive a public records request or a legal hold, what can you produce, and how fast?

Good answer: a real screen with real entries, plus a retention period in writing. If the vendor cannot state retention, plan to export logs on a schedule yourself.

J. Vulnerabilities and incidents

  1. How do researchers report a vulnerability to you? Do you publish a security.txt file?
  2. How are vulnerabilities in your platform and its dependencies found, prioritised and fixed?
  3. Do you commission independent penetration tests? Can we see a summary, its date and its scope?
  4. How soon will you tell us about an incident affecting our data, by what channel, and is that time in the contract?
  5. Who are your sub-processors, and how do you notify us of changes?

Good answer: a security.txt file is defined in RFC 9116. It lives at /.well-known/security.txt and must contain at least a Contact and an Expires field, so you can check for one yourself in ten seconds. On incident timing: if you are a controller under the EU GDPR, the GDPR gives you, as controller, 72 hours where feasible to notify the authority, but requires a processor only to tell you "without undue delay". That is why a number of hours belongs in the contract.

K. Leaving

  1. Can we export every site, including code, media and form data, without your help?
  2. What happens to our sites, domains and data on the day the contract ends, and thirty days later?
  3. Will you confirm deletion in writing?
  4. Could another provider run the exported sites without your platform?

Our vendor exit plan guide turns these into contract clauses.

Weigh the evidence, not the adjectives

Two vendors can both answer "yes" to question 10 and mean very different things. Score each answer by the strongest evidence behind it:

LevelEvidenceHow much weight
0A claim on a marketing page, or "yes" with no detailNone until supported
1A specific written answer from the vendorSome; it can be held to in a contract
2Documentation: policy, architecture note, help articleMore, if dated and specific
3Shown working in a live demo on your requestHigh for features; says little about internal process
4An independent report or certificate, in date, with a scope that covers the product you are buyingHighest for internal controls; read the scope

For a website platform, level 3 matters more than buyers expect. Approval, roles, domain checks, export and audit logs are all things you can ask to see in twenty minutes. Ask.

Red flags

How We.Inc answers, where we can

We would rather answer fewer questions truthfully than all of them vaguely. These are the answers we can give on this page, each tied to something you can see in the product. Everything else, ask us in writing during a demo and judge the answer by the evidence levels above.

QuestionOur answer
5. RolesA small, fixed set of team roles (owner, admin and member). We do not offer custom roles.
6, 13. Per-account restrictionsFor each client account you choose whether it can publish, connect its own domain, see the code, and use the blog, store, forms and SEO settings. A brand-wide default applies unless you override it.
10. Approval before publishingYes: "publishing needs my approval" can be the default for all clients or set per client. It is a single approval step by your team, not a multi-stage workflow.
11, 38. Audit logAn audit log of organisation actions, showing date, user, action, the record affected and details. We do not publish a retention period or immutability claim.
15. Custom domainsYour portal and each client site can run on domains you own.
35, 36. Email in your nameEmails to your clients carry your brand name, logo and support address for replies. Until your own sending domain is verified they go from our delivery address; once you add the DNS records and it verifies, they come from your domain.
47, 50. ExportEach site's code can be downloaded as a ZIP or synced to a GitHub repository, and runs without our platform.
Certifications (from your standard questionnaire)We do not claim SOC 2, ISO 27001 or similar certifications, and we do not publish a contractual availability figure or a choice of data region.
AccessibilitySites are built and edited with AI. Your team must test published pages; we do not claim conformance with any accessibility standard.
Team panel listing three team members with Admin and Member badges and a form to invite a new member by email with a chosen role
Team roles on the demo brand. People are invited by email with a role, and the form says what that role can do (here, a Designer opens and edits any client's site but has no access to billing).
A client account opened in the client manager, with switches for SEO settings and a Publishing needs my approval option, plus notes, tags and pause or remove controls
Per-client switches, including approval before publishing, and the controls to pause or remove a client.
Audit log table with two entries reading Updated client details, showing date, user identifier, action, the client record affected and the changed fields
The audit log with two real entries from editing a client. The user column currently shows an account identifier rather than a name.
Code panel in the site editor showing the project file tree, a component source file and a Download button
The code panel: each site is real code that can be downloaded.
Export project dialog with tabs for GitHub, ZIP, Vercel and Domain, a repository name field and a private repository option
Exporting a site to your own GitHub repository or as a ZIP file.

Send us your questionnaire, or this one, before a 30-minute demo and we will show the items above live on the call. For the wider buying process, see the website platform procurement checklist.

Sources

Last checked 2026-10-25.

This questionnaire is general information, not legal or security advice. Adapt it with your security and legal teams to your own obligations.

Frequently asked questions

Do I need a separate security questionnaire for a website builder?

Use your standard one (CAIQ, HECVAT or your own) and add website-specific questions. Standard questionnaires rarely ask who can publish to your domains, what happens to DNS after a site is removed, which scripts the platform adds to public pages, or what AI features do with your content.

What is the most overlooked website security question?

What happens to domains that still point at the platform after a site is closed. If the platform does not re-check ownership, another customer may be able to attach a site to that domain. Ask how ownership is verified and re-verified.

How should I score vendor answers?

By the strongest evidence behind each answer: a marketing claim counts for nothing, a written answer for some, documentation for more, a live demonstration for a lot on product features, and an in-date independent report with the right scope for the most on internal controls.

Does We.Inc hold security certifications?

We do not claim SOC 2, ISO 27001 or similar certifications. We can show roles, per-client restrictions, approval before publishing, the audit log, custom domains and code export live in a demo, and answer the rest of your questionnaire in writing.

More in Guides

Related guides and tools

Start building

We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label pricing is tailored to your volume and setup: book a 30-minute demo for a quote.

Product

Who It's For

Features

Resources

Company

View Sitemap