1.2K S3 compliance is the set of enforceable controls that make S3 or S3-compatible object storage acceptable to a regulator: retention that cannot be quietly undone, encryption whose keys you actually hold, and logs that survive contact with an auditor. It is a different question from S3 compatibility, which only asks whether a platform speaks the API. The two get conflated constantly in procurement. A platform can implement every S3 verb correctly and still fail an examination, because the rules governing regulated records are not about API surface area. They are about what happens when someone with administrative credentials tries to delete something they should not be able to delete. What S3 compliance actually means Three things have to be true at once. The storage layer has to enforce controls rather than offer them as settings, which means enforcement sits below the layer an administrator can edit. The system has to generate evidence: not just that a policy existed, but that it held. And the controls have to map to a specific obligation you can name, because “we use immutable storage” is not an answer to “which rule, and for how long”. The useful test is whether a control survives a compromised administrator. Bucket policies do not: they are IAM objects, and anyone who can edit IAM can edit them. Lifecycle expiration illustrates it well. AWS documents that a bucket policy cannot prevent deletions by a lifecycle rule, and that even a policy denying all actions to all principals leaves lifecycle functioning normally. Object Lock does stop it, because it is enforced beneath the policy layer. That gap is why regulators care about the difference. The rules that drive S3 compliance requirements In US financial services, the anchor is SEC Rule 17a-4. The 2022 amendments (adopted 12 October 2022, effective 3 January 2023, broker-dealer compliance from 3 May 2023) changed the shape of the requirement in a way most vendor material still gets wrong. Rule 17a-4(f)(2)(i) now offers two alternatives joined by “or”: preserve records in a non-rewriteable, non-erasable format, the traditional WORM path, or preserve them with a complete time-stamped audit trail capturing every modification and deletion, the time, the actor, and enough to re-create the original. WORM is no longer the only route. FINRA Rule 4511(c) picks the amended standard up automatically, since it cross-references 17a-4 dynamically. CFTC Rule 1.31 runs on a different model, and the difference bites when you plan storage tiers. The SEC pattern keeps records six years with the first two “easily accessible”. The CFTC requires electronic regulatory records to be readily accessible for the entire period, generally five years; the two-year window applies only to paper. Tiering an electronic CFTC record to slow archive in year three is a compliance problem, not a cost optimization. In healthcare, HIPAA is widely misquoted. There is no federal HIPAA medical-record retention period (state law governs that). The six-year rule at 45 CFR 164.316(b)(2)(i) applies to documentation: policies, procedures, and the written records of assessments the Security Rule requires. Encryption also needs stating precisely, because as of mid-2026 it remains addressable rather than required. Addressable is not optional (you must assess it, document any decision not to implement, and put an equivalent measure in place), but it is not a mandate. A January 2025 proposed rule would make encryption and MFA mandatory; it is not final and has slipped to a projected 2027 final action. In the EU, DORA has applied to financial entities since 17 January 2025, and its Article 12 governs backup and restoration. One frequently over-read detail: Article 12(3) requires that systems used to restore data be physically and logically segregated from the source system. It does not impose segregation on the backup copies themselves. The stronger binding text for separated, immutable copies sits in the NIS2 implementing regulation for digital infrastructure and cloud providers, which requires backup copies stored in locations that are not on the same network as the system and are far enough away to escape a disaster at the main site. Retention: how S3 Object Lock enforces it S3 Object Lock is the API-level mechanism, and it has two modes plus an independent legal hold. In Compliance mode, no user can overwrite, delete, or shorten the retention of a protected object version, including the account root. In Governance mode, an override is possible, but it takes two things together: the s3:BypassGovernanceRetention permission and an explicit request header. Retention can be extended in either mode; it can only be shortened in Governance mode, and never in Compliance mode. Maximum retention is 100 years. A widespread claim is that only Compliance mode satisfies SEC 17a-4. The assessment normally cited for that conclusion says the opposite: Object Lock meets the non-rewriteable, non-erasable requirement in either mode, with Governance passing on a compensating-controls basis requiring procedural control and monitoring over administrators holding the bypass permission. Governance mode is defensible, but only if you can show the surrounding controls, which is a governance burden rather than a technical one. Three operational details cause real audit findings. Object Lock requires versioning, and once enabled it cannot be turned off or versioning suspended. Legal holds carry no expiry, persist until explicitly removed regardless of retention, and are not defeated by the governance bypass. And the one that surprises people: a delete request without a version ID succeeds and inserts a delete marker, because delete markers are not themselves protected. The data is intact, but the object appears gone. Anyone testing immutability with a simple delete and seeing a 200 response draws exactly the wrong conclusion. Encryption, keys, and what “FIPS certified” really means Encryption at rest has been a default rather than a decision for a while, so the differentiating question in any encryption strategy for regulated data is key custody. Server-side encryption with platform-managed keys protects against media theft; it does not make data opaque to the operator. Customer-managed keys, ideally backed by an external HSM, are what let you claim the provider cannot read the records, and they enable crypto-shredding at decommissioning. Be careful with crypto-shredding as a compliance argument, particularly against the GDPR right to erasure. The European Data Protection Board’s position is that encrypted personal data is still personal data, that the erasure bar is effective anonymisation rather than inaccessibility, and that encryption strength degrades over the multi-decade horizons WORM retention implies. Key destruction is strong risk reduction, not a settled substitute for deletion. On FIPS 140 validation, the precision matters because procurement language often gets it wrong. Cryptographic modules are validated, not platforms or products. A product either is a validated module or merely contains one, and the certification program uses different approved phrasing for each case. The transition deadline is also close: all FIPS 140-2 certificates move to the historical list on 21 September 2026, after which they can support existing systems but not new procurements. Audit evidence: logs that hold up This is where otherwise well-architected deployments fail, and the reason is a single sentence in the AWS documentation. S3 server access logging is explicitly disclaimed: delivery is not guaranteed, records may arrive hours late or not at all, and there is no way to know whether all records for an interval were delivered. It is described as not meant to be a complete accounting of requests. That is fatal for a chain of custody. API-level audit logging (CloudTrail in AWS, its equivalents elsewhere) carries no such disclaimer and adds the properties that make evidence defensible: cryptographic log file integrity validation, encryption, cross-account delivery so the audited account cannot alter its own records, and fields capturing Object Lock parameters. Default retention is short, typically 90 days, so long-horizon obligations need an immutable event store or export to a SIEM or locked bucket. Either way, the audit trail needs the same retention treatment as the records it describes, which teams routinely forget to budget for. Residency, and where retention collides with erasure The most common false premise in sovereignty conversations is that the GDPR requires personal data to stay in the EU. It does not. Chapter V governs international transfers through adequacy decisions, standard contractual clauses, and binding corporate rules, and transfers to an adequate jurisdiction are treated much like intra-EU ones. EU law actually prohibits most localisation requirements for non-personal data. Where residency obligations genuinely exist, they come from sector rules, national law, procurement policy, or contract. DORA, for instance, requires contracts to disclose where data is stored and to give notice of changes, which is a transparency duty rather than a localisation one. The distinction is worth getting right, because arguing for sovereign infrastructure on a legal basis that does not exist collapses under scrutiny. The sharper tension is between immutable retention and the right to erasure. Article 17(3) resolves it narrowly: erasure does not apply “to the extent that” processing is necessary for compliance with a legal obligation, or for the establishment, exercise, or defence of legal claims. Two consequences follow. A statutory obligation defeats an erasure request only for the data and period it actually covers, so a blanket immutable bucket is not a blanket exemption. And storage limitation runs the other way: once the obligation lapses, keeping the immutable copy becomes its own violation. Retention that never expires is not the safe option it looks like. Checklist: evaluating S3 compliance capabilities Object Lock in both Compliance and Governance modes, with legal holds independent of retention, and bucket-level defaults enforced centrally. A documented answer to delete-marker behaviour, so “deleted” in the console maps to something you can explain to an examiner. Customer-managed keys with external HSM or KMS integration, and a custody model that survives the question “can the operator read this”. Cryptographic modules with current validation, verified by certificate number rather than a marketing claim, plus a plan for the September 2026 FIPS 140-2 transition. API-level audit logging with integrity validation and write-once or cross-account delivery, retained as long as the records it evidences. Separation of duties letting storage administrators manage capacity without reading record contents, and monitoring over anyone holding governance bypass. Retention that expires when the obligation ends, and an erasure workflow that can act on out-of-scope data while leaving locked records intact. Evidence export in a usable electronic format, including audit trails, on the timeline your regulator specifies. Putting it together The organisations that pass examinations comfortably tend to have done one unglamorous thing: mapped each control to a named obligation with a stated duration, rather than buying a capability set and assuming coverage. Immutability without a retention schedule tied to a rule is just expensive storage. An audit trail nobody has tried to export is an assumption, not evidence. The technical building blocks for S3 compliance are mature and broadly available across platforms as of 2026, so the failure mode is almost never a missing feature. It is a control configured once, never tested against a hostile scenario, and never mapped to the rule it was supposed to satisfy. Frequently asked questions Is S3 compliance the same as S3 compatibility? No. S3 compatibility describes how faithfully a platform implements the API, including whether it supports operations like Object Lock and versioning at all. S3 compliance describes whether it enforces the retention, access, encryption, and evidence controls a specific regulation demands. A platform can score well on the first and fail the second, most often on audit evidence and key custody. Does SEC 17a-4 require Compliance mode Object Lock? Not necessarily. The independent assessment usually cited here concludes that Object Lock satisfies the non-rewriteable, non-erasable requirement in either mode, with Governance depending on compensating procedural controls over administrators holding the bypass permission. Separately, the 2022 amendments added an audit-trail alternative to the WORM path, so WORM is one route rather than the only one. Does the GDPR require data to stay in the EU? No. It regulates international transfers rather than prohibiting them, permitting transfers to jurisdictions covered by an adequacy decision or protected by safeguards such as standard contractual clauses. Genuine residency requirements come from sector rules, national law, procurement policy, or contract. EU law separately prohibits most localisation requirements on non-personal data. How do immutable retention and the right to erasure coexist? Through a narrow exemption rather than a general one. Erasure does not apply to the extent processing is necessary for a legal obligation or for legal claims, so you must be able to name the obligation and show its scope. Data outside that scope still has to be erasable, and once the obligation ends, storage limitation requires disposal. Retention needs a defined end as well as a start. Are S3 server access logs sufficient as an audit trail? No, and this is documented rather than a matter of opinion. AWS states that server access log delivery is not guaranteed, that records may be significantly delayed or never delivered, and that there is no way to confirm whether all records for an interval arrived. Use API-level audit logging with integrity validation for anything that must function as evidence. Further reading For the rule-by-rule detail behind this overview, see SEC 17a-4 compliance, the CJIS compliant storage checklist, SOX compliance, and what genuinely immutable storage looks like.
