When a customer, an employee, or even a random website visitor sends your company an email asking "What data do you have about me?", how you respond is not just good practice โ it is a legal obligation under Swiss law. Since 1 September 2023, the new Federal Act on Data Protection (nFADP, known as nDSG in German and nLPD in French) has strengthened data subject rights significantly, and Swiss SMEs are expected to handle these requests promptly, accurately, and free of charge.
Yet the reality on the ground is troubling. Most small and medium enterprises in Switzerland have never received a formal access request, have no documented procedure in place, and would not know where to begin if one arrived tomorrow. This guide changes that. It walks you through every data subject right established by the nFADP, explains the practical steps for handling requests, highlights the exceptions that allow you to push back when appropriate, and compares the Swiss framework with the GDPR so you understand exactly where you stand.
Why data subject rights matter for your business
Data subject rights are not an abstract legal concept reserved for multinational corporations. They are the mechanism through which any person can hold your business accountable for the way you handle their personal data. Under the nFADP, these rights apply regardless of the size of your company, the volume of data you process, or whether you operate exclusively within Switzerland.
The Federal Data Protection and Information Commissioner (FDPIC) โ the Swiss supervisory authority (known as EDรB in German and PFPDT in French) โ has repeatedly emphasised that compliance with data subject rights is a priority area. The FDPIC's published guidance at edoeb.admin.ch makes clear that even SMEs must be able to demonstrate they can respond to these requests within the legal timeframe.
The practical stakes are significant:
- Penalties: Failure to comply with information obligations can trigger sanctions under Art. 60 nFADP, with fines up to CHF 250,000 against the responsible individual
- Reputational damage: A mishandled access request can escalate into an FDPIC investigation and public reporting
- Customer trust: Properly handling data requests signals professionalism and builds confidence
- Competitive advantage: In B2B relationships, demonstrating mature data governance increasingly influences vendor selection
The right of access (Art. 25 nFADP)
The right of access is the cornerstone of data subject rights under the nFADP. It allows any person to ask a controller whether personal data concerning them is being processed and, if so, to receive a comprehensive set of information about that processing.
What the data subject can request
Under Art. 25 para. 2 nFADP, the data subject is entitled to receive:
- The identity and contact details of the controller
- The personal data processed as such (the actual data, not just a summary)
- The purpose of the processing
- The retention period for the data, or the criteria used to determine it
- The available information on the origin of the data (if not collected directly from the data subject)
- Any automated individual decision-making (Art. 21 nFADP), including the logic involved
- The recipients or categories of recipients to whom data is disclosed
- Where applicable, information about cross-border data transfers, including the destination countries and the safeguards in place
This is a broader disclosure obligation than many SMEs realise. It is not sufficient to confirm "yes, we have your email address". You must provide all the data you hold, explain why you have it, disclose who has seen it, and indicate how long you will keep it.
The 30-day deadline
The controller must respond within 30 days of receiving the access request (Art. 25 para. 6 nFADP). This period starts from the day the request is received, not from the day you acknowledge it or verify the requester's identity.
If the request is particularly complex or involves a very large volume of data, you may extend this period. However, you must:
- Inform the data subject of the extension within the initial 30 days
- Provide specific reasons for the delay
- Indicate the expected response date
In practice, the 30-day window passes quickly. If you have no procedure in place, identifying all relevant data across email inboxes, CRM systems, analytics platforms, paper files, and backup tapes within a month is a serious challenge. This is where having a systematic data inventory โ such as one maintained through PrivaGuard's processing register โ becomes invaluable.
Form and delivery of the response
The information must be provided in writing (including electronically), in a precise, transparent, understandable, and easily accessible form (Art. 25 para. 5). The nFADP does not prescribe a specific format, but best practice suggests:
- A structured letter or PDF covering each category of information
- An annex containing the actual data (database exports, copies of correspondence, etc.)
- Clear language, avoiding unnecessary legal jargon
- Delivery through a secure channel (encrypted email, registered post, or a secure download link)
Free of charge โ with exceptions
The provision of information must be free of charge as a matter of principle (Art. 25 para. 6 nFADP). However, the Federal Council's implementing ordinance (the FADPO, or DSV in German) allows the controller to charge a reasonable fee in two specific situations:
- Excessive effort: When the request requires disproportionate effort, for example because the data subject makes repeated requests within a short period
- Information already provided: When the same information was recently communicated to the data subject
The fee must be proportionate to administrative costs and must be communicated to the requester before the information is provided. The requester then has the option to withdraw or narrow the request.
Important: Charging a fee should be the exception, not the rule. The FDPIC has indicated that controllers who routinely charge for access requests will face scrutiny.
The right to data portability (Art. 28 nFADP)
The right to data portability is a new addition under the revised nFADP, reflecting the growing recognition that personal data should not be locked into proprietary systems.
What portability means in practice
Under Art. 28 nFADP, any data subject may request that their personal data be provided in a commonly used electronic format. If the controller processes data by automated means, the data subject can also request that the data be transmitted directly to another controller, provided this is technically feasible and does not require disproportionate effort.
The key elements:
- Machine-readable format: The data must be provided in a structured, commonly used format (e.g., CSV, JSON, XML)
- Direct transfer: Where technically feasible, the data subject can request transmission to a new service provider
- Scope: Only data provided by the data subject or generated through their use of the service (not inferred data or analytical outputs)
- Free of charge: The same free-of-charge principle applies
Practical example
A customer switching from one Swiss cloud accounting platform to another can request that their transaction history, contact records, and uploaded documents be exported in CSV format and either downloaded or transmitted directly to the new provider. The original platform cannot refuse on the grounds that it would benefit a competitor.
Comparison with GDPR portability (Art. 20 GDPR)
The GDPR right to data portability under Art. 20 is limited to data processed on the basis of consent or a contract and carried out by automated means. The nFADP portability right is broader in one respect โ it is not restricted to specific legal bases โ but narrower in another, as it applies only where the controller processes data by automated means and transfer is technically feasible without disproportionate effort.
The right to rectification and erasure
While the nFADP does not create a standalone "right to rectification" or "right to erasure" in the same explicit manner as Articles 16 and 17 of the GDPR, the same outcomes are achieved through the general data processing principles in the Act.
Rectification
Under Art. 6 para. 5 nFADP, anyone who processes personal data must ensure that the data is accurate. If the data subject demonstrates that their personal data is inaccurate, the controller must rectify it. The data subject can assert this right in combination with the right of access โ once they see what data is held, they can challenge its accuracy.
Practical tip: When a data subject requests rectification, document the original data, the correction requested, the date of the change, and the evidence provided. This audit trail protects you in case of a later dispute.
Erasure
The right to request erasure arises from the purpose limitation and proportionality principles (Art. 6 nFADP). When personal data is no longer necessary for the purpose for which it was collected, or when the data subject withdraws consent and no other legal basis applies, the controller must delete the data.
Important limitations: Erasure requests do not override legal retention obligations. Swiss commercial law requires businesses to retain accounting records for 10 years (Art. 958f CO), and employment law mandates retention of certain personnel records. Where such obligations exist, the controller must inform the data subject that the data cannot be deleted but that its processing will be restricted to the legally required purpose.
The right to object to automated individual decision-making (Art. 21 nFADP)
The nFADP addresses automated individual decision-making in Art. 21, which grants data subjects the right to be informed when a decision that significantly affects them is made exclusively by automated means, and the right to request that the decision be reviewed by a natural person.
This is relevant for SMEs that use:
- Automated credit scoring or risk assessment
- Algorithmic hiring or CV screening
- Automated insurance underwriting
- AI-powered customer categorisation
If your business makes decisions with legal or similarly significant effects on individuals using purely automated processes, you must:
- Inform the data subject that the decision was automated
- Allow them to express their views
- Offer the possibility of human review
Comparison with GDPR Art. 22
The GDPR's Art. 22 creates a general prohibition on automated individual decision-making with legal effects, subject to specific exceptions. The nFADP takes a lighter approach โ it does not prohibit such processing but requires transparency and the possibility of human intervention.
Restrictions and exceptions (Art. 26 nFADP)
Not every data subject request must be granted in full. Art. 26 nFADP allows the controller to restrict, defer, or refuse the provision of information in specific circumstances.
Grounds for restriction
The controller may restrict the right of access when:
- A formal law requires it โ for example, anti-money-laundering legislation may prevent disclosure of certain monitoring activities
- Overriding interests of a third party require protection โ for example, where disclosure would reveal information about another identifiable person
- The controller's own overriding interests justify it โ but only if the data is not disclosed to third parties. This is a significant limitation: you cannot use your own interest as a shield if you have already shared the data
- A public interest requires it โ for example, in the context of an ongoing official investigation
How to apply restrictions in practice
If you rely on a restriction under Art. 26, you must:
- Document your reasoning in detail
- Inform the data subject that their request has been restricted and the reasons for the restriction (unless providing the reasons would itself defeat the purpose of the restriction)
- Provide the information that can be disclosed, even if other parts are restricted
- Consider whether a partial disclosure is possible
Critical point: The burden of proof lies with the controller. If an FDPIC investigation or court challenge arises, you must be able to demonstrate that the restriction was justified, necessary, and proportionate.
The FDPIC's role
If a data subject disagrees with a restriction, they can file a complaint with the FDPIC. The FDPIC has the power to investigate, mediate, issue recommendations, and โ since the 2023 revision โ issue binding decisions ordering the controller to comply (Art. 51 nFADP). This is a significant change from the old regime, where the FDPIC could only issue non-binding recommendations.
Comparison with GDPR data subject rights (Arts. 15โ22 GDPR)
Swiss SMEs that also serve EU customers or have EU-based employees need to understand how nFADP rights compare with their GDPR equivalents. Here is a practical comparison:
| Right | nFADP | GDPR | Key difference |
|---|---|---|---|
| Access | Art. 25 โ 30-day deadline | Art. 15 โ 1-month deadline | Substantially similar |
| Portability | Art. 28 โ machine-readable format | Art. 20 โ structured, commonly used format | GDPR limits to consent/contract; nFADP broader legal bases |
| Rectification | Art. 6 para. 5 โ accuracy principle | Art. 16 โ explicit right | Same outcome, different structure |
| Erasure | Purpose limitation + proportionality | Art. 17 โ explicit "right to be forgotten" | GDPR more explicit; nFADP achieves same result |
| Restriction of processing | Art. 26 โ restriction grounds | Art. 18 โ explicit right | GDPR has a standalone right; nFADP does not |
| Object to processing | Limited (automated decisions, Art. 21) | Art. 21 โ broad right to object | GDPR broader; nFADP narrower |
| Automated decisions | Art. 21 โ transparency + human review | Art. 22 โ prohibition with exceptions | GDPR stricter (prohibition); nFADP lighter (transparency) |
Practical implication: If you comply with the GDPR, you largely comply with the nFADP on data subject rights โ but not entirely. The nFADP has its own specificities, particularly around restriction grounds and the criminal sanctions framework.
Practical handling procedure for Swiss SMEs
Handling data subject requests should not be improvised. A documented, repeatable procedure protects your business legally and ensures consistent responses. Here is a step-by-step framework:
Step 1: Receive and log the request
- Designate a single point of contact (email address, web form) for data subject requests
- Log the request immediately with the date received, the identity of the requester, and the nature of the request
- Start the 30-day clock
Step 2: Verify the requester's identity
Before disclosing any personal data, you must verify that the person making the request is who they claim to be. Providing data to the wrong person is itself a data protection violation.
Acceptable verification methods include:
- Government-issued ID (passport, identity card) โ redact unnecessary information such as the photo or ID number if not needed
- Comparison with data on file โ verify the requester's details match those in your system (email, address, date of birth)
- Electronic identification โ where available, through SwissID or similar services
- Two-factor verification โ for existing customers, confirm through a known communication channel
Important: The verification method must be proportionate to the sensitivity of the data. For a newsletter subscriber requesting their email preferences, a confirmation email may suffice. For a patient requesting medical records, a government-issued ID is appropriate.
Step 3: Locate all relevant data
This is where most SMEs struggle. Personal data may be scattered across:
- CRM and customer databases
- Email inboxes and archives
- HR and payroll systems
- Website analytics (Google Analytics, etc.)
- Cookie consent records
- Paper files and physical archives
- Backup systems
- Third-party processors (cloud providers, email marketing tools)
A comprehensive data processing register โ which the nFADP already requires for most businesses โ is essential here. If you have one, responding to access requests becomes a matter of consulting the register to identify where data resides. If you do not have one, consider building one with a tool like PrivaGuard's processing register feature, which maps your processing activities and data flows systematically.
Step 4: Compile and review the response
- Gather all personal data relating to the requester
- Organise it by category (identity data, contact data, financial data, usage data, etc.)
- Review the data to ensure no third-party data is inadvertently included
- Apply any legitimate restrictions under Art. 26 (document your reasoning)
- Prepare the response in a clear, structured format
Step 5: Deliver the response
- Send the response within 30 days
- Use a secure delivery method appropriate to the sensitivity of the data
- Retain a copy of the response and delivery confirmation for your records
- If you need more time, communicate the extension within the 30-day window
Step 6: Follow up if necessary
- If the data subject requests rectification or erasure following their access request, handle this as a separate action with its own documentation
- Update your processing register to reflect any changes
- If data has been shared with third parties, notify them of corrections or deletions
Template response letter
To help you get started, here is a structure for an access request response:
Subject: Response to your data subject access request of [date]
Dear [Name],
We acknowledge your request dated [date] pursuant to Art. 25 of the Swiss Federal Act on Data Protection (nFADP).
Following identity verification completed on [date], we provide the following information:
1. Data controller: [Company name, address, contact details]
2. Personal data we process concerning you:
- [Category]: [Specific data]
- [Category]: [Specific data]
3. Purposes of processing: [List purposes]
4. Retention periods: [Specify per category]
5. Recipients: [List recipients or categories]
6. Cross-border transfers: [Countries and safeguards, or "None"]
7. Origin of data: [How data was collected]
8. Automated decision-making: [Yes/No โ if yes, explain logic]
Should you wish to exercise further rights such as rectification or erasure of your data, please contact us at the address above.
Kind regards, [Signature]
Identity verification: getting it right
Identity verification deserves special attention because getting it wrong creates risk in both directions:
- Under-verification: Disclosing personal data to an impostor is a data breach
- Over-verification: Demanding excessive documentation creates unnecessary barriers and may itself violate data minimisation principles
The FADPO (implementing ordinance) provides that the controller must take appropriate measures to verify identity. The standard varies with the context:
| Context | Appropriate verification |
|---|---|
| Existing customer with online account | Login + security question or 2FA |
| Former customer | Email verification + comparison with stored data |
| Non-customer (e.g., website visitor) | Government-issued ID + comparison with available data |
| Employee | Internal HR verification process |
| Sensitive data (health, financial) | Government-issued ID + additional safeguards |
Tip: Document your verification policy and apply it consistently. Inconsistent verification invites complaints.
Penalties for non-compliance (Art. 60 nFADP)
The nFADP's sanctions framework is criminal, not administrative. Failure to comply with data subject rights falls under Art. 60 nFADP (breach of information obligations), which carries penalties of up to CHF 250,000 against the responsible individual โ not the company.
Key points about enforcement:
- The FDPIC cannot impose fines directly โ it investigates, issues recommendations and binding orders, and can file criminal complaints with the public prosecutor
- The public prosecutor conducts criminal proceedings and imposes sanctions
- Convictions appear on the individual's criminal record
- The statute of limitations is 3 years from the commission of the offence (Art. 66 nFADP)
- Intentional violations are required for criminal prosecution; negligent violations are not punishable under the current framework
For a detailed analysis of the sanctions regime, see our comprehensive guide on nFADP penalties and personal liability.
Even outside the criminal context, non-compliance carries practical risks:
- FDPIC investigations can be time-consuming and disruptive
- Binding orders may require costly remedial action
- Reputational consequences in an increasingly data-aware market
- Loss of customer trust, particularly in sectors like healthcare, finance, and legal services
Common pitfalls and best practices
Pitfall 1: Ignoring requests or treating them as complaints
An access request is a legal obligation, not a customer service inquiry. Failing to respond within 30 days โ or responding with a vague "we will look into it" โ exposes your business to enforcement action.
Best practice: Treat every access request as a formal legal matter. Log it, assign it to a responsible person, and track the 30-day deadline.
Pitfall 2: Incomplete responses
Providing only the data from your main database while overlooking email correspondence, analytics data, or data held by your processors is a common and dangerous oversight.
Best practice: Use your processing register to identify all locations where personal data may reside. If you do not have a register, this is the strongest argument for building one โ tools like PrivaGuard make this process straightforward.
Pitfall 3: Over-relying on restrictions
Some businesses reflexively cite "overriding interests" to avoid disclosing data. Art. 26 restrictions are meant to be the exception, not the rule, and must be justified on a case-by-case basis.
Best practice: Apply restrictions only where genuinely necessary, document your reasoning thoroughly, and always provide the data that can be disclosed even when restricting other parts.
Pitfall 4: No identity verification
Sending personal data to someone who has not been verified is a data breach. It is also a violation of the controller's obligation to ensure data security under Art. 8 nFADP.
Best practice: Implement a proportionate verification procedure and apply it consistently to every request.
Pitfall 5: Charging fees by default
Some companies add a "processing fee" to every access request in an attempt to deter them. This directly violates the free-of-charge principle.
Best practice: Provide information free of charge. Only consider a fee where the request is genuinely excessive or manifestly unfounded, and always communicate the fee before processing the request.
Pitfall 6: No internal documentation
If the FDPIC investigates, your ability to demonstrate compliance depends on your records. "We handled it verbally" is not a defensible position.
Best practice: Maintain a log of all data subject requests, including the date received, the verification method used, the response date, and a copy of the response. PrivaGuard's consent audit log can help track these interactions systematically.
Pitfall 7: Forgetting about processors
If you use cloud services, SaaS tools, or external service providers that process personal data on your behalf, they may hold data relevant to the access request. You remain the controller and are responsible for the complete response.
Best practice: Include your processors in the data collection process. Ensure your data processing agreements (DPAs) include provisions requiring processors to assist you in responding to data subject requests within a timeframe that allows you to meet the 30-day deadline.
Building a sustainable compliance framework
Handling data subject requests should not be a crisis exercise. It should be part of your regular business operations, supported by:
- A comprehensive processing register that maps where personal data resides across your organisation โ this is the foundation of everything else
- A documented request handling procedure with clear responsibilities, deadlines, and escalation paths
- An identity verification policy that is proportionate and consistently applied
- Template response letters adapted to different types of requests
- Training for employees who may receive or handle data subject requests
- Regular reviews to ensure procedures remain current as your business and data processing activities evolve
PrivaGuard provides Swiss SMEs with the tools to build this framework efficiently โ from the processing register required by Art. 12 nFADP to consent management and privacy policy generation. The platform is designed specifically for Swiss law, hosted in Switzerland, and built to make compliance practical rather than theoretical.
Conclusion
Data subject rights under the nFADP are not optional, and they are not exclusively a concern for large corporations. Every Swiss business that processes personal data โ which is effectively every Swiss business โ must be prepared to receive, verify, process, and respond to these requests within the legal timeframe.
The good news is that the nFADP framework is reasonable. The 30-day deadline is manageable with proper preparation. The restrictions in Art. 26 provide genuine protection against abusive requests. The free-of-charge principle has sensible exceptions. And the FDPIC has indicated a willingness to work constructively with SMEs that demonstrate good faith.
The key is preparation. Waiting until you receive your first access request to figure out your process is a recipe for non-compliance. Building your framework now โ with a proper processing register, documented procedures, and the right tools โ means you can respond confidently, quickly, and lawfully when the time comes.
For the full legal text of the nFADP, consult the Federal Chancellery's publication on fedlex.admin.ch. For practical guidance and templates, the FDPIC's website is your primary reference.