The following controls are not applicable

When your company doesn’t do any software development, these five controls don’t apply:

A8.4 – Access to source code, clearly if we have no development, there’s no source code to manage!

A.8.25 – Secure development lifecycle If you don’t have a development team, you don’t have a development lifecycle.

A.8.26 – Application security requirements This control concerns the security specifications for your own applications. Not those you buy or rent. If you don’t develop anything, this control doesn’t concern you.

A.8.27 – Secure architecture and engineering principles This covers the secure design of the systems you develop. Once again, without development, there is no architecture to design.

A.8.28 – Secure coding The most obvious. No code, no secure coding. Some companies think that configuring software is “coding”. No, it’s configuration.

A.8.29 – Security tests in development Security tests on code under development. Without development, this control falls through.

The grey areas that create confusion

Three controls often create confusion:

A.8.30 – Outsourced development This one is more subtle. If you hire outside programmers to develop something specifically for you, this control applies. But if you buy software off the shelf, even if it’s customized, it doesn’t count as outsourced development.

A.8.31 – Separation of environments You don’t need a development environment if you don’t develop. However, if you have a test environment for your purchased software, this control may be partially applicable.

A.8.33 – Test information If you never test anything, this check doesn’t apply. But beware: most companies do at least acceptance testing on their new software.

What remains applicable

Control 8.32 – Change management is almost always applicable, even without development. Because you’re changing configurations, updating software, modifying settings. That’s change management.

For other controls, such as network security, access management, backup, training? They remain applicable, because with or without development, these measures protect your IT environment, no matter where your software comes from.

How to assess applicability

Ask yourself these simple questions:

• Does anyone in my company write code?
• Do we have in-house programmers?
• Do we hire firms to develop applications specifically for us?
• Do we modify our software source code?

If all answers are “no”, then checks A8.4, 8.25 to 8.29 do not apply to you.

Justification is mandatory

When you declare a control inapplicable, you must justify it in writing in your Declaration of Applicability. This is not optional, it’s a requirement of the standard.

A good justification looks like this:

“The company does not develop any software in-house, nor does it use any development suppliers. All software used is a commercial solution acquired on the market..”

Beware of changes

Your declaration of applicability is not set in stone. If your company evolves and starts to develop, you’ll need to revise this declaration.

I’ve seen companies that started by buying software, then hired programmers to customize it. Overnight, certain controls became applicable again.

What is the OWASP Top 10?

The OWASP Top 10 is a list of the ten most common web security vulnerabilities, designed to make developers and organizations aware of the highest-priority risks to correct or monitor.

Here are the 10 biggest risks associated with a web application for version 2021. (A new version should be released in 2025).

• A01 – Access controls faulty
• A02 – Cryptography and inadequate data protection
• A03 – Injection
• A04 – Unsafe design
• A05 – Component security vulnerabilities
• A06 – Incorrect safety configurations
• A07 – Weak identification and authentication
• A08 – Inadequate error handling and logging
• A09 – Data integrity check
• A10 – Client-side security

Its aim is to raise awareness and help educate people about the risks of Web applications.

What is OWASP ASVS?

The Application Security Verification Standard (ASVS) provides a detailed list of technical requirements for designing, developing and verifying the security of web applications and services.

You can free my introductory post here: https://medium.com/@btk667/owasp-asvs-cest-quoi-9ffd3cb06ad9

It’s a structured framework, designed for testing and integration into the SDLC. The current stable version is ASVS 5.0.0.

Each requirement is identifiable and formulated in a verifiable way – practical for acceptance during code reviews, tests or an external audit.

ASVS is organized into chapters covering all aspects of web development. These include architecture, design, authentication and ID management, sessions, access control, validation/encoding, cryptography, logging and error management, data protection, communications, code integrity, business logic, files/resources, APIs and configuration.

The OWASP organization even offers Cheat Sheets to better understand and manage controls in day-to-day operations.

Cheat Sheet OWASP

When to use one or the other

The Top 10 is for getting started or beginning to build a security culture by training developer teams, creating checklists and achieving quick wins in the short term.

But if we want to build more seriously and above all validate our work methodically, we need to integrate the ASVS into the SDLC, starting with the first level, then progressing as our maturity increases. Our maturity increases as the quality of our tools and procedures increases, and as they become rapidly repeatable.

Effort and costs

Top 10
Low cost for training, list, targeted corrections.

Rapid impact on basic hygiene, but beware: partial coverage of risks and little fine-grained traceability.

