Skip to main content
The revised Federal Act on Data Protection (nDSG) governs how the platform handles personal data. HR data is squarely within its most sensitive categories — health data, in the case of sick leave and medical certificates.

​
Controller and processor

Swiss HR Easy is deployed single-tenant. Each customer operates their own environment and is the data controller for it. The platform vendor’s role is defined by the agreement between the parties; the product’s job is to make compliant operation possible.

​
Data residency

Credentials and tokens are never stored as plaintext. A field holding a credential, session token or API key must use the application-layer encryption utilities — a raw String? column for such a value is a defect. See Security conventions.

​
AI and third-country processing

Where AI features are enabled, content is sent to the model and embedding providers for processing. This is disclosed in the transparency notice, is optional per installation, and is auditable — every AI call is recorded as AI_OPERATION. Applicants can decline AI processing entirely, and withdrawing consent deletes both the generated output and the derived search index entry. See AI transparency. The MCP connector is a separate channel: an external assistant (Claude, for example) reads records through a person’s own connection. Before enabling it, the installation as controller needs a processor agreement with each assistant vendor, a processing-register entry for the connector, and staff information under Art. 19 nDSG — the assistant sees whatever the connected person may see. HR Easy supplies the rest: every call is audited, each person sees in Portal → Connections which assistants read their record and on whose behalf, and a daily allowance limits how many person records one connection may read.

​
Data subject rights

Requests arrive through a public endpoint — the requester is often a former employee or a rejected applicant with no account — protected by CAPTCHA that fails closed on a partial configuration, identity verification by confirmation link, and a cooling period between requests. See Audit and DSAR.

​
Retention

Erasure is not absolute. Swiss law requires records to be kept: A DSAR response states what was erased and what was retained, with the legal basis. Quietly retaining data is not a compliant response.

​
Processing records and logging

  • Every state-changing operation is audited: who, what, when, before and after.
  • Sensitive values are masked before storage; client IPs are truncated.
  • Structured logs go to Application Insights with correlation IDs, without personal data in log messages.
console.* is banned in application code precisely because ad-hoc logging is how personal data ends up in a log aggregator nobody has a retention policy for. All output goes through the structured loggers.

​
Security posture

  • Role-based access control with ownership checks on every HTTP verb.
  • Session-based authentication with secure cookies; SSO through Entra ID.
  • Magic links signed, expiring, and compared in constant time.
  • Redirect targets validated as https:// before use.
  • No tokens in Location: headers or query strings.
  • Secrets in Key Vault, rotated with documented procedures.

​
Breach notification

The nDSG requires notification to the EDÖB where a breach is likely to result in a high risk to the data subjects. The technical side of detection and response is in the incident runbook.
The incident runbook does not yet cover the breach assessment or the EDÖB notification decision. Those remain the controller’s process, and an incident with a suspected data exposure must be escalated to the data-protection contact alongside the technical response.
This page describes what the platform provides. It is not legal advice, and it does not discharge the controller’s obligations — a privacy notice, a processing register and a data-protection impact assessment remain the operating organization’s responsibility.