Security Posture, Incidents and Enterprise Sign-in

The Security Control Center shows a posture score from 0 to 100 with a 30-day trend. It is built from six weighted components, each with its own score, a one-line reading and the figures behind it, so the number is never a black box: MFA (25 points, the share of active people with MFA on), incidents (20, open incidents weighted by severity), policy (20, controls switched on, minus drift since the last snapshot), sign-ins (15, failed sign-ins this week against the week before), devices (10, devices unseen for 90 days that still hold access) and access (10, people holding a segregation-of-duties conflict).

A snapshot of the day’s score and security policy is stored every morning, and the trend line and the drift figure read those snapshots. Drift is the important one for an auditor: if someone relaxed the password policy last Tuesday, the policy component drops and says which control moved, even if nobody raised an incident. The same score and trend are in the mobile app, so a security lead can see a sudden drop away from the desk.

In practice: a school network’s score sits at 61. The reading for MFA says 42% of active people have it on, and the devices component lists nine laptops unseen for three months that are still trusted. The administrator requires MFA, revokes the nine devices from the Stale Access page, and the next morning’s snapshot shows 84. The trend line is what the board sees, and every point on it can be explained.

Anomaly rules run every fifteen minutes and turn suspicious patterns into security incidents. There are six: impossible travel (two sign-ins from countries too far apart for the time between them, which needs the country header your edge network supplies), excessive failed sign-ins on one account, excessive failed sign-ins from one IP address, repeated refused requests, export volume well above the person’s own weekly average, and deletions across modules. Thresholds are set per workspace in Settings › Security, and a threshold of 0 switches that rule off. A rule that keeps firing for the same person in the same window updates one incident instead of opening a new one each run.

An incident now has a full lifecycle. It can be assigned to an owner, commented on, given remediation notes and moved between open, triaged, resolved and ignored. Closing it requires a reason: remediated, false positive, accepted risk, duplicate or expected activity. Every step writes an append-only event, and the incident’s timeline exports as a CSV, so the evidence is the record of what happened rather than a reconstruction from the incident’s final state. The same lifecycle is available on the web, through the API and in the mobile app.

In practice: on a Saturday, the export rule fires for a sales officer whose exports are twenty times their weekly average. The security lead assigns the incident to themselves from the app, finds the officer was preparing a year-end customer list at the director’s request, notes that on the incident and closes it as expected activity. On Monday the auditor exports the timeline and sees who looked, when, and why it was closed.

Settings › Security › Single sign-on connects your identity provider with SAML or OIDC. First claim your email domain and prove you own it by adding the TXT record AWRA shows to your DNS, then press Verify. People then sign in from the SSO page by typing their work email; AWRA finds the connection from the verified domain and sends them to your identity provider. The AWRA app has the same entry, Sign in with your organization’s SSO. A test button checks the connection before anyone depends on it, and requiring SSO for everyone remains a separate control in the security policy. Beside it, Only our own identity provider stops the Google and Microsoft buttons from counting as single sign-on. A SAML connection also signs people out both ways, so leaving AWRA ends the provider session and the reverse, and it can require encrypted assertions under its own certificate, which New SP Certificate rotates. AWRA re-checks each domain’s TXT record every day and unverifies a domain whose record has been missing for seven days, after warning the security admins.

SCIM 2.0 lets the identity provider create, update and deactivate AWRA users for you. Generate a SCIM token on the same page and give your provider the base URL /api/scim/v2. When the provider sends a delete, AWRA deactivates the user and keeps their records; it never erases their history, because purchase orders and approvals still name who did them. Deactivation in your identity provider therefore removes access in AWRA without breaking the audit trail.

Device rules can now differ by role. For each role you can require an approved device, block device classes (rooted or jailbroken phones, emulators, unknown platforms, or the web browser so the role works from the app only), and set an offline trust window in hours. Once a phone has gone that long without reaching AWRA, the app stops queueing new offline work and asks the person to reconnect; the next successful connection refreshes the policy and work carries on. Someone with several roles gets the strictest combination. The rules apply at web sign-in and to the mobile app. In practice: a pharmacy chain requires approved devices for its Cashier and Pharmacist roles, limits offline work on tills to 12 hours, and leaves head office roles unrestricted.

A regulated workspace can lock its audit retention for between 365 days and ten years. Once locked, audit entries younger than that period cannot be purged or anonymised by any retention policy, and the period can only be lengthened in place. Lifting or shortening it is deliberately slow, because the person most likely to want the trail gone is the one it describes: an Admin requests a release, the request waits seven days, and a different Admin must confirm it after the wait. Every step is audited. The lock is a choice; a workspace that does not set one keeps its ordinary retention settings.

Every night AWRA verifies the audit log’s hash chain, in which each entry carries the seal of the one before it. If the chain is broken, meaning an entry was altered or removed outside the application, the workspace owner is emailed and a security incident is opened in the audit integrity category, so the break is handled like any other incident, with an owner, a timeline and a closure reason.

Together with the evidence pack’s control map, these give an auditor something concrete: a trail that cannot be shortened by one person, a nightly check that it is intact, and a pack that cross-references which records answer which control. The control map refers to ISO 27001, SOC 2 and Kenya Data Protection Act clauses to help your own audit. It does not mean AWRA or your workspace is certified, and you should never describe it that way to a customer or regulator.