Marcus Belke
CEO of 2B Advice GmbH, driving innovation in privacy compliance and risk management and leading the development of Ailance, the next-generation compliance platform.
A good Audit-Preparation means more than just a complete Documentation to ensure compliance. It requires clear responsibilities, structured documentation, and transparent processes. Companies that establish these structures early on avoid stress during the audit while simultaneously strengthening their governance. In this article, you’ll learn how auditors think, what weaknesses commonly arise in data protection audits, and how you can prepare for an audit in a structured way.
What Auditors Typically Expect
The auditing bodies (Regulatory Authority, internal audit, external auditor, client/partner) may differ in tone, but rarely in their core messages. Auditors seek reliable answers to three key questions:
- Does the organization know its Processing?
„What data do we process, why, for how long, with whom, and where?“ (VVT as core evidence). - Are the protective measures appropriate for the level of risk and effective?
The TOMs are not just „on paper“; they have been implemented and verified in a transparent manner. - Are Rights of data subjects and obligations operationalized?
Information/Deletion, incident management, Duty to inform, The withdrawal of consent must be defined as a formal process with deadlines and assigned responsibilities.
It is also crucial for regulatory authorities that Responsible persons and data processors cooperate upon request. The extent of cooperation may also be a factor in determining fines (a criterion for reduction or calculation).
Testing Methods You Should Realistically Plan For
In practice, a combination of document reviews, structured questionnaires, interviews, and spot checks is used. The fact that regulatory authorities can, among other things, conduct data protection audits and request information is enshrined in the legal framework of their powers.
For example, the BayLDA questionnaire provides a perspective that is very „audit-oriented“: It explicitly asks about data protection governance, the involvement of the data protection officer, VVT, Privacy by Design, data processors/data processing agreements, Duty to inform, rights of data subjects, proof of consent and data protection management. This is practically a catalog of expectations.
Test Methodology | How Examiners Determine Maturity | Typical evidence |
Document Review („Desk Audit“) | Consistency: VVT ↔ TOM ↔ DSFA ↔ Contracts ↔ Retention Periods ↔ Duty to inform | VVT, TOM Concept/Mapping, AV Contracts, Fire Suppression Plan, DPIA/risk analysis, proof of consent |
Questionnaire (Regulatory/Partner Audit) | Accountability without „ad hoc solutions“; clear responsibilities | Completed questionnaires, evidence index by question (link to supporting documentation) |
Interviews/Workshop Discussions | Employees are familiar with the process, escalation procedures, and deadlines; there are no conflicting statements | Role Matrix, Training Certificates, Process Manuals, Ticket/Workflow Examples |
Spot Checks/Walk-Throughs | „Show me“: Information, Deletion, Authorization, Whether Incident Response Is Actually Feasible | 1–3 case files per process (DSAR tickets, deletion runs, authorization reviews, incident runbook) |
Technical evidence (demos/logs) | Effectiveness and Traceability (e.g., roles/permissions, 2FA, backup tests) | Authorization policies, logs, backup test logs, MFA rollout documentation |
Link tip: GDPR questionnaire LDA Bavaria
Typical Exam Questions and Grading Criteria
The following examples are worded in such a way that they are suitable for both regulatory and client or certification audits. They reflect typical regulatory questions (e.g., the BayLDA questionnaire) as well as the DSK classification system (VVT/DSFA/Rights of data subjects).
| Theme block | Typical exam question | Assessment criterion (what „good“ means) | Typical evidence |
|---|---|---|---|
| Governance | „Is Data protection “A top priority—are responsibilities clearly defined?" | Responsibilities are documented and effectively implemented in day-to-day operations | Data protection guideline, roles/RACI, DPO integration concept |
| Processing transparency | „Is there a VVT, and is it complete and up to date?“ | VVT covers actual processing operations, including recipients, retention periods, and a description of TOM | VVT + Change Process/Review Minutes |
| Order processing | „Have all data processors been identified, and have Article 28 data processing agreements been concluded?“ | Complete list of vendors; antivirus contracts with minimum requirements; monitoring mechanism | Vendor Registry, AV Contracts, TOM Audit of Service Providers |
| Rights of data subjects | „Can you provide the information by the deadline?“ | Process & organization ensure timely, comprehensible information | DSAR Process, Sample Responses, Ticket Examples |
| Deletion | „How do you ensure that data is deleted within the required timeframes for each data type?“ | Data deletion policy by data type; justified retention periods; documented deletion processes | Fire Suppression Plan, Deletion Logs, Exception/Blocking Rules |
| Risk/DSFA | „For which processes do you conduct a DSFA?“ | DSFA prior to launch; decision documented for each process; actions are derived from it | DSFA Reports, Threshold Analysis, Action Plan |
| Consents | „Can you provide evidence of consent and Revocation make it possible?“ | Verifiability, information, revocation mechanism | Consent Registry, UI Screenshots, Logs |
Common Weaknesses Found in Audits
The following weaknesses are not „theoretical errors,“ but rather typical points of discontinuity between paper-Compliance and everyday life. The examples are deliberately based on regulatory audit questions and best-practice guides (e.g., TOM checklists), since auditors focus precisely on areas where implementation is often lacking.
Technical Defects
A common Audit-The finding is not „no TOM,“ but rather TOM without any reference to effectiveness: Although a PDF with keywords exists, there is no reliable evidence that measures were implemented, tested, and selected in a manner appropriate to the risk. Although the criterion „regularly review/evaluate“ is explicitly addressed, without a concrete description it is practically impossible to meet.
Concrete, often criticized technical examples:
- Weak Authentication: No (or inconsistent) use of 2FA in high-risk areas, no lockouts after failed login attempts, passwords are shared or written down, and inadequate admin password standards.
- An immature role/authority framework: lack of role profiles, no regular reviews, „functional mailboxes,“ and collective accounts without accountability.
- Backup/recovery as a blind spot: no written backup concept, no restore tests, no 3-2-1 strategy, potentially affected by Ransomware Encrypted backups, missing or untested emergency plan.
- Mobile/Remote Risks: Lack of end-to-end device encryption, inadequate MDM, insecure app sources, no clear chain of responsibility in the event of loss.
Organizational Shortcomings
In this area, organizations often fail because of issues related to responsibilities and governance, not because of a lack of legal knowledge.
- The DSB/data protection function is integrated too late. Projects are launched and systems go live while data protection is „added as an afterthought.“ However, this conflicts with the expectation that data protection concerns should be taken into account from the very beginning or whenever processes are changed (Privacy by Design in the audit question logic).
- There is no robust data protection management system; rather, there are only individual measures that are not integrated into a system that provides a structured framework for implementation, verification, and updating. It is precisely this ability to „ensure compliance and provide evidence“ (on a risk-based basis) that lies at the heart of the accountability framework.
- Service provider management is formal, but not substantive: AV contracts exist, but there is no complete overview of service providers, no Transparency via sub-processors and no recurring audit of technical and organizational measures. Auditors ask precisely for „overview“ and „minimum content Art. 28“.
Audit Organization: No Stress!
Audit-Stress rarely stems from individual questions, but rather from disorganized searches, contradictory statements, and unclear role assignments. Preventing stress is therefore primarily a matter of organization.
Before the audit
One effective tool is what is known as „evidence mapping“: Each audit requirement is assigned clear supporting documentation („single source of truth“) in advance, and a responsible Role. This will help you avoid having to rush to put things together during the exam.
As a minimum standard, you should ensure the following before the appointment:
- Single Point of Contact (SPoC) for communication with auditors (prevents parallel chats and conflicting statements).
- Clarification of Roles: Who is responsible for „Policy,“ who for „IT Details,“ who for „HR Processes,“ and who for „Legal/Contracts“?.
- Run a mock-Audit with five to ten key questions (VVT, DSAR, Deletion, AV, TOM, DSFA) as a dry run.
The fact that cooperation and a structured approach are not merely „soft skills“ is demonstrated by the fact that cooperative behavior can be taken into account in supervisory measures and when determining fines.
During the audit
The tried-and-true rule of communication is: „Answer + Evidence + Context.“.
- The answer should be brief, factual, and verifiable.
- The document must be immediately linkable in the Audit-Folder (not „pass it to someone“ as the default mode).
- Context: Clarification in case the scope does not apply (e.g., „applies only to System X, not to Y“).
When dealing with government agencies, it is also important that Responsible persons and processors on request.
After the audit
The post-phase determines whether the Audit „becomes “expensive":
- Findings triage (high/medium/low) according to risk for Affected parties and probability of occurrence; content consistent with risk-based requirements and DPIA logic.
- An action plan is drawn up, specifying the person in charge, the deadline, and the form of documentation. The DSK expressly recommends a coordinated approach for implementation projects and keeping senior management informed as a starting point.
- Proof of completion: Each action is not marked as „completed,“ but rather as „verifiably completed“ (e.g., screenshot, log, test report).
Audit Check at a Glance
Checkpoints | Responsible persons Role | Form of proof | Priority |
Audit‑Scope, systems, locations, and time period defined | Management / Data protection coordination | Audit‑Readme + Scope Document‑ | High |
Single Point of Contact (SPoC) + communication rules defined | Data protection coordination | Role sheet + communication plan | High |
Data Protection Roles/RACI, Including Clear Integration of the DPO | Management / DPO | RACI, organization chart, integration process | High |
VVT complete, up-to-date, versioned | Process owners + DPO | Master VVT + Change Log | High |
VVT specifies deletion deadlines and criteria for each data category | Process owner | VVT Fields + References to the Fire Suppression Plan | High |
VVT contains TOM references / general TOM description | IT Security + DPO | VVT Entry + TOM Document Link | High |
TOM Verification: Risk→Action Mapping Available | IT Security + DPO | TOM Matrix/Mapping | High |
Authentication: Password Policy + 2FA for High-Risk Users | IT Security | Policy + System Settings/Reports | High |
Role/Authorization Concept Documented and Reviewed | IT Security / IT Operations | Role Model + Review Log | High |
Written backup plan + restore tests | IT Operations / Business Continuity Management | Backup Plan + Test Reports | High |
Emergency/BCM plan in place and tested | BCM / IT Operations | Emergency Plan + Drill Reports | Medium |
Vendor Registry Complete (All Data Processors) | Purchasing/Vendor Mgmt + DSB | Service provider list | High |
Collective Bargaining Agreements with Minimum Provisions (Art. 28) for All Collective Bargaining Agreements | Legal + DPO | AV Contracts + Annexes | High |
Subprocessor‑Transparency + Approval Process | Vendor Mgmt + Legal | Subprocessor list + releases | Medium |
Disclosure Requirements (Art. 13/14) by Core Process | Legal/Marketing + DSB | Data protection information + versioning | High |
DSAR Process (Intake, Identification, Data Search, Response) | Customer Service / DPO | Process description + ticket examples | High |
Information deadlines/monitoring of deadlines operationalized | DPO / Departments | Deadlines—SLA + Workflow | High |
Fire Suppression Plan per data type (purpose, duration, requirements) | Records Mgmt / DSB | Fire Suppression Plan | High |
Firefighting operations verifiable (logs/reports) | IT Operations / Business Units | Deletion Logs | High |
Procedure for Requests for Deletion Under Article 17 | DPO / Service | Process + case file | High |
Threshold Analysis: DSFA Yes/No for Each High-Risk Transaction | DPO + process owner | Threshold Analysis Document | High |
DSFA performed prior to commissioning (where required) | DPO + project management | DSFA Report + Action Plan | High |
Proof of Consent + Opt-Out Mechanism | Marketing/Product + DSB | Consent Registry + Logs/UI Records | High |
Training/sensitization (Phishing, data transfer) | HR + IT Security | Training plan + attendance records | Medium |
Request log for Audit (Questions, answers, supporting documents, deadlines) | Audit‑SPoC | Audit‑Log (e.g., table/ticket) | High |
Action plan according to Audit (Owner, date, document) | Management / DPO | Action Plan + Closure Documentation | High |
Audit-ready with 2B Advice and Ailance
Audit-Competence does not arise only when an audit is announced. It is the result of clear structures, transparent processes, and verifiable evidence in data protection.
Companies that take a strategic approach to data protection reap dual benefits: They pass audits with flying colors while simultaneously strengthening their governance and building trust among customers and partners.
If you'd like to know how well your company is prepared for a data protection—Audit Once you're prepared, it's worth taking a structured look at your own processes.
Learn more about our solutions for data protection and Compliance-Management with Ailance and get in touch with our experts.
Marcus Belke is CEO of 2B Advice as well as a lawyer and IT expert for data protection and digital Compliance. He writes regularly about AI governance, GDPR-Compliance and risk management. You can learn more about him on his Author profile page.
German 
English 
Italian 
French