ARCUser documentationBack to FAQ

ARC user documentation

How to use the ARC governance terminal end to end — from signing in and navigating workspaces to activating frameworks, assessing vendors, publishing policies and automating against the API.

1. What ARC is

ARC is a governance terminal: one application, one database and one audit trail covering incident response, security and privacy compliance, AI governance, enterprise risk, vendors, assets, policies and forms.

Each area is a workspace reached from the top bar. Workspaces share records — a vendor, an asset or a control is stored once and referenced everywhere.

  • Responder — incidents, runbooks, escalation, lessons learned, response metrics.
  • Security — control matrix, frameworks, crosswalks, SoA, gaps, evidence, recurring tasks.
  • AI — AI systems, model cards, datasets, bias tests, disclosures, change management, AI controls.
  • Privacy — RoPA, DSARs, privacy controls, HIPAA gaps, coverage, privacy reporting.
  • Risk & Resilience — risk register (Impact × Likelihood × Vulnerability), treatment plans, corrective actions, taxonomy, score summary, programme dashboard, BIA, continuity, disaster recovery, tabletop exercises and audit management.
  • Controls — the unified register across every enabled framework, with coverage gaps and the advisor Decision Tracker.
  • Audit — audit plans, objectives, timelines, schedules and linked evidence.
  • Tasks & Evidence — the central cross-module queue with schedules and history, the evidence library and population lists.
  • Vendors — shared supplier registry, third-party risk, impact trace, domain assessments.
  • Assets — configuration database with criticality, dependencies and review cycles.
  • People — the workforce roster used as audit evidence, with directory sync, snapshots and population-list templates.
  • Policies — authoring, review, approval, taxonomy, publication and PDF compilation.
  • Forms — form builder, public links, submissions and responses.

2. Accounts and access

ARC does not allow self sign-up. An administrator creates the user in Admin → Users & Roles; ARC emails an invitation so the person sets their own password. Google and Microsoft sign-in are available for invited addresses, and an admin can resend an invitation at any time.

Access is controlled twice: by role (admin vs. standard user) and by module. In the user edit dialog, each module chip can be switched on or off; disallowed modules disappear from navigation and are blocked if the URL is entered directly. Administrators always retain full access.

3. Working day to day

Start on the terminal overview: it aggregates KPIs, a cross-module watchlist, framework coverage across Security, Privacy and AI, and the recent audit stream. Every panel drills through to the underlying record.

Work items land in Tasks, the central queue. A task links to records in any module — controls, risks, vendors, assets, evidence, people — with an accountable owner and a separate assignee from the roster. Tasks repeat on a schedule (daily, weekly, monthly, quarterly, half-yearly, annually) and completing one rolls the next occurrence forward. A History tab records every change of owner, assignee or state with the date, actor and reason. Evidence due to expire is surfaced alongside so renewals are not missed, and a general file library holds record-less working documents.

4. Frameworks, controls and coverage

Each compliance module has a framework library. Activating a framework seeds its controls into the module's framework controls page; 'Load controls' refreshes them if the catalog is updated. Frameworks show a version and last-updated badge so you know which release you are working from.

Controls support deep editing, ownership, status, inheritance, mapped requirements and evidence links. Crosswalks and cross-framework deduplication let one tested control satisfy several frameworks, and coverage bars recalculate from the matrix — an empty matrix reads zero rather than showing stale progress.

The unified Controls workspace reads across every enabled framework without modifying the per-module matrices: one register with immutable UC numbers, lifecycle, ownership, an audit tab, and a Coverage dashboard that shows mapped versus unmapped requirements per framework with gaps highlighted and exportable.

Controls → Decision Tracker is where advisors submit decisions against controls — type, outcome, rationale, conditions and review dates — with covered controls and relied-upon evidence ticked per decision and an append-only trail of every change. The register exports to CSV, PDF or Excel.

Filtered control sets export as CSV, XLSX or PDF, including mapped requirements, from both the index and each control drill-down.

5. Vendors and assets

The vendor record holds ownership, primary and escalation contacts, addresses, contract dates and attachments, SLAs, service documentation, higher-risk flagging and review dates, plus Security, Privacy and AI risk ratings that can be searched, sorted and exported.

