From 69ce585650785843684a7dc9c1b992c45e07a1a6 Mon Sep 17 00:00:00 2001 From: filipagr Date: Wed, 5 Aug 2026 14:55:24 -0300 Subject: [PATCH 1/3] docs: add a Compliance & Certifications page (FIL-895) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The website's Compliance LP tells procurement reviewers to "check docs.fil.one for current status" and no such page existed — a reader following that instruction landed on a docs site covering only encryption, authentication, and API keys. New security/compliance.mdx states the status plainly, using the same wording as the website's ComplianceLandingPage.tsx so the two surfaces cannot drift: no SOC 2 Type II, no ISO 27001, no third-party attestation of any kind, both actively pursued. Adds the shared-responsibility split (which determines what any future certification could actually cover), what a procurement team can request today, and an explicit list of what Fil One does not claim. Kept independent of the Data Deletion page (FIL-894) so the two can be reviewed and merged in either order — deletion/account-closure semantics are referenced via the FAQ and Trial & Billing pages, which exist on main today. Worth retargeting those links at Data Deletion once both have landed. --- docs/security/compliance.mdx | 51 ++++++++++++++++++++++++++++++++++++ sidebars.js | 1 + static/llms-full.txt | 49 ++++++++++++++++++++++++++++++++++ static/llms.txt | 7 +++++ 4 files changed, 108 insertions(+) create mode 100644 docs/security/compliance.mdx diff --git a/docs/security/compliance.mdx b/docs/security/compliance.mdx new file mode 100644 index 0000000..6c61eec --- /dev/null +++ b/docs/security/compliance.mdx @@ -0,0 +1,51 @@ +--- +title: Compliance & Certifications +description: Current certification status, the shared-responsibility split, and what a procurement team can request today. +--- + +This page states Fil One's certification status plainly, so a procurement or security reviewer does not have to infer it from feature documentation. + +## Certification status + +**Fil One does not hold SOC 2 Type II or ISO 27001 certification today.** Both are actively being pursued. This page is the current-status reference — if you were sent here from elsewhere on the site, this is the answer. + +We hold **no third-party compliance attestation** for any Fil One feature. That includes SEC 17a-4 assessments of the Object Lock / WORM capability, which is the attestation most often asked about for retention workloads. + +If a certification is a hard requirement for your evaluation, contact [security@fil.one](mailto:security@fil.one) so we can tell you where the work currently stands rather than leaving you to guess from this page's revision date. + +## Shared responsibility + +Fil One is not the sole party in the storage path, and this determines what any future certification could actually cover. + +| Layer | Operated by | Responsible for | +|-------|-------------|-----------------| +| Console, API, identity, billing | **Fil One** | Authentication, access-key issuance and scoping, MFA, the dashboard, request authorization, subscription state | +| Regional S3 storage gateway | **Regional storage operator** | Accepting and serving object data, server-side encryption at rest, **custody of encryption keys** | +| Underlying storage network | **Filecoin storage providers** | Physically holding data and producing the network's proof-of-storage | + +Two consequences worth stating explicitly to a reviewer: + +- **Encryption key custody sits with the regional storage operator**, not with Fil One and not with you. There is no customer-managed-key option and no SSE-C. See [Encryption](/security/encryption). +- **The specific cipher and SSE mode are set by the regional operator** and are not currently published. If your requirements depend on the exact scheme, contact support — see [Encryption](/security/encryption). + +## What is available to a procurement team today + +- **Security contact:** [security@fil.one](mailto:security@fil.one) +- **Controls you can verify yourself in the product:** passkey / Google / GitHub / email-password authentication with opt-in MFA (TOTP, WebAuthn security keys, device biometrics — SMS is intentionally not offered); region-scoped, permission-scoped, optionally bucket-scoped and expiring access keys; always-on encryption in transit (TLS, HTTP rejected) and at rest; WORM retention via Object Lock in Governance and Compliance modes. +- **Documented behaviour relevant to retention and privacy reviews:** [Object Lock](/storage/object-lock) for WORM retention and its compliance caveats, [API Keys](/security/api-keys) for the access-control model, and the [FAQ](/faq) and [Trial & Billing](/billing/trial) for deletion and account-closure semantics. +- **What to request from whom:** questions about Fil One's own controls (auth, access keys, the console) go to [security@fil.one](mailto:security@fil.one). Questions about the storage gateway's encryption implementation or key custody are answered by the regional operator; contact support and we will route them. + +## What Fil One explicitly does not claim + +Stated here so it does not have to be inferred: + +- **No third-party attestation or certification** of any kind, for any feature, today. +- **No auditor-presentable per-object proof.** The product surfaces no CID, deal ID, or seal state for an object, so there is nothing to hand an auditor as evidence that a specific object was stored intact or destroyed. Filecoin's network-level proof cycle is real, but it is a property of the network and is not exposed per object — see [How does Filecoin protect the integrity of stored data?](/faq). +- **No determination that any feature satisfies a specific regulation.** Object Lock provides WORM-style retention, which many regimes call for as a building block; whether it meets a named obligation is for your own compliance review to decide. The regulations named anywhere in these docs are illustrative use cases, not certification claims. +- **No published cipher or key-management scheme** for encryption at rest (see above). + +## Related + +- [Encryption](/security/encryption) — at-rest and in-transit encryption, key custody +- [Object Lock](/storage/object-lock) — WORM retention and its compliance caveats +- [API Keys](/security/api-keys) — permissions, region scoping, expiration diff --git a/sidebars.js b/sidebars.js index e47cf3b..2884dbe 100644 --- a/sidebars.js +++ b/sidebars.js @@ -31,6 +31,7 @@ const sidebars = { "security/authentication", "security/api-keys", "security/encryption", + "security/compliance", ], }, { diff --git a/static/llms-full.txt b/static/llms-full.txt index db86a1b..0e834d0 100644 --- a/static/llms-full.txt +++ b/static/llms-full.txt @@ -1236,6 +1236,55 @@ Client-side encryption is in addition to the server-side encryption that Fil One applies automatically. +--- + +# Compliance & Certifications + +Source: https://docs.fil.one/security/compliance + +## Certification status + +Fil One does NOT hold SOC 2 Type II or ISO 27001 certification today. Both are +actively being pursued. Fil One holds NO third-party compliance attestation for +any feature — including SEC 17a-4 assessments of the Object Lock / WORM +capability. Contact security@fil.one if a certification is a hard requirement. + +## Shared responsibility + +| Layer | Operated by | Responsible for | +|-------|-------------|-----------------| +| Console, API, identity, billing | Fil One | Authentication, access-key issuance and scoping, MFA, dashboard, request authorization, subscription state | +| Regional S3 storage gateway | Regional storage operator | Accepting/serving object data, server-side encryption at rest, CUSTODY OF ENCRYPTION KEYS | +| Underlying storage network | Filecoin storage providers | Physically holding data, producing the network's proof-of-storage | + +Consequences: encryption key custody sits with the regional storage operator, +not Fil One and not the customer (no customer-managed keys, no SSE-C); and the +specific cipher / SSE mode is set by the regional operator and is not published. + +## Available to a procurement team today + +Security contact: security@fil.one. Customer-verifiable controls: passkey / +Google / GitHub / email-password auth with opt-in MFA (TOTP, WebAuthn security +keys, device biometrics — SMS intentionally not offered); region-scoped, +permission-scoped, optionally bucket-scoped and expiring access keys; always-on +encryption in transit (TLS, HTTP rejected) and at rest; WORM retention via +Object Lock in Governance and Compliance modes. Questions about Fil One's own +controls go to security@fil.one; questions about the gateway's encryption +implementation or key custody are answered by the regional operator via support. + +## What Fil One explicitly does not claim + +- No third-party attestation or certification of any kind, for any feature. +- No auditor-presentable per-object proof — no CID, deal ID, or seal state is + surfaced, so there is nothing to hand an auditor as evidence a specific object + was stored intact or destroyed. Filecoin's network-level proof cycle is real + but is a property of the network and is not exposed per object. +- No determination that any feature satisfies a specific regulation. Regulations + named anywhere in these docs are illustrative use cases, not certification + claims. +- No published cipher or key-management scheme for encryption at rest. + + --- # Pricing diff --git a/static/llms.txt b/static/llms.txt index 0f9b837..eb1f479 100644 --- a/static/llms.txt +++ b/static/llms.txt @@ -103,6 +103,13 @@ Critical integration notes for developers: the regional operator (no customer-managed keys, cipher unconfirmed). Client-side encryption is up to you — AWS's S3 Encryption Client exists only for Java/.NET/Go/Ruby, NOT boto3/CLI/JS v3 +- [Compliance & Certifications](https://docs.fil.one/security/compliance): Fil + One holds NO SOC 2 Type II, NO ISO 27001, and NO third-party attestation of + any kind today (both actively pursued). Shared-responsibility split: Fil One + owns console/API/identity; the regional storage operator owns the gateway and + encryption key custody; Filecoin providers hold the data. Security contact + security@fil.one. No auditor-presentable per-object proof, no published + cipher, no claim any feature satisfies a named regulation ## Billing From 300dadef17b6bc9c6e68bfaf4b3b16024d082749 Mon Sep 17 00:00:00 2001 From: filipagr Date: Wed, 5 Aug 2026 15:13:58 -0300 Subject: [PATCH 2/3] docs: reframe the Compliance page around posture, drop em dashes Same treatment as the Data Deletion page. The old version led with what Fil One lacks and stated the no-attestation fact twice, then closed on a four-item "what Fil One explicitly does not claim" list. Every fact was accurate but the page read as a disclosure notice rather than a compliance posture. Restructured: - Certification status now leads with the work in progress (SOC 2 Type II and ISO 27001 actively pursued), then states plainly that neither is held and there is no third-party attestation. Stated once, not twice. Dropped the self-deprecating "rather than leaving you to guess from this page's revision date". - New "Controls in place today" table, promoted near the top: authentication, multi-factor, access-key scoping, encryption, WORM retention. This is the substance a procurement reviewer is looking for and it was previously buried in a single dense bullet halfway down. - Shared responsibility kept (it is what determines what any future certification covers), with the key-custody and cipher consequences folded into one prose paragraph instead of two negative bullets. - "Who to ask" split out so the routing is findable. - The four "does not claim" bullets consolidated to two scope statements: proof-of-storage is a network property, and named regulations are use cases rather than certifications. No fact dropped. Also removed every em dash from the page and its mirror sections per the house style, using commas, colons and parentheses instead. --- docs/security/compliance.mdx | 58 +++++++++++++++------------- static/llms-full.txt | 74 +++++++++++++++++++----------------- static/llms.txt | 19 +++++---- 3 files changed, 83 insertions(+), 68 deletions(-) diff --git a/docs/security/compliance.mdx b/docs/security/compliance.mdx index 6c61eec..e4c6108 100644 --- a/docs/security/compliance.mdx +++ b/docs/security/compliance.mdx @@ -1,51 +1,57 @@ --- title: Compliance & Certifications -description: Current certification status, the shared-responsibility split, and what a procurement team can request today. +description: Certification status, the shared-responsibility model, and what a procurement team can request today. --- -This page states Fil One's certification status plainly, so a procurement or security reviewer does not have to infer it from feature documentation. +This page is the current reference for Fil One's compliance posture: where certification stands, which controls are live in the product today, and how responsibility divides between Fil One and the storage operators behind it. ## Certification status -**Fil One does not hold SOC 2 Type II or ISO 27001 certification today.** Both are actively being pursued. This page is the current-status reference — if you were sent here from elsewhere on the site, this is the answer. +**SOC 2 Type II and ISO 27001 are actively being pursued.** Fil One does not hold either certification today, and holds no third-party compliance attestation for any feature, including the SEC 17a-4 assessments often asked about for WORM retention workloads. -We hold **no third-party compliance attestation** for any Fil One feature. That includes SEC 17a-4 assessments of the Object Lock / WORM capability, which is the attestation most often asked about for retention workloads. +For where that work currently stands, contact [security@fil.one](mailto:security@fil.one). -If a certification is a hard requirement for your evaluation, contact [security@fil.one](mailto:security@fil.one) so we can tell you where the work currently stands rather than leaving you to guess from this page's revision date. +## Controls in place today + +These are live in the product and open to your own review: + +| Area | What is in place | +|------|------------------| +| **Authentication** | Passkeys (the primary method), Google, GitHub, and email with password. | +| **Multi-factor** | Opt-in per user: authenticator apps (TOTP), WebAuthn security keys, and device biometrics. SMS is deliberately not offered. | +| **Access control** | Access keys scoped to a single region and to specific permissions (Read, Write, List, Delete), optionally restricted to named buckets, with optional expiry dates. | +| **Encryption** | Always on, at rest and in transit. TLS is enforced and HTTP is rejected. It cannot be disabled. | +| **Retention (WORM)** | Object Lock in Governance and Compliance modes, from 1 day to 100 years. A Compliance-mode lock binds every caller, including the account owner. | + +Detail on each: [API Keys](/security/api-keys), [Encryption](/security/encryption), [Object Lock](/storage/object-lock). ## Shared responsibility -Fil One is not the sole party in the storage path, and this determines what any future certification could actually cover. +Storage is fulfilled by regional operators on the Filecoin network, so a review needs to know which layer owns what: | Layer | Operated by | Responsible for | |-------|-------------|-----------------| -| Console, API, identity, billing | **Fil One** | Authentication, access-key issuance and scoping, MFA, the dashboard, request authorization, subscription state | -| Regional S3 storage gateway | **Regional storage operator** | Accepting and serving object data, server-side encryption at rest, **custody of encryption keys** | -| Underlying storage network | **Filecoin storage providers** | Physically holding data and producing the network's proof-of-storage | - -Two consequences worth stating explicitly to a reviewer: +| Console, API, identity, billing | **Fil One** | Authentication, access-key issuance and scoping, multi-factor enrolment, the dashboard, request authorization, subscription state | +| Regional S3 storage gateway | **Regional storage operator** | Serving object data, applying server-side encryption at rest, custody of encryption keys | +| Underlying storage network | **Filecoin storage providers** | Holding data and producing the network's proof-of-storage | -- **Encryption key custody sits with the regional storage operator**, not with Fil One and not with you. There is no customer-managed-key option and no SSE-C. See [Encryption](/security/encryption). -- **The specific cipher and SSE mode are set by the regional operator** and are not currently published. If your requirements depend on the exact scheme, contact support — see [Encryption](/security/encryption). +The practical consequence for a security review: encryption at rest is applied and keyed by the regional storage operator, so there is no customer-managed-key or SSE-C option, and the cipher in use is set by that operator. If your requirements turn on the exact scheme, or on who holds key material for a given region, contact support and we will route the question to the operator for your region. -## What is available to a procurement team today +## Who to ask -- **Security contact:** [security@fil.one](mailto:security@fil.one) -- **Controls you can verify yourself in the product:** passkey / Google / GitHub / email-password authentication with opt-in MFA (TOTP, WebAuthn security keys, device biometrics — SMS is intentionally not offered); region-scoped, permission-scoped, optionally bucket-scoped and expiring access keys; always-on encryption in transit (TLS, HTTP rejected) and at rest; WORM retention via Object Lock in Governance and Compliance modes. -- **Documented behaviour relevant to retention and privacy reviews:** [Object Lock](/storage/object-lock) for WORM retention and its compliance caveats, [API Keys](/security/api-keys) for the access-control model, and the [FAQ](/faq) and [Trial & Billing](/billing/trial) for deletion and account-closure semantics. -- **What to request from whom:** questions about Fil One's own controls (auth, access keys, the console) go to [security@fil.one](mailto:security@fil.one). Questions about the storage gateway's encryption implementation or key custody are answered by the regional operator; contact support and we will route them. +- **Fil One's own controls** (authentication, access keys, the console): [security@fil.one](mailto:security@fil.one). +- **The storage gateway's encryption implementation or key custody:** contact support and we will route the question to the regional operator. -## What Fil One explicitly does not claim +## Scope of what Fil One claims Stated here so it does not have to be inferred: -- **No third-party attestation or certification** of any kind, for any feature, today. -- **No auditor-presentable per-object proof.** The product surfaces no CID, deal ID, or seal state for an object, so there is nothing to hand an auditor as evidence that a specific object was stored intact or destroyed. Filecoin's network-level proof cycle is real, but it is a property of the network and is not exposed per object — see [How does Filecoin protect the integrity of stored data?](/faq). -- **No determination that any feature satisfies a specific regulation.** Object Lock provides WORM-style retention, which many regimes call for as a building block; whether it meets a named obligation is for your own compliance review to decide. The regulations named anywhere in these docs are illustrative use cases, not certification claims. -- **No published cipher or key-management scheme** for encryption at rest (see above). +- **Proof-of-storage is a network property.** Filecoin storage providers continuously prove they still hold the data they committed to store. Fil One does not surface per-object content identifiers, deal IDs, or seal state, so there is no per-object artefact to hand an auditor. See [How does Filecoin protect the integrity of stored data?](/faq). +- **Named regulations describe use cases, not certifications.** Where these docs mention SEC 17a-4, FINRA, HIPAA or similar, they describe a scenario the underlying capability supports. Whether a given feature satisfies a specific obligation is a determination for your own compliance review. ## Related -- [Encryption](/security/encryption) — at-rest and in-transit encryption, key custody -- [Object Lock](/storage/object-lock) — WORM retention and its compliance caveats -- [API Keys](/security/api-keys) — permissions, region scoping, expiration +- [Encryption](/security/encryption): at-rest and in-transit encryption, key custody +- [Object Lock](/storage/object-lock): WORM retention and its compliance caveats +- [API Keys](/security/api-keys): permissions, region scoping, expiration +- [FAQ](/faq) and [Trial & Billing](/billing/trial): deletion and account-closure behaviour diff --git a/static/llms-full.txt b/static/llms-full.txt index 0e834d0..ae07587 100644 --- a/static/llms-full.txt +++ b/static/llms-full.txt @@ -1244,46 +1244,50 @@ Source: https://docs.fil.one/security/compliance ## Certification status -Fil One does NOT hold SOC 2 Type II or ISO 27001 certification today. Both are -actively being pursued. Fil One holds NO third-party compliance attestation for -any feature — including SEC 17a-4 assessments of the Object Lock / WORM -capability. Contact security@fil.one if a certification is a hard requirement. +SOC 2 Type II and ISO 27001 are actively being pursued. Fil One does not hold +either certification today, and holds no third-party compliance attestation for +any feature, including the SEC 17a-4 assessments often asked about for WORM +retention workloads. Contact security@fil.one for where that work stands. + +## Controls in place today + +| Area | What is in place | +|------|------------------| +| Authentication | Passkeys (primary method), Google, GitHub, email with password. | +| Multi-factor | Opt-in per user: authenticator apps (TOTP), WebAuthn security keys, device biometrics. SMS deliberately not offered. | +| Access control | Access keys scoped to a single region and to specific permissions (Read, Write, List, Delete), optionally restricted to named buckets, with optional expiry. | +| Encryption | Always on, at rest and in transit. TLS enforced, HTTP rejected, cannot be disabled. | +| Retention (WORM) | Object Lock in Governance and Compliance modes, 1 day to 100 years. A Compliance-mode lock binds every caller including the account owner. | ## Shared responsibility | Layer | Operated by | Responsible for | |-------|-------------|-----------------| -| Console, API, identity, billing | Fil One | Authentication, access-key issuance and scoping, MFA, dashboard, request authorization, subscription state | -| Regional S3 storage gateway | Regional storage operator | Accepting/serving object data, server-side encryption at rest, CUSTODY OF ENCRYPTION KEYS | -| Underlying storage network | Filecoin storage providers | Physically holding data, producing the network's proof-of-storage | - -Consequences: encryption key custody sits with the regional storage operator, -not Fil One and not the customer (no customer-managed keys, no SSE-C); and the -specific cipher / SSE mode is set by the regional operator and is not published. - -## Available to a procurement team today - -Security contact: security@fil.one. Customer-verifiable controls: passkey / -Google / GitHub / email-password auth with opt-in MFA (TOTP, WebAuthn security -keys, device biometrics — SMS intentionally not offered); region-scoped, -permission-scoped, optionally bucket-scoped and expiring access keys; always-on -encryption in transit (TLS, HTTP rejected) and at rest; WORM retention via -Object Lock in Governance and Compliance modes. Questions about Fil One's own -controls go to security@fil.one; questions about the gateway's encryption -implementation or key custody are answered by the regional operator via support. - -## What Fil One explicitly does not claim - -- No third-party attestation or certification of any kind, for any feature. -- No auditor-presentable per-object proof — no CID, deal ID, or seal state is - surfaced, so there is nothing to hand an auditor as evidence a specific object - was stored intact or destroyed. Filecoin's network-level proof cycle is real - but is a property of the network and is not exposed per object. -- No determination that any feature satisfies a specific regulation. Regulations - named anywhere in these docs are illustrative use cases, not certification - claims. -- No published cipher or key-management scheme for encryption at rest. - +| Console, API, identity, billing | Fil One | Authentication, access-key issuance and scoping, multi-factor enrolment, dashboard, request authorization, subscription state | +| Regional S3 storage gateway | Regional storage operator | Serving object data, applying server-side encryption at rest, custody of encryption keys | +| Underlying storage network | Filecoin storage providers | Holding data and producing the network's proof-of-storage | + +Practical consequence: encryption at rest is applied and keyed by the regional +storage operator, so there is no customer-managed-key or SSE-C option and the +cipher in use is set by that operator. Questions turning on the exact scheme or +on key custody for a region go to support, who route them to the operator. + +## Who to ask + +Fil One's own controls (authentication, access keys, the console): +security@fil.one. The storage gateway's encryption implementation or key +custody: contact support, who route to the regional operator. + +## Scope of what Fil One claims + +- Proof-of-storage is a NETWORK property. Filecoin providers continuously prove + they still hold committed data, but Fil One does not surface per-object content + identifiers, deal IDs, or seal state, so there is no per-object artefact to + hand an auditor. +- Named regulations describe USE CASES, not certifications. Where these docs + mention SEC 17a-4, FINRA, HIPAA or similar, they describe a scenario the + underlying capability supports. Whether a feature satisfies a specific + obligation is a determination for your own compliance review. --- diff --git a/static/llms.txt b/static/llms.txt index eb1f479..4f318a3 100644 --- a/static/llms.txt +++ b/static/llms.txt @@ -103,13 +103,18 @@ Critical integration notes for developers: the regional operator (no customer-managed keys, cipher unconfirmed). Client-side encryption is up to you — AWS's S3 Encryption Client exists only for Java/.NET/Go/Ruby, NOT boto3/CLI/JS v3 -- [Compliance & Certifications](https://docs.fil.one/security/compliance): Fil - One holds NO SOC 2 Type II, NO ISO 27001, and NO third-party attestation of - any kind today (both actively pursued). Shared-responsibility split: Fil One - owns console/API/identity; the regional storage operator owns the gateway and - encryption key custody; Filecoin providers hold the data. Security contact - security@fil.one. No auditor-presentable per-object proof, no published - cipher, no claim any feature satisfies a named regulation +- [Compliance & Certifications](https://docs.fil.one/security/compliance): SOC 2 + Type II and ISO 27001 are actively being pursued; neither is held today, and + there is no third-party attestation for any feature. Controls live today: + passkey/Google/GitHub/email auth, opt-in MFA (TOTP, WebAuthn, biometrics, no + SMS), region- and permission-scoped expiring access keys, always-on + encryption, Object Lock WORM. Shared responsibility: Fil One owns + console/API/identity; the regional storage operator owns the gateway and + encryption key custody (so no customer-managed keys, no SSE-C, and the cipher + is the operator's); Filecoin providers hold the data. Security contact + security@fil.one. Proof-of-storage is a network property, so there is no + per-object artefact for an auditor; named regulations are use cases, not + certifications ## Billing From bcf17f29a014c02c5bd5742d0aebe18237250223 Mon Sep 17 00:00:00 2001 From: filipagr Date: Wed, 5 Aug 2026 16:25:13 -0300 Subject: [PATCH 3/3] docs: rename to Certifications & Trust, add auditor-evidence section Prompted by comparing against Wasabi's compliance docs, which turn out to document their Compliance mode WORM feature and name no certifications or regulations at all. That is a different genre from this page, and the comparison surfaced a naming collision we have and Wasabi does not. 1. Renamed the page. "Compliance" already names a specific Object Lock retention mode in Fil One ("Compliance mode binds every caller, including the account owner"), so a docs reader searching for "compliance" hit two unrelated things: a retention mode under Storage and a certifications page under Security. "Certifications & Trust" removes the collision and is the more accurate title, since the page covers certification status, shared responsibility and scope of claims rather than any compliance feature. 2. Added a disambiguation callout pointing WORM/immutability readers at Object Lock. 3. New "Demonstrating a control is in force" section, borrowed from Wasabi's "Checking for Immutability" idea. Auditors want evidence rather than a statement that a feature exists, and this was the one genuinely useful thing the page lacked. Lists what a customer can produce themselves: GetObjectRetention, GetBucketObjectLockConfiguration, GetObjectLegalHold and GetBucketVersioning, plus a reproducible 403 on deleting a retained object. Region-scoped honestly (GetObjectLegalHold is confirmed in us-east-1 only) and notes the reads need selectable key permissions. No redirect needed: the old /security/compliance URL never shipped, since this page has only ever existed on this branch. --- ...iance.mdx => certifications-and-trust.mdx} | 25 +++++++++++++++-- sidebars.js | 2 +- static/llms-full.txt | 26 +++++++++++++++-- static/llms.txt | 28 +++++++++++-------- 4 files changed, 64 insertions(+), 17 deletions(-) rename docs/security/{compliance.mdx => certifications-and-trust.mdx} (68%) diff --git a/docs/security/compliance.mdx b/docs/security/certifications-and-trust.mdx similarity index 68% rename from docs/security/compliance.mdx rename to docs/security/certifications-and-trust.mdx index e4c6108..58676bb 100644 --- a/docs/security/compliance.mdx +++ b/docs/security/certifications-and-trust.mdx @@ -1,9 +1,13 @@ --- -title: Compliance & Certifications +title: Certifications & Trust description: Certification status, the shared-responsibility model, and what a procurement team can request today. --- -This page is the current reference for Fil One's compliance posture: where certification stands, which controls are live in the product today, and how responsibility divides between Fil One and the storage operators behind it. +This page is the current reference for Fil One's security and compliance posture: where certification stands, which controls are live in the product today, and how responsibility divides between Fil One and the storage operators behind it. + +:::note Looking for WORM immutability? +"Compliance" also names a specific Object Lock retention mode in Fil One. If you are here for immutable storage, retention periods, or legal holds, see [Object Lock](/storage/object-lock). This page is about certification status and security posture. +::: ## Certification status @@ -25,6 +29,23 @@ These are live in the product and open to your own review: Detail on each: [API Keys](/security/api-keys), [Encryption](/security/encryption), [Object Lock](/storage/object-lock). +## Demonstrating a control is in force + +Auditors usually want evidence, not a statement that a feature exists. What you can produce yourself today: + +| To show | Call | Returns | +|---------|------|---------| +| A specific object version is under retention | `GetObjectRetention` | The retention mode (`GOVERNANCE` or `COMPLIANCE`) and its `RetainUntilDate` | +| A bucket's default retention policy | `GetBucketObjectLockConfiguration` | The mode and duration applied to new object versions | +| A legal hold is active on an object | `GetObjectLegalHold` | The hold status | +| Versioning is enabled on a bucket | `GetBucketVersioning` | `Enabled` | + +`GetObjectRetention` and `GetBucketObjectLockConfiguration` work in both regions. `GetObjectLegalHold` is confirmed in `us-east-1` and not yet confirmed in `eu-west-1`. The reads require the matching access-key permissions, which are selectable when you create a key rather than granted by default: see [API Keys](/security/api-keys). + +A failed delete is also evidence in itself. Attempting to delete an object under active retention returns `403 AccessDenied`, which is reproducible on demand. + +What you **cannot** produce is a per-object cryptographic artefact (see [Scope of what Fil One claims](#scope-of-what-fil-one-claims)). + ## Shared responsibility Storage is fulfilled by regional operators on the Filecoin network, so a review needs to know which layer owns what: diff --git a/sidebars.js b/sidebars.js index 2884dbe..ddfe162 100644 --- a/sidebars.js +++ b/sidebars.js @@ -31,7 +31,7 @@ const sidebars = { "security/authentication", "security/api-keys", "security/encryption", - "security/compliance", + "security/certifications-and-trust", ], }, { diff --git a/static/llms-full.txt b/static/llms-full.txt index ae07587..098cd84 100644 --- a/static/llms-full.txt +++ b/static/llms-full.txt @@ -1238,9 +1238,12 @@ applies automatically. --- -# Compliance & Certifications +# Certifications & Trust -Source: https://docs.fil.one/security/compliance +Source: https://docs.fil.one/security/certifications-and-trust + +Certification status and security posture. NOT the Object Lock "Compliance" +retention mode, which is a separate feature (see Object Lock). ## Certification status @@ -1259,6 +1262,25 @@ retention workloads. Contact security@fil.one for where that work stands. | Encryption | Always on, at rest and in transit. TLS enforced, HTTP rejected, cannot be disabled. | | Retention (WORM) | Object Lock in Governance and Compliance modes, 1 day to 100 years. A Compliance-mode lock binds every caller including the account owner. | +## Demonstrating a control is in force + +Auditors want evidence, not a statement that a feature exists. Producible by the +customer today: + +| To show | Call | Returns | +|---------|------|---------| +| An object version is under retention | GetObjectRetention | Mode (GOVERNANCE/COMPLIANCE) and RetainUntilDate | +| A bucket's default retention policy | GetBucketObjectLockConfiguration | Mode and duration applied to new versions | +| A legal hold is active | GetObjectLegalHold | Hold status | +| Versioning is enabled | GetBucketVersioning | Enabled | + +GetObjectRetention and GetBucketObjectLockConfiguration work in both regions. +GetObjectLegalHold is confirmed in us-east-1, not yet confirmed in eu-west-1. +These reads need the matching access-key permissions, which are selectable at +key creation rather than granted by default. A failed delete is also evidence: +deleting an object under active retention returns 403 AccessDenied, reproducible +on demand. What CANNOT be produced is a per-object cryptographic artefact. + ## Shared responsibility | Layer | Operated by | Responsible for | diff --git a/static/llms.txt b/static/llms.txt index 4f318a3..2c5363b 100644 --- a/static/llms.txt +++ b/static/llms.txt @@ -103,18 +103,22 @@ Critical integration notes for developers: the regional operator (no customer-managed keys, cipher unconfirmed). Client-side encryption is up to you — AWS's S3 Encryption Client exists only for Java/.NET/Go/Ruby, NOT boto3/CLI/JS v3 -- [Compliance & Certifications](https://docs.fil.one/security/compliance): SOC 2 - Type II and ISO 27001 are actively being pursued; neither is held today, and - there is no third-party attestation for any feature. Controls live today: - passkey/Google/GitHub/email auth, opt-in MFA (TOTP, WebAuthn, biometrics, no - SMS), region- and permission-scoped expiring access keys, always-on - encryption, Object Lock WORM. Shared responsibility: Fil One owns - console/API/identity; the regional storage operator owns the gateway and - encryption key custody (so no customer-managed keys, no SSE-C, and the cipher - is the operator's); Filecoin providers hold the data. Security contact - security@fil.one. Proof-of-storage is a network property, so there is no - per-object artefact for an auditor; named regulations are use cases, not - certifications +- [Certifications & Trust](https://docs.fil.one/security/certifications-and-trust): + certification status and security posture (NOT the Object Lock "Compliance" + retention mode, which is a separate feature). SOC 2 Type II and ISO 27001 are + actively being pursued; neither is held today, and there is no third-party + attestation for any feature. Controls live today: passkey/Google/GitHub/email + auth, opt-in MFA (TOTP, WebAuthn, biometrics, no SMS), region- and + permission-scoped expiring access keys, always-on encryption, Object Lock + WORM. To evidence a control to an auditor: GetObjectRetention, + GetBucketObjectLockConfiguration, GetObjectLegalHold (us-east-1 only), + GetBucketVersioning, plus a reproducible 403 on deleting a retained object. + Shared responsibility: Fil One owns console/API/identity; the regional storage + operator owns the gateway and encryption key custody (so no customer-managed + keys, no SSE-C, and the cipher is the operator's); Filecoin providers hold the + data. Security contact security@fil.one. Proof-of-storage is a network + property, so there is no per-object artefact for an auditor; named regulations + are use cases, not certifications ## Billing