由于数据安全越来越受重视，如今的信息系统穿上了一层又一层的“防火衣”，从网络防火墙到ips，再到web应用防火墙，所以当听到数据安全审计时，不免就会有这样的疑问：“我已经有这么多的安全设备了，难道数据库审计不是多余的吗?”
答案是肯定的，不同的安全防护系统针对的关键风险不同，当数据的价值越来越高，数据库成为攻击目标时，防火墙、ips、waf这些系统是无法识别特定用户的具体数据库活动，更谈不上细粒度的审计。
而数据库安全审计系统可以对数据的访问操作行为做一个完整的记录，以备违反安全规则的事件发生后，能有效的追查责任和分析原因，必要时还可以为惩罚恶意攻击行为提供必要的证据。这就对数据库安全审计产品提出了一个相当基本的要求：完整的纪录。
当然还有另外一点，现如今的应用系统架构，n-tier的终端用户大多使用共享库联机或共同账号与数据库服务器沟通，无法辨识sql指令所对应到的真正终端使用者。要解决这个问题，大部分的数据库审计产品都必须修改客户的应用程序才能解决，但对企业来说，这不仅工程浩大且存在风险。
通常情况数据库安全审计产品都以软件交付，用户还需要自己选择硬件，如此以来，用户所面对的就是两个服务窗口。除此之外，为了发挥数据库安全审计系统的相当好的性能，还要针对不同的硬件做很多优化。这无论对用户还是厂商来说，都是不太方便的。
审计是记录历史动作，但有些情况下，光历史记录远远不够。对于应用系统，很多语句都是都是绑定参数运行的，直观审计到的就是一条条带问号的语句，不能看到实际动作，若要还原真实语句，需要联系上下语句分析，非常不便，这就要求审计有一定的语句还原拼接功能，把参数和内容放一起展示。更进一步，假如有人非常了解审计系统，知道审计记录不会一直存放，在某时刻建一个带有破坏性的存储过程，等超期不再保留建立过存储程记录后，执行并删除，真实运行动作将无法通过审计得知，对这类操作，就有了反向追踪运行内容语句的需求，尤其在金融行业中
另一方面，审计用户也应该是个特权用户，和超级用户互相制约。审计用户应该独立出来，有超级用户不能修改的帐号密码，专门用于审计相关操作，如开关审计，设置审计策略，查阅审计结果，超级用户不能干涉这些动作，保证审计记录的真实性和完整性。审计用户账号应该掌握在客户相当核心人手中，以对超级用户活动形成制衡，更加保证数据的安全。
再深入一层，有客户需求可能希望不同用户看到的内容不一样，对敏感数据根据不同用户进行自动过滤，严格来说这已经不再属于审计范围了，属于数据安全问题，需要有更严密的处理逻辑来实现。对于数据库产品来说，基于blp模型的强制访问控制（mac）是实现该需求的方法之一，该模型关键在于权限标签，对主客体进行标识，每个主体客体都有自己的标签，权限高的可访问修改低的对象，低权限的不能看到高权限的内容，对每个表、列甚至行都打上标签，对内容过滤可以做到列级直至行级。