Skip to content
Legiscope
Menu
Data Privacy

GDPR Compliance Software for Austria: Buying Criteria

Choose GDPR compliance software for Austria: DSB context, German-language workflows, verified vendor offerings, quote comparisons and practical acceptance checks.

For an Austrian organisation, useful GDPR compliance software must fit the people who maintain its records, the systems holding personal data and the decisions its privacy team must document. Employee count alone does not determine the right product. A small business handling sensitive information may need stronger access controls and assessment workflows than a larger business with simpler processing.

This guide sets out a buying process, with official legal and vendor information checked on 28 September 2026. It covers the Austrian Datenschutzbehörde (DSB), the national Datenschutzgesetz (DSG), transfers, assessments and supplier terms. The vendor examples describe published offerings, rather than results of hands-on testing or a ranking. A purchase should follow a demonstration against your own requirements and a written offer covering the actual package.

Define the work before choosing the platform

Start with three examples from your organisation: one processing activity that changes frequently, one supplier relationship with several data locations, and one request from an employee or customer. Identify who supplies information, who reviews it and where the evidence currently sits. These examples reveal whether you need a shared register, an assessment workflow, integration with operational systems or a more extensive platform.

The Article 30 record is a useful starting point, but a list of software applications is not a complete processing record. A single application can support several purposes with different legal bases, recipients and retention periods. Conversely, one activity can use several systems. Ask the supplier to demonstrate those relationships using your example, then export the result. The guide to a record of processing activities explains the underlying structure.

Do not assume that having fewer than 250 employees removes the recordkeeping obligation. The Article 30(5) exemption is unavailable for relevant processing that is not occasional, is likely to create risks to rights and freedoms, or includes Article 9 special categories or Article 10 data. Assess the activities concerned. Software should support the required record without encouraging a blanket exemption based on company size.

What makes the Austrian assessment different?

The GDPR operates alongside Austria’s Datenschutzgesetz. One practical national requirement is section 6 on data secrecy. It addresses controllers, processors and their employees, including instructions about disclosure and continuing confidentiality. Where the relevant employee obligation does not already arise by law, the provision requires contractual commitments. Buying software does not itself establish those commitments or train the people handling the information.

Translate that requirement into an onboarding decision. Who can see the underlying employee or customer records, who only needs a task status, and which administrators can export documents? Ask for permissions that follow those responsibilities. Retain evidence of instructions and confidentiality arrangements in an appropriate location, and make sure a departing administrator cannot continue to access the workspace through an old account or integration token.

German-language support is often operationally valuable, particularly for local staff, notices and regulatory correspondence. It should be a demonstrated requirement where your users need it. The GDPR does not impose one universal rule that every Austrian internal record must originate in German. Assess the audience, applicable procedure and any required translation. A German interface also does not prove that generated legal documents use the correct Austrian provisions.

For a DACH group, ask whether Austrian and German records can share common information while retaining distinct national analyses. A global template should not overwrite a local retention rule or approval. Compare that requirement with the Germany software buying guide, but do not treat a German legal template as evidence of compliance with Austrian law.

Use enforcement history accurately

The DSB’s Google Analytics decision was dated 22 December 2021, and the authority describes it in its 2022 annual report. The case examined transfers under GDPR Chapter V and the effectiveness of the safeguards used in that situation. It predates the EU-US Data Privacy Framework adequacy decision of July 2023. It should not be turned into a current blanket statement that every use of analytics or every US supplier is unlawful.

The Österreichische Post proceedings also require care. The Federal Administrative Court’s account distinguishes substantive decisions about political-affinity processing from the 26 November 2020 annulment of the €18 million fine and termination of that penalty proceeding. Describing the fine as merely reduced is inaccurate. The procedural reasoning of that historical decision should not be presented as a complete statement of current corporate-liability law.

For a buyer, the useful questions concern evidence and review. Can the platform record why an inferred characteristic is collected, whether special-category rules apply and whether a proposed use requires a DPIA? Can it preserve the facts and legal analysis applicable at the time? A dramatic historical fine is not a sound method for calculating the return on a software subscription.

Evaluate transfer records beyond a hosting label

Ask where production data, backups, support records and diagnostic logs are processed, and which legal entities can access them. EU hosting can be relevant but does not settle every transfer question. Remote support, subprocessors and separate telemetry services may create additional flows. The supplier’s registered office and the location of your chosen data centre answer different questions.

The European Commission’s current adequacy list includes US commercial organisations participating in the EU-US Data Privacy Framework. When using that route, verify the recipient’s active participation and the scope covering the relevant transfer. Do not assume that every company in a corporate group, or every service sold under the same brand, is covered by one listing.

