Standards & governance
3 August 2025

Which ISO27001 standards are applicable in accordance with Quebec’s Act 25 on…


Those who have implemented ISO27001:2022 must create a file called a “declaration of applicability” based on the controls in Annex A. There are 93 of them.
We also need to explain why certain controls are applicable to our organization.

The easy way is if there is a legal requirement, contractual requirement, or the result of our risk analysis.
Here I’d like to explore the legal requirement of Bill 25.

Important reminder that I am not a lawyer.


In short, based on ISO 27001:2022 and looking only at the explicit or very direct requirements of Bill 25 (mainly the Act respecting the protection of personal information in the private sector, LQ c P-39.1, as amended), here’s a control-by-control analysis.

Compare – Photo by Melanie Dijkstra on Unsplash

Important information:

  • This analysis focuses on explicit requirements. Many other ISO controls are good practices that help meet the general safety obligation (Art. 10), but are not explicitly required by law.
  • Section 10 of the Privacy Act requires that appropriate security measures be taken to protect personal information, taking into account the sensitivity of the information, the purpose for which it is to be used, its quantity, distribution and medium. This is a general obligation that underlies the relevance of many controls, but we will only list “Yes” if the Act specifically requires the type of measure described by the ISO control.
  • Sections cited refer to the Act respecting the protection of personal information in the private sector (LQ c P-39.1), unless otherwise indicated.

