Contratto di responsabile del trattamento (DPA)

Data Processing Agreement (DPA)

Processing of personal data on behalf of the Customer

Parties

This Data Processing Agreement ("DPA") is a standalone agreement between the Processor and the Customer. It governs all processing of personal data that LogSheet carries out on the Customer's behalf, and it is concluded when the Customer registers a company account and accepts it at sign-up, as described under "Conclusion of this DPA" below.

In this DPA, "Main Agreement" means the service relationship between the parties under which LogSheet provides the LogSheet web and iPhone applications to the Customer — formed when the Customer registers a company account, and continuing for as long as that account is in use. Where the parties later agree separate terms of service or a subscription contract, those become part of the Main Agreement and this DPA continues to apply alongside them. In case of conflict on data-protection matters, this DPA prevails.

1. Subject matter, roles and duration

1.1 Roles. LogSheet is a multi-tenant SaaS application for recording working time, absences, holiday requests and — optionally — client/project time. In respect of the personal data of the Customer's employees and of the Customer's own business contacts entered into the application, the Customer is the controller and LogSheet is the processor within the meaning of Art. 5 let. j and Art. 9 of the Swiss Federal Act on Data Protection of 25 September 2020 ("nFADP / nLPD / revDSG", in force since 1 September 2023) and, where applicable, Art. 4(8) and Art. 28 GDPR.

1.2 Subject matter. LogSheet processes personal data solely to provide, maintain, secure and support the LogSheet web application (logsheet.ch) and the LogSheet iPhone application, as described in the Main Agreement.

1.3 What this DPA does not cover. LogSheet acts as an independent controller, not a processor, for: (a) the account and billing relationship with the Customer; (b) support requests submitted through the in-app support widget and the contact form; (c) technical error diagnostics collected to keep the service running; and (d) visitors of the public logsheet.ch website. Those processing activities are governed by the LogSheet Privacy Policy, not by this DPA. Annex A marks them explicitly.

1.4 Duration. This DPA takes effect on the effective date and remains in force for as long as LogSheet processes personal data on behalf of the Customer, i.e. for the term of the Main Agreement plus the return/deletion period under Clause 12.

2. Nature and purpose of the processing

LogSheet carries out the following processing operations on the Customer's behalf:

The categories of personal data and data subjects are set out in Annex A.

3. Instructions of the Controller

3.1 LogSheet processes personal data only on documented instructions from the Customer, including with regard to transfers to a third country. The Main Agreement, this DPA and the Customer's use of the application's configuration options (roles, departments, absence-privacy setting, retention decisions, exports, deletions) constitute the Customer's documented instructions.

3.2 LogSheet informs the Customer without undue delay if, in its opinion, an instruction infringes the nFADP, the GDPR or another applicable data-protection provision. LogSheet may suspend execution of that instruction until it is confirmed or amended.

3.3 LogSheet does not use the Customer's data for its own purposes, does not sell it, does not use it for advertising, and does not use it to train machine-learning or AI models. LogSheet may compute aggregated, non-identifying usage statistics for capacity planning and service improvement.

3.4 The Customer warrants that it has a lawful basis for the data it enters into LogSheet, that it has informed its employees as required by Art. 19 nFADP (or Art. 13/14 GDPR), and that it complies with Swiss employment-law limits on employee monitoring (in particular Art. 26 ArGV 3 / OLT 3, which prohibits monitoring systems intended to observe employee behaviour).

4. Confidentiality

4.1 LogSheet keeps all personal data processed under this DPA confidential and does not disclose it to third parties except to the sub-processors listed in Annex B, or where required by binding law.

4.2 Access to Customer data in production is limited to the persons who need it to operate and support the service. As of the effective date this is one person: Ben Chaulet, the operator of LogSheet. That person is bound by a confidentiality obligation that survives the end of the engagement. Any future employee, contractor or freelancer with access will be placed under an equivalent written confidentiality undertaking before access is granted.

4.3 Where LogSheet is compelled by law to disclose Customer data to a public authority, it will — unless legally prohibited — inform the Customer beforehand and limit the disclosure to what is legally required.

5. Security of processing (TOMs)

5.1 LogSheet implements appropriate technical and organizational measures ("TOMs") to ensure a level of security appropriate to the risk, in accordance with Art. 8 nFADP and Art. 1–3 of the Data Protection Ordinance (OPDo/DSV), and where applicable Art. 32 GDPR. The measures in force are described in Annex C.

