Short Answer
Sub-processes are not a separate category of the GDPR. Here, the term refers to an organizational and technical structural principle in the Record of Processing Activities: A central master process represents the common core of a process. Local or use-case-specific variants are managed as subordinate instances of this master process.
Such a model can be particularly relevant for corporate groups. Many processes are carried out in a similar manner across multiple companies, countries, or locations, but differ in specific details. Under these circumstances, unlinked copies can lead to inconsistencies. In contrast, master processing with associated sub-processes makes it possible to link common standards, local variations, responsibilities, approvals, versions, status information, and the decommissioning of variants that are no longer needed.
Local Differences in the Consolidated RoPA
In corporate groups, there are numerous data processing activities that are carried out in a similar manner across multiple companies or at multiple locations. This applies, for example, to HR processes, applicant management, CRM, tenant communication, facility management, supplier management, visitor registration, training administration, IT support, fleet management, whistleblower systems, and marketing processes.
The core process is often similar across the board. Upon closer inspection, however, there may be significant differences. One company uses a local service provider, while another relies on a provider used group-wide. At individual locations, additional data is processed or additional recipients are involved. Retention periods may vary due to local requirements. The specific purpose, the applications used, the Legal basis Or, the internal approval processes do not have to be identical across all companies.
Not every one of these deviations necessarily requires a completely independent processing activity. However, it must be documented in a structured manner so that the common standard and the respective local specifics remain clear.
In practice, an existing processing activity is often duplicated and then adapted for the specific company or location. This approach can initially reduce the documentation burden. However, as the number of duplicates increases, it becomes more difficult to identify the connection between the original process and the local variations and to manage them over the long term.
Risks of Unlinked RoPA Copies
A copy of an existing data processing activity can usually be created quickly. The existing entry is copied and adapted to local conditions in individual fields. This approach can become problematic as soon as the central description or another shared specification changes.
An unlinked copy generally does not contain reliable information about the master process on which it is based. If, for example, a central data category is changed, it must first be determined which local entries are affected by this change. The same applies when changing service providers, adjusting a retention period, making changes to technical and organizational measures, or revising a central process description.
If there are numerous similar copies, it may become unclear over time which entry reflects the group-wide standard and which entries merely contain local variations. This creates more than just a documentation problem; it particularly affects control, updating, reporting, and record-keeping.
Pursuant to Article 30 GDPR that must Record of Processing Activities including information on the purposes of the Processing, the categories of data subjects and personal data, the recipients, any transfers to third countries, the intended retention periods, and, to the extent possible, a general description of the technical and organizational measures. The record must be maintained in writing, although an electronic format is also permitted, and the competent Regulatory Authority to be made available upon request.
Against this backdrop, it is not only the completeness of the individual entries that is important, but also the structure of the directory. If multiple copies describe the same process in different ways, it can be difficult to provide management, data protection officers, or regulatory authorities with a clear and comprehensible overview of the actual current status.
The Concept of Sub-Processing in the RoPA
The term „sub-Processing“ is deliberately used in this article in an operational sense. It refers neither to subcontracting by another processor nor to a new legal category of GDPR.
A sub-Processing Rather, it refers to a subordinate variant of a master record processing operation within the list of processing activities.
Master data processing describes, in particular, the common core of the process:
- the overarching purpose,
- the main process,
- the groups of people who are regularly affected,
- Typical data categories,
- central systems,
- Default recipient,
- typical service providers,
- fundamental Technical and organizational measures,
- the default deletion logic,
- Key Risks,
- key responsibilities, as well as
- Required standard tests and approvals.
The Sub-Processing In contrast, it represents a controlled deviation from the common standard. It may refer in particular to:
- a local company,
- a location,
- a specific country,
- a department,
- an additional use case,
- a different service provider,
- an additional data category,
- a different local retention period,
- an additional recipient,
- a local process step,
- a different status,
- a local share, or
- a supplementary local measure.
Instead of multiple unconnected copies, this results in a master record to which the respective local or use-case-specific variants are clearly assigned.
Example: Applicant Management in a Corporate Group
In applicant tracking systems, the core process is similar across many companies. Applications are received, reviewed, coordinated with the relevant departments, documented, and deleted once the applicable deadlines have passed. This affects job applicants. The data typically processed includes contact information, details from resumes, proof of qualifications, interview notes, and communication data. A candidate management system, the human resources department, the relevant departments, and, if applicable, external service providers are regularly involved.
This common core can be documented in a master process. However, the specific implementation may vary from company to company.
For example, a German company may use the central applicant tracking system, while in France a local service provider is also involved. In the U.S., a different interview platform may be used. A company may retain certain documents for a longer period due to local labor law requirements. A business unit may collect additional portfolio documents. At one location, security clearances are conducted for certain roles. In one country, different Duty to inform, whereas another company also provides for a works council process.
These differences do not necessarily result in ten completely separate processing activities in every case. As long as the common core process remains viable, they can be managed as variants of the main processing activity. By classifying them as sub-processes, it remains clear which specifications apply across the entire group and where local deviations exist.
| Assessment Question | Unlinked copy | Master Data Processing with Sub-Processing |
|---|---|---|
| Common Process Core | This is described several times. | This is maintained once in master data processing. |
| Local deviation | This is often only visible within the copy. | It is explicitly documented as a variant. |
| Changes to the Standard | They must be updated individually in the affected copies. | They can be controlled centrally and checked for variations. |
| Local Responsibility | It is often unclear or is only included in free-text fields. | Can be assigned to a custom local role or an owner. |
| Reporting | Requires the subsequent consolidation of multiple entries. | Variants remain assigned to their respective base processes. |
| Auditability | The history and decisions are spread across several entries. | Deviations, inspections, and approvals remain linked to one another. |
| Deactivation and Archiving | Copies that are no longer in use often remain. | Variants can be specifically deactivated or archived. |
| Management Perspective | Displays numerous similar entries without a parent entry. | Shows a common process with controlled characteristics. |
Sub-processes are therefore not intended to reduce the required scope of documentation. They are intended to Documentation structure it in such a way that common standards and local characteristics remain manageable.
Inheritance and Local Maintenance of Fields
Not all details of a processing activity need to be maintained again in every local variant. For processes that are comparable across the group, it may make sense to transfer certain information from the master data processing. It should be possible to supplement, verify, or overwrite other details locally.
| Field Group | Typical Treatment | Justification |
|---|---|---|
| Process Name and Primary Purpose | Inherit centrally | Promotes a consistent structure and brand recognition. |
| Description of the Standard Process | Inherit centrally | Avoids having different versions of the same description. |
| Standard Data Categories | Inherit and supplement locally | Additional local data categories must remain identifiable. |
| Affected Groups | Inherit and supplement locally | The groups are often similar, but not necessarily completely identical. |
| Centralized System | Inherit centrally | Systems used company-wide do not need to be maintained multiple times. |
| Local Systems | Add locally | Any deviations from standard applications must be explicitly documented. |
| Standard Service Provider | Inherit centrally | Prevents the same service provider information from being entered multiple times. |
| Local Service Providers | Add locally | Can be used for Order processing, transfers to third countries, and risks may be relevant. |
| Legal basis | Partially import and check locally | Local circumstances may require a separate assessment. |
| Retention Periods | Inherit and configure to allow local overwriting | It must be possible to account for national or organizational differences. |
| Technical and Organizational Measures | Inherit and supplement locally | Central measures can be supplemented by local precautions. |
| Risks | Linking Central and Local Risks | A distinction must be made between group-wide and local risk situations. |
| Owner | Assign locally | Operational responsibility must be clearly defined for each option. |
| Approval | Locally or centrally, depending on the process | The approval status may vary between variants. |
| Status | Manage Locally | A variant can be active, scheduled, deactivated, or archived. |
| Review Date | Set locally or centrally | Responsibilities are determined by the risk profile and organizational model. |
The key is not to centrally inherit as many fields as possible. Rather, it is important to determine which data points actually constitute a binding standard and which require local review and control.
Requirements for Local Variants
Local variants should not be maintained as freely editable copies. Rather, a structure is required that makes it possible to trace the connection to the master data, the specific deviation, and the responsibility for it.
A sub-Processing should therefore at least make it clear that:
- which master record processing is used as the basis,
- which company, location, or department is affected,
- which fields differ from the group-wide standard,
- the reason why the deviation is necessary,
- whoever checked the discrepancy,
- who granted approval,
- what additional risks may arise as a result of the deviation,
- what local measures are planned,
- when a review should take place, and
- whether the variant is planned, under review, active, deactivated, or archived.
Without this information, there is a risk that this will simply result in yet another copy with a different name. Only through documented assignment, justification, and approval can a local deviation be transformed into a manageable governance object.
Use-Case-Specific Variations
Not every variant is tied to a specific country, company, or location. Differences may also arise due to a specific use case.
For example, a CRM process can serve as the standard for customer service. One business unit may also use the same process for an events program, while another unit uses it for communicating with partners. An additional data source may be used at a single location. A project team can enhance the existing process with analytical functions.
In such cases, it must be determined whether the activity still constitutes part of the existing core process or whether a separate processing activity should be documented. The key factors to consider are, in particular, the purpose, the data being processed, the recipients, the risk profile, and organizational responsibility.
It would therefore not be appropriate to automatically classify every deviation as a sub-Processing to classify it, nor to represent every specific feature with a completely new and unrelated copy. The key factor is whether the common process core remains viable and whether the deviation can be described, reviewed, and approved with sufficient precision.
Distinction from Independent Processing Activities
Sub-processing must not be used to obscure material differences between processing activities. An independent Processing may be considered, in particular, if:
- if the purpose differs significantly,
- other affected groups are included,
- additional categories of data that pose a higher risk are processed,
- another system or service provider significantly alters the risk situation,
- other recipients are included, or
- the local variant constitutes an independent process from an organizational standpoint.
If a standard HR system is used for applicant management, but a local company also uses it to conduct automated aptitude assessments with the help of AI, this may go beyond a minor deviation, depending on the specific setup. In such a case, this may constitute a separate processing activity or, at the very least, a clearly delineated sub-Processing may require a separate risk assessment and approval.
The key factor, therefore, is the technical distinction. Administrative simplification alone cannot be the sole determining factor in deciding whether a variant or an independent processing activity is involved.
Approval of Local Deviations
A local variant should not be transferred to operational status without a documented review. The required approval process does not necessarily have to be extensive, but it should define clear responsibilities and review steps.
A typical process may include the following steps:
- The local owner is applying for the exemption.
- The system indicates which fields differ from the default.
- The relevant data protection function assesses the relevance under data protection law.
- Where necessary, the Legal Department, IT Security, the Data Protection Officer, or other relevant departments will be involved.
- Identified risks and necessary measures are documented.
- The variant is approved, approved with conditions, or returned for revision.
- A status and a review date are assigned to the variant.
- The variance remains linked to the underlying master data processing.
This approach not only documents a change to the data record; it also ensures that the basis on which the deviation was reviewed and approved remains traceable.
Status Model for Sub-Processes
Sub-processes should have their own status. Without such a status model, it is not possible to reliably distinguish whether a variant is merely being prepared, has already been tested, is in operational use, or is no longer in use.
| Status | Meaning |
|---|---|
| Draft | The variant is being prepared and is not yet valid. |
| Under review | Data protection, Legal or other relevant roles will review the variance. |
| Returned | Information is missing, or the discrepancy is not sufficiently justified. |
| Approved | This variant is active and may be used. |
| Approved with Conditions | The variant is active, but is subject to certain requirements or deadlines. |
| In Review | The variant is being reevaluated. |
| Disabled | This variant is no longer used, but it remains traceable. |
| Archived | This variant is historically significant but is no longer in active use. |
| Deleted | The variant may be removed, provided there are no legal or technical requirements for documentation that would prevent this. |
A corporate RoPA can become difficult to navigate not only due to the ongoing addition of new entries. The same applies to variants that are no longer needed for operational purposes but whose status has not been updated. A transparent status model is therefore essential for the ongoing maintenance of the directory.
Deactivation, Archiving, and Deletion
Variants that are no longer relevant should not be permanently listed as active processing activities. An immediate Deletion However, this is not always appropriate either.
First, it must be determined whether the variant in question was actually used in operations. If it was never deployed, a Deletion may be considered, provided that there are neither legal obligations to provide evidence nor internal reasons for further Storage exist.
If, on the other hand, the variant was used in production, deactivation or archiving is generally the better option. This ensures that it remains clear that the variant existed, for how long it existed, when it was terminated, which data was affected, which retention periods must still be observed, and which decisions were made in connection with the Processing were made.
A review of the sub-Processing This is particularly relevant when:
- the company in question no longer uses the process,
- the system in use was shut down,
- a service provider was changed,
- the purpose no longer applies,
- the underlying use case has been completed,
- a previously local variation has been incorporated into the group-wide standard,
- the variant was replaced by a new variant, or
- An audit revealed that the structure was outdated.
Deactivation is therefore part of governance and not merely a measure to formally clean up the directory.
Reporting Requirements
For a group data protection officer or a central data protection function, a list of numerous, nearly identical processing activities is generally of limited value. Rather, what is required is an analysis that shows:
- which processes are standardized across the group,
- which companies or locations deviate from the standard,
- which deviations pose an increased risk,
- which variants have not yet been approved,
- for which variants local measures are overdue,
- which entries are outdated and
- which local variations, if any, should be incorporated into the Group-wide standard.
A report on applicant management should therefore not merely list several unrelated processing activities side by side. It should identify the master process, the active variants, the respective deviations, the risk and approval status, overdue reviews, open actions, expired variants, and companies without a current review.
This type of reporting requires that master data processing and variants be linked in a structured manner. Only then can the RoPA go beyond mere Documentation ...and can also be used as a management tool.
Relationship to Article 30 of the GDPR
Art. 30 GDPR requires data controllers to maintain a record of the processing activities under their control. Data processors must maintain a record of the categories of processing activities they carry out on behalf of a data controller. The respective record is the Regulatory Authority to be made available upon request.
The GDPR However, it does not prescribe any specific technical data model. In particular, Article 30 provides that GDPR This does not mean that every local variation must necessarily be recorded as a completely separate entry. Nor does the regulation require that similar processes be documented using unrelated copies.
It is crucial that the information that is actually relevant be accurate, traceable, and available. The EDPB describes the record as an inventory of processing operations that can be used to identify responsibilities and potential risks. The relevant information includes, among other things, the purpose, the categories of data, the recipients, any transfers, retention and deletion periods, and the security measures in place.
Sub-processing therefore does not replace the requirements set forth in Article 30 GDPR. Rather, they represent a possible organizational model for systematically mapping the necessary information within complex corporate structures.
Support from Ailance RoPA
Ailance RoPA It can map enterprise processes as interconnected master processes and local or use-case-specific variants. The central master process describes the common standard, while subordinate sub-processes capture the respective specifics.
Fields can be imported from master data processing, supplemented locally, or overwritten in a controlled manner. This ensures that any discrepancies remain visible. Responsibilities, approvals, actions, status information, and review dates can be assigned to the respective variant.
When it comes to control, three levels in particular must be distinguished from one another:
Standard
What information applies group-wide to the shared process?
Variant
What information applies differently to a specific company, location, or particular use case?
Proof
Who reviewed, approved, modified, re-evaluated, or deactivated the deviation?
This distinction is particularly relevant for larger organizations with numerous similar processes. Problems in the RoPA often arise not only from missing entries, but also from the lack of a clear structure among similar entries.
Example: Communication with Tenants
A real estate company conducts data processing activities related to tenant communications. The master data may include, in particular, the following information:
- Communication with tenants,
- Master data,
- Contact information,
- Contract reference,
- Handling of requests,
- Use of a centralized CRM system,
- a standard retention period,
- Default recipients and
- central Technical and organizational measures.
At the local level, there may be various variations on this model. One company also uses a local service center. At one location, a different communication tool is used. In one region, specific claims information is processed. One company contracts an external printing service provider, while another operates its own tenant app.
These specific features can be documented either as standalone processing activities or as clearly defined sub-processing activities. As long as the common core of the process remains in place, linking them to the main processing activity allows for a clearer presentation of the group-wide standard and the respective local deviations.
Example: Facility Processes
Because of their location-specific nature, facility processes are particularly prone to the creation of numerous similar entries. These include, for example, visitor registration, Physical Access Control, Video Surveillance, key management, parking lot management, cleaning coordination, and repair requests.
Many locations carry out these processes in a similar manner. However, the specific details can vary significantly from one location to another. At one location, Video Surveillance used at one location but not at another. Some locations use local service providers, process license plate numbers, maintain additional access logs, or use a special app. Other locations continue to use manual lists.
Sub-processes can help highlight these site-specific variations without breaking down the common facility process into numerous unrelated entries. This allows central management to identify which specifications are part of the standard process and at which sites deviations occur—and for what reasons.
Example: CRM
CRM processes are typically relevant across the entire organization. Master data processing can refer to the management of customers and prospects. Local variations can include, among other things, different marketing consents, local campaigns, additional data sources, specific recipients, varying deletion logic, or different ways of using the system.
In CRM processes in particular, unlinked copies pose the risk of conflicting information regarding purposes, recipients, Legal basis and retention periods. In contrast, a master process with associated sub-processes can clarify which information applies group-wide and which local or use-case-specific details have been reviewed and approved.
Review Questions for Existing Group RoPAs
To get a preliminary overview, you can select a process that occurs in multiple companies or at multiple locations. Examples include applicant management, CRM, tenant communication, facility management, supplier management, visitor registration, training administration, or IT support.
Next, the following questions, in particular, should be examined:
- Is there a clearly defined core process?
- What local or use-case-specific variants are there?
- Are the discrepancies explicitly documented, or are they merely contained in copies that are independent of one another?
- Who reviewed and approved the respective discrepancies?
- Which variants are no longer used in operations?
If these questions cannot be answered readily, this does not typically indicate that the number of processing activities is too low. Rather, there may be a lack of structure among the existing entries.
Conclusion
Sub-processes can serve as a suitable structural model for consolidated RoPAs when comparable processes are carried out across multiple companies, countries, or locations, even if they are not identical in every detail.
Unlinked copies can initially be created with little effort. However, as their number increases, they can lead to conflicting information, unclear responsibilities, difficulties in updating, and limited analyzability. In contrast, master data processing with assigned local or use-case-specific variants can reveal which data points form the common standard and where verified deviations exist.
Such a structure supports approval processes, reporting, reviews, and the deactivation and archiving of variants that are no longer needed. It is essential that every deviation can be assigned to a traceable process, a responsible party, and a documented status.
Questions and Answers
What are sub-processing operations in the record of processing activities?
Sub-processes are subordinate variants of a master process. They represent local or use-case-specific deviations from the common process core. The term does not refer to a separate category of the GDPR, but rather a possible structural model for corporate RoPAs.
Is "sub-processing" the same as "subcontracted processing"?
No. In this article, the term “sub-processing” does not refer to either a subprocessor or a subcontractor. The term refers to variations of a processing activity within a structured RoPA model.
Why can sub-processing be helpful for corporations?
Many processes are carried out in corporate groups in similar, though not entirely identical, ways. Sub-processes make it possible to combine a common core process with controlled local variations without having to create a separate copy for each variant.
When should sub-processing be used instead of a copy?
A sub-Processing This is an option if the common process core remains the same and only individual details differ based on local circumstances or specific use cases. This may apply, for example, to local service providers, additional data categories, different deadlines, local systems, or special approvals.
When is in-house processing better than outsourcing?
An independent Processing This may be necessary if, in particular, the purpose, the risk profile, the system used, the categories of data, the recipients, or organizational responsibility differ so significantly that the original core process is no longer viable.
Which fields should be transferred from master data processing?
Typically, the process name, primary purpose, standard description, central systems, standard data categories, standard service providers, and central Technical and organizational measures as well as the default deletion logic. Whether this is appropriate must be checked for each field group.
What information should be included in a local variant?
A local variant should, in particular, affected Company, location, or use case; the fields that differ; the reason for the deviation; the responsible persons; risks; measures; approvals; status information; and the scheduled review date.
How should local deviations be approved?
A local exception should be requested, technically reviewed, documented, and approved. Depending on the nature and risk of the exception, Data Protection, Legal, IT Security, the Data Protection Officer, or other relevant departments may need to be involved. The variant should remain associated with the underlying master process.
When should sub-processing be disabled?
Deactivation should be considered, in particular, if the local variant is no longer in use, its purpose has ceased to exist, a system has been shut down, a service provider has been changed, or the previous deviation has been incorporated into the group-wide standard.
Should sub-processes be deleted or archived?
If a variant has been used in production, archiving or deactivating it is generally a better option than immediately Deletion. This ensures that past decisions, retention periods, and other supporting documentation remain traceable. A Deletion This may be considered, in particular, if the variant was never put into production and there are no legal or technical reasons for retaining it.
How can Ailance RoPA support sub-processing?
Ailance RoPA can link master data processing, local variations, inherited fields, deviations, responsibilities, approvals, actions, status information, and reviews. This allows common standards and local specifics to be mapped in a structured manner within the Group RoPA.
What is the main advantage of subcontracting?
The key advantage lies in the clear link between the standard and the deviation. The RoPA thus not only shows several similar processes, but also indicates which variant deviates from the standard in which respects, the reason for the deviation, and who reviewed and approved it.
German 
English 
Italian 
French