Proactive Recovery: Recoverability, Rehearsal and Communication

Most organisations learn how well they recover on the worst day of the year. Backups are configured, plans approved and objectives agreed, but the first time anyone measures whether a service can actually be restored from those backups, within that objective, by the people and suppliers named in the plan, is during a real incident. Recovery is reactive by default, because rehearsing it is expensive and easy to postpone.

This chapter turns recovery into a proactive, continuously verified capability. It shows how AI makes frequent rehearsal affordable, including for AI artefacts such as models and retrieval stores; how AI predicts recovery times and finds unrecoverable dependencies before an incident does; how recoverability findings feed Govern, Identify and Protect; and how recovery communication is prepared in advance and drafted with AI under human sign-off. It is responsible for two Categories of the Recover Function of NIST CSF 2.0 (19, NIST, 2024). From RC.RP Incident Recovery Plan Execution, whose outcome is that restoration activities ensure the operational availability of affected systems and services, it treats the part decided long before the incident: whether the plan can be executed at all. RC.CO Incident Recovery Communication asks that restoration activities are coordinated with internal and external parties. Chapters 22 and 23 covered executing a plan and restoring AI systems; this chapter makes both verified rather than assumed.

Figure 24.1: The proactive recovery loop from restore drills to findings that improve Govern, Identify and Protect.

From reactive to proactive recovery

Recoverability as a measured property

A recovery plan states an intention; recoverability is the measured ability to fulfil it. Almost every organisation can show an auditor a plan and a backup schedule, but far fewer can show the restore time they measured last month. NIST's guide to cybersecurity event recovery makes the same distinction, treating recovery as something planned, tested and continuously improved, with metrics that inform continuous improvement (22, Bartock et al., 2016).

Assumed in a reactive organisation	Measured in a proactive organisation
Backups exist and are complete	Backup integrity verified by restore, not job status
The service can be restored within its RTO	Restore time measured in the latest drill and predicted for the current estate
The plan lists every dependency	Dependencies observed when the service was restored in isolation
Suppliers will meet their commitments	Supplier steps timed in drills that include the supplier
People know what to say and to whom	Prepared messages released within their target time in an exercise

Each measurement has an age, and a restore time measured eleven months ago describes an estate that no longer exists. A proactive organisation therefore tracks, per service, the date of the last successful drill, the measured restore time, the achieved recovery point, the dependencies not restored and the time to release the first prepared message: the service's recoverability profile.

Architecture as Code (Chapter 13) concluded that security and compliance tests, including synthetic attack simulations, belong in the pipeline and run against ephemeral environments (71, Nordqvist, 2025). A restore drill is such a test: it builds an ephemeral copy of a service from its definitions and backups and checks that it works. This chapter builds on that conclusion (F8 in the series foundations) and applies it to the property that is tested least often.

Assume breach

Proactive recovery assumes that the adversary will at some point destroy or corrupt something that matters. Destructive and extortion attacks draw their leverage from the victim's doubt about recovery, so an organisation that knows from last month's drill that it can rebuild within a day is in a stronger position than one that hopes. The assumption also changes what recovery must withstand. An adversary who expects the victim to restore will target the means of restoring: backup consoles and credentials, the repositories of known-good definitions, and the identity services needed to reach them. Drills must therefore use the same protected sources and separated credentials as a real recovery; a drill that succeeds only because it uses an administrator's everyday account proves nothing.

AI-assisted rehearsal and restore testing

What a drill restores

A restore drill destroys nothing in production: it builds a copy of one service in an isolated range, from the sources a real recovery would use. The range has no route to production, uses its own identities and holds only synthetic or lawfully copied data; Chapter 25 sets out its safety boundaries.

Beyond definitions, images, data, secrets, certificates and licences, a drill of an AI system adds the artefacts listed in Chapter 23: model version, prompts, retrieval store, tool connections, any agent's permission manifest and the evaluation baseline. A drill that restores an assistant's serving stack but not its retrieval store has not shown that the assistant can be brought back to a trustworthy state. The dependencies that most often break a drill are mundane: identity and multi-factor authentication services, internal certificate authorities, name resolution, time sources, licence servers, secrets vaults, package mirrors and unwritten supplier steps. They are shared by everything and therefore owned by nobody in the plan.