A.5 Organizational controls

  • A.5.1 Information security policies: Yes.
  • Justification: Art. 3.3 requires all companies operating in Quebec to establish and implement policies and practices governing their governance of personal information and aimed at ensuring its protection. These policies must include a framework for the retention and destruction of information, the roles and responsibilities of staff members, and a process for handling complaints. A security policy is an essential component of this framework.
  • A.5.2 Information security roles and responsibilities: Yes.
  • Justification: Art. 3.1 automatically designates the person with the highest authority as the person responsible for the protection of personal information (may delegate). Art. 3.3 requires that governance policies provide for “the roles and responsibilities of its personnel throughout the information life cycle”.
  • A.5.3 Segregation of duties: No. Law 25 does not explicitly require this specific internal control.
  • A.5.4 Management responsibilities: Yes (implicitly).
  • Justification: The existence of a designated officer (Art. 3.1) and the obligation to establish governance policies (Art. 3.3) imply management responsibility for overseeing and approving these measures.
  • A.5.5 Contact with authorities: Yes.
  • Justification: Art. 21.0.1 requires prompt notification to the Commission d’accès à l’information (supervisory authority) of any confidentiality incident presenting a risk of serious harm.
  • A.5.6 Contact with specific interest groups: No. Law 25 does not explicitly require this type of contact.
  • A.5.7 Threat intelligence: No. Useful for Art. 10, but not explicitly required.
  • A.5.8 Information security in project management: Yes (via PIAs).
  • Justification: Art. 3.2 requires the completion of a Privacy Impact Assessment (PIA) for “any information system acquisition, development and redesign or electronic service delivery project involving personal information”.1 A PIA must consider security measures.
  • A.5.9 Inventory of information and other related assets: No. Law 25 focuses on personal information. Knowing where they are is necessary for compliance, but a complete inventory of all assets in the ISO sense is not explicitly required.
  • A.5.10 Acceptable use of information and other related assets: No. Implicit in policies (Art. 3.3) and security (Art. 10), but not formulated as an explicit requirement of this type of policy.
  • A.5.11 Return of assets: No. Internal procedure not specified by law.
  • A.5.12 Classification of information: No. The Act refers to “sensitivity” (Art. 10) but does not impose a formal classification system.
  • A.5.13 Labelling information: No.
  • A.5.14 Transfer of information: Yes (for Personal Information).
  • Justification: Art. 17 specifically governs the communication of personal information outside Quebec (requires a PIA and adequate safeguards). In addition, Art. 10 (security) applies to all transfers, and policies (Art. 3.3) must cover the life cycle, including transfers/communications.
  • A.5.15 Access control: Yes (implicitly fundamental).
  • Justification: Although Art. 10 is general, limiting access to personal information to authorized persons is a fundamental security measure implicitly required to ensure the required protection. Policies (Art. 3.3) should address this.
  • A.5.16 Identity management: Yes (implicitly required).
  • Justification: Necessary to implement access control (A.5.15), therefore implicitly required by Art. 10 and policies (Art. 3.3).
  • A.5.17 Authentication information: Yes (implicitly required).
  • Justification: Necessary for identity management (A.5.16) and access control (A.5.15), therefore implicitly required by Art. 10 and policies (Art. 3.3).
  • A.5.18 Access rights: Yes (implicitly required).
  • Justification: Necessary to implement access control (A.5.15), therefore implicitly required by Art. 10 and policies (Art. 3.3).
  • A.5.19 Information security in relations with suppliers: Yes.
  • Justification: Art. 17 (communication outside Quebec, often via suppliers) requires a PIA and guarantees. Art. 10 requires appropriate security, which implies due diligence when suppliers handle personal information. Art. 3.2 (PIA) may also apply if a supplier is involved in a targeted project.
  • A.5.20 Treatment of information security in supplier agreements: Yes.
  • Justification: Necessary to formalize the guarantees required by Art. 17 and to ensure compliance with Art. 10 when suppliers are involved.
  • A.5.21 Information security management in the ICT supply chain: Yes.
  • Justification: Variant of A.5.19/A.5.20, particularly relevant for cloud services or other links in the ICT chain dealing with personal information, in connection with Art. 10, Art. 17, Art. 3.2.
  • A.5.22 Monitoring, review and change management of supplier services: Yes.
  • Justification: Monitoring to ensure that contractual (A.5.20) and legal (Art. 10, Art. 17) obligations are met over time.
  • A.5.23 Information security for the use of Cloud services: Yes.
  • Justification: Specific case of supplier management (A.5.19 to A.5.22) critical for compliance with Art. 10, Art. 17 and potentially Art. 3.2 (PIA).
  • A.5.24 Information security incident management planning and preparation: Yes.
  • Justification: Directly supports the “confidentiality incident” management requirements of Art. 21.0.1 (notification) and 21.0.2 (register).
  • A.5.25 Assessment and decision regarding information security events: Yes.
  • Justification: Necessary step to determine whether there is a “confidentiality incident” and whether it presents a “risk of serious harm” (Art. 21.0.1).
  • A.5.26 Response to information security incidents: Yes.
  • Justification: The main action required following an incident, including measures to reduce risk (implicit in Art. 21.0.1) and record keeping (Art. 21.0.2).
  • A.5.27 Learning from information security incidents: No. Good practice, but not an explicit requirement of Law 25.
  • A.5.28 Collection of evidence: No. May be necessary for investigation (A.5.26), but not an explicit legal requirement per se.
  • A.5.29 Information security during disruptions: No. Business continuity is not explicitly required by Law 25 (unless the unavailability causes harm under Art. 10 or an incident).
  • A.5.30 ICT preparation for business continuity: No. See A.5.29.
  • A.5.31 Legal, statutory, regulatory and contractual requirements: Yes.
  • Justification: Law 25 is a legal and regulatory requirement that must be identified and complied with. Policies (Art. 3.3) must reflect compliance.
  • A.5.32 Intellectual property rights: No. Not relevant to privacy.
  • A.5.33 Record protection: Yes.
  • Justification: Personal information constitutes records that must be protected (Art. 10) and managed for retention and destruction (Art. 11, Art. 3.3).
  • A.5.34 Confidentiality and protection of personally identifiable information (PII): Yes.
  • Justification: This is the very purpose of Bill 25. Art. 10 requires their protection, Art. 3.3 requires governance policies, etc.
  • A.5.35 Independent review of information security: No. Not explicitly required by Law 25.
  • A.5.36 Compliance with policies and standards: Yes (implicitly).
  • Justification: The obligation to implement policies (Art. 3.3) implies verification of compliance with them.
  • A.5.37 Documented operating procedures: No. Good practice. Good practice, but not explicitly required by Law 25.

