GDPR Article 28(3)(h) processor audits: what customers can ask

What a processor must allow in a customer audit under GDPR Article 28(3)(h)

When an enterprise customer or a regulator asks what audit rights it has over your company, the answer starts with Article 28(3)(h) of the GDPR. A processor must make available all information necessary to demonstrate compliance with its Article 28 obligations, and it must allow for and contribute to audits, including inspections, carried out by the controller or by an auditor the controller mandates. The GDPR requires no audit, attestation or certificate for this, so the obligation is met by giving the controller a real route to verify your processing, not by producing a particular report. How much verification a customer asks for depends on the sensitivity of its data and the breadth of your service. Your processing agreement should state how requests are made, how much notice applies and who bears the cost, and your team should confirm those terms before a request arrives.

Your organization owns its controls. An implementation partner can help prepare systems, configuration records, access reviews and logs so that a customer can test them, but only an independent auditor or certification body issues any report or certificate. Expect the customer's effort to scale with the request. A questionnaire built on your published security documentation is usually the first step, and a document review or remote session follows if the customer's risk requires it. On-site inspection of data centers is a separate and more costly step, and many processors meet it by pointing to the audit reports of their hosting provider, which the customer can then review. Confirm what your hosting contracts allow you to pass on before you promise that.

Ask three questions before you agree to audit terms. First, which parts of the service fall inside the audit scope, including sub-processors and remote administration from outside the EEA. Second, who pays for an audit the customer mandates and for the staff time you spend supporting it, since that cost recurs with every request. Third, whether an existing third-party assessment, such as an approved certification, can answer some requests. Under Article 28(5), an approved certification can be used as an element in showing sufficient guarantees, but it does not replace the right to audit. The GDPR text on EUR-Lex sets the obligation, and your legal team should confirm how it applies to your contracts.

What customers usually ask to see first

Most customer audit requests of a processor start with the same short list of documents. Each item answers a specific question the controller must be able to answer for its own accountability, so the controller can ask for the minimum needed and the processor can prepare it once.

Processing description

A written description of what the processor does for this customer: the categories of personal data, the categories of data subjects, the processing activities, and the duration. Annex III of Decision (EU) 2021/915 asks for this kind of description in the controller-processor clauses. It shows whether the processing the processor actually runs matches the instructions in the agreement. Check that it names the systems and environments in scope, not only the service name.

Technical and organisational measures

The description of security measures that Annex III of Decision (EU) 2021/915 expects, including any relevant certifications. It should cover access control, encryption, logging, backup, and incident handling in terms specific to the service. Certifications help but do not replace this description, because Article 28(5) and Article 32(3) treat them as one element of the guarantees. Ask which certificate covers which systems and when it was last issued.

Sub-processor names and contacts

The name, address and contact person of every sub-processor that touches the customer's data. EDPB Opinion 22/2024 says controllers should have this information available at all times, though they need not request each sub-processing contract. Confirm that the list matches the one in the processor agreement and that changes were notified under the agreed authorisation model. Ask where each sub-processor stores and accesses the data.

Breach handling procedure

The processor's documented process for detecting, assessing and reporting a personal data breach to the controller, including the notice period and the content it will provide. This shows whether the controller can meet its own deadlines under Article 33. Ask for the procedure and the last time it was tested, and check who on the processor side makes the decision to notify.

Deletion or return of data

Evidence of how the processor returns or deletes customer personal data at the end of the service, including timing, format of any export, and deletion from backups and sub-processors. Article 28(3)(g) requires the choice to be made by the controller. Ask for the retention rules in writing and a sample of the deletion record, not only a policy statement.

Access logs for customer data

Records showing who accessed the customer's data, when, and for what purpose, including administrator and support access. These logs answer the question of whether the processor acted only on documented instructions. Ask for a sample covering a defined period and confirm how long logs are kept. Request only the entries for the customer's environment, since logs for other tenants are not the controller's to see.

Scaling verification to risk: questionnaire, documents, on-site or remote audit

For processing that involves limited personal data, few systems and no special category data, most customer verification can be handled with a security questionnaire and a set of current documents. Article 28(3)(h) requires the processor to make available all information necessary to demonstrate compliance and to allow for and contribute to audits, but the controller can decide how far to go in proportion to the risk. A proportionate approach usually starts with the processor's written description of its technical and organisational measures, which Annex III of the Commission's controller-processor clauses (Decision (EU) 2021/915) expects to include any relevant certifications.

