# Data processor

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/data-processor

## Quick definition

A data processor is anyone who handles personal data for someone else. They follow the instructions of the data controller, who decides why and how the data is used. Processors can be cloud service providers, payroll companies, or email marketing platforms. They do not own the data or decide what to do with it.

## Simple meaning

Think of a data processor like an external catering company hired to cook a meal for a big party. The person throwing the party is the data controller. They decide the menu, the number of guests, and the dietary restrictions. The catering company is the data processor. They receive the ingredients (the data) and follow the party host's instructions exactly. They cannot decide to add extra dishes or change the menu without asking. They handle the food carefully, store it properly, and at the end of the party, they either return the leftovers or dispose of them according to the host's directions. If a guest gets sick from the food, the host is still responsible to the guests, but the host will turn to the catering company for answers. In the IT world, a data processor might be a cloud storage provider like AWS or Azure. When a bank (the controller) stores customer transaction records in AWS, AWS is the processor. AWS holds the data, ensures its security, and follows the bank's instructions about who can access it and how long to keep it. But AWS cannot use that data for its own purposes, like analyzing customer behavior for its own marketing. The bank remains responsible for complying with data protection laws, but the processor must also follow the law and have a written contract that spells out their duties. The key point is control: the controller decides, the processor executes.

## Technical definition

In information security and privacy law, a data processor is any entity that processes personal data on behalf of a data controller. The term originates from the European Union's General Data Protection Regulation (GDPR) but is now used globally in privacy frameworks including the California Consumer Privacy Act (CCPA) and Brazil's LGPD. The legal relationship is defined by Article 28 of the GDPR, which requires a binding contract or other legal act that sets out the subject matter and duration of processing, the nature and purpose of processing, the type of personal data, categories of data subjects, and the obligations and rights of the controller. 

The data processor must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including pseudonymization, encryption, confidentiality, integrity, availability, and resilience of processing systems. They must also ensure that any person authorized to process personal data commits to confidentiality. The processor cannot engage another processor (a sub-processor) without prior specific or general written authorization from the controller. If general authorization is given, the processor must inform the controller of any intended changes concerning the addition or replacement of sub-processors, giving the controller the opportunity to object. 

Real IT implementation means that cloud service providers, software-as-a-service platforms, and managed service providers all act as processors for their customers. For example, a company using Salesforce to manage its sales contacts is the controller, and Salesforce is the processor. The contract must specify how long Salesforce retains the data, what security controls are in place (encryption at rest and in transit, access controls, logging), and how they handle data breach notifications. The processor must assist the controller in fulfilling its obligations to respond to data subject access requests, and must delete or return all personal data at the end of the service. 

Standards such as ISO 27001 and SOC 2 Type II are commonly used to demonstrate that a processor has adequate security controls. For the CISSP exam, understanding the distinction between controller and processor is critical in the domain of Risk and Asset Security, specifically in the context of data ownership, third-party governance, and privacy compliance. The processor is not the data owner; the controller is the data owner or data steward. The CISSP candidate must know that the processor has legal obligations independent of the controller, such as mandatory breach notification to the controller. Failure to comply can result in fines both for the controller and the processor, and in some jurisdictions, third-party beneficiaries can sue the processor directly.

## Real-life example

Imagine you are organizing a large charity run. You decide to use an online registration platform, RaceRocket, to collect runners' names, emails, emergency contacts, and t-shirt sizes. You are the data controller because you decided what information to collect and why you need it. RaceRocket is the data processor. They provide the technology and store all that data on their servers. They cannot decide to use the runner emails to promote their own t-shirt sales. They cannot share the emergency contact data with a third-party insurance company without your permission. When the race is over, you ask RaceRocket to delete all personal data, and they must comply. If a hacker breaks into RaceRocket and steals the data, RaceRocket must notify you immediately so you can inform the runners. You, as the controller, are still responsible to the runners, but RaceRocket faces legal consequences for the security failure. In this real-world scenario, the relationship is governed by a Data Processing Agreement (DPA). The DPA specifies that RaceRocket will only process data in the European Economic Area, that they will use encryption, that they will allow audits, and that they will not subcontract any part of the processing to a company in a country with weak privacy laws without your written consent. This analogy maps directly to corporate IT: the marketing department uses a cloud email platform as a processor, the HR department uses a payroll processor, and the IT department uses a backup service as a processor. The core message is that the processor is a trusted helper, not the decision-maker.

