Most Alberta software companies meet the Personal Information Protection Act one of two ways. Either a security questionnaire asks which privacy law governs the contract and the answer is not PIPEDA, or a laptop goes missing and the reporting duty runs to a provincial regulator. Both are late, and the obligations that catch technology companies are specific enough to close in weeks once you know them.
What Alberta PIPA is and who it binds
PIPA is a provincial statute, SA 2003 c P-6.5, in force since 2004 and amended several times since. It governs how organizations collect, use and disclose personal information, balancing an individual's right to protection against an organization's need to use the information for reasonable purposes. Two features of its scope matter. First, the definition of organization is wide: s. 1 covers corporations, unincorporated associations, trade unions, partnerships and individuals acting in a commercial capacity. No revenue floor, no startup carve-out.
Second, PIPA is not limited to commercial activity. Section 4(1) applies the Act to every organization and in respect of all personal information, and it reaches employee data through a defined category, personal employee information, meaning information reasonably required to establish, manage or terminate an employment or volunteer-work relationship. Your HR records, candidate pipeline and contractor files sit inside the statute. PIPEDA reaches employee information only for federal works, undertakings and businesses, so a program built on PIPEDA alone usually has a gap exactly there.
The Act does not apply to health information as defined in the Health Information Act to which that Act applies. Alberta health care runs on a separate statute, covered in our Alberta HIA and BC PIPA guide.
Where PIPA stops and PIPEDA starts
Alberta is one of the provinces whose private sector law the federal Governor in Council has declared substantially similar to Part 1 of PIPEDA. The instrument is the Organizations in the Province of Alberta Exemption Order, SOR/2004-219, made under PIPEDA s. 26(2)(b), and its effect is narrow: organizations subject to Alberta PIPA, other than federal works, undertakings or businesses, are exempt from Part 1 of PIPEDA for collection, use and disclosure that occurs within the province.
Three cases follow. Your Alberta customers, employees and contractors: PIPA governs and PIPEDA is displaced. Personal information crossing a provincial or national border in commercial activity: PIPEDA governs, because selling a subscription to a customer in Manitoba or Ohio is not handling that occurs within Alberta. And if you are a federal work, undertaking or business, meaning telecommunications, banking, interprovincial transport or aviation, PIPEDA governs you regardless.
So an Alberta SaaS company selling into several provinces holds two regimes and builds one program that satisfies both. That works because the laws are substantially similar by design, and it fails when a company writes policies for one and quietly misses the other. Our guide to which Canadian privacy law applies walks the national sorting exercise.
The consent model, and where consent is not required
Section 7 states the rule: no collection, no collection from another source, no use and no disclosure without the individual's consent. Section 7(2) adds a line worth pinning above the signup form: an organization shall not, as a condition of supplying a product or service, require consent beyond what is necessary to provide it. Bundled consent for analytics and marketing inside a mandatory checkbox is what that section exists to stop.
Consent may be written or oral under s. 8(1), and is deemed under s. 8(2) where the individual voluntarily provides the information for a purpose. Section 8(3) permits an opt-out model for particular purposes on legible notice, and s. 9 lets consent be withdrawn or varied at any time on reasonable notice, which is an engineering problem before a policy one.
Consent is not needed everywhere. Sections 14, 17 and 20 allow collection, use and disclosure without it, including where authorized by statute and for investigations and legal proceedings. Sections 15, 18 and 21 do the same for personal employee information reasonably required for the employment relationship. For a current employee, s. 15(1)(c) still requires reasonable notification before collection, saying what will be collected and why. Notification is not consent, and that distinction is what monitoring projects get wrong.
The obligation tech companies miss: service providers outside Canada
This one is close to unique in Canadian privacy law, and almost every technology company triggers it on day one. Section 13.1 covers two situations: using a service provider outside Canada to collect personal information on your behalf with consent, and directly or indirectly transferring information collected with consent to a service provider outside Canada, which includes a sub-processor engaged by your hosting provider.
Section 13.1(3) sets the duty. Before or at the time of collecting or transferring, notify the individual in writing or orally of two things: how to obtain written information about your policies and practices with respect to service providers outside Canada, and the name or position name or title of a person who can answer questions about what those providers do with the information. This is in addition to the s. 13 collection notice. Section 6(2) supplies the content behind the pointer: your policies must name the countries where the handling occurs or may occur and the purposes the provider is authorized for, and s. 6(3) makes that information available on request.
So you need a named country list, not a region and not a link to a vendor's own trust page. It is notice, not consent: nothing requires the individual to agree to the transfer, which makes it cheap to meet and embarrassing to miss. Behind it sits a subprocessor register that is actually true, with hosting regions per vendor. Our guide on the vendor DPA and subprocessor register covers building one, and Canadian data residency separates where residency is law from where it is preference.
Breach reporting to the Alberta Commissioner
Section 34.1(1) requires an organization having personal information under its control to notify the Commissioner, without unreasonable delay, of any incident involving loss of or unauthorized access to or disclosure of personal information where a reasonable person would consider that there exists a real risk of significant harm to an individual.
Section 19 of the Personal Information Protection Act Regulation, AR 366/2003, sets the content: a written notice covering the circumstances, the date or period, the information involved, an assessment of the risk of harm, an estimate of the number of individuals at real risk, the steps taken, and a contact for the regulator's questions.
Here is the mechanical difference. Under PIPEDA you report to the Privacy Commissioner of Canada and notify affected individuals yourself. Under Alberta PIPA that second decision sits with the regulator. Section 37.1 lets the Commissioner require an organization to notify individuals at real risk of significant harm, in the form and manner prescribed and within a time the Commissioner sets, with an expedited process under s. 37.1(3) where the risk is obvious and immediate. The Alberta runbook is therefore a report to the regulator plus a readiness to notify on direction, with a draft notice that already meets s. 19.1 of the regulation.
The trigger phrase is the same one PIPEDA uses, so the assessment logic transfers even though the mechanics do not. Failing to give notice under s. 34.1 is an offence at s. 59(1)(e.1), carrying a fine of up to $100,000 for an organization, subject to the s. 59(4) defence where it establishes it acted reasonably.
Access, correction and the 45 day clock
Section 24(1) gives an individual two distinct requests: access to their personal information, and information about the use or disclosure of it. The second trips up engineering teams. Under s. 24(1.2) you must give the purposes for which the information has been and is being used, and the persons to whom and circumstances in which it has been disclosed. Answering in a week means you already keep a data map and a subprocessor register.
Section 28(1) sets the clock at 45 days from receipt of the written request, or the end of an extension. Section 28(2.1) is blunt: failure to respond in time is treated as a refusal, which puts the individual straight into a review. Section 31(1) allows an extension of up to an additional 30 days, or longer with the Commissioner's permission, where the request lacks detail, a large volume must be searched, or consultation is needed, and s. 31(2) then requires you to give the reason, the expected date and notice of the right to seek review. Section 32 permits a reasonable fee, except on a request for personal employee information.
Correction is s. 25. An error or omission must be corrected as soon as reasonably possible and, where you disclosed it to other organizations, you send them the correction where reasonable. If you decide not to correct, s. 25(3) requires you to annotate the record with the correction requested but not made, and s. 25(5) bars altering an opinion.
The privacy officer requirement
Section 5(3) is one sentence: an organization must designate one or more individuals to be responsible for ensuring that the organization complies with the Act, and s. 5(4) permits delegation. No prescribed title, no registration with the Commissioner, no qualification requirement.
What surrounds it is heavier. Section 5(1) makes the organization responsible for personal information in its custody or under its control, and s. 5(2) makes it responsible for the compliance of any person whose services it engages, whether as agent, by contract or otherwise. That is the statutory basis for vendor management being a privacy obligation rather than a procurement preference. Section 5(6) confirms it does not relieve the service provider of its own duties.
Under about fifty people that individual is usually a co-founder or a head of operations, which is fine. A name in a policy attached to no calendar is not: the role owns the access request queue, the breach decision and the subprocessor register, and somebody must be able to say when each was last exercised.
What you hold alongside PIPA when you sell beyond Alberta
PIPA is the floor. The register for an Alberta SaaS company selling across Canada and into the US:
- PIPEDA, for every flow across a provincial or national border in commercial activity, including its breach reporting duty, breach record retention duty and the ten Fair Information Principles.
- Quebec Law 25, for Quebec customers or employees: the heaviest penalty structure in Canadian private sector privacy law, plus a privacy impact assessment duty, a person in charge of the protection of personal information, and a private right of action.
- British Columbia PIPA, if you employ people or serve customers from a BC footprint. Also substantially similar, also covering employee information.
- A health statute, Ontario PHIPA or Alberta HIA, where you touch health information in a custodian's hands.
- US state privacy statutes, and sectoral rules such as HIPAA business associate obligations.
- Contractual privacy terms, which bind harder and faster than statute. Customer DPAs routinely impose notification timelines measured in hours, audit rights, subprocessor approval and deletion commitments beyond anything PIPA asks.
Where PIPA and SOC 2 overlap, and where they do not
A SOC 2 report and a PIPA program are built from the same raw materials and answer different questions. They overlap on access control, vendor management, incident response, risk assessment and logging, and the Security criteria carry nearly all the safeguarding needed for the reasonable safeguards expectation in s. 34. After a SOC 2 Type II, your incident response process, vendor review cycle and access review evidence are close to what a PIPA review wants.
They do not overlap here. SOC 2 does not ask whether you have a lawful basis for collection, and s. 7 does. It does not ask whether consent is bundled with service delivery, and s. 7(2) does. It does not require you to name the countries where your subprocessors operate, and ss. 13.1 and 6(2) do. It gives nobody a right to see their own data or have it corrected within a deadline, and ss. 24, 25, 28 and 31 do. It does not tell you when to call a provincial regulator, while s. 34.1 does. The optional Privacy category gets closer, but most Canadian SaaS reports scope Security, Availability and Confidentiality only.
"We are SOC 2, so we are PIPA compliant" is therefore a claim a careful buyer will test, and it will not survive the first access request. Our SOC 2 requirements guide sets out what the report does carry.
What a PIPA readiness engagement covers
TrazTech runs privacy readiness the way it runs SOC 2 and ISO 27001 readiness: a gap assessment first, then remediation scoped and priced from what it found, because remediation cannot be priced honestly before anyone knows the gaps. Phase 1:
- A jurisdiction map. Which flows sit inside Alberta under PIPA, which cross a border under PIPEDA, and whether Quebec, BC or a health statute is in play. This decides what everything after it must satisfy.
- A data inventory and flow map, including personal employee information, the category most often missing when an inventory was built on federal assumptions.
- A consent review against ss. 7, 8 and 9: signup, marketing, analytics, telemetry and the conditions attached to service delivery.
- Policies against s. 6 and a service provider review against ss. 5(2), 6(2) and 13.1: every processor and sub-processor, the country each operates in, and whether your notice does what s. 13.1(3) requires.
- Access and correction against ss. 24 to 32, ending with whether 45 days is achievable.
- The breach process against s. 34.1, s. 37.1 and Part 6 of the regulation: a real risk decision record, a report template carrying the s. 19 content, and a draft notice meeting s. 19.1.
- The s. 5(3) designation, with duties written down and on a calendar.
- Safeguards under s. 34 and retention and destruction under s. 35, where a SOC 2 or ISO 27001 control set does most of the work.
The output is a findings register: each gap, its section, the evidence, and what closing it requires. Phase 2 is the remediation, scoped from that register.
Next step
Start with the two provisions cheapest to close and most visible to a regulator or a buyer: the s. 13.1 outside-Canada notice and the s. 5(3) designation with real duties.
TrazTech does privacy readiness, SOC 2 and ISO 27001 readiness, penetration testing and fractional CISO work for Canadian startups and SMEs, and the practice is run by a published security researcher with five CVEs on the public record. Questions worth asking any firm: has it completed engagements in Canada it can show you, is remediation priced before or after the gap assessment, and which entity signs the contract and under which province's law.
Book a call and we will walk your data flows and tell you which statutes you are holding.