Data Subject Access Requests (dsars) in Austria 2026: How Businesses Must Respond

Data subject access request austria compliance remains demanding in 2026, with the Austrian Data Protection Act (Datenschutzgesetz, DSG) supplementing the GDPR and guidance from the Datenschutzbehörde (DSB) shaping expectations around identity verification, processing time and documentation. Businesses operating in Austria must respond to a data subject access request within strict deadlines, retain a defensible audit trail, and apply exemptions only where the law permits. This guide sets out a practical, step-by-step procedure for in-house counsel, data protection officers and compliance teams, aligned with Article 15 of the GDPR, the DSG, and current DSB practice. Treat it as an operational playbook, not a substitute for case-specific legal advice.

Quick summary: what you need to know now

• Deadline. You generally have one month from receipt to respond, extendable by a further two months for complex or numerous requests where you notify the requester within the first month.
• Fees. Responses are normally free; a reasonable fee or refusal is only permitted for manifestly unfounded or excessive (repetitive) requests, under GDPR Article 12(5).
• Current practice. The DSB and EDPB guidance place weight on proportionate identity verification and on disciplined logging, so a documented, repeatable process is essential.

1. Overview: What is a data subject access request in Austria?

A data subject access request in Austria is the exercise of the right of access under Article 15 of the GDPR, as supplemented by the DSG. It entitles an identified natural person to obtain confirmation of whether their personal data is being processed and, if so, a copy of that data together with prescribed information about the processing. In practice, a DSAR is among the most common data subject rights that Austrian businesses receive, and mishandling one is a frequent trigger for a complaint to the DSB.

1.1 Legal basis (GDPR and DSG)

The substantive right flows from GDPR Article 15, which lists what must be disclosed: the purposes of processing, the categories of personal data concerned, the recipients or categories of recipients, the envisaged retention period, the existence of data subject rights, the right to lodge a complaint with the DSB, the source of the data where not collected from the data subject, and the existence of automated decision-making including profiling. Article 12 governs the modalities, transparency, timing and fees. The DSG (consolidated text available via the Rechtsinformationssystem des Bundes, RIS) adapts and supplements these rules within the margin the GDPR leaves to member states, including procedural and enforcement provisions administered by the DSB.

1.2 Who can make a DSAR

Only a living, identifiable natural person, the data subject, holds the right of access. This is a crucial distinction from corporate information rights. A company is not a data subject and cannot make a DSAR about itself. The right of access under the GDPR does not, as a general rule, extend to the data of a deceased person, although Austrian law may provide certain protections in limited circumstances. A subject access request Austria businesses receive must therefore be screened at intake to confirm it genuinely concerns an individual’s personal data.

2. Eligibility: who can submit and what counts

Determining eligibility early prevents wasted effort and avoids inadvertent disclosure. The core question is whether the requester is the data subject or a person lawfully acting on their behalf, and whether the material sought is in fact personal data relating to that individual.

2.1 Representatives and mandated requests

A data subject may appoint an authorised representative, for example a lawyer, a family member or an advocacy organisation. Where a third party submits the request, you should obtain a written mandate or power of attorney signed by the data subject, together with proof of identity for both the data subject and the representative. The underlying right remains that of the data subject, so the response (and the data) should ultimately reach the data subject or be released strictly in accordance with the mandate. Requests concerning minors require particular care: a parent or legal guardian may generally act on behalf of a child, but you should assess the child’s capacity and best interests where relevant.

2.2 Requests from authorised third parties

Beyond representatives, you may receive requests routed through platforms, unions or consumer bodies. Treat each as a request on behalf of a named individual, verify the mandate, and apply the same identity and scope checks you would for a direct request. If the mandate is unclear, limited or missing, seek clarification before releasing any personal data, releasing data to an unauthorised party is itself a personal data breach.

3. Step-by-step: responding to a data subject access request Austria businesses can rely on

The following procedure maps the end-to-end handling of a DSAR, assigns ownership, and gives realistic timing. Use it as the backbone of a written standard operating procedure. The illustrative wording below is a starting point only and should be adapted and legally reviewed for your organisation.

3.1 Step 1, Logging and triage

