Odoo Security & Access Control
Odoo's security model is more powerful than most teams realise — and more often misconfigured than people admit. Done right, it gives you fine-grained control per user, per record and per company. Done wrong, the CEO sees the intern's reports and the salesperson sees the supplier prices.
We're regularly called in to fix Odoo security setups that drifted: too many admins, custom groups nobody owns, record rules added in panic that contradict each other, multi-company leaks. The pattern is the same — security wasn't designed at the start, just added when something broke.
This guide is the reference we use when we design or audit security on an Odoo instance. It covers the concepts (groups, ACLs, record rules), the multi-company model, the audit trail, GDPR essentials, and the operational practices that keep security clean over time.
Groups, ACLs, record rules — the three layers
Odoo security has three layers. Groups (user → group membership) define what a user is. ACLs (group → model) define what each group can read, write, create, delete on each model. Record rules (group → record subset) refine to specific records — only your team's leads, only your department's purchase orders.
Most security incidents we investigate trace to one of two patterns: too many users in 'Settings' or 'Admin' groups (so ACLs don't bite), or contradictory record rules across groups (a user inherits both 'Own only' and 'All' rules, the OR logic gives them everything). Discipline on group membership is half the battle.
- Three layers: groups (user is what), ACLs (group can do what on model), record rules (which records)
- Group membership discipline is half the battle — too many admins = no security
- Record rules use OR logic across groups — contradictions give the broadest access
- Standard Odoo groups (User/Manager/Settings) cover 80% of needs out of the box
- Custom groups should be rare and well-documented — each one adds maintenance cost
Multi-company isolation — the trap many groups fall into
Multi-company in Odoo can mean isolation (each company's data invisible to the other) or sharing (group-level data visible across). The default tends toward sharing, which fits most groups but can leak information you didn't intend — financial figures of company A visible to a user of company B.
We always run a 'multi-company audit' on existing setups: log in as a user of each company, walk through the menus, verify what's visible and what isn't. Surprises are common. The fix is usually a tightening of company-aware record rules and a careful review of which models support company isolation natively.
- Multi-company can be isolation or sharing — default tilts toward sharing
- Some models (partners, products) shared by default; others (invoices, sales orders) per-company
- Audit by logging in as users of each company and walking the menus
- Tighten record rules per company where leaks are found
- Inter-company transactions need their own setup — partial visibility by design
Audit trail and the question of 'who did what'
Odoo's mail thread captures most user actions on records — who created, who modified, who logged what message. For deeper audit (who changed which field at what time), the audit log module (OCA or paid) is needed. For compliance-sensitive sectors (finance, healthcare, regulated industries), this isn't optional.
The audit trail is only useful if it's consulted. We set up a standard audit review cadence with our clients — monthly look at the most-modified records, the most-active users, the unusual patterns. It catches issues early and demonstrates governance to auditors.
- Mail thread captures most user actions natively — basic audit out of the box
- Field-level audit needs a module (OCA or paid) — non-optional for regulated sectors
- Audit log is only useful if reviewed — monthly cadence catches issues early
- Login logs and session tracking available via standard Odoo admin tools
- External SIEM integration possible via Odoo's logs and webhooks
Authentication, SSO, MFA — the modern baseline
Native Odoo authentication is fine but the modern baseline is single sign-on (SSO) via SAML or OAuth, ideally with multi-factor authentication enforced. Odoo supports both natively or via modules. For Microsoft-centric Belgian SMEs, Azure AD SSO is the most common setup we deploy.
MFA should be mandatory for anyone with admin or manager rights, ideally for all users. Password policies, session timeouts, and IP whitelisting where appropriate complete the baseline. None of this is exotic — it's standard for any business application in 2026.
- Native auth is fine for small teams — SSO + MFA is the modern baseline
- SAML and OAuth supported — Azure AD SSO is the typical Belgian SME setup
- MFA mandatory for admins and managers minimum — all users ideally
- Password policies, session timeouts, IP whitelisting complete the baseline
- Integrate Odoo logs into your SIEM if you have one — webhooks make it easy
GDPR essentials — what Odoo gives you and what you must add
Odoo gives you the technical foundation for GDPR: personal data inventory (Contacts, HR, partners), audit trail, encryption in transit, backups, deletion of personal data via standard or custom procedures. What it doesn't give you: the policy, the consent management, the documented retention rules.
We help clients with the GDPR-Odoo overlap: data subject access requests (export and deletion), retention schedules (auto-archive after X years), consent tracking for marketing, and data processing agreements with Odoo / Odoo.sh / hosting. The technical part is solvable; the process part needs ownership in your organisation.
- Odoo gives the technical foundation — data inventory, audit trail, encryption, backups
- Data subject access requests (export, deletion) implementable but need procedure
- Retention schedules via auto-archive jobs — implement explicitly per data category
- Consent tracking for marketing — module-supported, needs configuration
- DPA with Odoo / Odoo.sh / hosting provider is mandatory — sign it before go-live
Security mistakes we keep seeing in audits
These are the patterns that produce real exposure — sometimes regulatory, sometimes commercial.
- Too many users in admin/settings groups — ACLs don't bite.
- Custom groups added over years with no documentation — nobody knows what they grant.
- Multi-company assumed isolated when it isn't — financial leak across companies.
- No MFA on admin accounts — single password compromise = full system access.
- Audit trail enabled but never reviewed — useful only after an incident, not before.
Metrics that prove your Odoo security posture is healthy
We track these quarterly with IT and the data protection officer. Steady metrics = steady posture.
- Number of admin users <5% of total user base — minimum-privilege working.
- MFA enforcement at 100% for admins and managers, >80% for all users.
- Custom groups inventoried with documented purpose — zero 'orphan' groups.
- Multi-company audit walk-through done at least yearly with no leaks found.
- Audit log review cadence respected (typically monthly) with documented findings.
How we design and audit Odoo security at Flydoo
On new implementations we design security from day one: user matrix per role, group inheritance, ACL design, record rules. Multi-company setups get an explicit isolation plan. SSO and MFA are configured before go-live, not after.
On existing setups we run a security audit: review of groups, ACLs, record rules, multi-company configuration, MFA coverage, audit-log review. Output is a prioritised remediation plan. Most audits surface one or two real exposures plus a handful of cleanup items.
- User matrix per role designed before configuration starts
- Custom groups limited and documented; standard groups preferred
- Multi-company isolation plan explicit, audited by walking menus as test users
- SSO and MFA configured before go-live, mandatory for admins and managers
- Audit log review cadence agreed with the DPO and finance — monthly minimum
Practical security checklist for an Odoo instance
Walk this list with IT, the security officer and the DPO. Most ticked = healthy posture.
- User matrix per role documented and applied
- Admin users <5% of total — minimum-privilege respected
- Custom groups inventoried with documented purpose
- Multi-company isolation audited by walking menus as test users
- MFA enforced for all admins and managers, ideally for all users
- SSO configured (Azure AD, Okta, Google) where applicable
- Audit log review cadence agreed and documented
- DPA signed with Odoo / Odoo.sh / hosting provider
Key takeaways
- Odoo security has three layers: groups, ACLs, record rules — design them, don't bolt them on
- Discipline on group membership (especially admin) is half the battle
- Multi-company default tilts to sharing — audit explicitly to confirm what leaks and what doesn't
- MFA is mandatory for admins and managers in 2026 — no exceptions
- GDPR: Odoo gives the tools, you must own the policy and review cadence
- Audit logs are useful only if reviewed — monthly cadence catches issues early
Frequently asked questions
How granular can Odoo's record rules get?
Very. You can scope visibility to records owned by the user, by their team, by their company, by any field combination. We've built rules like 'sales managers see all leads in their region except those tagged confidential'. The risk isn't 'Odoo can't do it' — it's 'we built ten layered rules and nobody understands the result anymore'. Keep rules minimal and documented.
Is Odoo's multi-company strong enough to host a holding with subsidiaries?
For most holdings, yes. Each subsidiary as a company, isolation rules tightened, finance per company. For a regulated holding (banking, insurance) with strict separation requirements, you may need additional controls and possibly separate Odoo databases. We assess case by case based on your regulatory framework.
Does Odoo support SAML / OAuth / Azure AD SSO?
Yes — SAML and OAuth are supported natively in Enterprise; Community has modules. Azure AD is the most common SSO we configure for Belgian SMEs. We typically pair it with MFA enforced at Azure AD level, so the Odoo experience is 'click button → in', and the security gate is at the IdP.
What's the GDPR data retention story for Odoo?
Odoo doesn't enforce retention by itself — you decide. We typically configure auto-archive jobs that move records to archived state after a defined retention period (e.g. 7 years for finance, 3 years for marketing leads). Hard deletion of personal data is implemented per GDPR DSAR procedure. The technical mechanisms are there; the policy is yours to set.
How do we audit an existing Odoo for security issues?
Start with five things: (1) list all users with admin or settings rights, (2) inventory all custom groups and what they grant, (3) walk multi-company menus as a test user of each company, (4) check MFA coverage, (5) verify the audit log is actually being reviewed. From there, our standard security audit takes 2-5 days for an SME instance and produces a prioritised remediation plan.
Need help applying any of this to your own context? We're happy to talk.