A.6 Personal controls

  • A.6.1 Background check: No. Not required by Law 25.
  • A.6.2 Terms and conditions of employment: No. Not covered by Law 25, although confidentiality clauses are a good practice (supports Art. 10).
  • A.6.3 Information security awareness, education and training: Yes.
  • Justification: Art. 3.3 requires that governance policies provide for “the training and awareness measures that [the company] offers to its staff members” regarding the protection of personal information.
  • A.6.4 Disciplinary process: No. Internal HR responsibility.
  • A.6.5 Responsibilities after termination or change of employment: No. Internal procedure. Internal procedure.
  • A.6.6 Confidentiality or non-disclosure agreements: No. Not explicitly required. Not explicitly required, but good practice (supports Art. 10).
  • A.6.7 Remote working: No. The Act requires security regardless of location (Art. 10), but does not prescribe a specific policy for teleworking (this should be covered by the general policies under Art. 3.3 if applicable).
  • A.6.8 Reporting of information security events: Yes.
  • Justification: Necessary mechanism for staff to report incidents, enabling the company to meet its obligations under Art. 21.0.1 and 21.0.2. Part of training/awareness (Art. 3.3).

A.7 Physical controls

  • A.7.1 Physical security perimeters: Yes (implicitly fundamental).
  • Justification: Art. 10 requires appropriate measures. Physical protection of premises where personal information is stored/processed is implicitly required.
  • A.7.2 Physical access controls: Yes (implicitly fundamental).
  • Justification: Necessary for A.7.1. Linked to Art. 10.
  • A.7.3 Securing of offices, rooms and facilities: Yes (implicitly fundamental).
  • Justification: Necessary for A.7.1/A.7.2. Linked to Art. 10.
  • A.7.4 Physical security monitoring: No. Specific method not required by Law 25.
  • A.7.5 Protection against physical and environmental threats: Yes (implicitly).
  • Justification: Ensuring the availability/integrity of personal information falls under the “appropriate measures” of Art. 10.
  • A.7.6 Work in secure areas: Yes (implicitly).
  • Justification: Linked to A.7.1-A.7.3 and Art. 10.
  • A.7.7 Clean desk and clean screen: No. Specific practice not required.
  • A.7.8 Location and protection of equipment: Yes (implicitly).
  • Justification: Physical protection measure required under Art. 10.
  • A.7.9 Off-premises asset security: Yes (implicitly).
  • Justification: Art. 10 applies regardless of location. Relevant for teleworking, mobile devices.
  • A.7.10 Storage media: Yes.
  • Justification: Art. 10 requires secure storage. Art. 11 requires secure destruction/anonymization (relevant for media disposal).
  • A.7.11 Utilities: No. Not explicitly mentioned.
  • A.7.12 Wiring safety: No. Technical details not mentioned.
  • A.7.13 Equipment maintenance: No. Internal procedure (but unsafe maintenance could violate Art. 10).
  • A.7.14 Safe disposal or reuse of equipment: Yes.
  • Justification: Directly related to Art. 11 (destruction/anonymization) when equipment contains personal information. Also Art. 10.