ASVS
Greater investment with selection of requirements, adaptation to SDLC, addition of tests (automated and manual), collection of evidence.

Reduced residual risk and greater demonstration of compliance for your customers and suppliers.

Why OWASP ASVS

OWASP ASVS provides a common language and a clear checklist for securing applications. For an SME, it’s a simple way to avoid blind spots, align the team and prove that security is taken seriously.

Standardize what counts.
ASVS offers a consistent set of requirements applicable to all your projects.

Cover all controls.
From authentication to session management, from data validation to cryptography, ASVS includes it all. By following it, we reduce the classic risks (SQL injection, XSS access control failures) that cause the majority of incidents.

Facilitate safety testing.
ASVS provides concrete verification criteria for manual and automated testing. These criteria can be integrated into quality assurance processes or continuous integration.

Increase developer maturity.
Guidelines make security more tangible for the team. They understand why a control is required and how to implement it correctly.

Improving safety posture.
With the ASVS standard, deviations are identified more quickly and dealt with before they become critical vulnerabilities.

Support regulatory compliance.
ASVS helps demonstrate that appropriate controls are in place, facilitating compliance. Demonstrate to customers and auditors that application security is managed in a structured way.

Reduce costs.
Correcting during development is much cheaper than rushing in after an incident. Preventing breaches also avoids fines, legal fees and lost business.

Gaining the trust of users.
More secure applications mean fewer security flaws. In a competitive market, this trust becomes a clear advantage.

How the levels work: L1, L2, L3

The ASVS proposes three levels of increasing priority for the 345 items.

• L1 (Level 1):70 controls (basic security, covering known risks and easy to test, for low-risk applications).
• L2 (Level 2): 183 controls (advanced protection for applications handling sensitive data).
• L3 (Level 3): 92 controls (maximum security required for critical applications, such as healthcare or financial applications).

The ASVS does not impose any particular level. It’s your risk analysis, the sensitivity of the application and the expectations of your users that should guide your choice.

What are “documented safety decisions”?

Documented safety decisions” means that everything the organization chooses in terms of safety and functions must be written down.

ASVS 5.0 calls for choices to be drafted, shared and traceable.

During the audit, we check that these decisions exist and are feasible, and that the code, configurations and processes apply exactly what has been decided.

Example: The first name field must be less than 50 letters long. When validating by integration, numbers must be rejected and more than 50 letters as well.

What the ASVS contains

The standard comprises 345 requirements in 17 chapters, each divided into thematic sections:

This structure allows you to choose what’s relevant to the context; for example, a machine-to-machine API will ignore “V3-frontend web” requirements.

The ASVS deliberately uses the word “requirement”: it states what must be true (“must”), not optional “shoulds”. The idea is to aim for clear, easy-to-understand safety objectives that are not tied to a specific technology, and this makes the verification method independent.

Other information

• According to ISO, over a million companies worldwide are ISO 9001 certified. It is the most widely used standard for demonstrating a structured management framework.
• I found a Harvard Business School study (2015) that showed that ISO 9001-certified organizations have a higher survival rate and 9% better financial performance on average.
• In Quebec, we have Innovation Québec, and some public tenders require quality certification, such as ISO 9001.

New version of the standard to come (Oct. 2025)

A new version of ISO 9001 is currently under development and will bring changes:

• Emerging technologies : Added issues on the integration of artificial intelligence and automation in quality processes.
• Ethics and integrity: a place in the leadership section, with explicit expectations in terms of transparency and organizational integrity.
• Risks vs. opportunities: clearer distinction in document and operational management, to avoid confusion and reinforce control of both aspects.
• Sustainability and ESG: introduction of sustainability objectives, with an emphasis on environmental and social impact, as well as customer satisfaction and stakeholder awareness.
• Evolution of the title: the standard will emphasize “guidelines for use”, with an explicit desire to provide practical support rather than just requirements.

In short, ISO 9001 is not a luxury. It’s a lever for increasing credibility and ensuring survival for any SME that wants to grow and retain the trust of its customers.

Deming put it this way: “Without data, you’re just another person with an opinion.”

In other words, documenting processes and learning from our mistakes builds trust. Conversely, without data and rigor, you’re just repeating the same problems over and over again.

The question is the same: will you take the quality of your products into your own hands?

History

• 2014 (1st edition): first publication of the “code of best practice” for cloud computing processors.
• 2019 (2nd edition): minor revision to correct and clarify the 1st edition.
• 2025 (3rd edition): Upgrade to align with the new ISO/IEC 27002:2022 standard, with new families of controls, attributes, etc.

