GDPR and privacy

Sutja is built privacy-first. All personal data is stored and processed in Finland and the EU. This page explains how Sutja meets its GDPR obligations, who the sub-processors are, and why every one of them is a European company.

This page is written for the customer, that is the employer subscribing to the service, who is the controller for its employees' data. It describes Sutja's obligations as a processor in plain language; the binding wording is in the data processing agreement. In case of conflict, the agreement prevails.

Questions about an employee's own data are for their employer as controller, not for Sutja. The data Sutja processes in its own controller role is described in the privacy policy.

When a customer uses Sutja to manage its employees' shift and HR data, the customer is the controller and Sutja acts as a processor on the customer's behalf.

As controller, the customer decides what data is stored in the service, for what purpose and on what legal basis, and is responsible for informing employees appropriately. Sutja does not make these decisions and does not use the data for its own purposes.

Sutja processes the data only on the customer's documented instructions. Those instructions comprise the data processing agreement and the way the customer uses the service. If Sutja considers an instruction to infringe data protection law, it informs the customer.

Sutja is itself the controller only for data arising from its own business: website visitors, enquiries and the contact persons of customers. That data is covered by the privacy policy.

The customer can grant an external payroll clerk limited access to a workspace without creating an employment relationship. The clerk can view payroll data, individual time entries and reimbursements, and the personal and employment details needed to set up employees in payroll, including personal identity codes, bank accounts, addresses and salary information. The clerk can correct payroll IDs, cost centre codes and payroll settings and initiate payroll exports, but cannot approve hours or reimbursements. The customer is responsible for granting access and for its own payroll clerk; the clerk is not a subprocessor selected by Sutja. Opening employee details is recorded in the activity log without the identity code, bank account or other displayed values. Access can be revoked in workspace settings.

The service, database, files and sign-in run in the Finnish provider UpCloud's data centres in Finland. Email is delivered through Lettermint, a Dutch company whose sending infrastructure is in the Netherlands and Germany. Personal data is not stored outside the EU or EEA.

The traffic path is European as well: DNS, content delivery and the firewall are provided by BunnyWay (bunny.net), a Slovenian company. Traffic is served from EU locations, and the restriction is recorded in the data processing agreement as a documented instruction.

Sutja uses a limited set of carefully selected providers, with agreements containing data protection obligations in place. Personal data is stored and processed in Finland and the EU, and all the providers are European companies.

The table marks which role each provider acts in. A sub-processor processes the data a customer stores in their workspace on Sutja's behalf, so the contractual chain runs through the data processing agreement to the customer. A provider marked as Sutja's own register processes only data for which Sutja is itself the controller, such as invoicing and accounting.

The marking states the widest role a provider may act in, not only what it does at this moment. Brevo, for example, is primarily customer relationship management, but it is also the fallback path for sending email, so it is marked as a sub-processor.

App users are not transferred into customer relationship management. They are customers' employees, not Sutja's contacts. Only a workspace's billing contact is sent to Brevo's CRM for the subscription, alongside website leads. Marketing messages are sent only with explicit consent.

Sutja notifies intended sub-processor changes in advance, and the customer may object to a change on reasonable grounds. The procedure is set out in section 7 of the data processing agreement.

Sutja supports data subject rights: access, rectification, erasure, portability and restriction of processing. Because the controller for employee data is the customer, such requests are routed to the customer and Sutja assists in fulfilling them.

The service includes tools for this. A workspace administrator can export the workspace's data from the Privacy section of the settings; the same section also offers the signed data processing agreement as a download. The export produces a compressed, machine-readable JSON file that stays available for 7 days, and every download is logged. Attachments are not yet included in the package; they are downloaded from the service separately. Deletion happens through the service's own functions: an employee is removed from the staff view, a workspace is deleted from its settings page, and a user account is deleted from the profile page.

Assistance is included in the service fee. Sutja does not charge separately for supporting a response to a data subject request or for providing the information about the service needed for a data protection impact assessment (DPIA). Exceptionally extensive separate work is agreed in advance, and the term is set out in section 9 of the data processing agreement.

As controller, the customer decides what data is stored in the workspace. Sutja has built the service so that its standard features ask only for what shift planning, working time records and the basis for paying wages require. Sutja does not collect data from a workspace for its own purposes and does not use customer data to train AI models.

Some data has a specific basis of its own. The personal identity code is asked for in order to pay wages and to meet the employer's related statutory obligations, and section 29 of the Finnish Data Protection Act permits processing it in those tasks: they require identifying the employee unambiguously, and a name is not a unique identifier. The same applies to paying reimbursements: when the customer has enabled the accounting integration, the code is sent to the financial system the customer has chosen, so that the travel expense claim is matched to the right recipient rather than to a namesake. In the application the code is visible only to the employee, their own supervisor chain and administrators, and it is cleared after the membership ends as set out in the retention table.

