AI Controls, Audit Streaming and Restore Drills

Third-party AI is on by default. Under Settings, Security & Devices, AI & Data, an administrator with edit-settings unticks Use third-party AI for summaries, assistants and analysis and clicks Save, and from that moment nothing is sent to any AI provider from any in-app feature. The switch sits on the single path every language-model call goes through — dashboard and module insights, the in-app assistant, helpdesk drafts and summaries, quotation analysis, supplier prequalification scoring, forecast narratives, workflow builder suggestions and procurement insights — so no feature can skip it. Features keep working and show their figures without the written summary.

The same page answers the next two questions a reviewer asks. Who receives what lists each AI provider in use with its purpose, region and data, read from the same published sub-processor register as the website, so the two cannot disagree. Calls in the last 30 days lists calls per provider and purpose with the time of the last one; only the provider, the purpose and the length of the request are logged, never the request or the answer. Switching AI off or on is itself an audit-log entry. The website and Academy assistants answer visitors to the public site, not your workspace, so they sit outside this switch.

In practice: a health NGO’s data protection officer must confirm that no beneficiary information reaches an AI provider. The administrator switches third-party AI off, screenshots the page, and a week later exports the audit log entry showing who switched it off and when. The usage log has not grown since that date. Program staff still see stock-out risk figures on the dashboard; only the paragraph summarising them is gone. If the organization later decides to allow AI, the same switch turns it back on and the log shows exactly which features started calling which provider.

Open Settings, Security & Devices, Audit Log Streaming and pick a Format. JSON over HTTPS posts batches of events with your token as a Bearer header and an X-Awra-Signature HMAC-SHA256 of the body, so your receiver can check the batch came from AWRA. Splunk HTTP Event Collector sends one HEC event per audit entry with source type awraops:audit. Datadog Logs intake sends with your API key under service awraops-audit. Enter the HTTPS endpoint and the token — the token is write-only and encrypted at rest — tick Stream audit events and Save, then use Send a test event to prove the destination works without waiting for activity.

Events go out every minute, in order, from a stored position that only moves after the destination answers with success. A failed batch is retried with growing gaps up to an hour apart, the error is shown on the page, and nothing is skipped. Each event carries the actor, action, module, route, IP address, subject and metadata plus chain_sequence, previous_hash and row_hash, so the receiving side can check that every event follows on from the one before and that none was altered. Endpoints must be public HTTPS addresses; private and internal addresses are refused and redirects are not followed.

In practice: a bank-owned microfinance company’s security team runs Splunk Cloud. They create an HEC token, paste the collector URL and token into AWRA, and leave Start from now off so the whole existing audit log is sent first. Waiting to send drops from 180,000 to zero over the next few hours. They then write a Splunk search that alerts when chain_sequence skips a number for any organization. A month later their collector is down for a maintenance window; the page shows the error and a growing backlog, and when the collector returns the backlog drains in order with no gap in the sequence.

A backup nobody has restored is a hope, not a backup. A restore drill takes the newest database backup, restores it into a separate scratch database — the drill refuses to run if that names the live database — times it, compares what came back with the live database, records the result and empties the scratch database again. It is a control of the AWRA deployment, not a workspace setting: it is off until the deployment names a scratch database and switches it on, then runs every Sunday, and the results page is visible to the system owner only.

A drill passes only if the import finished cleanly, the core tables — organizations, users, roles, permissions and migrations — came back and are not empty, the backup holds at least 90 percent of the live tables (so a dump cut short by a full disk fails), and the restore finished within the recovery time objective, 60 minutes unless the deployment sets another figure. It records two numbers: recovery time, how long the restore took, and recovery point, how old the backup was when the drill started — how much work a restore at that moment would lose. Row counts for items, customers, vendors, purchase orders, invoices and audit entries are kept beside the live counts.

In practice: a procurement questionnaire asks “When did you last test a restore, and what was your RTO and RPO?”. The honest answer names the latest drill on the deployment that serves you, its recovery time and recovery point, and whether it passed — and if drills are not configured there, says so rather than quoting a policy. Pair it with your own controls: audit log streaming gives you a copy of the trail outside AWRA, and an administrator can export your organization’s data at any time, so your evidence and your data do not rest on one party.