5.2 LogSheet takes into account that the data includes sensitive personal data within the meaning of Art. 5 let. c no. 2 nFADP (data on health), because absences may be recorded as sickness and because free-text remark and approval-comment fields may contain health information. Annex C describes the specific measures applicable to that data.

5.3 LogSheet may update the TOMs at any time, provided the level of protection is not reduced. Material reductions are notified to the Customer in advance.

6. Sub-processing

6.1 General authorization. The Customer grants LogSheet a general authorization to engage sub-processors. The sub-processors engaged at the effective date are listed in Annex B.

6.2 Conditions. LogSheet imposes on each sub-processor, by written contract, data-protection obligations that are substantially equivalent to those in this DPA, and remains fully liable to the Customer for the performance of the sub-processor's obligations.

6.3 Changes. LogSheet informs the Customer at least 30 days before adding or replacing a sub-processor, by e-mail to the Customer's administrative contact and by updating the public sub-processor list at logsheet.ch/subprocessors, which carries the date of its last change (that address resolves to the sub-processor section of the privacy policy). The Customer may object on reasonable, documented data-protection grounds within that period. If the parties cannot agree on a solution, the Customer may terminate the affected part of the Main Agreement without penalty, with effect from the date the change takes effect.

6.4 AI assistant connections (user-initiated export). LogSheet offers an optional connection that allows an authorised user of the Customer to make working-time data available to an AI assistant of the Customer's own choosing, through a read-only interface. The connection is established per user, requires that user to authenticate and to grant explicit consent, is limited to reading data, and may be revoked at any time by the user or by the Customer. Where such a connection is established, the Customer remains the controller and the provider of the AI assistant acts as the Customer's own processor or sub-processor, not LogSheet's: LogSheet neither selects the provider, nor determines the purposes for which the data is used, nor transmits data other than in response to a request authenticated with that user's consent. That provider is therefore not a sub-processor of LogSheet and does not appear in Annex B, and it is for the Customer to put the necessary arrangements in place with it.

Two safeguards apply to every such connection. First, LogSheet pseudonymises the data before it leaves the platform: the names of natural persons are replaced by their initials together with a stable, non-reversible code, e-mail addresses and telephone numbers are masked, and the Customer's own company name is replaced by a code. The provider therefore receives working-time data that is not directly attributable to an identified natural person, and LogSheet does not transmit the identifiers that would make it so. Second, an administrator obtains individually identifiable working-time records only for the periods the employee concerned has validated; for any other period, only aggregated figures covering at least three people are available. The Customer remains responsible for informing its employees of the use of such a connection where its own legal framework requires it.

7. Assistance with data-subject rights

7.1 Taking into account the nature of the processing, LogSheet assists the Customer by appropriate technical and organizational measures in fulfilling its obligation to respond to requests to exercise rights under Art. 25–29 nFADP (access, rectification, deletion, data portability, objection) and, where applicable, Chapter III GDPR.

7.2 If a data subject addresses such a request directly to LogSheet, LogSheet will not answer it on the merits. It will forward the request to the Customer without undue delay and refer the data subject to the Customer as the controller.

7.3 What the application already provides. The Customer can satisfy most requests itself, without LogSheet's involvement:

• Access / portability: monthly and yearly Excel exports, payroll CSV exports, the archives view, and the per-employee yearly calendar.
• Rectification: administrators can correct entries and employment settings for any month that is not locked/approved; a locked month can be reopened by an administrator.
• Deletion: administrators can delete entries and deactivate accounts; the employee can delete their own account in the iPhone app (see Clause 7.4).

7.4 Self-service account deletion and its deliberate limits. The LogSheet iPhone app offers in-app account deletion. When a user triggers it:

• the Firebase Authentication account is deleted and all refresh tokens are revoked — the person can no longer sign in;
• their identifying profile data (display name, e-mail address, date of birth, personnel number) is removed from their user document and replaced with a "Deleted employee" tombstone;
• their timesheets, daily entries and client-work entries are deliberately retained, attached to an identifier that no longer resolves to a person in the system, together with the employment settings (percentage, weekly schedule, vacation allowance) that make those records interpretable.

This is because those records are the Customer's working-time documentation, which the Customer is required by law to retain (Art. 73 para. 2 ArGV 1 / OLT 1: five years) and which are therefore not the employee's to erase. Deletion beyond this can only be instructed by the Customer as controller. LogSheet will not represent to any data subject that more is deleted than actually is.

