Taskiim — Data Processing Agreement

Effective date: 13 August 2026 Last updated: 15 August 2026

This Data Processing Agreement (“DPA”) forms part of the Terms of Service between Arif Setyo Wibowo (“Processor”, “Taskiim”) and the customer organisation accepting those Terms (“Controller”, “you”). It applies whenever we process personal data on your behalf.

Where this DPA conflicts with the Terms, this DPA prevails for matters of personal data protection.

1. Roles

You are the controller of the personal data contained in your workspace. You determine what personal data is entered, whose it is, who may access it, and how long it is kept. We are the processor, acting only on your documented instructions.

Using the Service in accordance with its documentation constitutes your documented instruction. If we believe an instruction breaches applicable data protection law, we will inform you and may suspend that processing.

2. Subject matter and scope

Item	Detail
Subject matter	Provision of the Taskiim project and task management service
Duration	The term of the Terms, plus the deletion period in section 9
Nature and purpose	Hosting, storage, transmission, display, malware scanning, backup, and support of workspace data
Types of personal data	Names, email addresses, profile pictures, roles and organisational placement; the content of tasks, comments and files, which may contain any personal data you choose to enter; working time records, timer notes, approval decisions and rejection reasons; IP addresses and user-agent strings in session records and audit entries
Categories of data subject	Your employees, contractors and invited members; your clients’ contact persons; any individual mentioned in the content your users create
Special category data	Not requested and not required. You should not enter health, biometric, religious, political or similar data into free-text fields. If you do, you remain responsible for the additional conditions that apply to it.

3. Our obligations

We will:

process personal data only on your documented instructions, including for international transfers, unless legally compelled otherwise (and then, where permitted, we will tell you first);
ensure personnel authorised to process personal data are bound by confidentiality;
implement the technical and organisational measures described in Annex A;
respect the conditions in section 5 for engaging sub-processors;
assist you, taking into account the nature of processing, in responding to data subject requests (section 6);
assist you with data protection impact assessments and prior consultations, and with your own security and breach-notification obligations;
delete or return personal data at the end of the term as set out in section 9;
make available the information necessary to demonstrate compliance, and allow for audits as set out in section 8.

4. Your obligations

You will:

ensure you have a lawful basis for the personal data you enter, and have given the required notices to the individuals concerned — this applies with particular force to the time tracking and audit log features, which record identified individuals’ activity, and which in many jurisdictions require prior notice to, or consultation with, employees;
configure roles and permissions so that access is limited to those who need it;
keep the personal data in your workspace accurate and no more extensive than necessary;
not enter personal data into the public demo workspace, which is shared with strangers and erased on a schedule.

5. Sub-processors

You give general authorisation for us to engage sub-processors. We impose data protection obligations on each that are no less protective than this DPA, and we remain liable for their performance.

Current sub-processors:

Sub-processor	Purpose	Location
Hetzner Online GmbH	Server hosting, database, object storage	Germany
Cloudflare, Inc.	DNS, TLS termination, reverse proxy, DDoS protection	Global edge network
Resend (Plus Five Five, Inc.), sending via Amazon SES	Delivery of transactional and notification email	Ireland (eu-west-1)
Google LLC	Google Sign-In identity verification (only for users who choose it)	Global
Lemon Squeezy, LLC	Sale, payment processing and tax handling for paid subscriptions, as Merchant of Record (only for workspaces that buy a paid plan)	United States

Lemon Squeezy acts as an independent controller for the payment transaction itself — it is the seller of record, and it decides what it must retain to meet its own tax and anti-fraud obligations. It is listed here because the billing contact’s name and email reach it through us. Card and bank details are given by the payer directly to Lemon Squeezy and never pass through, or rest in, our systems.

We will give at least thirty (30) days’ notice before adding or replacing a sub-processor. You may object on reasonable data protection grounds within that period; if we cannot accommodate the objection, you may terminate the affected part of the Service without penalty.

6. Data subject requests

The Service lets you access, correct, export and delete workspace data directly. Where a data subject contacts us instead of you, we will not respond substantively but will refer them to you and forward the request without undue delay. We will provide reasonable assistance if you cannot fulfil a request using the Service’s own functionality.

