Security strategy - Database logging
The customer is nearing completion of the build phase of the project, and the security strategy is clearly defined. A great deal of knowledge transfer has occurred between partner and customer, and progress is on schedule. The customer has been testing role-based security, identifying sensitive data, and planning for future audits.
Pattern - Implement database logging judiciously
Though database logging can be valuable from a business perspective, it can be expensive regarding resource use and management. Therefore, you should use it judiciously.
Limit your use of database logging to specific data elements where you explicitly need an auditable record of changes to specific tables that contain sensitive information, such as parameter and base setup tables.
Be aware of the potential performance implications of extensive database logging, and test logged areas extensively.
Create a plan for how long to retain logged data and how to archive or delete data.
Limit log entries and help improve performance by selecting specific fields to log instead of whole tables. Limit logged tables to parameter and base setup tables and avoid logging on transactional tables.
Anti-patterns when database logging
Avoid the following anti-patterns when you're implementing database logging:
Assuming that everything is logged everywhere forever
Implementing database logging without a plan for review and archival and without having a plan for performance impact assessment