This page describes how DynamoOS protects customer data. Every statement here describes something that is in place in the product or in our operations, and the page changes when the platform does.
1.At a glance
| Area | What is in place |
|---|---|
| Access | Role-based permissions, per-company access and an activity history in every workspace |
| Sign-in | Two-factor authentication, single sign-on and SCIM provisioning, set up by the customer with its identity provider |
| Separation | One workspace per customer, with its own database and storage area |
| Encryption | HTTPS (TLS) for every connection; credentials encrypted or hashed; backups encrypted with AES-256 |
| Backups | Daily automatic backups, kept for up to twelve months |
| Monitoring | A public status page built from real health checks and declared incidents |
2.Access control
2.1Each workspace uses role-based permissions: what a user can see and do depends on the roles they have. Access can also be limited by company. Activity history shows who changed what.
2.2Subscription rules and Dynamo AI can only remove access, never add it. What a user cannot open, Dynamo AI cannot use for that user.
2.3Dynamo staff access to workspaces is limited to what is needed to run and support the service, and operator actions are recorded in an audit trail.
3.Identity and sign-in
- Password sign-in with account lockout after repeated failures.
- Two-factor authentication for password sign-in, with a limit on wrong codes.
- Single sign-on with Microsoft Entra ID, Google Workspace, or any OpenID Connect provider, with the option to enforce it for a domain. Providers that only support SAML connect through an OpenID Connect broker. Single sign-on uses the authorization-code flow with PKCE, validates the signed identity token and binds the identity to the account on first use.
- SCIM 2.0 provisioning and deprovisioning of users and groups. Deprovisioning ends open sessions.
- Service accounts for integrations, with API keys that can be rotated and no password sign-in.
- Break-glass accounts, so that an organization is never locked out.
3.1Single sign-on and SCIM work with the customer’s own identity provider, and the customer’s administrator configures them. Their availability and policies are the customer’s responsibility.
4.Workspace separation
4.1Every customer has its own workspace with its own database and storage area. Files are stored under a prefix that is specific to the workspace, and keys that point outside it are refused. Dynamo AI’s index, embeddings, conversations and drafts live in the workspace’s own database and nowhere else.
5.Encryption and credentials
5.1Every connection between your browser and the website, your workspace or our administration system is encrypted with HTTPS (TLS).
5.2Passwords are stored in hashed form. Other credentials, such as keys and secrets for integrations, are stored encrypted per workspace. Entitlements that control which apps a workspace may use are digitally signed. Credentials never reach the browser through file links, and exports never contain passwords or credentials.
5.3Backups are encrypted with AES-256 and sealed so that any change is detected before a restore.
6.Files and storage
6.1Storage buckets are private. A file is released only after a permission check, through a short-lived signed link, and the link carries the file name so that scripts and HTML always download instead of rendering in the browser.
6.2Uploads are checked for content type and size. Executables, installers and scripts are refused whatever their name. Each object has a stored checksum and uploads are verified, files keep earlier versions, and deleted files go to a trash that is purged after a retention period (30 days by default).
6.3Malware scanning works when a scanner is connected, and fails closed: an upload is refused if the scanner cannot be reached.
6.4File events (upload, download, share, delete, restore) are logged and kept for 365 days. Public links are off unless allowed, and they expire.
7.Backups and recovery
7.1Every workspace is backed up automatically every day. Backups are encrypted (AES-256) and integrity-checked, and restores are tested into a scratch copy. Copies are kept for up to twelve months: daily copies for 7 days, weekly copies for 4 weeks and monthly copies for 12 months.
7.2Restores are carried out by our operators on request, from the most recent suitable backup.
8.Availability and incidents
8.1The public status page is built from real checks and from incidents that our operators declare. A component without recent data shows “No data”, never “Operational”.
8.2Incidents are published with updates until they are resolved, and every operator action is audited. The Service Level Agreement sets out our support, incident and maintenance commitments.
9.Audit trail
9.1Operator actions in our administration system are recorded in an audit log: provisioning, subscription changes, backups, incidents and deletion. Deleting a workspace requires two different operators and is never carried out by a scheduler. Within a workspace, administrators have the activity history and file event log.
10.Updates and vulnerability management
10.1A DynamoOS release is a closed, pinned set of software. Nothing in it looks for, downloads or installs updates by itself. A release changes only when the platform owner builds, signs off and installs a new package. Upstream usage telemetry and update checks are switched off.
10.2Security fixes are released deliberately. Dependencies are checked against published security advisories before a release is cut, and the results decide when the next release is made.
11.Where data is kept
11.1The platform runs on servers that Dynamo operates, in Germany. Storage for workspace files is set per workspace. Choosing a storage location is a technical setting and is not by itself a statement about data residency or compliance.
12.ZATCA e-invoicing
12.1Dynamo Finance includes e-invoicing capability for ZATCA Phase 2, which we tested against ZATCA’s developer sandbox. This is a product capability. It is not a certification, approval or accreditation by ZATCA, and it goes live for a customer only after that customer completes its own onboarding on the ZATCA portal.
13.Responsible disclosure
13.1If you believe you have found a vulnerability, write to security@dynamoos.com. Our contact details and policy are also published at https://www.dynamoos.com/.well-known/security.txt.
13.2Please give us a reasonable time to fix a problem before you disclose it, do not access or change data that is not yours, do not degrade the service, and stop and tell us if you reach personal data. We acknowledge reports within 3 business days and keep you informed until the problem is fixed.
13.3We will not pursue legal action against anyone who reports a vulnerability in good faith and follows these steps, and we do not treat such a report as a breach of our Acceptable Use Policy.
14.What the customer is responsible for
14.1Security is shared. Customers choose their administrators and roles, should enable single sign-on or two-factor authentication, should remove access promptly when people leave (SCIM can do this automatically), should keep their devices and networks secure, and should keep their own copies of data they need by using the export function.
Company details
- Company
- DYNAMO
- Incorporated in
- United Kingdom
- Sales and general e-mail
- sales@dynamoos.com
- Privacy e-mail
- privacy@dynamoos.com
- Security e-mail
- security@dynamoos.com