The text tiers four suppliers, but the register in Table 19.4 has no carrier row, so one important supplier is unmanaged. Also, §19.2 says the payment processor needs PCI DSS plus an ISAE 3402 or SOC 2 report, yet the register lists only PCI DSS under Assurance. The register should match the text.

Section 19.4 says our clocks start on our awareness, so is the supplier’s 24-hour window the right target? NIS2 already requires an early warning within 24 hours of awareness, so a 24-hour supplier notice leaves almost no margin. Should the clause be shorter for critical suppliers, such as ‘without undue delay’ or 12 hours?

$18.3 says a policy that requires unique passwords without providing a password manager ‘writes Chapter 14’s workaround into its own policy’. But the policy table has no uniqueness rule and no password manager row. It should add both.

This describes a strength, not a weakness. What are the real weaknesses of passkeys, such as a lost device or the account-recovery path? For a small company like ours, which would we need to plan for?

$17.2 says checkout outages over one hour are unacceptable, which sounds like a limit per outage. Table 17.2 uses one hour per quarter as the escalation tolerance. The appetite and the tolerance should use the same unit, and the table should say whether it means per outage or per quarter.

How should a company without margin figures, like our case company, estimate capacity? Should we use an assumption such as a share of annual revenue, or is it fine to leave capacity as a qualitative statement?

Applied to Nordic Phone’s rule ‘MFA for CRM and email’: design test = inspect the identity-provider configuration, effectiveness test = sample 25 logins from the log. The effectiveness test would catch admin or legacy logins that skip MFA, which the design test alone misses.

Does this list match ISO 19011:2018? I think the 2018 edition adds a seventh principle, the risk-based approach, which would fit the ‘risk-based’ planning described in the same section.

Example 15.3 adds records as a fourth layer of the evidence chain, but Definition 15.1 has no place for them. Are records part of the document hierarchy, or a separate evidence layer? I wrote a policy, two standards and a procedure for Nordic Phone and wasn’t sure where to put the tickets and logs.

Definition 15.2 and Table 15.3 say four binding pillars plus one voluntary one (Art. 45). ‘Five pillars’ contradicts that, so the text should say ‘four binding pillars and a voluntary fifth’.

Applied to Nordic Phone (35 staff): I used three messages (Report button, MFA by default, check ID), measured click rate, reporting rate and time to report, and owned it by the Operations Manager. Staff who register subscriptions needed their own topic (ID fraud), like finance in this example

Table 14.1 lists five triggers, including commitment, and the opening of §14.1 names six. Definition 14.1 and the summary list only four, so the definition should say ‘for example’ or include commitment.

$13.2 says a loss of the customer database hits all three CIA properties at once, but this example rates availability as medium. One of them needs fixing. The summary also says ‘Chapter 9’s actors’ while $13.2 uses Chapter 8’s actor ladder (Table 8.10)

Applied to Nordic Phone’s R3: ‘no MFA, limited monitoring, low phishing awareness’ rewritten as missing controls 8.5, 8.16 and 6.3 gave a direct to-do list (gaps 1–3). This turned a vague ‘weak authentication’ risk into three owned actions.

Applied to Nordic Phone: customer verification/D1 gets RTO 3 h and subscription activation 4 h, so the dependency rule holds, and payment gets 2 h / 5 min. This worked only after I lowered the database RTO below the activation RTO.

This conflicts with the paragraph after Table 12.1. The checkout (RTO 1 h) depends on the customer database (RTO 4 h), and a component can’t recover faster than what it depends on. Either the database RTO should be 1 h or less, or the table should name the checkout fallback.