Security

Security Audit Logging & Compliance: SOC2, GDPR & PCI-DSS for Java Developers in 2026

Audit logging is simultaneously a compliance requirement and a security control. Without it, you fail SOC2 Type II, violate GDPR Article 30, and breach PCI-DSS Requirement 10. With it, you can detect insider threats, trace data breaches to their source, demonstrate regulatory compliance, and answer "who did what, when, and from where" after any incident. This guide gives you a complete Java Spring Boot implementation of tamper-proof, compliance-ready audit logging with centralized SIEM integration.

Md Sanwar Hossain April 6, 2026 18 min read Compliance Logging

1. Compliance Requirements: SOC2, GDPR & PCI-DSS

2. What to Log: Security-Relevant Events

• Authentication events: Successful logins, failed logins (with source IP), MFA challenges, password changes, account lockouts, session creation and termination.
• Authorization events: Access denied events (RBAC/ABAC rejections), privilege escalation attempts, role changes, permission grants/revocations.
• Data access events: Read/write/delete of sensitive data (PII, financial data, health records), bulk data exports, data downloads above threshold size.
• Administrative events: User account creation/modification/deletion, configuration changes, API key creation/revocation, secret rotation.
• System events: Service startup/shutdown, deployment events, infrastructure changes, backup operations.
• Data subject rights (GDPR): Access requests, erasure requests (right to be forgotten) with outcome, portability requests, consent changes.

3. Audit Event Schema: Structured JSON for SIEM

A consistent, structured schema is essential for SIEM ingestion, alerting, and forensic investigation. Every audit event should answer: who, what, when, where, why, and with what result.

{
  "eventId": "550e8400-e29b-41d4-a716-446655440000",  // UUID v4, globally unique
  "eventType": "DATA_ACCESS",                          // Enum: AUTH, AUTHZ, DATA_ACCESS, ADMIN, SYSTEM
  "action": "READ",                                    // CREATE, READ, UPDATE, DELETE, EXPORT
  "outcome": "SUCCESS",                                // SUCCESS, FAILURE, ERROR
  "timestamp": "2026-04-06T09:15:30.123Z",            // ISO 8601 UTC, millisecond precision
  "actor": {
    "userId": "usr_a1b2c3d4",                         // Never log raw email — use internal ID
    "username": "j.doe",                              // For display, not PII like full email
    "roles": ["ROLE_ANALYST"],
    "sessionId": "sess_xyz123",
    "ipAddress": "203.0.113.42",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)..."
  },
  "resource": {
    "type": "Customer",
    "id": "cust_98765",
    "path": "/api/customers/98765"
  },
  "request": {
    "method": "GET",
    "correlationId": "req_abc123",                    // For distributed tracing correlation
    "serviceId": "customer-service"
  },
  "metadata": {
    "dataClassification": "PII",                      // PII, PHI, PCI, CONFIDENTIAL, PUBLIC
    "legalBasis": "LEGITIMATE_INTEREST"               // GDPR legal basis if PII involved
  },
  "integrity": {
    "previousHash": "sha256:d4e5f6...",              // For hash-chaining tamper detection
    "hash": "sha256:a1b2c3..."                       // Hash of this event including previousHash
  }
}

4. Spring Boot AOP Audit Logging Implementation

Custom @Auditable Annotation

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Auditable {
    String eventType();
    String action();
    String resourceType();
    String dataClassification() default "CONFIDENTIAL";
}

// Usage on service methods
@Auditable(eventType = "DATA_ACCESS", action = "READ",
           resourceType = "Customer", dataClassification = "PII")
public CustomerDto getCustomer(String customerId) {
    return customerRepository.findById(customerId)
        .map(customerMapper::toDto)
        .orElseThrow(() -> new ResourceNotFoundException("Customer not found: " + customerId));
}

AOP Aspect for Automatic Audit Event Capture

@Aspect
@Component
@RequiredArgsConstructor
public class AuditLoggingAspect {

    private final AuditEventPublisher auditPublisher;
    private final SecurityContextHolder securityContextHolder;

