Contact Info

Log in
Sign up

Security Policy

Legal

Table of Contents

Last updated: 10 August 2026

Keeping your data secure is important to us. This Security Policy describes the technical and organizational measures Specifique Norge AS ("Diggle," "we," "us") uses to protect the confidentiality, integrity, and availability of the data you trust us with. It is separate from, and doesn't form part of, our Terms & Conditions — for our contractual commitments, see the Terms and our Privacy Policy.

Openness and shared responsibility

Diggle is built to be simple and accessible, including features like shareable join links and codes. You can control the level of access security for each session you run — see "Levels of security when joining a Diggle" in our Privacy Policy. We can't take responsibility for exposure that results from a less secure option you've chosen, or from links or access codes you've shared with people you didn't intend to give access.

People and access

  • Access to Diggle's systems and to data about Users is granted on a need-to basis and revoked as soon as it's no longer needed.
  • Everyone with system access must keep credentials confidential, use two-factor authentication and password-protected SSH keys where applicable, keep device firewalls enabled, and lock their screen when stepping away.
  • Employee credentials used for work are kept in a password manager.

Our CTO owns security strategy, threat planning, and incident response for Diggle.

Data processing and hosting

Scaleway (France) hosts our application, database, backups, and user-uploaded images. Scaleway is ISO 27001:2013, HDS, and ISO 50001:2018 certified, holds Tier 3 Uptime Institute certification, and is GDPR- and SWIPO-compliant. DigitalOcean (US) hosts our landing page; the only personal data processed there is access-log IP addresses, deleted every two weeks.

For AI Features, we use Scaleway's generative-AI infrastructure (also hosted in France) — the underlying model is an open-weight model originally developed by OpenAI, but it's hosted and operated by Scaleway, and OpenAI doesn't receive prompts or generated content under our current setup. We may use additional or different AI providers as these features develop — see our sub-processor list for the current, up-to-date list. Requests to our AI sub-processor are encrypted in transit (TLS), and Scaleway applies its own access controls, consistent with GDPR. We do not use data processed through AI Features to train AI models, and we don't permit our AI sub-processors to do so either.

Encryption

  • Data in transit is encrypted using TLS 1.2 or higher; we maintain an A+ rating from SSL Labs.
  • CloudFlare, Google Analytics (currently deactivated), GSuite, Sentry, and Slack all encrypt data at rest.
  • Stripe encrypts card numbers at rest with AES-256, with decryption keys stored separately from Stripe's primary infrastructure. Card details are held by Stripe, a Level 1 PCI-compliant processor — we don't store card numbers ourselves.
  • User passwords are hashed and salted using bcrypt; we can't see your password, and you reset it yourself by email if needed.

Backups and availability

Backups run continuously, with automatic failover, on a high-availability managed Postgres database (Scaleway). Data is retained in backups for up to 21 days after deletion. We reserve the right to disconnect the Services for maintenance or upgrades; our intention is to give advance notice and to schedule this during low-traffic periods where possible.

Engineering practices

  • Enforced code conventions and static code analysis;
  • established frameworks and practices to guard against common attack vectors (XSS, CSRF, SQL injection);
  • continuously updated dependencies and libraries;
  • continuous integration, with the ability to roll back releases quickly; and
  • a yearly security review of the codebase.

Ongoing security practices

  • Access-transfer tooling reviewed at least twice a year;
  • security training for the team at least annually;
  • access revoked promptly when someone leaves the team;
  • firewall configuration checked twice a year; and
  • external penetration testing and vulnerability scanning performed as needed, and at a minimum once every two years.

Security incidents

If we become aware of a security incident affecting your data, we'll take appropriate steps to contain and assess it as soon as possible, and will notify affected customers through relevant channels (typically email) as soon as possible, consistent with applicable law and our contractual obligations. All security incidents are documented and reviewed internally afterward to reduce the chance of a repeat.

Changes to this policy

We review this Security Policy periodically and update it as our practices, infrastructure, or applicable law change. Material changes will be reflected here and, where relevant, referenced in our Privacy Policy.

Contact

Questions about this policy, or to report a suspected security issue: [email protected].