Audit Logging and Compliance for B2B Custom Software

What enterprise buyers expect from audit trails

Security teams want immutable, time-ordered records of security-relevant actions: authentication, authorization changes, data exports, configuration edits, API key lifecycle, and admin impersonation. Compliance teams want retention aligned with policy, searchable evidence for investigations, and clarity on who can read logs. Operations wants business-meaningful events tied to workflows: approval granted, status transition, integration replay, manual override with reason code. Pure HTTP access logs rarely answer 'why did this order state change?' Procurement questionnaires repeat the same themes: log integrity, retention duration, access controls on logs, tenant isolation in multi-tenant setups, and export for customer SIEM. Answering 'we will add it later' delays deals.

• Who acted (user, service account, API key, support impersonation)
• What changed (before/after or structured diff)
• When (UTC timestamp, monotonic ordering per aggregate)
• Where (IP, user agent, session ID, tenant context)
• Why (reason code or ticket reference when humans override rules)

Audit logs vs application logs vs metrics

Application logs help engineers debug: stack traces, query timings, cache misses. Metrics aggregate health: error rate, latency. Audit logs prove accountability to customers and regulators. Mixing them in one stream without taxonomy makes SIEM ingestion expensive and investigations noisy. Audit events should be append-only from the application perspective: no in-place edits, no deletes without governed retention jobs documented in policy. Storage can be database table, immutable object store, or event bus consumer; the contract is tamper-evidence and retention, not the brand of tool. Separate hot search (last 90 days in app UI for tenant admins) from cold archive (years in cheaper storage) if contracts require long retention.

Designing an event taxonomy early

Define event types with stable names: user.role_assigned, order.status_changed, integration.replay_requested. Namespace by domain, version schema internally, and document required fields per type. Capture actor and subject explicitly. Actor is who performed the action; subject is the entity affected. Support actions on behalf of another user (delegation, support mode) with both actor and on_behalf_of when applicable. For configuration changes, store structured diffs redacting secrets. Never write passwords, API secrets, or full payment PAN into audit payloads. Store field names changed and masked previews. Align taxonomy with discovery workshops by asking compliance which workflows require evidentiary strength during audits.

• Catalog of event types with owner team and retention class
• Required metadata: tenant_id, actor_id, correlation_id
• Human-readable labels for admin UI plus machine codes for SIEM
• Mapping from domain events to compliance control frameworks where needed

Tenant isolation and admin visibility

In multi-tenant B2B SaaS, tenant admins must see only their audit trail. Platform operators may need cross-tenant views for abuse investigation with stronger access controls and their own audited actions. Support impersonation is high risk: log start and end of impersonation sessions, actions taken, and require ticket reference. Some customers forbid impersonation entirely; document your model in security appendix. Row-level security on audit tables mirroring application data isolation prevents the classic failure mode: correct app isolation but support SQL console leaks all tenants.

Audit expectations when integrating ERP and external systems

Integrations create dual records: your app changed state and ERP reflected it (or failed). Log outbound integration attempts with correlation IDs matching ERP integration patterns, payload hash or key fields, response status, and reconciliation outcome. When customers replay or reverse transactions, audit reason codes and link to original event ID. Month-end disputes often need a chain of evidence across systems; your log should point to ERP document numbers. If integration is asynchronous, log enqueue, success, failure, and manual intervention. 'Silent retry' without audit leaves operations blind.

GDPR, retention, and right-to-erasure tension

EU customers ask how audit logs interact with GDPR. Personal data in logs (names, emails, IP addresses) may need retention limits and erasure policies that conflict with fraud investigation needs. Legal should classify audit log baselines: which fields are necessary for legitimate interest or contractual obligation. Pseudonymize actor identifiers in long-term archive if law allows continued retention of events without direct identifiers. Document what happens on tenant offboarding: export window, deletion schedule, and legal holds. Do not promise 'delete everything about user X' without engineering review of audit and backup immutability. Contracts should spell out realistic behavior.