    @Around("@annotation(auditable)")
    public Object auditMethod(ProceedingJoinPoint joinPoint, Auditable auditable)
            throws Throwable {
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        HttpServletRequest request = ((ServletRequestAttributes)
            RequestContextHolder.getRequestAttributes()).getRequest();

        AuditEvent.Builder eventBuilder = AuditEvent.builder()
            .eventId(UUID.randomUUID().toString())
            .eventType(auditable.eventType())
            .action(auditable.action())
            .timestamp(Instant.now())
            .actor(AuditActor.fromAuthentication(auth, request))
            .resource(AuditResource.builder()
                .type(auditable.resourceType())
                .path(request.getRequestURI())
                .build())
            .dataClassification(auditable.dataClassification());

        try {
            Object result = joinPoint.proceed();
            eventBuilder.outcome("SUCCESS");
            auditPublisher.publishAsync(eventBuilder.build());
            return result;
        } catch (Exception ex) {
            eventBuilder.outcome("FAILURE")
                        .errorMessage(ex.getMessage());
            auditPublisher.publishAsync(eventBuilder.build());
            throw ex;
        }
    }
}

Async Publisher to Dedicated Audit Log Table

@Service
@RequiredArgsConstructor
public class AuditEventPublisher {

    private final AuditLogRepository auditLogRepository;
    private final ObjectMapper objectMapper;

    @Async("auditExecutor")  // Separate thread pool — never block request thread
    public void publishAsync(AuditEvent event) {
        try {
            String json = objectMapper.writeValueAsString(event);
            AuditLogEntry entry = AuditLogEntry.builder()
                .eventId(event.getEventId())
                .eventJson(json)
                .eventType(event.getEventType())
                .timestamp(event.getTimestamp())
                .outcome(event.getOutcome())
                .build();
            auditLogRepository.save(entry);
        } catch (Exception ex) {
            // CRITICAL: Never swallow audit log failures silently
            log.error("AUDIT LOG FAILURE: failed to persist audit event {}", event.getEventId(), ex);
            // Alert via PagerDuty/Slack — audit log failure is a compliance incident
            alertingService.sendCriticalAlert("Audit log persistence failed", ex);
        }
    }
}

5. Spring Data Envers: Database-Level Entity Audit

Spring Data Envers (Hibernate Envers integration) provides automatic, database-level change tracking for JPA entities. Every INSERT, UPDATE, DELETE creates a revision entry in an audit table, giving you a complete history of every entity's state changes.

// Enable auditing on entity
@Entity
@Audited
@EntityListeners(AuditingEntityListener.class)
public class CustomerEntity {
    @Id
    private String id;

    @NotAudited  // Exclude volatile computed fields
    private LocalDateTime lastLoginAt;

    private String email;
    private String status;

    @CreatedBy private String createdBy;
    @LastModifiedBy private String modifiedBy;
    @CreatedDate private Instant createdAt;
    @LastModifiedDate private Instant modifiedAt;
}

// Query audit history
@Repository
public interface CustomerRevisionRepository
    extends RevisionRepository<CustomerEntity, String, Long> {}

// Usage: get all revisions for a customer
List<Revision<Long, CustomerEntity>> revisions =
    customerRevisionRepository.findRevisions("cust_98765").getContent();

6. Tamper-Proof Audit Logs: Hash Chaining & Immutability

PCI-DSS Requirement 10.3.3 requires that audit logs be protected against modification. Hash chaining (similar to blockchain) ensures that any modification to historical audit entries is detectable.

@Service
public class TamperProofAuditService {

    public AuditLogEntry createEntry(AuditEvent event, String previousHash) {
        String eventJson = serialize(event);
        // Hash = SHA-256(previousHash + eventJson)
        String currentHash = sha256(previousHash + eventJson);

        return AuditLogEntry.builder()
            .eventJson(eventJson)
            .previousHash(previousHash)
            .hash(currentHash)
            .build();
    }

    public boolean verifyChainIntegrity(List<AuditLogEntry> entries) {
        for (int i = 1; i < entries.size(); i++) {
            AuditLogEntry entry = entries.get(i);
            String expectedHash = sha256(entries.get(i-1).getHash() + entry.getEventJson());
            if (!expectedHash.equals(entry.getHash())) {
                log.error("AUDIT CHAIN VIOLATION at entry {}: tamper detected!", entry.getEventId());
                return false;
            }
        }
        return true;
    }
}

