Data privacy and legal frameworks (GDPR, HIPAA, NDPR)
In one sentence: data privacy is a person's right to control who sees and uses their personal information, and laws such as the GDPR (General Data Protection Regulation, Europe), HIPAA (Health Insurance Portability and Accountability Act, United States) and the NDPR (Nigeria Data Protection Regulation) turn that right into rules that IT systems must be designed to follow, using both technical and organisational measures.
Your medical file at a private hospital in Port Harcourt. You hand it over so the doctor can treat you. You would be upset if the hospital sold your file to a drug company for adverts, kept it unlocked at reception, or kept your details for 30 years after you moved away. Privacy law says: use the data only for the reason it was collected, take only what you need, keep it safe, keep it accurate, delete it when you no longer need it, and be able to prove you did all of that.
Part A: What data privacy is and why it matters
The course reading defines data privacy as "the protection of personal data from those who should not have access to it and the ability of individuals to determine who can access their personal information." So privacy has two halves: protection (keeping data away from the wrong people) and control (letting the person decide who sees, uses or shares it).
It builds and keeps trust. Strong privacy practices prevent misuse such as identity theft, fraud and discrimination, and show ethical behaviour towards stakeholders.
Big data, AI (Artificial Intelligence) and cross-border data flows. Nearly 79% of the world's population is now covered by some form of privacy law (GDPR, NDPR, and US state laws like the CCPA, California Consumer Privacy Act).
Personal data is any information that identifies a living person directly or indirectly: name, phone number, NIN (National Identification Number), BVN (Bank Verification Number), address, location, photos, health records. Sensitive data (health, biometrics, religion, political views) needs extra care because misuse causes bigger harm.
Two roles you must know: controller and processor
| Role | Plain meaning | Example |
|---|---|---|
| Data controller | Decides why and how personal data is processed | A bank in Lagos decides to collect customers' BVNs for account opening |
| Data processor | Handles data on behalf of the controller, following its instructions | The cloud company that stores the bank's customer database |
| Data subject | The living person the data is about | The customer |
Controller = Chooses. Processor = Performs. The controller is still responsible even when a processor does the work, which is why contracts with vendors matter (Part F).
Part B: The three laws compared (GDPR, HIPAA, NDPR)
| GDPR (European Union) | HIPAA (United States) | NDPR (Nigeria) | |
|---|---|---|---|
| Year | 2018 | 1996 | 2019 |
| Who it covers | Any organisation processing personal data of EU residents, even outside the EU if it targets or monitors them (extraterritorial) | US healthcare providers, health plans, healthcare clearinghouses and their business associates. Not outside the US, not non-health data | Data processed in Nigeria, and data of Nigerian citizens wherever they live |
| Main focus | All personal data, broad principles and strong rights | Confidentiality, integrity and security of health information | Citizens' data and the digital economy; modelled on the GDPR |
| Rights | The most comprehensive: access, rectification, erasure, restriction, portability, objection | Limited to health data: mainly access, correction and an accounting of disclosures | Similar to GDPR: access, rectification, erasure, portability, objection |
| Key duties | Privacy by design and default; DPIAs (Data Protection Impact Assessments) for high-risk processing; DPOs; 72-hour breach report | Three rules: Privacy Rule, Security Rule (administrative, technical and physical safeguards for electronic health records), Breach Notification Rule | Appoint DPOs, publish a data protection policy, submit audit reports; 72-hour breach report |
| Penalties | Up to €20 million or 4% of global annual turnover, whichever is higher | Up to $50,000 per violation, capped at $1.5 million per year, plus possible criminal penalties | For controllers handling data of more than 10,000 people: ₦10 million or 2% of annual gross revenue, whichever is greater (smaller controllers: ₦2 million or 1%) |
HIPAA is not a global law. If a question describes a Nigerian hospital or a European clinic, HIPAA does not apply. HIPAA also does not stress data minimisation as strongly as the GDPR and NDPR. And the GDPR reaches companies outside Europe: a Nigerian app that targets users in Germany must comply.
The readings use the NDPR (2019). In 2023 Nigeria passed the NDPA (Nigeria Data Protection Act 2023), which set up the NDPC (Nigeria Data Protection Commission) as the regulator. The slides mention the NDPA alongside the GDPR and HIPAA, and the readings note that the NDPC is short of staff and funding. Earlier the agency in charge was NITDA (National Information Technology Development Agency). In a case study answer, name the NDPR as the course does and add that the NDPA 2023 now sits above it.
One fine detail differs between readings: Reading 1A gives the NDPR fine as "₦10 million or 2%", while Reading 1C says "₦10 million or 1%" for controllers with over 10,000 subjects. The regulation's wording is the version in the table (2% for the larger group, 1% for the smaller). If a CA question gives only one of these figures among the options, pick the one offered.
Part C: The seven principles of data protection
Every lawful system follows these principles. The slides pair each principle with what it means for an IT system, which is exactly how CA questions are written.
| Principle | Plain meaning | What the IT system must do (from the slides) |
|---|---|---|
| Lawfulness, fairness and transparency | Have a valid legal reason, be fair, and tell people clearly | Log the legal basis for each processing activity; show clear privacy notices |
| Purpose limitation | Collect for specified, explicit, legitimate purposes; don't reuse for something incompatible | Tag data with purpose flags; block unauthorised reuse |
| Data minimisation | Collect only what is strictly necessary | Forms with only the necessary mandatory fields; auto-delete excess data |
| Accuracy | Keep data correct and current; fix errors quickly | Edit and audit workflows; user portals where people update their own details |
| Storage limitation | Keep data only as long as needed | Automated deletion schedules and archive rules |
| Integrity and confidentiality | Protect data from breaches, leaks and damage | Encryption, access controls, regular penetration testing (authorised simulated attacks) |
| Accountability | Demonstrate compliance proactively | Audit trails, documentation tools and DPIA frameworks |
A loan app collects your BVN to verify you (purpose), then uses it to sell insurance: purpose limitation broken. A school form asks for parents' salaries and church name to enrol a child: data minimisation broken. An employer keeps CVs of rejected applicants for ten years: storage limitation broken. A hospital that cannot show who viewed a patient's record: accountability broken.
"Little People Make Awesome Shiny Imported Accessories": Lawfulness, Purpose, Minimisation, Accuracy, Storage, Integrity, Accountability.
Part D: Technical measures (things the technology does)
Privacy by Design means embedding privacy into the system architecture from the very start (inception), being proactive (prevent breaches) rather than reactive (fix things after a breach). Examples: default data minimisation in form design and automated retention enforcement. Privacy by Default means the system automatically applies the most private settings without the user having to do anything. Both are legally required under GDPR Article 25.
Proactive, not reactive (prevent rather than respond); end-to-end security (protect data from collection to deletion); user-centric (give users control and transparency); minimal data by default. Example: a social app that asks only for email and password at sign-up, sets profiles to private by default and offers easy consent options.
Anonymisation removes identifiers irreversibly: nobody can link the data back to the person. Pseudonymisation replaces identifiers with artificial markers (for example, patient "Ada Okafor" becomes "P-10293"); with the key, it can be reversed. Both reduce re-identification risk. Pseudonymised data is still personal data under the law.
| Technical measure | What it does |
|---|---|
| Encryption | Scrambles data so only key holders can read it. At rest (in storage): AES-256 (Advanced Encryption Standard, 256-bit key). In transit (moving over a network): TLS 1.3 (Transport Layer Security). Use end-to-end encryption for sensitive messages and rotate keys regularly |
| Access controls | Role-based permissions plus MFA (Multi-Factor Authentication: password plus a code or fingerprint) |
| DLP (Data Loss Prevention) | Monitors and blocks unauthorised data transfers, such as an employee emailing a customer list to a personal Gmail |
| PETs (Privacy-Enhancing Technologies) | Tools that let you use data without exposing people: differential privacy in analytics (adds statistical noise), homomorphic encryption (compute on data while it stays encrypted), federated learning (train AI without moving raw data) |
| Secure storage and deletion | Encrypted databases; cryptographic erasure (destroy the key so the data becomes unreadable) when data is no longer needed |
In the slides' own mid-lesson question, the answer to "Which of the following is a Privacy-Enhancing Technology (PET)?" was Encryption, not DLP, firewall or data mining, because encryption makes data unreadable to unauthorised people and directly protects confidentiality. Data mining is the opposite of privacy-enhancing.
Implementation checklist from the slides: run DPIAs for new systems; use pseudonymised data in test environments (never real customer data); automate access revocation when staff change roles; schedule cryptographic wiping of decommissioned storage.
Part E: Organisational measures (things people and policies do)
1. Data protection policy: documents the lawful basis and the rules for handling data. 2. PIA (Privacy Impact Assessment) / DPIA process: mandatory for high-risk processing; covers data flows and third-party sharing risks. 3. Breach notification procedure: the GDPR's 72-hour reporting window plus an internal escalation path. 4. Retention policy: maximum storage time per data type, with automated deletion triggers.
DPO (Data Protection Officer): required for public bodies and large-scale monitoring; reports directly to senior management. Accountability framework: board-level responsibility and an annual compliance sign-off. Training: role-specific modules (HR vs IT), phishing simulations, quarterly refreshers on password hygiene and secure file sharing.
Annual privacy audits (sample-check policies, verify third-party processor contracts); data flow mapping (see every collection and sharing point, spot unauthorised transfers); automated alerts for unusual access patterns and overdue deletions; centralised logging for investigations.
An independent adviser: monitors processing, trains staff, liaises with regulators during audits. To build a privacy culture: clear breach-reporting channels, regular impact assessments for new projects, and pushing privacy-aware design in IT procurement.
Technical = encryption, anonymisation, pseudonymisation, access controls, DLP, firewalls. Organisational = PIA/DPIA, policies, breach procedure, retention policy, DPO, training, audits. The slides ask this directly: PIA is organisational; anonymisation is technical.
Part F: Implementing compliance in IT systems (Reading 1B)
1. Data mapping and inventory, the foundation
Data mapping shows how personal data moves through the organisation (collection → processing → storage → sharing). A data inventory is the record of data types, purposes, locations, retention periods and who has access. It supports GDPR Article 30 (Records of Processing Activities), spots excessive collection, and makes it possible to answer DSARs (Data Subject Access Requests). Key activities: identify all sources (websites, CRM (Customer Relationship Management) systems, HR systems); categorise data (PII, Personally Identifiable Information, vs sensitive); map flows including third parties; document the legal justification (consent, contract).
2. Access controls and data minimisation
Access by job function. HR staff see employment records but not payroll.
Access by characteristics such as department, location or data sensitivity. "Only Abuja-branch staff, during working hours, for non-sensitive records."
Best practices: enforce MFA for sensitive data, review access rights regularly as roles change, collect only what is needed and delete it when done, and anonymise or pseudonymise where possible. Apply least privilege: give each person the minimum access they need.
3. Incident response and breach notification
A breach notice should describe the breach, the data involved, the actions taken and advice for affected people. Under the CCPA and other US state laws timelines vary by state.
4. Encryption, secure storage and secure transmission
Disk and database encryption; least-privilege access; reputable cloud providers with certifications such as ISO 27001 (International Organization for Standardization standard for information security).
HTTPS/TLS for websites; SFTP (SSH File Transfer Protocol) or FTPS (File Transfer Protocol Secure) for files; VPNs (Virtual Private Networks) for remote access.
5. Vendor and third-party risk management
Vendors who process data for you create risk. Keep an inventory of vendors and their data access; assess their security with frameworks like SOC 2 (System and Organization Controls 2) or ISO 27001; put privacy and security obligations in contracts; monitor them through regular reviews and audits.
Part G: Challenges, strategy and operations
| Challenge (slides) | Why it hurts |
|---|---|
| Legacy systems | Old systems often lack encryption and proper access controls, so adapting them to GDPR/NDPR is hard |
| Data silos | Systems that are not integrated make consistent policies hard; data may be shared wrongly or kept for different, excessive periods |
| Resource gaps | Too few privacy specialists and too little money for tools |
| Regulatory complexity | Overlapping laws (GDPR plus sector rules) and frequent updates need adaptable processes |
| Evolving tech | Cloud, AI and IoT (Internet of Things) bring new collection risks |
Risk-based approach: start where a breach would hurt most (customer databases) and spread resources by risk level. Documentation: records of all processing and breach responses. Privacy culture: train staff to spot phishing and handle files securely.
Regulatory monitoring: a team tracks changes to GDPR, NDPA and HIPAA. Cross-team collaboration: legal and IT review vendor contracts and run PIAs together. Tech upgrades: replace outdated systems with modular ones, with safe data migration.
Part H: When privacy fails: ethics, consequences and trends (Reading 1C)
Psychological harm (anxiety; a leaked address can endanger a domestic-violence survivor or whistleblower); identity theft and fraud; loss of autonomy (stigma, discrimination when health or political data leaks); societal impact (people stop trusting digital services, which slows innovation).
Proactive safeguards (technical controls and training); transparency (explain how data is collected, used and protected); swift breach response (contain, notify, fix).
Loss of customer trust; investors and partners pull back; negative publicity; lower employee morale and higher turnover.
Incident containment → root cause analysis → transparent communication (notify individuals and regulators, support victims) → policy and technical upgrades (better controls, revised policies, retraining).
| Trend (Readings 1A and 1C) | Meaning |
|---|---|
| Harmonisation / regulatory expansion | Countries align laws for smoother cross-border flows, but a growing "patchwork" (India's DPDPA, Brazil's LGPD, US state laws) demands flexible compliance |
| Accountability and enforcement escalation | More documentation and risk assessments; bigger fines and scrutiny |
| Data subject empowerment | A surge in requests for access, correction and deletion |
| PETs and technological integration | Privacy by design, homomorphic encryption, federated learning |
| AI and privacy | Consent, bias and misuse concerns; the EU AI Act responds |
| Zero-trust security | Verify every access attempt continuously instead of trusting anyone inside the network perimeter |
| Data sovereignty | Countries require data to be stored and processed within their borders |
| Trust as a competitive edge | Privacy is now seen as crucial for business success |
Recommendations for sustained compliance: adopt privacy by design; use centralised compliance platforms (automate consent management, subject requests and reporting to cut human error); invest in PETs; enhance transparency; implement zero trust; manage third-party risk; train employees.
Summary
- Data privacy = protection plus control. GDPR (EU, 2018, extraterritorial, €20m/4%), HIPAA (US health, 1996, $50k per violation, $1.5m a year), NDPR (Nigeria, 2019, citizens anywhere; NDPA 2023 and the NDPC now above it).
- Seven principles: lawfulness/fairness/transparency, purpose limitation, minimisation, accuracy, storage limitation, integrity/confidentiality, accountability.
- Technical measures: privacy by design and default (GDPR Art. 25), anonymisation vs pseudonymisation, AES-256 at rest, TLS 1.3 in transit, RBAC/ABAC, MFA, DLP, PETs, cryptographic erasure.
- Organisational measures: policies, DPIA/PIA, 72-hour breach procedure, retention policy, DPO reporting to senior management, training, audits, data flow mapping.
- Incident response: preparation → detection and containment → eradication and recovery → post-incident review.
- Challenges: legacy systems, silos, resources, regulatory complexity, evolving tech. Answer: risk-based, documented, privacy culture, cross-team work.