Article 31 Cooperation with the supervisory authority

Article 31 obliges controllers, processors and their representatives to cooperate with the supervisory authority on request. This page explains what regulators can demand, how readiness is tested and what evidence holds up.

On this page

What Article 31 asks for when a regulator comes knocking

When a regulator letter, a complaint or an inspection request lands, the first question is what you are obliged to do. Article 31 requires controllers, processors and, where applicable, their representatives to cooperate with the supervisory authority on request in the performance of its tasks. The duty is reactive: it is triggered when the authority asks, and it covers the whole range of its functions, not only the matter in the letter. The GDPR on EUR-Lex sets out the duty, and the powers behind it sit in Article 58(1), which lets the authority order any information it requires, carry out data protection audits, and obtain access to all personal data and to premises, including processing equipment.

This duty is practical, not paperwork. An authority can ask for a copy of your records of processing under Article 30(4), walk into a data center or ask engineers to demonstrate how access to a database is granted and logged. Your team needs to answer with accurate, current material within the deadline the authority sets, which is usually short. Confirm with the authority or your counsel what deadline applies to your letter, and check whether the request is a simple information request or part of a formal investigation, since the response expected differs.

What usually makes this hard is structure, not intent. Responsibility often has no single owner: the privacy team holds the policies, IT holds the system settings, and the business owns the processing purpose, so nobody can assemble the full answer quickly. Records are scattered across ticketing tools, cloud consoles and spreadsheets, and retrieval is slow because nobody has tested it. Before any letter arrives, name one accountable lead, map where each category of evidence lives, and rehearse a retrieval exercise. Cooperation is also a factor in fines under Article 83(2)(f), so how you respond matters as well as what you find.

Who must cooperate and which systems a regulator can reach

Article 31 places the duty to cooperate on the controller, the processor and, where one is appointed, the representative. The practical work starts with deciding which processing activities, hosting environments and records fall inside a supervisory authority's reach, because each of those decisions changes what must be ready when a request arrives.

Controller duty and accountable owner

The controller carries the primary duty to cooperate with the supervisory authority on request, and it is the party that answers for the outcome. Name one accountable owner who can receive a regulator's request, route it to engineering and legal, and sign off the response. Confirm that the owner knows which systems hold personal data for each processing activity, because a regulator will ask for that mapping first.

Processor duty and assistance

A processor must cooperate with the supervisory authority in its own right, and its contract with the controller should say how requests are passed along and answered. Check that the processing agreement sets timelines for forwarding a regulator's request and names who inside the processor can provide logs, configurations and access. Ask whether the processor can produce evidence without waiting for the controller to coordinate every step.

Representative for non-EU entities

Where a controller or processor outside the Union is caught by the territorial scope rules and has appointed an EU representative, that representative must also cooperate on request. Confirm the representative has a current copy of the processing record, the contact channel and the authority to receive correspondence. Appointing a representative does not move liability away from the organization itself.

Processing activities and records in scope

A regulator can ask for the record of processing activities, which Article 30 requires to be made available on request. Scope the request by listing each processing activity, its purpose, its data categories and the systems that support it. Gaps in this list become gaps in the response, so reconcile the record against actual application inventories before any request arrives.

Hosting environments and sub-processor systems

Investigative powers cover access to all personal data, which reaches into production, backups, analytics copies and sub-processor platforms. Map every environment where personal data sits, including the systems of hosting providers and sub-processors, and confirm the contracts allow the controller to obtain what it needs. Ask each sub-processor how it would produce logs or data on a regulator's instruction.

Premises, equipment and audit access

Supervisory authorities may carry out data protection audits and obtain access to premises, including processing equipment. Decide in advance which facilities, physical media, network segments and administrative consoles could be in scope, and who is authorized to grant access. Confirm with counsel which self-hosted or on-premises locations would need to be shown, and document how access is logged and supervised.

How a supervisory authority tests cooperation

This table sets out how a supervisory authority typically tests cooperation under Article 31, what it asks the organization to produce, and where responses tend to fall short. Read each row as a stage of an inquiry, from the first information request through to the authority's review of the records and systems. The main takeaway is that the authority judges cooperation by how quickly and completely the organization can produce accurate, current evidence on request.

