If tiering decides how much scrutiny each supplier receives, how should an organisation define its tiers (for example by the sensitivity of the data, the level of access and how critical the service is to operations), and how can it make sure that a supplier is moved to a higher tier when its role changes over time, such as a low-risk tool that gradually gets access to customer data, so that the depth of diligence, contract and review always matches the risk the supplier actually carries?

If FIDO2 keys and passkeys resist phishing structurally while SMS codes and authenticator-app codes do not, how should an organisation decide which MFA method to require for which users and systems (for example administrators and the customer database versus ordinary staff and low-value systems), and how should it handle the practical problems of rolling out stronger methods, such as lost keys, account recovery and users who fall back to weaker methods that an attacker could then exploit?

if the board owns the risk appetite statement and the security function applies it, how can the organisation make sure that this division of roles works in practice, so that the board receives the information it needs to judge whether the appetite is still right (for example reports on accepted risks, exceptions and near-breaches of the stated lines), and so that the security function is not left making ad hoc judgement calls when the statement turns out to be too vague for a real decision?

If a badly drawn scope can leave a threat avenue unexamined, how should an organisation draw the audit scope so that it covers the real risk areas without gaps (for example by using its risk register and the value-threat-vulnerability-control model), and what should happen when the auditors and the audited unit disagree on what belongs inside the scope, given that the audit charter is meant to protect the audit function’s independence?

DORA applies to financial entities, but its demands on resilience, testing and documentation reach their ICT providers too. How should a financial entity prove to a supervisor such as Finanstilsynet that it is actually resilient (through dated evidence of exercises, tests and incident handling), rather than just compliant on paper, and how should it handle its dependence on a few critical cloud and software providers whose failure could be systemic?

If nudging and good design can change behaviour without anyone having to remember a rule, how should an organisation decide which security behaviours to handle through design (such as MFA on by default or a one-click Report button) and which still need training, and how would it measure whether a nudge is actually working so that the awareness programme and control selection really are treated as one conversation?

If a gap table is only a snapshot of one moment, what should determine the rhythm at which it is re-taken (for example fixed intervals versus triggers such as a new system, a major incident or a change in the threat picture), and how would you make sure that each new version is compared with the previous one so that the organisation can show that gaps are actually closing over time?

If an exercise creates value by training the people, and not only by exposing flaws in the document, what must an exercise include so that those who will actually handle an incident (not just the IT department or the preparedness lead) get to practise their own role, and how can an organisation document that this has happened, so that an auditor can see evidence of operating effectiveness and not merely design effectiveness?

If accountability always stays with the organisation, what can it realistically recover from a supplier that causes a breach? Contracts often cap liability or exclude indirect losses, so the fine and the loss of trust may exceed what the supplier pays. Should the contract and the risk assessment treat the gap between accountability and recourse as a residual risk that someone has to accept

NIST dropped forced rotation in 2017, but what should an organisation do if a customer contract, an auditor’s checklist or an older standard still requires regular password changes? Should the policy follow the evidence and document the deviation with a justification, and who has the authority to approve that deviation?

How is the threshold kept fixed in practice? If many risks land above the line in one cycle and the budget is limited, there is pressure to move the line instead of the risks. Should the board approve the appetite statement before each assessment cycle, and who is allowed to change it mid-year, with what record?

If a full-population test is possible for anything that leaves a machine record, should it replace sampling for those controls? The text says the analysis is only as good as the question asked of the data, so how does the auditor show that the data extract is complete and that the log source itself was not altered? Does the audit trail need a step for validating the data before the test?

The procedures are written by the first line, and the records (tickets, logs, sign-offs) are produced by the same people who do the work. Who checks that the records are complete and true between audits, especially in a small organisation without an internal audit function? Is a periodic sample by the second line enough, and how often should it run

If MFA only protects the login, which controls protect the session once a token is stolen? The case names short session lifetimes and alerts on new sessions, but how short is short enough without making staff log in so often that they look for workarounds? And who decides the session policy, security or the business?

Who decides when a patch is allowed to deviate from the CVSS order, and where is that decision recorded? The example says the reasoning must be written down, but if the patch policy sets deadlines by CVSS band, the 7.5 on the checkout could break the policy while the 9.8 on the test machine is within it. Should the policy include a rule for deviations that cites value, exposure and existing controls?

If preparedness is a corrective control, how should it be rated in the risk register? Does it lower the consequence score and leave likelihood unchanged, and who signs off that the lower rating is deserved?