Where you rely on standard contractual clauses, the workflow should support the appropriate clauses, the necessary assessment and any supplementary measures. Other Chapter V routes can apply in suitable circumstances; SCCs are not the only possible mechanism outside an adequacy decision. Store the actual legal conclusion and supporting evidence rather than a checkbox stating that a supplier is compliant.

In a demonstration, change the support location or add a subprocessor. Observe whether the owner can identify affected activities and update the analysis without losing the earlier record. Our guide to cross-border data transfers explains the legal questions. The buying requirement is the ability to maintain an intelligible, current record of the answers.

Check the Austrian DPIA workflow

A DPIA module should support a reasoned assessment before processing likely to result in high risk begins. The DSB’s controller guidance points to Austria’s DSFA-V list of processing requiring assessment and the DSFA-AV list of exceptions. Ask how the supplier keeps the applicable criteria identifiable and how reviewers can record a conclusion that differs from an automated suggestion.

A completed questionnaire should show the proposed processing, necessity and proportionality, risks to individuals, planned safeguards and unresolved issues. It should also identify who owns the measures and whether they were implemented before launch. Use the DPIA guidance to prepare a realistic scenario, such as a new employee-monitoring system or a change to sensitive customer profiling.

Do not reward a product merely for displaying a green score. A DPIA does not create a missing legal basis, and an attractive risk score is not regulator approval. Where the conditions for prior consultation under Article 36 are met, the workflow must allow that issue to remain unresolved pending the appropriate process. Procurement should verify that users can preserve legal uncertainty and escalate it to someone authorised to decide.

Compare published vendor offerings with your requirements

Dastra publishes Starter, Pro and Enterprise offerings on its pricing page. The page differentiates the processing-record foundation from additional rights-request, breach and contract functions and invites buyers to request a quote. It does not substantiate an Austrian entry price of €79 per month. Ask which tier includes your required workflow, German outputs, imports, access controls and onboarding; obtain those points in the proposal.

OneTrust describes data and activity mapping, assessments and vendor-related privacy work in its current packaging information. Its Privacy Automation Suite adds rights-request and incident capabilities to the stated operations offering, with pricing tied to users and privacy asset inventory. That is a reason to define the assets and users in your quotation request, not evidence that the platform becomes appropriate at a universal 300-employee threshold.

TrustArc describes configurable intake, routing, deadline tracking and activity history in its Individual Rights Manager documentation. This is relevant when request handling is a buying priority. Ask how the quoted package connects to your inventory and source systems, and verify hosting and support arrangements in the actual agreement. A brand’s nationality does not establish the data locations for your contract.

A controlled spreadsheet and document repository can also remain workable for limited, stable processing if responsibilities, security and updates are managed. Compare the work required to maintain that arrangement with the work required to administer a platform. For a wider set of candidates, use the GDPR software comparison as a starting point, then check current supplier evidence against your Austrian requirements.

Make demonstrations answer operational questions

Use synthetic information in procurement demonstrations. For the first scenario, have an operational owner update a processing record, a reviewer reject an unsupported retention period, and the owner correct it. Confirm that the final export explains the activity and that the history identifies the change. A successful presentation by the salesperson is less useful than your own user completing this sequence.

For the second scenario, submit a data subject access request involving records in more than one system. Verify assignment, identity checks where justified, collection, review of third-party information and secure delivery. The default response period is one month, with a possible extension under the GDPR’s conditions. The system should support notice of that extension within the first month rather than silently moving the deadline.

Also demonstrate a refusal. Article 12(4) requires reasons and information about complaint and judicial remedies without delay and at the latest within one month when the controller does not act. An automated status of “closed” does not show that the person received that explanation. Test who approves the response and whether the final communication remains linked to the request.

For the third scenario, record an incident with incomplete facts. Article 33 requires authority notification without undue delay and, where feasible, within 72 hours after awareness unless risk to individuals is unlikely. Late notification requires an explanation, and every personal-data breach must be documented. Article 34 communication where high risk is likely is a distinct decision. The tool should support those decisions without automatically treating every technical alert as a reportable breach.

Compare quotes using the same scope

Request offers for the same legal entities, administrators, occasional contributors, assets, workflows and integrations. Ask which quantities determine renewal pricing and what happens when you exceed a tier. Include implementation, migration, training, translation, support and required connectors. A low base subscription can be difficult to compare with an offer that includes those services unless the scope is made explicit.