7.5 Assistance beyond the self-service functions above is provided at LogSheet's reasonable request-based effort; LogSheet may charge for disproportionate effort, after notifying the Customer.

8. Assistance with the Controller's other obligations

LogSheet assists the Customer, taking into account the nature of the processing and the information available to it, with:

• security of processing (Art. 8 nFADP / Art. 32 GDPR) — by providing Annex C and answering security questionnaires within reason;
• data-protection impact assessments (Art. 22 nFADP / Art. 35 GDPR) and prior consultation of the supervisory authority — by supplying the technical information the Customer needs;
• breach notification (Art. 24 nFADP / Art. 33–34 GDPR) — as set out in Clause 9.

9. Personal data breaches

9.1 Notification to the Customer. LogSheet notifies the Customer of any breach of data security affecting the Customer's personal data without undue delay and in any event within 48 hours of becoming aware of it, by e-mail to the Customer's administrative contact and, where a faster channel is warranted, by telephone.

9.2 Content. The notification describes, as far as known at the time: the nature of the breach; the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address it and to mitigate its effects; and a contact point for further information. Where information is not available at once, it is supplied in phases without further undue delay.

9.3 Roles. The Customer, as controller, is responsible for assessing whether the breach is likely to result in a high risk to the personality or fundamental rights of the data subjects and, if so, for notifying the Federal Data Protection and Information Commissioner (FDPIC/PFPDT/EDÖB) as soon as possible under Art. 24 para. 1 nFADP, and/or the competent EU supervisory authority within 72 hours under Art. 33 GDPR, and for informing the data subjects where required. LogSheet does not make that notification on the Customer's behalf unless expressly instructed in writing.

9.4 Cooperation and records. LogSheet cooperates with the Customer in the investigation and remediation, and documents the facts of the breach, its effects and the remedial action taken.

10. Audit rights

10.1 LogSheet makes available to the Customer all information necessary to demonstrate compliance with this DPA, in the first instance in the form of this DPA's annexes, its security documentation, and the certifications and audit reports of its sub-processors (in particular Google Cloud's ISO/IEC 27001, 27017, 27018 and SOC 2/3 reports, available from the Google Cloud compliance portal).

10.2 If those documents are not sufficient, the Customer may — at its own cost, no more than once per calendar year except after a personal data breach, with 30 days' written notice, during business hours and subject to confidentiality — conduct an audit, or mandate an independent auditor who is not a competitor of LogSheet to do so. The audit must not disrupt the service or compromise the confidentiality of other customers' data.

10.3 Audits of the sub-processors' own data centres are excluded; for those, the sub-processors' certifications and audit reports apply. LogSheet has no physical access to Google Cloud infrastructure.

11. International transfers and data location

11.1 Primary storage location. The Customer's application data — user profiles, timesheets, daily entries, absences, client/project data, invoices, notifications, backups — is stored in Google Cloud Firestore in the `nam5` multi-region — the United States (confirmed in the Firebase console on 29 July 2026). The Cloud Functions that process this data run in the `europe-west6` (Zurich, Switzerland) region, so the processing logic is Swiss while the database itself is not. The transfer of personal data to the USA relies on Google LLC's certification under the Swiss–U.S. Data Privacy Framework and the EU–U.S. Data Privacy Framework, together with the Standard Contractual Clauses with the Swiss addendum in the Google Cloud Data Processing Addendum.

11.2 Services not region-bound. The following components are provided by Google on a global infrastructure and are not confined to Switzerland:

• Firebase Authentication (identitytoolkit.googleapis.com) — stores the e-mail address, the password hash, the account identifier (UID) and sign-in timestamps. Google does not offer a Swiss/EU-only residency option for this service; processing may take place in the United States.
• Firebase Hosting — the static web application is served from Google's global CDN; server logs may be processed outside Switzerland.
• App Check (reCAPTCHA v3 on the web, Apple App Attest on iOS) — attestation tokens and, for reCAPTCHA, IP address and interaction signals.
• Google Analytics for Firebase — public website only, consent-gated; see Clause 11.5.

11.3 Legal mechanism. Transfers to the United States are covered by (i) the adequacy decision of the Swiss Federal Council recognizing the Swiss–U.S. Data Privacy Framework (Google LLC is certified under the EU–U.S. DPF and its Swiss extension), and, as a complementary safeguard, (ii) the Standard Contractual Clauses with the Swiss addendum contained in Google's Cloud Data Processing Addendum, to which LogSheet has subscribed. The Customer acknowledges these mechanisms.

