The auditors want to audit the DBAs, not just access to the database, they want to see what data changes the DBA do.
Thanks,
That's non-trivial. It will be relatively straightforward to enable OE Auditing, assuming familiarity with the documentation. As with many other database features, there are OE Auditing best and worst practices and that is a lengthy (and separate) discussion topic. You can find some of that with a site search here.
But OE Auditing, in and of itself, isn't a complete solution that will just give your auditors what they want. Once implemented and configured (which also requires some business decisions to be made; it isn't just technical work), you have raw audit
data. There is no OpenEdge audit data viewer/analyzer tool or application. You have to design and build that yourself. You also have to think hard about the life cycle of the data, define it rigorously, and implement policies and procedures to enforce it.
"What data changes the DBAs do" could mean any create/update/delete operation on any table. So if you don't audit everything, the audit trail will be incomplete. Of course that also means having a business process for ensuring that you continue to modify the auditing configuration as the scope of "everything" changes when the application schema does. Auditing everything is a lot of work and, depending on write volume, may generate enormous amounts of audit data and the accompanying BI/AI volume increases and their various effects. Again, don't ignore the best practices or else you (or your successor) will regret it.
Also, give some thought to the idea that OE Auditing is implemented by the DBA.
Good luck!