Assessments are distinct instruments — Security Risk, Privacy Risk, AI Risk, DPIA, TIA, AI Impact and related types — each with attachments. An AI risk assessment can only begin once the vendor exists and a security vendor assessment is complete.

Assets records systems and their criticality, dependencies and review cadence so impact trace can follow a vendor or incident through to affected services and data.

6. People

People is the workforce roster used as audit evidence — it is not an HR system. Each entry holds department, manager, start and end dates and status; terminated people stay on the roster, greyed out, so historical ownership and evidence still resolve to a real person.

The roster can sync itself: connect Microsoft Entra or Google Workspace in People → Sync Setup (credentials are encrypted at rest), run nightly or on demand, and preview hires, leavers and changes with a dry run before committing. Every run is listed on the Sync History page. Roster changes flow through to assigned controls, risks and tasks — when someone leaves, every record they own is flagged for handover, reassignment or clearing.

People can be assigned directly: control detail pages carry a People section (owner, accountable owner, delivery team), risk detail pages have a People tab, and tasks take a roster-backed owner and assignee. The risk queue has a People view so unowned risks stand out, and the audit plan lists the people assigned to each control with their roles.

For auditors, take a point-in-time snapshot, or build a reusable population-list template with saved filters and columns and download it as PDF or CSV. Any artefact can be filed against controls as evidence — hashed, stored privately and referenced on each control. Auditors can also submit their own population list under Tasks & Evidence → Population Lists, reconciled against the active roster.

7. Risk and resilience

The register scores every risk as Impact × Likelihood × Vulnerability (I×L×V), 1–5 on each axis, for inherent and residual exposure. Severity bands and categories are defined by you in Risk Taxonomy, so scoring reflects your appetite rather than a fixed scale.

There are two ways in. Add to Register is row-by-row entry for risks, controls and requirements, with inline score pickers and owners chosen from the user directory; blank rows are ignored and the batch commits in one save. Import Register handles bulk loads from a CSV template.

Owners are real accounts, not free text. Risks, controls, requirements, treatments and corrective actions all carry an owner, and ownership coverage is reported alongside exposure. Each risk also has a People tab linking roster members as owner and accountable owner, a Controls & evidence tab linking the risk to its mitigating controls and supporting evidence, and the queue's People view flags risks with no owner. Accepting a treatment writes an approved treatment record and a linked corrective action with team and progress tracking.

Programme Dashboard reports register totals, inherent versus residual exposure, weighted treatment delivery by team, ownership coverage and crosswalk gaps. Score Summary rolls the same data up by band, category and owner and exports to PDF, CSV or XLSX.

Resilience sits in the same workspace: business impact analyses, business continuity and disaster recovery records, tabletop exercises with a reminder calendar, exceptions, change management, impact trace and audit management with calendars and SLAs.

8. Crosswalks and framework mapping

The Crosswalk Builder proposes candidate mappings between framework requirements, ranks them, and lets you confirm or dispute each one. The Advisor can act as tie-breaker and score candidates with I×L×V when it is configured.

Coverage Gaps lists orphaned requirements and disputed mappings so nothing quietly falls outside the programme, and can draft treatment options per gap. Framework Mapping lets you publish your own control set, which then feeds the crosswalk engine like any catalogued framework.

9. Policies and forms

Policies moves documents through drafting, review and approval, organised by category, tag and Company/Division taxonomy. Sort & Publish compiles several approved documents into one publishable PDF.

Forms builds questionnaires and audit forms, publishes them to a public link and collects responses. Anonymous submissions are rate limited and bot protected; respondent PII is pseudonymised, retained for a defined window and every access is logged.

10. Administration

All administrative functions live in one workspace: users and roles, module access, framework management, control matrix defaults, branding, legal text, locale and translations, retention, PII access logs, abuse monitoring, query profiling, API access and analytics, and the unified audit log.

The audit log retains 365 days of activity with masked sensitive fields, and covers every user action across every module.

11. API and automation

