Source folder: SOPs
Source file: SOP – GDPR Training & Data Verification - AU.pdf
File type: PDF document
Back to folder index
SOP - GDPR Training & Data Verification
Purpose
To ensure all EasyDNA staff understand and comply with the General Data Protection
Regulation (GDPR), including proper handling of personal, sensitive, and highly
sensitive data, and verification procedures for existing clients.
- Overview of GDPR
The General Data Protection Regulation (GDPR) protects the privacy rights of
individuals and regulates how organisations collect, use, and store personal data.
GDPR is based on six core principles that must be followed at all times:
- Lawfulness, Fairness, and Transparency - Processing must be legal, fair,
and clear to the individual.
- Purpose Limitation - Data collected must only be used for the stated
purpose.
- Data Minimisation - Only collect what is necessary.
- Accuracy - Keep data accurate and up to date.
- Storage Limitation - Do not keep data longer than necessary.
- Integrity and Confidentiality - Protect data against unauthorised access,
loss, or destruction.
All EasyDNA staff share responsibility for protecting client data under these
principles.
- Data Classifications
Personal Data
Any information that identifies or can identify a person, directly or indirectly.
Examples:
- Name, address, phone number, email
- Order number linked to a client
- Case reference number
- Payment details
Sensitive Personal Data
Data revealing an individual's personal attributes or beliefs.
Examples:
- Race or ethnicity
- Religion or political opinion
- Health information
- Biometric data
- Sexual orientation
Highly Sensitive Data
Information requiring the highest level of protection due to potential harm or
discrimination if exposed.
Examples:
- Genetic data (DNA results, raw files)
- Criminal conviction data
- Identity documents (passport, ID card)
- Prenatal or post-mortem relationship data
All genetic and relationship analyses handled by EasyDNA or Endeavor DNA are
classified as Highly Sensitive Data.
- Data Processing and Legal Basis
Data processing includes any operation performed on personal data, such as
collection, storage, use, sharing, or deletion.
Processing must have at least one legal basis under Article 6 of GDPR
Legal Basis Example in EasyDNA Context
Consent Client ticks consent box when
submitting samples
Contract Processing necessary to perform DNA
analysis
Legal Obligation Compliance with immigration or court
orders
Vital Interests Rare cases involving medical
emergencies
Legitimate Interests Internal fraud prevention or quality
control
Note: In employment or client-service relationships, "consent" is rarely valid due to
power imbalance; rely instead on contractual or legal obligations.
Purpose
To protect client data and prevent unauthorised access or disclosure.
Procedure
- Confirm Caller Identity:
- Ask for the case reference number, full name, and email address
used on the order.
- Cross-check with ATP or CRM.
- Check Security Information:
- Confirm date of birth, address, or test type.
- Do not disclose results or sensitive information until verification is
complete.
- If Caller Fails Verification:
- Politely refuse to share data.
- Advise: "For data protection reasons, we cannot share this information
until verification is complete. Please email us from the address
registered to your case."
- Record Verification in Notes:
- Add ATP note: "Client verified under GDPR check - confirmed DOB +
CR."
- Handling Subject Access Requests (SARs)
Types of Requests
- Access Request - Client requests a copy of all personal data held.
- Use EN - GDPR_REC_4.2 (RECORD) form.
- Deletion Request ("Right to be Forgotten") - Client requests deletion of
their data.
- Use EN - GDPR_REC_1.1 (DELETE) form.
Procedure
- Verify the identity of the requester.
- Record the request using the appropriate form.
- Forward to the Data Protection Officer (DPO) for processing.
- Data must be provided or deleted within 30 days unless extended under
Article 12(3) GDPR.
- Confirm completion to the client in writing.
¶ 6. Data Retention and Deletion
- Retain client data only for as long as necessary for testing, result delivery,
and legal compliance.
- Once retention limits are reached, data must be securely deleted from all
systems (ATP, email, shared drives, and lab archives).
- For sensitive and highly sensitive data, ensure the laboratory also confirms
deletion.
Retention examples:
Data Type Typical Retention Period
Case records 2 years post-analysis
Legal/Immigration cases 7 years
Employee records 5 years after employment ends
CCTV/Call recordings 30-90 days
- Data Breaches
A data breach occurs when personal data is accessed, disclosed, or lost
unintentionally or unlawfully.
Immediate Steps
- Notify the DPO within 24 hours.
- Record incident details (who, what, when, where, how).
- The DPO assesses if notification to the supervisory authority (e.g., ICO, OAIC)
is required within 72 hours.
- Affected individuals must be informed if the breach is high-risk.
- Data Protection Impact Assessments (DPIA)
A DPIA is required when processing activities are likely to result in high risk to
individuals' rights (e.g., genetic or health-related processing).
It should describe the purpose, assess the necessity, and outline risk mitigation
steps.
Key triggers for DPIA:
- Use of new technology (AI, automation)
- Large-scale processing of sensitive data
- Monitoring public or online behaviour
¶ 9. Roles and Responsibilities
Role Responsibility
All Staff Follow GDPR principles; ensure secure
handling of all personal and sensitive
data.
Customer Service / CSR Perform verification before disclosing or
updating client data.
DPO Oversee compliance, handle SARs,
advise on breaches and DPIAs.
Managers Ensure staff complete GDPR training
and implement policy updates.
10. Reference Documents and Links
- EasyDNA Terms of Service & Data Protection Policy:
https://easydna.com.au/terms-of-service/
- EN - GDPR_REC_1.1 - Subject Access Request (Delete)
- EN - GDPR_REC_4.2 - Subject Access Request (Record)
- DPO Course Notes (Sessions 1-3)
- EU GDPR (Regulation (EU) 2016/679)
- Review and Training
- All employees must complete GDPR training annually.
- Refresher sessions to be logged in HR training records.
- This SOP is reviewed by the DPO every 12 months or upon significant policy
changes.
- Addendum - Verification When Client Refuses to Provide ID
Purpose
Provide a consistent, auditable process to verify a requester's identity for SARs
(access/erasure) when they refuse to share photo ID, aligned to our verification
checks and SAR handling.
Scope
All Subject Access Requests where ID is refused but verification is still required due
to the nature of our data (highly sensitive genetic data).
Legal context (summary)
- Under Article 12(6) UK GDPR, where there is a reasonable doubt about
identity, we may request additional information before processing. Timelines
run once "what we need" is received, per our SAR procedure.
A. Code-Based Verification (Approved Alternative to Photo ID)
When to use
- The requester refuses to provide ID but will complete our form and accept a
one-time verification code.
- We have a reliable contact point already on file (registered email and, if
available, a phone number). This complements existing verification checks for
existing clients.
Procedure
- Generate a One-Time Code
- Create an 8-10-character alphanumeric code.
- ATP note: "GDPR alt-ID verification code generated."
- Send the Code
- Send via email the case to the registered email address on file
(never to a new or unverified address).
- Include this instruction:
"Please write the code below in the 'Verification Code' box on the
attached Data Subject [Deletion/Access] Form, sign the form, and
reply from the same email address."
- Optional Call-Back (if number on file)
- If a phone number is on file, place a brief call and ask the client to
read back the code they received by email. Do not disclose
personal data until verification is complete. Log the call per verification
checks.
- Client Returns Form
- Client prints and signs EN - GDPR_REC_1.1 (DELETE) or EN -
GDPR_REC_4.2 (RECORD), writes the code in the "Verification Code"
box, and replies from the registered email.
- Verify & Log
- Confirm: code matches, form is signed, reply came from the registered
email.
- ATP note example:
"GDPR alt-ID verified via one-time code. Code: [xxxx-xxxx], matched on signed
form. Email matches the file. Proceeding with [DELETION/ACCESS]."
- Forward to the DPO and complete within the SAR timeline set in the
SOP (30 days unless extended under Article 12(3)); confirm
completion in writing.
Edge cases
- Email-only (no mobile or landline only): Proceed with email code +
signed form (steps 2, 4, 5); the call step is optional.
- Guardianship claims: If the requester claims to be a legal guardian, ensure
the case already evidences guardianship or obtain the required proof per
existing procedures before proceeding to erasure/access. If missing, escalate
to DPO.
- Signals of impersonation or inconsistency: Pause and escalate to DPO
under Article 12(6) proportionality assessment.
Data minimisation & retention
- Retain the signed SAR form containing the code in the SAR record per our
retention rules; delete any transient drafts once processed and follow the
existing deletion controls for highly sensitive data (ATP, email, shared drives,
lab archives).
B. Escalation (When Code-Based Verification Fails or Is Refused)
If the requester refuses the code method or material doubt remains after checks:
- Pause processing, note "reasonable doubt" under Article 12(6).
- Escalate to the DPO for a proportionality assessment and next steps.
- Update the client: timelines resume once sufficient verification is received, in
line with our SAR procedure.
C. Standard Wording (Email Snippets)
Offer - Code Method
Thank you for your request. As an alternative to photo ID, we can verify identity
with a one-time security code. We will email you a unique code. Please write this
code on the attached Data Subject [Deletion/Access] Form, sign it, and reply from
the same registered email address. Once verified, we will proceed within the
standard timeframe.
Refusal of Code Method
We understand your position. Because we process highly sensitive genetic data, we
must verify the requester's identity to prevent unauthorised deletion or disclosure. If
you do not wish to use the code method, we will refer your request to our Data
Protection Officer for assessment under Article 12(6) UK GDPR and will update you
on the next steps.
D. Records & Audit Trail
- Mandatory ATP entries: code generation, dispatch, match outcome, route
used (code), and any DPO escalation.
- SAR file must include: the signed SAR form showing the verification code and
the final completion email.
- Apply existing Retention & Deletion controls.
Owner: DPO, EasyDNA Group
Effective date: October 2025
Next review: Per Section 11 review cycle.