Executive Summary

This document provides a security and privacy overview of Wastime (the "Application") intended to support GDPR/UK GDPR transparency, App Store and Google Play privacy reviews, and enterprise due diligence. It summarizes our data processing activities, data flows, roles (controller/processor), international transfers, and technical and organizational measures ("TOMs") under Article 32 GDPR.

This document is informational and does not replace our Privacy Policy. For business customers requiring a DPA, SCCs/UK IDTA, or additional evidence (e.g., vendor documentation, audit reports), please contact us.

1. Controller, Scope, and Contact

Data Controller (GDPR/UK GDPR): Vladimir Makarevich (individual developer), Gdansk, Poland.

Scope: this document covers personal data processing in the mobile applications (iOS/Android), the web application, and the backend services used to provide features such as authentication, synchronization, calendar publishing, reporting/abuse handling, and subscriptions.

2. Data Processing Inventory (ROPA-Style Summary)

The table below summarizes key processing activities. Actual data fields may vary by feature use and platform.

Notes: We do not process payment card data. Purchases are processed by Apple App Store and Google Play as independent controllers. We do not send marketing emails at this time.

3. Controller/Processor Model and Subprocessors

We act as the controller for personal data we process in connection with providing the Application. We use processors (service providers) to perform processing on our behalf. Some third parties (notably app stores) act as independent controllers for their own processing.

We have executed data processing agreements (DPAs) with our processors (including Microsoft Azure, Google Firebase, and RevenueCat), including appropriate terms addressing confidentiality, security, and subprocessors. For international transfers from the EEA/UK, we rely on appropriate safeguards (for example, the EU Standard Contractual Clauses and the UK Addendum/IDTA, as applicable) and implement supplementary measures as appropriate to the risk.

4. International Transfers (GDPR/UK GDPR Chapter V)

Our primary backend hosting is in the European Union (Azure Poland Central). Certain vendors (notably Firebase and RevenueCat) may process personal data in the United States and other countries where they and their subprocessors operate.

For restricted transfers, we rely on recognized transfer mechanisms (such as SCCs and, where applicable, the UK IDTA/Addendum) and assess whether supplementary measures are needed based on the nature of the data, the processing, and the vendor risk profile.

5. Lawful Bases and Purpose Limitation

Where GDPR/UK GDPR applies, we process personal data only for specified purposes and rely on appropriate lawful bases. In practice, the key lawful bases are:

• Contract (Art. 6(1)(b)): provide the Application, user accounts, publishing, synchronization, and subscription entitlements.
• Legitimate interests (Art. 6(1)(f)): security, fraud prevention, abuse handling, service reliability, and limited operational analytics where permitted.
• Consent (Art. 6(1)(a)): where required by law for analytics and/or geolocation, depending on jurisdiction and platform.
• Legal obligation (Art. 6(1)(c)): comply with lawful requests and legal obligations (e.g., certain abuse reports).

Consent posture (current state): In the mobile applications, analytics/crash/performance telemetry is enabled by default. We do not currently implement a region-based opt-in consent gate for EEA/UK users. This is a compliance risk in jurisdictions where opt-in consent is required for certain telemetry, and it is a priority remediation item.

We do not intentionally collect special category data (Art. 9 GDPR) as part of core features. If future features require such data, we will perform an updated assessment and implement additional safeguards and disclosures.

6. Security Program and Safeguards (Article 32 GDPR; ISO 27001 / SOC 2 Alignment)

We implement technical and organizational measures designed to protect personal data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access. While we are not currently certified under ISO 27001 or SOC 2, we align our controls to commonly accepted security principles used in those frameworks.

• Encryption in transit: HTTPS/TLS for communications between clients and backend services.
• Encryption at rest: cloud-provider encryption for managed databases and storage; secrets managed via Azure Key Vault.
• Access control: least privilege; strong authentication for administrative access; separation of environments where applicable.
• Secret management: credentials and sensitive configuration are not hard-coded; secrets stored in Azure Key Vault; managed identities used where available.
• Logging and monitoring: operational telemetry via Azure and Firebase tooling; monitoring for errors and service health.
• Vulnerability management: dependency review and security updates; remediation prioritized based on risk.
• Secure development: code review practices; change control through version control; security testing where appropriate.

Security measures are reviewed periodically and updated based on product changes, incidents, and emerging threats.

7. Logging, Monitoring, and Auditability

We maintain logs and telemetry necessary for operating and securing the Application. This may include request logs, error logs, performance metrics, and security-relevant events. Authentication events are handled by Firebase Authentication and may also be reflected in our backend logs where needed for security and troubleshooting.

Access to logs is restricted to authorized personnel. For Azure operational telemetry stored in Log Analytics / Application Insights, the workspace retention is configured to 30 days. Firebase Analytics/Crashlytics/Performance retention is currently set to vendor defaults and should be verified and documented as part of compliance hardening.

8. Backups and Disaster Recovery

We use managed database backup capabilities (for example, Azure PostgreSQL point-in-time restore) and related infrastructure resilience features. Backups are encrypted by the cloud provider and access is restricted.

For Azure PostgreSQL in production, the point-in-time restore (PITR) backup retention period is configured to 7 days.

For Azure Storage used to store report attachments, soft delete retention is enabled for blobs and containers for 30 days (to protect against accidental deletion), subject to cloud-provider behavior and configuration.

Deleting an account removes data from active systems. Residual copies may persist in encrypted backups for a limited period until backups are overwritten in accordance with the backup lifecycle.

9. Data Retention and Deletion

• Default retention: user data is retained until the user deletes it or deletes the account.
• Account deletion: available through Application features where implemented; intended to permanently remove user data from active systems and revoke access. If self-service deletion is not available on your platform, contact us.
• Published content: can be unpublished or removed by deleting the calendar and/or account; public-by-link access is revoked when content is removed.
• Support and abuse records: retained for a reasonable period to handle disputes, security issues, and compliance.
• Local device data: can be removed by uninstalling the Application and/or using in-app deletion features where provided.

We do not provide deletion confirmations via email at this time. Confirmation is provided through in-app workflows where applicable.

10. Incident Response and Breach Notification

We maintain an incident response process to identify, assess, contain, eradicate, and recover from security incidents. When GDPR/UK GDPR applies and a personal data breach is likely to result in a risk to individuals' rights and freedoms, we will notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, unless an exception applies.

Where notification to affected users is required, we may provide notice in-app and/or via public notices on our website, depending on available contact channels and the nature of the incident.

11. Data Subject Rights and Request Handling

We support applicable data subject rights under GDPR/UK GDPR, including access, rectification, erasure, restriction, portability, objection, and withdrawal of consent (where processing is based on consent). We also support applicable consumer rights under CCPA/CPRA where required.

• Self-service: users can delete accounts and certain data within the Application.
• Requests by email: contact [email protected] with sufficient detail to identify the account and the request.
• Response timelines: GDPR/UK GDPR requests are generally handled within one month, subject to extensions where permitted.

We may require identity verification to protect users and prevent unauthorized disclosure or deletion.

12. CCPA/CPRA Considerations (California)

For California residents, we do not sell personal information and we do not share personal information for cross-context behavioral advertising. We process personal information for business purposes described in our Privacy Policy and this document.

Geolocation data may be considered "sensitive personal information" under CPRA when it involves precise geolocation. Where precise coordinates are processed (web geolocation), they are used only to infer country/time zone for localization and are not stored in our backend.

13. Document Governance

This document is reviewed periodically and updated when material changes occur in our processing activities, technology stack, or legal requirements. The "Last updated" date at the top of this page indicates when it was last revised.

Material changes may be communicated through in-app notices where feasible.