Security Policy

Last updated: 11 September 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/IEC 27001:2022, 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.
• Cloudflare, Google Workspace, and Slack provide encryption at rest for relevant hosted data and services.
• 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 PCI DSS Level 1 service provider — 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.
• The disaster-recovery storage used at Hetzner is encrypted at rest.

Backups and availability

Database backups are created daily on Scaleway. Backup copies may retain deleted data for up to 7 days. The production database uses a high-availability managed PostgreSQL setup with automatic failover. Separately, an encrypted disaster-recovery and standby copy is refreshed daily to Hetzner infrastructure in Helsinki, Finland. 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].