Organisational Context and Risk Strategy for AI in Cyber Defence

A security strategy rests on an account of what the organisation exists to do and depends on, and a decision about how much risk it will take in pursuit of that purpose. AI changes both: it enters the context as an asset and as an adversary's capability, and the risk strategy as software that drafts and sometimes executes security actions. An organisation that has not written down how much error it tolerates from that software, how far it may act without a person, and which assumptions about attackers no longer hold, has delegated those decisions to its vendors and its adversaries.

This chapter is responsible for two Categories of the Govern Function of NIST CSF 2.0: GV.OC Organizational Context, the understanding of the mission, stakeholder expectations, dependencies and legal, regulatory and contractual requirements that surround cybersecurity risk decisions, and GV.RM Risk Management Strategy, the priorities, constraints, risk tolerance and appetite statements and assumptions that support operational risk decisions (19, NIST, 2024). It treats both through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025), and ends with a risk-appetite statement written as code, with autonomy ceilings per usage mode and the changes that trigger its review.

From context and assumptions through risk appetite and strategy as code to autonomy ceilings per usage mode

Figure 5.1: From context and assumptions through risk appetite and strategy as code to autonomy ceilings per usage mode.

Mission, stakeholders and obligations

GV.OC makes the context of risk decisions explicit, so that each can be traced back to what the organisation is protecting and for whom.

What GV.OC asks for

CSF 2.0 expresses Organizational Context as five outcomes (19, NIST, 2024): the mission (GV.OC-01), stakeholders and their expectations (GV.OC-02), legal, regulatory and contractual requirements, including privacy and civil liberties (GV.OC-03), the critical services others depend on (GV.OC-04), and what the organisation itself depends on (GV.OC-05). None of these outcomes mentions AI; what changes is the content. A regional authority now depends on AI assistants and on security AI that triages the alerts protecting them, and the context record must name those systems as dependencies under GV.OC-05, and the security AI the organisation operates as a capability others rely on under GV.OC-04, because a SOC that depends on an AI triage assistant has a single point of failure it did not have before.

AI as an asset and as a threat in the context

In practice the context record needs four additions when AI is in scope.

AI systems the mission depends on, with their usage mode, owner and risk classification. Following AI Platform and Security, Chapters 18 and 25, these are both assets to protect and sources of threat to contain: every AI system is designed twice (73, Nordqvist, 2026).
Security AI the defence depends on, from vendor verdicts and embedded assistants to triage agents and the AI that the managed security service provider (MSSP) uses on the organisation's telemetry, much of it arriving as ambient AI inside a product bought for another reason.
Suppliers of models and AI services behind both groups, and their jurisdictions. Chapter 8 develops the supply-chain controls; the context record only makes the dependency visible.
Adversaries who use AI, taken from the threat profile of Chapter 2. A context that names the organisation's adversaries without stating that they use AI describes a threat that no longer exists.

Here the organisation decides that its security AI falls under the same risk management as every other system, not an exception granted because it serves defence.

Under GV.OC-02 the stakeholder list for security AI is long, because it reads telemetry about people and may act on their accounts: employees and their representatives, residents and customers whose data appears in alerts, supervisors, and the vendors and MSSP whose AI acts on the organisation's behalf.

Obligations that shape the context

GV.OC-03 is where European law enters. The obligations below are attributed to NIS 2 (3, European Union, 2022), DORA (2, European Union, 2022) and the AI Act (1, European Union, 2024), and their implications are architectural, not legal advice. Chapter 3 maps the whole of CSF to these instruments; the table records only what bears on context and risk strategy.

Instrument	Provision	Implication for context and risk strategy
NIS 2 Directive	Article 20	Management bodies approve and oversee the measures; the risk strategy needs an owner at that level
NIS 2 Directive	Article 21	Measures cover supply-chain security and effectiveness assessment, including for security AI and its suppliers
DORA	Articles 5 and 6	The management body owns ICT risk; the ICT risk tolerance follows the risk appetite
DORA	Article 28	The register of information covers AI services and security providers
AI Act	Article 3 and role-based obligations	Provider or deployer role known for each security AI system

