What a Security Review of WebinOne Turns Up: The Answers, and Where They Are Published

A platform security review is not a sales conversation. Someone in your client's organisation, or in your own, works down a list: who is responsible for what, where the data sits, what happens in an incident, what the contract actually promises, and what is explicitly out of scope. This page answers that list from WebinOne's own published documents, quotes them rather than paraphrasing them, and names the items that belong in a contract rather than in an assumption.

For the platform and architecture context, the companion pieces are the systems integrator briefing, what runs where on AWS and how an integrator delivers on the platform. This one is the review.

What does WebinOne publish before you have to ask for it?

Four documents, all public, all linked from the footer of every page. The security overview is a full whitepaper covering infrastructure, data location, authentication, physical security and personnel controls, and it offers a PDF version for attaching to a review pack. The incident response plan is published as its own document, with a named responsible officer and a defined escalation path. The terms of service carry the contractual layer: intellectual property, confidentiality, data processing, availability and liability. The privacy policy covers collection and cookies.

Getting these before a call is the point. Most of the questions a reviewer sends a vendor are already answered here, which means the call can be spent on the two or three that are not.

Who is responsible for what between AWS, WebinOne and your own practice?

Three layers, and the middle one is stated precisely. Our security overview puts it this way: "AWS operates, manages, and controls the components from the hypervisor virtualization layer down to the physical security of the facilities in which WebinOne operates. In turn, WebinOne assumes responsibility and management of the guest operating system (including updates and security patches) and application software, as well as the configuration of the AWS-provided security group firewall."

The third layer is yours and it is not in that sentence. Your practice owns the client's content, the admin users you create, the integrations you build against the platform, and the credentials your team holds. The terms of service say so directly — "You are responsible for determining whether the Services meet applicable regulatory standards and otherwise comply with your own security requirements" — and that clause is the one worth reading twice before you sign a client into a regulated sector.

Which AWS services does the platform actually run on?

The named list is published, which is unusual enough that an AWS practice should read it as a signal about how the platform is built. Our security overview states that WebinOne "is fully hosted in Amazon Web Services (AWS) and it takes advantage of a large set of its products: Amazon Elastic Compute Cloud (EC2) for scalable computing capacity in the cloud, Elastic Block Store (EBS) and Simple Storage Service (S3) for storing and retrieving data, Virtual Private Cloud (VPC), Identity and Access Management (IAM), Security Groups, and others for security purposes, Simple Email Service (SES) for sending emails, CloudWatch for monitoring and others."

A service list is not an architecture, and a reviewer who knows AWS will treat it as a starting point rather than a design document. It does tell you that this is a platform operated inside AWS primitives rather than a hosting arrangement described in AWS vocabulary, and it tells your architects which conversations are worth having in the technical assessment.

Where does a client's data sit, and does it leave that region?

It stays where it was placed, and the mechanism is published rather than implied. Our security overview states: "Except for very little operational information (e.g., DNS entries), customers' data is stored exclusively in the designated AWS region/data center. Content that customers store in WebinOne (e.g., assets) is not replicated to other data centers in other regions."

Read the exception rather than skipping it: DNS entries are called out as operational information that does exist outside the designated region. For a residency requirement that is normally fine, and it is far better to see it named than to discover it later. Which region a specific client's site runs in is confirmed during the technical assessment, and the current list of available regions is published on the platform pages — get the one that applies to your client in writing, because it is the kind of answer a reviewer will want attached to a name rather than to a marketing page.

Who owns the content once it is on the platform?

Your client does, and the terms of service are unambiguous about it: "Customer Content is and remains your exclusive property, and we claim no rights whatsoever to the Customer Content except to the extent explicitly granted herein." The grant that follows is a service licence — the right to host, reproduce and display the content "solely and strictly to the extent required to provide the Services to you under the terms of the Agreement."

The counterpart is stated just as plainly: we own the platform, the systems and networks used to deliver it, and all system-generated data such as performance data. That is the normal split for a hosted platform, and the reason to read it in a review is scope. Content and end-user records are the client's to take. The platform is not, which is why the exit question is about portability of your build rather than ownership of your data.

How are backups handled, and what is actually promised?

