---
title: "ADR-019: Configurable audit read logging"
manual: "nr-vault"
version: "1.0"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-vault:adr-019-configurable-audit-read-logging@1.0"
source: "Developer/Adr/ADR-019-ConfigurableAuditReadLogging.rst"
rendered: "2026-09-18T07:37:50+00:00"
---

# ADR-019: Configurable audit read logging {#adr-019-configurable-audit-read-logging-1}

**Table of contents**

-   [Status](https://docs.typo3.org/permalink/netresearch/nr-vault:status@1.0)
-   [Date](https://docs.typo3.org/permalink/netresearch/nr-vault:date@1.0)
-   [Context](https://docs.typo3.org/permalink/netresearch/nr-vault:context@1.0)
-   [Decision](https://docs.typo3.org/permalink/netresearch/nr-vault:decision@1.0)
-   [Consequences](https://docs.typo3.org/permalink/netresearch/nr-vault:consequences@1.0)
-   [Related decisions](https://docs.typo3.org/permalink/netresearch/nr-vault:related-decisions@1.0)

## Status {#status}

Accepted

## Date {#date}

2026-03-28

## Context {#context}

Every call to `VaultService::retrieve()` wrote audit log entries,
resulting in three database operations per read (fetch secret, write audit
entry, update hash chain). In frontend rendering scenarios where multiple
vault references are resolved per page request, this caused significant
performance overhead.

For a typical page with 5 vault-backed content elements, this meant 15
additional database operations per page render solely for audit logging of
read operations. Write operations (create, update, delete, rotate) are
infrequent and their audit overhead is acceptable, but read operations
dominate in frontend contexts.

## Decision {#decision}

Add an `auditReads` configuration option that controls whether read
(retrieve) operations are written to the audit log:

-   **When enabled** (default for backend): Every `retrieve()` call is
    audit-logged, preserving full read traceability.
-   **When disabled**: Read operations skip the audit log write, eliminating
    2 of the 3 database operations per retrieve call.

Write operations (create, update, delete, rotate) are always audit-logged
regardless of this setting. The option is designed for use in
performance-sensitive contexts such as frontend rendering, where read audit
is less critical than in backend administrative contexts.

## Consequences {#consequences}

### Positive {#positive}

-   **~60% fewer DB operations** for frontend vault reference resolution
    (from 3 to 1 per retrieve call).
-   **Configurable per context**: Backend can retain full read auditing while
    frontend skips it.
-   **No impact on write auditing**: All mutating operations remain fully
    logged.

### Negative {#negative}

-   **Reduced read traceability**: When disabled, there is no audit record of
    which secrets were read in frontend contexts.
-   **Configuration complexity**: Operators must understand the security
    trade-off when disabling read auditing.

## Related decisions {#related-decisions}

-   [ADR-006: Audit logging](https://docs.typo3.org/permalink/netresearch/nr-vault:adr-006-audit-logging@1.0) \- Core audit logging model
-   [ADR-017: Audit metadata retention](https://docs.typo3.org/permalink/netresearch/nr-vault:adr-017-audit-metadata-retention@1.0) \- Audit metadata retention policy