Security, Compliance, and Recovery

Security is not only login. In AWRA, access is shaped by roles, permissions, MFA, device trust, session control, plan entitlements, and sensitive action throttles.

A secure workspace is reviewed regularly. People change roles, devices get lost, vendors leave, and support access must be controlled. The access model must move with the business.

In practice, run an offboarding in order. Select the person on the Users list, suspend them and sign them out everywhere, so no live session outlasts the decision. Then open Security → Device Trust: revoke any device that will not come back, and revoke the biometric enrolment on a phone that is being reassigned. If a laptop is only missing, lock it instead, because a lock keeps the record and can be undone. A workspace that wants new hardware vetted can turn on Require administrator approval for new devices under Settings → Security; an unrecognised browser or phone is then held as locked until an admin unlocks it. Settings → Stale Access lists what still works but nobody uses: dormant users, unused roles, risky permission pairs, old API keys and devices not seen for 90 days.

Compliance proof is built while people work, not after the auditor arrives. Signed downloads, secure attachments, document vault files, audit logs, and evidence packs all help answer what happened and who approved it.

The goal is not more paperwork. The goal is enough structured evidence that a reviewer can trust the record without chasing private chats and scattered files.

In practice, an auditor asks for every approval and every deletion in the last quarter. Rather than exporting six screens, open Security → Evidence Packs, name the pack, choose the Approvals and Trash Lifecycle Ledger sections (and Audit Logs if they want the wider trail), and set the date range. The pack builds in the background and moves from generating to ready with a row count per section, a file size and a SHA-256 checksum. Send the checksum with the file, and the auditor can confirm that what they received is exactly what you generated. Downloads go through short-lived signed links and are recorded on the pack, and every section is scoped to your organization when it is built, not filtered afterwards.

Deletion in an operations platform is sensitive because records often have downstream meaning. Trash recovery, impact previews, force delete approvals, legal holds, and purge reports turn deletion into a governed workflow.

The safest recovery routine asks three questions: what is being restored or removed, what depends on it, and what evidence proves the decision was authorized.

In practice, someone deletes a customer record that is under a billing dispute. Open it in Trash and read the impact preview before anything else: it shows what the record is attached to, what would come back with a restore and, before a permanent delete, the saved reports, active workflows and ledger lines that depend on it. Put a legal hold on it while the dispute is open; a permanent delete is then refused, not merely discouraged, and a retention policy set under Settings → Security stacks with the hold. For record types marked high or critical risk, a permanent delete always goes to someone with the approve trash deletes permission, the request must say why, and the person who asked can neither approve nor carry out their own delete. Some records never reach Trash: purchase orders, POS sales and journals are cancelled, voided or reversed instead.