Data Handling & Privacy

Not All Data Is Created Equal

Every day, you handle different types of data. Some of it — if exposed — would be embarrassing. Some would be devastating.

Understanding the difference is the foundation of data protection.

The Data Classification Pyramid

Public Data

• Marketing materials
• Press releases
• Public website content

Internal Data

• Company policies
• Internal announcements
• Non-sensitive business documents

Confidential Data

• Financial reports
• Employee records
• Business strategies
• Customer contracts

Restricted/Sensitive Data

• Customer personal data (PII)
• Payment card information
• Health records
• Login credentials
• Encryption keys

Why Classification Matters

Scenario: You're sending a report to a colleague.

If it's internal data → Email is fine

If it's confidential → Consider secure file sharing

If it contains customer PII → Requires encryption, audit trail, and legitimate business need

The handling requirements change based on classification. Get it wrong, and you could trigger a data breach.

Real Example: British Airways (2018)

Attackers modified the BA website to skim customer payment details. Over 380,000 transactions were compromised.

ICO Fine: £20 million (reduced from £183 million due to COVID impact)

What went wrong:

• Payment card data (restricted) wasn't properly isolated
• Insufficient monitoring for data access
• Delayed breach detection

Lesson: Restricted data requires the highest security controls — and constant vigilance.

Personal Data Under GDPR

If you handle EU/UK customer data, you're handling regulated data.

What Counts as Personal Data?

Obviously personal:

• Name
• Email address
• Phone number
• Home address
• Date of birth
• National Insurance number

Also personal (often forgotten):

• IP addresses
• Device IDs
• Location data
• Cookie identifiers
• Photographs
• CCTV footage
• Employee ID numbers

Special category (extra restrictions):

• Health information
• Religious beliefs
• Political opinions
• Biometric data
• Sexual orientation
• Trade union membership

The Key Principles

1. Lawful basis — You need a legal reason to process data

2. Purpose limitation — Only use data for the stated purpose

3. Data minimisation — Only collect what you actually need

4. Accuracy — Keep data up to date and correct

5. Storage limitation — Don't keep data longer than necessary

6. Security — Protect data appropriately

What This Means Day-to-Day

✓ Ask why — Do you actually need that data field?

✓ Check purpose — Are you using data for the reason it was collected?

✓ Limit access — Only those who need it should have it

✓ Question requests — "Why do you need this customer's data?"

The Email Problem

Email is convenient. Email is also:

• Unencrypted in transit (often)
• Permanently stored on multiple servers
• Easily forwarded to wrong recipients
• Impossible to recall once sent

The #1 cause of data breaches in the UK? Emails sent to the wrong person.

Real Example: NHS Scotland (2023)

An NHS employee accidentally CC'd instead of BCC'd an email containing patient information.

Result: 500+ patients' sensitive health data exposed to other patients.

Cost: ICO investigation, reputational damage, patient distress.

Fix: Would have taken 3 seconds to check the recipient field.

Safe Ways to Share Sensitive Data

Method 1: Secure File Sharing Links

Instead of attaching files, use your company's approved file sharing system:

• SharePoint
• OneDrive for Business
• Google Drive (business account)
• Approved secure transfer tools

Benefits:

• ✓ Access can be revoked
• ✓ Links can expire
• ✓ Activity is logged
• ✓ Password protection available
• ✓ Recipient verification possible

Method 2: Encrypted Email

If you must use email:

• Use your company's email encryption feature
• Some email systems automatically encrypt when you mark as "Confidential"
• Check with IT how encryption works in your organisation

Method 3: Secure Portals

For regular data exchanges with partners:

• Use established secure portals
• SFTP for technical transfers
• API integrations for automated flows

What NOT to Do

❌ Email attachments with personal data — Unless encrypted

❌ WhatsApp/personal messaging — No audit trail, no company control

❌ USB drives — Easy to lose, hard to track

❌ Personal cloud storage — Dropbox personal, Google personal

