CIO Deep Dive: SOC 2, GDPR, EU AI Act and DORA Evidence

What an auditor actually asks

Auditors do not ask whether you use AI responsibly. They ask for evidence, and the evidence they accept is the same shape whichever framework they are working from. For a person touching a system of record you already have it: the identity provider says who they were, the application log says what they did, the approval workflow says who signed off. For an agent, most organisations have a chat transcript and a vendor's word.

The fix is not a new framework. It is to give an agent's actions the same evidentiary shape a person's already have, and to do it at the one point every agent action passes through: the tool call.

The evidence pack: one record per call

An evidence pack is the set of records an auditor can pull for any period, any team or any agent. Each record is one tool call, and it needs these fields:

Nothing here is exotic. It is a web-server access log with three additions: the human principal behind the session, the policy decision, and the approval. Those three are what the frameworks below keep asking for.

Mapping the record to each framework

SOC 2

The Trust Services Criteria most exposed by agents are CC6 (logical access), CC7 (system operations and monitoring) and CC8 (change management). CC6 wants to know that access is provisioned and removed on a rule: entitlement by identity-provider group answers it, because a joiner or leaver changes access the moment the group changes. CC7 wants monitoring of activity and a way to investigate: the per-call record with a SIEM feed is that. CC8 wants changes to be authorised: a policy that holds every write for approval, and records the approver, is the control and the evidence in one.

GDPR

Article 5 asks for data minimisation and purpose limitation; Article 30 asks for records of processing; Article 32 asks for security measures appropriate to the risk; Article 35 asks for an impact assessment when a new technology processes personal data at scale, which an agent reaching your CRM is. The redacted-arguments field is minimisation you can show. The per-call record, grouped by tool and system, is a record of processing you did not have to write by hand. The policy engine deciding on arguments, not just tool names, is the security measure an assessor will ask you to demonstrate.

EU AI Act

Obligations for most high-risk uses apply from 2 August 2026, and the articles that bite for a deploying enterprise are 12 (logging), 13 (transparency to the deployer), 14 (human oversight) and 26 (deployer obligations, including using the system under human oversight and keeping the logs it generates). Whether a given agent is high-risk is a classification you have to make, but the evidence you will want exists either way: automatic logging of each action, a documented point at which a person can intervene, and proof that they did. The approver field is your Article 14 evidence. The per-call log is your Article 12 evidence. Keep it for the period the regulation and your sector require.

DORA

For financial entities DORA has applied since 17 January 2025. Its ICT risk-management and third-party provisions treat an agent calling a core system as ICT activity like any other: it must be logged, its providers must be in the register of ICT third-party arrangements, and incidents must be classifiable and reportable. An agent that can only reach systems through a governed connector gives you one place to log, one provider to register, and a record that distinguishes an agent error from a person's.

Worked example: a supplier bank-detail change

Someone in accounts payable asks their assistant to update a supplier's bank details from an email the supplier sent. This is the classic invoice-fraud vector, and it is exactly the kind of action an agent makes faster.

1. The assistant reads the supplier record (read tool, allowed by the AP group's policy, logged).
2. It proposes the write. The policy for update_supplier_bank_details is "hold for approval by the AP team lead" regardless of who asked. The call is held.
3. The team lead sees the proposed change, the source email and the old value in the approval message, checks by phone, and releases or refuses it. Their identity and timestamp land on the record.
4. The write executes; the supplier's IBAN is redacted in the stored arguments; the record is hash-chained and streamed to the SIEM.

Six months later an auditor asks how bank-detail changes are controlled. You export every call to that tool in the period: each one shows the requester, the approver, the decision and the time. That is the whole answer, for SOC 2 CC8, for the EU AI Act's human-oversight article, and for a DORA incident review if the change was ever wrong.

Building it in a week

1. Connect the identity provider. Entitlement follows the groups you already maintain. This is the day-one step and it is what makes CC6 automatic.
2. Expose two or three systems for one team. Most have an MCP server already. Start with the team whose work has an obvious approval step (AP, HR changes, customer credits).
3. Write the policy on the writes. Reads open, writes held for approval, bulk operations denied. Name the approver group.
4. Turn on redaction and the SIEM stream. Decide what is masked in stored arguments before the first real call.
5. Pull the pack. After a week, export the records and hand them to whoever runs your next audit. If they can read it without a walkthrough, you are done.

That is what Palma provides: one governed connector per person, assigned by identity-provider group, with policy on the actual arguments, approval on the calls that need it, redaction, a tamper-evident log and a SIEM feed. The evidence pack is a by-product of running it, not a project on top. If you would like to see one for a workflow of yours, book thirty minutes.