Questionnaire: Answers on access control, encryption, logging, backup and breach handling, dated and signed by a responsible officer.
Reviewed documents: Current policy set, an independent certificate or report where one exists, and the sub-processor list.
Remote session: A short call with the security lead to clarify answers, without access to production systems.
Escalation triggers: A new category of personal data, a material security incident, or a change in hosting location.

Before accepting answers, confirm that the processor's documents describe its actual setup rather than a generic template.

How certifications and codes of conduct show sufficient guarantees

An approved GDPR certification or code of conduct can support a processor's claim to sufficient guarantees, but it does not replace the audit right in Article 28(3)(h). Article 42 certification is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce the processor's responsibility for compliance. Article 28(5) and Article 32(3) allow adherence to an approved certification or code to be used as an element of proof for sufficient guarantees and for security of processing. The key word is element: the controller still has to judge whether the certified scope matches the service it is buying, and the processor still has to answer questions about the processing that the certificate does not cover.

Before relying on any certificate, check two sources. The EDPB register of certification mechanisms, seals and marks lists approved mechanisms, and the EDPB's first approved European data protection seal for transfers, announced on 16 April 2026, shows how an approved seal can be used as a transfer tool. For each certificate offered, confirm the certificate holder, the issuing body, the validity dates, the scope (which products, locations, systems and processing activities are covered), and whether that scope includes the production environment and any sub-processors your data touches. Ask for the certification criteria and the most recent assessment outcome, not only a logo or a PDF.

ISO/IEC 27001 certificates and SOC 2 reports are useful security evidence, but they are not GDPR certifications unless the scheme has been approved under Article 42. Treat them as inputs to your review of the processor's technical and organisational measures, and ask the certificate holder in writing to confirm that point and to state how the scope maps to your processing. Where a certificate does not cover the service, the controller should scale verification to the risk of that processing, using the processor's documented measures and targeted questions or an on-site inspection.

How a customer audit of a processor runs from request to closure

A customer audit of a processor moves from a written request through agreed scope, document review, a session with the controller or its mandated auditor, and tracked remediation. Each step ends with a record that both parties can point to later.

Receive and triage the audit request
The controller, or an auditor it has mandated, sends a written request stating what it wants to examine and why. The processor's privacy or legal lead checks whether the request falls under the processing agreement, whether the requester has authority to act, and whether the request duplicates evidence already provided. The step closes with a logged request and a named internal owner.
Agree scope and confidentiality terms
Both parties agree in writing which processing activities, systems, locations and sub-processors are in scope, which questions are out of scope, and who may attend. Confidentiality terms cover the processor's security architecture and other customers' data, and the auditor's own obligations are stated. The step closes with a signed scope note or confidentiality agreement that the audit file references.
Exchange documents before any session
The processor provides the information needed to demonstrate compliance, such as its description of technical and organizational measures, sub-processor details, policies, existing certifications or independent reports, and relevant incident history. Requests for documents that the processor cannot share are recorded with the reason. The step closes with a document index that shows what was provided, when, and to whom.
Hold the remote or on-site session
The controller or its auditor reviews the open questions with the people who run the controls, using walkthroughs, screen views, configuration samples or, where agreed, an inspection of premises and systems. The processor records each question, the answer given, and any evidence shown. The step closes with session notes reviewed by both parties and any open items listed.
Record findings and agree remediation
Gaps between the agreed requirements and the observed practice are written as findings with a description, the affected processing, and the risk each creates. The processor proposes remediation actions with owners and completion evidence, and the controller accepts, amends or escalates them. The step closes with a findings register that both parties have confirmed.
Verify remediation and close the audit
The processor delivers evidence for each remediation action, such as changed configurations, updated agreements, or test results, and the controller or auditor checks it against the finding. Items that cannot be closed are carried forward with a documented risk decision. The step closes with a written closure note stating which findings are resolved and which remain open.
Keep the audit record for later reference
The processor files the request, scope note, document index, session notes, findings register, remediation evidence and closure note together, and links them to the processing agreement and the affected records. The file is kept for as long as the controller may need to show how it verified the processor's guarantees. The step closes when the record is complete and the next review date is set in the processor's compliance calendar.