❌ Printing and posting — Last resort only, use secure mail

Before You Share: The Checklist

1. Do they need it? Does the recipient have a legitimate business need for this data?

2. Is it minimised? Can you remove columns, redact information, or limit the scope?

3. Is the method appropriate? Does the sensitivity match the sharing method?

4. Is the recipient verified? Are you 100% certain you have the right email address?

5. What happens next? Will they store it securely? Delete it when done?

Real Example: The CC vs BCC Disaster

An HR team sends an email about salary reviews.

What they did: CC'd 200 employees What they meant to do: BCC'd 200 employees

Result: Every employee could see everyone else's email address and infer who was getting a salary review.

Prevention:

• Always double-check CC vs BCC
• For bulk sensitive emails, use mail merge or HR systems
• Consider: "What if everyone on this list saw everyone else?"

Data Minimisation in Practice

Scenario: Marketing asks for a customer list to analyse purchasing patterns.

Bad approach: Export entire customer database with all fields.

Good approach:

1. Ask what specific data points they need
2. Remove unnecessary columns (names, addresses if not needed)
3. Consider anonymisation (customer ID instead of name)
4. Limit date range to what's relevant
5. Use aggregated data if possible

The principle: Start with "no" and work toward the minimum necessary — not start with "everything" and hope for the best.

Your Rights, Their Rights

Under GDPR, individuals have significant rights over their personal data. When someone exercises these rights, your organisation has one month to respond.

The Main Rights

Right to Access (Subject Access Request / SAR) "Show me all the data you hold about me."

Right to Rectification "This data is wrong — please correct it."

Right to Erasure ("Right to be Forgotten") "Delete my data."

Right to Restrict Processing "Stop using my data for X purpose."

Right to Data Portability "Give me my data in a format I can take elsewhere."

Right to Object "Stop processing my data for marketing."

When Someone Makes a Request

Step 1: Recognise It

A data subject request doesn't have to be formal. These all count:

✓ "Can you tell me what data you have about me?"

✓ "Please delete my account and all my information"

✓ "Stop sending me marketing emails"

✓ "I want a copy of my records"

Even if they don't use legal terms, it's still a valid request.

Step 2: Don't Ignore It

❌ "I'm too busy, I'll deal with it later" — Clock is ticking

❌ "That's not my job" — Everyone's job to escalate

❌ "They're just being difficult" — Legal right, legal obligation

Step 3: Escalate Immediately

Forward the request to:

1. Your Data Protection Officer (DPO)
2. Privacy/Compliance team
3. Your manager

Include:

• When the request was received
• What exactly they asked for
• Their contact details
• Any context about their relationship with the company

Step 4: Don't Process Data While Pending

Once a deletion or restriction request is received:

• Don't use that person's data
• Don't share it externally
• Don't include it in campaigns
• Wait for the compliance team's guidance

What You Might Be Asked to Do

Search for data: "Check your emails, files, and systems for any data relating to [Name]"

Preserve data: "Don't delete anything relating to this person until further notice"

Verify identity: "Can you confirm this is the same person we have on record?"

Explain processing: "What do you use this customer's data for?"

The One-Month Deadline

The clock starts: When the request is received (even if it's in your inbox over the weekend)

Can be extended: Up to 3 months for complex requests, but must notify the person within the first month

Failure to comply: ICO can investigate and fine

Real Example: Google Spain (The "Right to be Forgotten" Case)

A Spanish man requested Google remove search results linking to old newspaper articles about his debt repayments (which were now resolved).

The ruling: European Court of Justice ruled in his favour. Search engines must consider removal requests for outdated, irrelevant information.

Why it matters: This established that individuals have genuine power over their data, even when it's technically accurate information.

Quick Reference: What to Do

The Bottom Line

1. Recognise — Any request about personal data could be a DSR
2. Don't delay — One month deadline starts immediately
3. Escalate — This is not your decision to make
4. Cooperate — Help the compliance team find the data
5. Document — Keep records of what you did and when