Where AI helps

Drills are rare because each costs skilled people days of work. AI reduces that cost at four points without taking over execution.

Choosing what to drill next. A planner reads the recovery plans of Chapter 22, the change history and earlier results, and proposes the service whose dependencies changed most, whose last drill is oldest, or whose predicted restore time is closest to its objective. A person approves the schedule.

Preparing the drill. An assistant assembles the runbook from the plan, the definitions and the previous log, and lists what must be pre-staged, such as test accounts or a reserved slot with a supplier.

Observing the drill. The isolated range is an excellent dependency detector, because a restored service that tries to reach a host outside its plan fails visibly. AI turns hundreds of failed connections and authentication errors into a short list of missing dependencies, each with its evidence.

Reporting the result. AI drafts the drill report for the service owner to review.

Each task reads material that may be inaccurate or manipulated. AI Platform and Security, Chapter 16, concluded that prompt injection is a property of the architecture, so controls must sit outside the model (73, Nordqvist, 2026); OWASP likewise holds that, given the stochastic nature of generative models, it is unclear whether fool-proof prevention exists and recommends privilege control and least-privilege access as mitigations (14, OWASP, 2025); the AI components therefore propose and interpret but hold no credentials to backup systems or production, and every restore step passes through the deterministic orchestration and policy point of Chapters 22 and 25.

Predicting recovery times

Between drills the estate changes. A prediction combines measured step durations, data volumes, supplier commitments and dependency order into a restore-time range; the critical path itself is arithmetic, and AI contributes where inputs are messy, maintaining the dependency graph and explaining why a prediction moved, for example "predicted restore time 6 to 9 hours against an objective of 8 hours; the upper bound exceeds the objective because the retrieval store has doubled in size since the last drill".

Three rules keep predictions honest. First, a prediction is never evidence of recoverability: one that exceeds the objective triggers a drill or a finding, and one that meets it does not extend the drill interval. Second, predictions are recalibrated against every drill. Third, a prediction is labelled as an estimate wherever it appears, and is never published in recovery communication as a commitment.

Practical guide: Setting up a monthly AI-assisted restore drill

Purpose. Establish a monthly drill that measures recoverability for one service at a time, uses AI to reduce effort, and produces evidence and findings without touching production.

Roles. CISO or head of resilience (owns the schedule), service owners (accept results), the platform team (executes), suppliers in scope, the MSSP where contracted, and the chaos engineering programme of Chapter 25 (schedules and logs drills as experiments).

Steps.

1. Rank the services in scope by business impact, starting with those whose loss would affect residents, customers or the identity services everything depends on, and record their objectives from the recovery plans of Chapter 22.
2. Build an isolated range with no route to production, its own identities and synthetic or lawfully copied data, and agree with each supplier how its steps will run there.
3. Write a recoverability test definition per service, as in the worked example below, and keep it in version control beside the recovery plan.
4. Register each definition in the chaos engineering catalogue, so that drills inherit its safety boundaries: isolated range, abort conditions independent of the AI, and blackouts during real incidents.
5. Configure the AI assistant at Level 0 Advisory, with read access to drill logs and range telemetry only.
6. Run the first drill per service with the service owner present, at Level 2 Supervised for every restore step.
7. Route every finding as described in the next section, and close it only when a re-run of the same drill passes.
8. Publish each service's recoverability profile to the CSF profile and management reporting.

Default values to adapt. One service per month, each critical service at least twice a year; abort at twice the recovery time objective; findings acknowledged within five working days. DORA's yearly testing requirement, discussed below, is a floor rather than a target.

Definition of done. Every critical service has a test definition in version control and a recent successful drill, every drill has produced evidence and owned findings, and the recoverability profile shows measured rather than assumed values.

Worked example: Recoverability test definition with objectives, drill schedule and evidence output

