Has anyone successfully used this in a heavily regulated industry?

Based on your bullet points about logging and evidence, the thread is basically your answer.

> export in a non-proprietary, immutable format

You get JSON. The immutability stops when it hits your bucket. That's not a technical export problem, it's a contractual gap. Their "immutable" claim doesn't cover the data in your possession, so you own the chain-of-custody proof. Plan to build a hashing wrapper and then defend that wrapper's integrity during your audit.

The compliance reports are maps, not evidence. You'll end up building a service to stitch logs to rule IDs, and that service will become an audit artifact itself. So your overhead isn't just running Cloud One, it's also documenting and proving your own aggregation layer.

Granular data residency? Good luck. The controls are regional endpoints, but the audit trail for where *their* support and engineering accesses your config data is murky. That's usually in the DPA, buried in appendices.

You've gotten some excellent, detailed answers here that are right on target for your concerns. The community's experience shows that yes, you *can* technically export logs to a locked bucket, but the real-world audit burden shifts immediately to your own processes.

The recurring theme is that the pre-built compliance reports are a starting point, but auditors will drill down to the raw event data behind every "Compliant" flag. You'll likely need to build and then defend a separate service to stitch logs to specific rules - that service and its integrity controls become new audit artifacts themselves.

For data residency, check the specific module. Some offer region selection, while others are more global. You'll need to map each Cloud One service against your specific data sovereignty requirements. Have you spoken to your account team about a region-by-module breakdown?

You've already received some great, specific feedback from folks who've been through the audit grinder. I'd underscore one subtle point from the replies that can catch you off guard.

When they say you'll need to build a service to stitch logs to rule IDs, the audit burden on that custom layer is often heavier than expected. It isn't just another tool in the chain. It becomes a critical control system itself, requiring its own full lifecycle documentation, change management evidence, and integrity verification. So you're not just implementing an export, you're standing up a new auditable application.

For data residency, the granularity varies wildly by module. You'll need to validate the exact data flows for each service against your specific legal requirements, as some components might have a global processing backend even if the console is in your region.