TGV Security group: the 112 criteria explained

What the group covers

In the official grid of the Trousse globale de vérification (TGV), version of April 24, 2026, the Security group checks information security around your technology product or service (PST). It is the largest group: 112 of the 382 criteria, S01.01 to S16.04, in 16 categories close to the Annex A domains of ISO 27001 in its 2013 version, though the grid does not claim equivalence. Most criteria apply to every PST; some apply only in specific cases, such as an application that uses email (S11.04). The official grid exists only in French: the criteria and quotes on this page are Sentrix's translations, and the suggested evidence and advice are Sentrix's interpretation.

The categories one by one

Risk management and security policy

Risks are assessed at design time and before going live, then periodically and for every major change, with management sign-off. The policy sets objectives, roles and the handling of exceptions; it is approved, communicated and versioned. S02.04 adds a directive on malicious emails and viruses, with a reference to “SCT (13/15 mesures)”.

Organization and human resources

Security responsibilities are defined, every asset has an owner and incompatible duties are identified. Project management builds in security, and mobile device and remote work risks are covered. On the HR side: verified skills, awareness for all staff including management, defined sanctions, and a reminder of lasting obligations when people leave.

Asset management

Terms of use are accepted at first use and must be customizable to include the user's responsibility for personal health information (S05.02). Assets are inventoried, have an owner and are classified for availability, integrity and confidentiality. The rest covers the return of assets, removable media and secure disposal.

Access control

With 26 criteria, this is the largest category: access policy, profiles, privileged accounts and access reviews. S06.06 makes MFA mandatory, internally and externally for employees and high-privilege accounts, and with behaviour analytics (UBA, UEBA) for users and citizens. The grid also expects modern protocols (LDAPS, SAML, OpenID), no passwords in clear text or in code, disabling an ID after at most 5 failed attempts (S06.16) and automatic logout. Practitioner accounts come from Santé Québec's central directory (S06.24), and S06.26 refers to Law 5 and Law 25.

Cryptography and physical security

Sensitive data is encrypted at rest and in transit, exchanges between components are also authenticated, and keys are managed across their whole life cycle (S08.01). On the physical side: protected premises, maintained equipment, a clean desk and clear screen policy, backed by service contracts.

Operations security

The grid wants operating procedures plus user, installation and maintenance guides. Backups are protected from ransomware and allow full or partial recovery. Add change management, a visible version number, vulnerability and patch management, a statement that the application has no backdoor, and antivirus with EDR. S10.03 asks you to use Santé Québec's tools: protocols, the RGT network and the provincial GIA identity and access portal.

Logging and monitoring

All activity, including a system pilot's or an administrator's, must be loggable: who, when, what, and on which information. Logs can be analyzed and exported in a standard format, and an auditor role can read the reports. The application alerts system pilots (S10.06), the environment detects intrusions, and logs are protected and retained according to applicable laws and standards.

Communications security

All communications, remote support included, are protected, for example with end-to-end encryption, and the environment is segmented (public access, server zone). Email carries nothing confidential without protection, connectivity goes through the RGT network or encrypted links, and S11.05 asks for ongoing phishing simulations.

Acquisition, development and maintenance

Security is built into every development stage, following a framework such as OWASP's. Development, test and production environments are separate, with no confidential production data used in development; outsourced development is supervised and third-party components are monitored. S12.01 requires ongoing training on 4 topics: mobile devices, phishing, viruses and ransomware, and social engineering.

Supplier relationships

You list your suppliers and, for each one, carry out the threat and risk assessments and privacy impact assessments that are needed, set requirements, sign an agreement and monitor its compliance and performance. S14.02 refers to “requirement 05 of the 12 minimum requirements” for the PST's location, with only a link to an MSSS document on protecting data at rest.

Security incident management

Your incident management process is aligned with your clients', who are notified as soon as possible under an established process. Monitoring follows the solution's sensitivity. If its availability is classified moderate to very high, S15.03 asks for a disaster recovery plan or alignment with the mechanisms of the Secrétariat du Conseil du trésor (Quebec's Treasury Board Secretariat).

Business continuity and compliance management

A business continuity plan and a disaster recovery plan exist, and the latter is tested periodically. A strategy validates the technical compliance of components. S16.03 requires a penetration test by an independent provider recognized by Santé Québec, and S16.04 a guarantee of your rights to the code under copyright law, or their limits, such as the licence type.

Evidence to prepare

• Risk assessment, treatment plan and management approvals.
• Security policy, proof of approval, version history and incident directive.
• Description of security roles, incompatible duties and remote work policy.
• Awareness program, training plan and phishing simulation results.
• Terms of use with screenshots, asset inventory and classification.
• Access policy, list of profiles, list of high-privilege accounts and exception requests.
• Documentation of encryption and of the key life cycle.
• Guides, change process, vulnerability management plan and no-backdoor statement.
• List of logs, their protections and their retention schedule.
• List of suppliers, agreements and the assessments done for each one.
• Incident process, notification clauses, continuity and recovery plans, test results.
• Penetration test report, action plan and warranty statement on the code.

Points to watch

• Numbering does not follow the categories: S08.01 belongs to cryptography, S09.01 to physical security, S10.01 to S10.03 to operations. File your evidence by criterion number.
• Some criteria are conditional: S06.09 if the application manages passwords, S06.21 (CAPTCHA) optional when MFA is in place, S11.04 if the application uses email.
• Passwords in code or scripts (S06.11) or generic accounts (S06.18) require an exception request to Santé Québec.
• Cross-references to watch: S06.24 cites GIA directive SanteQc-DIR-012, marked “not yet published”, and S06.16 points to S10.03 for an alert, while the application's alert features are in S10.06.
• After certification, the annual self-declaration requires at least 1 penetration test in the last year and vulnerabilities fixed or mitigated within 15 days of the report.

Need help with this group?

Sentrix helps PST vendors prepare this group, from reading the criteria to gathering the evidence; certification itself rests with the Bureau de certification de Santé Québec. See our TGV certification support service or book a meeting.

Next in the guide

Back to the full TGV guide · TGV framework page