It varies. I've been in situations where the QA database was owned and maintained entirely by the QA team. That database was typically kept as a backup in a network share, and restored into the test environment at need.
In my current situation, the data cleanup is handled differently. The database is too large to restore in a viable time frame and contains too much sensitive data. Instead, there are other reset mechanisms which I have no access to. My approach here is to keep the data I create as clean as I can, clean up anything I run into which is bad, malformed, or ugly, and make as much as I do reversible as I can.
If the QA database is small enough and it's feasible for the QA team to run their own server (it can be on a quarantined subnet with its own internal firewalls), let them. The reason they want the access is to make sure the data they're working with is kept in a state they can use - I think every long-time tester is familiar with the test that takes 2 hours to configure and 5 minutes to test (and has set up a dedicated data set so that they don't have to do this more than once).
Another possibility is to boost your database logging and give the qa team members the access they want on their accounts. If your main concern is knowing who ran which script at what time, this would give you that information.
Testers do tend to fall foul of security processes fairly often - our major concerns with data are to keep it in a state that meets our needs, which includes a lot of backing up before doing a test with a chance of corrupting data, then restoring if we have to. (Not to mention automation that checks database tables against baselines and needs to be able to run nightly with a non-expiring password).
If you work with them, chances are you'll find a method that suits both of you well enough to be used. You can always tweak once you start if your initial attempt is problematic.