Governance

How we protect your data

A plain-language overview of where customer data lives, who can access it, and the engineering and operational practices that keep it safe.

Last updated May 6, 2026
This page is informational, not a legal document. It is intended as a general overview of how we govern data, security, and privacy at Dime Software. For binding terms, see our Privacy Policy, Terms of Service, and Cookie Policy.

Hosting and infrastructure

Dime.Scheduler runs on a tier-1 European cloud platform certified under ISO 27001, ISO 27017, ISO 27018, ISO 27701, SOC 1, SOC 2 Type 2, and SOC 3, and aligned with the GDPR. These certifications cover the underlying infrastructure on which our service runs and are independently auditable on the provider's trust portal. See Compliance posture for how Dime Software's own practices build on top of those controls.

Where your data lives

Customer data is hosted across multiple regions inside the European Union as part of our disaster recovery and business continuity plan. Data is replicated and backed up only between EU regions and never leaves EU boundaries.

How data is protected

Encryption

All traffic between your browser, our APIs, and back-office integrations is encrypted in transit using TLS 1.2 or higher. Data at rest is encrypted using industry-standard algorithms with provider-managed keys.

Tenant isolation

Each customer has their own tenant within Dime.Scheduler. Access controls keep every tenant separate, so customers only ever see their own organisation's data, configuration, and activity.

Data minimization

Dime.Scheduler is designed to be a scheduling layer on top of a customer's back-office system (for example, Microsoft Dynamics 365 Business Central). The master records that customers care about, such as resources, jobs, customers, and items, live in the back-office system. We hold only the operational scheduling data needed to run the planning board.

Authentication and access

How users sign in

Users can sign in with a username and password, or with single sign-on through Microsoft Entra ID (Azure AD). Customers using Entra ID inherit their own identity provider's policies, including MFA and conditional access.

Roles and sessions

Dime.Scheduler uses role-based access control so that different users within the same customer tenant can be granted different levels of access to the planning board and its data. Inactive sessions time out automatically.

Customer audit trail

Customer administrators can review an in-application audit trail of meaningful actions taken within their own tenant. Audit log entries are retained for at least 90 days, and customers can request an export of their audit log at any time.

Internal access by Dime Software staff

  • Access to production systems is restricted to a limited, named set of Dime Software staff.
  • Multi-factor authentication is required for all production access.
  • Production access is audit-logged.

In addition:

  • All staff sign confidentiality agreements as part of their employment.
  • All staff complete security awareness training.
  • A documented onboarding and offboarding process governs how access is provisioned when staff join and revoked when staff leave.
  • Production access rights are reviewed periodically to verify that only the people who still need them retain them.
  • Staff workstations are full-disk encrypted, run endpoint detection and response (EDR), and automatically lock when idle.

Backups and resilience

Customer data is backed up daily. Restore procedures are tested periodically to verify backups are usable. Backups remain inside the EU.

Application security and engineering practices

Beyond the infrastructure-level controls described above, Dime Software runs a deliberate set of engineering and operational practices that keep Dime.Scheduler safe to use, predictable in operation, and recoverable when something does go wrong.

Secure development

  • Every code change is peer-reviewed before being merged.
  • Automated tests run in continuous integration before any deployment.
  • Dependencies are continuously scanned for known vulnerabilities.
  • The codebase is automatically scanned for security and quality issues.
  • Development, staging, and production run as separate environments.
  • Secrets and credentials are managed in a secure vault and are never committed to source code.
  • Deployments are reviewed and can be rolled back if a regression is detected.
  • All API endpoints are authenticated. There are no anonymous data endpoints.

Application-level protections

  • Database queries use parameterised statements; user-controlled input is never concatenated into SQL.
  • Output is escaped by default to prevent cross-site scripting (XSS).
  • State-changing requests are protected against cross-site request forgery (CSRF) using anti-CSRF tokens.
  • Session cookies are signed and issued with the Secure and HttpOnly flags so they cannot be read or transmitted insecurely.

Operational security

  • Production activity is logged and monitored, with alerting on anomalous behaviour.
  • Operating systems, runtimes, and dependencies are patched on a defined cadence, with critical security updates prioritised.
  • Disaster recovery and restore procedures are exercised periodically, not just assumed to work.
  • The application sits behind a web application firewall, with rate limiting and abuse detection enabled.

Incident response and testing

  • A documented incident response process defines who triages an incident, who decides on customer notification, and how communication happens.
  • Dime.Scheduler is subjected to third-party penetration testing on at least an annual basis. A summary of findings can be shared with customers under NDA on request.

Subprocessors

The Dime.Scheduler application itself uses no subprocessors beyond the hosting platform that runs the service. Customer scheduling data is not shared with, or sent to, any other third party.

Marketing and presales

Contact details that visitors provide on our website (for example, to request a demo or subscribe to our newsletter) are stored separately from the product, in:

  • Microsoft Dynamics 365: used as our CRM for sales and customer relationship management.
  • Mailerlite: used to send newsletters to subscribers. Mailerlite is established in Lithuania and operates under the GDPR.

These systems only ever contain prospect or contact information collected through our website. They never receive product data or end-customer data from the Dime.Scheduler application.

Notification of changes

If we ever introduce a new subprocessor that would process customer data, customers will be notified before that change takes effect, so they have an opportunity to review and respond.

Compliance posture

