sha3:3a8b3b915c7c65c7d938d10c0ea7bc78961de048b3ae78850807b92ef3fb794aIntactServiceNow / Jira / Azure DevOps
Compliance findings land where work happens.
Your team operates in ServiceNow, Jira, or Azure DevOps, and PolicyCortex does not ask it to move. Findings, remediation tasks, and POA&M items route into the tool you already run; approvals taken there become the authority on the record, and closure in either system is revalidated against the environment before the finding closes in proof of change.
8f3d0aff36e94b38297333586c32a64d24532e3b32c803dc59999474c616e95dprev:d34243cfddd8What a ticket must prove
A closed ticket is a claim that work happened. The assessor wants the claim tied to the environment: was the misconfiguration actually corrected, who approved the change, on what basis, and does the closure evidence match the state after the fix. An ITSM system records the workflow; it does not observe the cloud. A governance tool observes the cloud; it does not carry your approval workflow. The gap between them is where audit findings live.
The obligation is one record across both: the finding, the ticket, the approval, the action, the verification, and the closure, in sequence, with none of them editable after the fact.
- itsm.systems
- ServiceNow (ITSM incidents and changes, GRC findings and CARs, CMDB linkage), Jira, Azure DevOps. Existing assignment groups, business services, and SLA definitions are respected.
- itsm.routing
- Severity maps to priority; owner routing follows your assignment groups; a finding inherits the ITSM SLA and escalates as it nears breach.
- itsm.approvals
- Slack, Teams, or ServiceNow's own approval engine. Who approved, when, and on what basis flows back as the authority on the change.
- itsm.closure
- Closure in either system triggers revalidation against the environment. If the drift is gone the finding closes with closure evidence; if not, the ticket reopens with a note.
01b5d9011130113a16b8ff60b8a467317d9b5e93dd67cd7e5f3670d7e9ed6161prev:8f3d0aff36e9The record a ticket refers to
The ticket and the record are one sequence. Where each proof files:
- Finding to ticket
- Proof of state: the finding is a recorded difference between expected and observed state, with severity, control, and owner; the ticket carries a reference to that record, not a paraphrase.
- Approval
- Proof of agency: the approval taken in Slack, Teams, or ServiceNow is the named human in the GATED trust mode, and becomes part of the action's record.
- Remediation
- Proof of change: the action, its before and after hashes, and its rollback identifier, attached to the ticket as evidence rather than typed into a comment.
- Closure
- Revalidation against the environment before the finding closes. Closure evidence is a record the assessor can recompute, not a status field.
- POA&M
- Open items are the same rows as the tickets; the POA&M is generated from the record, and a closed ticket with no environmental change does not close a POA&M item.
4ded4da59a0ac9fbbba2e59d772ddd53bfcddca46baaab8d8cf6f86aa35f4debprev:01b5d9011130How a closed ticket is verified
For an ITSM question the recomputation ties the ticket to the environment: the approval, the action, the revalidation, and the closure are one sequence of rows, and a closed ticket with no environmental change does not recompute as a closed finding.
Every record PolicyCortex writes for this obligation is content hashed with SHA3-256 and carries the digest of the record before it, so each line commits to the entire history above it. The log is append only: a correction is a new record, never an edit. Verification is a recomputation, not an assertion. Run the chain from the first record forward and it returns one of two answers: intact, or the sequence number of the first record that breaks.
A second party can do that recomputation without our help. The records, the digests, and the chain rule are everything required: no PolicyCortex account, no API of ours in the loop. When a collector was down or a scope was unobserved, the chain carries a declared gap with the interval and the reason, never silently fewer rows. Absence is declared, not inferred.
392124c949c774c06f9d47fac90257ee01c94236f193dbe26373b19f1bed062eprev:4ded4da59a0aAccess and onboarding beside your ITSM
During agreed onboarding, review how findings route into ServiceNow, Jira, or Azure DevOps. SHADOW mode keeps remediation disabled while your team verifies the workflow within its agreed scope.
Request access so we can review your environment, evidence needs, and onboarding scope. After access is approved, read-only onboarding uses SHADOW mode inside your own tenant. Nothing executes. Policy evaluation, evidence collection, and action gating run where your data already is; there is no telemetry pipeline to PolicyCortex servers and no egress of evidence. You hold the records and can recompute the chain yourself.
- eval.mode
- SHADOW. Watch only; nothing executes.
- eval.onboarding
- Access is reviewed. Scope and onboarding are agreed with your team.
- eval.location
- Your tenant. Azure, AWS, and GCP are observed clouds, including AWS GovCloud, Azure Government, and GCC High.
- eval.egress
- None. No telemetry pipeline to PolicyCortex servers; no evidence leaves the tenant.
- eval.after
- You keep the records. Licensing is annual and the tenant owns the evidence; a delivery engagement is optional.
3a8b3b915c7c65c7d938d10c0ea7bc78961de048b3ae78850807b92ef3fb794aprev:392124c949c7Questions assessors and buyers ask
Which ServiceNow modules are supported?
ITSM (Incidents, Changes), GRC (Findings, CARs, SSPs), and CMDB asset linkage. PolicyCortex respects existing assignment groups, business services, and SLA definitions.
Custom Jira workflows?
Yes. PolicyCortex states map to your existing Jira workflow states; custom transitions, custom fields, and approval gates are respected.
What if a ticket is closed manually?
Closure in ServiceNow or Jira triggers a revalidation in PolicyCortex. If the underlying drift is actually remediated, the finding closes with closure evidence; if not, the ticket reopens with a note. A closed ticket never closes a finding on its own.
How do approvals work?
Native Slack approvals, Teams approvals, or ServiceNow's approval engine. The approval (who, when, on what basis) flows back to PolicyCortex as the authority on the change and becomes part of the record.
Where does the data live?
In your own tenant. There is no telemetry pipeline to PolicyCortex servers and no egress of evidence.
What happens when a collector is down?
The chain carries a declared gap: the stream, the interval, the reason, and when it was declared. Evidence never silently has fewer rows.
Route findings where work happens. Keep the record whole.