Skip to content
Security & audit

Built to pass a procurement review, not just a demo.

Housing data is sensitive and multi-party by nature. Annum is designed so that a CBO, a city and an employer can work from one record without any of them seeing more than the member agreed to.

Controls

What is enforced, and where

Tenant isolation at the database

Every tenant-owned table carries the organization it belongs to and a row-level security policy that checks the signed-in user's membership. Cross-tenant reads return nothing — not an error page that confirms a record exists.

Roles, not switches

Six roles — Annum operator, CBO administrator, case manager, municipal analyst, employer administrator and read-only auditor — are stored separately from profiles and evaluated server-side for every write.

Consent-scoped sharing

A member grants a sponsor a named scope (identity, household, income, employment, housing history, health & accessibility). Sponsors see aggregates computed only from consented records, with counts under five withheld. Revocation takes effect on the next refresh.

Guarded operational actions

Retrying a sync, requeuing a payment, approving a Dorothy run, changing an application state or resetting the demo all require a typed confirmation and a written reason. The action runs server-side after a fresh permission check.

Immutable audit log

Every guarded action appends an audit event with actor, before/after state, reason, correlation ID and source timestamp. Audit rows cannot be edited or deleted by any application role; the database rejects the attempt.

Integrations stay on the server

HMIS, property feeds and payment rails are reached through adapter interfaces that run only on the backend. The browser never holds a vendor credential. Freshness SLAs, failed syncs and stale sources are surfaced with their correlation IDs.

Dorothy proposes; people decide

Dorothy scores eligibility against versioned rule sets and explains each criterion in plain language. Its proposals are invisible to members and sponsors until a counselor approves them, and every run is reviewable.

Secrets and keys

Service credentials live in backend configuration only. Public web pages use publishable keys against insert-only or read-only policies, never privileged access.

Who sees what

One member record, four vantage points

DataCase manager (CBO)Municipal analystEmployer administratorAnnum operator / auditor
Member identity & contactFullPseudonym onlyNot visibleFull (operator), read-only (auditor)
Household, income, housing needFull, editableAggregates from consented recordsAggregates from consented recordsFull, read-only
Documents & evidenceVerify / rejectNot visibleNot visibleRead-only
Dorothy proposalsReview & approveNot visibleNot visibleReview (operator), read-only (auditor)
Programs, units, rule versionsViewView own; funded programsManage own benefitsManage all
Integration health & paymentsNot visibleNot visibleNot visibleOperate (operator), read-only (auditor)
Audit logOwn organizationNot visibleNot visibleAll tenants
Standards

Targets we design against

  • WCAG 2.2 AA — keyboard-first navigation, visible focus, minimum 44px targets, no colour-only status.
  • Data minimisation — sponsors receive counts, never rows; small cells are suppressed by default.
  • Traceability — every operational record carries a correlation ID and the source system's timestamp.

Formal certifications and a completed security questionnaire are shared during pilot scoping. Ask us for the current control matrix.