Data Security Policy

How we protect your data, maintain platform integrity, and respond to security incidents.

← Our Policies
📅 Effective: 6 May 2026 · Last updated: 6 May 2026 · Version: 2.0

About this document

This Data Security Policy describes the technical and organisational measures (TOMs) Stellar Mentoring UG uses to protect your personal data on the Stellar.Connect platform, in compliance with GDPR Article 32 and German implementing laws.

This document is a public summary. The full operational specification — including specific algorithms, key management procedures, and incident-response runbooks — is internal and may be shared with enterprise customers under non-disclosure as part of a Data Processing Agreement.

Plain English summary. Your data lives in Frankfurt on Amazon Web Services. It's encrypted on the way in (TLS 1.3) and on disk (AES-256). Access is least-privilege, authenticated with multi-factor login, audited, and limited to the people who actually need it. If something goes wrong, we tell you and the regulator within 72 hours, as the GDPR requires.

Section 1

Where your data lives

The Stellar.Connect platform runs on Amazon Web Services (AWS) in the eu-central-1 region (Frankfurt, Germany). All primary databases, file storage, and application servers are physically located in Germany.

  • AWS contracting entity: Amazon Web Services EMEA SARL (Luxembourg)
  • Data Processing Agreement: the AWS GDPR DPA applies to all our use of AWS services
  • Data residency: primary processing and storage in eu-central-1; daily backups in eu-central-1 (within the same Frankfurt region across multiple availability zones for low-latency restoration). Cross-region backup to eu-west-1 (Ireland) may be added in a future architecture revision; this Policy will be updated when it is.
  • Region certifications inherited from AWS: ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, C5 (Cloud Computing Compliance Criteria Catalogue, BSI Germany), and others — see aws.amazon.com/compliance/programs (opens in new tab)

The full list of AWS services we use is in Section 3 of the Privacy Policy.

Section 2

Encryption

In transit: all communication between your browser or app and our platform uses TLS 1.3 (with TLS 1.2 as the negotiated minimum for compatibility). HTTPS is enforced — plain-HTTP requests redirect to HTTPS. We use HSTS to instruct browsers never to use HTTP for our domains. Modern cipher suites only; legacy ciphers (RC4, 3DES) are disabled.

At rest:

  • All databases (DynamoDB) are encrypted with AES-256 using AWS-managed keys (AWS KMS).
  • All object storage (S3 buckets containing uploads, exports, profile photos) is encrypted with AES-256-SSE.
  • All Lambda function environment variables that contain secrets are encrypted with KMS at rest and decrypted only at function-invocation time.
  • All daily backups are encrypted with the same standard.

Passwords: never stored in plaintext or in a reversible form. We use AWS Cognito user pools, which apply SRP (Secure Remote Password) for authentication and store password hashes in a non-reversible form managed by AWS.

Section 3

Access controls

  • Role-based access control (RBAC). Application-level permissions are scoped per role: Super User, Admin, Coordinator, Mentor/Mentee. Users see only the data their role permits within their tenant.
  • Tenant isolation. Every query and mutation is filtered by tenantId derived from the user's authenticated session. Cross-tenant data access by application code is structurally impossible.
  • Least privilege for our staff. Stellar staff with operational access are granted only the AWS IAM permissions required for their function. Production access is logged via AWS CloudTrail and reviewed.
  • Multi-factor authentication. Mandatory for all Stellar staff with production access. Available and recommended for all platform users (Cognito MFA).
  • Audit logging. All authentication events, administrative actions, and access to sensitive data are logged. Logs are retained for 12 months for security incident investigation.
Section 4

Incident response and breach notification

72-hour rule (GDPR Art. 33). If a personal-data breach occurs that is likely to result in a risk to your rights and freedoms, we notify the competent supervisory authority — Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) — within 72 hours of becoming aware of the breach. If the breach is likely to result in a high risk to you, we notify you directly without undue delay (GDPR Art. 34).

