A learner reports a suspicious email and the report lands in an inbox nobody watches, while a phishing click that should have opened a ticket never touches the service desk at all. Connecting Cyber Aware to ServiceNow fixes both: every phishing click and every report becomes a real incident, with a caller, a category and an SLA attached.
TL;DR
- Cyber Aware's published integration list covers Google Workspace, Microsoft 365, Zapier and a direct API - there is no native ServiceNow connector.
- Cyber Aware's webhook or API is the trigger side; ServiceNow's Import Set API or a Zapier Custom Action creates the incident.
- The build: campaign-complete or report event, filter for clicks and reports, create a ServiceNow incident with caller and category mapped.
- Map Cyber Aware learner emails to ServiceNow callers (sys_user) before go-live, or every ticket arrives callerless.
- Test one synthetic click-to-incident path before pointing the flow at a live client tenant.
Why this matters
Phishing programmes produce exactly two signals worth escalating: who clicked and who reported. Today both usually surface in a campaign PDF that an admin reads days later - the phishing simulations reporting shows who clicked and who reported, but a PDF is not a workflow. A click that becomes a ServiceNow incident gets an SLA, an assignee and a resolution; a click in a PDF gets read, maybe.
For MSPs the stakes are higher. A client's incident queue is where their service commitment lives - many MSP contracts carry response-time obligations measured inside the PSA or ITSM tool, not in a training platform. Escalating a security event into that queue means the clock starts when the click happens, not when somebody happens to open a report.
There is no native ServiceNow app in Cyber Aware's published integration list. The route still exists: Cyber Aware exposes a webhook and a direct API, and ServiceNow exposes its own APIs for record creation. Either side can drive the other through Zapier's Webhooks and Custom Actions.
Who this is for
Two audiences. First, internal IT and security teams who already run ServiceNow as their ITSM system of record and want human-layer security events in the same queue as server and network incidents. Second, MSPs whose clients mandate ServiceNow - where every incident the MSP handles must exist in the client's own instance, not in a separate security portal.
Before you start
- ServiceNow access to the target instance with permission to create incident records - directly through the Table API, or via an Import Set mapped to the incident table.
- A Cyber Aware account with webhook or API access enabled on the tenant whose events you want escalated.
- A caller mapping: the ServiceNow incident expects a caller_id reference to a sys_user record. Decide how learner emails resolve to callers - direct match, or a lookup table.
- The gotcha: callerless incidents. An incident created without a valid caller_id either fails or lands as an anonymous record nobody can work. Resolve the mapping before the first live event, not after.
Step 1 - Capture the Cyber Aware event
- Decide which outcomes warrant an incident: phishing clicks and phishing reports are the standard pair; a failed quiz attempt can be added for high-risk clients.
- Point Cyber Aware's outbound webhook at Zapier's Webhooks by Zapier trigger, or poll the Cyber Aware API for campaign results on your own cadence.
- Send one test event and confirm the payload arrives with the learner's email, the campaign name and the outcome.
Expected result: a test payload with all three fields present. Add any missing field on the Cyber Aware side before mapping.
Step 2 - Filter and map the payload
- Route only genuine escalations into ServiceNow - a click on a simulation is an incident candidate; a congrats email is not.
- Normalise the learner email to lowercase so it matches the ServiceNow sys_user record.
- Map campaign name to the incident's short description and the outcome to the description body: "Phishing simulation click - [campaign] - [learner]" reads clearly in a queue.
Expected result: one clean, deduplicated record per event, with the caller resolvable before creation.
Step 3 - Create the ServiceNow incident
- Create the incident through ServiceNow's Table API on the incident table, or through a Zapier Custom Action calling the same endpoint.
- Map at minimum: short description, description, caller_id, category (security), and impact and urgency so ServiceNow derives priority by its own matrix.
- Add the Cyber Aware campaign identifier to the description or a custom field so the analyst can trace the event back to the original simulation without leaving ServiceNow.
Expected result: a test incident appears in the queue with a real caller, the security category and a priority the client's SLA recognises.
Step 4 - Close the loop
- When the incident resolves, log the resolution back against the learner where it matters: a repeat clicker next month feeds a higher Human Risk Score, which is the platform's own signal for who needs follow-up.
- Run a monthly reconciliation of incidents created against campaign outcomes so silent webhook failures surface within one cycle, not a quarter.
- Keep the escalation rules with the client's security policy - which outcomes escalate and at what priority is their call, not a platform default.
Troubleshooting
- No incident appears. Webhooks are event-driven - nothing fires until the next campaign outcome after go-live. Trigger one test event to prove the path.
- Incident created but callerless. The learner's email did not match a sys_user record. Add a fallback caller (the service desk queue itself) so security events still arrive while the mapping is fixed.
- Duplicate incidents. Both the webhook and a scheduled API poll ran for the same event. Keep one live path per tenant and disable the other.
- Wrong priority. ServiceNow derives priority from impact and urgency; the Cyber Aware payload does not carry them. Set defaults in the mapping step rather than expecting them from the event.
- 403 from ServiceNow. The integration user lacks the role for the incident table, or the instance restricts API access by IP. Grant the role or allowlist the caller before re-testing.
What to do next
Escalation is one half of the loop; the other half is making sure the underlying programme produces fewer escalations over time. That is the security awareness training side: auto-enrolment, monthly courses and remediation on failure. Teams that want the assessment angle alongside incidents can map their posture work with the gap assessment toolkit, which produces the framework-mapped findings that pair naturally with a ticketing history.
FAQ
Does Cyber Aware integrate with ServiceNow natively?
No. The published integration list covers Google Workspace, Microsoft 365, Zapier and a direct API. The ServiceNow connection is built with Cyber Aware's webhook or API on one side and ServiceNow's own record-creation APIs (or Zapier Custom Actions) on the other.
Which Cyber Aware events should become incidents?
The standard pair is phishing clicks and phishing reports. Some teams also escalate failed quiz attempts for high-risk clients. What escalates is a policy decision - keep the list short or the queue fills with noise.
Will the incident carry the learner's name?
Only if the caller mapping resolves the learner's email to a sys_user record. Without that mapping the incident arrives callerless, which is why the mapping is the gotcha to solve before go-live.
Do phishing reports need incidents too?
Usually yes - a report is a positive signal, but it still represents a suspicious email that may warrant triage. Many teams create reports as low-priority incidents and clicks at a higher priority so analysts work clicks first.
Can we escalate to our own PSA instead of ServiceNow?
Yes - the same pattern works against any system with a record-creation API. The trigger side (Cyber Aware webhook or API) does not change; only the mapping and destination endpoint do.
What happens to the learner afterwards?
Whatever your policy sets. The platform already auto-enrols anyone who clicks into a failed-phishing course; the ServiceNow incident is the escalation layer on top, not a replacement for the training remediation.
One last thing
Set the fallback caller before go-live. A callerless security incident is invisible in a queue sorted by caller - and invisible is the one state a phishing click must never be.