## Why it matters

In practical IT, the data processor definition matters because nearly every organization relies on third-party services to handle personal data. From cloud infrastructure to customer support chatbots to analytics tools, these vendors are data processors. Without a clear understanding of the processor's role, organizations risk violating privacy laws and facing massive fines. For example, under GDPR, fines can reach up to 4% of annual global turnover or 20 million euros, whichever is higher, for both controllers and processors that fail to meet their obligations. 

IT professionals need to know that selecting a vendor is not just about cost and features. The organization must vet the processor's security posture, review their audit certifications (like SOC 2), and ensure a proper DPA is signed. This is part of third-party risk management. The processor also has direct legal obligations, such as reporting data breaches to the controller without undue delay. Practitioners should understand that if a processor experiences a breach and fails to notify the controller, both parties can be penalized. 

the processor can be held liable for damages caused by processing that infringes the GDPR. This means that processors must appoint a data protection officer (DPO) in certain cases, maintain records of processing activities, and conduct data protection impact assessments when required. In day-to-day operations, an IT administrator might need to configure access controls in a cloud platform to ensure that only authorized personnel of the processor can touch the customer data. This is often enforced through role-based access control (RBAC). The rise of cloud computing means that the line between controller and processor can blur, especially in complex supply chains where a processor itself uses sub-processors. Understanding this hierarchy is essential for compliance and for passing exams like the CISSP.

## Why it matters in exams

For the CISSP exam, the data processor concept is critical in Domain 2 (Asset Security) and Domain 7 (Security Operations), but it also appears in Domain 1 (Security and Risk Management) under legal and regulatory compliance. The exam expects candidates to distinguish clearly between the data owner, data steward, data custodian, data controller, and data processor. The controller is the person who decides the purpose and means of processing. The processor is the person who processes data on behalf of the controller. This distinction is tested in scenario questions where the candidate must identify who is responsible for a breach or who must fulfill a data subject access request. 

Questions often present a scenario where a company outsources payroll to a third-party service. The third-party service is the processor. The candidate must know that the processor must have a written contract, must implement appropriate security measures, and must assist the controller in meeting its obligations. Another common question type involves a data breach at the processor. The candidate must determine that the processor must notify the controller, and the controller then notifies the supervisory authority and the affected data subjects. The processor does not notify the authorities directly unless specified by law. 

The exam also tests knowledge of sub-processors. If a processor uses another company to host data, that is a sub-processor, and the controller must authorize it. Candidates must understand that the controller remains ultimately responsible for all processing, including sub-processor activities. For the CISSP, this aligns with the concept of due diligence and third-party governance. In Domain 7 (Security Operations), the candidate must know that the processor is responsible for operational security of the processing environment, including access controls, logging, monitoring, and incident response. The exam may ask about agreements like the Data Processing Agreement (DPA) and how it differs from a Service Level Agreement (SLA). The DPA covers privacy obligations, while the SLA covers uptime and performance. The candidate who confuses these two will likely get the question wrong. Mastering the processor concept also helps with questions on data classification and data handling requirements, because the processor must handle data according to the classification level determined by the controller.

## How it appears in exam questions

CISSP exam questions about data processors typically take one of three forms: scenario-based role identification, compliance obligations, and incident response. 

Scenario-based role identification: The question presents a narrative. For example, a hospital contracts with a cloud storage provider to store patient medical records. The hospital determines that records must be retained for seven years and then destroyed. The cloud provider encrypts the data and limits access to authorized hospital staff. Who is the data controller? The hospital. Who is the data processor? The cloud provider. A typical question might then ask: Who is legally responsible if a patient requests deletion of their record? The answer is the controller (the hospital), but the controller can delegate the technical deletion to the processor. The candidate must not choose the processor as the primary responsible party. 

Compliance obligations: A question might ask: A data processor has experienced a data breach. Which of the following is the processor's first obligation? The correct answer is to notify the controller without undue delay. Some candidates might mistakenly think the processor must notify the regulatory authority directly. The CISSP emphasizes that the notification chain requires the controller to be informed first. Another question could ask: What document is required between a controller and a processor under GDPR? The answer is a Data Processing Agreement (DPA). A distractor might be a Memorandum of Understanding or an SLA. 

