Security questions, answered

Yes. Scratcher ApS is certified to ISO/IEC 27001:2022, the international standard for an information security management system (ISMS). The certification is issued by Bureau Veritas Certification under accreditation (FINAS), certificate no. FIHSK27150F, valid until 7 November 2028. We have been certified since November 2022.

Download the certificate (PDF)

The certified scope is the development, sales and support of software for interactive campaigns, marketing and related activities, including the collection of data and permissions. In practice, this covers the Scratcher platform, the campaigns that run on it, our processes and the cloud infrastructure behind them.

Bureau Veritas carries out an external surveillance audit every year and a recertification audit every three years. Before each external audit, we run an internal audit of all ISMS processes and a management review.

Yes. Our Statement of Applicability is mapped to the controls in ISO/IEC 27001:2022 Annex A (ISO/IEC 27002:2022) and shows which controls apply and how they are implemented. Enterprise customers can request it.

Yes. We process personal data in line with the EU General Data Protection Regulation (GDPR). For campaign data, you are the data controller and Scratcher is the data processor (Article 28), under a data processing agreement (DPA).

No. Our information security is certified to ISO/IEC 27001:2022 instead, and we provide the certificate and the Statement of Applicability as assurance documentation.

Our ISO 27001 certificate and Statement of Applicability cover most audit and vendor assessment needs. If you need an additional audit, we agree on the scope, timing and any costs with you in advance.

You do. You keep all rights to your data (customer data), and we only process it to deliver the service, as described in our terms and the data processing agreement.

Yes. Every customer is covered by our data processing agreement under GDPR Article 28. Enterprise customers can also use a DPA based on the standard contractual template from the Danish Data Protection Agency (Datatilsynet).

We use a small number of carefully selected sub-processors, for example Amazon Web Services (AWS) for hosting and a provider for sending transactional emails. Each sub-processor is bound by a data processing agreement. The current list is in Appendix B of our data processing agreement.

Yes. We notify you at least 14 days before we add or replace a sub-processor that processes your personal data. If you don't accept the change, you can terminate the agreement.

All customer data is stored in the EU. If a sub-processor processes personal data outside the EU/EEA, for example for AI features or bot protection, the transfer is protected by the EU Commission's Standard Contractual Clauses (SCCs) or the EU–US Data Privacy Framework (DPF).

No. We only process your data on your instructions to deliver the service (purpose limitation). We never sell your data or use it for our own marketing.

Yes. You decide which form fields each campaign has and which are required, so you only collect the data you actually need (data minimisation).

You decide the retention period. You can delete participant data at any time or set automatic deletion, for example a set number of days after a campaign ends. The maximum retention period is set out in your data processing agreement.

Yes. You can export participants and leads as CSV at any time, send them automatically to your own systems through our integrations, or fetch them through our REST API (data portability).

Your data is deleted after your subscription ends, in line with our terms and the data processing agreement. Copies in backups are overwritten as the backups roll over. Export anything you want to keep before the subscription ends.

As data controller, you handle requests from participants, such as access, rectification or erasure (GDPR Articles 15–17). You can find, export and delete participant data in the platform, and our team helps you if needed.

All customer data is stored in Amazon Web Services (AWS) data centres in the EU. We do not run servers of our own, so physical and environmental security is handled by AWS, which is certified to ISO 27001, SOC 2 and other recognised standards.

• Network isolation: all servers and databases run in a private network (Amazon VPC) that cannot be reached from the internet.
• Edge protection: only the load balancers (ALB) and the content delivery network (Amazon CloudFront) are public, and they are protected by a web application firewall (AWS WAF).
• Immutable infrastructure: servers run as containers that are never changed by hand. We replace them with new, tested versions, and there is no SSH access.
• Managed databases: databases run on Amazon RDS, a database service managed by AWS.

Yes. All traffic goes through Amazon CloudFront and AWS WAF, which filter malicious requests and absorb large traffic spikes (DDoS protection) before they reach our servers.

Scratcher is a multi-tenant platform. Each customer's data is logically separated by account (tenant isolation), and every request is authorised, so users only see data from the accounts they have access to.

Yes. API calls and changes to our AWS environment are recorded in an encrypted, tamper-evident audit trail (AWS CloudTrail with log file validation), and application logs are collected centrally (Amazon CloudWatch). In your account, you can see what your users have done in the activity log.

