AI in Cybersecurity

Investing in Resilience, Retaining Control

A note on terminology: Artificial intelligence (AI) is the broad umbrella for machine-based systems that perform tasks such as making predictions, recommendations or decisions. Machine learning (ML) is a subset of AI in which models learn patterns from training data to make inferences about new data, rather than relying solely on explicitly programmed rules. Large language models (LLMs) are a particular type of deep-learning model (within ML) trained on very large datasets to process and generate language and other content. These definitions draw on the United States National Institute of Standards and Technology (NIST). In short, LLMs are a form of ML, and ML is one approach to AI: the terms are related, but not interchangeable. An AI-enabled security tool need not use an LLM.

Executive Summary

Artificial intelligence can give defenders and attackers greater speed, scale and adaptability. For senior leaders, the question is whether and where AI can demonstrably improve resilience without creating unacceptable operational, legal or dependency risks. Investment should follow business exposure and evidence, rather than the availability of a new feature or the appeal of autonomous security. Four disciplines should guide those decisions:

• augment skilled people and sound processes rather than replace them;
• prioritise bounded applications that demonstrably strengthen identity, payment controls, detection and incident response;
• embed privacy, fairness, transparency, security and regulatory obligations throughout procurement and operation;
• and assign accountable owners, automation limits and approval thresholds, with the ability to review, pause or override consequential actions.

The strongest opportunities are bounded: helping security teams investigate and contain incidents, strengthening identity and fraud decisions, and directing attention towards material supplier exposures. Success depends on sound processes, reliable data and people empowered to challenge automated outputs. Leaders should require an accountable owner, a local performance baseline, explicit limits on automated action and a workable fallback for every material deployment. Approval should proceed through three gates: select a defensible use case; validate performance and operational readiness; and expand only when continuing evidence supports the investment. This article examines five decisions underpinning that approach: where to invest, which threats and dependencies to address, how to allocate authority, what evidence to demand and how to move from pilot to scale. References and the optional procurement appendix sit outside the substantive argument.

The Strategic Context: AI Is an Operating-Model Decision

AI changes the economics of cybersecurity more readily than it changes its underlying purpose. Organisations still need to protect services, information and trusted relationships, detect compromise and recover when controls fail. AI can help teams analyse more activity and act sooner, but attackers can use similar capabilities to produce convincing deception and automate established methods. The United Kingdom’s National Cyber Security Centre (NCSC), in Impact of AI on cyber threat from now to 2027 (National Cyber Security Centre, 2025), assesses that AI will almost certainly make elements of cyber intrusion more effective and efficient. This is a forward-looking assessment, not a measurement of every organisation’s present exposure. It provides a reason to reassess controls, not evidence that every organisation needs the same product or deployment timetable.

For executive teams, the relevant outcomes are continuity, fraud reduction, effective use of expertise and confidence in decisions. A detection tool that produces more alerts without increasing investigative capacity may add workload rather than resilience. An automated response that contains an incident but interrupts a critical service may transfer risk rather than reduce it. Equally, rejecting a useful capability because it is imperfect can leave avoidable exposure. The leadership task is to define the outcome, understand the trade-offs and decide what evidence would justify a change in operating practice.

Three distinctions keep that discussion grounded. First, using AI to improve security is different from securing AI systems themselves; both need owners and controls. Second, analytical assistance is different from authority to act: a useful recommendation does not automatically justify autonomous execution. Third, a supplier’s capability claim is different from evidence of value in the buyer’s environment. These distinctions help leaders avoid debates framed as a choice between unrestricted automation and no automation. The practical alternative is a series of bounded decisions, supported by tests, review and the ability to stop. AI should therefore be governed as part of the organisation’s wider service, risk and investment model, not isolated as an experiment belonging solely to the security team.

That operating-model perspective also clarifies the executive role. Boards and senior teams should challenge the purpose, exposure and conditions of investment without trying to select detection thresholds themselves. Operational owners need authority to implement controls within agreed boundaries, and a route back to leadership when those boundaries cannot be maintained. A useful discussion therefore starts with the service or process at risk, not a catalogue of products. It ends with a decision about resources, permitted action and assurance. This is how technical opportunity becomes an accountable business choice rather than a parallel technology strategy.

Decision 1: Where Can AI Create Defensive Value?

The investment case for AI in cybersecurity rests on four outcomes: earlier detection and containment, more effective use of security expertise, stronger identity and fraud decisions, and better visibility of critical suppliers. For detection and response, work by the AI Security Institute in collaboration with the NCSC identifies potential to scale and accelerate threat detection, investigation, mitigation and response (AI Security Institute, 2026). Its value depends on evidence of improvement in the organisation’s own operating environment, not capability claims alone.

Improve Security Operations, Not Just Alert Production

Traditional signature-based controls remain useful, but activity that appears legitimate in isolation can conceal compromise. Machine learning and behavioural analysis can complement existing controls by correlating signals across endpoints, identities, networks and cloud services. The executive benefit is not the volume of events processed; it is a better chance of identifying material activity early enough to limit disruption. IBM’s 2024 breach research associates extensive security AI and automation with faster identification and containment (IBM, 2024). Ponemon Instituteconducted the research; IBM sponsored, analysed and published it. This commercially sponsored observational association supports investigation of the opportunity, but does not establish that a particular product will cause the same improvement locally.

Detection, investigation, prioritisation and response should be assessed as one workflow. AI may summarise logs, classify files, connect related events or recommend a playbook, while analysts validate context and decide what matters. Automating one step can move the bottleneck elsewhere: faster triage will not improve containment if decision authority, staffing or access to evidence remains unclear. Leaders should ask which delay is being removed, what new burden is being introduced and whether the change improves the end-to-end service. Existing platform capabilities should be assessed before procuring another tool that requires additional integration and oversight.

AI’s value in anticipation is better prioritisation, not reliable prediction of an attacker’s next move. Correlating incident history, external intelligence and behavioural patterns can help teams identify emerging exposures and test plausible scenarios. An anomaly remains a reason to investigate, not proof of compromise. MITRE’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) (MITRE, n.d.-b) and Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS) (MITRE, n.d.-a) support threat-informed planning for conventional and AI-related attacks; they are knowledge bases, not engines for predicting zero-day exploits. Leaders should judge analytical capability by whether it directs scarce attention towards material risks and improves preparation, rather than by claims of predictive certainty.

Implementation evidence is most informative when it describes the work actually changed. Palo Alto Networks reportsthat Bank Central Asia developed 85 incident-response playbooks, successfully handled 740,000 tickets and fully automated the resolution of thousands of tickets since 2023 (Palo Alto Networks, n.d.). This is a vendor-reported account of one implementation, not a universal workload-reduction benchmark or an independent test of AI effectiveness. Playbook automation does not isolate the contribution of machine learning or LLMs. Its practical lesson is to examine the specific tasks, integration effort and retained human responsibilities behind an outcome. Organisations need to know whether automation frees analysts for more valuable investigation, reduces delay or merely changes how tickets are recorded.

