What regulators expect when AI joins the SOC
Regulated organisations can use AI in the SOC, provided they can show where security data goes, who made each decision, what evidence it rested on, and how the AI itself is governed. Banks, healthcare providers, government bodies and operators of critical infrastructure face different rules, but supervisors tend to ask the same underlying questions of any new technology that touches sensitive data or important decisions.
Those questions are familiar from outsourcing and from existing security tools. Is the data handled where it is allowed to be? Is a named person accountable for decisions? Can you prove what happened, after the fact? Has the supplier been assessed? What happens if it fails? An AI analyst raises them in sharper form, because it reads a wide range of sensitive records and produces judgements that people act on.
This guide sets out how to answer those questions in general terms. It is not legal advice. Your own regulators, legal team and compliance function decide what applies to you, and the specific rules vary by sector and country.
Where security data lives and who processes it
Security data is personal data, and often more. Alert records carry user names, email addresses, internal addresses, file names that reveal patients, clients or cases, and command lines that reveal how systems work. Many regulated organisations have rules on where such data may be stored and processed, and on which third parties may see it.
Map the flow before you choose a platform. Where are alerts collected from, where are they investigated, where does the AI model run, and where are the results stored? An AI platform that sends alert data to an external model provider adds another processor, possibly in another country. A platform that runs its model inside your own environment, on your own hardware, keeps the data where it already is, which makes the residency question much simpler to answer.
- Where the AI model runs, and whether any external AI service is called
- Whether external fallback can be switched off, and who can switch it back on
- Where investigation records, evidence and reports are stored, and for how long
- Which vendor staff, if any, can see your data, and how that access is logged
- How the data flow appears in your records of processing
How to keep a human decision on record
Supervisors are wary of important decisions made by software with no accountable person behind them. In a SOC, the cleanest way to meet that concern is to keep the AI’s role advisory: it investigates and recommends, and a named person decides what to do and records the decision.
That design matters most for actions with business impact. Taking a payment server offline, disabling a clinician’s account or isolating a control-room workstation can harm customers, patients or the public. When a person approves each such action, with the AI’s evidence in front of them and the approval recorded, you can show who decided, on what basis and when.
Keep the human decision meaningful. A reviewer who approves a hundred verdicts an hour without reading them is a signature, not oversight. Set review expectations by risk, track how long reviews take, and make it easy to disagree with the AI.
What audit evidence to keep for AI-assisted triage
When an auditor or supervisor asks about an alert, you should be able to show the whole story: what fired, what the AI looked at, what it concluded, who reviewed it, what they decided and when. If any link is missing, you are relying on memory.
Keep the evidence itself, not just the conclusion. An investigation record that cites the specific log entries, lookups and searches behind a verdict lets an auditor test the reasoning. Keep changes too: if a reviewer changed the AI’s verdict, the record should show both, and the reason given.
- The original alert and the rule that raised it
- Each question the AI asked and each record it collected
- The AI’s verdict, confidence and reasoning, as first given
- The reviewer’s name, decision and any change to the verdict, with reasons
- Approvals for any action taken, and who took it
- Changes to detection rules: who approved each, and when
- Reports shared with management, customers or supervisors
How to govern the model and the data
Treat the AI model as a system with its own lifecycle. Know which model is in use, who supplies it, how it was adapted, and when it changes. A model update can change verdicts, so updates should go through the same kind of change control as a rule change, with testing on known-answer alerts before and after.
Be clear about what the model learns from. If corrections made by your analysts improve later investigations, that learning should stay inside your organisation and be visible: you should be able to see what has been remembered and remove anything wrong. If your data trains a model shared with others, that needs explicit agreement and a place in your risk assessment.
Monitor performance over time. Keep simple measures, such as agreement between the AI and reviewers, the share of unsure verdicts and the share of verdicts changed, and review them on a schedule. A drift in those numbers is an early warning that something has changed in the model, your data or your environment.
How to get an AI SOC through a third-party risk review
Most regulated organisations will put an AI SOC supplier through a third-party risk review. Make it easier by gathering the answers early. Reviewers will want to know the supplier’s security practices, where data goes, which subcontractors are involved, how access is controlled, how incidents are reported and what happens if the supplier fails or the contract ends.
The deployment model shapes the review. A platform hosted by the supplier is reviewed like other cloud services, with attention to the supplier’s controls and staff access. A platform that runs fully on your own hardware, model included, shifts much of the review to your own controls, which you already understand. Ask for evidence rather than assurances, and do not accept claims of certifications or regulatory approval without seeing the documents.
Plan the exit as part of the review. How do you export investigation records, how is data deleted, and how quickly can you return to working without the platform?
How to document the AI’s role in your SOC
Write a short, plain description of what the AI does and does not do, and keep it current. It helps your own staff, your auditors and your supervisors, and it forces clarity on the boundaries that matter.
Keep it to a page or two, owned by a named person, and review it whenever the platform, the model or the way your team uses it changes. Link it from your risk register and from the procedures analysts follow, so that the description and the practice stay the same.
- What the AI does: which alerts it investigates and what data it reads
- What it does not do: for example, no actions on systems without approval
- Who reviews its verdicts, and to what standard
- Where the model runs and where data is stored
- How the model is changed, tested and monitored
- How corrections are recorded and used
- How the AI’s role appears in incident reports and risk registers
How armor360 approaches it
armor360 is built for in-house teams, providers and regulated organisations. It runs on its own AI model, fine-tuned by our team, and can run fully on your own hardware, the AI included, so alert data need not leave your environment; external AI fallback can be switched off. It can also be hosted for you.
It takes no response actions: it investigates, gives a verdict with cited evidence, recommends, and tells a person. People decide and act, and the audit trail keeps who approved what and when. Switching a detection rule off needs two administrators, and investigations can be shared as reports in HTML, Word or PDF.