Accounting software and ERP in a gestoría as processor: the supplier's obligations under the RGPD

Behind every modern gestoría there is, almost always, several technological pieces: an accounting or business management ERP, specific payroll software, an electronic invoicing platform and a cloud document manager for exchanging documentation with each client company. All of them process personal data of the client companies, their workforce and their suppliers. And all of them, by the functional nature of the service they provide, are processors within the meaning of art. 28 of the RGPD.

This guide reviews what contract the gestoría should sign with those suppliers, what technical and organisational safeguards to require from them, how the typical international transfers in the sector are covered and what rules apply when a platform is changed and the tax and employment history needs to be recovered.

Why the ERP, accounting software and invoicing platform are processors

Art. 4.8 RGPD defines the processor as the natural or legal person, public authority, agency or other body that processes personal data on behalf of the controller. In the gestoría sector there is a three-level chain that it pays to keep clear:

• The client company is the controller of the data of its workforce, its suppliers and its own customers. It decides on purposes and means.
• The gestoría is the processor in relation to the client company: it processes payroll, files Social Security returns, calculates taxes and keeps the books on behalf of the company, in accordance with its instructions.
• The supplier of the ERP, the accounting software or the invoicing platform is, in turn, a sub-processor in relation to the client company: it processes those same data on behalf of the gestoría, which acts as the principal processor. Sub-processor authorisation must appear in the art. 28 contract between the gestoría and each client company (arts. 28.2 and 28.4 RGPD).

That is the standard chain. Although some supplier contracts are presented under different commercial labels, what matters is the functional role with respect to the data.

Difference with official platforms: TGSS, AEAT, Sistema RED and SILTRA

A common confusion in the sector is to assume that any system the gestoría connects to is a processor. It is not. Public administrations that receive the data have a different regime:

• The General Social Security Treasury (via the Sistema RED), the Tax Agency (electronic office, tax forms) and the collaborating mutual insurers are independent controllers within their areas of competence. They receive the data in compliance with the client company's legal obligations (art. 6.1.c RGPD), not on behalf of the gestoría.
• No art. 28 contract is signed with those administrations: those contracts are designed for the controller–processor relationship, not for a legal disclosure between independent controllers.
• What can be a processor or sub-processor is the client software the gestoría uses to communicate with those administrations (transmission systems, online filing tools, electronic signature platforms). Those technology suppliers process the data on behalf of the gestoría — and, ultimately, of the client company — and fall under art. 28 RGPD.

The official electronic signature platforms and qualified trust service providers (FNMT, qualified providers) typically act as independent controllers in the issuance and validation of certificates, in accordance with Regulation (EU) 910/2014 (eIDAS).

The art. 28 contract: minimum content

The processor contract with the ERP, the accounting software or the invoicing platform must meet the minimum content of art. 28.3 RGPD. It is not a short clause in the general terms of service: it is a specific document or annex.

Sub-processors: how it is covered that the ERP uses AWS, Azure or GCP

Practically all current ERPs and accounting software rely on a cloud hyperscaler (AWS, Microsoft Azure, Google Cloud) to host the infrastructure. That infrastructure provider is not just any supplier: it processes personal data of the client companies, on behalf of the ERP, which makes it a sub-processor.

• Art. 28.2 RGPD requires the prior authorisation — general or specific — of the controller for the processor to engage sub-processors. General authorisation must allow the controller to know the list and to object on reasoned grounds to changes.
• Art. 28.4 RGPD requires the sub-processor to be subject to the same data protection obligations as the principal processor, by contract or equivalent legal act.
• If the sub-processor is outside the European Economic Area, the international transfer rules in Chapter V RGPD also apply.

The art. 28 contract with the ERP must contain a list of sub-processors — or a link to a page kept up to date with that list — and a clear mechanism for notifying new additions, with a reasonable period for the gestoría — and, through it, the client company — to object if it sees fit.

International transfers: Data Privacy Framework and CCT

It is very common for the ERP, the accounting software or their infrastructure sub-processors to have servers in the US or in distributed cloud regions. The rules on transfers revolve around a few key elements:

• Adequacy decisions of the European Commission (art. 45 RGPD): allow transfer without additional safeguards where the Commission has recognised an adequate level of protection.
• Data Privacy Framework (DPF): for the US, the usual operational safeguard is the supplier's adherence — and, where applicable, that of its infrastructure sub-processor — to the DPF, which operates as a partial adequacy decision. It is the gestoría's responsibility to verify that adherence is active on the official list.
• Standard Contractual Clauses (CCT): approved by the Commission, complemented where appropriate by supplementary measures following a Transfer Impact Assessment.
• Derogations under art. 49 RGPD: applicable only in occasional cases and not for systematic flows such as those of the ERP.

