ServiceNow

Proofroom reads change requests with their approvals, and security incidents, through ServiceNow’s Table API.

What each collector shows

Collector	Kind	Default cadence	What it shows	Suggested controls
Change tickets	window	monthly	Change requests closed in the period with who approved each. Flags Self-approved (approved only by the requester or assignee) and No approval.	PCI DSS 6.5.1, 6.5.2; SOC 2 CC8.1
Security issues	window	monthly	Security incidents opened, closed or still open in the period, with priority, state and days open.	PCI DSS 6.3.1; SOC 2 CC7.4 (or 12.10.1; CC7.3, CC7.4 when the tickets are incidents)

Create the user

A dedicated integration user (System Security → Users → New), Web service access only, with its time zone set to UTC (dates are compared in the user’s time zone), and these read roles:

sn_change_read: change requests (from the ITSM Roles plugin). Where that plugin is absent, itil works but is not read-only.
Read on sysapproval_approver: the approval records. If sn_change_read does not grant it on your instance, add approver_user or a read ACL on that table.
sn_incident_read for the incident table, or sn_si.read for Security Incident Response.

The connection test fails if no change requests are visible, because ServiceNow may hide records from a user without the role instead of refusing.

The base system has no security incident category; most instances add one. If your security query names a category (category=… or categoryIN…), the connection test and every security-issues run check it against the incident category choices (sys_choice for incident.category, matched in any case) and fail naming any that do not exist, rather than file “0 security issues”. The user needs read on sys_choice, which most roles have.

ServiceNow ignores a condition on a field the table does not have (unless the instance sets glide.invalid_query.returns_no_rows), so a mistyped field in the change query or security query would quietly match more records than intended. The connection test and every run ask the table for one record with just the query’s fields (dot-walked fields by their first part) and fail naming any field the table leaves out (a field the account may not read looks the same).

Connect

Field	Value
Instance URL	`https://<instance>.service-now.com`
Username, password	The integration user
Change query	Optional encoded query added to the change filter, such as `type=normal`
Security table	`incident` (default), or `sn_si_incident` with Security Incident Response
Security query	For the incident table: the encoded query for security issues (default `category=security`)
What these tickets are (`securityTickets`)	`incidents` files the security issues against PCI DSS 12.10.1 and SOC 2 CC7.3, CC7.4; `vulnerabilities` (security bugs) against PCI DSS 6.3.1 and SOC 2 CC7.4 (default `vulnerabilities`). Changing it moves the collector’s mapping too, unless the mapping was changed by hand.

Known limits

Basic authentication only; OAuth client credentials are not used yet.
Dates in encoded queries are read in the user’s time zone, so Proofroom asks for two days either side of the period and keeps only records inside it; a run late in the UTC day loses nothing whatever the user’s time zone.
Approvals are read 100 changes at a time.