Connecting a tool, mapping its fields, and everything else you'd need to actually run this.
Every THEWATCH account starts with requesting access or being invited to an existing organization. Once your admin account exists, two-factor authentication is required before you can reach the dashboard: there's no "skip for now" option, since a single account here can see across every connected tool your team uses.
Every account after the first goes through the same forced enrollment on its own first login: there's no "invite someone and they inherit MFA later" gap.
From Users & Roles (in the profile menu), an admin can invite teammates by email and assign a role. THEWATCH ships with Admin, Manager, and Analyst roles out of the box, plus custom roles built from individual permissions under Role Permissions if the defaults don't fit how your team is actually organized.
THEWATCH doesn't ship a pre-built integration for every vendor. Instead, every connector is a generic, authenticated webhook: you point your existing tool (a SIEM, EDR, ticketing system, or anything else that can send a JSON payload to a URL) at THEWATCH, and a field mapping you configure tells THEWATCH how to read that vendor's specific payload shape into a standard set of fields. This is deliberate: it means THEWATCH can ingest from literally anything with an outbound webhook capability today, not just the handful of vendors someone's built a dedicated plugin for.
siem, edr, identity, cloud, email, network, or other. This only affects how the connector shows up on the Data Source Coverage Matrix, and doesn't change how ingestion works.Point your source tool's outbound webhook at the ingest URL, sending the API key in an X-Connector-Key header:
THEWATCH stores every raw payload it receives before attempting to parse it, so nothing is lost even if a field mapping is wrong or incomplete. You can always go back and fix the mapping, then re-test against a payload you already have.
Once a connector exists, open its detail page (click Health from the Connectors list) and scroll to Field Mapping. For each canonical field THEWATCH understands, enter a dot-path into your vendor's JSON that resolves to that value:
| Canonical field | What it's for |
|---|---|
| title | The alert's headline, shown everywhere in the UI. |
| event_type | A short category for the event, used as the title if none is set. |
| severity | Must resolve to critical/high/medium/low/info, case-insensitive; falls back to the connector's default otherwise. |
| user, host, ip, domain, hash, file, process, cloud_resource | Entity fields: each populated value becomes a real, searchable Entity in THEWATCH, correlated across every alert that mentions it. |
A dot-path like actor.username walks into a nested JSON object: for a payload shaped like {"actor": {"username": "jdoe"}}, mapping the user field to actor.username extracts jdoe. Leave any field blank to skip it: an incomplete mapping doesn't block ingestion, it just leaves that field empty on the resulting alert.
THEWATCH doesn't originate cases: every case reflects something a connected system already created, whether that system generated it automatically or a person opened it by hand. If your source system is a ticketing tool (ServiceNow, Jira, or any system with its own case/incident concept) rather than a raw alert feed, a connector can mirror those tickets directly as THEWATCH cases instead of running them through the alert pipeline.
This is a second, optional mapping (Case Mirroring, on the same connector detail page as Field Mapping) against a different set of canonical fields:
| Canonical field | What it's for |
|---|---|
| external_case_id | The one required field: your ticket's own ID/number. If a payload doesn't resolve this, it's treated as a plain alert instead, not a case. |
| title, description | Mirrored onto the case as-is. |
| external_status | Your ticket's own status (e.g. "In Progress," "Resolved"), kept separate from THEWATCH's own case status, never overriding it. |
| priority | Mapped into THEWATCH's severity scale the same way alert severity is. |
| external_assignee | Stored as plain text (whatever name/email your ticketing system reports), not linked to a THEWATCH user account. |
Sending the same external_case_id again (for example, when your ticket's status changes) updates the same case rather than creating a duplicate. The case detail page shows a banner ("Mirrored from <connector>, ticket <id>") whenever a case originated this way, alongside your ticket's current external_status, so it's always clear a case is a live reflection of something outside THEWATCH, not a THEWATCH-native record.
An analyst working a case can reach back into whichever connector raised it for additional detail, without leaving THEWATCH, if that connector has an enrichment endpoint configured. This is separate from ingest: it's an outbound call THEWATCH makes on the analyst's request.
Authorization: Bearer header on every enrichment call.THEWATCH sends {"query": "...", "case_title": "..."} to that URL and logs whatever comes back to the case timeline. From a case's Enrichment tab, pick a configured connector, type a query (an IP, a hostname, whatever you're trying to learn more about), and click Ask. The result appears on the case for the whole team to see, not just whoever asked.
Every ingested event becomes an Alert. A Monitoring Policy can automatically group related alerts into a Case, or an analyst can do it by hand from the Alerts list. Cases carry their own status (open/investigating/resolved/closed), severity, assignment, SLA tracking against your org's policies, and a full timeline of everything that happened on them: notes, evidence, playbook runs, enrichment requests, and shift handoffs.
A Monitoring Policy is a WHEN/THEN rule: a set of AND-only conditions against an alert's normalized fields (severity, event type, user, host, IP, and the rest), and an action to take when they match: create the alert normally, suppress it as noise, bump its severity, auto-create a case, or run a Playbook. Policies are evaluated in creation order, first match wins.
A Playbook is the automated response itself: a sequence of steps (change status, notify, run a follow-up action) that can be triggered by a policy match or run manually from a case. Every playbook run is logged with its own history, viewable from Run History.
THEWATCH supports OIDC-based single sign-on, configured per organization from Single Sign-On in the profile menu (admin only).
acme).https://api.thewatchhq.com/auth/sso/callback.https://api.thewatchhq.com/auth/sso/<your slug>/start, or "Sign in with SSO instead" on the login page.An Enforce SSO option exists to require every login go through your IdP rather than a THEWATCH password. Talk to your account team before enabling it, since it changes how locked-out recovery works.
Passwords need at least 10 characters and 3 of 4 character classes (lowercase, uppercase, digit, symbol). Two-factor authentication is mandatory on every account: see Getting Started for first-login enrollment. If you need to re-enroll on a new device, do it from My Account while already logged in on an existing session.
Each plan includes a set number of Automation Actions per month. One action is one external operation THEWATCH performs on your behalf (querying a connected tool, an enrichment request, a playbook step that reaches outside THEWATCH). Internal correlation and case management don't count against this. See the FAQ for plan-by-plan specifics.
Three reports that don't watch for threats, they watch your own operation, using data THEWATCH already has from things you've connected and cases your team has worked. All three are read-only: they never change a connector, a case, or an assignment on their own.
Data Source Coverage (under Connectors) rolls up which tool categories (SIEM, EDR, identity, cloud, email, network) have live data flowing in, including categories with zero connectors at all. As of this release it also flags possible overlap: a category where more than one active connector is covering the same ground. That's not automatically wrong, some redundancy is deliberate, but it's worth a look at renewal time. THEWATCH doesn't recommend cutting anything; it just tells you where to look.
Every admin or config change in THEWATCH is already attributed to the person who made it, in the audit log. Continuity Risk aggregates that by system and flags when one person accounts for a disproportionate share of the changes on something critical, with no one else touching it. This is the pattern IR consultants run into constantly: the one person who set something up is gone, and nothing was documented. A finding only appears once your team has at least 3 people and 5 actions in the window, smaller samples aren't meaningful. This report needs continuity_risk.view (Admin and Manager by default).
Workload shows case volume per analyst against the team's own average, plus average resolution time for cases actually closed in the window. It's built to prompt a support conversation, not a performance review, an analyst carrying 3x the average is a staffing signal, not a verdict. This report needs workload.view (Admin and Manager by default).
Logged-in users can reach the in-app Support Center from the profile menu, or use the chat bubble in the corner of this page for a quick sales or support question. You can also email us directly: see the Support page for details.