The definition below is illustrative. It belongs to Nordvik Region's monthly drill programme NR-SEC-004 and covers the citizen-service assistant. Because a poisoned retrieval store is the most plausible way to manipulate the assistant, the store is rebuilt from published sources rather than restored from backup, as Chapter 23 explains. The assistant that predicts and compares runs on the Region's self-hosted capacity at Level 0 Advisory; people and the supplier execute every step.

# Illustrative: Nordvik Region, recoverability test for the citizen-service assistant
kind: RecoverabilityTest
id: NR-SEC-004-RD-07
programme: NR-SEC-004
csf: [RC.RP-03, RC.RP-05, PR.DS-11]
objectives: {recoveryTimeObjectiveHours: 8, recoveryPointObjectiveHours: 24}
schedule:
  cadence: monthly
  rotation: [citizen-service-assistant, identity-services, benefits-explanations]
  blackouts: [open-major-incident, benefit-payment-run]
environment: {target: isolated-copy, routeToProduction: false, data: published-information-only}
restore:
  - {component: open-weight-model, source: model-registry, verify: digest}
  - {component: prompt-template, source: registry, version: citizen-service/v7}
  - {component: retrieval-store, source: rebuild-from-published-sources}
  - {component: identity-integration, source: known-good-definition}
supplierSteps:
  - {supplier: european-hosting-provider, step: allocate-reserved-accelerators, commitmentHours: 4}
assistant:
  autonomyLevel: 0          # predicts, compares and drafts; people execute
  access: [drill-logs, range-telemetry]
acceptance: [evaluation-baseline-passes, answers-cite-published-sources-only, no-route-to-production-confirmed]
abort: {ifElapsedHoursExceed: 16, independentOfAssistant: true}
evidence:
  controlIds: [CTRL-RC-004]
  records: [measured-restore-time, achieved-recovery-point, unrestored-dependencies]
findings:
  unrecoverableDependency: supplier-management
  missingOrUnusableBackup: platform-backlog
  objectiveMissed: ciso-risk-register
  closeWhen: same-drill-passes-on-rerun

The definition makes explicit what a narrative plan leaves implicit: the supplier step and its commitment, the acceptance criteria that make a restored assistant trustworthy rather than merely running, and the route of each finding. When the drill finds that the hosting provider needed seven hours rather than four to allocate the reserved accelerators, that is a measured finding for supplier management, not an impression.

Recovery findings as input to other Functions

What drills find

Drill findings belong to different Functions, so that Recover strengthens the rest of the programme instead of absorbing its failures.

Finding	Typical example	Function and CSF outcome	Route and owner
Unrealistic objective	An RTO no drill has met	Govern: risk appetite (GV.RM)	Risk register; the business owner funds faster recovery or accepts a longer objective
Unrecoverable dependency	A licence server or undocumented supplier step	Identify: assets and dependencies (ID.AM)	Asset inventory and recovery plan; supplier management
Missing or unusable backup	A "successful" job that cannot be restored	Protect: backups tested (PR.DS-11)	Platform backlog; closed by a passing re-run
Slow or unclear communication	A missing message or unreachable approver	Govern and Recover (RC.CO)	Communications lead; message library and rota

CSF 2.0 expects exactly this movement: ID.IM-02 asks that improvements are identified from security tests and exercises, including those done with suppliers, and GV.SC-08 that relevant suppliers are included in incident planning, response and recovery (19, NIST, 2024). NIST's incident response profile likewise treats preparation for response and recovery as outcomes of Govern, Identify and Protect, and lessons learned as input to improvement across all Functions (21, NIST, 2025).

Findings as pull requests

Architecture as Code (Chapter 9C) concluded that threat handling belongs in the codebase and that findings return as pull requests, with the advice to celebrate the remediation pull request and not only the discovery (71, Nordqvist, 2025). This chapter builds on that conclusion (F1) for recovery. A dependency, a missing backup or an unrealistic objective found in a drill becomes a change to the plan, inventory, backup policy or objective. AI drafts the pull request from the drill report, a person merges it, and the drill is re-run to prove the finding closed. This is the purple loop of Chapter 26 applied to recovery: a drill that failed in March and passed in April after a merged change is the strongest evidence of improvement a recovery programme can produce.

