Supplier Disclosure Standard
The foundational artifact of the TPSA framework. Defines the Disclosure Card a structured, machine-readable document that suppliers publish to communicate their security posture across 7 mandatory domains.
Overview
TPSA-01 defines the Supplier Disclosure Card the foundational artifact upon which all other TPSA components depend. The Disclosure Card is a structured, machine-readable document that a supplier publishes to communicate its security posture across seven domains.
The standard is technology-agnostic and regulation-agnostic in core design. It applies to:
- Cloud providers (IaaS, PaaS, SaaS)
- Managed Service Providers (MSP) and MSSPs
- Software vendors, data centre operators, telecoms
- Any third party processing, storing, or transmitting client data
The Disclosure Card is published in JSON format, conforming to the TPSA-01 JSON Schema, and signed with ED25519.
Card Architecture
The Disclosure Card uses a two-layer model to balance transparency with confidentiality:
| Layer | Content | Audience |
|---|---|---|
| Header (H-01 to H-13) | Supplier identity, card version, validity, scope, security contact, digital signature | All stakeholders. Machine-readable. |
| Common Disclosure (D1–D7) | Shared infrastructure controls and certifications across all 7 domains | All clients |
| Client-Specific Annex | Dedicated assets, data classification overrides, tailored controls, specific SLAs for one client | Individual client (confidential) |
Header Section (H-01 to H-13)
The header identifies the card and its context. Field H-07 distinguishes Common Disclosure from Client-Specific Annex cards.
| ID | Field | Format | Required |
|---|---|---|---|
| H-01 | Supplier Name | String | M |
| H-02 | Supplier Identifier (LEI / DUNS / SIREN) | String | M |
| H-03 | Card Version | SemVer (e.g. 1.2.0) | M |
| H-04 | Issue Date | ISO 8601 | M |
| H-05 | Valid Until | ISO 8601 | M |
| H-06 | Scope Description | Free text | M |
| H-07 | Card Type | COMMON / CLIENT_SPECIFIC | M |
| H-08 | Parent Card Reference | String | C |
| H-09 | Client Name | String | C |
| H-10 | TPSA Level | BASIC / ENHANCED / FULL | M |
| H-11 | Security Contact | Object (name, email, PGP) | M |
| H-12 | Compliance Contact | Object | O |
| H-13 | Digital Signature | ED25519 | M |
M Mandatory C Conditional (context-dependent) O Optional
The Seven Disclosure Domains
Asset Inventory & Data Mapping
Foundation for all subsequent domains and TIBER-EU test scoping. The structured asset register enables precise RSC targeting and TIBER-EU scope definition without requiring additional reconnaissance.
Maps to: CIS 1.1/1.2/3.2 · ISO A.5.9/A.5.10/A.5.12 · DORA Art.28(3)/(7)(a) · NIS2 Art.21(2)(a)/(d)
Data Protection
Encryption, key management, data segregation (mandatory for multi-tenant deployments), retention, deletion, and cross-border transfer controls.
Maps to: CIS 3.6/3.10/3.12 · ISO A.8.24/A.8.22 · DORA Art.9(2)/28(7)(b)/(d) · NIS2 Art.21(2)(h)
Backup & Recovery
Frequency, scope, encryption, tested RTO/RPO, and crucially: the date and outcome of the last successful restore test. "A backup that has never been tested is not a backup."
Maps to: CIS 11.1/11.2/11.5 · ISO A.8.13/A.5.29 · DORA Art.11(1)/12(2)/25 · NIS2 Art.21(2)(c)
Access Control & Identity Management
Authentication mechanisms including MFA, privileged access management (PAM), access review cycles, least privilege policy, client-facing and third-party access controls, and logging.
Maps to: CIS 5.4/6.3/6.5 · ISO A.8.2/A.8.5 · DORA Art.9(4) · NIS2 Art.21(2)(i)/(j)
Vulnerability Management & Testing
Scanning frequency and tools, patch management SLAs by severity, penetration testing scope and results. At TPSA Full: SBOM availability and TIBER-EU readiness are mandatory.
Maps to: CIS 7.1/7.3/18.2 · ISO A.8.8/A.8.19 · DORA Art.9(1)/25/26 · NIS2 Art.21(2)(e)
Incident Management & Notification
Detection capabilities (SIEM, EDR, SOC), incident response plan reference, client notification SLAs by severity, notification content format, post-incident review process. DORA Art. 19 aligned (4h initial notification for major incidents).
Maps to: CIS 13.1/17.1/17.2 · ISO A.5.24/A.5.26 · DORA Art.10/17/19 · NIS2 Art.21(2)(b)/23
Compliance & Certification Status
Certifications held with scope and validity, audit findings summary (mandatory at Enhanced and Full), regulatory status, known gaps and exclusions, and optional cyber insurance coverage.
Maps to: CIS 15.1/15.3/15.4 · ISO A.5.22/A.5.31 · DORA Art.28(2)/(3)/(4) · NIS2 Art.21(1)/(2)(d)
Classification Uplift Mechanism
The Rising Tide Effect
When a client identifies that a shared asset is classified lower by the supplier than the client classifies its own data on that asset, the client may submit a Classification Uplift Request. The supplier must assess, apply the higher classification, update the Common Disclosure Card, and notify other clients on the same asset without revealing the requesting client's identity. All tenants benefit from the highest classification applied by any tenant.
Classification Uplift procedure:
- Client submits Classification Uplift Request referencing specific asset ID(s) from D1-01
- Supplier acknowledges within 10 business days
- Supplier assesses impact on shared infrastructure
- Supplier applies higher classification or proposes equivalent alternative controls
- Common Disclosure Card updated; all clients on the same asset notified (anonymised)
Disclosure Card Lifecycle
Cards use semantic versioning (MAJOR.MINOR.PATCH). Every change must update the Issue Date and be re-signed. A changelog entry must accompany each new version.
| TPSA Level | Review Cycle | Event-Driven Update | Signature |
|---|---|---|---|
| BASIC | Annual | No mandatory requirement | ED25519 |
| ENHANCED | Semi-annual | Within 30 days of material change | ED25519 |
| FULL | Continuous | Within 15 days of material change | ED25519 + auditor countersignature |
Maturity Level Requirements
| Criterion | BASIC | ENHANCED | FULL |
|---|---|---|---|
| Fields Required | All Mandatory (M) | All M + applicable Conditional (C) | All M + C + recommended Optional (O) |
| Annex Support | Common Disclosure only | Common + Client-Specific Annexes | Common + Client-Specific + Classification Uplift |
| TIBER-EU | Not required | Readiness declaration (D5-07) | Active participation demonstrated |
| SBOM | Not required | Optional (D5-06) | Mandatory (D5-06) |
Example: CloudWorks SAS (Fictitious)
Illustrative Example Not a Real Entity
CloudWorks SAS is a fictitious SaaS document management provider used in TPSA-01 to illustrate a conformant TPSA Enhanced Disclosure Card.
TPSA Level: Enhanced Scope: Document Management Platform Equinix PA3 Paris + FR5 Frankfurt
- Assets: Kubernetes cluster, PostgreSQL DB, S3-compatible storage, backup storage all Shared / Confidential–Restricted
- Backup: Full daily at 02:00 UTC, 15-min transaction log incremental, LTO-9 tape weekly. RTO: 4h DB / 8h storage. RPO: 15 min DB. Last restore test: 2026-02-15, SUCCESS, 2h47m, 100% records recovered.
- Vulnerability: Qualys weekly external, Wazuh daily internal, Trivy on every container build. Annual pentest by Synacktiv (grey box, Jan–Feb 2026): 0 Critical, 2 High (both remediated), 5 Medium, 8 Low.
- Detection: Internal SOC 8×5, Sekoia.io MDR 24×7, Wazuh SIEM, CrowdStrike Falcon EDR, Suricata NDR. MTTD <15 min critical.
- Certifications: ISO 27001:2022 (LSTI, valid 2025–2028), SOC 2 Type II (Mazars, 2025).