The workforce case should be equally concrete. Time saved in repetitive analysis has value only if it improves capacity, response or the quality of work elsewhere. During evaluation, teams should identify which tasks remain, what supervision is added and which skills are needed to investigate exceptions. A credible proposal explains how people and automation work together under normal and stressed conditions. It should not assume that a reduction in one task translates directly into an equivalent staffing reduction, particularly when the organisation already has unresolved investigative demand.

Strengthen Identity and Fraud Decisions

Identity is another practical investment priority. Verizon’s 2025 Data Breach Investigations Report identifies credential abuse as an initial attack vector in 22% of the breaches in its analysed dataset (Verizon, 2025). This is a finding from that report, not a population-wide estimate or a statement of the latest annual position. Adaptive authentication can combine device, location, behavioural and other contextual signals to decide when additional checks are warranted. Those signals should supplement strong authentication, not substitute for it. NIST’s authentication guidance specifies the authenticators required at each assurance level (Temoshok et al., 2025); contextual risk signals should not be treated as substitutes for those requirements. The objective is proportionate access control, rather than treating every unusual login as either harmless or malicious.

Behavioural and biometric systems require particular care because a single accuracy figure conceals important trade-offs. Performance depends on the signal, population, threshold and operating environment. NIST’s face-recognition research examines false matches, false non-matches and differences between algorithms and groups, rather than establishing universal reliability (Grother et al., 2019). A control that reduces fraud but blocks legitimate customers, overloads reviewers or makes recovery difficult may not represent a net improvement. Investment decisions should consider losses prevented, false positives, customer friction, review capacity and a meaningful route to challenge an adverse outcome.

Direct Assurance Towards Critical Dependencies

Supplier risk is an enterprise-resilience issue: disruption or data exposure can arise through services on which the organisation depends. AI can help monitor large supplier populations, identify changes in external signals and prioritise where deeper assurance is needed. Verizon’s 2025 research reinforces the importance of third-party involvement in breaches (Verizon, 2025). However, external ratings and automated questionnaire analysis are indicators, not proof of control effectiveness. They should inform direct engagement, contractual assurance, access decisions and continuity planning, with particular attention to suppliers whose failure would materially affect services.

Supplier monitoring also needs an action owner. A changed rating is useful only if someone can determine whether it affects a critical dependency and pursue proportionate follow-up. The organisation may need clarification, remediation evidence, tighter access or a continuity response; the score cannot choose among these in isolation. Procurement and service owners should therefore agree how signals enter established processes. This connects automated visibility to decisions about dependence, rather than creating a separate stream of supplier alerts with no capacity or authority to resolve them.

The same investment discipline applies across these opportunities: choose a business problem, not an AI category. A security-operations team may need better investigation support; a payment process may need stronger verification; procurement may need to prioritise critical suppliers. Each requires different data, skills and decision rights. Leaders should resist bundling them into one programme whose success is impossible to interpret. A small number of clearly owned use cases makes it easier to establish whether AI improves the control, whether a simpler intervention would work better and what evidence would justify broader deployment.

Decision 2: Which Threats and Dependencies Need Attention?

AI can increase the speed, personalisation and scale of familiar attacks without making every incident technically novel. Leaders should distinguish demonstrated activity from experiments, supplier telemetry and forecasts. The NCSC’s assessment supports concern about lower barriers and more effective attacks, but does not justify assuming that reliable, fully autonomous attackers are already the norm (National Cyber Security Centre, 2025). Risk decisions should remain anchored in credible scenarios: fraudulent instructions, compromised identities, malicious code, manipulated inputs and operational dependence on tools that may fail or be unavailable.

Make Verification Independent of Apparent Authenticity

Payment controls must remain effective even when a voice or video appears authentic. In 2024, the Hong Kong Government reported a deepfake-enabled fraud in which an employee at a multinational company transferred approximately HK$200 million after a prerecorded video conference impersonated senior colleagues, including the chief financial officer. The official account states that there was no actual conversational interaction with the impersonated participants (Government of the Hong Kong Special Administrative Region, 2024). The case illustrates why apparent authenticity cannot substitute for payment authority: an unusual instruction still needs independent verification through a previously established channel and the organisation’s approval process. AI-generated voice and video can support phishing and business-email-compromise schemes. Synthetic-media services also have legitimate uses; a specific product should not be described as a criminal tool without evidence linking it to a documented incident.

The NCSC assesses that AI can assist stages of cyber intrusion, including reconnaissance and malware generation (National Cyber Security Centre, 2025). That assessment does not establish that reliable, fully autonomous, self-adapting malware is commonplace. Organisations should not base investments on criminal sellers’ claims or isolated demonstrations. The more defensible response is to test established controls against plausible variations: identity misuse, altered artefacts, suspicious execution and attempts to blend into legitimate activity. This keeps the focus on observable behaviour and consequences rather than on whether an attacker used a particular chatbot.

The implication is procedural rather than simply technical. Payment requests, supplier-detail changes and demands for sensitive information need independent verification even when the conversation, voice or video appears convincing. Heiding et al. (2024) compared AI-generated and manually designed phishing emails in a study involving 112 recruited participants and analysed their economics. The study supports concern about lower production costs and personalised phishing, but does not establish that AI consistently outperforms skilled human authors or demonstrate sustained conversational fraud. Training should therefore explain that fluency and familiarity are not evidence of authority. Verification must be practical under time pressure and supported by leaders, rather than treated as an obstacle when an apparently urgent instruction arrives.

Protect the AI Systems on Which Defenders Depend

Two different risks require separate controls: attackers can use AI to improve established attacks (National Cyber Security Centre, 2025), and they can attack the AI systems on which defenders depend. NIST’s adversarial-machine-learning taxonomy describes attacks including data poisoning and evasion (Vassilev et al., 2025). Keeping these categories distinct helps leaders assign ownership and test the right failure scenarios; a taxonomy identifies attack classes, not their prevalence in a particular organisation.

Protecting AI means examining its data, models, connected services and operating context. Poisoned data, crafted inputs and changing conditions can undermine classification or recommendations. A model may perform well in a benchmark and poorly against the organisation’s actual workload or an adversary’s chosen inputs. The European Union Agency for Cybersecurity (ENISA), in its 2020 AI cybersecurity analysis, takes a lifecycle and supply-chain perspective (European Union Agency for Cybersecurity, 2020), while MITRE ATLAS helps structure threat modelling and tests (MITRE, n.d.-a). For leaders, the key question is whether assurance covers the deployed system and its dependencies, not merely the model’s reported accuracy before integration.