Because responsibility sits with the management body under both NIS 2 and DORA, an appetite the CISO sets alone is incomplete, and because obligations differ by entity, the context record must say which applies where.

Risk appetite for AI in defence

GV.RM asks for agreed risk management objectives (GV.RM-01) and for risk appetite and tolerance statements that are established, communicated and maintained (GV.RM-02) (19, NIST, 2024). For security AI the appetite has three dimensions: error, autonomy and reversibility.

Risk appetite is the broad amount of risk accepted; risk tolerance is the measurable variation around it that triggers action. The NIST AI Risk Management Framework treats risk tolerance as contextual and does not prescribe it (16, NIST, 2023), and DORA requires financial entities to set an ICT risk tolerance in line with their appetite (2, European Union, 2022). For security AI, the appetite is a short statement the management body can read; the tolerances are numbers a pipeline can check.

Error tolerance

Every security AI makes mistakes, and so does every analyst; the strategy decides which mistakes, at what rate, and who catches them. A triage assistant whose drafts an analyst checks can be tolerated at a higher error rate than an agent that isolates an endpoint before anyone reads the alert. The statement should therefore express error tolerance per use case and autonomy level, measured on the organisation's own evaluation set rather than a vendor's benchmark, and name the action on breach: the level falls automatically by one until the owner has investigated. Because alert content can be crafted to steer the model (14, OWASP, 2025), a property of the architecture according to AI Platform and Security, Chapter 16 (73, Nordqvist, 2026), tolerance measured only on benign inputs overstates performance under attack; Chapter 13 supplies the adversarial share of the evaluation set.

Autonomy ceilings

The second dimension is how far security AI may act without a person deciding each action. Chapter 6 defines five autonomy levels, from Level 0 Advisory to Level 4 Autonomous, and the six usage modes. The risk strategy turns those definitions into a ceiling: the highest level that any security AI in a given mode may reach without a decision of the management body. A ceiling is not the level a system runs at but the limit within which the AI governance board or the CISO may raise a level on evidence; above it, a proposal is risk beyond appetite.

Ceilings follow the mode, which determines who catches the error. Figure 5.1 shows a typical pattern: Modes 1 and 2 at Level 0 Advisory or Level 1 Assisted, since a person checks every output and the AI acts with that person's identity; Modes 3 and 4 up to Level 2 Supervised; and Mode 5 at Level 3 Bounded only for catalogued, reversible actions. Two limits hold whatever the mode. Level 4 Autonomous is never used for offensive or irreversible actions, and Mode 0 features that act automatically are brought inside the appetite by asking vendors to declare them, so that the organisation decides the ceiling rather than discovering the level afterwards.

This answers, at the level of strategy, the open question of when a defensive AI may act without per-action approval and who decides: the management body sets the ceiling, and a named forum raises systems within it on evidence. In the tiers of AI Governance, Chapter 13, from pipeline gates to the management body (72, Nordqvist, 2026), the ceiling marks the boundary between the AI governance board and the management body.

Reversibility and blast radius

The third dimension is the consequence of an action that goes wrong. Isolating one workstation is reversible within minutes, changing a shared firewall rule only with effort, and some actions on evidence or production data not at all. The strategy ties these classes to the ceilings: Level 3 Bounded only for reversible actions on a bounded number of targets, Level 2 Supervised where reversal takes effort, and nothing above Level 1 Assisted for irreversible actions. AI Governance, Chapters 19 and 25, concluded that agents should be governed as well-meaning insiders, because only boundaries set a ceiling on the consequences of unwanted behaviour (72, Nordqvist, 2026); reversibility and blast radius are where the risk strategy sets those boundaries.

The CISO and the chief risk officer propose the appetite and the management body approves it; the AI governance board sets the ceilings within it, after consulting employee representatives where AI may act on employees' accounts, and use-case owners own the tolerances.

Practical guide: Writing a risk-appetite statement for security AI

Purpose. Produce a short, enforceable statement of how much risk the organisation accepts from AI used in its own cyber defence, with tolerances a pipeline can check and ceilings per usage mode.

Roles. CISO (author), chief risk officer (co-author), use-case owners, data protection officer, employee representatives where relevant, and the management body (approver).

Steps.