Test stageEvidence requestedCommon findings
Written information requestDocuments, explanations and data flow descriptions named in the request, with the scope the authority setsAnswers arrive late, cover only part of the question, or describe controls that differ from what is actually operating
Access to records of processingThe Article 30 record of processing activities, produced in the form the authority asks forRecord is outdated, missing systems or processors, or cannot be produced quickly from a single source
Audit and inspection powers (Article 58(1))Access to personal data, systems, processing equipment and premises, as the authority specifiesAccess is delayed, logs are incomplete, or staff cannot explain how the system handles personal data
Review of security measuresRisk assessment, configuration records, access reviews, logs and evidence that the Article 32 measures operateMeasures are documented but not evidenced, or evidence dates from before the processing changed
Processor and sub-processor checksProcessor contracts, instruction records and sub-processor lists, with proof they are currentContracts are missing required terms, or the processing chain the organization describes does not match the contracts
Timeliness and completeness of responsesDated response log showing when each request was received, answered and what was withheld or pendingNo single owner for requests, unclear deadlines set by the authority, or follow-up questions that show earlier answers were incomplete
Remediation after findingsCorrective action plan, owners, dates completed and evidence the fix worksActions are promised without evidence, or the same weakness reappears in a later review

How to build a regulator response capability

This sequence gives a controller or processor a named owner, a map of where personal data and records sit, a tested intake process, and an evidence index ready before a supervisory authority asks for anything under Article 31. Each step ends with a written output you can inspect.

  1. Name an owner and escalation path

    Assign one accountable owner for regulator contact, usually the data protection lead or the DPO where one is designated, with a named deputy. Document who inside legal, security, engineering and executive management must be informed, in what order, and who may speak to the authority. The output is a short written escalation chart, approved by senior management and stored where staff can find it during an incident. Confirm that every person on the chart knows their role and has current contact details.

  2. Map where records and personal data live

    Work from the record of processing activities to the systems that hold each processing activity, including SaaS tools, backups, logs, sub-processors and any remote support access. Article 30(4) requires records to be available to the authority on request, so the map must show that the records can be produced quickly. The output is a system inventory linked to each processing activity, with the owner, hosting location and processor for every system. Check the map against a sample of live systems, not only the documentation.

  3. Define intake and triage for authority requests

    Set up a single intake channel so that any letter, email, call or on-site visit from a supervisory authority reaches the owner the same day. Triage each request against the powers the authority may use under Article 58(1), including orders for information, data protection audits and access to personal data and premises. Record the scope, the deadline stated by the authority, the systems involved and whether legal privilege or confidentiality needs handling. The output is a triage log entry and a response plan for each request, reviewed by counsel before any substantive reply.

  4. Prepare an evidence index

    Build an index that points to the evidence an assessor or authority would likely ask for: records of processing, security measures under Article 32, policies, processor contracts, training records, DPIAs, breach logs and access reviews. Each entry should name the document, its owner, its last review date and the system it covers, and it should sit in a location that can be exported in its current form. Gaps are recorded as open items with an owner. The output is a maintained index that a named person can produce within the time the authority sets.

  5. Rehearse a mock request

    Run a tabletop exercise in which a fictional, clearly labelled (illustrative) authority letter asks for records, processor contracts and evidence of a security measure. Time the team from intake to a complete response draft, and note where the owner, the systems or the evidence index slowed things down. Include a case where a request covers a processor, so the processor's duty to cooperate under Article 31 is tested in practice. The output is a written after-action report with assigned fixes, owners and a re-test date.

  6. Set a review cycle

    Schedule regular reviews of the escalation chart, system map, triage procedure and evidence index, and trigger an extra review after any significant change such as a new processor, a hosting move or a reported incident. Confirm that the cooperation record also shows how the controller cooperated with the authority, because Article 83(2)(f) treats the degree of cooperation as a factor in deciding fines. The output is a dated review log showing what changed, who approved it and which open items remain. Ask any external reviewer you use to confirm the cycle matches your risk profile.

How cooperation changes the size of a fine

Cooperation with the supervisory authority is one of the factors a regulator weighs when it decides whether to fine and how much. Under Article 83(2)(f), the degree of cooperation to remedy an infringement and mitigate its effects is listed among the circumstances that shape a fine. In practice, this means that a controller or processor who responds promptly, supplies complete information, fixes the defect and documents the fix is in a better position than one who delays or answers partially. The factor works in both directions. Cooperation does not erase an infringement, and it cannot be assumed to offset a failure that caused serious harm. Your team should therefore treat every supervisory request as a deadline-driven task with an owner, a response log and a record of what was changed as a result.

Refusal to cooperate carries its own, heavier exposure. Failing to give the authority access in breach of Article 58(1), which covers information, audits and access to personal data and premises including processing equipment, falls in the higher tier under Article 83(5)(e): up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Before an inspection, confirm who in your organization can authorize access to production systems, backup locations and processing equipment, including systems run by a hosting provider or outsourced operator, and whether contracts with those providers let you grant that access in time. Records of processing under Article 30(4) must also be producible on request, so keep them in a form that can be sent without a rebuild.