Recoverability in management reporting

AI Governance, Chapter 24, concluded that patch decisions must be delegated in advance, because a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities, and that patch velocity belongs in management reporting as a risk indicator (72, Nordqvist, 2026). This chapter builds on that conclusion (F15) in two ways. First, recoverability metrics, such as the share of critical services with a recent successful drill that met its objective, belong beside patch velocity, so that the management body can fund faster recovery or accept the risk on record. Second, the decisions recovery needs are also delegated in advance: who may declare recovery started and finished, who may restore from which backup, and who may release which prepared message.

Recovery communication

Prepared before it is needed

Recovery communication differs from the response communication of Chapter 21: its subject is which services are back, what people should do meanwhile and when the next update comes, and its audiences range from staff, customers and residents to elected representatives and supervisors. CSF 2.0 frames the outcomes as recovery progress communicated to designated stakeholders and public updates shared using approved methods and messaging (19, NIST, 2024), and NIST's recovery guide recommends that communication plans be developed as part of recovery planning, not improvised during the event (22, Bartock et al., 2016).

Proactive recovery communication therefore rests on four prepared elements:

1. A message library: for each audience and plausible recovery situation, pre-approved fixed wording with marked slots for facts from the incident record. Approving wording calmly in advance is what makes release within minutes possible.
2. An approver rota: named approvers and deputies per audience, reachable out of hours.
3. Channels independent of the affected systems: a status page hosted outside the estate, a contact-centre script that does not depend on the knowledge base, and contact lists available when the directory service is down.
4. Release targets: for example 60 minutes from a service's restoration to the first public update, measured in exercises like any other recovery objective.

Because public authorities' libraries may be requestable under public-access rules, out-of-hours numbers belong in a classified annex.

AI-assisted drafting from the incident record

During recovery, an assistant fills the slots of prepared messages from the incident record and orchestration status, produces variants per audience and language, and flags where the facts fit no prepared message, so that a person writes a new one. It follows the discipline of the reporting assistant of Chapter 21: structured, confirmed facts, every statement linked to its record entry, and attacker-controlled content only as labelled evidence that cannot change its instructions.

Three errors are specific to recovery communication. The first is premature restoration, announcing a service because the orchestration reports it running before it has passed the checks of Chapter 22; the assistant therefore takes service state only from the verified return-to-service record. The second is a predicted time published as a promise, so public messages give the time of the next update unless the service owner approves a commitment. The third is divergence between what residents, supervisors and staff are told, so each draft is checked against everything already released.

Human sign-off and release

Every recovery message is approved by a named person before release. Architecture as Code (Chapter 20) set the rule "agents draft; humans approve" (71, Nordqvist, 2025), and Chapter 21 explained why sign-off needs support to be more than a formality. A message with pre-approved wording and verified facts in its slots can be approved quickly without being rubber-stamped, because the approver checks facts rather than prose.

Worked example: A prepared recovery message record

In Hansa Mutual's message library, entry HM-COMMS-RC-012 (illustrative) is the update to policyholders when the claims service has been partially restored. The record holds no message text, since each entity approved the wording per language in advance. Instead, it defines where each slot's fact comes from (the verified return-to-service record and the incident record), what may never be said (predicted times as commitments, an unconfirmed cause, personal data), who approves (the accountable owner per entity), which channels carry it, and the 60-minute release target last met in a test.

Evidence of recoverability

What the instruments expect

NIS 2 Article 21(2) requires business continuity, such as backup management and disaster recovery, crisis management, and procedures to assess the effectiveness of these measures (3, European Union, 2022), and Article 23 makes notifying affected recipients of services part of compliance. For the digital service providers it covers, including managed security service providers, Implementing Regulation (EU) 2024/2690 sets out more detailed requirements, among them business continuity and disaster recovery, backup and redundancy management and crisis management (4, European Commission, 2024), and ENISA's implementation guidance describes the evidence an entity can show for each (8, ENISA, 2025).

