1. Controller and roles
| Service provider | Meetsko Oy |
|---|---|
| Service | Meetsko |
| Contact and data protection enquiries | tuki@meetsko.fi |
Meetsko Oy processes personal data in two roles:
- As a processor (Article 28 GDPR) for data processed in a customer organisation's projects. The customer organisation is the controller and decides how the service is used in its projects. Meetsko Oy processes this data only on the customer's instructions and under a data processing agreement.
- As a controller for user accounts, service operation, security and logs, the customer relationship and invoicing, and for projects that do not belong to any customer organisation.
Customer agreements include a separate data processing agreement (DPA) covering the subject matter, duration, instructions, sub-processors and assistance obligations.
2. The service
A lead organisation creates a project and invites participants from its own and other organisations. Each participant authorises Meetsko themselves with their own Microsoft or Google account. Nobody shares another person's calendar on their behalf, and no organisation-wide calendar permission is required from IT administrators.
Meetsko shows participants' free and busy times, suggests times that suit everyone, and can send a meeting invitation from the organiser's own Outlook calendar. The content of calendar events (title, location, description, other attendees) is neither shown nor stored.
3. Personal data processed
| Category | Content | Source |
|---|---|---|
| Basic user data | Name, email address, sign-in account identifier | Microsoft or Google sign-in |
| Profile | Job title, function or team, language | The user |
| Organisation data | Customer organisation, its email domains, membership and application role (e.g. organisation administrator) | The customer organisation, the service provider |
| Project participation | Projects, project role, groups, invitation status, invitation and reminder dates | The inviter and project administrators |
| Calendar availability | Start and end times of busy and free periods (free / busy) for roughly three months ahead | Microsoft Graph or Google Calendar, with the user's own authorisation |
| Visibility restrictions | Visibility windows and hidden periods set by the user for each project | The user |
| Calendar connection credentials | Encrypted refresh token, granted permissions (read / read and write), change notification subscription identifier | Microsoft or Google |
| Events and drafts created in Meetsko | Title, message, time, recurrence, organiser, invitees, Teams link, calendar event identifier, cancellation status | The event's creator; time and cancellation from the organiser's calendar |
| Activity log | Project actions: openings, changes to participants and groups, event creation and cancellation, reminders; who and when | Recorded automatically by the service |
| Technical logs | Sign-ins, errors, timestamps | Recorded automatically by the service and its sub-processors |
| Emails | Recipient, message content and delivery status | The service and the email delivery provider |
The service does not process special categories of personal data (Article 9 GDPR).
4. Purposes and legal bases
| Purpose | Legal basis |
|---|---|
| Finding common times and managing project events across organisations | The agreement between the customer organisation and Meetsko Oy (Art. 6(1)(b)) and the customer's legitimate interest in organising its work (Art. 6(1)(f)) |
| Reading calendar availability and sending meeting invitations | The user's own authorisation: each person grants read access, and separately write access, themselves and can withdraw either at any time |
| User accounts and access control | Performance of the agreement (Art. 6(1)(b)) |
| Invitations, authorisation reminders and notifications | Performance of the agreement (Art. 6(1)(b)) and the customer's legitimate interest (Art. 6(1)(f)) |
| Activity log, recording of support access and security | Legitimate interest (Art. 6(1)(f)) and security of processing (Art. 32) |
| Technical operation and troubleshooting | Legitimate interest (Art. 6(1)(f)) |
5. Sources of data
- The user: profile details, visibility restrictions and choices made in the service.
- Microsoft or Google: name, email address and calendar availability, always on the basis of the user's own authorisation.
- The inviter or an organisation administrator: the invitee's name and email address.
Inviters must make sure they have grounds to process the invitee's contact details. Before authorising, the invitee sees who invited them and to which project.
6. Protecting calendar content
Meetsko processes only the time and status of calendar entries, never their content. This is enforced as a technical control, not merely a policy.
| Calendar data | Processed? |
|---|---|
| Start and end time | Yes |
| Status (free / busy) | Yes; tentative and out of office are shown as busy |
| Event title | No, removed on the server before storage |
| Location and meeting link | No, removed on the server before storage |
| Description, attachments, other attendees | Not retrieved |
| Events marked private | Shown only as busy time, with nothing identifying |
Meetsko requests read access to the user's own Microsoft calendar (Calendars.Read), or equivalent read access from Google, because narrower permissions do not reliably return availability. As this permission would technically allow access to event content, a filtering layer on the server strips everything except time and status as soon as the calendar response arrives, before anything is stored in the database or sent to a browser.
Users can restrict, per project, when their calendar is visible (visibility windows and hidden periods). Hidden time is shown to others as busy and is not used for time suggestions.
Changes to Outlook calendars are signalled through Microsoft change notifications. A notification only says that the calendar has changed; availability is then fetched again through the same filter.
7. Creating events and Outlook sync
- Write access only on request. Only a participant who has separately granted write access to their calendar in the project (Calendars.ReadWrite) can send meeting invitations. Read authorisation does not grant write access.
- Own calendar only. The invitation is created in the organiser's own calendar with their own authorisation, and Outlook sends the invitations as usual. Meetsko never writes to other participants' calendars or uses another user's authorisation.
- Only the organiser can make changes. An event created in Meetsko can be cancelled from the app only by its organiser.
- Sync. For events created in Meetsko, only the time and cancellation status are read from the organiser's calendar to keep the project's event list up to date. The title, message and attendee list are never read from Outlook.
- Visibility. Events are visible to project participants unless the creator chooses not to show the event to others. Drafts are visible only to their author. Invitees' responses (accepted / declined) are not shown.
Why does Microsoft call write access “full access”?
When you grant write access, Microsoft asks for consent to the Calendars.ReadWrite permission, described as “Have full access to your calendars” (“Have full access to user calendars” in the organisation's Entra ID). The name and description are Microsoft's standard wording, which apps cannot change. Microsoft offers no narrower permission that lets an app create a meeting invitation in a user's calendar, so every app that creates invitations on a user's behalf uses the same permission.
Because the permission would technically allow access to every event in your calendar, Meetsko's use of it is restricted in the application code:
- New events only at your request. An event is created only when you send an invitation from Meetsko yourself, and only in your own calendar.
- Changes only to Meetsko's own events. Meetsko stores the Microsoft identifiers of the events it creates at the moment of creation. Cancellations and other changes are applied on the server only to these stored identifiers. Microsoft event identifiers are never accepted from the browser, so there is no technical route to any other event.
- Other events are left alone. Meetsko never edits, deletes or cancels any other event in your calendar, and their content is not read (see section 6). For Meetsko's own events, only the time and cancellation status are read.
- Your calendar, your request. Your permission is used only for your own requests and only for your own calendar. Another user's permission is never used to write.
- Optional and per project. Write access is granted separately in the project settings and is not needed for viewing schedules. Without it, Meetsko copies the attendees so you can create the invitation yourself in Outlook.
- Revocable. When you remove the authorisation in Meetsko's settings, Meetsko deletes its stored calendar connection (read and write) and can no longer reach your calendar. You can also remove the consent in your Microsoft account's app settings.
Your organisation's IT can restrict user consent with Entra ID consent policies if it wishes. Meetsko's scheduling also works with read access alone.
8. Access control and visibility
The main rule: calendar data is visible only to participants in the same project. People outside a project cannot see its participants' data, except for the administrators listed below.
| Role | What they can see and do |
|---|---|
| Project member | Names, free and busy times of participants in the same project, and the project's events |
| Project administrator | In addition, managing participants and groups and sending reminders |
| Guest user | Only projects they have been invited to; cannot create projects |
| User (can create projects) | Can create projects; sees only the projects they take part in |
| Organisation administrator | All of their organisation's projects including calendars, even without taking part, subject to participants' visibility restrictions; managing the organisation's members and settings. Access is recorded in the activity log. |
| Application administrator (Meetsko Oy) | Technical support access for troubleshooting and support requests. Opening a project without being a participant is recorded in the activity log as support access, so that it can be reported to the customer. |
Access rights are checked on the server for every request. Database tables are closed to direct access with row level security, so bypassing the user interface does not open access to data.
9. Emails and reminders
- Project invitations say who sent the invitation, to which project, and what the participant is asked to do.
- Authorisation reminders. Project administrators can remind a participant who has not yet authorised their calendar (at most once a day). Meetsko also sends at most two automatic reminders: two days after the invitation and three days after the first reminder. Organisation administrators can switch automatic reminders off for their organisation's projects.
- Organisation notifications, such as being made an administrator or given the right to create projects, and, where needed, a notice to the customer's IT contact about the service being taken into use.
Emails are not used for marketing.
10. Sub-processors and data location
| Sub-processor | Task | Data | Location |
|---|---|---|---|
| Supabase | Database, sign-in, server logic | All data stored by the service | EU (Ireland) |
| Netlify | Delivery of the website and user interface | Technical connection logs | Global content delivery network (US company) |
| Resend | Sending emails | Recipient name and address, message content | US company |
| Microsoft | Sign-in and calendar API | Sign-in, availability, meetings created in Meetsko | The user's own Microsoft environment |
| Calendar API (if the user authorises a Google calendar) | Availability | The user's own Google account |
Calendars stay in the user's own Microsoft or Google environment; only availability made up of time ranges is transferred to Meetsko. Where personal data is transferred outside the EU or EEA, the transfer relies on a European Commission adequacy decision (the EU–US Data Privacy Framework) or on standard contractual clauses. Customers are notified of new sub-processors in advance. Data is never sold or disclosed for marketing.
11. Retention and deletion
| Data | Retention |
|---|---|
| Calendar availability | Updated continuously; deleted when authorisation is withdrawn or the participant is removed from the project |
| Calendar connection credentials | While the authorisation is valid; deleted when it is withdrawn |
| Projects, participants, groups, events and drafts | Until the project is deleted. Deleting a project deletes this data; invitations already sent remain in participants' calendars. |
| User account and profile | For as long as the user belongs to a project or a customer organisation. After 12 months without either, the profile and sign-in account are deleted automatically without separate notice. |
| Activity log | For the term of the customer agreement; kept after a project is deleted so that support access can be demonstrated |
| Technical logs and email delivery logs | According to the sub-processors' retention policies |
Users can remove their authorisation in the project settings or on the My profile page; Meetsko then stops fetching the calendar and the change notification subscription is removed. Authorisation can also be withdrawn in the Microsoft or Google account settings. When an agreement ends, the customer's data is deleted or returned as agreed; data is removed from backups as they rotate.
12. Security
- All traffic is encrypted (TLS), and data is encrypted at rest.
- Sign-in takes place with Microsoft or Google; Meetsko never sees or stores passwords. Multi-factor authentication and conditional access follow the user's own organisation's policies.
- Calendar refresh tokens are stored encrypted on the server, never in the browser.
- Calendar content is filtered on the server before storage.
- Meetsko writes only to the organiser's own calendar, at their own request.
- Access to production data is limited to named people, and support access to projects is logged.
- Changes to production go through version control.
13. Your rights
You have the right to access your data (Art. 15), to have inaccurate data rectified (Art. 16) and data erased (Art. 17), to restrict processing (Art. 18), to receive your data in a portable format (Art. 20) and to object to processing based on legitimate interest (Art. 21). You can withdraw your calendar authorisation at any time.
Where Meetsko Oy acts as a processor, requests should primarily be addressed to the customer organisation, which is the controller. Meetsko Oy forwards any requests it receives to the customer without delay and helps with the response.
Requests: tuki@meetsko.fi. We respond within one month. You also have the right to lodge a complaint with the Office of the Data Protection Ombudsman in Finland (tietosuoja.fi) or with the supervisory authority in your own country.
14. Personal data breaches
Meetsko Oy notifies the customer of any personal data breach it becomes aware of without undue delay, and within 24 hours of discovery at the latest. As a controller, Meetsko Oy notifies the supervisory authority within 72 hours where required (Art. 33) and the data subjects if the breach is likely to result in a high risk (Art. 34).
15. Changes to this policy
This policy is updated as the service evolves and legislation changes. Customers are notified of material changes in advance.
| Version | Date | Change |
|---|---|---|
| 2.1 | 25 October 2026 | Scope of write access (Calendars.ReadWrite) and how it is technically limited to Meetsko's own events |
| 2.0 | 22 October 2026 | Service name Meetsko; event creation and Outlook sync, visibility restrictions, organisation roles, activity log, authorisation reminders, Google Calendar and 12-month profile retention |
| 1.0 | 19 September 2026 | First version |