We operate the infrastructure together with a specialised DevOps partner that is itself ISO 27001 certified. Partners only get the access their work requires (least privilege).

The platform is checked automatically every 30 seconds from several AWS regions (uptime monitoring). Our operations team is alerted automatically if something goes wrong, and most problems are detected within minutes. Application errors are tracked with error monitoring.

Yes. Automatic abuse detection runs in the background, and campaigns can use bot protection (Cloudflare Turnstile), participation limits, verification codes and blocklists for email addresses and phone numbers.

Yes. All traffic to the platform, the campaigns and the API is encrypted with TLS (HTTPS).

Yes. Databases, files and backups are encrypted at rest with AES-256 through AWS.

Encryption keys are managed by AWS (AWS-managed keys) and are only available to the services that need them.

Credentials for your integrations, such as API keys for your email tool or CRM, are additionally encrypted in the application with AES-256 before they are stored (application-level encryption).

Passwords are never stored in plain text. They are hashed and salted with bcrypt, an algorithm designed for passwords.

Yes. Your team can log in with their Google account (Google SSO).

Yes. Every user can turn on two-factor authentication (2FA) with an authenticator app such as Google Authenticator or Microsoft Authenticator (time-based one-time passwords, TOTP), and recovery codes are provided. Two-factor attempts are rate limited.

Login sessions use secure, HTTP-only cookies and end automatically after a period of inactivity (session timeout). Each user can also sign out of all their other browser sessions.

Yes. Login and two-factor attempts are rate limited to protect against brute-force attacks and password guessing.

Yes. Access is controlled with roles and permissions (role-based access control, RBAC) on two levels:

• Account roles: Owner, Admin, Manager, Analyst and Support, each with different rights to users, billing, campaigns and data.
• Campaign permissions: you can give each person access to specific campaigns and decide what they may do there, for example design, write texts, handle prizes and winners, or only review.

You can see what your users have done in the activity log.

Yes. Our REST API only works over HTTPS, uses personal access tokens and is rate limited. Webhooks from Scratcher are signed with a shared secret (HMAC signature), so you can verify that they come from us.

Only employees who need access for their work, and only when they need it (need-to-know). In your account settings, you decide whether our support team may access your account to help you.

Access follows the principle of least privilege, uses unique user accounts and is reviewed at least once a year. Employees use a password manager, multi-factor authentication where possible and encrypted laptops, and access is revoked as soon as someone leaves (offboarding).

Databases and servers are backed up automatically every day, and at least seven days of backups are kept. Backups are encrypted, stored separately from the production systems in highly durable AWS storage (Amazon S3) and can only be read by administrators. Before any recovery work after an incident, an extra backup is taken first. Restores are tested at least once a year.

We have business continuity and disaster recovery plans (BC/DR) for outages at AWS, outages of the platform and attacks on campaigns. The plans are reviewed and exercised every year. If an outage lasts more than an hour, all customers are informed by email. Our operations team responds to downtime within 1 hour during business hours and within 3 hours outside business hours, with on-call cover around the clock.

Support is included in every subscription. Enterprise customers can agree on specific service levels with us.

We follow a documented incident management process: incidents are reported to our information security manager, assessed, contained, analysed to find the root cause (root cause analysis) and followed up with corrective actions. Every incident is logged and reviewed.

Yes. If a breach affects your personal data, we notify you without undue delay and within 24 hours, and help you with your own notification to the supervisory authority within 72 hours (GDPR Articles 33 and 34).

No breach of the confidentiality or integrity of customer data was recorded in our latest annual review of the information security management system.

Please write to contact@scratcher.io with as much detail as possible. We follow a vulnerability disclosure policy (responsible disclosure), investigate every report and get back to you.

We follow a documented secure software development life cycle (SDLC) based on ISO/IEC 27001:2022 (controls 8.25–8.33). Every feature has an owner who is responsible for security from idea to retirement, and security requirements are defined already in the specification and design phase.

• Security by design and by default: security is built in from the start, and the safest settings are the default.
• Least privilege: people, services and partners only get the access they need, and nothing more.
• Defence in depth: several independent layers of protection, so one failure does not expose data.
• Default deny: access is blocked unless it has been explicitly allowed.
• Zero trust: never trust, always verify. Every request is authenticated and authorised, whether it comes from inside or outside the network.
• Fail securely and assume breach: systems are designed to stay safe if something goes wrong.
• Least functionality: only the features and services that are needed are enabled.
• Distrust external input: all input is validated.