DORA is more prescriptive for financial entities (2, European Union, 2022). Article 11 requires ICT response and recovery plans, tested at least yearly and after substantive changes to systems supporting critical or important functions, together with the crisis communication plans. Article 12 requires periodically tested restoration procedures, restoration onto segregated systems, and recovery time and point objectives for each function. Article 14 requires crisis communication plans for clients, counterparts and the public. ISO/IEC 27002 expresses the same outcomes as controls for ICT readiness for business continuity and information backup (31, ISO/IEC, 2022). The common architectural implication is that recoverability is shown by tests, not asserted by plans.

Evidence as a by-product of drills

Architecture as Code (Chapter 15A) concluded that evidence is machine-collected, signed and versioned rather than assembled in audit season (71, Nordqvist, 2025), and AI Governance, Chapter 11, added that evidence is a by-product of delivery, tied together by an evidence manifest, and that attestation is a person asserting while evidence is machine-generated (72, Nordqvist, 2026). This chapter builds on both conclusions (F4 and F12): every drill writes a signed record against its control identifier and Subcategories, every release test records its timing and approval, and the evidence manifest links them to the obligations they serve.

Obligation	Evidence the drill programme produces
NIS 2 Article 21(2), continuity, backup and disaster recovery	Drill records per service, with measured times and findings
NIS 2 Article 23, informing recipients of services	Message library, approver rota and release-test records
DORA Article 11, testing of response and recovery plans	Drill schedule, records linked to change events, communication release tests
DORA Article 12, backup and restoration	Test definitions with objectives, isolated-range records, achieved recovery points
DORA Article 14, communication	Message library with approval history and release targets

The CSF profile as code of Chapter 3 receives the same records, so that for each Subcategory under RC.RP and RC.CO the target profile is compared with measured rather than declared capability.

Proactive recovery in practice

Across the usage modes

The table summarises the differences across the usage modes.

Mode	Opportunity	Characteristic vulnerability	Who judges	Whose identity
Mode 0 Ambient AI	Backup products flag anomalous changes	Opaque verdicts; automatic action on snapshots	The vendor's model, then the platform team	The product's own
Mode 1 Conversational assistants	Faster runbooks and test definitions	Recovery details pasted outside the approved tier	A person	The person's session
Mode 2 Embedded workplace assistants	Drafts and drill summaries where people work	Drafts from incomplete context	A person	The person's, by delegation
Mode 3 Agentic work tools	Coding agents build drill automation	Engineer's credentials touching backup systems	A person reviews	The engineer's
Mode 4 Built AI applications	Drill planning, prediction, dependency discovery, drafting	Manipulated inputs; over-confident predictions; premature announcements	People, via a policy point	A read-only service identity
Mode 5 Autonomous production agents	Catalogued drills in isolated ranges at machine speed	Restore permissions make it a privileged insider	Policy point and stop-path holders	Own workload identity, just-in-time range credentials

Across the autonomy levels

The autonomy levels apply to two kinds of action here: executing restore steps and releasing messages.

Level	Restore drills and recovery	Recovery communication
Level 0 Advisory	Proposes schedule, predicts times, lists dependencies	Suggests which prepared message fits
Level 1 Assisted	Prepares the runbook; a person executes	Drafts the message; a person edits and releases
Level 2 Supervised	Executes each step after approval; default in production	Sends only after the named approver approves
Level 3 Bounded	Executes catalogued drill steps in isolated ranges	Internal status notices from verified records only
Level 4 Autonomous	Not used: restoring overwrites state	Not used

Verifying with security chaos engineering

Three experiments from the catalogue of Chapter 25 verify this chapter.

Scheduled restore drill. A test copy of a service in an isolated range is lost; the hypothesis is that it is restored from protected sources within its recovery time objective, passes acceptance and writes its evidence record, with the recovery point within objective. Scheduling drills as experiments keeps them running when attention moves elsewhere.

Silent backup failure. A backup job for a test service reports success but writes an unusable copy; the hypothesis is that the sample-restore integrity check detects it and raises a finding within 24 hours, verifying the Protect outcome recovery depends on.

