FS security and compliance posture

@@ -7,23 +7,17 @@ audience: vendor-public
bcsc_class: current-fact
language: en
paired_with: service-fs-security-compliance.es.md
## See Also

- [[service-fs-architecture]]
- [[capability-based-security]]
- [[machine-based-auth]]
- [[sel4-foundation]]

---


`service-fs` is engineered to meet the highest international standards for immutable storage and data sovereignty. By implementing a structural {{gli|WORM}} (Write-Once-Read-Many) architecture, Foundry provides a verifiable assurance that data records are non-rewriteable and non-erasable, satisfying the core requirements of global financial and trust regulations.

`service-fs` is engineered to meet the highest international standards for immutable storage and data sovereignty. By implementing a structural WORM (Write-Once-Read-Many) architecture, Foundry provides a verifiable assurance that data records are non-rewriteable and non-erasable, satisfying the core requirements of global financial and trust regulations.

## 1. Regulatory Alignment

Foundry’s security posture is designed to satisfy multiple international regulatory frameworks:

*   **SEC Rule 17a-4(f):** Foundry targets the strict "{{gli|WORM}} path," structurally denying record modification. This exceeds the "Audit-Trail" alternative often used by cloud vendors to mask mutable underlying storage.
*   **SEC Rule 17a-4(f):** Foundry targets the strict "WORM path," structurally denying record modification. This exceeds the "Audit-Trail" alternative often used by cloud vendors to mask mutable underlying storage.
*   **eIDAS (EU 2025/1946):** Aligns with Qualified Preservation standards by ensuring long-term integrity, authenticity, and accessibility "irrespective of future technological changes."
*   **SOC 2 Trust Services Criteria:** Directly addresses Processing Integrity (PI1, PI4) through signed ingest and read-audit sub-ledgers, and Logical Access (CC6) via tenant-level isolation.

@@ -46,3 +40,10 @@ Foundry’s posture is intended to defend against high-level institutional risks
*   **Operator Tampering:** Even an administrator with root access cannot alter the ledger without breaking the Merkle chain and failing public Rekor consistency checks.
*   **Vendor Obsolescence:** Open-standard formats ensure data survival beyond the lifespan of the software vendor.
*   **Cryptographic Agility:** The system is designed to transition to post-quantum signature schemes (e.g., Dilithium) without requiring a full storage migration.

## See Also

- [[service-fs-architecture]]
- [[capability-based-security]]
- [[machine-based-auth]]
- [[sel4-foundation]]