Which evidence answers most audit requests

Most customer audit requests under Article 28(3)(h) are answered with a small set of documents rather than on-site inspections. The cards below cover the records a processor should keep current, who owns each one, and what a controller should check before accepting them as sufficient.

Current security policies and review dates

The information security policy set, with its scope, owner, approval record and next review date, shows the controller what measures the processor committed to. Assessors look first for policies that are dated, approved by management and tied to specific procedures, not generic statements. The processor owns these documents and must review them on a schedule it can prove. An implementation partner can draft or restructure them, but management approves them. Check that the policies describe the systems that actually hold the customer's data.

Independent assurance reports

Where the processor holds an independent report or certificate, it answers a large share of audit questions without an inspection. Confirm the scope covers the services the customer buys, the period covered and whether any exceptions or qualifications were raised. A certificate alone is weaker evidence than a report with a stated scope. The processor owns the report and its scope. An independent auditor or certification body issues it, not the implementation partner.

Penetration test summaries

A summary of recent penetration tests shows which systems were tested, when, by whom and how findings were closed. Request the scope, the test dates, the severity of open items and evidence that retests confirmed fixes. Summaries should be shared under a confidentiality agreement, since full reports reveal exploitable weaknesses. The processor owns the testing program. A security testing provider can perform the tests, but the processor decides which findings to accept or remediate.

Access review records

Periodic access reviews show who can reach customer data and whether that access was confirmed as still needed. Useful records include the review date, the reviewer, the population reviewed and the removals made. Privileged and remote administrator accounts deserve separate lines, since those are where unauthorized access usually starts. The processor's IT or security team owns these reviews. Ask whether support staff outside the EEA appear in the review population.

Backup and restore test records

Backup policies state what is copied and how often, but restore tests prove that the data can actually be recovered. Ask for the date of the last restore test, the systems covered, the time taken and any failures and their fixes. This matters to controllers because availability and recovery are part of security of processing under Article 32. The processor owns the backup program. Restore tests should be run and recorded by the team responsible for operations, with an outside party able to verify the results.

Breach log and notification templates

A processor's breach register and notification templates show how it will meet its duty to notify the controller without undue delay after becoming aware of a breach. Check that the register records incidents that were not notified, that the templates include the information controllers need for their own 72-hour clock, and that named contacts are current. The processor owns the register and must keep it up to date. An outside incident response provider may help write the templates, but the processor must run the process.

Sub-processor register

The sub-processor register names every entity that processes customer data on the processor's behalf, with its location, the service it provides and any transfer mechanism in use. Controllers need it available at all times, along with contact details, so they can judge the chain of processing. Review it for entities that were added without notice and for locations outside the EEA. The processor owns the register and must keep it current. Confirm that changes trigger the notice and objection periods set in the processor agreement.

Who owns the controls, who prepares the evidence and who attests

The processor is the organization that receives the audit under Article 28(3)(h) and remains fully responsible for its security measures, its instructions handling and its sub-processors. Owning a control means the processor decides how it is designed, approves it, operates it and accepts the consequences if it fails. No outside firm can take that responsibility over, and a contract that says otherwise does not change the GDPR position.

Control ownership: Named executives approve the security measures described in the processing agreement and the Annex III description of technical and organisational measures.
Operation: Staff run access reviews, change approvals, monitoring and backups every day, whether or not an audit is scheduled.
Customer communication: The processor answers audit requests, sets the scope, and decides which information to disclose and under what confidentiality terms.
Sub-processor oversight: The processor keeps the list of sub-processors current and confirms that their controls meet the same standard.
Remediation: The processor records findings from its own reviews and from customer audits, then tracks each fix to closure.

Before a customer audit, check who in the processor signs the security description and whether that person can answer for each operating control without referring to a vendor.

What usually makes processor audits slow or costly

Most slow audits come from the same few gaps: contracts that do not say how security will be met, evidence held in too many places, and sub-processor details nobody can produce quickly. Each card below names one of these causes and the fix that shortens the next request cycle for both the processor and the customer.

Contracts that restate the GDPR

A processing agreement that repeats Article 28 without naming controls leaves every audit request open to interpretation. EDPB Guidelines 07/2020 say the agreement should specify how requirements will be met and the level of security required. Check whether the annex lists concrete measures, such as encryption standards, access review frequency and restore testing, that an auditor can test against.