Fine amounts depend on many factors beyond cooperation, including the nature, gravity and duration of the infringement, the categories of data involved and the controller's history, so no general estimate is reliable for your case. Take legal advice from counsel qualified in the relevant Member State before making any statement to a regulator about a specific matter. Also note that Regulation (EU) 2025/2518 lays down additional procedural rules for complaints and investigations in cross-border GDPR enforcement cases and applies from 2 April 2027. Confirm with counsel how those rules will affect cases involving several supervisory authorities, and plan your cooperation process to work across those authorities as well as the one that writes to you first.

Evidence that shows cooperation is ready

Article 31 cooperation is judged on what the organization can produce quickly and accurately when a supervisory authority asks. The artifacts below are the working set an assessor or authority will expect to see, and each one needs an owner and a refresh routine so it reflects the systems as they are on the day of the request.

Current records of processing

The record of processing activities is the first document an authority will request, and Article 30(4) requires it to be made available on request. For each processing activity, check that the purposes, categories of data, recipients, transfers and retention periods match the systems actually running, including self-hosted platforms deployed in the client's own cloud or data center. Review the record after every new system, material change of vendor, or new processing purpose, and record the date and approver of each revision so the version presented during an inspection can be shown to be current.

Authority request runbook with named owners

A runbook sets out who receives a request from a supervisory authority, who validates scope, who collects evidence, who signs off the response, and who is the contact for follow-up. Name a primary and a deputy for each role and state the escalation path to the DPO and legal counsel. Test the runbook with a tabletop exercise at least once a year and after any organizational change, because an authority may set its own deadline and an unclear owner is a common reason responses are late.

Document index mapping requests to systems

An index links each category of likely request, such as records, security measures, access lists or transfer documentation, to the system, repository and owner where the evidence lives. Include the platform components of self-hosted deployments, backup locations and any sub-processor holding copies. Confirm the index with each system owner on a fixed schedule and whenever infrastructure changes, since an index that points to a retired repository slows the response as much as having no index at all.

Access logs and audit trail retrieval procedure

Authorities may obtain access to personal data and to processing equipment under Article 58(1), and they may carry out data protection audits. Document how administrator access, authentication events and data access logs are exported from each platform, how logs are preserved against overwriting, and how their integrity is shown. Run a retrieval drill against a sample date range and confirm that the export is readable, complete and covers the retention period the record of processing declares.

Processor cooperation clauses and contacts

Processors and their sub-processors must cooperate with the controller so that the controller can answer an authority, and that duty should be visible in the processing contract. Check that each contract gives the controller a route to obtain records, logs and assistance within a stated time, and that the contacts for each processor are current. Where DeployOpen or another implementation partner supports the platform, confirm in writing who holds which evidence and how it is passed to the controller during an inspection.

Log of past requests and response times

A register of earlier requests from authorities, complaints forwarded to the organization and the responses given shows how the team actually performs. Record the date received, the authority, the scope, the owner, the date sent and any follow-up. Review the log quarterly to find recurring gaps, such as the same evidence being requested again, and update the runbook and index to close them. Keep the log itself under the same retention rules as the records it describes.

What cooperation readiness costs and what drives it

This table breaks down the cost components of being ready to cooperate with a supervisory authority under Article 31, marking which are one-time and which recur and what pushes each up. No fee figures are supplied for this topic, so use the rows to structure a written quote and compare proposals line by line.

Cost componentWho is paid or who spends timeOne-time or recurringWhat drives it and what to request in a quote
Internal legal and privacy timeYour legal, privacy and compliance staffRecurringVolume of authority requests, number of processing activities and jurisdictions. Ask who owns the request workflow and how many hours are assumed per request type.
Engineering time to build retrieval and loggingYour engineers or an implementation partnerOne-time build, then recurring upkeepNumber of systems holding personal data, log coverage and export formats. Ask which systems are in scope, what retrieval produces, and what ongoing maintenance is included.
Record of processing maintenancePrivacy team, system owners and sometimes an external adviserRecurringNumber of processing activities, system changes and processors added. Ask how updates are triggered when systems change and who signs off each revision.
External legal counsel or outsourced DPO supportExternal law firm or DPO service providerOften on call, sometimes retainedCross-border cases, complexity of the authority's questions and contract scope. Ask for hourly or retainer terms, response time expectations and what is excluded.
Mock exercises and tabletop reviewsInternal teams, facilitators and possibly an external assessorRecurring at an agreed intervalNumber of teams involved and systems covered per exercise. Ask what the exercise tests, what evidence it produces and how findings are tracked to closure.
Processor coordinationYour team and each processor's contactsRecurringNumber of processors and sub-processors that must supply information quickly. Ask how processor contact points and response timelines are documented in contracts.
Independent review of readinessIndependent auditor or qualified reviewerPeriodicScope of systems reviewed and depth of testing. Ask who is independent of the implementation work and that the reviewer issues findings, not certifications.