11.4 Outbound e-mail. Transactional e-mail (verification, password reset, employee welcome, reminders, digests, operational notices) is sent through the authenticated SMTP relay of Hostpoint AG (Rapperswil-Jona, Switzerland), from the info@logsheet.ch mailbox, over implicit TLS on port 465. The message content — recipient address, display name, and the subject of the notification — transits and is stored on Swiss infrastructure. Onward delivery to the recipient's own mail provider is outside LogSheet's control.

11.5 Analytics. Google Analytics for Firebase runs only on the public logsheet.ch website, only after the visitor accepts the cookie banner, and never in the iPhone application (the mobile build aliases analytics to a no-op module). No analytics or advertising SDK processes data inside the authenticated application. No third-party advertising, attribution or session-replay SDK is present in either application — this has been verified against the dependency manifests of all three packages (web, functions/, TimeSheetApp/).

11.6 iCal feed. Where an employee activates the optional calendar feed, absence events are served from a Cloud Functions endpoint (europe-west6) over HTTPS, authenticated by an unguessable token embedded in the subscription URL. The feed carries the employee's own name and absence entries, and the labels of absences are the categories listed in Annex A. Once subscribed, a copy of that data resides with the employee's chosen calendar provider (e.g. Apple, Google, Microsoft), which is outside LogSheet's and the Customer's control and outside the scope of this DPA. The employee can invalidate and rotate the token at any time from the application.

12. Return and deletion on termination

12.1 On termination of the Main Agreement, the Customer may, within 30 days, export its data itself through the application's Excel, CSV and PDF export functions. On written request within the same period, LogSheet will provide an additional export of the Customer's tenant data in a structured, commonly used, machine-readable format.

12.2 After that period, LogSheet deletes the Customer's personal data, including from active systems, within 90 days, unless Swiss or EU law requires further retention. Residual copies in Google Cloud's automated backups are overwritten in the ordinary backup cycle.

12.3 The Customer acknowledges that it, as employer, is subject to statutory retention obligations for working-time records (five years under Art. 73 para. 2 ArGV 1 / OLT 1, and ten years for accounting-relevant records under Art. 958f CO) and that it is the Customer's responsibility to export and retain those records before deletion is carried out.

12.4 On request, LogSheet confirms deletion in writing.

13. Liability, term and miscellaneous

13.1 Liability between the parties is governed by the Main Agreement and, failing terms agreed there, by Swiss law. Nothing in this DPA limits a data subject's rights against either party under applicable data-protection law.

13.2 This DPA is governed by Swiss law, excluding conflict-of-law rules and the CISG. The place of jurisdiction is Luzern, subject to any mandatory place of jurisdiction.

13.3 Where the GDPR applies to the Customer's processing, this DPA is to be read as also satisfying Art. 28(3) GDPR, and the parties will conclude the EU Standard Contractual Clauses if and to the extent legally required.

13.4 Amendments must be in writing (electronic form sufficient). If any provision is invalid, the remainder stands.

Conclusion of this DPA

This DPA stands on its own and is concluded electronically; no signature is required for it to bind either party. The Customer concludes it when registering its company account: the registration form states that the person registering accepts the privacy policy and this Data Processing Agreement on behalf of the company, and links to both. LogSheet records the date of that acceptance together with the account.

The person who registers the account warrants that they are authorized to conclude this DPA on behalf of the Customer.

A countersigned PDF copy, and a version bearing the Customer's own company details, are available on request to info@logsheet.ch.

Annex A — Categories of data and data subjects

Reflects the data model actually persisted by the application as of 29 July 2026 (Firestore collections `users`, `timesheets` and subcollections, `projectTimesheets`, `customers`, `projects`, `invoices`, `notifications`, `archives`, `icalTokens`, `holidays`, `announcementAssignments`, `officeTaskAssignments`).

A.1 Categories of data subjects

A.2 Categories of personal data — processed by LogSheet as processor

A.3 Categories of personal data — processed by LogSheet as controller (outside this DPA)

A.4 Frequency and volume

Continuous processing for the term of the Main Agreement. Volume: one record set per employee per working day, plus monthly summaries and weekly backup snapshots.

Annex B — Sub-processors