List every security AI in the context record, including Mode 0 features and the MSSP's AI, with its usage mode, current autonomy level, owner and identity.
Classify the actions each one can take as reversible within minutes on a single target, reversible with effort, or irreversible.
State the appetite in one paragraph, in terms of consequences rather than technology.
Set an autonomy ceiling per usage mode, with the two fixed limits on Level 4 Autonomous and on undeclared Mode 0 actions.
Set error tolerances per use case and level on the organisation's own evaluation set, including adversarial cases, and name the automatic step down on breach.
Name the review triggers, such as a new system, model version, mode or level change, incident, red-team finding or supplier change.
Link the statement to the risk register and record its approval as a versioned decision.

Default values to adapt. A missed-threat rate of at most 2 per cent on the evaluation set for anything at Level 2 Supervised or above; automatic step down by one level on breach; a review opened within five working days of a trigger; and a calendar backstop of twelve months, which should rarely be the reason a review happens. Adapt these to the organisation's risk appetite and alert volume.

Definition of done. The statement is approved and versioned, every security AI has a checkable ceiling and tolerance, and a test change opens a review automatically.

Risk assumptions under AI-enabled threats

AI-enabled attacks invalidate several of the strategy's assumptions about the adversary, which should be revised explicitly rather than discovered in an incident.

The exploitation window

Mandiant found that the average time between disclosure of a vulnerability and its exploitation fell to days in 2023, with a growing share exploited before a patch was available (44, Charrier & Weiner, 2024); AI Platform and Security, Chapter 18, traced how AI compresses the window further (73, Nordqvist, 2026), a shift the Five Eyes agencies also describe (39, Five Eyes agencies, 2026), and the UK National Cyber Security Centre has advised organisations to prepare for a coming wave of patches (38, NCSC, 2026). AI Governance, Chapter 24, drew the strategic consequence: patch decisions for known-exploited vulnerabilities must be delegated in advance, because a weekly change advisory board cannot sit in their path, and patch velocity belongs in management reporting as a risk indicator (72, Nordqvist, 2026). The revised assumption is that exposed, known-exploited vulnerabilities are under attack now. The Exploit Prediction Scoring System (26, FIRST, n.d.), the CISA Known Exploited Vulnerabilities catalogue (27, CISA, n.d.) and ENISA's European Vulnerability Database (28, ENISA, 2025) give the strategy measurable inputs, which Chapter 11 turns into an exposure-management practice.

Synthetic media and trust in identity

Many processes still treat a familiar voice, a face on a video call or a well-written email as evidence of identity. In 2024 a Hong Kong employee of the engineering firm Arup was deceived in a deepfake scam that cost the firm about USD 25 million (55, Magramo, 2024). For decisions that move money, change payees, reset credentials or approve security exceptions, the strategy should therefore state that recognition is not verification, and require verification through a channel the requester does not control. Identity and approvals that resist synthetic media, one of the commitments of AI Platform and Security, Chapter 18, is a risk-strategy decision before it is a control (73, Nordqvist, 2026); Chapters 14 and 15 develop the controls and training.

Scale

Strategies built for human adversaries assume that targeted attacks are expensive and therefore rare. The UK National Cyber Security Centre assessed that AI will continue to make elements of cyber intrusion more effective and efficient up to 2027 (37, NCSC, 2025), and in June 2026 the Five Eyes agencies jointly urged leaders to act on the shift AI brings to cyber risk (39, Five Eyes agencies, 2026). In July 2026 ECB Banking Supervision wrote to the chief executives of the significant institutions it supervises on addressing AI-enabled cybersecurity threats (7, ECB, 2026), a signal that supervisors expect these threats in the risk strategy and not only in operational plans.

Revising the assumptions

Assumption	Earlier basis	Revised basis	Consequence for the strategy
Time to exploit	Weeks; monthly patch cycle	Days or less for exposed, known-exploited vulnerabilities	Delegated patch authority; patch velocity as a reported risk indicator
Trust in voice, video and writing	A known person can be recognised	Recognition is not verification	Out-of-band verification for high-impact decisions
Volume of targeted attacks	Expensive, therefore rare	Cheaper, therefore more frequent	SOC capacity planned with AI assistance
Security tooling	Deterministic, behaves as configured	Contains AI that changes with model versions and reads attacker-controlled input	Security AI in scope of risk management and red teaming
Adversary speed	Human working pace	Machine pace for parts of the operation	Detection and containment at machine speed within autonomy ceilings

