Most security incidents on an Odoo deployment are not exotic. They are an ex-employee whose account was never deactivated, an API key pasted into a shared spreadsheet, a third-party module downloaded from a forum thread, or a portal user who can read far more records than anyone intended. None of those get fixed by choosing a better host. That is the thing worth understanding before you sign a hosting contract: managed hosting removes one specific set of problems and leaves another set entirely with you.
The confusion is costly in both directions. Teams assume the host is watching their user permissions, so nobody reviews them. Or they assume nothing is covered, and spend weeks rebuilding controls that already exist. Here is where the line actually falls.
What the hosting layer owns
A managed Odoo host is responsible for the parts of the stack you cannot reach from inside Odoo:
- The server and runtime. Operating system patching, container images, and the resources your instance runs on.
- Network exposure. TLS certificates and renewal, which ports are reachable from the internet, and isolation between one customer's environment and another's.
- The database service. Including automated backups and point-in-time recovery, so a bad import or a corrupted table is recoverable rather than terminal.
- Infrastructure monitoring. So a failing disk or an unhealthy container shows up on a dashboard instead of arriving as a support ticket from your accountant.
- Environment separation. Staging and sandbox environments that let changes be tested somewhere that is not your live database.
If your host does all of this, your infrastructure risk is genuinely low. It is also, unhelpfully, not where most breaches start.
What stays with you, permanently
Everything inside the Odoo application is yours. No hosting arrangement changes that, and any provider claiming otherwise is describing something they cannot see:
- Users and deactivation. When someone leaves, their Odoo user has to be archived. Removing their email account does not remove their Odoo login, and an active user with a saved session or an API key keeps working.
- Access rights and groups. Which users are in which groups, and whether anyone has been quietly promoted to a settings-level group to unblock a task and never demoted.
- Record rules. The multi-company and per-user filters that decide which records a given user can see. These are the most commonly misconfigured control in Odoo, and they fail silently: nobody reports being able to see too much.
- Portal and website users. Customers and vendors with portal access are real users. What they can read is defined by your rules, not by your host.
- API keys and integrations. Every key you issue is a credential with the permissions of the user who created it. Keys issued to a system administrator inherit administrator scope.
- Your data itself. What you collect, how long you keep it, and who you share it with is a business decision, not an infrastructure one.
The gray zone: third-party modules
This is where responsibility genuinely blurs, and where honest hosts and optimistic ones diverge. A module you install from the Odoo app store or a community repository runs with full access to your database. It can read every table, call external services, and modify records. The host provides the environment it runs in; it does not audit the code.
Treat every third-party module as code you are adopting: check whether it is maintained for your Odoo version, install it in staging first, and know who you would contact if it breaks after an upgrade. A module that has not been updated in two major versions is a liability regardless of how good the hosting is.
Compliance belongs to the localization modules
Worth stating plainly, because it gets marketed loosely: ZATCA e-invoicing in Saudi Arabia, ETA in Egypt, FTA VAT reporting in the UAE, and WPS payroll files are delivered by Odoo's official localization modules. A hosting provider runs those modules; it does not certify them, and neither does a consultancy. What hosting contributes is that the modules are installed on a supported version and that you have a tested environment to validate output before it reaches a tax authority.
A review worth running twice a year
Open the user list, filter to active internal users, and check every one against your current headcount. Then open the groups configuration and look for anyone in an administrative or settings group who should not be. Then list your API keys and delete the ones nobody can explain. Most organizations find something on the first pass. It takes an afternoon, and it addresses more real risk than any infrastructure change you could make in the same time.
Questions to ask a hosting provider
Ask how often backups run and how recovery is actually tested, not just whether backups exist. Ask whether you get a staging environment, and whether restoring production into it is a routine operation. Ask what happens to your data if you leave, and in what format. Ask who has administrative access to your database on their side, and under what circumstances.
If you want the application layer covered as well as the infrastructure, that is a support engagement rather than a hosting one, which is what our managed support and SLA service exists to handle. And if you would rather have hosting and change requests in one place, Plemo combines managed Odoo hosting with a request flow that runs every customization through a written spec and a sandbox preview before it touches production.
The short version: your host should make the infrastructure boring. Keeping the application honest is still your job.