Use your own assumptions to model total cost. For example, two hypothetical offers could have the same annual subscription while one requires substantial paid migration and the other requires more internal administration. Record both external charges and the staff time you expect to spend. These are purchasing scenarios, not market price estimates or evidence of what Austrian companies generally pay.

Ask for renewal notice periods, any indexation or increase mechanism, minimum commitment, tax treatment and exit charges. Separate the initial project from recurring service. The software cost guide can help structure the comparison, but a dated written quotation for your requirements is the relevant pricing evidence. Do not approve a purchase solely because its annual cost is small compared with a theoretical regulatory maximum.

Review the processor terms and the exit route

Determine whether the supplier acts as processor for the records you place in the service and whether it has any separate controller purposes. Article 28 processing must be governed by a written contract or another binding Union- or Member-State-law instrument, including electronic form. For a commercial software purchase, the data processing agreement is normally central to this review.

Check instructions, confidentiality, security, subprocessor arrangements, assistance, audits and deletion or return. Processing outside your instructions requires the relevant Union or Member-State legal obligation binding the processor, with prior notice to you unless that law prohibits notice on important-public-interest grounds. Broad permission to use customer content for the vendor’s own purposes should be separately examined, not hidden inside a generic processing clause.

At the end of the service, Article 28 requires deletion or return at the controller’s choice and deletion of existing copies unless Union or Member-State law requires retention. Ask how this is implemented across exports, attachments and backups, what evidence is provided and how legally retained material is restricted. Do not invent an immediate technical deadline for every backup; assess whether the documented lifecycle and contract meet the legal obligations.

Before signing, perform an export and check it outside the platform. Can you read the processing records, decisions, attachments and relevant histories without another subscription? Identify who would run a migration and what assistance costs. A system that is easy to enter but difficult to leave can create a practical dependency even when its subscription price looks modest.

Decide on evidence and ownership

Choose the product whose demonstrated workflows, contractual terms and total cost fit the work you have defined. Keep unresolved issues visible in the decision: a missing German output, an unconfirmed subprocessor location or an integration that has only been promised. Ask for a concrete commitment or adjust the scope before relying on the feature.

Assign an internal owner for implementation and another person able to review the legal configuration. Start with a bounded set of real activities, check the imported information and then expand. Software can make responsibilities and evidence easier to maintain; it cannot decide the lawfulness of your processing merely by filling every field. The useful outcome is a system your Austrian team can operate, explain and keep accurate as the business changes.

L
Written by
Legiscope
Legiscope

Put this guidance into operation

See how Legiscope connects privacy records, source material and review-controlled work.

Book a tailored demo
Continue reading

Related articles

01Data Privacy

GDPR Compliance Software Denmark (Datatilsynet)

- The GDPR applies directly in Denmark and is supplemented by the Databeskyttelsesloven (Data Protection Act) with an enforcement procedure in which Datatilsynet recommends fines, but the courts…

July 10, 2026
02Data Privacy

GDPR Compliance Software for Spain: SME Buying Guide

GDPR compliance software for a business operating in Spain should support the work your team actually has to perform: maintaining processing records, applying Spanish rules, handling requests,…

July 2, 2026
03Data Privacy

GDPR Compliance Software in Poland: A UODO Buyer Test

The right GDPR software for a Polish organisation is the system its people can maintain and explain. It should help an accountable owner describe processing, update security decisions, answer rights…

July 8, 2026
04Data Privacy

GDPR Compliance Software in Sweden: An IMY Buyer Test

A Swedish organisation choosing GDPR software needs a system its people can keep accurate, not a promise that a licence is “IMY ready”. Test whether the team can maintain a processing record, answer…

July 8, 2026
05Data Privacy

GDPR Compliance Software Ireland (DPC)

An Irish organisation shopping for GDPR compliance software should start with the work it needs to prove: a current record of processing, decisions about high-risk projects, processor and transfer…

July 9, 2026
06Data Privacy

GDPR Compliance Software Italy: Practical Buyer Guide

Here is what is specific about Italy, what matters at 10-300 employees, and how the options compare.

July 6, 2026
07Data Privacy

GDPR Compliance Software Netherlands: Practical Buyer Guide

Here is what is specific about the Netherlands, what matters at 10-300 employees, and how the options compare.

July 6, 2026
08Data Privacy

GDPR Compliance Software Norway (Datatilsynet)

- Norway applies the full GDPR via the EEA Agreement, implemented through the Personopplysningsloven — the obligations match the EU's. - Datatilsynet's highest-profile fine — Grindr (NOK 65 million)…

July 10, 2026