7. Personal data breach

We will notify you without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting your personal data. The notice will describe, so far as known, the nature of the breach, the categories and approximate number of data subjects and records involved, the likely consequences, the measures taken or proposed, and a contact point.

Notifying regulators and data subjects is your responsibility as controller; we will provide the information and assistance you reasonably need to do so within your own deadlines.

8. Audit

On reasonable written notice, not more than once per year (unless required by a regulator or following a breach), we will provide the information necessary to demonstrate compliance with this DPA and respond to a reasonable security questionnaire. Where a documentary review is genuinely insufficient, we will permit an on-site audit by you or an independent auditor bound by confidentiality, at your cost, during business hours, and in a manner that does not disrupt the Service or compromise other customers’ data.

9. Deletion and return

On termination, and at any time on your written request, we will delete personal data in your workspace within thirty (30) (thirty) days, except where retention is required by law. You may export your data using the Service’s export functions before then, and may request an export from us within thirty (30) days of termination.

Backups rotate on a 30-day cycle, so data deleted from the live system may persist in a backup for up to 30 days afterwards. Data held in a backup is not processed for any other purpose while it awaits deletion.

10. International transfers

Where personal data is transferred out of the EEA or the UK, the parties agree that the European Commission’s Standard Contractual Clauses (Module Two, controller to processor), and the UK Addendum where applicable, are incorporated by reference, with this DPA and its annexes supplying the required details. For Indonesian personal data, the transfer conditions of UU PDP apply, and we maintain the safeguards described in Annex A.

11. Liability

Each party’s liability under this DPA is subject to the limitations in the Terms.

Annex A — Technical and organisational measures

Access control and authentication

No passwords exist in the system; authentication is via Google Sign-In or passkeys (WebAuthn). For passkeys we hold only public keys — no biometric data ever leaves the user’s device.
Refresh tokens and invitation tokens are stored only as hashes.
Sessions rotate on every use; presenting an already-used token revokes the whole session family, containing a stolen session automatically.
Refresh tokens are delivered in httpOnly, Secure cookies scoped to the authentication endpoints, keeping them out of reach of page scripts.

Authorisation

Role-based access control with a fixed permission catalogue; roles are configurable per workspace.
Permissions are read from the database on every request rather than embedded in a token, so revoking access takes effect immediately rather than at token expiry.
Routes are closed by default and must be explicitly opened.

Tenant isolation

Every business record carries its workspace identifier; the data-access layer injects that identifier into every read, write and create, and refuses to execute a query with no workspace context rather than returning all rows.
Automated integration tests run against a real database and assert that one workspace cannot read, fetch, or update another’s records.

Encryption

TLS for all data in transit; the service is served over HTTPS only.
Encryption at rest as provided by the hosting platform’s storage layer.

File handling

Files are identified from their actual content, not their declared type; types outside the accepted list are refused.
Documents carrying macros are refused, which catches a renamed macro-enabled file that is otherwise structurally valid.
Every upload is scanned for malware before it is stored. If the scanner is unreachable the upload is refused — an outage cannot become a bypass.
Object storage is private; files are served only through short-lived presigned links minted per request from a database record, so revoking access is a record change rather than an object change.
Uploaded filenames never form part of the storage key, preventing path traversal and collisions.

Logging and accountability

Append-only audit log per workspace recording actor, action, entity, changes, timestamp, IP and user-agent.
No personal data of public demo visitors is recorded at all.

Resilience

Automated database backups every six hours, retained 30 days, written to object storage in a bucket separate from the one the application itself can reach — so credentials compromised in the application cannot destroy the restore points.
Every backup is verified with pg_restore before it is kept; an unreadable dump is discarded rather than counted.
Restores are exercised against a scratch database using a scripted procedure (restore-postgres.sh --verify), most recently on 13 August 2026.
Rate limiting on the API.
Container restart policies and health checks on every service.

Organisational

Access to production systems limited to personnel who require it.
Confidentiality obligations for all personnel with access.
Changes deployed through version control and automated pipelines.