All code is kept in version control (Git), and every change goes through a pull request with peer code review before it is merged. Automated unit, feature and architecture tests run on every pull request, and the architecture tests block unsafe code patterns from being merged. Linting and automated refactoring run on every commit, and design and technical changes are approved by our CTO.

The platform is built on established, actively maintained frameworks (Laravel and Vue) with built-in protection against common vulnerabilities from the OWASP Top 10, such as SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF). All input is validated on the server, and sensitive endpoints are rate limited. Suspicious requests are logged and reviewed.

Yes. Development, test (staging) and production are separate environments with separate access. Changes are tested in staging before they reach production, and our policy is that production data is not copied into development or test environments.

Changes are deployed through an automated CI/CD pipeline that builds a new, versioned container image for every release. Database changes run as a controlled step of the deployment, and because every release is a separate image, we can quickly roll back to the previous version if needed. No single person can change production without review and approval (segregation of duties).

Our source code is kept in private repositories with access control and full version history. Secrets such as passwords and API keys are never stored in the code; they are kept in AWS Secrets Manager and injected at runtime.

We only use well-known, actively maintained open-source libraries from reputable sources. New libraries must be approved before use, versions are locked (lock files) and dependencies are updated continuously (software supply chain security).

Our developers hold a security review every week (vulnerability management). Vulnerabilities found by our team, our tools or reported to us are assessed, prioritised and fixed, and handled through our incident process if needed.

Yes. Our developers follow secure coding guidelines and receive security awareness training when they start and on an ongoing basis.

We run a risk assessment based on likelihood and impact. Risks are reviewed every month, and every risk is reassessed at least once a year (risk management).

Our CTO is the information security manager (ISM), and management approves our information security policies. Policies are reviewed every year.

Our information security management system (ISMS) includes approved policies for, among other things:

• Information security and acceptable use
• Information classification and information transfer
• Access control and cryptography (including key management)
• Supplier relationships and cloud services
• Protection of personal data (PII) and records
• Remote working, clear desk and clear screen, endpoints and removable media
• Logging and monitoring, backup and data retention
• Vulnerability management and vulnerability disclosure
• Use of AI

The policies are approved by management, communicated to all employees and reviewed every year.

Yes. New employees go through background screening before they start, sign confidentiality agreements (NDA) and receive security awareness training when they start and on an ongoing basis.

Scratcher is a remote-first company. Our remote working policy requires secure home offices, screen lock, encrypted devices, protected Wi-Fi (WPA2/WPA3) and VPN on public networks.

Yes. Information is classified by confidentiality, integrity and availability (CIA) and handled according to its level.

Suppliers are assessed for confidentiality, integrity and availability before we use them (supplier risk management). Security requirements are part of our contracts, and suppliers are reviewed regularly.

Our AI features, including Rex, the AI assistant, use large language models (LLMs) from Google Gemini and image models from fal.ai. The providers are assessed in our supplier process, and our AI usage policy covers how AI is used.

Yes. Our AI policy requires human oversight (human in the loop) for important decisions. Changes made with AI happen in the editor, and your team decides when a campaign is published. Rex and the other AI features only make changes when someone on your team asks them to.

By default, campaigns only use functional cookies and storage: cookies that balance traffic between our servers (load balancer cookies), local storage in the browser, for example to remember that someone has already played, and, for pop-ups embedded on your website, cookies that control how often the pop-up is shown. If you add your own tracking, for example Google Tag Manager or the Meta Pixel, it only loads after the participant has given consent in the campaign's cookie banner. If bot protection (Cloudflare Turnstile) is turned on, Cloudflare also processes technical data such as the IP address and browser signals.

Yes. You write your own consent texts and terms, choose which fields are required and can use double opt-in for newsletter sign-ups.

Transactional emails such as prize emails are sent through our email delivery provider. You can send them from your own domain, so participants recognise the sender.

Yes. On Professional and Enterprise plans, campaigns can run on your own web address (custom domain), and emails to participants can be sent from your own domain.

• ISO/IEC 27001:2022 certificate: download it here
• Statement of Applicability (SoA), on request
• Data processing agreement (DPA), including the list of sub-processors
• Answers to your security questionnaire or vendor assessment

Yes. Send your security questionnaire or vendor assessment to us, and we will fill it in. Many questions are already answered on this page.

Write to contact@scratcher.io or book a meeting. Scratcher ApS, CVR 38552864.