GV.RM-04 asks that strategic direction describing appropriate risk response options is established and communicated (19, NIST, 2024); the last column of the table is that direction for AI-enabled threats.

Risk strategy as code

Context, appetite and assumptions become versioned, reviewed and checked artefacts.

Risk records and appetite statements

Architecture as Code (Chapter 9C) established that risk is a versioned record with a likelihood, an impact, an owner and expiring exceptions, and that a failing control metric fails the pipeline (71, Nordqvist, 2025). Applied to the risks AI adds, each revised assumption becomes a risk record, including manipulation of security AI and dependency on a vendor model that changes without notice. GV.RM-06 asks for a standardised method for calculating, documenting, categorising and prioritising cybersecurity risks (19, NIST, 2024); a schema enforced in the pipeline is that method in executable form. Nordvik Region's record NR-RISK-2027-014, for example, covers exploitation of internet-facing services within days of disclosure, links it to a delegated patch decision for known-exploited fixes on its inference platform and to the exposure prioritisation of NR-SEC-003, and reports days-to-fix as an indicator to the regional director.

The appetite statement is versioned beside the risk records, so that a deployment above a ceiling fails the pipeline and an evaluation outside tolerance lowers the level. Moreover, the policy decision point that AI Platform and Security, Chapter 4, placed between security AI and its tools can read the statement (73, Nordqvist, 2026), so that a ceiling is enforced at run time and not only at deployment.

Change-triggered review

AI Governance, Chapter 8, concluded that classification is triggered by change, not by the calendar (72, Nordqvist, 2026). The same holds for the risk strategy, because vendors update models and the threat profile shifts: the statement names its triggers, the pipeline opens a review when one fires, and the calendar backstop only catches triggers the organisation failed to define.

Worked example: Risk-appetite statement as code with autonomy ceilings and review triggers

The illustrative statement below is Hansa Mutual's. Note the difference between ceilings and running levels: HM-SEC-001 runs at Level 2 Supervised, and the statement allows the board to raise it to Level 3 Bounded for two named, reversible actions once the evidence supports it.

# Illustrative: Hansa Mutual, risk appetite for security AI
kind: RiskAppetiteStatement
id: HM-RAS-SECAI
version: 2.1.0
approval:
  approvedBy: executive-board
  recommendedBy: [group-ciso, chief-risk-officer]
  ceilingsSetBy: group-ai-governance-board
  date: 2027-01-20
appetite: >-
  Security AI may act faster than people where actions are reversible
  and bounded. No unreviewed action may interrupt a customer-facing
  service or delete evidence.
fixedLimits:
  level4: never-for-offensive-or-irreversible-actions
  mode0AutomaticActions: only-if-declared-by-vendor-and-listed
autonomyCeilings:
  mode1: level1-assisted
  mode3: level1-assisted        # isolated ranges only, no production credentials
  mode4: level2-supervised
  mode5:
    default: level2-supervised
    level3Bounded:
      useCase: HM-SEC-001
      actions: [isolate-single-endpoint, disable-session-token]
      maxTargetsPerHour: 5
  entityOverrides:
    employeeRepresentationPending: level1-assisted
errorTolerance:
  HM-SEC-001:
    missedThreatRateMax: 0.02
    falseContainmentRateMax: 0.01
    evaluationSet: hm-sec-eval-2027-q1   # includes adversarial cases from HM-SEC-003
    onBreach: step-down-one-level
reviewTriggers: [new-security-ai-registered, model-version-change, mode-or-level-change,
  incident-involving-security-ai, red-team-finding-against-security-ai, supplier-or-mssp-change, regulatory-change]
reviewOpenedWithin: P5D
calendarBackstop: P12M
riskIndicators: [patch-velocity-kev, level3-actions-reversed, approval-time-p10]

