Technical and Organizational Security Measures

Modora – Discord Bot Platform
PC Servicedesk B.V.

Last updated: 24 February 2026

This document describes the technical and organizational measures implemented by PC Servicedesk B.V. (Modora) to ensure a level of security appropriate to the risk for the Processing of Personal Data, in line with Article 32 GDPR and the Data Processing Agreement (DPA). It applies to the Modora Discord bot, web dashboard, and related infrastructure (Node.js, Laravel, Docker, cloud deployment).

1. Encryption

1.1 Encryption in transit

All communication between clients (browsers, Discord) and Modora services uses TLS 1.2 or higher (TLS 1.3 where supported).
Dashboard and API endpoints are served over HTTPS only; HTTP is redirected to HTTPS.
Internal service-to-service communication (e.g. dashboard ↔ bot API, app ↔ database) uses encrypted channels where they traverse untrusted networks.
Discord API and gateway connections use Discord's required encryption (WSS/TLS).

1.2 Encryption at rest

Databases: Database volumes and backups are encrypted at rest (e.g. using provider-managed encryption or LUKS/disk encryption where self-hosted).
Sensitive configuration and secrets: Environment variables, API keys, and database credentials are not stored in plain text in code or in version control; they are managed via secure configuration (e.g. environment files, secrets manager) and access is restricted.
Backups: Backups are stored in an encrypted form and access to backup storage is restricted.

2. Access control

2.1 Role-based access control (RBAC)

Dashboard: Access to the Modora dashboard is authenticated (e.g. Discord OAuth). Permissions are enforced per guild and per feature (e.g. manage server, view logs, manage tickets) so that users only access data for servers they are authorized to manage.
Staff/admin: Internal staff or administrative access to the platform is restricted by role (e.g. support, admin) and is logged. Principle of least privilege is applied.
Database and infrastructure: Direct access to databases and production infrastructure is limited to authorized personnel and uses strong authentication (e.g. SSH keys, MFA). Access is logged and reviewed.

2.2 Authentication and session management

User sessions are managed with secure, httpOnly cookies and CSRF protection. Session fixation and session hijacking mitigations are in place.
Passwords (where used) are hashed using industry-standard algorithms (e.g. bcrypt). No plain-text passwords are stored.
Discord OAuth is used for dashboard login; Modora does not store Discord passwords.

2.3 Multi-tenant data separation

Data is logically separated by guild (Discord server) ID. Queries and API responses are scoped to the requesting guild; cross-tenant access is prevented at the application and database layer.
Database schemas use guild/server identifiers so that one tenant cannot access another tenant's data through normal application or API use.
Where shared infrastructure is used (e.g. same database cluster), row-level or schema-level isolation ensures tenant separation.

3. Logging and monitoring

Application and security events: Access to sensitive data, administrative actions, and authentication events are logged (with minimal Personal Data where necessary for security). Logs are retained in accordance with the Data Retention Policy.
Infrastructure and errors: Service health, errors, and performance metrics are monitored (e.g. via Sentry or similar). Logs are protected from unauthorized access and tampering.
Alerts: Automated alerts are configured for anomalies (e.g. unusual access patterns, repeated failures, suspected abuse) to enable timely response.

4. Rate limiting and abuse prevention

API and dashboard: Rate limiting is applied to dashboard and API endpoints to reduce the risk of brute-force attacks, abuse, and denial of service. Limits are tuned per endpoint and per user/IP where appropriate.
Discord bot: Command and interaction rate limits are applied in line with Discord's requirements and Modora's own limits to protect stability and prevent abuse.

5. Anti-scam and content safety

Anti-scam systems: Modora's anti-scam module uses detection logic (e.g. link scanning, pattern matching) to help Controllers protect their communities. Scans and results are stored in a controlled manner and are only accessible to authorized guild staff.
Data minimization: Only data necessary for detection and logging (e.g. message content, links, user IDs) is processed; retention is limited as per the Data Retention Policy.

6. OCR and image moderation safeguards

Purpose limitation: OCR (optical character recognition) and image moderation are used only where enabled by the Controller and only for the stated purpose (e.g. rule enforcement, safety).
Processing scope: Image and text extraction is limited to what is needed for the feature; raw images and OCR output are retained only as long as necessary (see Data Retention Policy).
Access: Access to OCR results and moderation logs is restricted to authorized guild administrators and to Modora personnel only where required for support or incident response.

7. AI request isolation and transparency

Isolation: Requests to Anthropic are made in the context of the specific guild and user action; no cross-tenant mixing of prompts or responses.
No training on customer data: Where contractually agreed with the AI provider, customer data sent via the API is not used for model training. This is reflected in Modora's configuration and in the Subprocessors document.
Transparency: Use of AI is disclosed in the DPA and Subprocessors document; Controllers enable AI features knowingly. Data Subject information can be provided by the Controller based on Modora's documentation.

8. Backup and business continuity

Backups: Databases and critical configuration are backed up regularly. Backup frequency and retention are defined in the Data Retention Policy and operational runbooks.
Recovery: Recovery procedures are documented and tested where feasible. Backups are encrypted and stored in a separate location or account from primary systems.
Availability: Where applicable, high availability and redundancy (e.g. multiple instances, health checks) are used to reduce the impact of single points of failure.

9. Incident response

Detection and response: Modora has procedures to detect, assess, and respond to security and Personal Data incidents (e.g. unauthorized access, data breach). Incidents are escalated and documented.
Notification: In the event of a Personal Data breach affecting Community Data, Controllers are notified without undue delay in accordance with the DPA, with information needed for regulatory and Data Subject notifications.
Post-incident: Incidents are reviewed to identify root cause and to improve controls and procedures.

10. Secure development and deployment

Code and dependencies: Code is stored in version control; dependencies are updated to address known vulnerabilities where possible. Sensitive data is not committed to repositories.
Deployment: Deployments are performed via defined pipelines (e.g. Docker, CI/CD). Production changes are controlled and, where applicable, reviewed. Default credentials are changed and secrets are not hardcoded.
Containers: Application and bot run in containers (e.g. Docker); images are built from trusted base images and scanned for known issues where feasible.

11. Physical and organizational security

Infrastructure: Production servers are hosted in Finland (EU/EEA) via Hetzner; database and CDN are self-hosted on this infrastructure. Dashboard and web traffic may be proxied via Cloudflare (CDN, DDoS protection, WAF). Where Modora uses third-party hosting (e.g. cloud providers), physical and environmental security are governed by the provider's policies and certifications (e.g. ISO 27001, SOC 2). Modora selects providers that meet appropriate standards.
Personnel: Access to production systems and Personal Data is limited to personnel who need it for their role. Server administration (including root access for maintenance) is performed by authorized parties (e.g. Sassguard) under confidentiality and data protection obligations; access is limited to what is necessary for server maintenance and support. Confidentiality and data protection are part of internal policies and training. Access is revoked when no longer required.

12. Review and updates

These measures are reviewed periodically and updated to reflect changes in the service, technology, and risk. Material changes that affect the DPA or Data Subjects will be communicated as required by the DPA or applicable law.

Document reference: This document is Annex II (Technical and Organizational Measures) for the purposes of the Modora Data Processing Agreement.

Contact: security@modora.gg / legal@modora.gg
PC Servicedesk B.V. (Modora)

Security Measures