Security at ONETEEM

Version 2.0. Effective 27.07.2026. Next review 27.07.2027.

Protecting customer data is a core obligation, not a feature. This page sets out what we do, where your data lives, and what we do not yet have. We have kept it specific on purpose, because a security page full of qualifiers is of no use to the person reviewing it.

If you are running a security or procurement review, our trust centre collects this page together with our privacy policy, our subprocessor list and our contractual documents.

Scope

This applies to all five ONETEEM service lines:

• TEEMAPPS, the Marketplace apps we publish
• TEEMDEV, private and custom Forge apps and AI agents we build for customers
• TEEMFORCE, consulting, delivery and migration work, including Data Center to Cloud
• TEEMDESK, managed services, governance and licensing
• TEEMLEARN, training and enablement

These service lines touch customer data in very different ways. The table below sets out which controls apply where, so you can skip to the part that concerns your engagement.

What we access, by service line

What we commit to

• We collect and process only what is needed to deliver the feature or service you asked for
• We never sell customer data, never use it for advertising, and never use it to train AI models
• You can disconnect any integration and request deletion at any time
• We tell you plainly what we have not yet certified, rather than implying more than we can evidence

Where your data is processed

Apps. Our Marketplace and Forge apps run on Atlassian's platform. App data stays within Atlassian's hosting and inherits Atlassian's residency, isolation and encryption controls. We do not copy app data into our own systems. Where a feature needs to call a service outside Atlassian, that service and its region are named in the app's documentation before you install.

Consulting and managed services. We work inside your environment using accounts you issue. Production data stays in your systems. Where a migration requires an export, the location, encryption and deletion of that export are agreed in writing before work starts, and it is deleted within 30 days of migration sign off.

Our own business systems. Project records, contracts and correspondence are held in Atlassian Cloud, Google Workspace and Odoo, with hosting and edge security from IONOS and Cloudflare. Locations and transfer mechanisms for each are on our subprocessors page. Customer production data is not stored in these systems.

Delivery locations. We deliver from Germany and, through ONETEEM TUNISIA SUARL, from Tunisia. Tunisia is a third country under the GDPR with no adequacy decision, so those transfers are governed by a data processing agreement and the standard contractual clauses approved by the European Commission, supported by encryption and access limited to named personnel. For providers in the United States we rely on the EU US Data Privacy Framework or the standard contractual clauses. If your requirements restrict processing to the EEA, we can staff your engagement from Germany only.

Certifications, and what we have instead

We do not hold SOC 2 or ISO 27001 certification today. We would rather say that than let a reader assume otherwise.

Our controls are modelled on ISO 27001 Annex A, the Atlassian Marketplace security requirements for cloud apps, and GDPR Articles 25, 28 and 32. Certification is on our roadmap and we will publish the target date here once an audit window is booked.

On request we provide a completed security questionnaire, our subprocessor list, our data processing agreement, and evidence of the specific controls described on this page.

Governance and people

Security is owned by the Managing Director and reviewed at least annually. Roles for security, privacy and incident response are documented and named. Everyone with access to customer data signs a confidentiality agreement and completes security training at onboarding and annually. Background checks are performed where permitted by law in the relevant jurisdiction.

Access management

• Role based access and least privilege by default
• Multi factor authentication is mandatory on every account with access to customer data or production systems, not only privileged ones
• Single sign on across our own business systems
• Elevated access is granted for a defined period, logged, and revoked automatically
• Access is reviewed quarterly and on every role change
• Secrets are held in a managed vault. No credentials in source control, ever

Access during TEEMFORCE and TEEMDESK engagements

Consulting and managed services put our people inside your systems, so we handle that access explicitly.

• We work under accounts you issue and control, so you can see and revoke our access at any time
• Only named consultants assigned to your engagement receive access. We give you the list and tell you when it changes
• We do not copy production data out of your systems unless it is required for the agreed work and you have approved it in writing
• Access is revoked within one business day of the engagement ending or a consultant leaving the team
• Work on customer systems is performed from managed devices with disk encryption, screen lock, endpoint protection and current patches
• Every consultant is bound by confidentiality obligations that survive the engagement

Secure development

Threat modelling on new features that change how data is accessed. Secure coding standards and mandatory peer review before merge. Static analysis, dependency scanning and secrets scanning on every change. Separate development, staging and production environments with change approval and a rollback plan. Forge apps request the narrowest scopes that deliver the feature, and any scope increase is called out in release notes.

Platform safeguards

Cloud native architecture using the provider's isolation, encryption and monitoring controls. Hardened configurations and least privilege service accounts. Default deny on egress for components that handle customer data, with an allow list where an external call is required. Content Security Policy and secure headers on web surfaces.

Encryption