In Sutja's own reporting and product development, aggregated or anonymised data is used, from which an individual cannot be identified.

When the retention period ends, data is either deleted or irreversibly anonymised. This happens automatically and requires no separate request from the customer.

Data is encrypted in transit and at rest, access is role-based and follows the least-privilege principle, and activity is monitored through logs and change history.

A plain-language description is on the security page. At the contractual level the measures are specified in Appendix 1 to the data processing agreement, which sets out point by point how encryption, key management, confidentiality, integrity, availability and resilience are implemented. The appendix is not published, because it describes the details of the safeguards. It is available on request at tietosuoja@sutja.fi.

Sutja processes data only for the duration of the agreement. When processing ends, the customer's data is returned or deleted within 90 days, except for data that law requires to be retained. The same deadline is written into the data processing agreement.

Below is a single table of every retention period that applies to the data a customer stores in their workspace. The customer is the controller for that data. Data arising in Sutja's own controller role has its own retention periods, listed in the privacy policy.

The same information is also shown in the Privacy section of the workspace settings, where the table is generated directly from the system's own rules. The table on this page is checked against those same rules by an automated gate before every release, so the description cannot drift apart from what the service actually does.

The retention period starts from the moment in the right-hand column, not from the end of the agreement. The staging is not slowness but statutory retention duties: working time records may not be destroyed before the limitation period under the Working Hours Act has expired.

Deletion is not a single moment but several stages. They are spelled out because the difference matters to a controller:

• Access ends immediately. When a workspace or a user account is deleted, sign-in and access to the data stop at once.
• Data is destroyed after a grace period. The rows of a deleted workspace are removed from the database and its attachments from file storage 60 days after the deletion.
• The encryption key is destroyed last. Once everything else has been destroyed, the workspace's encryption key is destroyed, after which the fields and files encrypted with it cannot be recovered with any key.

The workspace owner receives a reminder 14 and 2 days before the destruction and a confirmation message afterwards. Data should be exported before deleting, because deletion ends access to the workspace immediately and self-service export is no longer available after that. During the grace period the workspace can still be restored by contacting us, after which exporting works normally.

Sick leave certificates and sickness-based absence reasons are health data within the meaning of GDPR Article 9. They are destroyed 60 days after the absence ends, whether or not the employment continues: health data must be destroyed once the basis for processing it, namely paying and checking sick pay, has been handled. The customer as controller is responsible for the legal basis and for who in the employer organisation may handle health data; the applicable provisions are GDPR Article 9(2) and section 5 of the Finnish Act on the Protection of Privacy in Working Life (759/2004).

Deleting a user account anonymises the account immediately: the name and contact details are replaced, sessions are invalidated, the profile picture is removed and the CRM contact is deleted. The same is done automatically for an account that has no active workspace membership and has been unused for 90 days.

Destroying an encryption key has its limits, and it is more honest to say so than to leave it unsaid. Destroying the key makes unreadable only what was encrypted field by field or file by file; the rest is removed from the database and file storage row by row and object by object. In backups taken before the deletion, unencrypted data remains until those backups have rotated out. The cycle is approximately 30 days, so even the last copy predating the deletion is removed within that period. Encrypted data in backups is unreadable as soon as the key has been destroyed.

One thing is worth handling before the 24-month limit: Sutja is not the employer's permanent archive. The duty to provide an employment certificate extends to 10 years from the end of employment, so employment documents such as employment contracts and the source data for certificates must be moved into the organisation's own archive before the 24-month retention period ends. The data export collects the workspace's records in machine-readable form, but attachments must for now be downloaded from the service separately.

Sutja offers customers a data processing agreement under GDPR Article 28 as part of the service terms. The agreement is in force without a separate request and covers the subject matter and purpose of processing, processing on the customer's documented instructions, confidentiality, security, sub-processors, support for data subject rights, personal data breaches, audits and the end of processing.

Appendix 1 to the agreement specifies how the security obligations in section 6 are implemented in practice. The appendix is not published on the website; Sutja provides it to the customer on request at no additional charge.

A signed copy can be downloaded from the Privacy section of the service settings. It can also be requested at tietosuoja@sutja.fi.

If personal data is subject to a breach, Sutja notifies the customer acting as controller without undue delay and within 72 hours of Sutja becoming aware of the breach at the latest.

The initial notification is made as soon as the breach is confirmed, even if not all details have been established, and it is supplemented in phases as the investigation progresses. The customer's own 72-hour deadline for notifying the supervisory authority starts when the customer becomes aware of the breach, so Sutja does not wait for a complete picture before the initial notification.