Capture the request the moment it arrives through any channel, email, letter, web form, social media or a verbal request at a counter. There is no prescribed format under the GDPR, so a DSAR can be made in plain language and need not use the words “access request.” Record the date of receipt (which starts the one-month clock), the channel, and the requester’s stated identity. Preserve the original message in full, including email headers and metadata, as good practice for demonstrating when and how the request was received. Acknowledge receipt promptly.

Illustrative acknowledgement: “We confirm receipt of your request dated [date] concerning your personal data. We will respond within one month. We may contact you to verify your identity or to clarify the scope of your request.”

3.2 Step 2, Identity verification

Verify identity using proportionate means, you must be satisfied the requester is the data subject, but you must not demand excessive information. Acceptable methods include an official photo ID (passport or national ID), a secure electronic identity such as ID Austria, a qualified electronic signature, or, for existing account holders, authentication through the account combined with recent transactional detail. Where there are reasonable doubts about identity, you may request additional information necessary to confirm it (GDPR Article 12(6)). Record precisely which method was used and why it was proportionate, since both under- and over-verification can give rise to compliance issues.

3.3 Step 3, Scope and search strategy

Define what personal data you hold and where. Use your processing-activity records and data inventory to build a search plan covering structured systems (HR, CRM, ERP), unstructured sources (email, shared drives, collaboration tools), backups where reasonably accessible, and data held by processors or cloud providers on your behalf. If the request is broad or ambiguous, you may ask the requester to specify the information or processing activities to which it relates, but you cannot use clarification as a delaying tactic. Document the systems searched and the search terms applied.

3.4 Step 4, Review for exemptions and redactions

Before release, review the retrieved material for content that must be withheld or redacted. The most common issue is the rights and freedoms of others, including the personal data of third parties: the right to obtain a copy under Article 15(4) must not adversely affect the rights and freedoms of others, so you should redact or withhold such material unless disclosure is otherwise justified. Apply a balancing test and record your reasoning. Other grounds, legal professional privilege, protection of the rights of others, and specific DSG restrictions, may also apply. Keep a redaction log citing the GDPR article or DSG section relied upon for each redaction.

3.5 Step 5, Prepare response and delivery

Assemble the response: a copy of the personal data plus the Article 15 information set (purposes, categories, recipients, retention, rights, source, automated decision-making). Write explanations in clear, plain language. Where the request was made electronically, provide the response in a commonly used electronic form unless the requester asks otherwise. Deliver via a secure channel, encrypted email, a secure portal or recorded delivery, and confirm the recipient. Avoid sending personal data to an unverified address.

3.6 Step 6, Recordkeeping and evidence preservation

Create a complete case file: the original request, verification evidence, search outputs, the data released, the redaction log, all correspondence, and an internal decision memo. This file is your primary defence if the matter reaches the DSB. Log the key milestones with timestamps so you can demonstrate the timeline was met. Retain the file in line with your retention policy, bearing in mind that DSB complaints and judicial remedies can arise months after a response is delivered.

4. Required documents and evidence to gather

A defensible data subject access request Austria file depends on gathering the right documents from the outset. The table below lists the items the DSB will typically expect to see if a complaint is raised.

4.1 Documents for identity verification

Accept the least intrusive proof that still gives reasonable assurance. For digital-native businesses, account authentication plus a recent transaction reference is often sufficient and avoids collecting ID copies you do not need. Where you do collect ID, minimise and delete it once verification is complete, documenting that step.

4.2 Sources of personal data and evidence retention

Map sources before you search: primary databases, email archives, call recordings, CCTV, backups, and processor-held data. Retain the search outputs and system exports as evidence that your search was reasonable and complete, a frequent gap the DSB identifies is a response that fails to show which systems were actually checked.

5. Timeline and deadlines, including extensions and interruptions

Under Article 12(3) of the GDPR, you must respond without undue delay and in any event within one month of receiving the request. That one-month period may be extended by a further two months where the request is complex or where you have received a number of requests, provided you inform the requester of the extension and the reasons for it within the first month. Where you have reasonable doubts about identity, you may request further information to confirm it, and the time to respond runs from when that information is provided, but you cannot engineer delay.

Document the start date, any extension notice, and any verification steps so you can prove compliance. A short, dated extension notice should state that the request is complex, give the reason, and confirm the new deadline.