What’s new in 2025

The new standard is aligned with the ISO27002:2022 version: controls are reorganized by theme (organization, people, physical, technological). Here are some examples:

• Threat watch (5.7) and ICT continuity preparedness (5.30);
• Configuration management (8.9), information deletion (8.10), data masking (8.11), leakage prevention (8.12);
• Activity monitoring (8.16), web filtering (8.23), secure coding (8.28).

New “public cloud and PR” controls: ISO/IEC 27018 adds implementation guidance specific to public cloud services for several controls, and adds information to Annex A when PR-specific expectations apply. For example:

• Identity management (5.16): provide customers with the means to create and remove user access;
• Logging (8.15): define who can see what, restrict access to logs containing PR, set retention periods and automatic deletion;
• Cryptography (8.24): describe the key management services (KMS), security hardware modules (HSM) and bring-your-own-key (BYOK) options available, as well as key management choices;
• Backups (8.13): clarify who (you or your customer) is responsible for copies, restoration, testing and where replicas are located.

A new Appendix B is a 2019 → 2025 correspondence table to match the old standard with the new one.

Integrate PR requirements right from the start, and clearly define responsibilities in contracts (customer, supplier, subcontractors).

Updated content and references (including ISO/IEC 29100:2024) to better reflect current cloud usage and privacy expectations. The standard is not a law, but it better aligns with the RGPD and Law 25.

More measures to support the customer in collecting, modifying and withdrawing consent, with preservation of proof and operational effect (e.g. immediate cessation of an e-mail after withdrawal).

Increased need for logging of accesses, deletions and modifications to PR, for justification of actions and for availability of electronic traces useful for audits and requests from individuals.

Controls consistent with a “Zero Trust” approach: implementation of least privilege, separation of environments, visibility on transfers and control of subcontractors, including for cross-border transfers.

Clarification and distinction between controller (customer) and processor (supplier), better documented and contractualized throughout the subcontracting chain, with audit trails to demonstrate responsibilities.

Change vocabulary, structure and clauses to better harmonize and facilitate assessments and recognition of compliance with privacy standards and laws worldwide.

Examples of specific “27018” controls

Here are a few examples of ISO27018 requirements

1) A.2.1 – Consent and choice
The processor must support the customer in obtaining valid consent, allowing its modification or withdrawal, and keeping proof of these decisions.
Therefore, a granular consent screen (by purpose), a preferences page accessible at all times, a record of decisions with timestamp and user identity, and automatic updating of processing (e.g., stop sending marketing emails as soon as consent is withdrawn) are required.

2) A.10.1 – Notification of PR breaches
All incidents must be evaluated to determine whether a PR breach has occurred; the customer must be notified promptly with the information required for his legal obligations.
In concrete terms, therefore, the organization must have an incident procedure with criteria (severity, types of PR affected), notification of the customer within a defined timeframe (e.g. 24 to 72 h), incident log, sample message that specifies cause, scope, measures taken and recommended actions to the customer.

3) A.11.8 – Mandatory unique identifier
Access must be assigned individually; shared accounts are to be avoided to ensure traceability.

4) A.12.1 – Location of PRs
The processor documents where PRs are processed and stored (production, backups, backup), and keeps this information up to date.

5) A.5.1 – Deleting temporary files
Temporary files containing PRs should be deleted when they are no longer required.

Quick checklist

Answer Yes or No to each question.

1. Does your SoA reflect the 2025 structure (chapters 5 to 8) and the relevant PR controls?
2. Do you offer your customers the means to exercise their rights (portal and API, clearly defined deadlines)?
3. Do you keep an up-to-date register of subcontractors, including locations and guarantees?
4. Do your contracts include standardized PR clauses (purpose, prohibited use, audit, notification, retention/erasure, localization)?
5. Does identity management provide for customer delegation, a complete lifecycle (creation-modification-end) and periodic validation?
6. Does the logging limit access by organization, include periodic reviews, automatic retention and purging rules?
7. Are your deletion procedures tested (production and backups), with published deadlines and proof of deletion retained?
8. Do you have an inventory of Key Management Service (KMS), Hardware Security Module (HSM) and Bring Your Own Key (BYOK) options, and is the key management policy communicated to customers?
9. Do your backups and restores have defined and tested OTR/OPRs, with documented locations?
10. Does your incident process qualify a PR breach according to clear criteria, with intervention guides for notification and up-to-date records?
11. Do test environments prohibit PR, or do they use pseudonymized/masked data with rapid erasure?
12. Do you offer role-appropriate PR awareness training (consequences, prohibited gestures)?
13. Do you carry out privacy impact assessments (PIAs ) for transfers outside Quebec/Canada/EU, and do you have contractual safeguards in place?
14. Do you keep an up-to-date file of evidence (reports, captures, logs) and schedule an independent review?