The art. 28 contract must identify the storage regions, the safeguards applicable to international transfers and the supplier's undertakings in the event of changes. A recommended practice is, where the supplier allows, to choose a storage region within the EU to reduce exposure to transfers.

Security and profiles: differentiated roles and per-adviser logs

The ERP, the accounting software and the invoicing platform must allow, as a measure under art. 32 RGPD, granular management of the gestoría team's access:

• Differentiated profiles by function: employment adviser, tax adviser, accounting adviser, administrator, reception, supervisor, administration. Each with access only to what is necessary for their role.
• Individual account per adviser, with no shared credentials. Second-factor authentication where available — and, for profiles with access to bulk workforce data, it should be required of the supplier.
• Access logs: which adviser consulted which file, which client company, which payslip and when. That traceability is the basis for investigating incidents, handling data subject rights and demonstrating compliance.
• Immediate revocation when an adviser leaves the gestoría. The supplier must allow users to be deactivated with immediate effect.
• Quarterly periodic review of active users on the firm's side.
• Encryption at rest and in transit, regular backups and a documented recovery plan.

At the end of the contract: full export of the tax and employment history

Changing the ERP, accounting software or invoicing platform is one of the most delicate moments in the relationship with the supplier. The rule in art. 28.3.g RGPD is clear: at the end of the service, the processor must return or delete personal data at the controller's choice. The correct operational choice for a gestoría is:

1. Request in writing the full export of the accounting, employment and tax history of each client company, in a structured and useful format: accounts in standard format (journal, ledger, balance sheets), payroll and TC forms in CSV or Excel, filed tax forms in the official AEAT format (.csb, XML), associated documentation and metadata.
2. Verify the export: check that the volume exported matches the actual history, that it opens correctly in the new system and that the integrity of the files is preserved (client–worker relationships, tax periods, document links).
3. Comply with legal retention periods: the export must cover, at the very least, the four tax years of the tax limitation period and the six commercial years of the Commercial Code. If a client has longer contractual periods, they are respected.
4. Only then, authorise the outgoing supplier in writing to carry out final deletion in its systems (including sub-processors and backups, in accordance with the supplier's technical timeframes).
5. Keep documentary evidence of the entire process: request, export receipt, deletion authorisation, destruction certificate.

This routine is not a legal whim: it protects the gestoría — and, ultimately, each client company — so that they can continue to meet their legal retention periods without being trapped by a supplier that no longer provides the service. Any contractual clause attempting to impose automatic destruction without prior export is contrary to art. 28.3.g RGPD.

Supplier migration: how to protect the data during the transition

Migration between ERPs or accounting software is usually a process of several weeks in which the data live simultaneously in the outgoing and incoming systems. The operational routines:

• Documented migration plan: scope, dates, leads on the gestoría and the supplier sides, communication channels.
• Information to client companies: prior communication explaining that their data will be migrated to a new sub-processor, the identity of the new sub-processor and, where applicable, the possibility of reasoned objection in accordance with the art. 28 contract.
• Encrypted transfer channel between suppliers. Never by unencrypted email or via a public shared folder.
• Double verification of data integrity in the new system before any deletion in the old system.
• Minimum coexistence period: the old system remains operational — at least in read-only mode — for the time needed to detect any incidents.
• Migration logs kept as evidence in the event of a future incident.

Checklist to choose a responsible ERP

Before contracting a new ERP, accounting software or invoicing platform — or when renegotiating an existing contract — this is a minimum script to cover:

• The supplier signs an art. 28 RGPD contract with the minimum content of art. 28.3.
• It clearly identifies sub-processors and provides a mechanism to know them and object to changes.
• It indicates the storage regions and, where these are outside the EU, the applicable safeguards (DPF, CCT, adequacy decision).
• It allows differentiated access profiles, individual accounts per adviser and second-factor authentication.
• It keeps access logs that the gestoría can consult for traceability and incident investigation.
• It holds recognised security certifications (ISO/IEC 27001, ISO/IEC 27701, SOC 2) and shares the corresponding reports.
• It guarantees the full export of the accounting, employment and tax history in a structured format before any deletion.
• It has a breach notification procedure to the principal processor without undue delay.
• It does not include clauses allowing the data of client companies to be reused for the supplier's own purposes (commercial analytics, machine learning on real data, marketing).
• It has a business continuity and disaster recovery plan in the event of incidents, with committed timeframes.

If you run a gestoría or asesoría and want to review your data protection documentation, at Certix we work specifically with gestorías and asesorías. No salespeople: from the very first contact, you will speak with a specialist.

This content is for general guidance and information purposes only; it does not in any case constitute specialised legal advice. Regional sectoral rules may extend or modify the deadlines and requirements of national legislation. The application of the rules to each specific case requires individual analysis.