Illustrative extension notice: “Because your request is complex and covers multiple systems, we are extending our response time by up to two further months in accordance with Article 12(3) GDPR. We expect to respond by [date].”

6. Costs and fees: when a charge is permitted in Austria

The default position under Article 12(5) of the GDPR is that responding to a DSAR is free. A fee, or a refusal, is only permitted where a request is manifestly unfounded or excessive, in particular because of its repetitive character. Any fee must be reasonable and based on the administrative cost of providing the information. In Austrian practice, fees are rarely charged, and the burden is on the controller to demonstrate that a request is manifestly unfounded or excessive, with contemporaneous time logs.

7. Practical compliance priorities for 2026

While the core GDPR framework is unchanged, the following areas are consistent compliance priorities that the DSB and EDPB guidance emphasise:

• Identity verification. Verification should be proportionate, neither waved through nor used as a barrier through excessive demands, with the method documented.
• Processing-time discipline. Clear handling of when the response period runs (including where further identity information is sought), and documenting the start date and any extension.
• Manifestly unfounded or excessive requests. A high evidential burden must be met before a fee or refusal is justified.
• Logging obligations. Preserving the original request, email headers and metadata, and maintaining a complete audit trail.
• International transfers. Where responses require processing or transfers involving third countries, lawful transfer mechanisms and safeguards must be documented.

The practical effect is that organisations with a written DSAR SOP, proportionate verification steps and disciplined logging will be well placed, while those relying on ad hoc handling will be more exposed to complaints.

8. Common pitfalls and practical tips

• Releasing third-party data. Disclosing another individual’s personal data without redaction or a balancing assessment is a frequent and serious error.
• Incomplete search scope. Overlooking email archives, backups or processor-held data in the cloud leaves the response incomplete and indefensible.
• Weak logging. Failing to preserve the original request, email headers and metadata undermines your ability to prove the timeline and the search.
• Disproportionate identity checks. Demanding excessive ID is itself a data protection failing; so is releasing data to an unverified requester.
• Missed deadlines. Not issuing an extension notice within the first month forfeits the right to the two-month extension.

8.1 Prevention checklist

• Maintain a written DSAR SOP with owners and timings.
• Log every request on receipt, with date and channel.
• Use a standard, proportionate verification process.
• Run a documented, inventory-driven search across all sources.
• Keep a redaction log citing the legal basis for each redaction.
• Deliver via a secure channel and retain the full case file.

8.2 When to involve legal

Escalate to legal where the request is broad or hostile, where third-party or privileged material is involved, where you are considering a refusal or a fee, where international transfers arise, or where a DSB complaint appears likely. Early legal involvement is far cheaper than defending a poorly documented decision after the fact.

9. Decision matrix: refuse, comply or redact

Whatever the decision, communicate it in writing. Under Article 12(4), where you do not act on a request you must inform the data subject without delay (and at the latest within one month) of the reasons and of the right to lodge a complaint with the DSB and to seek a judicial remedy.

10. Templates and next actions

Operationalise this guide with a small set of illustrative, legally reviewed templates:

• Acknowledgement of receipt email.
• Identity verification request.
• Extension notice (Article 12(3)).
• Refusal letter with complaint and judicial remedy rights.
• Redaction justification memo.

Review how enforcement unfolds in practice in Austrian DPA Investigation 2026, how to respond.

Conclusion and next steps

Handling a data subject access request austria organisations receive in 2026 is less about legal novelty than about disciplined execution: proportionate identity verification, a complete and documented search, careful redaction, timely delivery, and a defensible audit trail. The framework rewards businesses that embed these steps into a written standard operating procedure and penalises those that improvise. Put a DSAR SOP in place, adopt reviewed templates, train the teams that receive requests, and secure legal sign-off before responding to anything contentious. Where a request is broad, hostile, or involves third-party data, privilege or international transfers, obtain tailored advice from an Austrian data protection lawyer before you respond.

Sources

1. GDPR consolidated text (Regulation (EU) 2016/679)
2. Austrian Data Protection Authority (Datenschutzbehörde, DSB), guidance and publications
3. Rechtsinformationssystem des Bundes (RIS), Austrian Data Protection Act (DSG)
4. European Data Protection Board (EDPB), Guidelines and opinions
5. Court of Justice of the European Union (Curia), case law database