What a vendor bidding into a BC public body is asked to demonstrate
A British Columbia ministry, health authority, university or municipality wants to buy your software. The request for proposals has a privacy section, a security schedule and a questionnaire that reads differently from the enterprise ones you have answered before. It is not harder. It is aimed at a different statute, and most of the obligations it protects belong to somebody else.
The short version
FIPPA binds public bodies, and in one respect it binds your people directly: section 25.1 applies to the employees and associates of a service provider. Most of the rest reaches a vendor through the contract, which is why the security schedule rather than the statute is the document that decides most of what you must do. A public body cannot delegate away its duties under the Freedom of Information and Protection of Privacy Act, so it passes the operational parts of them to you in writing and then has to be able to demonstrate that it did.
That single fact explains almost everything unusual about public-sector procurement: the level of specificity, the insistence on documentation before award rather than after, and the questions that seem to be about the buyer’s process rather than your product. They are about the buyer’s process. You are being asked to make it possible.
Where FIPPA lands, and how it reaches you
Three provisions do most of the work in a supplier relationship.
- Section 25.1 prohibits an employee, officer or director of a public body — and an employee or associate of a service provider — from collecting, using or disclosing personal information except as authorized by that Part. The Act names service providers directly, and the duty attaches to your people.
- Section 30 requires the public body to protect personal information in its custody or under its control by making reasonable security arrangements against such risks as unauthorized collection, use, disclosure or disposal. When the information sits in your system, the reasonableness of those arrangements is largely a statement about you.
- Section 36.2 requires the head of a public body to develop a privacy management program in accordance with the responsible minister’s directions. Your evidence becomes part of that programme.
The control-by-control view of these is in the statute-to-control map.
Privacy impact assessments
The public body conducts the privacy impact assessment. FIPPA defines it as an assessment conducted by a public body, and places the duty to conduct one on the head of the public body — the vendor’s job is to supply accurate answers about the system, quickly. FIPPA defines a privacy impact assessment as an assessment conducted by a public body to determine whether a current or proposed enactment, system, project, programme or activity meets the requirements of Part 3 of the Act, and section 69 requires the head of a ministry, and the head of a public body that is not a ministry, to conduct one in accordance with the responsible minister’s directions.
What that means for a vendor is a request for detail on a schedule you do not control. The questions are consistent: what personal information the system collects and why, where it is stored and processed, who can access it and under what controls, how long it is kept and how it is destroyed, what it is disclosed to and where those parties are, how the public body gets its data back or has it destroyed at the end, and how a breach would be detected and reported. The PIA and the information-sharing agreement that often travels with it are covered on BC FIPPA PIAs and information-sharing agreements.
Have those answers written before the request arrives. A vendor who returns them in a day, in the buyer’s format, is materially easier to buy from — and the assessment is frequently on the critical path to award.
Where the data lives, and who can reach it
The provisions that restricted storage and access outside Canada, FIPPA sections 30.1 and 30.2, were repealed in 2021. Residency is now a matter for the public body’s own assessment and for the contract, which means it is frequently still required of you. Read the schedule, not the history: many public bodies continue to require Canadian storage and processing as a matter of policy or contract, and some require that no access occur from outside Canada even where storage is domestic.
That second requirement is the one that catches software companies out, because it reaches support rather than hosting. An engineer troubleshooting from another country, a follow-the-sun support desk, a subcontracted operations team and a model provider with no residency commitment are all access, and all four need an answer before you bid rather than during due diligence.
Access, correction and records requests
A public body has statutory duties to respond to requests for records and to requests for correction of personal information, on statutory timelines. If the records live in your system, your system has to be able to produce them.
Three capabilities are worth having before anyone asks: retrieve everything relating to a named individual across the whole system, including logs and attachments; record a correction, or an annotation where the original cannot be altered; and export in a form somebody can actually review, which normally means documents rather than a database dump. Building these under a statutory clock is far more expensive than building them in advance.
The security schedule
Read the security schedule before the technical requirements, because it is the part of a public-sector contract that creates obligations your architecture may not currently meet. The recurring items are unsurprising and worth checking your architecture against line by line: encryption in transit and at rest; role-based access with individual accounts and multi-factor authentication; logging of access to personal information with a stated retention; background checks for personnel with access; restrictions on subcontracting and a duty to disclose subcontractors; breach notification to the public body within a stated and usually short period; a right of inspection or to receive evidence on request; secure destruction or return at the end of the contract; and business continuity commitments.
Two of these tend to need genuine engineering rather than a policy: individual accounts with elevation controls for your own staff, and access logging that can be filtered to one public body’s records. Both are the same work you would do for a large private buyer, which is the useful thing about preparing for this market — nothing in it is wasted elsewhere.
Breach notification runs on the contract clock
Under section 36.3 a public body must, without unreasonable delay, notify an affected individual where a privacy breach could reasonably be expected to result in significant harm to that individual, and must notify the commissioner in those circumstances. The public body cannot meet that duty unless you tell it promptly, which is why supplier contracts impose their own short notification period on you.
Your obligation is therefore contractual and fast, and it sits upstream of a statutory duty belonging to someone else. Plan on notifying the public body before you know the full extent, because the alternative is discovering the timeline after it has run. The position for private-sector organizations is different and frequently misreported — we set it out in reporting a breach in BC.
Preparing the evidence before the RFP
- A data-flow description: what personal information the system holds, where it is processed and stored, and which third parties touch it.
- A sub-processor list with locations, kept current.
- An access model: roles, how staff access is granted and removed, and what is logged.
- A retention and destruction schedule.
- An incident process with the notification path to a customer named in it.
- A current test summary and the status of anything still open.
- Answers to the standard privacy impact assessment questions, in a document you can adapt rather than rewrite.
Assembling this before a bid rather than during one is the whole recommendation of this page. The Canadian-privacy version of the same preparation is Canadian privacy readiness, and how the instruments divide up is in which Canadian privacy law applies.
How this differs from a private enterprise review
A private reviewer is managing their own risk and can exercise judgement. A public body is discharging a statutory duty and documenting that it did, so the process is more formal, more evidenced, and less negotiable. Timelines are longer and driven by the buyer’s internal review rather than by a deal. Requirements arrive as contract schedules rather than as questions. And the output is a file that may itself be subject to a request for records.
What does not differ is the underlying engineering. The rest of our compliance work is set out under compliance and privacy.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Does FIPPA apply to us directly?
FIPPA binds public bodies, and in one respect it binds your people directly: section 25.1 applies to the employees and associates of a service provider. Most of the rest reaches a vendor through the contract, which is why the security schedule rather than the statute is the document that decides most of what you must do.
Who writes the privacy impact assessment?
The public body conducts the privacy impact assessment. FIPPA defines it as an assessment conducted by a public body, and places the duty to conduct one on the head of the public body — the vendor’s job is to supply accurate answers about the system, quickly.
Do we need our data in Canada?
The provisions that restricted storage and access outside Canada, FIPPA sections 30.1 and 30.2, were repealed in 2021. Residency is now a matter for the public body’s own assessment and for the contract, which means it is frequently still required of you.
Which part of the contract matters most?
Read the security schedule before the technical requirements, because it is the part of a public-sector contract that creates obligations your architecture may not currently meet.
Nothing here is legal advice. The public body’s counsel and privacy office set the requirements for their procurement, and your own counsel reads the schedule you are being asked to sign.
Preparing for a public-sector bid
Send the security schedule and the privacy section of the request. The reply says which commitments your architecture already meets and which two need work first. More of our writing is indexed at writing.