Is there a downside to enabling auditing on the sys_user and sys_user_group tables?

[johnthomas]

I've seen this answered on a couple of other posts, but I just wanted to verify...

I was surprised to discover that, by default, the sys_user and sys_user_group do not have auditing enabled by default.   Is there any downside/risk to performance or functionality to enable auditing on these tables?

[BALAJI40]

Note: By default, the system does not audit records from system tables. To audit a system table, add it to the list of tables in the glide.ui.audit_deleted_tables property list.

check this one in , http://wiki.servicenow.com/index.php?title=Turning_on_Auditing_(History)_for_a_Table#gsc.tab=0

[Alikutty A]

It should not matter unless I think your user table is very very large in size.

Thank You

Please Hit Like, Helpful or Correct depending on the impact of response

[Subhajit1]

Hi John,

Turning on auditing on the User and Group set of tables (sys_user, sys_user_has_role, sys_user_grmember, sys_user_group etc) is very important from Administration perspective as it helps us investigate and identify causes when an unauthorized access occurs or a user suddenly loses access to features within Service-Now. I reckon without audit being turned on for this important part of the platform, it would be a nightmare to investigate these sort of issues.

I have worked on 5 instances and nowhere I found that auditing on the User and Group set of tables is turned off. The performance will not at all be an issue due to this.

Thanks,

Subhajit

[Gary22]

I have a question . how to verify the performance impact if you are auditing a new table . Suppose i have included a new table for auditing , how to verify that it is not causing any performance impact  on the instance .