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 is about access, retention and what happens when things end.

2. Data in transit

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

A published site is issued its certificate as part of publishing, on your own domain, with nothing for you to buy, install or renew. Renewal is not something you have to remember.

3. 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.

This section is the whole of what we are prepared to say about stored data. Section 11 says what we are deliberately not claiming.

4. How a published site is served

A site you publish is compiled to static pages and served from a content network with locations around the world. It is not an application that runs on each request, and serving it does not depend on the Mondovo application being up.

The practical consequence for your client: a fault in our application will not usually take their published site offline. Publishing a change to it would have to wait; the site itself keeps being served.

That is a description of how the system is built, not a commitment about availability. We do not offer one — see section 11.

5. 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 exist so that the person reviewing the work cannot accidentally change it.

6. Version history and putting things back

Every change is kept as a version. Restoring is self-serve — you do it, you do not raise a ticket for it — and it is either the whole design or a single page. A restore is itself recorded as a version, so a restore can be undone.

What is actually kept:

• For each page in each design, the last hundred versions, regardless of how old they are.
• Everything from the last sixty days, regardless of how many versions that is.
• Any version you published, or pinned, is never removed by the automatic cleanup.
• Across a whole site, a ceiling of five hundred unpublished versions. On a site being edited heavily, that ceiling is the limit you will meet first.

Two things this is not. It is not a backup: it lives inside the same account as the site it belongs to, and deleting the design or the site removes its history along with it. And it cannot be taken out — there is no export. Section 11.

7. Drafts and work in progress

Work that has not been published is not public in the way a published site is. Draft addresses are served with instructions telling 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. A shared review link carries the same no-indexing rule: the link is the secret.

8. Deleting a site

Deleting a site moves it to a trash you can restore it from, so an accidental deletion is recoverable on the day it happens.

About thirty days later it is removed permanently, along with the files it published and the version history that belonged to it. After that we cannot get it back for you.

9. Leaving

This is the question an agency's client should ask before signing anything, so here is the whole answer.

If a subscription ends, sites are taken offline after the period you have already paid for. Nothing is deleted at that point. The subdomain, the design, the code, the content and the version history stay in the account, and republishing is never blocked by which plan you are on — pay for the live site again and it goes back up.

The domain is not ours to hold. It is registered to you, at your own registrar, under your own account, and it points here through a record you control. If you leave, you repoint that record. We cannot prevent it and there is nothing to request from us.

What we do not offer is a copy to take with you. See section 11 before you decide this is enough.

10. 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.

11. What we do not have

If you are assessing us, read this section first. We would rather be taken off a shortlist for something we do not have than be asked about it after a client has signed.

• No certification. We hold no SOC 2, ISO 27001, HIPAA or PCI attestation, and there is no audit report to send you.
• No independent penetration test to show you.
• No availability commitment. We publish no uptime figure and we offer no service level agreement.
• No export. There is no way to download a site's code or content as a file, and version history is not a substitute for one — it lives in the same account. If having your own copy is a condition of your review, this is the honest answer: we do not provide one today.
• No multi-factor authentication and no single sign-on.
• Beyond the stored credentials and connected-account tokens in section 3, this page makes no claim about how data is encrypted while it is stored.

Every line here is a statement about today, not a roadmap. When one of them stops being true it moves out of this section and the date at the top of the page changes with it.

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.