Errors can have unequal and material effects. An unusual working pattern may be legitimate, while a risk threshold may burden some users more than others. False positives consume capacity and can interrupt access; missed detections leave exposure untreated. These are reasons to validate models against the real operating population and context, with review routes for affected users. They are not reasons to treat every automated score as inherently unfair or every human decision as sound. The objective is evidence of proportionate treatment and reliable outcomes, with accountability for correcting both technical and procedural failures.

Reliance creates a second exposure. Teams can lose resilience if they accept recommendations without challenge, allow investigative skills to erode or assume that automated monitoring will identify every material threat. A control can also fail through configuration, integration or loss of supply rather than model error. Leaders should ask how security operations continue when the AI service is unavailable, its outputs are unreliable or the organisation decides to suspend it. Fallback arrangements need to be exercised, because an untested manual process may not support the same workload or response commitments.

The resulting threat model should connect technical failure to business impact. Leaders need to understand which service could be interrupted, which transaction could be authorised incorrectly, what information could be exposed and how quickly the organisation could recognise and reverse the error. Critical dependencies deserve more demanding tests and clearer escalation than low-impact assistance. This provides a proportionate basis for prioritisation: address the scenarios that matter to the organisation, retain uncertainty where evidence is incomplete and update the assessment as deployment conditions change.

Decision 3: Who Has Authority, and Where Must Automation Stop?

Governance becomes useful when it determines what systems and people may do. Allocating authority by business impact, reversibility and uncertainty is more effective than approving automation simply because it is technically possible. The NIST AI Risk Management Framework’s discussion of human–AI interaction supports clearly defined roles and responsibilities (Tabassi, 2023). A material use case should have a named outcome owner, understood boundaries and an escalation route. Security, service operations, legal, privacy and procurement should contribute where their responsibilities are engaged, rather than assuming that the technology team can accept every consequence alone.

Define Decision Rights Before Enabling Action

Bounded automated response can be valuable when it contains activity within approved limits. Isolating a device, restricting a session or initiating a recovery workflow may be appropriate, but the impact depends on the service and timing. Patching and restoration still require testing, change control and rollback proportionate to business impact. Product descriptions of rapid containment establish what a supplier claims its service can do; they do not establish that the same action is safe in every environment. Buyers should verify the deployed version’s defaults, approval settings, permitted actions and overrides before switching on autonomous features.

Human oversight is not a ceremonial approval step. Reviewers need time, competence, relevant evidence and authority to disagree. High-volume prompts that encourage routine approval can create the appearance of control without meaningful challenge. For ambiguous or consequential cases, the operating model should specify who reviews the recommendation, what evidence is available and what happens if no authorised reviewer is reachable. Low-impact, well-tested actions can remain automated within limits, while decisions affecting critical availability, sensitive access or material customer outcomes warrant stronger approval and escalation.

Pause and recovery arrangements matter as much as permission to act. The organisation should know who can suspend automation, how actions are recorded, what can be reversed and how affected services are restored. Uncertainty should trigger a defined response rather than an improvised debate during an incident. In fraud operations, for example, high-value or ambiguous transactions can be routed for review while tested, lower-risk decisions proceed automatically. The review capacity and customer consequences must be part of the design, otherwise a technically effective detector can simply create an unmanageable queue.

Capability development should follow these responsibilities. Analysts need to interpret outputs, validate alerts, recognise failure modes and preserve independent investigation skills. Non-technical colleagues need to understand where AI is used, what information it processes and how to raise concerns or challenge outcomes. Training should reflect actual systems and scenarios, including operation without automated advice. Leaders should fund the time required for this transition rather than assume that a licence creates competence. Retaining skilled people is part of the control environment, not an incidental cost that automation necessarily removes.

Individuals also need a test they can use before submitting information or relying on an AI answer:

• am I authorised to use this tool for this purpose?
• am I entitled to share the information?
• can I verify the material claims?
• could I explain and defend my use to someone affected?

In security work, that means using approved environments for sensitive evidence, checking original records before repeating generated conclusions and acknowledging material uncertainty or AI assistance where context, policy or professional duties require it. The Association for Computing Machinery (ACM) grounds professional conduct in avoiding harm, honesty, privacy, confidentiality, competence and appropriate review (Association for Computing Machinery, 2018, §§ 1.2–1.3, 1.6–1.7, 2.2 and 2.4–2.6). These questions apply those principles; they are not an assurance that every permitted use is ethically justified.

Translate Privacy, Fairness and Legal Duties into Controls

Responsible-AI principles need operational expression. Transparency means useful information about monitoring and consequential automated decisions. Accountability means an owner for errors as well as successful outcomes. Fairness means testing relevant differences in treatment and documenting trade-offs. Privacy means proportionate collection, defined purposes, controlled access and appropriate retention. The voluntary NIST AI Risk Management Frameworkprovides a structure for organising this work (Tabassi, 2023). Adopting its vocabulary, or a supplier’s principles, does not by itself establish that a deployment is trustworthy or legally compliant; controls must be evidenced in the actual operating environment.

A technically effective use of AI can still conflict with the organisation’s purpose or commitments. Before approval, identify which values the proposed use engages, whose interests could be affected and what conduct those values rule out. Convert each relevant commitment into an observable condition: privacy into defined data boundaries, honesty into verified claims and appropriate disclosure, and accountability into an identifiable decision-maker and challenge route. NIST’s AI Risk Management Framework calls for the organisation’s mission and relevant goals for AI to be understood and documented (Tabassi, 2023, MAP 1.3). Making the organisation’s values explicit alongside those goals helps translate that context into approval conditions. These conditions should sit alongside performance criteria: an efficiency gain does not, by itself, settle whether the use is acceptable.

Security monitoring can involve intrusive information, including behavioural or biometric signals. For deployments subject to UK data protection law, the Information Commissioner’s Office explains how accountability, governance and data-protection impact assessment apply to AI systems processing personal data (Information Commissioner’s Office, n.d.). Its guidance is under review following the Data (Use and Access) Act, so the current law and applicable commencement provisions need checking for the deployment. The justification should be specific: what risk requires the data, why a less intrusive approach is insufficient and who may use the result. Purpose, necessity, lawful basis, retention and notice need assessment, with an appropriate data-protection impact assessment where required. Consultation and clear limits on use help distinguish a security control from open-ended surveillance. A tool acquired for one purpose should not quietly become a general mechanism for drawing conclusions about people or making decisions outside its approved scope.

Where values pull in different directions, record the decision rather than hide the conflict in a single score. A hypothetical behavioural-security control might improve detection while collecting information that users reasonably regard as intrusive. Compare it with less intrusive alternatives, involve those affected where practicable, document the remaining uncertainty and decide whether to narrow, defer or reject the proposed use. The United Nations Educational, Scientific and Cultural Organization (UNESCO) offers an ethical impact assessment method that examines whether automation is appropriate, how stakeholders will participate and how effects will be assessed across the lifecycle (United Nations Educational, Scientific and Cultural Organization, 2023). This is a decision aid, not certification that a deployment is ethical or lawful.

