Security and Data Handling Overview
This page provides a practical, high-level overview of where different parts of PlanCoo typically process data, what types of data are involved, and why it is necessary.
Practical security note
The following points clarify important boundaries in how planCoo handles data.
- Raw user passwords are not stored in planCoo. Authentication is primarily handled through Firebase Authentication, including email/password, Google sign-in, and Microsoft sign-in. LinkedIn is used as an optional OAuth-based account linking and sharing integration, not as the primary login system.
- The platform is designed for project collaboration, roles, updates, and related application data. It is not intended to serve as the customer's formal document archive or records management system.
- Access to non-public data inside the platform is intended to be controlled through authentication, roles, and memberships. At the same time, certain pages or content may be intentionally published as public-facing content to support transparency, visibility, and collaboration across organizations.
| Category | Component | Country/Region | Data types | Purpose |
|---|---|---|---|---|
| Abuse prevention | Abuse prevention (Google reCAPTCHA) | Global service (Google) – may involve processing outside the EU/EEA | Risk signals and technical metadata used to determine whether a request is likely automated abuse. | Protect public submission forms and non-read actions from bot abuse and automated attacks. |
| AI features | AI text generation (Microsoft Azure OpenAI) | EU/EEA – Sweden Central. All calls are server-to-server via Azure Functions; the API key is never exposed to the browser. | Project titles, descriptions, task names/status, team member display names and roles, and meeting titles/agenda content — submitted when a logged-in user explicitly requests an AI-generated report or briefing. Email addresses, passwords, payment data, private messages, and Firebase UIDs are not transmitted. | Powering user-initiated AI features: project report generation, meeting briefings, and portfolio analysis. Processing only occurs on explicit user action (no background AI processing). Microsoft does not use planCoo inputs/outputs to train or improve its AI models. |
| Billing | Payments/subscriptions (LemonSqueezy) | US/global (third party) | Payment and subscription metadata for the paying customer/administrator (not intended for student data). | Handling billing, subscriptions, and license status. |
| Communication & Collaboration | Realtime Chat (Firebase Realtime Database & Firestore) | EU/EEA – Europe-West1 (Belgium) | Chat messages, timestamps, and participant metadata. Strictly access-controlled to participants. | Enabling secure, realtime communication between users. |
| Core data (EU/EEA storage) | File storage (Azure Blob Storage) | EU/EEA – West Europe (Netherlands) | Files such as profile pictures, limited supporting attachments, and project images (files + URLs/references). PlanCoo is not intended to function as the customer's formal document archive or records management system. | Storing and serving user-uploaded content that supports collaboration in the platform, not long-term institutional document archiving. |
| Core data (EU/EEA storage) | Primary application data (SQL Database) | EU/EEA – West Europe (Netherlands) | Project data, tasks, memberships/roles, company data, and user-generated application content stored in the platform. | Core functionality and storage of the data created and managed in PlanCoo. |
| Hosting & content delivery | Static web / edge delivery (Azure Static Web Apps) | Azure Static Web Apps resource region: East US 2 (as currently configured), with globally distributed edge delivery for static content (Global). | Delivery of static assets; may involve technical metadata (e.g., IP address and user-agent at the edge level). | High performance and high availability through global edge delivery (fast load times and resilient delivery). |
| Hosting & server-side processing | API processing (Azure Functions via Azure Static Web Apps) | Azure Static Web Apps resource region: East US 2 (as currently configured); API processing runs via integrated Azure Functions as part of the SWA platform (fronted by global edge delivery). | API requests/responses, identifiers (e.g., user/company/project IDs), and operational metadata required to serve requests. | Server-side processing for application features (CRUD operations, access checks, integrations). |
| Identity & access | Authentication (Firebase Authentication) | Global service (Google) – may involve processing outside the EU/EEA | Email address, Firebase UID, authentication events/metadata; password credentials are handled by Firebase (hashed/salted), and PlanCoo does not store raw passwords. PlanCoo supports email/password, email-link (magic link), Google sign-in, and Microsoft sign-in via Firebase Authentication. | Secure login and access control, while avoiding operating our own password storage/verification (risk reduction by using an established authentication provider). |
| Identity & social integrations | LinkedIn account linking / sharing (optional, user-initiated) | Global service (LinkedIn) – may involve processing outside the EU/EEA | LinkedIn account identifier, basic profile attributes returned by LinkedIn, LinkedIn profile URL, and user-selected content for publishing. OAuth tokens are used on-demand for requested actions and are not stored persistently by PlanCoo. | Enables optional LinkedIn profile linking/verification and user-initiated social publishing. |
| Network & traffic security | DNS / traffic security (Cloudflare) | Global (Cloudflare network) | DNS queries, IP address, request metadata (URL path, user-agent, HTTP headers), and TLS connection metadata for all requests passing through Cloudflare. Static assets are cached and served directly by Cloudflare edge nodes. | DNS management, HTTPS termination, static asset caching (performance), WAF/DDoS protection, bot detection, and traffic management. Cloudflare processes request metadata to distinguish legitimate users from automated threats. |
For school deployments, including deployments involving minors, we recommend minimizing student personal data in the platform where appropriate, for example by using student IDs or pseudonyms and limiting access through roles and project memberships.
See also the Data Processing Agreement (DPA) and the Privacy Policy.
Last verified: 2026-02-13