Evidence scattered across tools

When access logs, change records, backup reports and training completions sit in separate systems, each request triggers a manual hunt. Processors should keep a maintained evidence register that maps each security measure in the Annex III description to its source system and owner. Ask for the register first, then confirm that each entry can be exported without engineering time.

Unknown sub-processor locations

Controllers audit sub-processors through the processor, so a missing location or contact delays the whole review. EDPB Opinion 22/2024 says the name, address and contact person of every processor and sub-processor should be available at all times. Maintain a current list with hosting regions and transfer mechanisms, and confirm that updates reach customers before new sub-processors start processing their data.

Repeated bespoke questionnaires

Each customer sending a different spreadsheet forces the processor to answer the same security questions many times, and answers drift apart over time. A standard security questionnaire, kept under version control and reviewed on a fixed cycle, lets the processor answer consistently. Ask customers to accept it first, and reserve bespoke questions for gaps the standard response does not cover.

Scope disputes over on-site inspection

Disagreement about what an inspection may cover, who pays, and whether shared multi-tenant infrastructure is in scope can stall an audit for months. Article 28(3)(h) requires processors to allow and contribute to audits and inspections by the controller or a mandated auditor, but the agreement should define the method, notice period and limits. Agree those terms in writing before the first request, and prefer independent reports where they cover the same systems.

Certifications without matching scope

A certificate can look sufficient while its boundary excludes the services a customer actually uses, which invites a full audit anyway. Article 28(5) and Article 32(3) allow approved certification to support sufficient guarantees, but it does not reduce either party's responsibility. Compare the certificate's scope statement with the customer's processing before accepting it, and ask for a bridge letter covering any period since the report was issued.

Questions processors ask before an audit

Must a processor accept an on-site audit from a customer?

Article 28(3)(h) requires a processor to make available all information needed to demonstrate compliance and to allow for and contribute to audits, including inspections, by the controller or an auditor the controller mandates. The provision does not say that every request must end in a visit to your premises. In practice, the processor's obligation is to contribute, and an inspection is one form of that contribution. Most processors offer documents first, then a call or a scoped remote review, and keep physical access for cases where the controller shows a specific need. Check your processing agreement, because it sets the mechanics, including notice periods, who attends, and confidentiality terms. Your own supervisory authority can also carry out audits and access premises under Article 58(1), which is a separate power from the contractual audit right.

Does a certificate replace a customer audit?

No. The GDPR requires no audit, attestation or certificate, and an approved certification under Article 42 does not reduce the processor's responsibility for compliance. A certificate can be one element that helps a controller judge sufficient guarantees under Article 28(5) and security under Article 32(3), but it does not settle every question. Its scope, its validity period and the controller's own processing risk decide how much further checking is reasonable. Many controllers accept a current certificate plus a questionnaire and a summary of relevant reports for low-risk processing, and ask for direct evidence where the data is sensitive or the processing is novel. Confirm the certificate's scope covers the service you buy, not only the company headquarters.

Who pays for a customer audit of a processor?

The processing agreement usually decides this, so read it before the request. Typically, the controller pays for its own auditors and internal staff time, while the processor absorbs the cost of answering reasonable questions and producing existing documents. Costs rise when the audit requires new reports, extensive onsite time, travel, or repeated rounds of follow-up. Ask the processor for a written statement of what is included in standard assurance and what is charged separately. If you are the processor and buy outside help to prepare for audits, the cost components are the readiness work, evidence collection, any independent assessment you commission, and the recurring effort to keep evidence current. Any figure should come from a written quote tied to a defined scope.

How long does a customer audit request usually take?

The duration depends mainly on the scope of the request, how current the processor's evidence already is, and how many parties must review it. A document-based review of a standard service usually moves faster than an inspection that involves multiple sites, sub-processors and open findings. Delays tend to come from unclear questions, missing sub-processor details and requests that arrive without an agreed scope or timetable. Ask the processor to confirm its response process and the expected sequence of steps when you send the request. Because the GDPR sets no fixed audit length, the processing agreement and your internal third-party review timetable should set the expectations you will hold each other to.

Can a processor prepare for audit requests internally?