Legal assessment must be deployment-specific. Personal-data processing, consequential automated decisions and cross-border operations can engage different obligations. Article 6 and Annex III of the EU AI Act provide high-risk classification rules; they do not make every cybersecurity application high-risk (Regulation (EU) 2024/1689, 2024, art. 6 & annex III). Assessment should also account for the 2026 amending regulation and applicable commencement provisions (Regulation (EU) 2026/1744, 2026). The consolidated text dated 27 July 2026 is a reading aid; the authentic Official Journal acts remain the legal sources. Legal and privacy teams should translate the deployment-specific assessment into procurement conditions, documentation, human-review routes and periodic reassessment. Voluntary guidance can support that work, but is not interchangeable with binding law or a deployment-specific legal conclusion.

Procurement is where many of these commitments become enforceable. Buyers should establish what data the service accesses, where it is processed, what evidence is available, how material changes are communicated and how incidents are supported. Contracts and operating arrangements should reflect the controls on which the investment case depends. If a supplier cannot provide sufficient transparency for a consequential use, the answer may be to narrow the use case, retain additional internal controls or choose a different approach. Assurance should determine the permitted deployment, rather than follow a decision already made.

Organisational approval does not remove individual responsibility, and a personal concern does not make unilateral action the right response. If an AI use appears inconsistent with a professional duty or the organisation’s stated values, describe the specific concern, preserve the relevant facts through approved channels and seek review from the accountable owner or an appropriate ethics, privacy, legal or security contact. Leaders need a usable route for such concerns, a named reviewer and a recorded response. The ACM Code recognises that ethical principles can conflict and calls for accountable, transparent judgement with the public good as the primary consideration (Association for Computing Machinery, 2018). Where concerns remain unresolved, seek appropriate professional advice rather than treating convenience, authority or a system’s recommendation as the final ethical argument.

A practical governance record can bring these requirements together without creating another abstract policy. For each material use, record its purpose, owner, data boundaries, permitted actions, approval thresholds, testing obligations and pause arrangements. Keep the record aligned with the deployed configuration and the supplier relationship. The value lies in making responsibilities visible to those who must act, including during an incident or a service change. If different teams understand the boundary differently, that disagreement should be resolved before deployment rather than discovered when an automated action has consequences.

Decision 4: What Evidence Justifies Investment and Continued Use?

A credible investment case starts with the current position. Without a baseline, leaders cannot distinguish improvement from changes in workload, staffing or reporting. For security operations, useful measures include detection, investigation and containment times, alert quality and analyst effort. Identity and fraud measures should include losses prevented, false positives, customer friction and review delays. Supplier-risk work should show whether monitoring improves prioritisation and leads to completed assurance or remediation, rather than merely producing new scores. The measures need to connect to the outcome the organisation is buying.

Testing should reproduce the conditions that matter: representative data, legitimate unusual activity, relevant attacks, operational constraints and realistic review capacity. Aggregate accuracy is insufficient when the cost of a missed threat differs greatly from the cost of a false alarm. Teams should document thresholds, failure modes and trade-offs, including effects on users and critical services. Evaluation also needs to examine integration and human decisions: a correct recommendation delivered too late, or one that reviewers cannot interpret, may provide little protection. Acceptance criteria should be agreed before the pilot results are known.

For each material AI-enabled control, leaders need a concise assurance view answering six questions: What business outcome does it support? Which accuracy and failure measures show whether it works? What can it do autonomously? Who owns the outcome? How often is it independently tested? How are incidents, bias, drift and overrides reported and addressed? These questions turn responsible-AI commitments into governable evidence and reflect NIST’s Govern, Map, Measure and Manage model (Tabassi, 2023).

Evidence has different strengths. Primary research and standards may establish a method or a broader association; a supplier case study may describe an implementation; product documentation identifies stated capabilities. None automatically proves local effectiveness. Decision papers should identify the source, baseline, period and deployment context behind material claims, and preserve qualifications that affect interpretation. Small pilots can support a bounded next step without demonstrating readiness for enterprise-wide autonomy. Where evidence is uncertain, leaders should record that uncertainty and limit the decision accordingly rather than disguise it through a composite score.

Assurance continues after deployment because data, threats, configurations and working practices change. Rao et al. (2026) identify challenges in monitoring deployed AI systems through practitioner workshops and a literature review. Their report supports attention to real-world behaviour but does not establish a validated universal monitoring method. Monitoring should cover functionality, human factors, security and wider effects, with investigation of drift, incidents and overrides. Retraining is not an end in itself: the objective is evidence that the system remains fit for purpose. Material changes should trigger proportionate reassessment, and persistent failure should lead to correction, restriction or withdrawal.

Values alignment also needs evidence after deployment. Alongside detection and cost measures, review whether information is being used within its approved purpose, explanations remain useful, challenges lead to correction and staff can exercise the authority to pause or escalate. For each material concern, identify who will investigate, what change is required and when continued use will be reconsidered. UNESCO’s ethical impact assessment includes assessment before and during use, while NIST treats risk management as a continuing activity (Tabassi, 2023; United Nations Educational, Scientific and Cultural Organization, 2023). A favourable performance dashboard cannot substitute for examining whether the service still operates within the ethical boundaries on which approval depended.

Senior reporting should be concise enough to inform a decision and specific enough to challenge. The six-question assurance view should show the intended outcome, performance and failure evidence, permitted autonomy, ownership, testing and the handling of adverse events. A favourable status should not conceal unresolved exposure or an untested dependency. Leaders need to know whether the service remains within agreed limits and what decision is required when it does not. That makes assurance a continuing condition of investment rather than a report produced only for approval or audit.

Decision 5: How Should Leaders Move from Pilot to Scale?

The priority is disciplined progress, not indiscriminate adoption or defensive delay. A staged programme allows organisations to learn without granting more authority than the evidence supports. Start with a small number of material problems whose outcomes can be measured and whose risks can be bounded. Senior sponsorship should resolve ownership and dependencies, while delivery teams retain responsibility for realistic testing. A pilot should answer a decision question, whether to proceed, change course or stop, not become a demonstration that must be declared successful to protect an earlier commitment.

A successful pilot is not yet a complete investment case. The continuing commitment includes hosting, integration, data handling, assurance, training and incident support, alongside the people needed to operate and challenge the service. Free and open-source options also require these capabilities; licence price does not determine total operating burden. Leaders should understand exit and migration arrangements, supplier-failure exposure and which controls remain available if the service is withdrawn. Expansion is justified when the demonstrated resilience benefit supports the full operating commitment, not simply when a short demonstration looks impressive.

