How Navan Handles Audit Logging Across the Enterprise

Learn how Navan’s tech team overhauled its audit logging strategy to boost developer productivity, improve system performance, and meet strict compliance standards.

For any modern enterprise platform, audit logging — the systematic recording of user actions — is key to maintaining security, compliance, and operational visibility. But as infrastructure scales across microservices and global teams, audit logs can quickly become a bottleneck.

That’s exactly what we saw at Navan.

Fragmented Systems, Repeated Work

Navan’s early audit logging relied on siloed implementations, where each service built its own system for tracking user actions. That meant:

• Engineers spent weeks building and testing custom infrastructure.
• Performance suffered due to added database calls and PII handling.
• Reviewers relied on engineering support to generate reports.
• Costs and complexity kept rising, as systems duplicated efforts.

This model simply didn’t scale with our pace of growth.

A Centralized, Future-Proofed Audit Logging Platform

To fix this issue, we reimagined the system from the ground up and moved to a unified architecture that streamlines how audit trails are captured, stored, and reviewed across all services.

By integrating Apache Kafka, AWS S3, Snowflake, and ThoughtSpot, Navan now has a scalable, secure, and developer-friendly solution.

The centralized system made audit logging easier, faster, and more secure — helping Navan scale more effectively. Now, our engineering teams can focus on building new features instead of maintaining logging infrastructure.

How Navan Built a Future-Proofed Audit Logging Pipeline

To support scalability, security, and ease of integration, Navan designed a centralized audit logging architecture that streamlines how audit trails are collected, stored, and reviewed across all services.

The solution provides flexible ingestion points, robust data handling, and intuitive access for reviewers. The result? Comprehensive and compliant audit logging with minimal overhead.

Here’s a general overview of how this architecture works:

• Services log events via Kafka topics or direct HTTPS calls to the central audit service.
• Logs are stored in AWS S3 (for tamper-proof, scalable storage) and forwarded to Snowflake for analytics.
• PII is redacted on demand, before storage or downstream processing.
• Business users can explore and generate reports in ThoughtSpot — no SQL required.

Here’s a look at the orchestration code:

1@Service
2@RequiredArgsConstructor
3public class AuditService {
4   /* stores trail into s3 */
5   private final AuditRepository auditRepository;
6
7   /* produces trail to kafka topic for SnowFlake consumption */
8   private final SinkAuditService sinkAuditService;
9
10   /* redacts PII from the audit trail on demand */
11   private final PiiRedactorService piiRedactorService;
12
13   public Auditable create(Auditable auditable) {
14       /* Auditable::isRedactPii can be configured by clients */
15       if (nonNull(auditable) && auditable.isRedactPii()) {
16           piiRedactorService.redact(auditable);
17       }
18       sinkAuditService.publish(auditable);
19       return auditRepository.create(auditable);
20   }
21}

The PiiRedactorService uses factory patterns to support modular, category-based redaction logic:

1@Service
2@RequiredArgsConstructor
3public class PiiRedactorService {
4   private final List<PiiDetectionService> detectionServices;
5   private final Map<PiiCategory, PiiMaskingService> mappedMaskingServices;
6
7   public void redact(Auditable auditable) {
8       for (var field : auditable.values()) {
9           for (var detectionService : detectionServices) {
10               if (detectionService.containsPii(field)) {
11                   var piiCategory = detectionService.getCategory(field);
12                   var redacted = mappedMaskingServices.get(piiCategory).redact(field);
13                   /* save redacted value back into auditable */
14               }
15           }
16       }
17   }
18}

Major Design Decisions and Why They Matter

Navan’s centralized audit logging platform was designed to scale with our growth, minimize developer overhead, and meet evolving compliance needs — without compromising performance or security.

• AWS S3 provides immutable, tamper-proof storage using Object Lock (WORM), with virtually unlimited scalability and tiered storage classes for cost-effective long-term retention. Security is enforced with encryption, IAM policies, and VPC endpoints.
• Snowflake enables fast, scalable audit data processing by separating compute and storage, while ThoughtSpot gives non-technical teams the power to explore audit logs and generate reports without writing SQL.
• Apache Kafka guarantees that logs can be written independently of service availability; it also supports schema evolution through Schema Registry, allowing the system to adapt as audit requirements change.

Together, these technologies create a resilient, efficient foundation for secure and accessible audit logging across Navan’s platform.

The Future, Streamlined

Audit logging often sits behind the scenes, but it plays a critical role in scaling secure, reliable systems.

At Navan, investing in centralized audit logging has eliminated technical debt, improved performance, and strengthened our ability to serve customers with transparency and trust. As we continue to grow, this foundation helps ensure we can adapt to evolving regulations, move faster, and build with confidence.