FAQ & User Documentation

Open the Sign in page and use the workspace's managed identity options — Google or Microsoft — or the email and password account issued to you. Accounts are never self-service: a workspace administrator provisions every user.

Admin — full control: manage users and invites, integrations, storage, retention, AI settings, and delete cases. Analyst — investigates: creates and edits cases, evidence, tasks, indicators, notes and reports, and runs AI requests. Viewer — read-only access to the shared investigation corpus.

An admin sends an invite from Settings → Users. The invite email carries a secure activation link (valid 7 days) — the invitee chooses their own password; no initial password is ever generated or shared. Admins can resend or revoke invites, and change roles at any time.

Yes — use "Forgot password?" on the sign-in page. A reset link is emailed to your address; opening it lets you set a new password. Invite and reset links both resolve to the same secure password page.

A live operating picture: open incidents by severity and status, the alert queue, recent evidence, MITRE ATT&CK/ATLAS coverage, investigation activity and response metrics. Tiles and panels deep-link to the underlying registers.

Open the Case Register and use New Case. You set the title, severity, phase/status, classification, lead analyst, impacted hosts, priority, team, tags and SLA due date. Storage for the case (bucket/prefix and encryption key) is provisioned automatically.

Yes — the case screen has an Edit control covering the same metadata. Every update is recorded in the Investigation Activity log with a request id.

Cases move through triage, investigating, containment, eradication and recovery to closed — set via the case screen. Deleting a case is an admin action that removes the case and everything attached to it (evidence, custody, artifacts, timeline, indicators, notes, tasks, reports, activity and keys) and is audit-logged.

A case and a payload file are both required. The file is hashed with SHA-256 before it is accepted; the hash is written to the evidence record before the object is stored, so integrity is established at ingest.

Yes. Evidence is envelope-encrypted with AES-256-GCM (the ARC1 format) using a per-case key before it is written to storage. On upload the workspace verifies the stored copy by reading it back, decrypting and re-hashing it — the evidence record's integrity flag reflects that check.

Every movement is a custody ledger entry: action, actor, role, location and optional hash verification. Records are appended when evidence is added, and analysts can add custody entries at any time from the Chain of Custody screen.

Administrators choose a backend in Settings → Storage: a Wasabi S3-compatible object store or a local network filesystem share. Each case gets its own bucket/prefix and is provisioned automatically, with status shown on the case.

Keys are per case, never shared. In SSE-C mode the key is held in the workspace database (masked, admin-only); admins can rotate a case key, which re-encrypts safely via read-decrypt-rewrite with verification.

Settings → Storage → Test connection validates the endpoint, credentials and reachable bucket and reports detailed, non-secret diagnostics.

The Artifact Explorer (hosts, users, hashes, IPs, domains, files), Timeline Explorer (correlated events), IOC Correlation (indicators with hits, confidence and case links), the Indicator Map (every registered indicator with its feed, confidence and the cases/alerts it appears in) and ATT&CK/ATLAS Coverage. Evidence Search spans the vault with filters and a quick-view panel.

From a case's Indicators tab or the IOC Correlation register: value, artifact type, severity, confidence, status, source, label, ATT&CK technique and tags. Edits are logged to the activity stream.

Vendor connectors: Bitdefender GravityZone, Tenable, Microsoft Azure Defender/Sentinel, Microsoft 365 Defender, Datto RMM and NinjaOne. Keyless public intelligence: CISA KEV, abuse.ch Feodo Tracker, URLhaus and ThreatFox. Everything is normalized, deduplicated and scored on ingest.

Each source has an Ingest mode in Settings → Alert connectors. "Raise alerts" puts every item into the Alert Triage queue; "Indicators only" enriches the indicator register and Indicator Map without creating queue noise. Bulk intel feeds are best left on indicators-only; curated feeds such as KEV work well as alerts.

Intel Feeds shows each source's sync rate, last run, untriaged backlog, stale-feed warnings and an ATT&CK gap analysis. Opening a feed lists the alerts and indicators it produced plus its full sync history (items fetched, imported, duration and any error detail).

Admins, plus any responder explicitly granted scope on that source (Settings → Alert connectors). Manual alerts are visible to all responders.