The first approval gate is use-case selection. Define the business outcome, current baseline, accountable owner and boundaries of the proposed capability. Establish what the system may recommend or execute, where human approval is required and which services or users could be affected. Identify the necessary data, skills and integrations, and compare the proposal with improving existing processes or controls. Approve a pilot only when its scope, evaluation criteria and stop conditions are clear. This prevents an open-ended technology trial from accumulating dependencies before its purpose is agreed.

The second gate is deployment readiness. Require representative testing of performance, security, fairness where relevant, operational capacity and failure recovery. Confirm that approval thresholds work in practice, reviewers can act on the evidence and response actions respect critical-service tolerances. Legal, privacy and procurement assessments should be complete for the intended deployment, and the operating owner should accept the continuing responsibilities. Unresolved limitations need explicit treatment: narrow the scope, add controls or defer deployment. A favourable average result should not override an unacceptable consequence in a material scenario.

The third gate is expansion. Use operating evidence to determine whether benefits persist, costs remain justified and failures stay within agreed limits. Increase scope or autonomy only when the evidence supports that particular change; success in one workflow does not establish readiness elsewhere. Keep approval conditional on continued monitoring, periodic testing, the ability to pause automation and arrangements to reverse actions where possible or recover from their consequences. Material changes to the service, data or supplier relationship should prompt review. Scaling should be a sequence of accountable decisions, not an automatic consequence of completing the pilot.

Longer-range developments belong in the wider resilience plan, but should not displace these immediate decisions. Post-quantum migration, for example, has its own exposure and lifecycle drivers: NIST’s standards and migration resources support identifying vulnerable cryptographic dependencies and planning their replacement (National Institute of Standards and Technology, n.d.). In NIST Report Provides Guidelines for Transition to Post-Quantum Cryptography Standards, NIST explains the urgency of protecting information collected today that may be decrypted in future, making data longevity a relevant planning consideration (National Institute of Standards and Technology, 2026). Cryptographic migration is therefore a distinct resilience programme, not inherently an AI investment case. The same discipline applies to emerging autonomous capabilities: distinguish present evidence from future ambition and sequence investment according to actual organisational risk.

Across the three gates, the leadership test remains the same: does this deployment improve a material outcome, can its limits be explained and controlled, and is someone accountable for continuing evidence that it works? Record the answer and the conditions attached to each approval. This keeps investment in the operating model alongside investment in technology, and makes expansion conditional on governed performance rather than claims of intelligence or autonomy.

Conclusion: Make Resilience the Test, Not Adoption the Target

The next leadership decision should not be which AI product to buy, but which material security outcome to improve; and what evidence would justify trusting a new approach. Start with a bounded problem, an accountable owner and a local baseline. Agree success criteria, failure limits and withdrawal conditions before the pilot; authorise deployment only after representative testing and operational-readiness checks; and expand only when continuing evidence supports the specific change. Fund the people, integration, assurance and fallback arrangements needed to make the control work, not just the technology that makes the demonstration possible.

At the next investment or risk review, require a clear answer to three questions: what will improve, who can authorise or stop consequential action, and how will continuing performance be demonstrated? Expand where the evidence supports it; narrow or stop where it does not. Keep independent verification, strong authentication, skilled investigation and tested recovery at the centre of the operating model. AI should strengthen those foundations, not become a reason to bypass them.

Make the next commitment a measurable resilience outcome, not an adoption milestone. Use AI to equip people to act sooner and challenge more effectively, while keeping low-impact, well-tested actions automated within agreed limits and retaining meaningful review of consequential decisions. Adopt where local value is demonstrated, scale only where continuing evidence supports the proposed scope and autonomy, and preserve the authority and practical ability to pause, reverse actions where possible and change course when systems fail.

💬 Join the Conversation

The evidence base below is intended to support practical discussion rather than prescribe a single model. Which AI-enabled security decision would create the greatest value for your organisation, and what evidence, accountability and human oversight would you require before trusting it at scale? Useful answers will connect technical capability with business outcomes, organisational values and the realities of implementation.

If this article has prompted a useful question or challenged an assumption, bring it to your next investment or risk discussion: which decision would you change, and what evidence would justify that change?

Sources serve different purposes in this article: primary and regulatory materials support legal and standards-based claims; research informs interpretation; and first-party documentation describes supplier capabilities, corporate principles and reported implementation outcomes. Product pages and vendor case studies are not independent validation. The frameworks and knowledge bases also provide practical resources for

📖 Evidence Base and Further Reading

All author–date citations in the article correspond to entries below. Delaney (2022) and Wachter (2024) are additional further reading, not sources cited in the article’s argument. Definition links and appendix product-documentation links are navigational resources rather than author–date research citations. For web readability, publication titles carry the source links and retrieval dates are omitted; the list therefore uses an adapted author–date presentation rather than strict APA 7 reference-list formatting.

• AI Security Institute. (2026, March 31). Harnessing frontier AI for cyber defence.
• Association for Computing Machinery. (2018). ACM code of ethics and professional conduct.
• Delaney, K. (2022, December 6). Seven keys to security resilience. Cisco.
• European Union Agency for Cybersecurity. (2020, December 15). Artificial intelligence cybersecurity challenges.
• Government of the Hong Kong Special Administrative Region. (2024, June 26). LCQ9: Combating frauds involving deepfake.
• Grother, P., Ngan, M., & Hanaoka, K. (2019). Face recognition vendor test (FRVT) part 3: Demographic effects(NISTIR 8280). National Institute of Standards and Technology.
• Heiding, F., Schneier, B., Vishwanath, A., Bernstein, J., & Park, P. S. (2024). Devising and detecting phishing emails using large language models. IEEE Access, 12, 42131–42146.
• (2024). Cost of a data breach report 2024.
• Information Commissioner’s Office. (n.d.). What are the accountability and governance implications of AI?
• Microsoft. (n.d.). Responsible AI: Ethical policies and practices.
• (n.d.-a). MITRE ATLAS.
• (n.d.-b). MITRE ATT&CK.
• National Cyber Security Centre. (2025, May 7). Impact of AI on cyber threat from now to 2027.
• National Institute of Standards and Technology. (n.d.). Post-quantum cryptography.
• National Institute of Standards and Technology. (2026, October 27). NIST report provides guidelines for transitionto post-quantum cryptography
• Palo Alto Networks. (n.d.). Transforming the SOC for Bank Central Asia.
• Rao, A. K., Keller, A. J., Kalra, N., Steed, R., Kwegyir-Aggrey, K., Klyman, K., Staheli, D., & Bergman, A. S. (2026). Challenges to the monitoring of deployed AI systems (NIST AI 800-4). National Institute of Standards and Technology.
• Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 (Artificial Intelligence Act), Official Journal of the European Union, L, 2024/1689 (2024).
• Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI), Official Journal of the European Union, L, 2026/1744 (2026).
• Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology.
• Temoshok, D., Fenton, J. L., Choong, Y.-Y., Lefkovitz, N., Regenscheid, A., Galluzzo, R., & Richer, J. P. (2025). Digital identity guidelines: Authentication and authenticator management (NIST SP 800-63B-4). National Institute of Standards and Technology.
• United Nations Educational, Scientific and Cultural Organization. (2023). Ethical impact assessment: A tool of the Recommendation on the Ethics of Artificial Intelligence.
• Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X., & Hamin, M. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2e2025). National Institute of Standards and Technology.
• (2025). 2025 data breach investigations report.
• Wachter, S. (2024). Limitations and loopholes in the EU AI Act and AI liability directives: What this means for the European Union, the United States, and beyond. Yale Journal of Law & Technology, 26(3), 671–718.

