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)

The header identifies the card and its context. Field H-07 distinguishes Common Disclosure from Client-Specific Annex cards.

ID Field Format Required
H-01Supplier NameStringM
H-02Supplier Identifier (LEI / DUNS / SIREN)StringM
H-03Card VersionSemVer (e.g. 1.2.0)M
H-04Issue DateISO 8601M
H-05Valid UntilISO 8601M
H-06Scope DescriptionFree textM
H-07Card TypeCOMMON / CLIENT_SPECIFICM
H-08Parent Card ReferenceStringC
H-09Client NameStringC
H-10TPSA LevelBASIC / ENHANCED / FULLM
H-11Security ContactObject (name, email, PGP)M
H-12Compliance ContactObjectO
H-13Digital SignatureED25519M

M Mandatory   C Conditional (context-dependent)   O Optional

The Seven Disclosure Domains

D1

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.

D1-01 Asset Register D1-02 Asset Location D1-03 Hosting Model D1-04 Data Types Hosted D1-05 Data Flow Diagram D1-06 Sub-processors D1-07 Asset Classification D1-08 Asset Owner

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)

D2

Data Protection

Encryption, key management, data segregation (mandatory for multi-tenant deployments), retention, deletion, and cross-border transfer controls.

D2-01 Encryption at Rest D2-02 Encryption in Transit D2-03 Key Mgmt / BYOK / HYOK D2-04 Data Segregation D2-05 Retention Policy D2-06 Deletion Process D2-07 Classification Scheme D2-08 Cross-border Transfers

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)

D3

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."

D3-01 Backup Policy D3-02 Backup Location D3-03 Backup Encryption D3-04 RTO Declared D3-05 RPO Declared D3-06 Last Restore Test D3-07 Test Frequency D3-08 DR Plan Reference D3-09 DR Test Results

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)

D4

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.

D4-01 Authentication / MFA D4-02 PAM D4-03 Access Review Cycle D4-04 Least Privilege D4-05 Client-Facing Access D4-06 Third-Party Access D4-07 Logging & Monitoring

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)

D5

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.

D5-01 Vulnerability Scanning D5-02 Patch Management SLAs D5-03 Penetration Testing D5-04 Pentest Remediation D5-05 Bug Bounty / VDP D5-06 SBOM (mandatory at FULL) D5-07 TIBER-EU Readiness

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)

D6

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).

D6-01 Detection / SIEM / SOC D6-02 IR Plan Reference D6-03 Notification SLA D6-04 Notification Format D6-05 Post-Incident Review D6-06 Incident History 24m D6-07 Secure Comms Channel

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

D7

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.

D7-01 Certifications Held D7-02 Certification Scope D7-03 Audit Findings (mandatory Enhanced+) D7-04 Regulatory Status D7-05 Exclusions & Gaps D7-06 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:

  1. Client submits Classification Uplift Request referencing specific asset ID(s) from D1-01
  2. Supplier acknowledges within 10 business days
  3. Supplier assesses impact on shared infrastructure
  4. Supplier applies higher classification or proposes equivalent alternative controls
  5. 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).