Incident response: A scenario where a processor's employee accidentally emails a spreadsheet of personal data to the wrong recipient. The question asks who is responsible for conducting the data protection impact assessment (DPIA) or for implementing the corrective measures. The candidate must understand that the processor is obliged to assist the controller with DPIAs, but the controller is the one who commissions it. Also, the processor must have an incident response plan that includes communication with the controller. Another twist: a processor uses a sub-processor without the controller's authorization. The question might ask: What is the consequence? The processor may be held fully liable for the unauthorized processing. 

Candidates should also be prepared for questions that mix up the terms. They might see 'data custodian' and 'data processor' used interchangeably, but the CISSP distinguishes the data custodian as a person within the organization who handles data according to the data owner's policies, while the data processor is an external third party. Understanding these nuances can make the difference between a correct and an incorrect answer.

## Example scenario

Prepare for a scenario in the CISSP exam: You are the Chief Information Security Officer of a mid-sized e-commerce company that sells handmade furniture. Your company uses a third-party email marketing platform, MailBlast, to send promotional emails to customers. The platform stores customer names, email addresses, and purchase history. One day, a MailBlast employee accidentally deploys a misconfigured database that exposes this data to the public internet for four hours before it is discovered and fixed. 

Applying the data processor concept: Your e-commerce company is the data controller because you decided what data to collect (name, email, purchase history) and why (marketing). MailBlast is the data processor because they process that data on your behalf, following your instructions on when to send emails and to whom. As the processor, MailBlast is legally required to have a Data Processing Agreement (DPA) in place with your company. That DPA must include a clause requiring MailBlast to notify your company of any data breach without undue delay. In this scenario, MailBlast must inform your company immediately. Your company, as the controller, then has 72 hours to notify the relevant data protection authority (like the ICO or CNIL) and must also inform affected customers if the breach is likely to result in a high risk to their rights and freedoms. 

A typical exam question based on this scenario might ask: After the breach, who is responsible for conducting a Data Protection Impact Assessment (DPIA)? The correct answer is the controller (your company), but the processor (MailBlast) must assist. Another question: If a customer sues for damages, who is primarily liable? The controller is primarily liable, but the processor can also be held liable if it failed to comply with its specific obligations, such as not having adequate security measures. The candidate must also know that the processor cannot be held liable if it can prove that it is not in any way responsible for the event giving rise to the damage. This scenario underscores the importance of not only understanding definitions but also the legal interplay between the two roles.

## Common mistakes

- **Mistake:** Thinking the data processor is the same as the data owner.
  - Why it is wrong: The data owner is the person within the organization who has ultimate accountability for data, often a senior executive. The data processor is an external third party that handles data on behalf of the owner/controller. The processor does not own the data.
  - Fix: Remember: the processor is a hired hand, not the boss of the data.
- **Mistake:** Believing the data processor can use the data for its own business analysis or marketing.
  - Why it is wrong: Under GDPR and other privacy laws, a processor may only process data according to the controller's documented instructions. Unless the controller explicitly allows an exception, any use of the data for the processor's own benefit is a violation.
  - Fix: Assume the processor can only touch the data for the specific purpose stated in the contract. No side projects.
- **Mistake:** Assuming a data processor does not need to have a written contract with the controller.
  - Why it is wrong: GDPR and many other regulations require a legally binding contract or other legal act that governs the processing. Without it, the processing is unlawful.
  - Fix: Always check for a Data Processing Agreement (DPA) before engaging a vendor that will handle personal data.
- **Mistake:** Confusing the data processor with a joint controller.
  - Why it is wrong: A joint controller is an entity that jointly determines the purposes and means of processing with another controller. A data processor only acts on the instructions of the controller and does not make decisions about why data is processed.
  - Fix: If two companies decide together that data will be used for a shared purpose, they are joint controllers. If one tells the other what to do, the second is a processor.
- **Mistake:** Thinking that a data processor has no liability for a data breach.
  - Why it is wrong: Processors have direct statutory obligations under GDPR, and they can be fined up to 4% of annual turnover or 10 million euros, whichever is higher. They can also be sued by data subjects for damages.
  - Fix: Processors are not safe from legal consequences. They must implement strong security and comply with all obligations in the contract and law.

## Exam trap

