The site is under construction. The content was last updated in February 2026. Please note that we update the page regularly.
When you allow an external party (a data processor) to process personal data on behalf of Aarhus University (AU), AU has a duty to ensure that the processing takes place legally and securely. In order to ensure this, AU must audit the data processor.
In short, the audit is about checking that the data processor follows the rules and what is stated in the data processing agreement. The person or unit at AU that owns the system or has purchased the service is responsible for audit. In many cases, it will therefore not be you as a researcher who is responsible for the task. However, if you have purchased a system or service specifically for your project, it is you who must ensure that the data processor is audited.
The work of auditing actually begins before you even sign an agreement.
The following steps need to be in place because they form the basis for how and how often the audit should be carried out.
1. Clarify the need | Find out what the purpose of the data processing is. |
2. Make a risk assessment | Assess the level of security that is necessary and document the assessment. |
3. Choose a data processor | Check whether the data processor can meet the requirements you have identified. Document the assessment. |
4. Determine the method and frequency of an audit | Use AU's model to find out how and how often you should audit. |
5. Enter into the data processing agreement | Remember that your assessment of the method and frequency of audit is part of the data processing agreement. Contact TTO ([email protected]) for help in getting the agreement in place |
Aarhus University (AU) uses four different models to audit data processors in research projects. The choice of model depends on how the personal data is processed, the scope of the processing and the risks that may be associated with it.
The models are based on the principles in the Danish Data Protection Agency's guidance on audits of data processors. Below you can read more about the individual models and find templates that you can use when you need to carry out an audit.
What does ad hoc audit mean?
Audit will only be necessary, if AU becomes aware of conditions at the data processor that give rise to concern — e.g.:
Security breach
Complaints
Critical coverage in the media
Information from the data processor itself
In short: We only audit if there are signs that something may be wrong
Examples of tools:
Random checks – e.g. checking whether employees have received safety training
Request for information (Download template)
Elaborated status (see model 3)
Physical inspection (see model 4)
At fixed intervals, the data processor must send a more detailed written status to AU. It must cover at least:
1. Third party statement
A third-party statement is an independent assessment of the data processor's security and compliance — typically made by an auditor.
The most common in Denmark is ISAE 3000, which assesses the data processor's handling of personal data according to Article 28 of the General Data Protection Regulation.
2. Extended audit by AU
Building on questions from the ISAE 3000 framework.
Relevant when the data processor's work depends on physical security, e.g.:
What can AU inspect? Examples (inspired by ISO 27001 Annex A.11):
AU's own policy on physical security can be found here: https://medarbejdere.au.dk/en/informationsecurity/policies/physical-security |
You can use these tools if you need help assessing which audit method is appropriate for your situation.
When you choose an audit model, you must also decide how often the audit should be carried out. As a general rule, an annual audit may be appropriate, but both shorter and longer intervals may be relevant depending on the situation.
Below you will find the most important factors you should take into account.
🔎 Risks of the processing | The higher the risk, the more frequent audits. If the processing involves sensitive data or is of great importance to the data subjects, the audit should be carried out more often. |
⏳ Duration of the service |
|
⚠️ Specific incidents | Certain incidents may trigger the need for extra or stricter audit scheme, e.g.:
|
🤝 Knowledge and trust in the data processor | Consider:
|
🔗 Use of sub-processors | If the data processor uses sub-processors, it can increase complexity and risk — and thus the need for more frequent supervision. |