Communication release. A synthetic recovery milestone appears in an exercise record; the hypothesis is that the matching message is drafted, approved by the named approver or deputy and ready on the out-of-band channel within 60 minutes, released only to a test channel. An approver who cannot be reached on a Friday evening is exactly the failure proactive experimentation exists to find (67, Shortridge & Rinehart, 2023).

The three AI focus areas

The NIST Cyber AI Profile treats each Category through three focus areas (20, NIST, 2025).

Securing AI systems. AI systems are drilled like any other, with the additional artefacts of Chapter 23, and acceptance includes re-running the evaluation baseline. The planner, predictor and drafting assistant are themselves AI systems with an owner, a threat model and a degraded mode.

AI-enabled cyber defence. AI plans and prepares drills, predicts recovery times, finds unrecoverable dependencies, drafts findings as pull requests and drafts recovery communication from verified facts.

Thwarting AI-enabled attacks. Destructive and extortion attacks depend on the victim's uncertainty about recovery. Assuming breach and designing for fast, recently proven recovery, with separated backup credentials and restoration from known-good definitions, takes that leverage away.

Nordvik Region and Hansa Mutual

Nordvik Region uses AI-assisted drills to compensate for a small team. A monthly drill under NR-SEC-004, run with its MSSP, restores one service in an isolated copy, from the citizen-service assistant to the identity services, and an assistant on the Region's self-hosted capacity compares restore times with objectives at Level 0 Advisory while the platform team, the MSSP and suppliers carry out every step. The first drills found two services whose recovery depended on an undocumented supplier step; because most unrecoverable dependencies sit with suppliers, findings go to the CISO's risk register and supplier management, and commitments that miss the Region's objectives are recorded for contract renewal. Recovery communication is prepared for staff, residents, the municipalities it serves and the elected politicians of the regional council, and the communications lead and the CISO approve every message.

Hansa Mutual runs drills continuously within HM-SEC-006, as catalogued Mode 5 experiments in isolated ranges, at Level 3 Bounded in rehearsal and Level 2 Supervised in production, and uses AI to predict recovery times for the group platform. Findings feed the group CSF profile HM-CSF-2027 and are reported to the management body and, where required, to supervisors under DORA. Prepared communication exists in the languages of all seven countries in which the group operates, and drafts are approved in each entity by the accountable owner. Nordvik's proactive recovery is therefore about verifying what suppliers promise and keeping residents and politicians informed; Hansa's is about proving recoverability to a management body and supervisors across a large estate and many languages.

Summary

Recovery should be a measured property rather than an assumption. Under RC.RP Incident Recovery Plan Execution, AI makes that practical by planning, observing and reporting restore drills in isolated ranges, including for models and retrieval stores, and by predicting recovery times between drills as estimates that trigger drills rather than replace them. Every recoverability finding is fed back to Govern, Identify and Protect as a pull request and closed only when the drill that found it passes again, and recoverability belongs beside patch velocity in management reporting.

RC.CO Incident Recovery Communication is prepared before it is needed, with a message library, an approver rota, independent channels and measured release targets. During an incident, AI drafts messages in Mode 2 and Mode 4 tools from the verified return-to-service record, and named people approve them. The evidence that NIS 2 and DORA expect comes from the same drills and release tests. The underlying stance is to assume breach: when recovery is fast and proven, destructive and extortion attacks lose their leverage. Chapter 25 generalises this practice into security chaos engineering with AI, which verifies every Function continuously.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. Bartock, M., Cichonski, J., Souppaya, M., Smith, M., Witte, G. & Scarfone, K. Guide for Cybersecurity Event Recovery. (22, Bartock et al., 2016)
3. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. (21, NIST, 2025)
4. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
5. 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)
6. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (4, European Commission, 2024)
7. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
8. 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)
9. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls. (31, ISO/IEC, 2022)
10. Shortridge, K. & Rinehart, A. Security Chaos Engineering: Sustaining Resilience in Software and Systems. (67, Shortridge & Rinehart, 2023)
11. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
12. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
13. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
14. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)