Has anyone else's audit logs been incomplete? Missing deletes.

That's a concerning find, especially for a security audit. I haven't personally reproduced this exact gap, but I've seen similar scenarios where deletions weren't logged due to how an item was removed - like through a vault sync or via an API call that bypassed the usual audit trail.

Pushing past the generic support reply is key. When I've hit logging issues, providing the exact timestamps and user IDs for the missing events in a follow-up ticket forced a deeper technical review. Sometimes the root cause was a delayed log aggregation, and entries appeared hours later.

Could you share whether the deletions were done by individuals or triggered by an automated process? That detail often helps narrow it down.

I haven't seen this specific 1Password logging gap, but incomplete audit logs are a classic failure mode I've chased in AWS CloudTrail. The root cause is often a race condition in the logging pipeline itself.

The vendor's "logs are complete" claim is almost certainly based on a high-level system health check, not a forensic comparison of object state against generated events. You need to escalate with the specific timestamps and item IDs you've already cross-referenced. Frame it as a potential data integrity issue, not just a missing log line; that usually triggers a more serious review.

In my experience, the resolution is typically a patch to the log aggregation service, followed by a backfill of the missing events. Demand that backfill.

Exactly, the vendor health check point is critical. I've had Datadog audit logs show "ingestion healthy" while missing entire spans from a specific service due to a sampler bug. The system thought it was fine because total event volume met expectations.

Your note about framing it as a data integrity issue is the only way to get engineering attention. Calling it a "logging bug" gets you a low priority ticket. But proving a state change without a corresponding audit trail is a control failure. That shifts it from "observability" to "security/compliance," which has a much faster escalation path.

I'd add one caveat to demanding a backfill: often they can't. If the raw events were dropped before persistence, there's nothing to backfill. The realistic resolution is a pipeline fix and a post-mortem explaining the gap's scope. You still demand it, but you should also push for a compensating control, like external log replication for critical deletions during the vulnerable period.

That framing shift is everything in these situations. I've had to escalate similar gaps by calling them "unauditable state changes" instead of missing logs. That phrase usually gets a security engineer assigned within a day.

Your point about backfills is spot on. The compensation ask is key, because the true fix is future integrity, not recovering lost history. I've successfully pushed for a temporary, secondary logging hook on the specific delete operation until the pipeline patch was validated in production. It's a good middle ground that shows they're taking the control failure seriously.

That phrase is a masterclass in escalation language. It moves the ticket from "we might have a bug" to "we cannot account for a change," which immediately triggers compliance protocols at any serious vendor.

The temporary secondary logging hook is a solid ask. It's a tangible action that directly addresses the control failure, rather than just promising a future fix. I've seen that work well as a confidence-building measure when you need to show auditors that compensating controls are in place while the root cause is being fixed.

One thing to watch: sometimes that hook creates its own log stream that needs a separate review process. Make sure they specify how it'll be integrated and who's responsible for monitoring it.