In short, ISO/IEC 27018 version 2025 doesn’t reinvent the PR protection program; it updates practices to ISO27002:2022 and makes contractual commitments clearer.

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.

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.

A few pitfalls

Believing that backups are enough

A backup with no test, no restoration process, no network redundancy or alternative physical access = no guarantee.

An IT-only plan

The IT continuity plan affects finance, HR and customer service. Everyone is involved.

Copy and paste a generic plan

The standard insists on adaptation to the organization’s context (size, sector, specific threats). Copying a bank plan for an SME is pointless.

Ignoring suppliers

If you’re dependent on a hosting provider, SaaS provider or cloud service, your plan should incorporate their own plan. Demand contractual commitments (SLAs).

After reading the new version 2025 of ISO/IEC 27031, I think this is an important step forward.

It’s much clearer and I feel it’s closer to reality than it was. In short, it’s time to stop believing that continuity boils down to “we’ve got a backup somewhere”.

A true continuity plan ensures resilience, credibility and survival. And now you have a clear standard to guide you.

Link to ISO/IEC 27001:2022

There are several references to root cause analysis in ISO27001:2022.

• Clause 6.1.2 – Risk analysis and assessment for a clear understanding of threat scenarios
• Clause 9.1 – calls for the collection of reliable data and root cause analysis transforms this data into usable information for the future.
• Clause 10.2 – The main clause for managing non-conformities and creating corrective action calls for each NC to be evaluated to identify the cause and thus prevent recurrence.

The 5 Whys

The 5 Whys method involves repeatedly asking the question “Why?” to trace the symptoms of a problem back to its root cause.

By finding this root cause, we can apply corrective action that permanently eliminates the problem rather than masking its effects.

Its speed and simplicity make it a preferred tool in ISO-certified environments, because it’s simple and effective.

It has its limits when dealing with complex incidents where several independent causes interact.

How to perform a 5-Why analysis

1 – Clearly formulate the problem and write it down.
2 – Ask: “Why is this happening?” and write down the answer.
3 – Transform this answer into a new problem, then ask again: “Why is this happening?” and write down the new answer.
4 – Repeat the “Why?” question until no deeper explanation is possible; this is when the root cause is discovered.
5 – If several causes appear along the way, keep them: a single problem can have several root causes.

Fishbone Diagram (Ishikawa diagram)

The Ishikawa diagram provides a visual representation of the effect (“center edge”) and its potential causes, grouped by category (Material, Methods, Manpower, Environment, Measures, etc.).

It is recommended when an incident results from multiple interactions – typically a process failure or human error coupled with faulty technical control.

Its strength lies in stimulating collective reflection, which is useful in workshops involving several stakeholders. Its limitation is that it maps hypotheses; a validation stage is required to confirm the root cause.

It’s especially useful when a problem has several potential causes and you want to structure collective thinking.

How to create an Ishikawa diagram

1. Define the problem or effect to be analyzed. For example: understand why a series of pumps delivered to a customer frequently has defects.
2. Draw the skeleton of the diagram. In the center of the page, draw a horizontal arrow pointing to the right, representing the fish’s backbone. At the end of the arrow, like the fish’s head, write the problem statement (e.g.: common pump faults) and frame it.
3. Identify the main categories of causes. Starting from the central edge, draw oblique branches that will act as ribs. Ishikawa proposed the “6 M’s”, but encouraged the adaptation of titles to better speak to teams:

Materials: parts, ingredients, supplies.

Machinery: production equipment, handling devices, software (in some sectors, this category may be split).

Methods: procedures, techniques, processes, regulations (especially for public administration or highly regulated industries).

Measurement: key indicators, measuring instruments, data collection points.

Workforce: people, human resources, training, skills.

Milieu (Mother Nature): environment and external factors.

We sometimes add a seventh “M”: Money, i.e. operating expenses and investments.

4.explore possible causes. Based on these categories, ask: “Why is this happening?” and note each plausible cause under the appropriate branch, keeping it concise. The same cause can appear in several places if it concerns several categories.

