Security and your data

1. What this page covers

Two different things sit under one account: the Mondovo application you build in, and the sites you publish out of it. This page describes both, and where they behave differently it says so.

It is the third of three documents a supplier review usually asks for. The privacy policy says what personal data we collect and why. The sub-processors page names every company that processes data on our behalf, what each one does, and what reaches it. This page covers access, publishing, retention and your data from start to finish.

2. PHP2Shell (October 2026): Mondovo sites are not affected

On 21 October 2026, PHP released emergency fixes for two critical security flaws, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They can let an attacker take over a server running PHP without a password. PHP is the software behind most WordPress sites, so those sites depend on their host installing the fix.

Sites published on Mondovo don't run PHP, plugins or WordPress. They are served as finished pages from a global network, so they are not affected, and there is nothing you need to do.

• What the PHP2Shell flaws mean, in plain English

If you also run a WordPress site, ask your host to confirm it has been updated.

3. Data in transit

Traffic between you and the Mondovo application is encrypted, and so is traffic between a visitor and a site you publish.

Every published site gets its security certificate automatically as part of publishing, on your own domain, with nothing for you to buy, install or renew.

4. Who can reach production data

• Access to production data is restricted to the people who need it to run and support the service.
• The credentials and connected-account tokens you give us — the authorisations for accounts you link to a site — are stored encrypted.
• Administrative actions are recorded, so a change made on your account can be traced to whoever made it.

5. How a published site is served

When you publish, your site is compiled to fast, static pages and served from a global content network, close to your visitors wherever they are. There is no server-side application or plugin running behind each page, which leaves far less for an attacker to target.

Your live site also runs independently of the Mondovo application. If our editor ever has a problem, your client's published site keeps being served as normal; only new changes wait to be published.

6. Who can do what

Access to a site is granted by role. There are seven. They are enforced in the database rather than only in the interface, and the check runs on each protected request rather than only when a screen is drawn, so a role cannot be worked around by calling an address directly.

The two roles worth knowing before you approve anything: publishing requires admin, and editing requires editor. The three client-facing roles let the person reviewing the work see it and comment on it without being able to change it by accident.

7. Version history and putting things back

Every change is kept as a version. Restoring is self-serve — you do it yourself, in a click, with no ticket to raise — and it can be the whole design or a single page. A restore is itself recorded as a version, so a restore can be undone too.

What is kept:

• For each page in each design, the last hundred versions, however old they are.
• Everything from the last sixty days, however many versions that is.
• Any version you published or pinned, for as long as the site exists.
• Up to five hundred unpublished versions across a whole site.

Want a copy outside Mondovo as well? You can export the published site, your content and your contacts at any time.

8. Drafts and work in progress

Work that has not been published stays private. Draft addresses tell search engines not to index or follow them, so a client's unfinished site does not turn up in a search for their name.

A draft link can also be locked behind a key, so that only somebody holding the full link can open it, and previews can be switched off for a site entirely. Shared review links follow the same no-indexing rule.

9. Deleting a site

Deleting a site moves it to a trash you can restore it from, so an accidental deletion is easy to undo.

About thirty days later it is removed permanently, along with the files it published and its version history.

10. Leaving

Your work is yours to take with you. Admins can download the published site as a complete static bundle of HTML, CSS, JavaScript and media, and export content and contacts separately.

Your saved designs and content stay in your account until you choose to delete them, so you can come back and republish later.

Your domain stays yours throughout. It is registered to you, at your own registrar, under your own account, and it points here through a record you control. If you ever move, you simply repoint that record, with nothing to request from us.

11. Sub-processors and agreements

Every company that processes data on our behalf is named on the sub-processors page, together with what it does and what actually reaches it. That page carries a date, and it changes when a provider is added or removed.

A data processing agreement is available on request. Ask at the address below, and say whether you also want to be told in advance when the sub-processor list changes.

12. Reporting a problem

If you think you have found a security problem, write to the address below with enough detail for us to reproduce it, and please give us a chance to fix it before it goes anywhere else. We would rather hear it from you.