Appendix Documentation and Licensing Resources

• Arize AI. (n.d.-a). Phoenix: Elastic License 2.0.
• Arize AI. (n.d.-b). Self-hosting.
• Arize AI. (n.d.-c). What is Arize Phoenix?
• Fiddler AI. (n.d.). Agentic observability.
• Greenbone. (n.d.). Greenbone community containers.

Appendix A is an optional procurement companion. It translates the article’s evidence, governance and human-oversight principles into evaluation criteria for a representative tool landscape.

Appendix A: Representative Tool Landscape

The entries are illustrative rather than ranked, exhaustive or endorsed, and cover different architectures, deployment models and market segments. The commercial profiles cover capabilities, deployment, evidence and executive considerations; the free and open-source profiles emphasise operating requirements and evidence limitations. The Microsoft entry is a corporate-policy resource and OSCAL is a standard, not a directly comparable product. Inclusion indicates relevance to the stated use case, support in first-party documentation and sufficient distinctiveness to aid comparison. Buyers should verify current licensing, ownership, regional availability, integration requirements, data handling and lifecycle status, and should test material claims in their own environment. Free, open source and source available are not interchangeable: rights and restrictions must be checked for the selected component and version. First-party documentation establishes what a supplier or project says its product can do; it does not prove that the same outcome will be achieved in every organisation.

A1. AI-Enabled Detection and Response Platforms

The profiles below illustrate three commercial approaches: organisation-specific behavioural analytics; endpoint-led extended detection and response (XDR), which combines signals across security domains; and cloud-native security information and event management (SIEM), which collects and analyses security logs and events, with generative-AI assistance. They do not constitute a complete market comparison, and organisations should also assess the security operations capabilities already available through their principal cloud, identity and productivity platforms before procuring an additional service.

Terminology used in the profiles: a security operations centre (SOC) monitors and responds to threats; software as a service (SaaS) is a cloud-delivered service model; multi-factor authentication (MFA) uses more than one authentication factor; governance, risk and compliance (GRC) connects oversight, risk management and obligations; third-party risk management (TPRM) addresses supplier and partner exposure; an application programming interface (API) connects software services; a vehicle security operations centre (vSOC), as used in the Upstream profile, supports monitoring and incident response for connected vehicles and mobility services; and an original equipment manufacturer (OEM) produces equipment or components. SOC 2 refers to a service-organisation controls reporting framework, not a type of security operations centre.

• Darktrace Behavioral Defense Platform. Focus and capabilities: Behavioural detection, investigation and autonomous response across AI systems, email and collaboration tools, networks, cloud and operational technology, with identity and endpoint signals contributing context. Adaptive AI develops an organisation-specific behavioural profile, and Real-Time AI Analyst supports cross-domain investigation. Response coverage depends on the selected products and integrations. Deployment and commercial model: Commercial platform with sensors, collectors and integrations spanning cloud, on-premises and operational environments; confirm hosting and management options for the selected components. Evidence basis: First-party product documentation; detection efficacy, response outcomes and operational impact should be validated independently. Executive consideration: Assess response guardrails, explainability, domain coverage and alignment between autonomous actions and business-critical service tolerances.
• Palo Alto Networks Cortex XDR. Focus and capabilities: Endpoint-led XDR combining endpoint, network, cloud, identity and email telemetry with behavioural analytics, investigation and response. Palo Alto Networks also markets Agentic Endpoint Security and the Cortex AgentiX Assistant alongside this offer; availability, entitlements and dependencies should be established for the selected deployment rather than assumed to be part of every Cortex XDR subscription. Deployment: Cloud-delivered with endpoint agents and integrations; options and dependencies vary across the wider Palo Alto Networks estate. Evidence basis: First-party product documentation; benchmark coverage, investigation quality and response performance should be validated in the intended environment. Executive consideration: Validate data-source coverage, platform dependencies, investigation transparency and controls applied to agentic response.
• CrowdStrike Falcon Next-Gen SIEM and Charlotte AI. Focus and capabilities: Security-data aggregation, AI-assisted detection and investigation, and workflow-based response. The broader offer includes Charlotte AI investigation assistance and Falcon Onum data pipelines for ingesting, transforming, enriching and routing data. These are named capabilities across the Falcon portfolio, not a statement that all are included in every SIEM subscription. Deployment: Cloud-native SaaS with endpoint, identity, cloud and third-party data integrations. Evidence basis: First-party documentation and vendor-reported performance; require reproducible tests using representative organisational data and confirm current feature availability. Executive consideration: Examine data-retention economics, third-party ingestion, workflow approvals and whether reported performance can be reproduced locally.

A2. Adaptive Authentication and Fraud-Prevention Platforms

Authentication platforms and fraud-prevention platforms address related but different risks. Authentication services determine whether access should be granted or challenged, while specialist fraud platforms analyse behavioural, device and transaction signals across a wider customer journey. Buyers should compare products within the relevant use case rather than treating every entry below as a direct substitute.

• BioCatch. Focus and capabilities: Behavioural and device intelligence for account opening, account takeover, scams and transaction fraud. It analyses application, behavioural, device and network signals in real time. Deployment and commercial model: Cloud-delivered commercial service integrated with digital-banking and fraud-management workflows. Evidence basis: First-party materials and vendor-reported adoption; independently validate fraud-loss reduction, false positives and customer impact. Executive consideration:Review behavioural-data governance, explainability, customer redress, regional privacy requirements and current ownership or control arrangements during due diligence.
• Okta Adaptive MFA. Focus and capabilities: Risk- and context-aware workforce authentication with phishing-resistant options. It evaluates device posture, network, location and user behaviour and supports FastPass and FIDO2/WebAuthn authenticators. Continuous risk assessment and response through Identity Threat Protection are a related capability, not an entitlement implied by Adaptive MFA alone; confirm the selected subscription and configuration. Deployment: Cloud identity service with device, application and security-platform integrations. Evidence basis: First-party documentation and standards-based authenticator support; test policy effectiveness, recovery and user experience. Executive consideration: Prioritise phishing-resistant authenticators, define step-up thresholds and test recovery, exception and session-revocation processes.