Our incident-response process:

  1. Detection: automated alerts (Sentry, AWS CloudWatch, AWS GuardDuty) plus reports from staff or users.
  2. Triage: on-call engineer assesses severity and confirms whether personal data is involved within 4 hours of detection.
  3. Containment: immediate steps to stop ongoing exposure (revoke credentials, isolate components, etc.).
  4. Investigation: root-cause analysis, scope assessment (what data, how many people), evidence preservation.
  5. Notification: regulator (within 72 hours) and affected individuals (where required) following templates produced by counsel.
  6. Remediation: fix the underlying cause; document lessons learned; update controls.

If you suspect a security incident affecting your account or your data, contact privacy@stellarmentoring.com or use our service-desk portal.

Section 5

Security testing and assurance

  • Code review. Every change to production code is reviewed by at least one engineer who did not write it.
  • Static + dependency scanning. CI runs ESLint, type-checking, and dependency vulnerability scanning (GitHub Dependabot) on every commit. We track and remediate CVEs in our dependencies.
  • Runtime monitoring. AWS GuardDuty, AWS WAF, Sentry, and CloudWatch alarms monitor production for anomalies.
  • Penetration testing. PROVISIONAL: today we rely on AWS-side runtime controls (GuardDuty for threat detection, WAF for application-layer protection, CloudTrail for audit, Inspector for vulnerability scanning of our compute environment) plus continuous static and dependency scanning of our codebase. Engagement of an independent third-party penetration-testing firm is planned for 2026; this Policy will be updated to reflect the cadence and findings summary when that engagement begins.
  • Vulnerability disclosure. If you believe you have found a security issue, please report it to security@stellarmentoring.com or submit a report at /.well-known/security.txt. We respond within 5 business days. We do not currently operate a paid bug-bounty programme but will acknowledge contributors who report responsibly.
Section 6

Our staff and processes

  • Confidentiality. Every Stellar employee and contractor with access to personal data is bound by written confidentiality obligations.
  • Onboarding. New hires complete data-protection and security awareness training before being granted production access.
  • Ongoing training. Annual refresher on GDPR, secure coding, phishing awareness, and incident reporting.
  • Background checks. PROVISIONAL: we do not currently engage a third-party service for formal employment background checks. As the team grows, we will introduce a documented background-check policy proportionate to the role; this Policy will be updated at that point.
  • Offboarding. When someone leaves Stellar, their accounts are disabled and credentials are rotated within one business day.
  • Vendor management. New sub-processors are reviewed for security and data-protection posture before being engaged. Active sub-processors are listed in Section 3 of the Privacy Policy.
Section 7

Backup, retention, and business continuity

  • Backups. Encrypted daily backups of all production data, retained for 30 days. Backups are stored in a different AWS availability zone (and optionally a different region — see Section 1).
  • Restoration testing. PROVISIONAL: today we exercise restoration on an ad-hoc basis when infrastructure changes warrant it. Formal scheduled restoration drills will be introduced in 2026 and reflected here..
  • Recovery objectives. best-effort recovery within 4 hours of detection (Recovery Time Objective) and a maximum data-loss window of 24 hours (Recovery Point Objective). These are operational targets, not contractual service-level commitments. Specific SLAs may be agreed individually under enterprise contracts.
  • Data retention. See Section 4 of the Privacy Policy for how long different categories of personal data are kept.
  • Secure deletion. When data is deleted (whether by your erasure request or after the retention period), it is removed from the active database within 24 hours of the trigger. Backup copies expire on the standard backup-retention cycle.
Section 8

What you can do to keep your account secure

Security is a shared responsibility. The most effective controls you have:

  • Use a strong, unique password for your Stellar account. We enforce a minimum strength but a passphrase is always better.
  • Enable multi-factor authentication in your profile settings.
  • Don't reuse passwords from other services.
  • Be wary of phishing. We will never ask for your password or for a one-time code by email or phone. If you receive a suspicious email claiming to be from Stellar, forward it to security@stellarmentoring.com and delete it.
  • Sign out on shared devices and review your active sessions if you suspect anyone else has used your account.
Section 9

Changes to this policy

We update this Data Security Policy when our architecture, sub-processors, or controls change. The "Last updated" and "Effective" dates at the top tell you which version is currently in force. Material changes (new region, new sub-processor with security implications, new control category) are reflected here promptly.