Continuous monitoring

Know before the auditor does

65 monitors judge your systems every hour. A failure names the resource and the reason, says how to fix it, opens an issue, and feeds the controls that depend on it.

Frameworks Monitoring Integrations People & devices Policies Vendors & risk Access reviews Audits SOC 1 Trust Center AI questionnaires Consultancies

Monitors

Every test, with what it covered

Each monitor reads normalized resource types (accounts, employees, devices, repositories, merged changes, buckets, databases, findings, incidents) or the program itself (policies, vendors, risks, access reviews). Its status is passing when nothing failed, failing when something did, and no data when there was nothing to judge, naming the kind of integration that would supply it.

Identity: MFA in the IdP and every system, administrators with MFA, leavers disabled within the SLA, accounts with no known owner, 90-day inactivity, key age
Cloud and data: root MFA, audit logging, threat detection, public buckets and databases, encryption, backups ≥ 7 days, SSH/RDP open to the world
Code: branch protection, required reviews, status checks, force pushes, secret and dependency scanning, merged changes with an independent approval
Vulnerabilities: critical, high and medium findings against the SLAs in Settings (15 / 30 / 90 days by default)
Devices and people: disk encryption, screen lock ≤ 15 minutes, anti-malware, OS updates; policies accepted, training current, background checks

Monitors list filtered to failing: 35 passing, 30 failing, 0 without data; rows such as Instances require IMDSv2 (5/6 pass), Merged changes were reviewed by someone other than the author (38/43 pass, 5 fail) and Databases are encrypted at rest (2/3 pass). — Sixty-five automated tests, hourly. Each row shows how many resources passed and which controls the test feeds; 38 of 43 merged changes had an independent approval, so five did not.

A failure

The resource, the reason, the fix

The demo company’s offboarding monitor found that Marcus Webb, who left 21 days earlier, still had an active Okta account and an active GitHub account. Both are named, with the reason, the remediation, and the controls they affect (IAM-07 Timely deprovisioning, HR-07 Offboarding).

When a failure is an accepted risk, record an exception for that resource with a reason and an expiry: it no longer fails the monitor, stays listed as excepted, and comes back when the exception expires.

Monitor ‘Accounts of people who left are disabled within the offboarding SLA’, critical, failing: 2 tested, 2 failing, with the fix ‘Disable or delete the listed accounts…automate deprovisioning through the IdP (SCIM)’ and two failing resources, marcus.webb@northwindlabs.io and marcusw-nw, both ‘Still active 21 days after the person left’. — Marcus Webb left 21 days ago and still has an Okta account and a GitHub account. The monitor names both, says how to fix it, and feeds IAM-07 and HR-07. **Exception** records an accepted risk with an expiry instead.

Not judged when not reported

Unknown is not a pass, and not a failure

A monitor never fails a resource for data its source did not provide. If a connector cannot tell whether a GitHub member has two-factor authentication, that account is not judged by the MFA test; if every account is unknown, the monitor says no data instead of passing. An administrator is the exception: unconfirmed MFA on an admin account counts as missing.

Issues list: 30 open, 0 overdue; monitor-raised issues such as ‘Critical vulnerabilities are fixed within SLA’, ‘Storage buckets are not public’ and ‘Accounts of people who left are disabled…’ with severity, assignee and due dates. — Every failing monitor keeps one open issue with a due date by severity (critical 7 days, high 14, medium 30, low 60) and resolves it automatically when the monitor passes again.

As evidence

A monitor run, frozen for the auditor

Save as evidence freezes a monitor’s current result and the population it judged into a dated piece of evidence, linked to every control the monitor feeds. Snapshots taken across an observation period are what an auditor samples for a continuously monitored control; the full run history is kept for 400 days.

How it works

From a system to an issue: sync, normalize, test, record, raise

With several API replicas, a Postgres advisory lock lets exactly one run each round.

Questions it answers

What you can find out

Each one is answered on a screen you can open, and most can be typed into Ask Assure as they are.

Who left but still has access?The offboarding monitor and each leaver’s page

Which buckets are public?Storage buckets are not public, with the failing buckets

Which merged changes had no independent approval?Merged changes were reviewed by someone other than the author

Which critical vulnerabilities are past SLA?Critical vulnerabilities are fixed within SLA, with each finding’s age

Which laptops are unencrypted?Devices have full-disk encryption, by device and owner

What did this monitor show last quarter?The monitor’s history, or a saved snapshot

Outcomes

What teams do with it

Gaps found in hours, not at fieldwork

A leaver’s account or a public bucket shows up on the next hourly run.

Remediation with an owner and a date

Every failure becomes one issue, due by severity, closed when it is fixed.

Evidence that collects itself

Run history and snapshots replace screenshots taken the week before the audit.

Where it stops. Monitors judge what integrations report. A source that does not expose an attribute (for example Slack’s two-factor flag on free plans) leaves it unjudged, and checks that need a person’s judgement, such as a restore test or a tabletop exercise, are evidence you upload, not monitors.

Integrations People & devices Frameworks & controls Docs: integrations