Security and privacy are core to how we build and run Dime.Scheduler. The service runs on a tier-1 European cloud platform that is independently certified under internationally recognised standards including ISO 27001 and SOC 2 Type 2 (see Hosting and infrastructure for the full list), and Dime Software operates a defined set of engineering, operational, and access controls on top of it (see Application security and engineering practices).

Our internal practices are organised around the same control areas that underpin those frameworks: access management, secure development, logging and monitoring, incident response, and business continuity. Dime Software does not yet hold its own ISO 27001 or SOC 2 certification, but we operate as if we did, and we are happy to walk security and procurement teams through our controls in detail.

As a Belgian company, Dime Software operates under the EU General Data Protection Regulation (GDPR) and applies its principles in how we collect, process, and retain personal data: lawful basis, purpose limitation, data minimization, and the rights of data subjects. See our Privacy Policy for the formal statement of these rights and how to exercise them.

Privacy by design

Privacy and data minimization are deliberate product choices, not afterthoughts. Dime.Scheduler is intentionally built as a thin scheduling layer on top of a customer's back-office system: the master records customers care about (resources, jobs, customers, items) stay in the system of record, and we hold only the operational data needed to run the planning board. That keeps the volume and sensitivity of data we process on customers' behalf small by design.

Data Processing Agreement

A Data Processing Agreement (DPA) covering how we process personal data on behalf of customers is available on request. Email [email protected] and we will send it over.

Security controls

The summary below lists the controls we run, grouped by the control areas common to ISO 27001 and SOC 2. It is intended as a procurement-friendly view; each item is described in more depth in the relevant section of this page.

Identity and access management

  • Multi-factor authentication is required for all production access by Dime Software staff.
  • Production access is restricted to a limited, named set of staff and is audit-logged.
  • Role-based access control governs what users can do within their tenant.
  • Inactive sessions time out automatically.
  • Customers can sign in with single sign-on through Microsoft Entra ID, inheriting their own MFA and conditional access policies.
  • Production access rights are reviewed periodically so only the people who still need access retain it.
  • A documented onboarding and offboarding process governs how staff access is provisioned and revoked.

Secure software development

  • Every code change is peer-reviewed before being merged.
  • Automated tests run in continuous integration before any deployment.
  • Dependencies are continuously scanned for known vulnerabilities.
  • The codebase is automatically scanned for security and quality issues.
  • Development, staging, and production run as separate environments.
  • Secrets and credentials are managed in a secure vault and are never committed to source code.
  • All API endpoints are authenticated. There are no anonymous data endpoints.

Application-level protections

  • Database queries use parameterised statements; user input is never concatenated into SQL.
  • Output is escaped by default to prevent cross-site scripting (XSS).
  • State-changing requests are protected against cross-site request forgery (CSRF) using anti-CSRF tokens.
  • Session cookies are signed and issued with the Secure and HttpOnly flags.

Logging, monitoring, and detection

  • Production activity is logged and monitored, with alerting on anomalous behaviour.
  • An in-application audit trail captures meaningful actions inside each customer tenant. Audit log entries are retained for at least 90 days and can be exported on request.
  • The application sits behind a web application firewall, with rate limiting and abuse detection enabled.

Vulnerability and patch management

  • Operating systems, runtimes, and dependencies are patched on a defined cadence, with critical security updates prioritised.
  • Dime.Scheduler is penetration tested by an independent third party on at least an annual basis, with summaries available to customers under NDA on request.
  • A coordinated vulnerability disclosure channel is published (see Reporting a vulnerability).

Data protection

  • All traffic between browsers, APIs, and back-office integrations is encrypted in transit using TLS.
  • Data at rest is encrypted using provider-managed keys.
  • Per-tenant access controls keep each customer's data, configuration, and activity separate.
  • Data minimization is built into the product: only operational scheduling data is held, not the customer's master records.
  • Hosting and backups stay within the European Union.

Business continuity and resilience

  • Customer data is backed up daily, and restore procedures are tested periodically.
  • The service is deployed across multiple EU regions for disaster recovery.
  • Deployments can be rolled back if a regression is detected.
  • Disaster recovery procedures are exercised periodically rather than assumed to work.

Governance, people, and process

  • All staff sign confidentiality agreements as part of their employment.
  • All staff complete security awareness training.
  • Staff workstations are full-disk encrypted, run endpoint detection and response (EDR), and automatically lock when idle.
  • A documented incident response process defines who triages an incident, who decides on customer notification, and how communication happens.
  • Subprocessor changes are notified to customers before they take effect (see Subprocessors).

Data lifecycle and offboarding

Because Dime.Scheduler sits on top of a back-office system, the master data that drives the planning board remains in the customer's own back-office system at all times. When a customer ends their subscription:

  • The customer's back-office system, which holds the master data, is unaffected.
  • Operational scheduling data held by Dime.Scheduler is deleted within 90 days after the end of the contract.

Reporting a vulnerability

If you believe you have found a security vulnerability in Dime.Scheduler or our website, please report it to [email protected]. Please include enough detail to reproduce the issue, and give us a reasonable amount of time to investigate and fix it before any public disclosure.

Service status

The current status and uptime history of Dime.Scheduler is available on our public status page at status.dimescheduler.com.

Want more detail?

If you are evaluating Dime.Scheduler and need more specific information for a security review or procurement questionnaire, contact us at [email protected] and we will be happy to provide it under NDA where appropriate.