Who owns the response, who prepares evidence and who the regulator trusts

Article 31 places the duty to cooperate on the controller, the processor and, where applicable, their representatives. That duty cannot be handed to a consultant or vendor. Your organization decides how it responds to a request, which person speaks for it, what it discloses and what it refuses to disclose without legal review. The legal and privacy functions remain accountable for every statement made to the authority.

  • Named contact: Appoint a person or role who receives supervisory authority requests and has authority to commit the organization to deadlines.
  • Response decisions: Decide what information is produced, in what form, and what needs legal privilege or confidentiality review before release.
  • Remediation ownership: Own corrective actions and their timelines, since Article 83(2)(f) weighs how the organization remedied an infringement.
  • Records of processing: Keep the Article 30 record current, because it must be made available to the authority on request.
  • Staff readiness: Brief staff on how to escalate an authority contact, including unannounced visits and requests for access to premises and equipment.

Confirm internally who is authorized to receive and answer a supervisory authority request, and whether that role is documented in your incident and governance procedures.

Where organizations fall short when a regulator asks

Most organizations that struggle under an Article 31 request do not lack security tooling. They lack a named owner, current records, fast access to evidence, cooperation terms with their processors, and a tested process. The gaps below are the ones that tend to surface first when a supervisory authority asks for information.

No named owner for regulator contact

When a supervisory authority writes to the organization, the request often lands in a general mailbox and waits. Article 31 places the duty on the controller or processor itself, so the organization must show who receives the letter, who decides what to provide, and who signs the response. Check that a named role, with a deputy, is recorded in the incident and privacy runbooks and that the contact details registered with the authority are current. Confirm the arrangement with a tabletop exercise rather than a document review alone.

Outdated records of processing

Article 30(4) requires records of processing to be made available to the supervisory authority on request, so a stale register is a visible failure. Systems added through new projects, vendors onboarded by business teams and retired services often never reach the record. Compare the register against the asset inventory, cloud accounts and the contracts list each quarter, and record the date of the last review and the person who approved it. Ask who is accountable for updates when a new system goes live.

Logs that cannot be exported quickly

Under Article 58(1) an authority may require information and access to personal data and processing equipment, and the timeline for providing it is set by the authority, not by the organization's ticket queue. Logs that sit in several platforms, have short retention or can only be read by one administrator slow the response and invite follow-up questions. Test an export of access and processing logs for a defined date range, time how long it takes, and confirm that the output is readable without the engineer who built the system. Document the export procedure and the retention periods that apply.

Processors with no cooperation terms

Cooperation under Article 31 extends to the processors and the infrastructure they operate, so a hosting provider or support vendor that refuses to share logs, locations or staff access can stall the organization's own response. Review processor agreements for duties to assist the controller, timelines for forwarding information, and how the processor handles direct contact from an authority. Ask each processor to confirm, in writing, the contact route and expected turnaround for supervisory requests. Where terms are missing, raise them through the contract amendment process before a request arrives.

Cooperation not weighed in fine decisions

Article 83(2)(f) makes the degree of cooperation with the supervisory authority, to remedy an infringement and mitigate its effects, a factor in deciding fines. Organizations often treat cooperation as an afterthought, so the evidence of prompt, complete and candid responses is never assembled. Keep a dated log of each request, what was supplied, what was declined and why, and the remediation steps taken. Assign someone to maintain that log from the first contact so the record exists when the decision is made.

No rehearsal of the response

A first response to an authority that has never been rehearsed usually reveals missing contacts, unavailable evidence and unclear approval rights under time pressure. Run a scenario in which an authority requests processing records, access logs and a list of processors for a specific system, and measure what the team can produce and in what order. Record the gaps, assign owners and repeat the exercise after changes to systems or staff. Confirm with your legal and privacy advisers how the exercise is scoped and documented.

Questions buyers ask about Article 31 readiness

What does cooperating with a supervisory authority cost in effort?

