[klodolph]

That doesn’t sound especially unique or interesting, I would expect API access logs to expire after a time and without more knowledge of the specifics, two weeks seems reasonable to me. I would assume that the logs themselves contain PII so increasing the retention has a risk, too. Speaking of retention, given GDPR I would expect the logs to be expired after some known amount of time just for regulatory compliance reasons.

If you go too hard towards forcing disclosures you get pathological incentives to not retain the logs in the first place, the same way people at large companies these days will keep some discussions out of email so they can’t get subpoenaed. That’s not an excuse for bad behavior, but if you force companies to retain more logs for audit purposes, and you force companies to have PII retention policies that limit the retention period, you can easily force a company into a position where the cheapest way out is to reduce the detail in the logs to the point where they’re not useful for security audits any more (if this has the primary purpose of PII retention compliance).

[TangoTrotFox]

Logs with personal information anonymized are still just as useful for security and other system audits. You would be able to clearly see unauthorized access of A from B, even if A and B could no longer be identified.

And you're ignoring the biggest risk here. If this defense of claiming 'we see there was a trivially exploited issue to allow unauthorized access to data users had marked as private, but we threw away all logs so we can't be expected to see if it was exploited, or be held to any level of accountability' passes for acceptable, it's going to set a far worse precedent than any sort of legal action. Get hacked? Worried about regulatory requirements? No problem, just migrate to a two week cycle of completely deleting all logs, patch it, and stall for 2 weeks. There, you can now hoenstly say you have 'no evidence this attack ever happened.'