Backups run on the platform, and the promise attached to them is narrower than the mechanism. The platform takes its own snapshots on a lifecycle policy, and the terms of service separately disclaim any guarantee that a restore will succeed, which means the mechanism and the entitlement have to be read together rather than one standing in for the other. Our security overview states that "WebinOne stores data in Amazon EBS and backs it up via snapshot lifecycle policies every 12 hours" — that is our own published figure, and it describes the platform's snapshots rather than a per-site restore product.

The terms of service then set the expectation an architect should design against: "Although we may perform regular backups of your site and Customer Content, we do not guarantee that there will be no loss or corruption of data… you acknowledge that we have no liability related to the integrity of your backups or the failure to successfully restore your content to a usable state. You agree to maintain a complete and accurate copy of any Customer Content in a location independent of the Services."

That last sentence is a design instruction, not fine print. If you manage a portfolio of client sites, an independent copy of content is your responsibility under the agreement you have signed, and the retention window that matters to a client is a contract item rather than something to infer from the snapshot interval. Raise it during the technical assessment and get the answer written down.

Is there an availability commitment, and what happens when it is missed?

Yes, and it is contractual rather than promotional — the terms of service carry a Service Level Agreement section. It sets an availability target, defines the downtime that is excused from it, and attaches a credit-based remedy with a claim window, which is a different kind of statement from an availability figure quoted on a marketing page. It commits to making the services available 99.95% of the time excluding defined Excused Downtime, and it defines that term: scheduled maintenance, emergency maintenance, beta features, force majeure, your own actions or configuration beyond advertised limits, and "Downtime on the side of the hosting provider, such as AWS."

The remedy is a credit, and it is capped. You are entitled to "a credit of 5% of the applicable monthly Fees for each full hour of downtime in excess of the Service Availability targets", claimed through support within 30 days of the event, capped at 100% of the applicable monthly fees, not carried over and not refunded in cash. The section states that it is your sole remedy for downtime. AgentOne, our AI delivery layer, is in Partner Beta and is explicitly excluded from the availability commitment and the credits while it stays there.

Two things follow for a delivery practice. The AWS exclusion means the availability commitment sits above the infrastructure layer, so a regional AWS event is not a credit event. And a credit against monthly platform fees is not a commercial remedy for your client's downtime, which is a gap to price into your own contract rather than a defect to argue about in ours.

What happens when there is a security incident?

There is a published plan with a named owner, which is more than most platform reviews get to see. The terms of service commit to notification: "Should we determine that our network has been accessed in an unauthorized manner and that unauthorized access impacts your Services, we agree to notify you as soon as reasonably practicable after we have investigated the unauthorized access and fulfilled our legal obligations, in accordance with our Incident Response Plan."

The plan itself names the Chief Infrastructure Officer as responsible officer and Incident Commander, with the CTO as the default deputy. It defines reporting into a single support address, three response teams — management, containment and communications — a severity level of High, Medium or Low assigned by the Incident Commander, an after-action debriefing, and secure retention of evidence. It also states that findings are reported to partners in Slack within 72 hours of the initial incident report.

Two honest notes for a reviewer. The plan carries its own last revision date of July 2020 on the page, so ask when it was last exercised rather than when it was last edited. And the published notification path runs to partners over Slack, which is a communications channel rather than a contractual notice mechanism — if your client's own breach-notification obligations depend on receiving a formal notice, agree that path in writing during the assessment.

Under GDPR, who is the controller and who is the processor?

The split is defined in the terms of service, and it lands where an integrator would expect. Where European data protection law applies, we are the data controller for the personal data you provide through the portal, and the data processor for everything you collect from your own employees, customers or end users and pass to the platform. The processor commitment is stated: "Where we are the data processor, we will use such personal data only as instructed by you or required by law, and not for any other purpose."

Confidentiality is a mutual clause with a return-or-destroy obligation within 30 days of termination, and it expressly contemplates disclosure required by a supervisory authority. The entity behind all of it is named on the security overview: "WebinOne is owned and run by Upgrade Parade Corp - a USA-based entity (located in Sarasota, Florida) that carries all of WebinOne's transactions, contracts, agreements, and responsibilities." Governing law is Florida and US federal law, and total liability is capped at the fees paid or owed in the three months preceding a claim. None of that is unusual; all of it is the sort of thing a reviewer would rather read now than discover during redlines.