5. Refine by iteration. Go back to each cause and ask the question “Why?” to reach deeper levels; trace sub-causes as secondary branches. The stacking of branches reflects causal relationships.

6. Complete the brainstorm. When ideas dry up, focus on branches where there are fewer causes; this may reveal overlooked factors.

7. Analyze and prioritize. Examine all the causes identified to determine which deserve action. Keep in mind that the aim is to treat the root cause, not the symptoms. It may be useful to redraw the diagram to clarify the presentation before the final analysis.

Fault Tree Analysis

FTA builds a logic tree where the undesirable event is the root and the causes are deployed using AND/OR logic gates.

This analytical approach is suitable for critical technical events, such as a major downtime of a security service.

It does, however, require statistical skills, and can become cumbersome for smaller structures.

How to create FTA (Fault Tree Analysis)

1. Clearly identify the main problem to be analyzed and define its limits.
2. Gather all relevant information about the system, and consult the relevant experts.
3. Build the tree by linking the root causes to the main problem using logic gates.
4. Analyze the paths in the tree to understand the relationships between the causes and the problem.
5. Identify the events and critical paths that most influence the probability of the problem.
6. Develop strategies to mitigate risks by acting on critical causes.
7. Document the complete analysis and share it with stakeholders.
8. Monitor the effectiveness of the measures put in place and update the tree regularly.

Causal Factor Tree Analysis

CFTA details each contributing event and its causal factors in a chronological tree.

This can be a lengthy process, requiring precise information on the chronology of events.

How to create a causal factor tree analysis.

1. Define the problem: Write down clearly what happened (the main incident or problem).
2. Information gathering: Gather information about what happened, how the system works and validate with the people involved.
3. Draw the tree: Note the events that led to the problem and connect them like a tree, with arrows to show the link.
4. Analyze links: See how events are connected and understand their sequence.
5. Identify important points: Find the causes that have had the greatest impact.
6. Look for solutions: write down ideas to prevent it from happening again.
7. Monitor and improve: Check later if the solutions are working, and update the tree if necessary.

Change Analysis

This method compares the normal state of a system with the state at the time of the incident, in order to highlight the changes that may have introduced the non-conformity.

It is particularly relevant for agile or highly virtualized environments where updates are frequent.

Its strength is to quickly target a poorly controlled change, in line with the spirit of the Change Management clause (ISO 27002-5.33), even if it depends on a reliable configuration register.

How to do a change analysis

1. Define the system: Clearly identify what is being analyzed (process, equipment, configuration, etc.).
2. Describe the state before: Note how the system worked before the change.
3. Describe the state afterwards: Note what has been changed or added.
4. Compare the two states: Identify the differences between before and after.
5. Identify impacts: Find out what these differences have caused (problems, errors, improvements).
6. Assess: Ask why these impacts have occurred and how to manage them.
7. Document the analysis: Write a summary of observations and conclusions.
8. Suggest actions: Suggest adjustments or corrections if necessary.

Barrier Analysis

Barrier analysis examines existing controls – physical, technical, organizational – and determines which have failed or are missing.

It also draws on the Swiss cheese model, assessing why several layers of protection weren’t enough, and why a barrier that was supposed to stop the incident, such as a concrete wall protecting cyclists, didn’t work as intended.

This method is recommended when the incident highlights insufficient defense in depth.

It can also be used to understand what prevents individuals from changing or adopting a new behavior.

How to perform a barrier analysis

1. Identify the incident or risk: clearly define what you want to protect, avoid or change.
2. List existing barriers: note any controls or safeguards in place (technical, human, organizational).
3. Check the effectiveness of the barriers: assess whether they are working properly and whether there are any loopholes.
4. Identify failures or gaps: look for what has failed or what is missing as a barrier.
5. Suggest improvements: suggest ways of reinforcing or adding barriers.
6. Document the analysis: write a clear summary of the results and recommended actions.
7. Monitor corrective actions: check that improvements are implemented and that they are effective.

Risk Tree

The Risk Tree is similar to the FTA, but applies a risk-oriented logic rather than pure failure.

It is used to map the combination of events leading to an unacceptable risk.

In an ISMS, it sheds light on the interaction between threats, vulnerabilities and impacts, helping to prioritize corrective actions.

Its complexity grows rapidly with the number of risk factors, and can exceed the analysis capabilities of small teams.

How to create a risk tree

