Continuous monitoring and evidence requests

Axis Assure tests your controls from what your workspace already records — accounts and their second factors, training, policy acknowledgements, changes, incidents, vulnerabilities, vendors, continuity plans, access reviews — and, on Enterprise, from the tools you connect (see Connectors). One check is one test, and its results count in every program the control is linked to: test once, comply many.

TL;DR — Open Assure → Monitoring, pick a check that says it is available, and turn it on. Axis Assure proposes the requirements it is evidence for; a person approves each link. Results are graded on a schedule in your workspace's time zone, item by item. Nothing is ever green by default: an empty population, old data or a question the data cannot answer each have their own outcome. For evidence a person has to provide, use Assure → Evidence Requests.

The outcomes

Every run ends in exactly one of eight outcomes, and only a pass counts (or "at risk", for a test that declares a tolerance, until its window closes):

Turning a check on

1. 1

   See what is available

   Assure → Monitoring lists every check. A check is available when your workspace has what it reads — a solution installed, a module subscribed, a tool connected. When it is not, the reason is shown; nothing is configured by hand.

2. 2

   Turn it on

   A compliance manager turns it on. Axis Assure creates (or reuses) a control and its test, and proposes the requirements the check is evidence for in each program you follow. A proposal counts only after a person approves it.

3. 3

   Let it run

   Checks run daily (a few hourly), as each check states, on your workspace's clock. Run now records a run straight away.

Thresholds come from your programs. Where a control has an organization-defined parameter (for example, the period after which an unused account must be disabled), the check uses the value your program set. When several programs set one, the strictest applies and the run shows every candidate. A value written in words that cannot be read as a number makes the run "unsupported" and names the parameter — it is never guessed.

Results speak for systems. A run is about a component (your workspace, a cloud account, a code organization). It counts for a system only when that component is inside the system's boundary.

When a check is wrong for you

You cannot switch a check off silently. To exclude one item or a whole test, request an exclusion: choose why (false positive, operational requirement or risk acceptance), give it an expiry, and a second person approves it after confirming it's them. Exclusions are visible to your auditors, with who decided and until when; when one expires, the item is graded again on the next run.

What happens on a failure

• A failing test opens one finding, however often it fails, and links each run that brought a new failing item. It counts as recovered only on a clean pass.
• Each check states its remediation window (for example, 30 days for high-risk cloud posture findings), or why none applies — a check that grades a deadline of its own, such as offboarding, needs no second one. The window is counted in days on your workspace's calendar from when an item started failing; an item still failing after it escalates the finding once, and its owners are told once.
• A POA&M item is suggested, with a due date by severity; a person creates it.
• People who own the control and those who manage monitoring are notified, under the Governance & compliance notification category, which a workspace administrator can set in Settings → Notifications. Notices also go out when an approved exclusion is about to end (30, 7 and 1 day before) and when a connection stops reading (once per outage).
• Anyone can choose a daily governance & compliance digest in their account preferences: one email each morning, workspace time, listing what they own or review — and nothing on a day with nothing to report.

The daily seal

At each of your workspace's midnights, the day's automated runs are written to a file in your evidence library and sealed under one cryptographic root, with one entry in the chain of custody. Anyone with view access can verify a sealed run — its own record and its inclusion in the day's seal — from the test's history. A run that was altered after it was recorded is refused, never sealed over.

Access reviews

The access-review-complete check passes only when a workspace access review has been certified within the period your program sets (90 days by default). A campaign reviews every account that grants access: workspace roles, each module's roles, custom roles and the accounts your identity provider reports. A connected identity provider whose accounts cannot be read (its connection revoked or failing) fails the check until it is reconnected. Nobody decides on their own access — neither as the reviewer nor as the person approving a change; removing or changing access is a second person's decision, carried out through the same settings that change it by hand. Removing someone's only custom role is refused, because without one the workspace's default access applies, which is wider. A second person certifies the campaign, which files a record of it in your evidence library.

Evidence requests

1. 1

   Ask for it

   On Assure → Evidence Requests, ask someone for evidence: what is needed, a due day on your workspace's calendar, and, if it repeats, how often. Link it to the controls it supports.

2. 2

   They submit it

   The assignee uploads the file from the request. It can be submitted once the malware scan has found it clean.

3. 3

   Someone else reviews it

   A reviewer who did not submit it accepts it, asks for a revision, or rejects it with a reason. A rejected request can take a new submission. Evidence a person provides counts only once accepted.

Freshness follows the type of evidence. The type you choose decides how long it stays current, counted from the day the activity happened, not the day of the upload:

Retention. Evidence and monitoring records are held for the compliance retention period (six years today). A record inside it cannot be deleted, and a workspace or module purge waits for it. A redacted copy is a new version beside the original, with its own review — never a replacement.