SOC 2, ISO 27001, and customer security audits

SOC 2 Type II expects logging and monitoring controls evidenced over time. Your audit design should support control narratives: access provisioning/deprovisioning logged, privileged actions reviewed periodically, alerts on suspicious export volume. Customer on-site or virtual audits sample tickets: show how you traced an incident using correlation IDs across app, audit, and integration logs. Practice this drill before sales promises it. Third-party penetration tests often find missing authorization logging on admin endpoints. Include authz failures in audit or security event stream, not only successes.

• Quarterly review of privileged role assignments with evidence
• Alerting on bulk export and API key creation
• Documented retention and access policy for audit storage
• Runbooks linking audit search to incident response steps

Implementation patterns that avoid painful retrofits

Emit audit events at application service layer when business invariants change, not only in controllers. ORM hooks alone miss 'approved via background job' paths. Use outbox or transactional emit so audit records persist with the business transaction. Losing audit when DB commit succeeds is a credibility killer. Expose tenant admin UI: filter by user, date, event type, export CSV for customer compliance officers. Pagination and rate limits apply; exports themselves should generate audit events. Plan implementation effort in MVP if you sell to regulated or enterprise segments; deferring entirely usually costs more than a focused two to three week slice during build.

• Service-layer emit on state transition, not only HTTP layer
• Transactional outbox so audit and business data commit together
• Separate retention classes: security events vs routine config edits
• Load-test audit write path before bulk import or migration weekends

SIEM forwarding and customer-owned observability

Enterprise customers increasingly ask to stream audit events into their Splunk, Datadog, or Microsoft Sentinel tenant. Treat this as a product requirement with volume estimates, schema documentation, and authentication model (OAuth client, HMAC webhook, or syslog relay). Batch exports nightly are easier to ship but fail real-time fraud detection expectations. Streaming adds operational burden: retry queues, dead letters, schema versioning, and customer-side parser breakage when you add fields. Offer a stable JSON schema with additive versioning. Document rate limits and maximum payload size. Provide a replay window for missed events during outages, bounded to contractual retention. When forwarding includes PII, data processing agreements and subprocessors list must mention the SIEM path. Security review will ask whether your stream can leak cross-tenant data; partition streams per tenant or cryptographically separate delivery channels when contracts require it.

For smaller customers, CSV export from admin UI plus documented API read endpoints may suffice for year one. Sales should not promise SIEM integration on day one unless engineering has load-tested the pipeline.

Audit trails operators and support teams actually use

Compliance officers read audit logs during investigations. Operators read them to answer 'what happened to shipment 4472?' Support reads them during impersonation disputes. Each audience needs different UI affordances. Operators benefit from business identifiers in audit entries: order number, lot code, customer reference, not only internal UUIDs. Map stable external references in the event payload so search works the way floor staff think. Support workflows should link audit entries to tickets and chat transcripts without duplicating sensitive content. A support agent should see that an override happened, who approved it, and the reason code, then jump to the business record. Train customer admins during onboarding on where audit lives and which roles can export. Undiscovered audit UI becomes shelfware and renewals suffer when security questionnaires ask for screenshots you never showed the buyer.

Audit checks before go-live

Add audit scenarios to go-live checklists: role change, manual override, data export, failed login burst, integration replay, impersonation session. Verify tenant isolation by attempting cross-tenant access in staging and confirming no leakage in UI or API. Validate retention jobs in staging, backup restore includes audit tables, and SIEM forwarder (if sold) handles volume spikes during bulk imports.

Next steps

List the ten actions your customer compliance officer will ask about first. Map each to an event type today or mark gap. Schedule taxonomy review with engineering and legal before next enterprise RFP. See other resources, enterprise delivery experience, book a call, or send a message with your tenant model, target compliance frameworks, and whether audit logging is a current gap or a launch requirement.

FAQ