Issue keys in Admin → API Access. Authenticate with `Authorization: Bearer <key>` or `x-api-key: <key>` against `/api/public/v1`. Interactive documentation is at /api-docs and the OpenAPI contract at /api/public/v1/openapi.json.

Read endpoints cover every governance collection as a named endpoint — including the Decision tracker at `/decisions` — plus coverage posture, the audit trail and full policy text or PDF. Sync clients use `updated_since` with the `next_cursor` keyset cursor, `include_deleted=true` for tombstoned deletions, `kind_in`/`kind_not_in` to shape pulls, `?ids=` batch fetch, ETag conditional requests and a ZIP bulk export. `GET /meta` reports each kind's status vocabulary and `GET /health` reports the key's expiry, last-used time and rate budget.

Writes are scoped and deliberate: `records:write` for status transitions and work-log notes on operator-owned records, `evidence:write` for append-only evidence ingestion, `assets:write` for the asset register, `extensions:write` for the extension lifecycle, and the exclusive `attestations` scope for the registry connection. Filed evidence cannot be overwritten or deleted through the API.

12. Attestations and extensions

Attestations are the tenant-side control over what may later be published externally. Claims are created, approved and revoked in Admin → Attestations; approvals are recorded as append-only evidence, and only approved claims are served over the attestations API scope, each with a content hash and an ETag for cacheable fetching.

Extensions are programmatic add-ons registered at /x and managed in Admin → Extensions. Only holders of the extensions:write scope can create, update or delete them, in the UI and over the API, and every lifecycle action is retained in the Extensions Audit trail for 365 days.

13. Maintenance and data retention

Admin → Retention shows the nightly purge schedule, the last run time, deleted row counts and a sortable job history for both retention jobs. A failure raises an actionable alert with the job id, error detail and the affected retention window.

A dry-run mode reports how many rows would be deleted without deleting anything, so retention changes can be checked safely before they take effect. Admin → Version Notes records each release and can diff it against the previous one.

14. The Advisor (AI decisions about your data)

The Advisor is bring-your-own-AI. ARC ships no hosted model and has no fallback provider: if your endpoint is missing, switched off or unreachable, the Advisor simply refuses to run and says so on screen. Known hosted AI provider hosts are rejected outright, and only HTTPS endpoints are accepted.

The Advisor asks your own decision endpoint for calls about your data: risk ratings, control selection, gap verdicts, go/no-go recommendations, prioritisation, review-due calls and free-form questions. It is dormant until an admin sets the endpoint URL under Admin → Advisor Endpoint; the bearer token is read from the ADVISOR_API_KEY server secret when set.

Work from the Advisor workspace in the top bar, or press Ask Advisor on an AI system or vendor record. Pick a module scope and decision type, select up to 50 records, and request a decision. Only whitelisted fields leave the tenant (title, kind, status, category, severity, score, due date and a truncated summary) — free-form data and PII are never sent.

Every decision is a suggestion until a human acts: Accept & apply (applies update_status actions), Accept with manual edits, or Override with a note. Every request, verdict and outcome is written to the audit log and to the Decision Log, which is filterable by outcome, type and module and exports to CSV, PDF and XLSX.

Before enabling the service, use Admin → Advisor Test Harness to send a sample request: it shows the exact payload leaving the tenant, the raw response, and the parsed verdict and confidence, without writing to the Decision Log. If a live request fails because your endpoint is down, it is parked on Advisor → Retry Queue (up to five attempts) rather than lost, and every attempt is audit-logged.

Endpoint contract (v1): POST receives { version, decision_type, module, question?, scope: { record_ids, framework? }, context: { records[] } } and must answer { verdict, confidence (0–1), reasoning: [{ factor, weight?, detail? }], actions: [{ label, kind, target_id?, value?, detail? }], conditions: [] }. Actions of kind update_status are applied to the target record only after a human accepts.

15. Getting help

Check the FAQ first — it covers access, coverage calculation, assessment gating, exports and API basics. If something looks wrong with data, the audit log usually shows what changed, when and by whom.

If you still need help, contact your ARC administrator; they can adjust roles, module access, retention and framework activation on your behalf.