Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Federal, provincial and municipal buyers ask a consistent set of security and privacy questions. Most of the answers take weeks to produce and can only be produced once. Build them before the bid, not during it.
Canadian public sector security review has five recurring components: a security schedule in the contract, a threat and risk assessment, a privacy impact assessment that the institution owns but you supply the facts for, vulnerability and penetration testing evidence, and a hosting and residency answer. Federal deals add the Contract Security Program for cleared work and Government of Canada cloud requirements for anything above Protected A. Provincial and municipal buyers run lighter versions of the same. Almost none of it can be produced quickly, and none of it is bid-specific, which makes it the clearest case in security for building before you bid. The artifact that unlocks the most is a current, accurate data flow description.
People say "government" as though it is one buyer. In Canada it is at least three markets with different rules, different timelines and different levels of sophistication.
The federal government is the most structured. Procurement runs through Public Services and Procurement Canada and departmental authorities, opportunities are posted on the national tender service, and the security regime is codified: information is classified using the Protected and Classified scheme, security requirements are expressed on a standard security requirements checklist attached to the contract, cleared work requires organization and personnel screening through the Contract Security Program, and cloud services are governed by Treasury Board direction and Canadian Centre for Cyber Security guidance. Federal procurement is slow and heavily documented, and the requirements are knowable in advance, which is an advantage if you prepare.
The provinces vary widely. Ontario runs vendor of record arrangements as pre-qualified supply vehicles with second-stage competitions, and its institutions are working through the obligations introduced by Bill 194. British Columbia has a well-developed privacy impact assessment and security threat and risk assessment practice for public bodies. Alberta has its own access and privacy regime for public bodies and, for health, a Commissioner who reviews assessments before implementation. Quebec applies its public sector privacy act and, for anything touching personal information leaving the province, the Law 25 assessment logic. Each province has its own standards documents and its own templates.
The broader public sector, meaning municipalities, school boards, colleges, universities, hospitals, transit authorities and agencies, is the largest by count and the most variable. A large city runs a review comparable to an enterprise one. A small municipality may have no security function at all and will send you a template it downloaded. Both are real buyers and both need the same underlying artifacts from you.
The common thread is that the questions are more similar than the processes. A vendor with a complete artifact set answers all three markets from the same folder.
Public sector agreements attach a security schedule that states the controls you must maintain, and it is more prescriptive than a typical commercial agreement. Read it before you price the deal, because it can contain obligations that require engineering work.
The recurring clauses are: specific safeguards including encryption standards, access control and personnel screening requirements; restrictions on where information may be stored and accessed from; obligations to notify the institution of security incidents within a stated period; audit and inspection rights for the institution and sometimes for a regulator or auditor general; subcontractor disclosure and approval; return or certified destruction of information at the end of the contract; and a requirement to comply with named government standards.
Two clauses deserve particular attention. The first is incident notification, which is frequently drafted as immediate notice of any incident. The public sector version of the negotiation is the same as the private one: define the trigger as a confirmed security incident affecting the institution's information or the services provided to them, and commit to a clock your process has actually been exercised against.
The second is compliance with named standards. A schedule that requires compliance with a government technology standard by reference is committing you to a document you may not have read. Read it. Some of these standards are general and easy to meet; others contain specific requirements about cryptography, network zoning or logging that will require changes. The federal cryptographic guidance and the provincial technology standards series are the usual references.
The third thing to check is whether the schedule extends obligations to your subcontractors, because it usually does, and whether you have the contractual right to pass them down. A commitment you cannot flow down to a critical subprocessor is a commitment you cannot meet.
A threat and risk assessment, universally abbreviated to TRA, is the standard Canadian public sector instrument for evaluating the security of a system before it is deployed. Federal practice follows the risk management approach in the Canadian Centre for Cyber Security's guidance; provinces have their own equivalents, and British Columbia's security threat and risk assessment is the best known.
A TRA identifies the assets and the information involved, assigns injury or sensitivity levels, describes the threat environment, identifies vulnerabilities, assesses the likelihood and impact of compromise, and lists safeguards and residual risk. It concludes with a recommendation and, typically, a set of conditions the system must meet before authorization.
Sometimes the institution runs the TRA and you supply the input. Sometimes they require you to provide one, performed by an independent party. Sometimes an existing TRA needs updating because your product changed. All three happen, and the difference is worth clarifying at bid time because one of them is a cost you carry.
What the assessor will ask you for: a system architecture description including all components and data flows, the information categories and their sensitivity, the interfaces and integrations, the authentication and authorization model, the encryption in transit and at rest with specifics, the logging and monitoring arrangements, the hosting environment and regions, the administrative access model, the subcontractors, the vulnerability management process, and recent testing results.
What makes a TRA go badly: vague safeguard descriptions, undisclosed subcontractors, an access model where the vendor has standing production access, no record-level logging, unpatched components, and testing that excluded the parts of the system in scope. What makes it go well is having every one of those answers written down before the assessor asks, which is the same artifact set every other part of this guide needs.
Our threat and risk assessment work and the Canadian TRA guide cover the process from the assessor's side.
A privacy impact assessment is a separate instrument from a TRA and the two are often confused. A TRA is about security risk to the system. A PIA is about privacy risk to individuals: what personal information is collected, under what authority, for what purpose, who sees it, how long it is kept, what the risks are and how they are mitigated.
PIAs are mandatory for federal institutions under Treasury Board policy, for British Columbia public bodies under their privacy statute, for Alberta health custodians with a submission to the Commissioner, and now for Ontario provincial institutions under the changes introduced by Bill 194. Municipalities and broader public sector bodies increasingly do them as policy.
The assessment belongs to the institution. In practice, for a vendor-supplied system, most of its content is factual detail about your product. If you can supply a complete and accurate description on the first request, you shorten the institution's timeline by weeks and you become easy to buy from. If they have to extract it question by question, you become the reason the project slipped.
What to keep ready: the categories of personal information collected, the source of each, the purposes, the users and roles that can access each category, the retention period, the disposal method and the evidence it produces, every subprocessor with its location and function, the security safeguards in specific terms, whether any automated decision-making or model inference happens and what human review sits around it, and how individuals' access and correction requests are handled through your product.
Alberta deserves a specific note. For health custodians there, the privacy impact assessment is submitted to the Office of the Information and Privacy Commissioner of Alberta before the practice or system is implemented, and the custodian generally waits for the review. That makes it a schedule dependency on a regulator queue rather than an internal document, and it is covered in our Alberta and BC guide.
Public sector buyers ask for testing evidence more consistently than commercial buyers do, and they read it more carefully.
The baseline ask is an independent penetration test within the last twelve months, covering the application and infrastructure in scope for their use, with a report and the remediation status of every finding. Some institutions require the full report under NDA rather than an attestation letter. Some require the test to be performed by a firm meeting specific criteria, and federal work sometimes requires cleared testers.
The scoping trap is real. A test scoped to your marketing site, or to a version of the product without the integration the institution will use, will be noticed. So will a report where the same high severity findings appear in consecutive years. The remediation status column is read as closely as the findings.
Alongside the test, expect questions about ongoing vulnerability management: whether you scan, how often, how you triage by severity, what your remediation targets are by severity, and whether you can show that you meet them. Stating a 30 day target for high severity findings and then producing evidence that you actually close them in 30 days is far more persuasive than a policy alone. Our vulnerability management page describes what that looks like operationally.
Two other testing topics come up at the higher end. Source code and secure development: whether you use static analysis, dependency scanning and code review, and whether security requirements enter the development lifecycle. And third party components: a software bill of materials is increasingly requested, particularly federally, and even where it is not required, being able to produce a dependency inventory quickly answers several questions at once.
This is the requirement small vendors most often misjudge, in both directions. Some assume they need clearances they do not, and some bid on cleared work with no idea what it entails.
Federally, contracts with security requirements attach a security requirements checklist that states what is needed. Where the requirement is real, it is administered through the Contract Security Program, which handles both organization-level screening and personnel screening.
Organization-level screening comes in two main forms: designated organization screening, which covers access to Protected information and assets, and a facility security clearance, which covers access to Classified information. Personnel screening runs from reliability status, the baseline for access to Protected information, through secret and top secret clearances. There are separate requirements for storing Protected or Classified information at your own site, and it is far easier to structure the work so that you never do.
The timelines are the important part. Organization screening commonly takes months and can take well over a year depending on ownership structure, foreign ownership control and influence considerations, and the volume in the queue. Personnel screening for reliability status is faster but still measured in weeks to months, and secret clearances take longer. You cannot start this after you win. In most cases you cannot start it at all without a sponsor, which usually means a contract or a bid that requires it.
The practical implication for a small vendor is to check the checklist early and be honest about it. If the opportunity requires screening you do not have and cannot obtain in time, either partner with a firm that has it, or bid the opportunities that do not require it. Many software opportunities involve no classified information at all, and the requirement is limited to reliability status for the few staff who would touch the environment.
Provincially the picture is lighter and less standardized. Provinces commonly require criminal record checks and sometimes enhanced background screening for personnel with access, defined in the contract rather than through a central program. Read the schedule, and make sure your employment and contractor practices can actually deliver what you agree to.
Federal information is classified using a two-track scheme. Protected A, B and C cover information whose compromise could cause injury to a non-national interest, most commonly personal information; Protected B is the workhorse level and covers most personal information handled by government. Confidential, Secret and Top Secret cover national interest information. Provincial schemes differ in vocabulary but follow the same logic of classifying by injury.
Treasury Board direction requires that cloud-based services handling information classified up to and including Protected B be hosted within Canada, together with a set of security control requirements drawn from federal control catalogues. For a vendor, that is functionally a hard requirement rather than a negotiable preference, and it is the reason a Canadian region is a precondition for most federal software opportunities rather than a differentiator.
Provincially, residency requirements come mostly from policy and procurement templates rather than statute, with the notable exception of Nova Scotia, whose legislation genuinely requires public bodies and their service providers to store and access personal information in Canada. British Columbia removed its statutory prohibition in 2021 but the expectation persists in templates and health authority requirements. Our data residency guide separates the legal requirements from the contractual ones in detail.
Whatever the source, answer the residency question completely rather than on the strength of your primary region. Enumerate primary storage, backups and replication, application logs and telemetry, error tracking, support and ticketing tooling, managed platform services, content delivery, and the geographic location of staff who can access production. That last one is asked separately by good reviewers and it is where most claims break.
The federal cloud picture also includes assessment of the cloud service provider itself. Where you build on a major provider that has been assessed for government use, saying so precisely, and naming the services and regions, is worth more than a general assurance.
Two obligations recur in public sector contracts that have no commercial equivalent, and both surprise vendors.
The first is access to information. Records you hold on behalf of an institution may be in that institution's custody or control for the purposes of federal, provincial or municipal access legislation. That means a member of the public, a journalist or an opposing party can file a request that ultimately requires your customer to produce material that lives in your system. Your contract will oblige you to cooperate, usually within a short timeframe, because the institution is on a statutory clock. Somebody at your company needs to own that obligation and know how to extract records quickly.
The second is records management and retention. Public bodies operate under records schedules and archival legislation, which often require retention far longer than a commercial customer would ask for and sometimes require transfer of records at the end of a contract in a specified format. A default that deletes data 30 days after account termination is not conservative in this context, it is a breach of your customer's obligations.
A third, growing category is accessibility. Not a security requirement, but it appears in the same schedules and it stops bids: federal and several provincial procurements require conformance with recognized web accessibility standards, and Ontario has its own accessibility legislation applying to public sector organizations. If your product has never been tested against an accessibility standard, find out before you bid rather than after you win.
A fourth, newer one is artificial intelligence disclosure. Federal and provincial governments have been developing directives and requirements around the use of automated decision systems and AI in the public sector, and Ontario's Bill 194 creates authority for AI requirements on public sector entities. Expect to be asked whether your product contains AI or machine learning components, what they do, what data they process, whether customer data is used for training, and what human review exists. Answer honestly and inventory your stack first, because reviews find components that sales did not know about.
Everything in this guide is answerable from a fixed set of artifacts. None of them are bid-specific, all of them take longer to produce reactively than proactively, and together they are perhaps four to six weeks of focused work for a small team. Build them in this order.
A data flow description. Every category of information, where it is collected, where it is stored by region, which components and subprocessors can reach it, and the retention period for each. This single document feeds the PIA, the TRA, the security schedule response, the residency answer and the AI declaration. If you build one thing, build this.
A subprocessor register. Name, purpose, data categories, location, and your assessment of each. Keep it current, and keep it in a form you can send.
A controls summary mapped to a framework. Whether that is SOC 2, ISO 27001 or NIST CSF, having your controls expressed against something recognized lets a reviewer tie your answers to a structure they already understand.
Independent evidence. A SOC 2 Type II report is the most useful single document. Failing that, an ISO 27001 certificate, or at minimum a recent independent penetration test with remediation status. Public sector reviewers weigh independent evidence heavily because they cannot verify your assertions themselves.
An access model description. Who at your company can reach production data, under what controls, with what logging, and what the break-glass process is. Standing production access for support engineers is the most common finding in a public sector review, and fixing it before the review is much cheaper than explaining it during one.
Tested resilience. Recovery objectives, and the record of an actual restore test with dates and outcomes. Plus an incident response plan with the public sector notification path in it and the record of an exercise.
The administrative set. Insurance certificates with limits, your policy suite, a named security contact who is a person, background check practices, and financial statements or evidence of viability for the larger opportunities.
What to do during the bid rather than before: nothing on this list. During the bid you should be tailoring, not building.
Public sector timelines are long and the reasons are structural rather than obstructive. Knowing the shape helps you resource it.
A typical sequence: the opportunity is posted or you are approached; you respond to the solicitation including a technical and security response; the institution evaluates; a preferred vendor is selected; then the security and privacy work begins in earnest with the TRA, the PIA and the security schedule negotiation running in parallel; conditions are set; the contract is signed; then implementation, often with security conditions that must be satisfied before go-live.
The elapsed time from posting to signature is commonly six months to a year for a substantial system, and the security and privacy stage is typically two to five months of that. Where a regulator review is involved, as with an Alberta health privacy impact assessment, add the review queue. Where security screening is involved, add considerably more.
The biggest lever on the timeline is round trips. Each question that goes back to you and waits eleven days for an answer adds two weeks, and a review with thirty such questions is a quarter. Having the artifacts ready and one named owner who can get engineering answers quickly is worth more than any other intervention.
The second lever is scope honesty. Conditions imposed at the end of a review because something was discovered late are more expensive than a disclosure made at the start. Reviewers do not expect a small vendor to have everything; they expect the description to be accurate.
The upside, which is real, is that public sector contracts are long, renewals are common, and the second bid into the same institution or a comparable one is dramatically cheaper because the artifact set already exists. The first one is the investment.
Starting the security work after the win. The artifacts take weeks, the review has a schedule, and the institution has other priorities. This is the single most common failure.
Answering the residency question on the primary region alone. Backups, logs and support access break the claim, and a revised answer mid-review reopens everything.
Bidding cleared work without screening. Organization screening takes months to more than a year, requires a sponsor, and cannot be compressed. Check the checklist before you invest in the bid.
Standing production access. Fix it before the review. It is cheap early and expensive to explain later.
A penetration test scoped to the wrong thing. Reviewers read the scope section. A test that excluded the integration they will use is worse than no test, because it looks evasive.
Deletion defaults shorter than the institution's retention schedule. Public bodies operate under records legislation. Your 30 day default puts them in breach.
Declaring no AI when the product contains a model. Inventory your stack before you answer, because the review will find what sales did not know about.
No named owner on your side. Reviews stall on unanswered questions far more often than on failed controls.
| Artifact | What it answers | Effort to build |
|---|---|---|
| Data flow description | The privacy impact assessment, most of the threat and risk assessment, the residency question and the AI declaration. | Three to five days if the system is understood; longer if nobody has mapped it before. |
| Subprocessor register | Subcontractor disclosure clauses, residency follow-ups, fourth party risk questions. | One to two days, then maintained on vendor review. |
| Controls summary mapped to a framework | The security schedule, the bulk of the security questionnaire. | A week if the controls exist; the real cost is the controls themselves. |
| SOC 2 Type II report or ISO 27001 certificate | Independent evidence of operation, which reviewers weigh most heavily. | Months, including an observation window. Start before you need it. |
| Independent penetration test with remediation status | Vulnerability testing requirements, part of the threat and risk assessment. | Two to six weeks including remediation, repeated annually. |
| Access model and break-glass description | The hardest questions in every review: who at your company can see our data. | Days to write, weeks to months if standing access has to be removed first. |
| Tested restore and exercised incident plan | Resilience and incident notification obligations, increasingly asked for as a test record. | Two days to run, if the capability exists. |
| Security screening, where required | The security requirements checklist on federal cleared work. | Months to over a year for organization screening, and it needs a sponsor. |
Only where the contract has security requirements, which are stated on a security requirements checklist attached to the solicitation. Where they exist, organization-level screening and personnel screening are administered through the Contract Security Program: designated organization screening for Protected information, a facility security clearance for Classified information, and personnel screening from reliability status upward. Many software opportunities involve no classified information and require at most reliability status for the few staff who would touch the environment. Check the checklist before investing in a bid, because screening takes months to more than a year and requires a sponsor.
A threat and risk assessment evaluates security risk to a system: assets, threats, vulnerabilities, likelihood, impact, safeguards and residual risk, usually ending with conditions before authorization. A privacy impact assessment evaluates privacy risk to individuals: what personal information is collected, under what authority, for what purpose, who accesses it, how long it is kept, and how the risks are mitigated. Public sector projects commonly require both, they are produced by different people, and both draw most of their vendor-specific content from the same data flow description.
Federally, Treasury Board direction requires cloud services handling information classified up to and including Protected B to be hosted in Canada, which covers most personal information the government handles, so in practice a Canadian region is a precondition rather than a differentiator. Provincially it varies: Nova Scotia has a genuine statutory requirement for public bodies and their service providers, British Columbia removed its statutory prohibition in 2021 though the expectation persists in procurement, and most other provinces impose it through policy and templates rather than legislation.
For a substantial system, the security and privacy stage typically runs two to five months, inside an overall procurement cycle of six months to a year. Add time where a regulator reviews an assessment, as in Alberta health, and considerably more where security screening is required. Most of the elapsed time is round trips rather than analysis, so having the artifacts ready and one named person who can get engineering answers quickly is the single biggest lever on the schedule.
No statute or policy requires one, and plenty of vendors sell without it. What public sector reviewers weigh heavily is independent evidence, because they cannot verify your assertions themselves. A SOC 2 Type II report is the most useful single document; an ISO 27001 certificate is accepted; a recent independent penetration test with remediation status is the minimum credible substitute. Without any of them you can still win, but expect a longer review, more conditions and more scrutiny of your own attestations.
It is the standard federal form attached to a solicitation or contract that states the security requirements applying to the work: whether the contractor needs organization screening, what level of personnel screening applies, what classification of information will be accessed, whether information may be stored at the contractor site, and whether IT systems are involved. It is the document that tells you whether an opportunity is cleared work, and it should be one of the first things you read when evaluating a federal bid.
They continue. Expect ongoing security reporting, notification of material changes such as a new subprocessor or a change of control, annual or periodic reassessment, refreshed penetration test results, cooperation with access-to-information requests that reach records you hold, retention in line with the institution's records schedule rather than your default, and return or certified destruction of records in a specified format at contract end. Nominate an owner for the relationship who is not the salesperson who closed it.
Yes, particularly in the broader public sector and at the provincial level, and there are federal procurement streams intended for smaller suppliers. What is not realistic is bidding without preparation. The artifact set described in this guide is four to six weeks of focused work for a small team, it is not bid-specific, and it is the difference between a review you can survive and one that runs out of patience. Start with the data flow description, fix standing production access, get an independent test done, and bid the opportunities that do not require security screening you cannot obtain.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We build the artifact set the review will ask for, fix the findings that would otherwise become contract conditions, and stay on the file through the assessment.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.