01
Infrastructure & Hosting Architecture
All GTD application infrastructure, data processing, and storage is hosted exclusively within the European Union. No client data is transmitted to, processed in, or stored in any jurisdiction outside the EEA at any point in the diagnostic workflow.
Hosting Jurisdiction
| Cloud Provider | EU-based infrastructure — eu-west-1 / Frankfurt (AWS) or equivalent EU region |
| Data Residency | European Union — EEA at all times; no third-country transfers |
| Subprocessors | EU only; any subprocessor engagement subject to Article 28 DPA and adequacy decision or SCCs |
| CDN / Edge | EU-scoped delivery network; no client data cached outside EEA |
| Network Isolation | Application components deployed within private VPC; no direct public internet exposure to data layer |
Architecture Layers
End-to-end architecture — from client browser to data store
- →Frontend: React SPA served over TLS 1.3; no client data persisted in browser storage beyond the active session
- →Application Layer: Stateless service tier; horizontally scalable; no persistent local storage on compute instances
- →AI Inference: Anthropic Claude API — called over encrypted HTTPS; zero data retention under enterprise DPA (see Section 5)
- →Database Layer: Encrypted PostgreSQL with AES-256 at rest; per-tenant schema isolation enforced at database level
- →Object Storage: AES-256-S3 encrypted EU bucket; pre-signed URLs with short TTL for any file access events
02
Data Classification & Handling
GTD processes treasury process data — not personal data in the conventional sense. Diagnostic inputs are structural and operational: cash pooling structures, payment flow architectures, FX exposure parameters, bank account configurations, and treasury policy settings. No payroll data, no individual transaction records, and no personally identifiable financial data are required or ingested.
| Data Category | Treasury process and operational structure data |
| Personal Data (GDPR Art. 4) | Minimal — limited to client contact details for account management purposes |
| Special Category Data | None processed |
| Financial Transaction Records | Not required; aggregate and structural parameters only |
| Sensitivity Classification | Confidential — treated as commercially sensitive throughout lifecycle |
Data Flow — End to End
How your data moves through the GTD platform
- →Client completes the 107-question diagnostic via the GTD secure web portal — all transmission over HTTPS / TLS 1.3
- →Responses are encrypted in transit and written to the encrypted database under the client's isolated tenant schema
- →On completion, the diagnostic engine assembles a structured data payload — anonymised parameter sets, not raw questionnaire text — and submits it to the AI layer
- →AI-generated analysis is returned to the GTD application layer, enriched with expert benchmarks, and rendered into the report template
- →The final report is stored in encrypted object storage and delivered via a time-limited, authenticated download link to the authorised contact
- →No data is shared with any third party beyond the AI inference API (under DPA) and the EU cloud infrastructure provider
03
Encryption
In Transit
| Protocol | TLS 1.3 enforced; TLS 1.0 and 1.1 disabled globally |
| Certificate Authority | Let's Encrypt / DigiCert — publicly trusted CA |
| HSTS | Strict-Transport-Security header enforced with preload directive |
| Internal Service Calls | mTLS within the VPC; no plaintext inter-service communication |
| External API Calls | AI API called over HTTPS with certificate pinning |
At Rest
| Database | AES-256 at storage layer; column-level encryption for sensitive fields |
| Object Storage | AES-256-S3 server-side encryption; customer-managed key (CMK) option available |
| Backups | Encrypted prior to storage; same key management regime as primary data |
| Key Management | AWS KMS (EU region) or equivalent EU-based HSM; annual key rotation minimum |
| Compliance Standard | FIPS 140-2 compliant cryptographic modules throughout |
04
Access Controls
Authentication
| Method | Username / password with mandatory MFA (TOTP or WebAuthn / passkey) |
| Session Management | JWT with 60-minute expiry; refresh token rotation enforced on every use |
| Password Policy | Minimum 12 characters; bcrypt hashing (cost factor 12); breach-check via HaveIBeenPwned API on registration and login |
| Brute Force Protection | Rate limiting + exponential backoff + account lockout after 5 failed attempts |
| SSO / Federated Identity | SAML 2.0 and OIDC available for enterprise clients |
Tenant Isolation
GTD operates a strict multi-tenant isolation model. Each client organisation is provisioned as an independent tenant. Cross-tenant data access is architecturally prevented — not merely policy-controlled.
Isolation controls — enforced at multiple independent layers
- →Database-level row security policies enforced at the PostgreSQL engine, not the application layer
- →Application-level tenant ID validation on every API request, enforced in middleware before any data operation executes
- →Separate encryption keys per tenant for sensitive data fields
- →All data access events logged with tenant ID, user identity, and timestamp
Internal Access
| GTD Staff Access | Role-based; least-privilege principle enforced; quarterly access review |
| Production Data Access | Named individuals only; requires MFA + VPN + full audit log entry |
| Administrative Access | Just-in-time (JIT) provisioning; no standing privileged access |
| Developer Access | No access to production client data; anonymised synthetic data used in all development and testing environments |
| Deutsche Bank Separation | Complete organisational firewall — GTD operates as an independent entity; no Deutsche Bank personnel have any access to GTD systems, infrastructure, or client data |
05
AI Processing — Anthropic Claude API
GTD uses the Anthropic Claude API as the AI inference layer for report generation. This is governed by Anthropic's enterprise Data Processing Agreement, which provides the following material guarantees:
| Data Retention | Zero — Anthropic does not retain, log, or store API inputs or outputs beyond the duration of the API call |
| Model Training | Client data submitted via the API is never used to train, fine-tune, or evaluate Anthropic's models |
| Purpose of Processing | API response only; no secondary use of any kind |
| GDPR Role | Anthropic acts as data processor (Article 28); GTD as controller |
| DPA | Anthropic enterprise Data Processing Agreement in force |
What is sent to the AI layer
Precisely scoped API payloads — no client-identifying data
- →Aggregated diagnostic scores and parameter sets — not raw questionnaire responses in identifiable form
- →Benchmark comparison inputs: industry segment, revenue band, geography
- →Structured JSON payloads — not free-text narratives containing client-identifying information
- →No company name, registered address, VAT number, or personally identifiable information is included in any AI inference payload
06
GDPR Compliance
Roles & Legal Basis
| GDPR Role | Data Controller for client contact data; Data Processor for treasury diagnostic inputs on behalf of the client organisation |
| Legal Basis — Contact Data | Article 6(1)(b) performance of contract; Article 6(1)(f) legitimate interests |
| Legal Basis — Diagnostic Data | Article 6(1)(b) performance of contract |
| Records of Processing | Article 30 ROPA maintained; available to supervisory authority on request |
| Data Protection Contact | Designated contact available for DPO queries and DSAR handling |
Data Subject Rights
GTD supports the exercise of all data subject rights under GDPR Chapter III. Requests are processed within statutory timelines — 30 days standard, 90 days for complex requests with notification.
| Access (Art. 15) | Full data export on request in machine-readable format (JSON / CSV) |
| Rectification (Art. 16) | Self-service correction of contact data via the client portal |
| Erasure (Art. 17) | Deletion workflow on contract termination or on request; cryptographic erasure of encryption keys for at-rest data |
| Portability (Art. 20) | Diagnostic data exportable in JSON / CSV format on request |
| Object (Art. 21) | Opt-out from any processing beyond service delivery |
Data Retention & Deletion
| Active Engagement Data | Duration of engagement plus 12 months post-completion |
| Contact & Account Data | Contract duration plus applicable statutory retention (7 years for financial records) |
| Deletion Method | Cryptographic erasure (key destruction) for at-rest data; verified deletion from object storage and database confirmed in audit log |
| Backup Purge | Rolling 90-day cycle; confirmed in audit log |
| Deletion on Request | Executed within 30 days of verified request; written confirmation provided |
07
Security Operations
Vulnerability Management
| Dependency Scanning | Automated SCA (Software Composition Analysis) on every build |
| SAST | Static application security testing integrated into CI/CD pipeline; blocks deployment on critical findings |
| Container Scanning | Docker image vulnerability scan before every deployment |
| Penetration Testing | Annual third-party penetration test; summary findings and remediation status available under NDA |
| CVE Patching SLA | Critical: < 24 hours · High: < 7 days · Medium: < 30 days |
Monitoring & Logging
| Application Logging | Structured JSON logs; no client data in log payloads; correlation IDs for distributed tracing |
| Security Event Logging | SIEM integration; authentication events, access control failures, data export events all logged with full context |
| Log Retention | Minimum 12 months |
| Anomaly Detection | Automated alerting on unusual access patterns, API call volume spikes, and failed authentication clusters |
| Log Integrity | Append-only log storage; tamper detection via hash chaining |
Incident Response
| Detection to Triage | Target < 1 hour for P1 security incidents |
| Client Notification | Within 24 hours of confirmed breach determination; full written notification within 72 hours |
| Regulatory Notification | GDPR Article 33 — supervisory authority notified within 72 hours of awareness of a personal data breach |
| Post-Incident Review | Root cause analysis and remediation report within 14 days of incident closure |
| Incident Log | Maintained and available to clients on request under NDA |
08
Certifications & Audit
GTD is a purpose-built platform. The following reflects current certification status and our roadmap. We believe in transparent disclosure — including what is still in progress.
| ISO 27001 | ●In Progress Gap assessment complete; implementation underway; certification target Q4 2026 |
| SOC 2 Type II | ●Planned Following ISO 27001 certification; target 2027 |
| GDPR Assessment | ●Completed Full compliance documentation available to enterprise clients on request |
| DPIA | ●Completed Data Protection Impact Assessment completed for all core processing activities |
| Penetration Test | ●Completed Annual third-party test conducted; summary findings available under NDA |
| Client Audit Rights | ●Available Right-to-audit clauses supported for enterprise engagements, subject to reasonable notice and scope agreement |
09
Business Continuity & Resilience
< 4hRTO
< 1hRPO
99.5%Uptime SLA
Every 6hDB Snapshots
ContinuousWAL Shipping
AnnualDR Test
| RTO (Recovery Time Objective) | < 4 hours for core diagnostic platform |
| RPO (Recovery Point Objective) | < 1 hour — continuous database replication to standby instance |
| Availability SLA | 99.5% monthly uptime |
| Backup Frequency | Automated database snapshots every 6 hours; continuous WAL (transaction log) shipping to standby |
| DR Environment | Hot standby in secondary EU availability zone; automated failover |
| BCP Testing | Full disaster recovery test conducted annually; results documented and available on request |