Lifecycle due diligence: Products without a current first-party statement confirming availability, support horizon and strategic status should not be treated as current recommendations. Existing customers should obtain a written roadmap and validated support dates before further investment; prospective buyers should evaluate supported alternatives and test resilience to synthetic voice and other emerging threats.

A3. Third-Party and Supply-Chain Risk Platforms

The first two profiles address general enterprise third-party cyber-risk management. The final profile is included as a sector-specific example of connected-product and mobility security, not as a direct alternative. Organisations in other sectors should identify equivalent specialist platforms only where sector telemetry, safety or regulatory requirements materially change the risk model.

• SecurityScorecard TITAN AI. Focus and capabilities: Third-party cyber-risk management, ratings, assessments and remediation, including continuous vendor and nth-party monitoring, AI-assisted questionnaire and SOC 2 review, automated risk tiering, breach and ransomware indicators, and vendor-facing remediation plans. Deployment: Cloud-delivered SaaS with supplier, procurement, GRC and workflow integrations. Evidence basis: First-party documentation and vendor-generated ratings; validate attribution, correction processes and outcome correlation independently. Executive consideration: Treat external ratings as decision support rather than proof of control effectiveness, and establish challenge, correction and supplier-engagement processes.
• Bitsight Third-Party Risk Management. Focus and capabilities: Continuous third- and fourth-party visibility, vendor assessment and vulnerability response, including AI-automated assessments, SOC 2 summarisation, daily ratings, fourth-party discovery and exploitation-likelihood context. Deployment: Cloud-delivered SaaS with assessment, procurement and GRC integrations. Evidence basis: First-party documentation and vendor-generated risk intelligence; independently test entity attribution and decision usefulness. Executive consideration: Test coverage of critical suppliers, integration with procurement and the evidence used to translate ratings into business decisions.
• Sector-specific example: Upstream Security. Focus and capabilities: Automotive and smart-mobility cybersecurity rather than general enterprise TPRM. It provides cloud-based monitoring of vehicles, fleets, mobility services and APIs, with AI-powered threat detection, digital-twin context, vSOC workflows and regulatory support. Deployment: Specialist cloud platform integrated with vehicle, fleet, mobility-service and API telemetry. Evidence basis: First-party documentation; validate relevance and performance against automotive safety, telemetry and regulatory requirements. Executive consideration: Use where connected mobility is material and assess telemetry access, safety boundaries, OEM and supplier responsibilities, and integration with vehicle incident response.

A4. AI Assurance, Monitoring and Governance Platforms

AI governance, observability, evaluation and runtime security are overlapping but distinct capabilities. Governance platforms organise accountability, policies and evidence; observability platforms monitor model and application behaviour; evaluation tools test performance and failure modes; and runtime controls intervene when harmful behaviour occurs. Buyers should define which of these outcomes they require before comparing products.

• IBM watsonx.governance. Focus and capabilities: Lifecycle governance for predictive, generative and agentic AI across IBM and third-party environments, including model and agent inventories, factsheets, fairness and drift monitoring, evaluation, policy mapping and compliance evidence. Deployment: Enterprise software and services integrated with IBM and third-party AI environments; options depend on the selected architecture. Evidence basis: First-party documentation; validate third-party coverage, control effectiveness and audit evidence with representative models and agents. Executive consideration: Confirm coverage across the model estate, integration with GRC and whether controls generate audit-ready evidence.
• Fiddler AI. Focus and capabilities: AI observability and security for predictive models, LLM applications and agents. Model monitoring covers performance, drift, data quality and explainability; agentic observability documentation describes workflow traces, model calls, tool usage, errors and dashboards. Fiddler also offers guardrail and policy-enforcement capabilities; these are distinct from observing or explaining behaviour and depend on the selected integration. Deployment: Commercial platform integrated with development and production environments; confirm hosting, instrumentation and enforcement coverage. Evidence basis: First-party product materials and technical documentation; independently assess alert quality, explanatory usefulness and coverage of the organisation’s model and agent types. Executive consideration: Examine root-cause analysis, sensitive-data handling, enforcement failure modes and integration with incident and model-risk workflows.
• Arize AI: Arize AX and Phoenix. Focus and capabilities: Arize AX is the commercial AI engineering platform; Phoenix provides tracing, evaluation, prompt workflows, datasets and experiments for LLM applications and agents. The Phoenix documentation explains these functions, including inspection of model calls, retrieval and tool use. Traditional model drift and performance monitoring should be assessed against the chosen Arize product, rather than assumed to be identical in Phoenix. Deployment: Commercial Arize AX deployment options plus self-hosted Phoenix. Phoenix’s source is inspectable and self-hosting is free, but its Elastic License 2.0 restricts offering substantial functionality to third parties as a hosted or managed service; it should not be described as unrestricted open-source software. Evidence basis: First-party technical documentation and inspectable components; formal governance effectiveness still requires organisational controls and independent assurance. Executive consideration: Clarify product, licensing and deployment boundaries, protect trace data, and determine how observability findings feed approval, risk acceptance and remediation.
• Ecosystem reference: Microsoft’s responsible-AI approach (Microsoft, n.d.). Focus and scope: A corporate overview of Microsoft’s responsible-AI principles, practices, policies and related resources, rather than a specification of controls available in a particular service. Deployment and commercial model: The overview is publicly available; product deployment options, licences and controls require separate service-level documentation. Evidence basis: First-party corporate materials describe commitments and approach, not independent assurance or proof of a particular capability. Executive consideration: Identify the exact services and controls in scope, obtain their current documentation, map them to the organisation’s assurance requirements and commission independent testing for material use cases.

A5. Free and Open-Source Options for Small and Medium-Sized Enterprises (SMEs)

Free and open-source software can give small and medium-sized enterprises credible access to security monitoring, incident response, vulnerability management, identity infrastructure, software-supply-chain assurance and responsible-AI testing. These are distinct functions, and inclusion here does not mean that every tool uses AI: an identity provider does not replace fraud analytics, a vulnerability scanner does not replace endpoint protection, and an investigation platform does not replace a staffed security operation. Free software is also not cost-free to operate. Organisations must still fund hosting, secure configuration, integration, patching, backups, monitoring, staff training and incident support. The options below are illustrative rather than endorsed and should be compared by designed use case, operational burden and evidence, not licence price alone.

A5.1 Security Operations and Identity

In the profiles that follow, single sign-on (SSO) allows one authentication session to support access to multiple applications; Security Assertion Markup Language (SAML) supports exchange of authentication and authorisation information; continuous integration and continuous delivery (CI/CD) describe automated software-integration and delivery practices; and a software bill of materials (SBOM) records software components. The Open Worldwide Application Security Project (OWASP), Open Source Security Foundation (OpenSSF) and Open Security Controls Assessment Language (OSCAL) identify, respectively, a security community, a software-security foundation and NIST’s machine-readable assessment language. OpenVAS stands for Open Vulnerability Assessment System.

