Privacy FAQ
Every answer below is visible on this page — nothing is hidden behind a form. These are evergreen explanations of how privacy obligations are usually approached in practice, not legal advice and not news.
Showing 38 of 38 questions
No. The GDPR is scope-based, not threshold-based. A two-person company that processes personal data in the EU/EEA context is in scope; size affects some documentation duties, not applicability.
No. Consent is one of six lawful bases. Contract, legal obligation, vital interests, public task and legitimate interests are equally valid where they genuinely fit the purpose.
Not by itself. If people outside the EU/EEA can access the data — including administrators and support staff — that access is a transfer and needs a mechanism.
It is structurally very similar but not identical. Exemptions, transfer instruments, regulator guidance and the applicable fine currency differ, and an organisation can be subject to both regimes simultaneously.
Consent for non-essential cookies comes from PECR; the UK GDPR then governs any personal data processed as a result.
There is no comprehensive federal statute of general application. Sector laws cover specific data types, and general consumer privacy duties come from state law.
It can. Several states define sale and share broadly enough to capture disclosures to advertising partners for value, which is why tag inventories matter more than policy wording.
No. Processing rests on consent or on the specific legitimate uses listed in the Act. There is no open-ended balancing test.
The Act itself allows transfers except to territories restricted by government notification. Separate sector regulations may still require localisation.
No. It requires the transferring organisation to remain accountable, ensure comparable protection and be transparent that information may be processed outside Canada.
PIPEDA operates on an ombudsman model. Findings and recommendations are issued, with court proceedings available for remedies; some provincial regimes do provide direct penalties.
No. The exemption has significant carve-outs — health service providers, businesses trading in personal information and government contractors are covered regardless of turnover.
An entity must assess a suspected breach expeditiously, with the scheme contemplating assessment within 30 days, and notify the OAIC and individuals as soon as practicable once it is an eligible breach.
The PDPC must be notified as soon as practicable and in any case no later than 3 calendar days after the organisation determines the breach is notifiable.
No. Deemed consent and specified exceptions — including legitimate interests and business improvement in defined circumstances — can support processing without express consent.
No. Those free zones have their own data protection laws and regulators, and entities established in them follow those regimes.
Consent is the default, but the law lists circumstances where processing may proceed without it, including contract performance, legal obligations, public interest and certain legitimate interests.
Start with visibility rather than documentation. Establish which systems hold personal data, who owns each of them, and what the data is used for. From that base you can produce a defensible record of processing, decide what notices need to say, and prioritise the gaps that carry real risk. Writing policies before you understand the data usually produces documents that describe a programme nobody is running.
In practice you need a named owner in each function that touches personal data: engineering or IT for systems and access, marketing for consent and tracking, HR for employee data, procurement for vendors, and security for incidents. The privacy lead sets the standard and evidences it; the functional owners are the people who can actually change a system, a form or a contract.
Track a small number of operational measures rather than a policy count: proportion of systems in the inventory with a named owner and a retention rule, rights requests completed within your internal service level, vendors reviewed before signature, DPIAs completed before launch rather than after, and time to detect and triage an incident. Repeating the same maturity assessment at intervals makes the direction of travel visible.
A data inventory is a technical view: which systems and stores hold personal data, what categories they hold and who can reach them. A record of processing activities (RoPA) is a purpose-led view: for each activity, why the data is processed, the categories of people and data involved, recipients, transfers and retention. Most teams build the inventory first and derive the RoPA from it, because the RoPA cannot be accurate if the underlying systems are unknown.
Attach maintenance to events that already happen: new system procurement, a change of purpose, a new integration, or a vendor renewal. Give each entry an owner and a review date, and ask for confirmation at review rather than a rewrite. A short quarterly confirmation cycle across owners keeps a record honest far more reliably than an annual project to rebuild it.
Treat them as a discovery problem, not a discipline problem. Use expense and SaaS billing records, single sign-on logs and endpoint or cloud discovery to find where personal data actually lives. Then decide for each finding whether to bring it into a supported system, restrict it, or retire it. Recording the decision matters as much as the finding.
The common triggers are processing that is likely to be high risk to people: large-scale profiling or automated decisions with a significant effect, systematic monitoring of public or workplace activity, large-scale processing of sensitive categories, combining datasets in ways people would not expect, or new technology whose effects are not yet well understood. Specific requirements and regulator lists vary by jurisdiction, so check the framework that applies to you.
A description of the processing and its purpose, an assessment of whether it is necessary and proportionate to that purpose, an analysis of the risks to the people involved, and the measures you will put in place to reduce those risks — with owners and dates. The value is in the mitigation decisions, not in the length of the document; a DPIA that changes nothing about the design has usually been run too late.
One intake route that is easy to find, a proportionate way of confirming identity, a defined search across the systems recorded in your inventory, a review step for third-party data and any applicable exemptions, and a response format you use consistently. Log each request with dates and decisions. Teams that struggle with rights requests almost always struggle with search scope, which is an inventory problem rather than a legal one.
Enough to be reasonably confident the requester is who they claim to be, and no more. Prefer confirming through an existing authenticated channel such as the account the data sits in. Asking for government identity documents by default collects new sensitive data to answer a request about data you already hold, which usually increases risk rather than reducing it.
Set retention by record class and purpose rather than by system, express each rule as a trigger plus a period (for example, contract end plus a defined number of years), and name the owner who can implement it. Then implement it where the data lives — deletion jobs, lifecycle rules, or archive tiers. A schedule with no technical implementation is a statement of intent, and it will not survive a rights request or an audit.
The common approach is to delete from live systems immediately, place the record beyond use in backups, and let it expire with the normal backup cycle rather than surgically editing archives. Document the approach, the backup retention period and the controls preventing restored data from re-entering live use, so the position can be explained if questioned.
What personal data the vendor will process and for what purpose, where it will be processed and by which sub-processors, security posture and any independent assurance, breach notification commitments, deletion and return at exit, and whether the vendor uses your data to train models or improve their services. Score the review, record the risk flags, and re-check them at renewal instead of treating the assessment as a one-off.
Triage by exposure rather than alphabetically: start with vendors handling sensitive categories, large volumes, or data about employees and children. For each, confirm the contract terms in place, run the same checklist you would use for a new supplier, and record the gaps with a remediation owner. Renewal dates are the practical leverage point for changing terms.
A single reporting route that staff know about, a triage step that decides quickly whether personal data is involved and who is affected, a documented assessment of risk to the people concerned, pre-agreed decision owners, and drafted notification templates. Applicable notification thresholds and timeframes differ by framework, so map the ones relevant to your footprint in advance rather than during the incident.
Keeping an internal record of personal data incidents, including those assessed as not notifiable, is standard practice under most frameworks and is what allows you to demonstrate the assessment was made. Record the facts, the risk analysis, the decision and who made it. Patterns across small incidents are also the cheapest source of control improvements you will find.
Combine content classification with permission analysis. Classification alone tells you where sensitive content sits; permissions tell you who can actually reach it, which is where the risk usually is. Start with the highest-exposure surfaces — broadly shared drives, links open to anyone in the organisation, external guests — then remediate access first and relocate or delete content second.
Tune the rules against your own document set instead of relying on defaults, require multiple signals for high-volume identifiers, and sample findings with the business owner before acting. Report confidence bands rather than raw counts. Remediating on untuned results erodes trust with the teams whose cooperation you need for the next round.
An inventory of AI use cases including embedded vendor features, a lightweight intake that captures purpose, data used and affected people, a risk triage that routes higher-impact cases to fuller assessment, clear rules on what data may be entered into which tools, and human review where outputs affect people. Governance that only covers models your team built will miss most of the actual exposure.
Assistants generally inherit the permissions of the person asking. Over-broad sharing that was previously hidden by the difficulty of finding a file becomes instantly discoverable through natural-language search. The fix is permission remediation before deployment: reduce broad shares, expire stale links, review guest access, and stage the rollout to sites that have been cleaned.
Treat it as a separate purpose rather than an implementation detail. Establish whether training is on by default, whether it can be disabled contractually and technically, what happens to data already used, and how the vendor handles deletion requests that touch trained systems. Record the answer in the vendor assessment so it can be revisited at renewal.