Which ISO 27001 Controls Apply Under Quebec Bill 25 on the Protection of Personal Information?

For those who have implemented ISO 27001:2022, you must create a file called a Statement of Applicability based on the Annex A controls. There are 93 of them. You must also explain why certain controls apply to your organization.

The easy approach is when there is a legal requirement, a contractual requirement, or the result of your risk analysis. Here, I would like to explore the legal requirement of Bill 25.

Important reminder: 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 is a control-by-control analysis.

Compare — Photo by Melanie Dijkstra on Unsplash

Important:

  • This analysis focuses on explicit requirements. Many other ISO controls are good practices that help meet the general security obligation (Art. 10), but are not explicitly required term by term by the Act.
  • Section 10 of the privacy legislation requires that security measures appropriate to protect personal information be taken, taking into account their sensitivity, the purpose of their use, their 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.
  • Articles 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 Policies for information security: Yes.
  • Justification: Art. 3.3 requires every company operating in Quebec to establish and implement policies and practices governing its governance of personal information and aimed at ensuring their protection. These policies must include a framework for retention and destruction, the roles and responsibilities of staff members, and a complaint handling process. A security policy is an essential component of this framework.
  • A.5.2 Roles and responsibilities for information security: 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 life cycle of that information”.
  • A.5.3 Segregation of duties: No. Bill 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 special interest groups: No. Bill 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 a Privacy Impact Assessment (PIA) for “any information system acquisition, development, or redesign project, or electronic service delivery project involving personal information”. A PIA must consider security measures.
  • A.5.9 Inventory of information and other associated assets: No. Bill 25 focuses on personal information. Knowing where it is located 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 associated 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 the Act.
  • 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 of 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 and 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 supplier relationships: 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 Addressing information security within 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 Managing information security in the ICT supply chain: Yes.
  • Justification: Variant of A.5.19/A.5.20, particularly relevant for cloud services or other ICT chain links handling personal information, in connection with Art. 10, Art. 17, and 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 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 on 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 Bill 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 disruption: No. Business continuity is not explicitly required by Bill 25 (unless unavailability causes harm under Art. 10 or an incident).
  • A.5.30 ICT readiness for business continuity: No. See A.5.29.
  • A.5.31 Legal, statutory, regulatory and contractual requirements: Yes.
  • Justification: Bill 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 the protection of personal information.
  • A.5.33 Protection of records: 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 Privacy 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, and so on.
  • A.5.35 Independent review of information security: No. Not explicitly required by Bill 25.
  • A.5.36 Compliance with policies, rules and standards for information security: 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, but not explicitly required by Bill 25.

A.6 People controls

  • A.6.1 Screening: No. Not required by Bill 25.
  • A.6.2 Terms and conditions of employment: No. Not covered by Bill 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.
  • A.6.6 Confidentiality or non-disclosure agreements: No. 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 general policies under Art. 3.3 if applicable).
  • A.6.8 Information security event reporting: 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 and 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 or processed is implicitly required.
  • A.7.2 Physical entry: Yes (implicitly fundamental).
  • Justification: Necessary for A.7.1. Linked to Art. 10.
  • A.7.3 Securing 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 Bill 25.
  • A.7.5 Protecting against physical and environmental threats: Yes (implicitly).
  • Justification: Ensuring the availability and integrity of personal information falls under the “appropriate measures” of Art. 10.
  • A.7.6 Working in secure areas: Yes (implicitly).
  • Justification: Linked to A.7.1–A.7.3 and Art. 10.
  • A.7.7 Clear desk and clear screen: No. Specific practice not required.
  • A.7.8 Equipment siting and protection: Yes (implicitly).
  • Justification: Physical protection measure required under Art. 10.
  • A.7.9 Security of assets off-premises: Yes (implicitly).
  • Justification: Art. 10 applies regardless of location. Relevant for teleworking and mobile devices.
  • A.7.10 Storage media: Yes.
  • Justification: Art. 10 requires secure storage. Art. 11 requires secure destruction or anonymization (relevant for media disposal).
  • A.7.11 Supporting utilities: No. Not explicitly mentioned.
  • A.7.12 Cabling security: No. Technical detail not mentioned.
  • A.7.13 Equipment maintenance: No. Internal procedure (but unsafe maintenance could violate Art. 10).
  • A.7.14 Secure disposal or re-use 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 endpoint devices: Yes (implicitly).
  • Justification: Must be secured in accordance with Art. 10 if they process or 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 Information access restriction: 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 and access management (A.5.16, A.5.17) required by Art. 10.
  • A.8.6 Capacity management: No. Not explicitly required.
  • A.8.7 Protection against malware: Yes (implicitly fundamental).
  • Justification: Basic security measure required under Art. 10.
  • A.8.8 Management of technical vulnerabilities: Yes (implicitly).
  • Justification: Necessary part of maintaining the security 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 (privacy by default).
  • A.8.10 Information deletion: Yes.
  • Justification: Directly required by Art. 11 (destruction when the purpose is accomplished).
  • A.8.11 Data masking: Yes (as an anonymization/security method).
  • Justification: Anonymization is an option to destruction under Art. 11. Masking or 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 communication or access are required under Art. 10.
  • A.8.13 Information backup: Yes (implicitly).
  • Justification: Necessary to ensure integrity and availability, considered part of “appropriate measures” under Art. 10.
  • A.8.14 Redundancy of information processing facilities: No. Specific continuity measure not required.
  • A.8.15 Logging: Yes (implicitly).
  • Justification: Necessary for monitoring, incident detection and investigation (A.5.24–A.5.26, Art. 21.0.1/21.0.2), and potentially for demonstrating compliance (Art. 10).
  • A.8.16 Monitoring activities: 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 privileged utility programs: No. Specific technical control related to A.8.2.
  • A.8.19 Installation of software on operational systems: No. Change management practice not explicitly required.
  • A.8.20 Networks security: Yes (implicitly fundamental).
  • Justification: Basic security measure required under Art. 10.
  • A.8.21 Security of network services: Yes (implicitly).
  • Justification: Required for A.8.20. Linked to Art. 10.
  • A.8.22 Segregation of networks: No. Specific architecture choice 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 sensitivity into account. 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 life cycle: Yes (partially/via PIA and privacy by design).
  • Justification: Art. 3.2 (PIA) requires assessment of privacy impacts 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 Secure system architecture and engineering principles: Yes.
  • Justification: Linked to A.8.25, A.8.26, Art. 3.2, Art. 3.4, and Art. 10.
  • A.8.28 Secure coding: Yes.
  • Justification: Linked to A.8.25–A.8.27. Essential for application security (Art. 10) and privacy by design (Art. 3.4).
  • A.8.29 Security testing in development and acceptance: Yes.
  • Justification: Linked to A.8.25–A.8.28. Necessary to verify the 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.
  • 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 testing: No.

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

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