Article 31 itself carries no fee, but cooperation has a real effort cost that falls on your organization first. Most of the work is internal: locating records, producing the records of processing on request, answering information demands and making systems and staff available for inspection. The effort scales with how well your records already exist and how many systems hold personal data. The supplied facts do not give a cost figure, so ask any adviser to price the work from a written scope covering which systems, which records and which staff are in play. Expect the one-time cost of building an evidence set and the recurring cost of keeping it current to be separate lines in any quote.

How long does preparing for supervisory authority cooperation take?

Preparation time depends mainly on the state of your records and the number of systems in scope, not on Article 31 itself. An organization with a current record of processing, documented security measures and a tested process for producing evidence will need far less time than one assembling these from scratch. Duration drivers include the number of processing activities, the number of processors and sub-processors, whether records are kept centrally, and how many people must sign off. Ask for a timeline tied to a written scope, and ask which milestones depend on your own staff.

What does the work need from our internal staff?

Your staff must own the facts that only your organization holds. That includes who the controller contacts are, what each system does with personal data, where that data lives, which processors and sub-processors touch it, and who can authorize access to premises and equipment. Engineers must be able to explain system architecture, logging and access arrangements, and a named person should coordinate all responses to authority requests. Legal and data protection roles must agree on what gets disclosed and when. Plan for these people to be available at short notice, because the authority can set the timing of its requests.

Can a small team handle supervisory authority cooperation alone?

A small team can handle cooperation alone if its processing is limited and its records are accurate, because the duty is to respond on request, not to run a standing program. The difficulty is continuity: a small team may have one person who knows where everything is, and an authority request can arrive at any time. Check whether you can produce the record of processing, the security documentation and the names of people who can grant access within a short period. If any of those depend on one individual, document them now. Confirm your obligations against the regulation text and, where needed, your national authority's published guidance.

When should we bring in outside help for cooperation readiness?

Bring in outside help when the readiness gap is larger than your team can close while running normal operations, or when you need an independent view of your evidence. Common triggers include a first regulator inquiry, a cross-border processing footprint, many processors, or systems that were never documented. An implementation partner such as DeployOpen can prepare systems, controls and evidence within a written, fixed scope. It cannot issue audit reports or attestations, and it cannot speak for your organization to the authority. Ask any partner to state in writing what it will and will not deliver.

Does Article 42 certification remove our duty to cooperate?

No. Certification under Article 42 is voluntary, lasts for at most three years, and is issued by accredited certification bodies or supervisory authorities. It does not reduce the controller's or processor's responsibility for compliance, and it does not replace cooperation with the authority on request. A certificate may serve as evidence of diligence, but you still need to produce records, answer information requests and allow access when asked. Treat certification as one input to your evidence set, not as a shield.

Does cooperation with the authority reduce fines?

Yes, cooperation is a factor the authority weighs when deciding fines. Article 83(2)(f) makes the degree of cooperation to remedy an infringement and mitigate its effects a factor in that decision. Failing to provide access in violation of Article 58(1) falls in the higher fine tier, up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. Cooperation therefore protects you on both sides: it lowers exposure where a breach exists and avoids a separate access violation.

How DeployOpen prepares systems and evidence for regulator requests

When a supervisory authority asks for information under Article 31, the organization answers, not its implementation partner. DeployOpen's part is to make sure the systems that hold personal data can produce accurate answers quickly. In practice, that means scoping the platforms in question, implementing self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and configuring them so that logs, access records, configuration history and processing records can be retrieved and explained. DeployOpen does not decide what the organization must disclose, and it does not issue audit reports, attestations or certificates. Only an independent auditor or certification body does that. The organization owns its controls and its regulator relationship.

Readiness work is usually the most useful part of the engagement. Before a request arrives, DeployOpen can work with the client to map which systems hold records of processing, where logs are kept and for how long, who can export what, and how long a retrieval takes in practice. The output is a written inventory of evidence sources, a retrieval runbook and, where the client asks for it, a test in which the team pulls a sample set of records and checks that they are complete and attributable. Confirm with your own counsel how much time your organization must respond within, since that depends on the request and the authority, and build the runbook around that figure rather than an assumed one.

Every readiness engagement is fixed-scope, with the systems covered, deliverables and timelines agreed in writing before work starts. Ask for a quote that lists each system in scope, the logging and export configuration to be delivered, who on the client side approves the runbook, and what happens if a request covers a system outside the agreed scope. Ongoing support, upgrades and continuous testing can be added as a retainer if the client wants the evidence kept current after the first handover. Either way, the decision about what to hand to a regulator, and how to present it, stays with the organization and its legal team.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.