Beta Delivery Zone is in private beta and not yet open to customers — public launch coming soon.
Legal

Security Policy

Last updated: 2026-05-17 Effective: 2026-05-13

Security Policy — Delivery Zone

Version: 1.1 Last updated: 2026-05-17 Effective date: 2026-05-13

We take the security of our platform and your data seriously. This page describes the technical and organisational measures we have in place. We aim to be transparent without disclosing details that would assist attackers.

1. Our Security Approach

Security is a core design concern, not an afterthought. We apply the principle of least privilege, use encryption by default, and follow security-by-design practices in our development process. We aim to comply with GDPR Article 32 obligations to implement "appropriate technical and organisational measures" to protect personal data.

2. Infrastructure Security

  • The API is hosted on cloud infrastructure designed to separate public application traffic from database and internal services.
  • All connections to the API and dashboard use TLS 1.2 or higher. Unencrypted HTTP connections are redirected to HTTPS.
  • Database access is restricted to authorised application and administrative connections and protected by authentication, TLS, and provider-level access controls.
  • Application containers are run as non-root users where technically possible.
  • Infrastructure secrets (database credentials, signing keys, API keys for third-party services) are managed via a secrets management service and are not stored in source code or version control.

3. Authentication and Secrets

  • Passwords: Stored as salted bcrypt hashes. Plaintext passwords are never stored, logged, or transmitted after initial receipt.
  • API key secrets: Hashed using bcrypt before storage. The plaintext secret is shown once at creation and cannot be recovered by us or by you.
  • Refresh token storage: Refresh token values are hashed (SHA-256) before being stored. Plaintext token values are never persisted.
  • Session management: Authentication uses HttpOnly, Secure cookies (dz_access and dz_refresh) with SameSite controls to reduce cross-site scripting (XSS) exposure and cross-site request forgery (CSRF) risk. See the Cookie Policy for exact cookie attributes.
  • Refresh tokens: Rotated on each use — the existing token is revoked and a new one is issued. Revoked on logout. Refresh tokens expire after 30 days; access tokens expire after 1 hour.
  • Email verification: Required for all new accounts before access is granted.
  • Multi-factor authentication (MFA): TOTP-based MFA is available for all accounts. Platform administrator accounts require MFA.

4. Access Controls

  • Role-based access control (RBAC) is enforced at the API level for all dashboard operations.
  • All authenticated endpoints verify organisation membership and permission level before executing.
  • Platform administration access is separately gated and is not accessible via the standard customer API surface.
  • API keys are scoped to an organisation and can be revoked individually.

5. Logging and Monitoring

  • Structured logs are generated for all significant security events: logins, token issuance and revocation, API key creation and revocation, failed authentication attempts.
  • Logs do not contain: plaintext passwords, full API key secrets, unmasked payment card data, or end-consumer personal data beyond what is listed in our Privacy Policy.
  • Rate limiting is applied to authentication endpoints (login, registration, password reset, MFA verification) and to the public delivery check API to limit brute-force and abuse attempts.
  • Logs are retained for up to 12 months.

6. Data Protection in Transit and at Storage

  • All data in transit between clients, the API, and managed services is encrypted via TLS.
  • Sensitive configuration values are stored as environment secrets outside the application container, managed via a secrets management service.
  • ASP.NET Data Protection keys (used for cookie and token encryption) are stored in a protected location separate from the application container.
  • Where supported by our infrastructure providers, storage-level encryption at rest is enabled for managed databases and storage services.

7. Responsible Disclosure

If you discover a security vulnerability in our service, please report it to us privately before disclosing it publicly. We ask for a reasonable disclosure window (at least 14 calendar days) to assess and remediate the issue.

Security contact: security@deliveryzone.fi

Please include:

  • A description of the vulnerability.
  • Steps to reproduce it.
  • The potential impact, in your assessment.
  • Your contact details (optional).

We do not take legal action against good-faith security researchers who comply with this policy, act lawfully, avoid privacy violations, avoid service disruption, and give us a reasonable opportunity to investigate and remediate. This does not authorise access to other customers' data, persistence, social engineering, spam, physical attacks, destructive testing, service disruption, or public disclosure before we have had a reasonable opportunity to investigate and remediate.

We do not offer a bug bounty programme at this time.

8. Customer Security Responsibilities

You are responsible for:

  • Keeping your account credentials (email and password) confidential.
  • Enabling MFA on your account for additional protection.
  • Keeping your API key secrets confidential and not exposing them in public code repositories, frontend JavaScript, or other publicly accessible locations.
  • Revoking API keys immediately if you suspect they have been compromised.
  • Notifying us promptly at security@deliveryzone.fi if you believe your credentials or keys have been compromised.
  • Implementing secure coding practices in your API integration (HTTPS-only, secrets management, input validation on your side).

9. Incident Response

We maintain internal procedures for assessing and responding to suspected security incidents and personal data breaches.

If we become aware of a personal data breach, we will assess it and, where legally required under GDPR, notify the relevant supervisory authority and/or affected users. Where such notification is required, we aim to make it without undue delay and, where feasible, within 72 hours after becoming aware of the breach. If initial notification cannot include full details, we will supplement it as further information becomes available.

We assess each situation based on the facts available at the time. Not every security event is a personal data breach, and not every breach requires individual notification under GDPR.

10. No Guarantee of Perfect Security

Despite our efforts, no system connected to the internet is completely immune to security threats. We implement reasonable technical and organisational measures but cannot guarantee absolute security or zero downtime in the event of an attack.

In the event of a personal data breach that poses a risk to individuals' rights and freedoms, we will fulfil our notification obligations under GDPR Article 33 (supervisory authority) and Article 34 (data subjects), as appropriate.

11. Contact