Yes, many can, provided they have clear ownership of the controls, current policies and a repeatable way to produce evidence. The work involves maintaining a security questionnaire answer bank, a current sub-processor list, a record of processing that reflects the service, recent test results, access reviews, backup and restore evidence and incident records. Internal teams often handle routine requests well but struggle when a customer asks for something unusual, such as evidence from a sub-processor or a complex inspection. Where the gap is capacity or independence, an outside implementation partner can prepare systems and evidence. Only an independent auditor or certification body can issue a report or certificate, so preparation support does not replace that step.

What does the work need from our engineering and security teams?

The work needs named owners in engineering, security, legal and customer success, and it needs them to agree on a single source of truth for evidence. Expect requests for architecture diagrams, data flow maps, encryption and key management descriptions, access control and MFA settings, logging and monitoring coverage, backup and restore tests, vulnerability management records, and incident response procedures. Engineers should be ready to explain how these controls operate in production, not only how they are designed. Typical inputs include:

Current configuration exports and screenshots dated to the review period
Access review records and offboarding evidence
Test reports and remediation tracking for the service in scope
The sub-processor list and the contracts that flow down your obligations

Ask the processor which artifacts it keeps current and who approves releases to customers.

How should a controller scale audit checks to its risk?

Scale the checks to the sensitivity, volume and novelty of the personal data, and to the consequences of a failure. Low-risk processing may need only a current certificate, a completed questionnaire and a review of the processor's breach and sub-processor commitments. Special category data, large-scale profiling or a processor with broad remote administration access may justify document review, a scoped remote session and sample testing of specific controls. Record the reasoning in your vendor file, because the controller remains accountable for choosing a processor with sufficient guarantees. Revisit the decision when the service, the data or the sub-processors change.

When to bring in an implementation partner or assessor

Bring in outside help when the evidence pack for customer audits is incomplete, scattered or out of date, or when no one on your team has time to assemble it. An implementation partner can map your Article 28(3)(h) answers to the systems that produce them: the current Annex III security description, sub-processor contact records, access review exports, encryption settings, logging configuration, backup restore tests and breach runbooks. The partner prepares that material and the documentation around it. Your organization still owns the controls, and your own staff must be able to explain and run them when a customer or supervisory authority asks questions.

A second, narrower use is an independent assessment before a customer audit, to find gaps while there is still time to fix them. Ask any consultant for a fixed written scope before work starts: the processing activities and systems covered, the customer audit questions to be answered, named deliverables such as an evidence index or a gap register, the people you need to provide, the review cycle, and what is excluded. Ask whether the work includes remediation or only findings. Ask who will do the work and whether they have worked on your platforms. Quotes should follow from that scope, so compare offers against the same written scope.

Keep preparation and certification separate. If you intend to rely on a certification or report, such as an approved certification under Article 42 or a third-party attestation, the body that issues it must be independent of the people who designed or built the evidence. The GDPR itself requires no audit or certificate, and certification does not reduce your responsibility as a processor. Confirm with the certifying body or auditor which preparation activities they accept as independent, and do not let the team that wrote the evidence pack also sign off on it.

How DeployOpen prepares processors for customer audits

DeployOpen helps processors prepare the systems, controls and evidence that customer audit requests usually ask for, working inside the client's own infrastructure. The processor owns its obligations and decides how it answers each audit request, while DeployOpen prepares the technical material behind those answers.

How we scope

Engagements are fixed-scope, with the systems, customers and audit requests covered agreed in writing before work starts.
The written scope names which self-hosted platforms, environments and evidence sets are included for customer audit readiness.
Scope also states what is out of bounds, such as sub-processor contract reviews or legal interpretation of the processing agreement.

How we build

We configure logging, access records, backup and restore evidence and security settings inside the client's own cloud or data center.
Security testing of applications, APIs and infrastructure can run alongside the build to check the measures you describe to customers.
Each control is documented against the security measures your processing agreement and Annex III description will state.

How we hand over

You receive written documentation of configurations, evidence locations, and the control owner for each audit request category.
An audit request pack maps existing evidence to common customer questions, so your team can answer without rebuilding material each time.
Handover includes instructions for keeping evidence current, so the pack still matches your systems after upgrades or changes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the fixed-scope work.
A retainer can keep the audit pack current as platforms change and as new customer or regulator requests arrive.
Questions about which certification or code of conduct your customers accept are for your legal and compliance team and any accredited body you engage.