entityOverrides keeps the ceiling at Level 1 Assisted in any entity where employee representatives have not yet agreed to a tool that can act on employees' accounts, so one group statement respects national labour law. The evaluation set includes adversarial cases, so the tolerance reflects behaviour under attack. And approval-time-p10, the tenth percentile of the time people take to approve Level 2 actions, is reported as a risk indicator, because AI Governance, Chapters 10 and 21, observed that approvals given in seconds are a signal of rubber-stamping (72, Nordqvist, 2026).

Linking to enterprise risk management

GV.RM-03 asks that cybersecurity risk management is included in enterprise risk management processes, and GV.RM-05 that lines of communication are established for cybersecurity risks, including risks from suppliers and other third parties (19, NIST, 2024). Security AI's risk records therefore belong in the enterprise risk register with the same scales, its appetite refines the enterprise appetite for ICT risk, and supplier changes reach the risk function through a defined channel. The AI RMF likewise asks for AI risk management to be integrated with broader risk management (16, NIST, 2023), and one register avoids a gap in which neither process owns security AI.

GV.RM-07 asks that strategic opportunities, positive risks, are included in risk discussions (19, NIST, 2024). Security AI is one, and recording it lets the management body weigh the risk of using security AI against the risk of not using it.

Under NIS 2, Article 20, the management body approves and oversees the risk-management measures (3, European Union, 2022); under DORA, Article 5, it bears ultimate responsibility for ICT risk (2, European Union, 2022). The risk strategy for security AI therefore yields four indicators for it, developed in Chapter 8: patch velocity for known-exploited vulnerabilities on exposed systems, the number of security AI systems at each autonomy level against their ceilings, tolerance breaches and automatic step-downs, and open proposals above a ceiling. Each is derived from the code above, which keeps the report a by-product of operation.

The strategy across modes, levels and focus areas

Across the usage modes

The modes (usage modes) set the appetite because they decide who catches an error and with whose identity the AI acts.

Mode	Opportunity	Characteristic vulnerability	Who judges, with whose identity	Typical ceiling
Mode 0 Ambient AI	Vendor verdicts at scale	Automatic actions not chosen by the organisation	The vendor's model	Only declared actions
Mode 1 Conversational assistants	Faster queries and summaries	Wrong analysis accepted; data leaving the jurisdiction	A person, in the person's session	Level 0 Advisory or Level 1 Assisted
Mode 2 Embedded workplace assistants	Suggestions inside SIEM and ticketing	Attacker-controlled content steering output	A person, through delegated access	Level 1 Assisted
Mode 3 Agentic work tools	Detections built and tested quickly	An agent acting with an engineer's credentials between instruction and review	A person reviews; the engineer's identity	Level 1 Assisted, isolated ranges only
Mode 4 Built AI applications	Triage tuned to the organisation's data	Manipulation through alert content; drift after model updates	People and the policy point; a service identity	Up to Level 2 Supervised
Mode 5 Autonomous production agents	Containment at machine speed	A well-meaning insider with its own permissions	The policy point within bounds; the agent's own identity	Level 2 Supervised; Level 3 Bounded only for catalogued, reversible actions

Across the autonomy levels

The levels (autonomy levels) carry the error tolerance and the reversibility condition.

Level	Risk-strategy condition	Who may raise a system to it
Level 0 Advisory	Error tolerated; a person decides and acts	Use-case owner
Level 1 Assisted	Error tolerated if every draft is reviewed	Use-case owner with the CISO
Level 2 Supervised	Measured tolerance; approval quality monitored	AI governance board, within the ceiling
Level 3 Bounded	Strict tolerance; only catalogued, reversible, bounded actions; stop path tested	AI governance board, after evidence at Level 2
Level 4 Autonomous	Never for offensive or irreversible actions; elsewhere only by the management body	Management body

Verifying with security chaos engineering

The chapter's experiment injects two conditions, one at a time, in the governance pipeline rather than on the production estate: a synthetic security AI system registered in the asset register, marked as an experiment in the sealed ledger, and a synthetic supplier notice that the model behind a security product has changed version. The steady-state hypothesis is that, for each, a review of the context record and appetite statement is opened automatically within one working day and assigned to the named owner, and that the pipeline blocks any raise in autonomy level for the affected system until the review closes. The experiment is bounded to five working days, any failure goes to the purple backlog, and Chapter 25 describes the platform and safety boundaries.