As of 29 July 2026. Verified against `firebase.json`, `.firebaserc`, `src/firebase.js`, `functions/index.js` and the dependency manifests of all three packages.

Notes

• No payment processor. LogSheet integrates no payment provider (no Stripe, no PayPal). Plan management is internal (free / enterprise, with a grandfathering rule); billing, if any, is handled outside the application.
• No analytics, advertising, attribution, session-replay, error-tracking or CRM SDK beyond the Google Analytics measurement described above. Verified: no Sentry, PostHog, Mixpanel, Amplitude, Segment, Intercom, Crisp, Hotjar, Clarity, Meta/LinkedIn/TikTok pixel, Plausible or Matomo in any of the three dependency manifests.
• The iPhone application contains no analytics at all — the mobile build resolves the analytics module to a deliberate no-op.
• The public website embeds two static badge images (Product Hunt, PostYourStartup). Both are served from LogSheet's own domain, so displaying them causes no request to any third-party host and discloses no visitor IP address.

Annex C — Technical and organizational measures (TOMs)

Art. 8 nFADP and Art. 1–3 OPDo/DSV; Art. 32 GDPR where applicable. Every measure below corresponds to something actually implemented in the codebase or the Firebase project as of 29 July 2026. Known gaps and planned improvements are listed here deliberately rather than omitted.

C.1 Confidentiality — access control

Tenant isolation. Every document carries a companyId, and every read and write is gated by Firestore security rules that compare it to the caller's own company. Collection-group queries over daily entries and client-work entries are filtered on companyId at the rule level, so a client that omitted the filter would be rejected rather than served another tenant's data. The rules file is treated as a wire contract and is covered by an automated test suite (30 tests) that must pass before the rules are deployed.

Role model. Three roles (user, admin, super_admin), plus a delegation mechanism: an administrator can grant an individual employee access to specific admin tabs only, optionally restricted to one or more departments and made read-only (settings.viewableDepartments). The department scoping is enforced in the security rules, not only in the interface, and reads the target's department live from the owner's user record rather than from a client-supplied value.

Server-side authority. Sensitive operations run in Cloud Functions with the Admin SDK and re-check the caller's rights server-side: company creation, employee-account creation, domain verification, orphan-account cleanup, account deletion, iCal token issuance. A client cannot perform them by manipulating the interface.

Least privilege in operations. Production access is limited to the operator (Clause 4.2). Administrative scripts read their credentials from .env, which is git-ignored.

C.2 Confidentiality — pseudonymization and data minimization

• Sickness privacy control: a company-level setting hides the reason for a colleague's absence from other employees; a scoped viewer sees "Absent" instead of "Sick". An employee always sees the real reason on their own row. Enforced through a shared hook used by both the web and the mobile client, so the two cannot drift apart.
• Account deletion is a tombstone, not a purge: identifying fields are removed and replaced with a non-identifying marker while the working-time record — which the employer must keep — remains attached to an identifier that no longer resolves to a person (Clause 7.4). This is pseudonymization by design.
• Error logs are truncated: error message and context are capped at 1 000 characters and the user-agent at 300, and identical errors are de-duplicated within a 60-second window, so diagnostics stay minimal.
• No employee-behaviour monitoring: the application records working time as the employee enters it. There is no keystroke, screenshot, location or activity surveillance. lastActive is a single timestamp used to show presence in the team view.
• Non-enumerating authentication: the password-reset and login-help flows return the same response whether or not the address exists, and are rate-limited server-side.

C.3 Confidentiality — encryption

• In transit: HTTPS/TLS everywhere. HSTS is set with max-age=63072000; includeSubDomains; preload. Outbound SMTP uses implicit TLS on port 465.
• At rest: all Firestore and Cloud Functions data is encrypted at rest by Google Cloud (AES-256, Google-managed keys) by default.
• Passwords: stored and verified exclusively by Firebase Authentication (scrypt-based); LogSheet never sees or stores a password. A client-side strength checklist is enforced at sign-up and password change.
• Secrets: the SMTP password is held in Google Secret Manager and injected into the functions that need it; no credential is committed to the repository. Historic hard-coded script passwords were removed in July 2026 but remain in the git history until rotated.

C.4 Confidentiality — application and platform hardening

