TOM Documentation

Technical and Organizational Measures

BMX Holdings Ltd ("Orcha")

Version 5.0 | As of: 12.04.2026

Legal Basis: Art. 32 GDPR, Art. 28(3)(c) GDPR

1. Scope and Purpose

This TOM documentation applies to the processing of personal data within the SaaS platform of BMX Holdings Ltd ("Orcha"), which processes financial documents (invoices, receipts, contracts, purchase orders, goods receipt notes) for businesses and tax advisory firms. The platform operates as a processor pursuant to Art. 28 GDPR.

The measures described in this document meet the requirements of Art. 32 GDPR and additionally align with the protection level of §203 StGB (German Criminal Code -- Professional Secrecy), to also be suitable for clients with special confidentiality obligations. This applies as a universal standard for all customers, regardless of whether they are tax advisory firms or regular business customers.

The purpose of this documentation is to describe the technical and organizational measures that ensure the protection of customer data and trade secrets, as well as compliance with GDPR and German data protection law.

2. Confidentiality (Art. 32(1)(b) GDPR)

2.1 Physical Access Control

Orcha's infrastructure is hosted in the Amazon Web Services (AWS) region Frankfurt am Main (eu-central-1). This ensures processing within the European Union and compliance with local data protection requirements. The physical data centers are protected by comprehensive security measures:

• Multi-layer physical access control system
• Physical access restrictions to server racks
• Regular security audits by independent third parties

Orcha employees have no physical access to production servers. Administrative access is exclusively via secure, auditable remote sessions (AWS Systems Manager) without exposed SSH ports.

2.2 System Access Control

Access to the platform is protected through federated identity providers via AWS Cognito. End users authenticate through their existing Google or Microsoft accounts using industry-standard OAuth 2.0 / OpenID Connect protocols, benefiting from the authentication policies (including MFA where configured) of the respective identity provider.

Sessions are managed via HTTP-only, secure cookies. Cryptographic tokens are encrypted at rest using a customer-managed AWS KMS key before database storage.

2.3 Data Access Control

Access to customer data follows the principle of least privilege:

• Each customer organization is an isolated tenant; users can only access data belonging to their assigned tenant(s)
• Internal Orcha staff access for support purposes is limited to designated personnel with explicit authorization
• The administrative interface is architecturally separated and restricted to Orcha employee accounts
• External API access uses API keys with defined permission scopes per resource

2.4 Network Security

The network architecture is designed to limit exposure and segment access:

• Amazon VPC with separate public and private subnets across multiple availability zones
• Database systems run in private isolated subnets with no internet access
• All external traffic terminates at an Application Load Balancer with HTTPS and HTTP-to-HTTPS redirect
• Separate TLS certificates for application, administration, and API domains
• Security groups restrict database access to application and CI/CD environments only
• Administrative access via AWS Systems Manager with CloudWatch session logging

3. Integrity (Art. 32(1)(b) GDPR)

3.1 Transfer Control (Encryption in Transit)

All data transfers are encrypted:

• TLS encryption for all external and internal network connections
• HTTPS-only policy for all endpoints; HTTP requests are redirected
• All object storage enforces SSL via bucket policy
• Session cookies are flagged as secure and HTTP-only

3.2 Input Control (Audit Logging)

All significant data operations are logged:

• External API requests are logged with method, path, status, source IP, and requesting identity
• Financial export operations (e.g. DATEV) are tracked per document with status, timestamps, and initiating user
• Inbound email processing is recorded per message
• AI processing statistics (model, token counts, responses) are recorded per document
• All application log entries include structured context (tenant, document, and request identifiers)
• Log retention: 14 days for application logs, 30 days for administrative and session logs

4. Availability and Resilience (Art. 32(1)(b) GDPR)

Orcha ensures availability through the following measures:

• Availability target (SLA): 99.5% per year
• Load balancing across multiple availability zones
• Continuous health checks and automated alerting
• AWS Shield for baseline DDoS protection
• Cost anomaly detection for early warning of infrastructure issues

5. Recoverability (Art. 32(1)(c) GDPR)

A backup strategy ensures data integrity:

• Automated daily database backups with 14-day retention
• Database storage encryption enabled
• Document storage with versioning and lifecycle management
• Database deletion protection enabled
• Automated backups preserved across instance changes

6. Pseudonymization and Encryption (Art. 32(1)(a) GDPR)

6.1 Data Encryption

All personal data is encrypted at rest. Database storage, object storage, and message queues are encrypted using AWS-managed encryption. Sensitive application fields (authentication tokens, third-party credentials) are additionally encrypted using a customer-managed AWS KMS key with automatic annual rotation.

6.2 Pseudonymization

Pseudonymization (per GDPR Art. 4(5)) is the processing of data such that it cannot be attributed to a specific person without additional information (the key) stored separately.

Customer data is organized by internal tenant identifiers. The mapping between tenant identifiers and real customer identity is maintained in the authentication system, stored separately from the processed data.

Additional measures specific to AI-based document processing are described in Section 14.

7. Secure Software Development

The development process integrates security into all phases:

• Code review via pull requests before deployment
• Dependency vulnerability scanning against the NVD CVE database
• Static code analysis via linter with project-specific rules
• Development and testing use synthetic data in isolated local environments (Docker, embedded databases, AWS service emulation)
• CI/CD pipeline: automated build, containerization, and deployment via AWS CodePipeline
• Deployment is manually triggered, not automatic on code push

8. Vulnerability Management

A structured vulnerability management process protects against known security gaps:

• Dependency scanning against CVE databases with configurable severity thresholds
• Automated minor version upgrades for managed database services
• Infrastructure defined as code for auditability and reproducibility

9. Regular Review Procedures (Art. 32(1)(d) GDPR)

The effectiveness of TOMs is regularly reviewed:

• Annual full review and update of this TOM documentation
• Automated security updates and patch management for managed services
• Continuous monitoring and alerting on operational anomalies
• TLS certificate expiry monitoring with automated alerting
• Regular staff training on security topics

10. Sub-Processors

Orcha uses the following sub-processors for specialized tasks (detailed list in separate document O3 "Sub-Processor List"):

• AWS (Hosting and cloud infrastructure, email, authentication, key management)
• Anthropic (AI document extraction and classification)
• Google (OCR, AI processing, semantic search embeddings)
• Microsoft (SSO authentication, Outlook email sync, Teams notifications)
• Slack (Notification delivery)
• Maesn (DATEV accounting integration)

All sub-processors are contractually bound to equivalent technical and organizational measures. A current list with detailed data flows is available in document O3.

11. Incident Management (Incident Response)

11.1 Detection

Security incidents are proactively detected through automated alerting systems, application-level error monitoring with structured context, and employee reports of suspected security incidents.

11.2 Classification

Security incidents are classified by severity:

• Critical: Unauthorized access to customer data, data loss, system outage
• High: Brute-force attacks, unusual access, failed authentications at scale
• Medium: Vulnerabilities without current exploitation, policy violations
• Low: Information leaks without data damage, standard security warnings

11.3 Response and Notification

Every incident receives a timely response. The controller (client) is notified no later than 24 hours after discovery. For critical incidents, immediate containment measures are taken. Orcha supports the controller in reporting to supervisory authorities (72-hour deadline per Art. 33 GDPR). All response measures are documented.

11.4 Evidence Preservation and Forensic Analysis

After detection of an incident, all relevant logs and audit trails are preserved, affected systems are isolated to prevent further contamination, and forensic analysis is conducted for root cause determination. All evidence is preserved for potential criminal investigations.

11.5 Post-Mortem and Improvement

After resolution of an incident, a detailed root cause analysis is conducted, improvement measures are implemented, this documentation and security procedures are updated, and lessons learned are communicated to affected customers (without disclosing sensitive details).

12. Data Deletion and Return

12.1 Data Deletion

Customer data is deleted upon instruction of the controller. Deletion occurs within 30 days of contract termination or deletion request, covering all systems: production database, backups, caches, and logs. Verification of deletion is conducted through separate automated control runs, and a deletion confirmation is issued upon request. Archive retention for compliance requirements is taken into account.

12.2 Data Return

Upon request, customer data can be returned in machine-readable format (JSON or CSV as agreed), transmitted in encrypted form, with completeness verified before transmission.

13. Employee-Related Measures

13.1 Data Confidentiality Obligation

All employees are obligated to maintain trade secrets through a written obligation to comply with data confidentiality (§53 BDSG), a written confidentiality agreement, and explicit reference to criminal consequences under §203 StGB. These measures apply as a universal standard for all employees.

13.2 Data Protection Training

Data protection and security training is mandatory. This includes annual training on GDPR and German data protection law, awareness of §203 StGB criminal provisions, training in incident response and phishing detection, and documentation of all training participation.

13.3 Need-to-Know Principle

Data access is strictly limited to what is necessary. Tenant isolation is enforced at the application level. The administrative interface is restricted to Orcha employee accounts. Development and testing use exclusively synthetic and anonymized data.

13.4 Offboarding

Upon termination of employment, access is immediately revoked, all credentials and devices are returned, access history is archived for audit purposes, and compliance with confidentiality agreements is confirmed.

14. AI-Specific Measures

The automated processing of documents with AI systems is subject to special protective measures:

14.1 AI Systems in Use

Orcha uses closed AI models from Anthropic (Claude) and Google (Gemini, Document AI, Vertex AI) for document extraction, classification, email triage, post-processing, and semantic search. Contractual guarantees ensure that customer data is not used for model training by any AI sub-processor.

14.2 Data Minimization in AI Input

Only the documents and content necessary for the respective processing purpose are transmitted to AI services. Semantic search embeddings use derived text fields and explicitly exclude bank account details. Email triage uses truncated content and low-resolution previews. AI sub-processors are contractually prohibited from retaining input data beyond the processing duration or using it for model training.

14.3 Documentation and Auditing

AI processing statistics are recorded per document, including the model used, token counts, and confidence levels. AI responses are retained for audit purposes.

14.4 No Automated Individual Decisions

No fully automated decisions with legal effect are made pursuant to Art. 22 GDPR. AI results are used as suggestions for human validation. Financial export actions (e.g. DATEV booking) require explicit human confirmation, and documents flagged for review are blocked from export until a user has reviewed them. Controllers are informed about AI use in privacy notices.

Change History