The three AI focus areas

Securing AI systems. The context record brings the AI the organisation depends on, including security AI in products and its MSSP's service, into the strategy as owned risk records. The Cyber AI Profile treats the organisation's own AI as part of what cybersecurity must protect (20, NIST, 2025); this chapter treats security AI as a tier-0 asset, because a manipulated triage model or investigation agent weakens every control downstream.

AI-enabled cyber defence. The appetite statement sets tolerated error, ceilings per mode and reversibility conditions, and records the opportunity.

Thwarting AI-enabled attacks. The strategy revises its assumptions about the exploitation window, synthetic media and volume, and turns each into a risk record with a response, as supervisory signals such as the ECB's letter expect (7, ECB, 2026).

Nordvik Region and Hansa Mutual

Nordvik Region's context is public law, public access and a small team. Its context record lists the benefits-triage service and the citizen-service and staff assistants as AI the mission depends on, and the phishing-report classifier, the MSSP's tooling under framework agreement NR-2025-044 and the SOC triage assistant as security AI the defence depends on. The risk-appetite statement, proposed by the CISO and approved by the regional director, is correspondingly conservative: security AI may run in Modes 0, 1 and 4, none acts with an identity of its own, and NR-SEC-001 has a ceiling of Level 1 Assisted that any proposal to raise must be argued against. It tolerates measured error in checked drafts but no unreviewed action on the estate.

Hansa Mutual's context is seven jurisdictions, DORA and a management body that owns ICT risk. Its executive board approves the strategy, and the group AI governance board sets ceilings of Level 3 Bounded for a defined set of reversible containment actions, Level 2 Supervised for anything else HM-SEC-001 executes, and lower ceilings where works councils have not yet agreed to a tool that can monitor employees. DORA applies in the EU entities, while the Norwegian, UK and Swiss entities apply the same controls as group policy. Both write the appetite down as code with review triggers; Nordvik's mandate puts residents' trust first with a small team, while Hansa's supervisors expect a management body to own and evidence ICT risk across many regimes.

Summary

GV.OC Organizational Context should name the mission, stakeholders, obligations and dependencies, including the AI the organisation relies on, the security AI it operates or receives in products and services, and the adversaries who use AI against it, so that securing AI systems enters the risk strategy from the start.

GV.RM Risk Management Strategy should state a risk appetite for AI in defence in enforceable terms: error tolerances measured on the organisation's own evaluation set, reversibility and blast radius, and an autonomy ceiling for each usage mode. The management body approves it, and the AI governance board raises individual systems within the ceilings on evidence; error acceptable in a Mode 1 assistant is not acceptable in a Mode 5 agent, and Mode 0 features are brought inside the appetite. Risk assumptions must also change, because shorter exploitation windows, synthetic media and attacks at scale invalidate assumptions built for slower adversaries.

The strategy belongs in code, enforced at the pipeline and the policy point, linked to enterprise risk management and reviewed on change, as the chapter's chaos experiment verifies. Chapter 6 turns appetite into authority by defining roles, usage modes and autonomy levels for the people in command of security AI.

Sources

NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). (16, NIST, 2023)
European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
European Central Bank (2026). Addressing AI-enabled cybersecurity threats. (7, ECB, 2026)
Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (44, Charrier & Weiner, 2024)
National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. (38, NCSC, 2026)
Forum of Incident Response and Security Teams. Exploit Prediction Scoring System (EPSS). (26, FIRST, n.d.)
Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. (27, CISA, n.d.)
European Union Agency for Cybersecurity (2025). European Vulnerability Database (EUVD). (28, ENISA, 2025)
Magramo, K. (2024). Arup revealed as victim of $25 million deepfake scam involving Hong Kong employee. (55, Magramo, 2024)
National Cyber Security Centre (2025). Impact of AI on cyber threat from now to 2027. (37, NCSC, 2025)
Five Eyes cyber security agencies (2026). The AI shift in cyber risk: why leaders must act now. (39, Five Eyes agencies, 2026)
OWASP Foundation (2025). OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
Nordqvist, G. (2025). Architecture as Code. (71, Nordqvist, 2025)
Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)