{"trap":"A question asks: 'Who is responsible for notifying the data protection authority after a breach at a processor?' and gives options including 'the processor', 'the controller', and 'both'. The trap is that some candidates think the processor notifies the authority because they experienced the breach.","why_learners_choose_it":"Learners focus on the immediate event: the processor discovered the breach, so they assume the processor handles all notifications. They forget the legal chain of responsibility under GDPR.","how_to_avoid_it":"Memorize the notification chain: Processor notifies controller without undue delay. Controller notifies supervisory authority within 72 hours. Processor does not notify the authority directly unless the controller delegates that task or the contract specifies it. The default rule is that the controller is the primary communicator with regulators."}

## Commonly confused with

- **Data processor vs Data controller:** The data controller determines the purpose and means of processing personal data. The data processor only acts on the controller's instructions. The controller decides the 'why' and the 'how' in broad terms, while the processor executes. A single entity can be both controller and processor for different data sets. (Example: A hospital (controller) hires a cloud storage company (processor) to store patient records. The hospital decides the records are kept for 10 years; the cloud company just stores them.)
- **Data processor vs Joint controller:** Joint controllers share the decision-making about why and how data is processed. They are both responsible for compliance. A processor never shares decision-making authority; they only follow orders. If two companies run a loyalty program together, they are joint controllers. If one company runs it and hires a software vendor to manage it, the vendor is a processor. (Example: An airline and a hotel chain jointly create a shared customer loyalty program. Both decide what data to collect and how to use it. That makes them joint controllers. The IT company that builds the program's app is a processor.)
- **Data processor vs Data custodian:** A data custodian is an internal role within an organization that is responsible for the technical storage, handling, and protection of data. A data processor is usually an external third party. While a custodian might be an IT administrator inside the company, a processor is a separate legal entity. The custodian follows the data owner's policies; the processor follows the controller's instructions via contract. (Example: An IT manager at a bank is the data custodian of the bank's customer database. The bank's cloud backup provider is a data processor.)

## Step-by-step breakdown

1. **Identify the data controller** — The controller is the person or organization that decides the purpose and means of processing personal data. This is usually the company that collects data from its customers or employees. Without a controller, there cannot be a processor. The controller is legally responsible for the entire processing activity.
2. **Engage a data processor via a contract** — The controller must enter into a written contract with the processor. This contract, often called a Data Processing Agreement (DPA), must specify the duration, nature, and purpose of processing, the types of personal data, categories of data subjects, and the obligations and rights of the controller. The contract is a legal requirement under most privacy laws.
3. **Processor implements security measures** — The processor must implement appropriate technical and organizational measures to protect the data. This includes encryption, access controls, logging, and incident response plans. The level of security must be appropriate to the risk of the processing. The processor may also have certifications like ISO 27001 or SOC 2 to demonstrate compliance.
4. **Processor follows controller's instructions** — The processor must only process personal data on documented instructions from the controller. This includes instructions on storage, deletion, and any transfers. The processor cannot repurpose the data for its own benefit. If the controller asks for something illegal, the processor must refuse and inform the controller.
5. **Processor assists controller with data subject rights** — When a data subject exercises their rights (access, rectification, erasure, portability), the controller must respond. The processor must assist the controller in fulfilling these requests by providing the necessary data or tools. The contract should specify the time frame and method for assistance.
6. **Processor notifies controller of breaches** — If the processor experiences a personal data breach, it must notify the controller without undue delay. The controller then decides whether to notify the supervisory authority and affected individuals. The processor must provide the controller with all relevant information about the breach to help with the notification.
7. **End of processing and data return or deletion** — When the service ends, the processor must either return all personal data to the controller or delete it, unless the law requires continued storage. The contract must specify this process. The processor must also delete existing copies unless the controller requests otherwise. This step ensures data does not remain in the processor's systems indefinitely.

## Practical mini-lesson

In practice, the concept of the data processor is not just a legal label but a fundamental component of third-party risk management. Every time an organization signs up for a SaaS product, uses a cloud infrastructure provider, or outsources a business function that involves personal data, it must determine whether that vendor is a processor. If the vendor processes data only on your behalf and does not use that data for its own independent purposes, then it is a processor. If the vendor also uses the data for its own analytics or to improve its service, the line can blur, and the vendor may become a joint controller or even a separate controller. 

Professionals need to know that the due diligence process for selecting a processor should include reviewing the vendor's data protection policies, security certifications, and incident response capabilities. The contract must include a DPA that covers all required elements. IT teams must operationalize the processor relationship by configuring systems to limit data access. For example, if a processor is a cloud storage provider, the IT team must set access controls so that only specific people at the processor can access the data, and that access is logged. This is often done through Identity and Access Management (IAM) policies. 

What can go wrong? A common pitfall is when a processor uses sub-processors without the controller's knowledge. For example, a backup service might store data on a third-party cloud, which is a sub-processor. If the contract does not authorize this, and the sub-processor suffers a breach, the original processor is in violation. Another issue is when the processor fails to delete data after the contract ends. This can happen due to backup retention policies. The controller must ensure the contract specifies deletion requirements, including from backups. An audit of the processor's data deletion practices is a good idea. 

From a technical perspective, data processors often use data centers with redundancy and disaster recovery. The IT professional must verify that the processor's security controls are adequate for the data classification. For example, if the data includes payment card information, the processor must be PCI-DSS compliant. If it's health data, HIPAA compliance is required. The processor's role is also key in incident response: the controller's incident response plan should include procedures for communication with the processor. Having a clear understanding of the data flow between controller and processor helps in creating accurate data flow diagrams, which are required for data protection impact assessments (DPIAs). The data processor relationship is about trust, contracts, and technical controls. Mastering this concept helps in both career advancement and exam success.

## Memory tip

Remember: Controller calls the shots, Processor pushes the buttons.

## FAQ

**Is a cloud service provider like Amazon Web Services always a data processor?**

Yes, when a customer stores data in AWS and AWS only provides the infrastructure, it is a data processor. However, if AWS also processes the data for its own purposes (like using customer logs to improve services), it may act as a separate controller for that processing.

**Can a data processor be held liable under GDPR?**

Yes. A processor can be fined up to 4% of annual global turnover or 10 million euros, whichever is higher, for violating its direct obligations under GDPR, such as failing to implement appropriate security or using a sub-processor without authorization.

**What is a Data Processing Agreement (DPA)?**

A DPA is a legally binding contract between a data controller and a data processor that outlines the terms of data processing, including security measures, data retention, breach notification, and sub-processor use. It is required under GDPR Article 28.

**Do I need a DPA for every vendor that touches personal data?**

Yes, if the vendor is a data processor and processes personal data on your behalf. For example, a cloud storage provider, an email marketing platform, or a payroll service. If the vendor is a separate controller (e.g., a social media platform), you do not need a DPA, but you may need other agreements.

**What happens if a data processor uses a sub-processor without my permission?**

The processor is in violation of GDPR Article 28. The controller can object, and if the processor continues, the controller may have the right to terminate the contract. The processor remains fully liable for any damages caused by the unauthorized sub-processor.

**Can a small business be a data processor?**

Yes, any organization that processes personal data on behalf of another organization can be a processor, regardless of size. A small bookkeeping firm that handles a client's employee payroll data is a data processor. The same obligations apply.

## Summary

The term 'data processor' is a foundational concept in privacy and information security, especially within the frameworks of GDPR, CCPA, and other global regulations. A data processor is an entity that processes personal data on behalf of a data controller, strictly following the controller's instructions. Unlike the controller, the processor does not determine the purpose or the broad means of processing. Instead, the processor is a hired executor, bound by a written contract that specifies all details of the processing arrangement, including security measures, sub-processing restrictions, and data breach notification procedures.

For IT professionals, especially those preparing for the CISSP exam, understanding the distinction between controller and processor is critical. It affects how you manage third-party risk, how you draft contracts, and how you respond to incidents. The processor has direct legal obligations and can face substantial fines for non-compliance. In exam scenarios, you will need to identify which entity is the processor, who must notify whom after a breach, and who is responsible for data subject requests. Mistaking the processor for the controller, or assuming the processor has no liability, are common errors that can cost you points.

The real-world importance of the processor role continues to grow as organizations outsource more data processing to the cloud. Every security professional must know how to evaluate, contract with, and monitor data processors. This knowledge not only helps you pass the exam but also equips you to protect your organization from regulatory penalties and reputational damage. The takeaway is: controller decides, processor does, and both are accountable.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/data-processor