Odoo IT Audit Software Consulting

The core ITGC access-management tests — who has access, is it appropriate, was it approved, is it removed on termination — all require a clean listing of users mapped to groups and, ideally, to job function. Odoo's Settings > Users list gives an administrator this view interactively, but producing an exportable, auditor-ready population (every user, every group, as of a specific date, with prior-period comparison) usually requires either a saved list-view export or a small custom report, since the default UI is built for administration, not for point-in-time audit sampling. New-user provisioning and termination evidence is similarly assembled by hand: Odoo logs user creation and archiving events in the chatter on the res.users record if tracking is enabled, but there is no native new-hire or termination workflow that automatically ties access changes to an HR event.

The deeper limitation, consistent with Odoo's SoD posture generally, is that a clean access list does not by itself demonstrate appropriateness — an auditor still needs a role-to-job-function mapping to judge whether access is correct, and Odoo does not generate that mapping natively. Most Odoo IT-audit engagements end up building a maintained spreadsheet or Studio model cross-referencing each security group to the job functions it is intended for, which becomes the reference document access reviews and audit testing are performed against.

Change management testing looks for evidence that changes to the application — code deployments, configuration changes, database schema changes — were requested, approved, tested, and deployed through a controlled process. Odoo.sh, the platform's managed hosting product, provides a genuinely useful evidence source here: it tracks git-based deployments with commit history, branch merges, and deployment timestamps, which maps reasonably well to a change-management control for code-level changes. Self-hosted Odoo deployments do not get this for free and need an equivalent CI/CD or deployment log built separately.

Configuration changes made through Studio are a harder case. Studio does maintain some internal versioning, but it is not exposed as a formal, exportable change log comparable to a ticketing system's audit trail, and changes made directly through developer mode (editing a view, adding a field via technical settings rather than Studio) may leave even less trace. The practical control most SOX-scoped Odoo deployments adopt is procedural: route all financially relevant Studio and developer-mode changes through an external change-ticketing tool (Jira, a helpdesk queue, or similar), with the ticket serving as the system of record for approval and testing evidence, since Odoo itself cannot be relied on to produce a complete change history for anything outside Odoo.sh's code deployments.

Computer-operations ITGCs test that batch jobs run as scheduled, backups are performed and tested, and system availability is monitored. Odoo's ir.cron table holds scheduled-action definitions (like automated invoice reminders or recurring report generation) and their last-run status, which gives an auditor a queryable source for scheduled-job evidence, though again it requires a report to be built rather than being presented as an audit-ready log by default. Backup evidence depends entirely on the hosting model: Odoo.sh includes automated daily backups with a defined retention policy that can be pointed to directly as evidence, while a self-hosted deployment's backup evidence is only as good as whatever backup and restore-testing process the infrastructure team has built and documented independently of Odoo.

Where Odoo genuinely helps is that because so much of the operational and financial workload runs inside a single application, the population of scheduled jobs relevant to financial reporting (nightly reconciliation exports, scheduled report emails to finance) is usually small and identifiable, which keeps computer-operations testing scope manageable even without native ITGC tooling. The work that remains is documentation: capturing job names, schedules, and owners in a reference list that can be tied back to ir.cron records during testing, since no such reference list exists in Odoo out of the box.