// Database immutability: revoke UPDATE and DELETE on audit table
REVOKE UPDATE, DELETE ON TABLE audit_log FROM application_user;
GRANT INSERT, SELECT ON TABLE audit_log TO application_user;

7. Retention Policies & PII in Audit Logs

Audit logs create a tension between two requirements: security needs logs retained for as long as possible; privacy regulations (GDPR) require deletion of personal data when no longer necessary. Resolution:

• Log internal user IDs, not PII directly: Log userId: usr_123, not email: jane@example.com. The mapping from ID to PII is maintained separately and can be anonymized independently on GDPR erasure requests.
• Pseudonymization on erasure: When a GDPR erasure request is fulfilled, replace the actor's ID in audit logs with a pseudonymized token (DELETED_USER_a1b2c3). The audit log remains intact for integrity purposes, but the PII is removed.
• Tiered retention: Keep "hot" audit logs (recent 90 days) in fast storage for incident response; move to "warm" (S3/cold storage) for compliance retention; purge after maximum legal retention period.

8. SIEM Integration: OpenSearch, Splunk & AWS CloudTrail

Logback JSON appender for structured audit output

<!-- logback-spring.xml — separate appender for audit events -->
<appender name="AUDIT" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>/var/log/app/audit.log</file>
    <encoder class="net.logstash.logback.encoder.LogstashEncoder">
        <includeContext>false</includeContext>
        <fieldNames>
            <timestamp>@timestamp</timestamp>
            <message>message</message>
        </fieldNames>
    </encoder>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>/var/log/app/audit.%d{yyyy-MM-dd}.log.gz</fileNamePattern>
        <maxHistory>90</maxHistory> <!-- 90 days hot; ship older to S3 -->
    </rollingPolicy>
</appender>

<logger name="AUDIT_LOGGER" level="INFO" additivity="false">
    <appender-ref ref="AUDIT"/>
</logger>

OpenSearch Index Template for Audit Logs

PUT _index_template/audit-logs
{
  "index_patterns": ["audit-*"],
  "template": {
    "settings": {
      "number_of_shards": 1,
      "index.lifecycle.name": "audit-ilm-policy"
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "eventType":  { "type": "keyword" },
        "action":     { "type": "keyword" },
        "outcome":    { "type": "keyword" },
        "actor.userId": { "type": "keyword" },
        "actor.ipAddress": { "type": "ip" },
        "resource.type": { "type": "keyword" },
        "dataClassification": { "type": "keyword" }
      }
    }
  }
}

9. Security Alerting from Audit Events

• Failed login threshold: Alert on more than 5 failed authentication attempts from the same IP or for the same user within 5 minutes — potential brute force or credential stuffing.
• Privilege escalation: Alert immediately on any ROLE_ADMIN assignment or privilege change event, especially outside business hours.
• Unusual data volume: Alert when a single user accesses more records in one hour than their 30-day average — potential data exfiltration.
• Access from new geography: Alert on authentication from an IP that resolves to a country not in the user's historical access pattern.
• Service account anomalies: Alert when non-human service accounts perform human-like actions (interactive login attempts, unusual hours).
• Audit log gaps: Alert if audit log volume drops below expected baseline — could indicate log tampering, log shipper failure, or service outage.

10. Production Audit Logging Checklist

11. Conclusion

Security audit logging sits at the intersection of security, compliance, and forensics. Done correctly, it satisfies SOC2 Type II CC6 controls, GDPR Article 30 processing records, PCI-DSS Requirement 10 logging controls, and gives your incident response team the evidence trail they need to reconstruct any security event.

The implementation path is straightforward: create a structured AuditEvent schema, build an @Auditable AOP aspect to capture events automatically, persist to an INSERT-only table with hash chaining, ship to OpenSearch or Splunk via Filebeat, and configure alerting rules for the high-signal events that indicate active threats. The Java ecosystem (Spring Boot AOP, Spring Data Envers, Logstash Logback Encoder) makes this achievable in a single sprint.

Remember: audit log failure is itself a compliance incident. Monitor your audit log pipeline with the same rigor you apply to your application health checks — because an audit log that failed silently is worse than no audit log at all.

Md Sanwar Hossain

Software Engineer · Java · Spring Boot · Microservices · AI/LLM Systems

All Posts