For years, Db2’s Audit Facility has been the go-to for tracking auditable events at both the instance and database level. Db2 Warehouse on Cloud extended this capability by providing an automated method to perform database auditing and storing audit records in tables—a familiar approach for many administrators — for analysis or archiving.

But as workloads shift to the cloud, traditional methods start to feel like square pegs in round holes. Cloud-native environments need cloud-native solutions. That’s where audit-to-COS (Cloud Object Storage) comes in.

Why Make the Switch?

Moving audit logs to COS isn’t just a technical tweak—it’s a strategic upgrade. Here’s why:

• Performance and Scalability
  Free up your database from bulky audit tables and local audit files. COS handles storage so your database stays lean and responsive.
• Security and Control
  Logs are encrypted and stored outside the database. You control retention, access policies, and lifecycle management.
• Integration and Flexibility
  COS makes it easy to feed logs into analytics platforms or SIEM tools for compliance and monitoring.
• Cost Efficiency
  Object storage is far more cost-effective for long-term retention than database storage. Consider compliance standards like HIPAA where records must be maintained for six years.

Getting Started: A Practical Guide

Before enabling audit-to-COS, there are a few steps to ensure a smooth transition:

1.    Migrate Audit Data

• • Decide to physical move audit data from tables to COS or keep audit tables until compliance requirement has been met.
  • Keep your old audit tables for compliance—don’t delete them yet!
  • Depending on your needs, you might export the data and consolidate archives in COS.

a.     Log in to your IBM Cloud account and go to your Db2 Warehouse on Cloud instance.

b.    Click “Open Console” to launch the Db2 Console (also called the Web Console or Console UI).

c.     In the left-hand navigation pane, select “Object Explorer” → “Schemas” → “Tables”.

d.    Browse to the schema AUDIT and select the audit category table e.g. EXECUTE, VALIDATE, SECMAINT, etc.

e.     Click the checkbox next to the table name.

f.      Choose “Export” in the menu banner.

g.    Walk through the Export “<table_name>” table dialog export locally or directly to Object storage.

2.     Migrate Audit Policies

• • The audit configuration flow makes this easy by allowing you to decide to keep or discard your current policy configuration, but take a snapshot for redundancy:
    • Execute select * from SYSCAT.AUDITPOLICIES” & “select * from SYSCAT.AUDITUSE

3.      Migrating from Auditing-to-tables to Auditing-to-COS

• • Collect S3 HMAC credentials using this guide.
  • Go to the Storage Alias tab and create a new alias.

• • This option appears at the start of the audit configuration flow also. If it already created, select the Object storage alias.

• • Click Next and review the Summary

4. Complete Audit Setup

Once policies are configured and active, audit events start flowing to COS automatically.

5. Manage audit policies

In order to manage audit policies through the Console UI, the audit configuration must be complete.

Want to create new policies or adjust policies? Use the Audit → Policies page.

Note: You can’t set an “AUDIT_ALL” policy that audits every possible event on the database-level here—this is intentional prevent local disk space from filling up causing costs to increase and potentially disrupting service.

1. 1. Log in to your IBM Cloud account and open your Db2 Warehouse on Cloud instance.
   2. Click "Open Console" to launch the Db2 Console UI.
   3. In the left-hand navigation menu, go to Administration → Audit.
   4. In some UI versions, it appears simply as “Audit” in the top navigation bar.
   5. You’ll see several tabs within the Audit page:
      1. Audit files
      2. Policies
   6. Make sure you’re on the “Policies” sub-tab.
   7. Click “Create audit policy”.
   8. Select “Custom” such as auditing CRUD events on a specific table.
      1. Name: Give your policy a descriptive name (e.g., MONITOR_CRUD_ON_ACCTS).
      2.  Error Type: Recommended – “Audit” to ensure if there are any errors with the audit facility, Db2 will treat it as a SQL error.
      3.  Categories: Choose the category that will monitor executions, EXECUTE. Brief description on available audit categories:
         1. AUDIT– audit settings modified or accessed.
         2. EXECUTE – log SQL executions.
         3.  CHECKING – authorization checking of attempts to access or manipulate Db2 database objects or functions.
         4. OBJMAINT – creating or dropping data objects, and when altering certain objects.
         5. CONTEXT – to show the operation context when a database operation is performed.
         6. SECMAINT – various security-related events such as privilege manipulation, altering authorization, etc.
         7.  SYSADMIN – operations requiring SYSADM, SYSMAINT, or SYSCTRL authority are performed.
         8. VALIDATE – authenticating users or retrieving system security information.
      4. Enable Policy: Toggle “Enable policies” and click on “Select database entities”. In this example, select a table under a schema.
      5. Select the database entities to apply the policy.
      6. Click “Next”.
      7. Review Summary, the click Save.
      8. Once saved, you’ll see the new policy listed in the Policies tab. You can enable or disable it at any time via the toggle switch.

6. Understand Buffer Behavior

• • When the audit buffer fills, it flushes to COS.
  • It also flushes every 10–20 minutes, even if not full.

7. Access and Monitor Logs

• • Logs appear in your COS bucket and in the Audit tab preview.

8. Review audit records in audit logs

See “Extracting Db2 Audit Data for Compliance and Security Review: A Practical Guide” blog to review the audit records.

Lessons Learned from Real-World Migrations

• Plan for Compliance Early

If you need to retain historical audit data, decide upfront whether to keep it in tables or export it to COS. Mixing strategies later can get messy.

• Test Your Storage Alias

Misconfigured HMAC credentials are the #1 issue we’ve seen. Validate them before enabling COS.

• Monitor Early and Often

After migration, check the COS bucket and Audit tab regularly to confirm logs are flowing as expected

• Apply COS retention policies

Audit data is dictated by audit policy definition. Depending on how aggressive the policy is, audit data can add up pretty quickly causing costs to increase by GBs. Defining retention, deletion, cold storage policies would help balance meeting compliance standards with cost.

Final Thoughts

Auditing to COS isn’t just about storage—it’s about aligning with cloud best practices. You’ll gain scalability, security, and cost savings while simplifying compliance workflows.

About the Author

Brigitte DeLoren (@Brigitte DeLoren) is a 13-year software engineering who thrives at the intersection of cloud technology, code craftsmanship, and team leadership. Known for elevating engineering quality and demystifying complex systems, she has built expertise in Db2 auditing while also shaping teams through clear technical direction and documentation. This marks her debut into technical blogging, where she brings her hands-on experience to a broader audience.