• Wazuh. An open-source SIEM and XDR option for endpoint monitoring, file-integrity monitoring, vulnerability detection, threat hunting, compliance reporting and automated response. It can be self-hosted, with commercial cloud and support options also available. A typical deployment includes a server, indexer, dashboard and endpoint agents. Operating requirement: Moderate to high, because SMEs must own infrastructure, integration, rule tuning, alert triage and patching. Evidence, support and limitation: First-party documentation and inspectable components support the description, but detection efficacy and operating effort require local validation. Buyers should also assess release cadence, security-update processes, community health and the availability of paid support or a capable service partner. Wazuh is not a turnkey managed SOC.
• Security Onion. A platform for network and host visibility, intrusion detection, packet capture, threat hunting, log management and case management. It can use standalone or distributed sensors across local or cloud infrastructure. Buyers should verify the licences and commercial-feature boundaries for the selected version and components before treating the distribution as wholly open source. Operating requirement: High, with significant storage, sensor-design and analyst needs. Evidence and limitation: First-party project documentation supports the feature set, but effectiveness depends on sensor placement, telemetry coverage and analyst capability; it is best suited to SMEs with in-house expertise or a capable service partner.
• Velociraptor. A free, open-source option for endpoint monitoring, threat hunting, digital forensics, evidence collection and incident response. It uses a self-hosted server and lightweight cross-platform clients, and supports distributed deployments and offline collectors. Operating requirement: High, requiring forensic and incident-response expertise and careful control of powerful endpoint actions. Evidence and limitation: First-party documentation and inspectable code support the profile; it is an investigation and response tool, not a complete substitute for preventive endpoint protection or a staffed SOC.
• Greenbone Community Edition/OpenVAS. An open-source community vulnerability-management stack for network and system scanning, assessment and reporting; OpenVAS is its scanning component, while Greenbone also offers commercial products, feeds and support. Self-hosted deployment depends on maintained releases and vulnerability-test feeds. The official community-container guide is intended for testing and familiarisation, not production setups; its example deployment must not be treated as production-ready. Operating requirement: Moderate to high, including secure deployment, credentialed-scan design, feed maintenance, asset scoping and remediation ownership. Evidence and limitation: Official documentation and inspectable source support the description, but scan coverage and false positives require local validation, scanning can disrupt fragile systems, and production architecture and support arrangements require separate assessment.
• authentik. A self-hosted identity provider for SSO, MFA, passkeys, conditional-access flows and application federation. Authentik Security offers an open-source edition and a distinct source-available Enterprise edition with additional features and commercial support; it is commonly deployed in containers with application and directory integrations. Operating requirement: Moderate, requiring resilient hosting, secure administration, backups and monitoring. Evidence and limitation: First-party documentation supports the profile, but protocol interoperability, recovery and administrative controls should be tested; identity infrastructure is not equivalent to specialist behavioural-fraud analytics.
• Keycloak. A free, open-source identity and access-management platform for SSO, federation, MFA, OpenID Connect, OAuth 2.0, SAML and fine-grained authorisation. It can be deployed as a server, container or Kubernetes workload, typically with an external database, proxy, monitoring and high-availability design. Operating requirement: High, because production use requires identity architecture, hardening, resilient hosting, patching and tested recovery. Evidence and limitation: Official documentation and inspectable source support the profile, but misconfiguration can create systemic access risk and Keycloak is not a managed identity service by default.

A5.2 Software Supply-Chain Assurance

• OWASP Dependency-Track. A free, open-source platform for software-component and supply-chain risk management using CycloneDX software bills of materials, vulnerability intelligence, licence analysis and policy controls. It is self-hosted and commonly integrated with CI/CD pipelines, SBOM generators and issue-management workflows. Operating requirement: Moderate, requiring SBOM generation, vulnerability triage and clear remediation ownership. Evidence and limitation: OWASP project documentation and inspectable source support the profile; the platform identifies component risk but does not prove that an application is secure or that every finding is exploitable.
• OpenSSF Scorecard. A free, open-source tool for automated checks of security practices in open-source projects, including branch protection, code review, dependency updates and release controls. It can run through the command line, GitHub Actions or a public data service with minimal infrastructure for basic use. Operating requirement: Low to moderate, although results must be interpreted and integrated into procurement or development decisions. Evidence and limitation: The OpenSSF methodology and inspectable checks support the profile, but scores are heuristic indicators rather than proof that a project is secure, maintained or appropriate for a particular risk context.
• NIST OSCAL. An open standard for machine-readable control catalogues, implementation evidence, assessment plans and results. Free schemas, models and community tools can support compliance automation, but OSCAL is implemented through separately selected open-source or commercial tooling rather than delivered as a hosted service. Operating requirement: High, requiring technical implementation, framework mapping and integration with evidence workflows. Evidence and limitation: Primary-source NIST specifications and examples support the profile; OSCAL is an enabling standard, not a finished GRC platform, and its value depends on the surrounding tooling and governance process.

A5.3 AI Assurance and Testing

• AI Fairness 360. A free, open-source Python and R toolkit for measuring, explaining and mitigating bias in datasets and machine-learning models. It is embedded in self-managed data-science notebooks, pipelines and validation processes. Operating requirement: Moderate to high, requiring data-science capability, appropriate fairness definitions and governance of trade-offs between metrics. Evidence and limitation: The first-party repository and inspectable algorithms support the profile, but fairness conclusions still depend on data, metric choice and human judgement; it is not a complete governance or legal-compliance solution.
• Fairlearn. A free, open-source Python package for assessing and mitigating fairness-related harms in machine-learning systems. It can be used in notebooks, development pipelines and model-assessment workflows. Operating requirement: Moderate, requiring statistical expertise, representative data and accountable decisions about relevant groups and performance trade-offs. Evidence and limitation: Official documentation and inspectable source support the profile, and the project explicitly frames fairness as sociotechnical; metric results alone do not determine whether a system is lawful, ethical or appropriate.
• garak. A free, open-source Apache 2.0 vulnerability scanner and red-team probing tool for large-language-model applications, maintained by NVIDIA and community contributors. It runs from the command line against local or hosted models and services; some targets require paid API access. Operating requirement: High, requiring authorised scope, safe test environments, model-security expertise and skilled interpretation. Evidence and limitation: Official documentation, an active repository and inspectable probes support the profile, but findings require expert validation and do not replace threat modelling, manual red teaming or production monitoring.

Procurement checklist: Before shortlisting any platform, confirm six points: the business outcome and use case; the data and systems the service can access; the deployment and integration model; the evidence supporting claimed performance; the internal skills and continuing operating cost required; and the exit, migration and supplier-failure plan. Apply the same questions to commercial, free and open-source options.

Readers should use the profiles as a starting point for due diligence and apply the procurement checklist above to commercial, free and open-source options alike.