TLS 1.2 or higher in transit, with TLS 1.3 preferred and older protocols disabled. AES-256 at rest for databases, backups and object storage. Keys are managed by the platform provider's key management service and rotated at least annually or immediately on suspected compromise.

Logging and monitoring

Centralised, time synchronised logs for authentication, authorisation, administrative actions and access to customer data. Security and audit logs are retained for 12 months. Operational logs are retained for 90 days. Alerting on anomalies and abuse indicators, with audit trails for privileged operations.

Vulnerability and patch management

We scan code, dependencies and images continuously, and we meet the remediation timeframes in the Atlassian Security Bug Fix Policy for Marketplace apps:

• Critical: 14 days from verification
• High: 28 days
• Medium: 42 days
• Low: next maintenance cycle

Our internal targets are tighter than this and we routinely ship critical fixes within days. We publish the figures above because they are the commitment we will hold in every circumstance, including holiday periods. An emergency change process covers urgent fixes outside the normal release cycle.

Testing and independent assessment

We run internal security testing on critical paths before each release, and we commission independent third party assessment when an app introduces significant new data handling. Every app we publish passes Atlassian's security review before release, and we participate in Atlassian's partner security assessment activities for Marketplace and Forge apps.

Our current Marketplace partner tier does not require a public bug bounty programme. We accept vulnerability reports directly under the process below, and we will join the Atlassian Marketplace Bug Bounty Programme when our tier requires it. Findings are tracked to closure under the timeframes above.

Subprocessors

Our current subprocessors, their purpose, location and transfer mechanism are listed on our subprocessors page. We notify customers at least 30 days before adding or replacing a subprocessor that handles personal data.

Continuity and recovery

Services run on resilient cloud infrastructure with multi availability zone capability. Application data and configuration are backed up daily and backups are retained for 30 days. Restoration is tested at least annually. Our targets are a recovery time objective of 8 hours and a recovery point objective of 24 hours. Where your service agreement sets different targets, that agreement takes precedence.

Incident response

We maintain a documented plan covering triage, containment, eradication, recovery and communication, with on call coverage for critical incidents. If an incident affects your data we notify you within 48 hours of confirming it, with what we know, what we are doing, and what you may need to do. Where we act as processor we support your regulatory notifications, including the 72 hour deadline under GDPR Article 33. Every significant incident gets a written post incident review with corrective actions tracked to closure, and we share the review with affected customers.

Privacy and the GDPR

ONE T.E.E.M. GmbH is established in Germany and subject to the GDPR and the BDSG. In most engagements you are the controller and we are the processor. Our data processing agreement is available on request and forms part of our customer agreement.

Data minimisation and purpose limitation are applied at design time. Optional features that need broader access are off by default and require explicit opt in. We carry out data protection impact assessments where required, and we maintain records of processing under Article 30.

How we handle personal data on our website and in our own business operations is set out in our privacy policy, which also covers your rights, the legal bases we rely on, and retention periods. Privacy questions and data subject requests go to [email protected].

AI and your data

We build AI agents on Atlassian Rovo and Forge, and we use AI assistants in our own development work, so we are explicit about the boundaries:

• Customer data is never used to train AI models, ours or anyone else's
• AI features in our apps process data inside Atlassian's platform using Atlassian's AI services, under Atlassian's terms
• We use Anthropic's Claude in our own development work, for code review, testing and security hardening, under an enterprise agreement that prohibits training on our inputs. Customer production data is not submitted to it
• Where an app feature sends data to an AI service, we name that service and its region in the app's documentation before you install

Retention and deletion

Integration tokens and metadata are kept while the connection is active. On uninstall, disconnection or a verified deletion request, stored connection data and related app records are deleted within 30 days, and removed from backups within 90 days. Consulting and migration exports are deleted within 30 days of sign off. Project records and correspondence are retained for the periods required by German commercial and tax law, set out in our privacy policy, and are not used for any other purpose.

What we need from you

Security is shared. On your side:

• Control who can install and administer apps in your Atlassian sites
• Review the permissions any integration requests before approving them
• Manage user access in your identity provider and Atlassian organisation, and tell us promptly when someone who worked with us leaves
• Keep endpoints patched and use supported browsers
• Report anything suspicious to us immediately

Reporting a vulnerability

Email [email protected] with details and reproduction steps, or use our security and compliance request portal. We acknowledge reports within 2 business days, give you an initial assessment within 5 business days, and keep you updated until the issue is closed.

We will not pursue legal action against you for security research carried out in good faith, provided you avoid privacy violations, data destruction and service disruption, only test against your own instances or accounts, and give us reasonable time to remediate before public disclosure. We are happy to credit you when a fix ships, unless you prefer otherwise.

Changes to this page

We use semantic versioning for app releases and publish release notes for changes that materially affect security or permissions. Material changes to this page are announced through our usual customer channels and recorded below.