Data protection and privacy. These two concepts are the difference between a company that respects its customers and one that ends up on the front page of the news for a data breach. For a CISA candidate, understanding how to evaluate controls that protect information and respect individual privacy rights is not just a box to tick — it is the heart of why auditing exists: to make sure organisations do not lose or misuse the data people trust them with.
Jump to a section
A simple way to picture Data Protection and Privacy
Have you ever given a spare key to your neighbour so they can water your plants while you are on holiday? That is a simple act of data protection and privacy management. Your house is your personal data. The front door lock is your security control. The neighbour is a third party you trust with limited access. You gave them a specific key that only opens the front door, not the safe in your bedroom or the filing cabinet with your passport. You also told them exactly when to come in and what to do. If you gave them a master key that opens every lock in your house, you would be risking your entire privacy for the sake of convenience. In the IT world, this is the difference between granting the minimum access needed (the least privilege principle) and giving away the keys to the kingdom. You might also decide to change the locks after the holiday (revoking access), or install a camera to log every time the door opens (audit logging). If the neighbour loses that spare key, you need a way to invalidate it without replacing every lock in the house (key rotation and revocation in encryption). Your data is like your home — it needs locks, visitor logs, and a clear plan for who gets which key and for how long.
Data protection and privacy are two sides of the same coin, but they are not the same thing. Data protection is about keeping information safe from loss, theft, or damage. It is the technical and administrative measures you put in place to stop a hacker from stealing customer credit card numbers or to prevent a server crash from wiping out years of patient records. Privacy, on the other hand, is about how you collect, use, and share personal information. It answers the question: are you handling someone's data in a way that respects their rights and follows the law? A company can protect a piece of data perfectly with strong encryption (scrambling it so no one can read it without the right key) but still violate privacy by sharing that data without permission.
To understand how this works in practice, you need to know a few core terms. The first is personally identifiable information (PII). This is any data that can identify a specific person on its own or when combined with other data: name, address, email, phone number, national insurance number, IP address, even a photograph. The second is sensitive personal information, which is a subset of PII that could cause serious harm if exposed: health records, financial account numbers, biometric data (like fingerprints), and political opinions. Third is a data subject: the person whose data is being collected. Fourth is a data controller: the organisation that decides why and how personal data is processed (for example, your bank decides it needs your income data to approve a loan). Fifth is a data processor: the third party that handles the data on behalf of the controller (for example, a cloud server company that stores the bank's customer records).
The main controls you need to evaluate fall into three categories:
Technical controls: these are the software and hardware tools. Encryption turns readable data into scrambled code that only someone with a decryption key can restore. Access controls limit who can see or edit data — they are like the bouncer at a club checking IDs. Firewalls block unwanted network traffic. Intrusion detection systems (IDS) monitor for suspicious activity. Data loss prevention (DLP) tools scan outgoing emails and files to stop sensitive information from leaving the organisation without authorisation.
Administrative controls: these are policies and procedures. A privacy policy tells employees what they can and cannot do with customer data. A data classification policy requires staff to label documents as 'public', 'internal', 'confidential', or 'restricted' so that handling rules are clear. Training programmes teach staff not to fall for phishing scams or leave laptops unlocked.
Physical controls: these protect the actual hardware. Locked server rooms, security guards, biometric scanners, CCTV cameras, and cable locks prevent someone from stealing the physical machine that holds the data.
A key principle you will see tested again and again is the 'data lifecycle'. Data is not static — it is born, lives, and dies. The lifecycle has six stages: collection (gathering the data), storage (keeping it on a server or device), use (processing it for a purpose), sharing (giving it to another party), archival (moving it to long-term storage), and destruction (deleting it permanently). At each stage, different controls apply. For example, during collection you need consent from the data subject. During storage you need encryption. During destruction you need to wipe it so it cannot be recovered — simply deleting a file from your desktop does not remove it from the hard drive; you need specialised software to overwrite the data.
Why does this all exist? Historically, companies stored data on paper in filing cabinets. If someone stole the cabinet, they had the data. Then computers came along, and the problem of scale exploded. A single database can hold the personal information of millions of people. The economic incentive for cybercriminals to steal that data is enormous — they can sell credit card numbers on the dark web or use stolen identities for fraud. At the same time, governments around the world passed privacy laws to protect citizens. The most famous is the General Data Protection Regulation (GDPR) in Europe, which gives individuals the right to know what data is held about them and to request its deletion (the 'right to be forgotten'). In the US, the California Consumer Privacy Act (CCPA) gives similar rights. An auditor needs to check that an organisation complies with all the laws that apply to the data it holds.
What does it replace? In the past, security was often an afterthought — a company would build a product and then try to add security later. Modern best practice is called 'privacy by design': you build privacy and protection into the system from the start. Similarly, old approaches relied on a 'moat and castle' model: a hardened perimeter around the network with everything inside treated as trusted. That failed because once an attacker got inside, they had free rein. Modern approaches use 'zero trust architecture': never trust, always verify. Every user, even one inside the office network, must authenticate and be authorised for every access request.
Identify and Classify Data
The first step is to find out what personal data the organisation holds and label it by sensitivity. An auditor reviews the data inventory and interviews data owners to ensure classification labels (e.g., confidential, internal) are applied. This matters because you cannot protect what you do not know exists.
Map the Data Flow
You trace where data enters the organisation, where it is stored, who touches it, where it goes, and when it is deleted. This creates a data flow diagram. An auditor uses this to identify risky handoffs, unauthorised storage locations, and data sent to third parties without proper agreements.
Evaluate Access Controls
You check who has permission to view, edit, or delete the data. The auditor verifies that access is granted based on role and need, that no orphan accounts exist (e.g., departed employees still in the system), and that reviews happen regularly. This is where the principle of least privilege is tested.
Review Encryption and Key Management
You inspect whether data is encrypted at rest (while stored on disk) and in transit (while moving over a network). Critically, you also evaluate how encryption keys are stored and rotated. The auditor looks for weak practices like storing keys in the same database as the data or never rotating them.
Check Privacy Compliance
You verify that the organisation has published a privacy policy, obtained proper consent, can respond to data subject requests (e.g., right to access or deletion), and has data processing agreements with all third-party vendors. The auditor tests a sample of consent records and request responses to ensure the process works in practice.
Test Incident Response and Breach Notification
You simulate a data breach scenario to see if the organisation can detect it, contain it, and notify affected individuals and regulators within legal timeframes. Many privacy laws require notification within 72 hours. The auditor reviews past incident logs and the incident response plan to ensure it is up to date and tested.
Imagine you are the IT auditor for a mid-sized online retailer called ShopEasy that sells clothing and accessories. The company collects customer names, home addresses, email addresses, phone numbers, and credit card details. The chief information officer (CIO) asks you to evaluate the data protection and privacy controls before the company expands into the European market and needs to comply with GDPR.
You start your audit by reviewing the data inventory. You ask the database administrator to show you where customer data resides. You discover that credit card numbers are stored in the same database table as customer names, rather than being separated and encrypted with a dedicated payment card industry (PCI) compliant tokenisation system. You flag this immediately — credit card data should never be stored in full after the transaction is completed; it should be replaced with a token (a random string of characters that links to the card data held by a secure third-party payment processor). This is a finding you will write up in your report.
Next, you interview the head of marketing. You discover that the marketing team has been exporting customer email lists to a personal laptop to run email campaigns using a free online tool. The team says they did not realise this was a problem because they 'only used it for work'. You explain that transferring customer PII to an unapproved device and unapproved third-party service without a data processing agreement violates both privacy law and the company's own acceptable use policy. You recommend implementing a Data Loss Prevention (DLP) tool that automatically blocks emails containing customer email addresses from being sent to unauthorised external domains. You also recommend that the procurement team ensure every third-party vendor signs a data processing agreement (DPA) that specifies how they will protect the data.
You then check the access controls. You ask the IT manager for a list of all employees who have access to the customer database. The list shows 47 people, including three interns from last summer who have since left the company. You identify that there is no automated process to revoke access when an employee leaves. The access review is done once a year manually. You recommend implementing a user access review process that runs monthly, and integrating the human resources system with the identity management system so that when an employee status changes to 'terminated', their access is automatically removed within 24 hours.
Finally, you test the encryption controls. You ask for the encryption key management policy. The IT manager tells you that the same encryption key has been used for the customer database for five years and is stored in a text file on a shared network drive accessible to the entire IT team. This is a serious control weakness. You recommend rotating the encryption key every 90 days and storing keys in a hardware security module (HSM) — a dedicated physical device that manages and protects keys — or a cloud key management service (KMS) that automatically rotates keys and logs every access attempt.
At the end of the audit, you present your findings to the board. You grade each finding by severity: critical (e.g., storing full credit card numbers), high (e.g., terminated employees still having access), medium (e.g., lack of DLP tools), and low (e.g., privacy policy being too long for customers to read). For each finding, you give a specific recommendation and a timeframe for remediation.
The CISA exam tests 'Data Protection and Privacy' under Domain 5 (Protection of Information Assets). You can expect about 10-15% of the total exam questions to come from this area. The examiners love to test your understanding of the difference between data protection and privacy, the various roles in data governance, and which controls apply to which stage of the data lifecycle.
The exam topics you absolutely must know cold are:
The data lifecycle stages: collect, store, use, share, archive, destroy. You may be given a scenario and asked which control is appropriate for a specific stage (e.g., 'At which stage of the data lifecycle is an organisation most likely to implement data masking?').
The definitions of data controller, data processor, data subject, and data custodian. You will see questions where the answer depends on identifying who is responsible for compliance.
Privacy by design and privacy by default. The exam expects you to know that these are core requirements of GDPR and that the auditor should check if they are implemented at the start of a project, not added later.
Encryption types: symmetric (same key for encrypt and decrypt) versus asymmetric (public and private key pair). You need to know which is faster (symmetric) and which is more secure for key exchange (asymmetric).
The principle of least privilege and need-to-know. Questions will describe an employee who has access to data they do not need for their job role; the correct audit finding is that the principle of least privilege is violated.
Data classification schemes. You need to know the typical levels (public, internal, confidential, restricted) and what controls apply to each level (e.g., confidential data must be encrypted both at rest and in transit).
Data retention requirements. The exam tests that you cannot keep data forever — there must be a retention schedule based on legal, regulatory, and business needs. Destroying data too early is as bad as keeping it too long.
Key management practices. The exam loves to test that keys should be stored separately from the data they encrypt, that keys should be rotated regularly, and that a hardware security module (HSM) is the gold standard.
The traps the examiners set include:
Confusing 'confidentiality' with 'privacy'. Confidentiality is about preventing unauthorised access (a technical control). Privacy is about how you use data lawfully. A question may describe a privacy violation (e.g., sharing customer data without consent) and offer confidentiality controls (e.g., encryption) as distractor answers.
Assuming that if data is encrypted, it is private. Encryption protects the data from being read by an unauthorised party, but if you share the encrypted data with a third party who has the key, that party can still misuse it. The exam will test that you need both encryption (protection) and a data processing agreement (privacy).
Using the term 'data owner' when the question really means 'data controller'. The data owner is the person in the organisation who makes classification decisions; the data controller is the legal entity that determines processing purposes.
Overlooking the importance of data masking (also called data obfuscation) in non-production environments. A common scenario: a developer uses a copy of the production database containing real PII to test a new feature. The correct control is to mask or anonymise the data before giving it to developers.
Forgetting that privacy laws have extraterritorial reach. A question may describe a small company in Australia that sells to EU customers; the correct answer is that GDPR applies because the company processes data of EU residents.
Data protection is about securing information from unauthorised access or loss, while privacy is about how information is lawfully collected, used, and shared.
The data lifecycle has six stages — collect, store, use, share, archive, destroy — and each stage requires different controls.
The data controller decides why and how data is processed; the data processor handles data on behalf of the controller; both are legally accountable under privacy laws.
Encryption protects confidentiality but does not solve privacy — you need separate controls like consent management and data processing agreements.
Privacy by design means building controls into systems from the start, not retrofitting them after a breach.
The principle of least privilege ensures users have only the minimum access needed for their role, and it is a cornerstone of both protection and privacy.
Data retention policies must balance business need with legal requirements — keeping data forever is a compliance risk, not a safety net.
Anonymised data is not personal data; pseudonymised data still is and remains subject to privacy law.
These come up on the exam all the time. Here's how to tell them apart.
Encryption
Transforms data using an algorithm and a key; reversible with the key.
The original data format and length are not preserved.
If the key is stolen, all data can be decrypted.
Tokenisation
Replaces sensitive data with a random, unique identifier (token) that maps to the original data stored elsewhere.
The token preserves the original data format (e.g., 16-digit number for a credit card).
Breaching the token alone does not reveal the original data; the mapping table must also be breached.
Data Controller
Determines the purpose and means of processing personal data.
Has primary legal liability for compliance with privacy laws.
Must obtain consent, respond to data subject requests, and conduct data protection impact assessments.
Data Processor
Processes data only on behalf of and under the instruction of the controller.
Has limited legal liability but must still implement appropriate security measures.
Cannot use the data for its own purposes or share it without the controller's authorisation.
Symmetric Encryption
Uses a single key for both encryption and decryption.
Faster and suitable for encrypting large volumes of data.
The key must be shared securely between parties, which creates a distribution challenge.
Asymmetric Encryption
Uses a public key for encryption and a private key for decryption.
Slower and typically used for key exchange or digital signatures.
The public key can be shared openly; the private key is kept secret by its owner.
Anonymisation
Irreversibly removes all identifiers so no individual can be re-identified.
Output is not considered personal data and falls outside most privacy regulations.
Techniques include aggregation, hashing with no lookup table, and generalisation.
Pseudonymisation
Replaces direct identifiers with artificial labels (e.g., patient ID), but the original identity can be re-linked using a separate key.
Output is still personal data and remains subject to privacy law.
Reduces risk but does not eliminate compliance obligations; the key must be protected separately.
Mistake
If data is encrypted, I have fulfilled both data protection and privacy requirements.
Correct
Encryption protects data from being read by unauthorised parties, but it does not prevent the organisation from misusing the data. Privacy controls (like consent management, purpose limitation, and data processing agreements) are separate and needed on top of encryption.
Beginners see encryption as a magic solution and forget that privacy laws regulate how data can be used and shared, not just whether it is secure from theft.
Mistake
Once a customer provides their data, the company owns that data and can use it however it wants.
Correct
The customer (data subject) retains ownership of their personal data. The company (data controller) is only a custodian with a legal obligation to use it only for the specific purpose it was collected and to respect the individual's rights (e.g., right to access, right to deletion).
This misconception stems from a lack of familiarity with privacy law concepts. In everyday life, if you give something to someone, you often lose control of it. Privacy law inverts that assumption.
Mistake
Data protection is just an IT problem, so the IT department owns it entirely.
Correct
Data protection and privacy are cross-functional responsibilities. The IT department implements the technical controls, but legal defines the privacy policies, HR manages employee training, and senior management is ultimately accountable. The auditor evaluates all of these areas, not just IT.
Many beginners come from technical backgrounds and naturally think of security as an IT issue. But privacy regulations place legal liability on the entire organisation, not just the IT team.
Mistake
If a company has a privacy policy on its website, that is all it needs to do for compliance.
Correct
A privacy policy is just the starting point. Compliance requires that the policy is accurately implemented in practice: consent must be obtained and recorded, data must be processed only as stated, access controls must be enforced, retention schedules must be followed, and data subject requests must be responded to within legal timeframes.
People confuse the act of writing a policy with the act of operationalising it. Auditors are trained to verify that policies are actually followed, not just that they exist.
Mistake
Anonymised data is the same as pseudonymised data, so the same rules apply.
Correct
Anonymised data has been irreversibly stripped of all identifiers so that no individual can be identified. It is generally not considered personal data and falls outside most privacy laws. Pseudonymised data replaces identifiers with artificial labels (e.g., User123), but the original identity can still be re-linked using a separate key. Pseudonymised data remains personal data and is still subject to privacy regulations.
The terms sound similar and both involve removing direct names, but the key difference is reversibility. The exam tests that you know the difference between the two and that pseudonymisation does not remove legal obligations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The data controller decides the purpose and means of processing personal data (e.g., a bank decides to collect income data for loan approvals). The data processor acts on the controller's instructions (e.g., a cloud provider stores the bank's data). The controller has primary legal responsibility, but the processor also has direct obligations under most privacy laws.
No. GDPR requires a comprehensive set of privacy controls including lawful basis for processing, consent management, data subject rights, breach notification procedures, and data protection impact assessments. Encryption is one technical control but does not address privacy obligations.
The right to be forgotten (formally called the right to erasure) allows an individual to request that an organisation delete their personal data without undue delay. The organisation must comply unless there is a legal obligation to keep the data (e.g., tax records). An auditor checks that the deletion process is documented, timely, and covers all copies including backups.
No. Encryption keys should be rotated periodically (commonly every 90 days or annually) to limit the damage if a key is stolen. Using the same key for years violates good key management practices and would be flagged as a control weakness by an auditor.
Data masking (also called data obfuscation) replaces sensitive data with realistic but fake values. For example, a developer testing a new feature uses a database where all real credit card numbers are replaced with '4111-1111-1111-1111'. It is used in non-production environments (development, testing) to protect PII while preserving functionality.
Yes. GDPR has extraterritorial reach: it applies to any organisation anywhere in the world that processes the personal data of individuals in the EU, regardless of where the organisation is based. An auditor must consider whether a company handles data of EU residents even if the company is in a different region.
You've finished Data Protection and Privacy. Continue through the CISA study guide to build a complete picture of the exam.
Done with this chapter?