Tasks can be created from the case screen, Response Tasking or the Response Dashboard, assigned to a provisioned user, given a phase, priority and due date, and linked to evidence. Status moves Todo → In Progress → Done (or Blocked); overdue tasks are highlighted and advancing a task can fire SOAR automation.

Yes. Every note save snapshots a new version; the history view lets you browse versions and see a line-by-line diff between any two. Versions are append-only and cannot be edited or deleted.

New Draft supports executive, technical, forensic and lessons-learned types with author, title and summary; reports can auto-fill from the case. Open Full Report assembles scope, timeline, evidence, custody, indicators, tasks and notes into a generated document you can download as Markdown, export as PDF or print. Alerts can also be exported individually as PDF.

Yes — create a secure share link on the report. Links carry a hashed token, an expiry, an optional download limit and a label; they can be revoked at any time, and every download is counted and audit-logged.

The decision engine sends bounded context — never the full dataset — to a decision endpoint you configure. Bring-your-own-AI: each deployment supplies its own HTTPS endpoint in either ARC native contract mode or Service API mode (any OpenAI-compatible chat-completions API, with your exact model id). No shared AI service is provided and nothing is sent until an admin configures and enables it.

Alert triage dispositions (single or bulk), alert clustering, case guidance, IOC correlation, artifact and evidence review, timeline narrative reconstruction with gap/anomaly flags, report executive summaries, SLA prioritisation, task suggestions, search assistance and ATT&CK coverage-gap analysis. Each surface exposes the advisor where the work happens.

Low-risk alert actions (severity, assignee) at or above the confidence threshold are auto-applied and recorded. Everything else lands in the AI Review Queue, where analysts see confidence, extracted signals and step-by-step rationale, then apply, reject or escalate — individually or in bulk. Escalation bumps case severity and priority and raises a containment task. Every decision is traced by request id.

Settings → AI decision engine → Test endpoint runs a full health check: reachability, auth validation, latency and response-schema validation, with per-component status shown on the panel. Ledger exports (CSV/JSON) are available with filters for status, type, case and time range.

Playbook Builder defines reusable templates: phase (identification, containment, eradication, recovery, lessons learned), step, default owner, ATT&CK coverage and SLA hours. A template can be applied to any open case, which seeds its response plan as tasks. Cases promoted from an alert are seeded with a default playbook automatically.

It shows every open case's playbook progress: which phase is live, who owns each step, what is overdue and what is unowned. Owners and statuses can be changed inline, and completing the plan lets you close the case — which resolves linked alerts, updates ATT&CK coverage and clears the SLA counters.

SLA & Escalation lists overdue tasks and unreviewed AI decisions by severity, alongside the triage proposals that relate to them, so the oldest risk surfaces first.

Admins define SOAR actions in Settings → SOAR automation: a trigger phase/status, an optional match expression, and a dispatch target (outbound webhook or ARC Responder) with method, auth scheme, token, timeout and a body template. Advancing a matching task fires the action.

Completing the triggering task, moving the case to a new status, and extending the SLA by a set number of hours. Every run is recorded with HTTP status, duration, request id, applied effects and any error, and failures are retried.

No. ARC Forensics runs fully standalone in manual mode. Connecting the Responder module is optional and configured in Settings → ARC Responder with a base URL and API key.

Cases, alerts and artifacts, in the direction you choose (pull, push or both), on a schedule or on demand. Work is queued, deduplicated, retried on failure and idempotent, with artifact hashes validated on transfer; the queue and last sync result are shown in the admin panel.

The admin audit log and the Investigation Activity log have a configurable retention (minimum 3 months, maximum 120) set by an admin in Settings → Retention. A background scheduler purges expired entries; the admin panel shows the last purge run, deletion counts and a preview of what would be purged.

Yes — admins can export the audit log and activity log as CSV or JSON (limited to 5,000 rows) for incident review; exports are themselves audit-logged.

Nobody. All workspace routes are gated: before authentication you only see the sign-in screen. Data access is enforced by row-level security with admin/analyst/viewer roles; integrations and settings are admin-only.

Storage, integration, SOAR and AI credentials are stored server-side, masked in the UI and never returned to clients — the UI only ever shows whether a credential is set. Evidence payloads are encrypted before leaving the workspace, and there is no client-facing decrypt or download endpoint for evidence objects.