A.8 Technological controls

  • A.8.1 User terminals: Yes (implicitly).
  • Justification: Must be secured in accordance with Art. 10 if they process/store personal information. Policies (Art. 3.3) should cover this.
  • A.8.2 Privileged access rights: Yes (implicitly essential).
  • Justification: Essential aspect of access control (A.5.15, A.5.18) required to comply with Art. 10.
  • A.8.3 Restriction of access to information: Yes (implicitly essential).
  • Justification: Core of access control (A.5.15, A.5.18) required by Art. 10.
  • A.8.4 Access to source code: No. Specific technical control not required.
  • A.8.5 Secure authentication: Yes (implicitly essential).
  • Justification: Essential part of identity/access management (A.5.16, A.5.17) required by Art. 10.
  • A.8.6 Capacity management: No. Not explicitly required.
  • A.8.7 Malware protection: Yes (implicitly fundamental).
  • Justification: Basic safety measure required under Art. 10.
  • A.8.8 Technical vulnerability management: Yes (implicitly).
  • Justification: Necessary part of maintaining the safety required by Art. 10.
  • A.8.9 Configuration management: Yes (partially/implicitly).
  • Justification: Configurations required to enforce security (Art. 10), particularly relevant to Art. 3.4 (default confidentiality).
  • A.8.10 Deleting information: Yes.
  • Justification: Directly required by Art. 11 (destruction when purpose accomplished).
  • A.8.11 Data masking: Yes (as anonymization/security method).
  • Justification: Anonymization is an option to destruction under Art. 11. Masking/pseudonymization can be a security measure under Art. 10 or a mitigation measure in a PIA (Art. 3.2).
  • A.8.12 Data leakage prevention: Yes (implicitly).
  • Justification: Measures to prevent unauthorized disclosure or access are required under Art. 10.
  • A.8.13 Data backup: Yes (implicitly).
  • Justification: Necessary to ensure integrity and availability, considered as part of “appropriate measures” under Art. 10.
  • A.8.14 Redundancy of information processing facilities: No. Specific continuity measurement not required.
  • A.8.15 Logging: Yes (implicitly).
  • Justification: Necessary for monitoring, incident detection/investigation (A.5.24-A.5.26, Art. 21.0.1/21.0.2), and potentially for demonstrating compliance (Art. 10).
  • A.8.16 Activity monitoring: Yes (implicitly).
  • Justification: Necessary to detect incidents (Art. 21.0.1/21.0.2) and ensure the effectiveness of controls (Art. 10).
  • A.8.17 Clock synchronization: No. Technical detail supporting logging, but not explicitly required.
  • A.8.18 Use of preferred utility programs: No. Specific technical inspection related to A.8.2.
  • A.8.19 Installation of software on operational systems: No. Change management practice not explicitly required.
  • A.8.20 Network security: Yes (implicitly fundamental).
  • Justification: Basic safety measure required under Art. 10.
  • A.8.21 Network services security: Yes (implicitly).
  • Justification: Required for A.8.20. Related to Art. 10.
  • A.8.22 Network segregation: No. Specific choice of architecture not required.
  • A.8.23 Web filtering: No. Specific tool not required.
  • A.8.24 Use of cryptography: Yes (contextually/implicitly).
  • Justification: Art. 10 requires appropriate measures taking into account sensitivity. Encryption is often a key measure deemed appropriate for sensitive personal information (storage/transit). A PIA (Art. 3.2) could also identify it as necessary.
  • A.8.25 Secure development lifecycle: Yes (partially/via EFVP & PbD).
  • Justification: Art. 3.2 (PIA) requires privacy impact assessments of systems. Art. 3.4 (Privacy by design/default) implies that secure development practices incorporate privacy from the outset.
  • A.8.26 Application security requirements: Yes.
  • Justification: Linked to A.8.25, Art. 3.2, Art. 3.4, and Art. 10. Security must be integrated into applications handling personal information.
  • A.8.27 Architecture and engineering of secure systems: Yes.
  • Justification: Linked to A.8.25, A.8.26, Art. 3.2, Art. 3.4, Art. 10.
  • A.8.28 Secure coding: Yes.
  • Justification: Linked to A.8.25-A.8.27. Essential for application security (Art. 10) and Confidentiality by Design (Art. 3.4).
  • A.8.29 Safety tests in development and acceptance: Yes.
  • Justification: Linked to A.8.25-A.8.28. Necessary to verify effectiveness of measures (Art. 10, Art. 3.4).
  • A.8.30 Outsourced development: Yes.
  • Justification: Development by suppliers requires supervision similar to A.5.19-A.5.22, ensuring compliance with Art. 10, Art. 3.4, potentially Art. 17 and Art. 3.2.
  • A.8.31 Separation of development, test and production environments: No. Good practice, not explicitly required. Good practice, not explicitly required.
  • A.8.32 Change management: No. Process control not explicitly required (but uncontrolled changes could violate Art. 10).
  • A.8.33 Test information: No. The use of personal information in testing would be subject to Art. 10 and consent rules, but control over test data is not specifically required.
  • A.8.34 Protection of information systems during audit tests: No.

As expected, the list of “Yes” items based on explicit requirements is limited, but touches on important areas: governance (policies, roles), incident management, vendor/transfer management, training, destruction/anonymization, PIA and confidentiality by design. Many other controls, notably technical and physical, are strongly implied by the general security obligation of Article 10, but are not explicitly named in the law.


I invite you to click on “Follow” to continue learning more about information security and privacy topics.

Patrick Boucher
President and founder
25+ years of experience in security, ethical hacking, business continuity
Contact us

Sticky Services form

Want to work with us?

Tell us about your challenges. We’ll quickly see if we’re the right team for you.