DPA Annex 2 - Technical and Organisational Measures (TOMs)

Last updated: May 2026 Processor: Stratum1 GmbH, Schubertstrasse 6a, 8010 Graz, Austria This Annex describes the technical and organisational measures implemented by Stratum1 GmbH for the Arrival.Space platform. The measures are applied in a risk-based and proportionate manner, taking into account the state of the art, implementation costs, the nature, scope, context and purposes of processing, the risks to data subjects, and the fact that Stratum1 is a European startup with a small team operating a global SaaS platform. The measures may evolve over time, provided that the overall level of protection is not materially reduced. These TOMs do not constitute a service-level agreement and do not guarantee uninterrupted availability, response times, recovery times or support times unless expressly agreed separately in writing.

1. Governance and Organisation

Stratum1 maintains internal responsibility for security and data protection. Data protection and security tasks are assigned to appropriate team members according to role and expertise. Policies and internal procedures cover, as applicable:

• access control;
• confidentiality;
• incident handling;
• secure development;
• vendor and subprocessor management;
• backup and recovery;
• data deletion and retention;
• acceptable use of production systems.

Controls are designed to be practical, documented and proportionate for a European startup with a small team. Where a formal certification is not available, Stratum1 relies on internal controls, provider security documentation and risk-based review.

2. Confidentiality and Personnel Controls

Personnel with access to personal data are bound by confidentiality obligations, whether by employment, contractor agreement, founder duties or separate confidentiality commitments. Access to personal data and production systems is limited to persons who require access for their role, such as operations, support, security, development or legal compliance. Team members are informed of their responsibilities regarding confidentiality, data protection, secure handling of credentials, phishing risk and incident reporting.

3. Access Control and Authentication

Access to systems is managed according to least-privilege and need-to-know principles. Measures may include:

• individual user accounts where technically feasible;
• role-based access controls for internal systems;
• separate permissions for administrative access;
• review and revocation of access when no longer required;
• strong authentication requirements;
• multi-factor authentication for critical systems where available;
• secure handling of API keys, secrets and tokens;
• avoidance of shared accounts where reasonably possible.

Administrative access to production systems is restricted to authorised personnel.

4. Platform-Level Access Controls

The Platform includes or may include controls for:

• account roles and permissions;
• workspace and team access;
• space visibility and access settings;
• collaborator, viewer, editor and administrator roles;
• API keys, access tokens and MCP tokens;
• revocation or regeneration of API/MCP access;
• permission checks for spaces, assets and account-level actions;
• isolation of unrelated user spaces and account data;
• rate limits and abuse-prevention controls.

Plugins, vibes, APIs and MCP access are designed to operate within user permissions and technical scopes. Where technically implemented, plugins and vibes are restricted from general access to unrelated spaces, external domains, browser cookies or local storage unless enabled through Platform functionality and permissions.

5. Encryption and Transmission Security

Communication with the Platform is protected using TLS/HTTPS where technically feasible. Authentication credentials, tokens and sensitive secrets must not be transmitted unprotected over public networks. Encryption at rest is used where provided by infrastructure providers or where technically appropriate for the relevant storage system.

6. Network, Infrastructure and Cloud Security

Stratum1 uses professional cloud and infrastructure providers for hosting, compute, storage, networking, security and delivery of the Services. Measures may include:

• network segmentation or logical separation where appropriate;
• firewall or security group restrictions;
• load balancing and traffic management;
• DDoS protection and security filtering through providers;
• secure configuration of cloud resources;
• restricted administrative access;
• monitoring of infrastructure availability and performance.

Physical security of data centres is provided by the relevant infrastructure and cloud providers.

7. Logging, Monitoring and Auditability

Systems may generate logs for security, debugging, performance, abuse prevention and operational reliability. Logs may include access events, API activity, authentication events, errors, security events, system metrics, request metadata and administrative actions where technically available. Log access is restricted to authorised personnel. Logs are retained for limited periods according to operational and security needs unless longer retention is required for incident investigation, legal compliance or legal claims.

8. Secure Development and Change Management

Development follows practical secure development practices appropriate for a small engineering team and cloud SaaS product. Measures may include:

• use of version control;
• review or testing of relevant changes before production release;
• separation between development and production environments where feasible;
• dependency and vulnerability awareness;
• rollback or remediation procedures for problematic releases;
• tracking of relevant changes.

Security-relevant changes are reviewed with regard to their impact on confidentiality, integrity and availability where appropriate.

9. Backups, Resilience and Availability

Backup and recovery procedures are used where appropriate for relevant systems and data. Measures may include:

• automated backups for core systems;
• provider-level redundancy where available;
• monitoring of backup or infrastructure health;
• restoration procedures for technical incidents;
• protection of backups against unauthorised access;
• retention of backups for limited periods.

Backups may contain personal data until overwritten or deleted in the normal backup cycle.

10. Incident Response

Stratum1 maintains procedures for identifying, assessing, responding to and documenting security incidents and suspected personal data breaches. Incident response may include:

• triage and containment;
• technical investigation;
• remediation and recovery;
• assessment of affected systems and data;
• notification of customers, controllers, authorities or data subjects where legally required;
• post-incident review and improvement.

Personnel are expected to report suspected incidents promptly.

11. Data Minimisation, Retention and Deletion

Stratum1 aims to process personal data only to the extent necessary for the relevant purpose. Deletion and retention controls may include:

• user/customer deletion of spaces and content;
• account deletion workflows;
• limited retention of raw processing files, such as source files used for conversion workflows;
• limited retention of logs and security data;
• deletion or overwriting of backups according to backup cycles;
• anonymisation or aggregation where appropriate.

Where deletion cannot be immediate due to backups, security, legal obligations or technical constraints, data remains protected until deletion or overwriting.

12. Real-Time Communication Controls

For voice, audio, video, chat, presence and similar real-time features, measures may include:

• transport encryption according to the relevant protocol;
• real-time processing without permanent audio storage unless required for a specific feature or legal reason;
• pseudonymised or technical session identifiers where feasible;
• access limited to users present in the relevant space or authorised session;
• use of specialised communication providers where necessary.

13. AI Feature Controls

For AI-assisted features, measures may include:

• limiting data sent to AI providers to what is necessary for the requested feature;
• use of API-based provider arrangements and data processing terms where available;
• reduced retention or zero-data-retention configurations where technically available and enabled;
• warnings to users not to submit unnecessary sensitive or confidential data;
• logging and monitoring for abuse prevention, debugging and service reliability;
• user responsibility to review AI outputs before publication or reliance.

14. External Content, Gates and iframe Controls

For external content and Gates, measures may include:

• blocked-by-default external media where required;
• click-to-activate interaction before loading external content;
• consent or privacy settings for external media categories;
• server-side preview generation where used;
• iframe sandboxing or technical restrictions where feasible;
• user obligations prohibiting unlawful embedded content or unlawful tracking.

Once a user activates external content, the external provider may receive data directly and is generally responsible for its own processing.

15. APIs, MCP, Plugins and Integrations

For APIs, MCP access, plugins, vibes and integrations, measures may include:

• authentication and token-based access;
• token expiry, revocation or regeneration mechanisms;
• permission and scope checks;
• rate limiting and abuse prevention;
• logging of API and integration activity;
• restrictions on plugin or vibe access to unrelated spaces or account data;
• monitoring for suspicious or excessive activity;
• ability to suspend or revoke access where necessary.

External tools connected by users are outside Stratum1’s direct technical control after data has been transmitted to them.

16. Vendor and Subprocessor Management

Stratum1 uses service providers and subprocessors where necessary to provide the Services. Measures may include:

• selection of reputable cloud, infrastructure, payment, communication, email, AI and support providers;
• review of provider privacy, security or data processing terms;
• use of data processing agreements where required;
• use of Standard Contractual Clauses or other safeguards for third-country transfers where required;
• maintaining a subprocessor list for B2B customers where Stratum1 acts as processor.

17. Business Continuity

Stratum1 uses cloud-based infrastructure and provider-level capabilities to support availability and resilience. Business continuity measures are proportionate to company size and service maturity and may include infrastructure monitoring, backups, provider redundancy, incident response, manual recovery procedures and emergency communication channels.

18. Regular Review

The TOMs are reviewed and updated periodically or when material changes occur in the Services, infrastructure, risk profile or legal requirements.