What does the AI layer do with a client's data?

This is the question that stops most platform reviews in 2026, and ours is answered in the terms of service rather than in a blog post. The AI functionality behind AgentOne is powered by large language models from Anthropic accessed through Amazon Bedrock, with AWS acting as the hosting and AI-processing sub-processor, and prompt data and output processed within AWS infrastructure in the regions applicable to the account.

The training commitment is explicit: "WebinOne does not use Customer Content, Customer Data, Agent Prompt Data, or Agent Output to train its own or any third-party AI models", and the same clause states that under the AWS and Amazon Bedrock terms, AWS does not store inputs or outputs for model-training purposes, does not use them to train the underlying models, and does not share them with the model provider. Sub-processors will not change without notice. Prompt data is treated as customer content, and rights in the output are assigned to you.

One limit is published rather than glossed, and a reviewer will find it, so read it here first: "We apply commercially reasonable measures to isolate agents and data between accounts but do not guarantee that isolation will be absolute." That is the honest state of the art for this layer across the industry. The practical answer for a sensitive client is to scope what goes into a prompt, which is a decision your delivery team controls.

What is explicitly out of scope?

The restrictions are worth knowing before you scope a project rather than after. The terms of service prohibit using the platform to store or process protected health information as defined under HIPAA, cardholder data protected under PCI DSS, or other financial account details, and they prohibit use where a failure of the services could result in death or physical injury. Ecommerce is supported, on the condition that you follow practices that keep card data from being processed or stored on the platform — payment gateways rather than card storage.

One more affects reviews directly: penetration testing of the platform's network or systems, including your own hosted environment, requires prior written approval. That is a normal clause for a shared platform, and the reason to read it early is sequencing — a client whose security process includes a pen test needs that approval requested before the test is booked, not after.

Which certifications are ours, and which are AWS's?

This distinction decides whether a review pack is accurate, and it is the single most common misreading of any hosted platform's security page. The SOC 1 Type 2 report referenced in our security overview covers AWS data centre physical and environmental controls; it is AWS's report, describing AWS's controls. The certifications and audits described in that section are AWS's too.

WebinOne itself does not publish an independent third-party audit report of the platform, and the security overview — which is the document that would carry one — does not cite one. The platform is not FedRAMP-authorised and is not CMMC-certified. What is published under our own name is the control set: mandatory HTTP to HTTPS redirect, 256-bit SSL, Let's Encrypt certificates renewed automatically every three months, multi-factor authentication with SSH and SSL for management connections to the AWS infrastructure, segmented development and production environments with authorisation-based employee access, background check reports for employment purposes, and a defined access-revocation checklist when an employee leaves. If your client's process requires a certification we do not hold, that is a real disqualifier and it is better established in week one than in month three — where WebinOne is the wrong choice covers the rest of that category.

What belongs in the contract rather than in an assumption?

Five items, and none of them is a reason not to proceed. An independent copy of client content and the retention window you need, because the agreement puts the first on you and does not publish the second. Your own incident notice path, in writing, if a Slack message to partners does not satisfy your client's obligations. Pen-test approval, requested before it is scheduled. The region a specific client's site runs in, named rather than inferred. And exit: there is no source-code escrow arrangement today, and the counterweight is published in our terms of service — "In case of an unlikely event of the Service being closed or discontinued for any reason, we commit to open-source the WebinOne platform to the level that every Reseller would be able to host their trial and live sites, WebinOne Portal, and SSO service without our support."

One clause deserves the last word, because it tells you how to read every vendor page including ours. The terms of service state that statements, descriptions, comparisons and performance claims on marketing pages "are provided for general information only, do not form part of this Agreement, and do not constitute warranties or representations." That is standard, and it is also the reason this page quotes the contract and the whitepaper instead of quoting the sales copy. When a claim matters to your client, source it to the document that governs.

Operationally, live service state is published on the system status page, dedicated capacity is scoped per site on dedicated servers, and larger programmes are covered on the enterprise page. If you are still choosing rather than reviewing, the evaluation framework is the companion piece, and portfolio migration covers what a multi-site move involves.