1. Clearly define the risk or event you wish to analyze.
2. Identify all possible causes that could lead to this risk.
3. Break down each cause into sub-causes to better understand the origins of the risk.
4. Identify the possible consequences if the risk occurs.
5. Look for controls or barriers already in place to reduce or control the risk.
6. Represent everything in the form of a tree, linking causes, sub-causes, consequences and controls.
7. Analyze the tree to identify critical areas and decide on preventive or corrective actions.

Parent Analysis

Parent Analysis groups incidents according to common parent categories (process, technology, behavior) to identify structural trends.

It is used when several similar incidents occur over time.

Its strengths lie in the macro view it offers CISOs, useful for guiding continuous improvement plans, but its weakness is that it provides a brief and potentially hidden view of the specific items involved in a particular incident.

How to do a parent analysis

1. Incident collection
   Collect all security incidents over a given period, making sure to include enough data to detect recurring patterns.
2. Categorization of incidents
   Classify each incident into a parent category according to a common criterion: Process (e.g. failure in a procedure) Technology (e.g. vulnerability in a system or software) Behavior (e.g. human error, successful phishing)
   This step is crucial for structuring the analysis and identifying root causes.
3. Grouping similar incidents
   Group incidents that share the same parent category to highlight recurring trends or weaknesses.
4. Structural trend analysis
   Examine groups of incidents to understand common underlying causes, such as process flaws, technological shortcomings or risky behavior.
5. Macro summary for decision-makers
   Present a global view of trends, to guide continuous improvement plans and mitigation strategies.

Failure Mode and Effects Analysis (FMEA)

The FMEA lists each component of a process or asset, describes its possible failure modes and assesses their effect, severity, probability and detectability.

It is ideal for environments where safety depends on critical equipment or repetitive processes.

Source: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis

How to perform failure mode analysis

• Identify the process, product or system you wish to analyze.
• List process steps or product components.
• Determine possible failure modes (how it can fail).
• Identify the effects of each failure (what can happen if it fails).
• Assess the severity of each effect (from slight to critical).
• Identify the possible causes of each failure.
• Evaluate the probability of occurrence of each cause.
• Check whether controls or detections already exist, and assess their effectiveness.
• Calculate the “Risk Priority Score” (RPN) by multiplying severity × occurrence × detection.
• Prioritize corrective actions according to the highest scores.
• Document the analysis and monitor the improvements implemented.

Management Oversight and Risk Tree (MORT)

MORT is a root cause analysis method developed to investigate major events, such as industrial accidents, operational failures or safety incidents. It is different from the others:

• It doesn’t just analyze technical or human failures.
• It explores the flaws in management, supervision, decision-making and organizational systems that made the incident possible.

It seeks to answer both these questions:

1. What went wrong technically and operationally?
2. What allowed these failures to go unanticipated, undetected and uncorrected?

the MORT approach rests on two pillars:

• A logical, structured tree linking all levels of causes.
• A management assessment model that identifies systemic problems, not just visible symptoms.

How to do a simple DEATH analysis

1. Define the event or incident to be analyzed
   Be specific: nature, date, location, impact.

2. Collect data
Gather reports, interviews, recordings, procedures, logs… and create a complete picture.

3. Build the DEAD tree –Place the main incident at the top, Plug in the immediate causes (e.g. breakdown, human error, material defect) and Develop downwards the root causes (e.g. lack of training, poor quality control, managerial decisions, poor communication).

4. Explore two main areas
Control failures: Why the planned measures did not work.
Management weaknesses: Why the organization failed to prevent or correct these problems.

5. Use prioritization codes (in the complete approach)
As seen in classic MORT, use visual codes to distinguish: What is under control – What is uncertain – What represents a critical weakness.

6. Identify latent conditions
Conflicting priorities, unclear objectives, lack of leadership, performance culture at the expense of safety.

7. Formulate robust corrective recommendations

To correct technical failures, strengthen supervision, processes, culture and policies, and implement indicators to monitor changes.

Conclusion

The choice of root cause analysis method should reflect the severity and complexity of the incident, the maturity of the ISMS and the resources available.

A simple situation should use the five whys method.

Conversely, a complex or recurring incident may justify the use of tree-based approaches such as FTA, CFTA or MORT, to reveal technical and organizational interdependencies.

Whichever tool is chosen, integrating the RCA into the PDCA cycle reinforces continuous improvement, ensures the sustainability of the corrective actions provided for in clause 10.2, and ultimately consolidates the robustness of the ISMS in the face of current and future threats.