• App Check attests that requests come from the genuine application: reCAPTCHA v3 on the web, Apple App Attest on iOS. Enforcement is currently switched on for Firebase Authentication (`identitytoolkit`) and off for Firestore (verified 27 July 2026). Turning Firestore enforcement on is a deliberate pending decision, because it must be sequenced behind the mobile force-update gate.
• Strict Content-Security-Policy on every response, with frame-ancestors 'none', object-src 'none', base-uri 'self', form-action 'self' and an explicit connect-src allow-list; plus X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy disabling camera, microphone, geolocation, payment and USB.
• Registration control: self-registration is only possible for e-mail domains the company has proven it controls, through a DNS-TXT record or an ownership e-mail to a standard mailbox. Free and disposable e-mail domains are refused against a denylist of over 12 000 entries. The company list is not publicly readable; lookup goes through a server-side callable.
• Rate limiting on password reset and login-help requests, keyed per address and enforced server-side.
• iCal feed is protected by a 192-bit random token (crypto.randomBytes(24)), which the employee can rotate at will; an unknown token returns 404, not 401, so a scanned token cannot be distinguished from a typo. The feed is a bearer-URL capability by design — anyone holding the URL can read it. This is inherent to the iCal standard; it is documented for employees and the token is rotatable.

C.5 Integrity

• Firestore security rules are the single enforcement point for writes and are covered by an automated test suite.
• Month locking / approval: an approved month is frozen; the automatic backup job explicitly skips approved months so an archive cannot be silently overwritten.
• Persisted field names are treated as a frozen contract between the web and iPhone clients (fields may be added, never renamed), which prevents silent data corruption across the 24–48 h App Store release gap.
• Invoice numbering is allocated in a Firestore transaction, so two administrators cannot collide.
• Silent-failure detection: every rejected database write is captured, recorded and e-mailed to the operator, so a permission or quota failure cannot silently lose an employee's data.

C.6 Availability and resilience

• Google Cloud Firestore in nam5 provides multi-region replication and automated platform-level backup within that multi-region (United States).
• Application-level backup: a scheduled Cloud Function (snapshotWeeklyTimesheets, every Monday 03:00 Europe/Zurich) writes a snapshot of every non-approved month's daily entries and totals into a backups subcollection. Snapshots are idempotent per ISO week. Administrators can restore from a snapshot in the interface.
• Users can export their own and their company's data at any time to Excel, CSV or PDF — an independent, offline copy the Customer controls.
• Cloud Functions run with a capped maximum instance count, limiting runaway cost and load.

C.7 Regular testing, assessment and evaluation

• Automated unit tests for the shared business logic (npm run test:unit) and a dedicated Firestore-rules test suite (npm run test:rules), both run in CI on every push and pull request, for the web package and the mobile package separately.
• Linting with zero-warning tolerance in CI.
• A documented read-only scalability and security audit was conducted in July 2026; its critical finding (an over-broad archives read rule) was fixed, and the remaining findings are tracked with explicit owner decisions.
• Dependencies are pinned in lockfiles and updated deliberately.

C.8 Organizational measures

• Data protection is the operator's personal responsibility; the operator is the single point of contact at info@logsheet.ch.
• Confidentiality obligations as per Clause 4.2.
• Sub-processor contracts: the Google Cloud Data Processing Addendum; the Apple Developer Program agreements; and, for Hostpoint AG, the data-processing terms contained in its General Terms and Conditions, which meet the requirements of the Swiss revFADP and apply to the account automatically, without a separate signature. A dated copy of each is on file.
• Incident handling: operational alerts (database errors, new sign-ups, support tickets) are delivered by e-mail to the operator; breach handling follows Clause 9.
• A written incident-response runbook and a documented retention and deletion schedule are in place. A documented onboarding procedure for any future person with production access is an open item; none exists today because access is limited to one person (Clause 4.2).

C.9 Measures specific to sensitive data (health)

• Sick days are stored as a category on a day record, not as a diagnosis. LogSheet does not request, and the interface does not ask for, medical detail.
• The company-level absence-privacy setting restricts the visibility of the reason for an absence to the person concerned and to authorized administrators (C.2).
• Free-text remark and approval-comment fields may contain health information. The Customer, as controller, must instruct its administrators not to record medical detail in those fields. The application supports that instruction: a standing hint is displayed next to every free-text remark and approval-comment field, asking users not to enter medical or other sensitive detail.
• The same access-control, encryption, tenant-isolation and retention measures apply to this data as to all other data; no separate export path or lower-protection channel exists for it.

End of document. Template — to be reviewed by a Swiss data-protection lawyer before use.