A new hire signs their contract in Rippling on Friday and starts Monday - laptop, payroll and apps provisioned on day one. Security training should land in that same flow, and it can: connecting Rippling to Cyber Aware turns enrolment into an identity event instead of a CSV somebody emails around.
TL;DR
- Cyber Aware's published integration list covers Google Workspace, Microsoft 365, Zapier and a direct API - there is no native Rippling connector.
- Rippling's employee webhooks and API are the trigger side; Cyber Aware's API or Zapier actions are the action side.
- The build: Rippling employee created event, filter for active staff, create the learner in Cyber Aware, deactivate on the termination event.
- Map Rippling departments or locations to Cyber Aware client cohorts before go-live.
- Test one synthetic hire and one synthetic leaver before pointing the flow at real staff.
Why this matters
Rippling runs HR, IT and payroll for thousands of small and mid-size businesses, which makes it the system of record for who works where. When training enrolment keys off Rippling instead of a manual list, three failure modes disappear: new starters wait zero days for their first security awareness training assignment, leavers vanish from the active learner list the day they terminate, and department moves carry their training with them instead of relying on somebody noticing.
The first month of employment is exactly the window where an unfamiliar user is likeliest to click a payroll-diversion or invoice-fraud phish - the phishing simulations page notes that fresh, provisioned staff are a prime target. Every day a new hire sits outside the programme is a day of exposure during the highest-risk week of their tenure.
There is no native Rippling app in Cyber Aware's published integration list. The route still exists: Rippling emits employee lifecycle events through its webhooks and exposes its employee directory via API, and Cyber Aware exposes both Zapier actions and a direct API. Either side can drive the other.
Who this is for
Two audiences. First, internal IT and HR teams who run Rippling as their HRIS and want training to behave like every other app Rippling provisions. Second, MSPs who manage Rippling for client tenants and need each client's employee directory to feed its own Cyber Aware tenant without per-client manual work.
Before you start
- Rippling admin access with permission to configure webhooks or read the employee API.
- A Cyber Aware account with API or Zapier access - direct API for a code path, Zapier for a no-code build.
- A cohort mapping decision: which Rippling department, location or employment type maps to which Cyber Aware tenant or client. Write it down before step one.
- The gotcha: the termination event matters more than the hire event. A missed hire costs days of training; a missed leaver is a stale account in an audit trail and a seat you may still be billed for. Build and test the deactivation path first.
Step 1 - Capture the Rippling employee events
- In Rippling, subscribe to the employee lifecycle events that matter: employee created and employee terminated at minimum.
- Point the webhook at Zapier's Webhooks by Zapier trigger, or at a small endpoint of your own that calls Cyber Aware's API.
- Send one test event per type and confirm the receiving side logs it.
Expected result: a test payload arrives carrying at minimum work email, first name, last name, employment status and department. If a field is missing, add it to the payload before mapping anything else.
Step 2 - Filter and map the payload
- Only act on actively employed staff - skip candidates in onboarding status and contractors outside your enrolment policy.
- Map work email, first name and last name, and normalise the email to lowercase. Case mismatches between systems are the most common source of duplicate learner records.
- Apply your cohort mapping: Rippling department or company entity to Cyber Aware tenant. For an MSP, this rule decides which client each learner belongs to.
Expected result: one clean, deduplicated record per person, with the destination tenant decided before creation.
Step 3 - Create the learner in Cyber Aware
- Call Cyber Aware's API to create the user in the mapped tenant, or use the matching Zapier action.
- New learners follow the platform's standard enrolment behaviour: welcome email sent, baseline courses assigned, due-date reminders queued on the normal cadence.
- On the termination event, call the deactivate or remove path so the leaver disappears from the active learner list the same day.
Expected result: a test hire appears enrolled with baseline training assigned; a test leaver vanishes from active learners.
Step 4 - Run a monthly reconciliation
- Export the active-employee list from Rippling and the active-learner list from Cyber Aware once a month and compare them.
- Investigate both directions: learners with no Rippling record (contractors and board members enrolled deliberately) and employees with no learner record (mapping gaps).
- Log the exceptions; do not auto-delete accounts you cannot explain. A deliberate exception is a footnote, not an error.
Troubleshooting
- No learner appears. Webhooks are event-driven - nothing fires until the next employee event after go-live. Create one test employee in Rippling to prove the path.
- Duplicate learner records. A manual invite and the sync both created the user, or the email casing differed. Disable the manual path for synced tenants and normalise to lowercase.
- The leaver is still active. The event only fires on termination in Rippling. If staff are offboarded by status change rather than termination, add that event to the subscription.
- Learners land in the wrong client tenant. The department-to-tenant mapping is wrong or the department changed. Fix the mapping, move the learner manually, and re-test with an employee from that department.
- Nothing sends at all. Check the webhook subscription is enabled and the endpoint returns a 200 - a failing endpoint can be disabled automatically by the webhook provider.
What to do next
Once identities flow correctly, the reporting side looks after itself: every overdue course and phishing failure feeds each learner's Human Risk Score, and clean leaver removal keeps that score honest. MSPs comparing platforms before committing to a stack can work through the white-label platform comparison to see how integration depth differs across vendors.
FAQ
Does Cyber Aware integrate with Rippling natively?
No. The published integration list covers Google Workspace, Microsoft 365, Zapier and a direct API. The Rippling connection is built with Rippling's employee webhooks or API on one side and Cyber Aware's Zapier actions or direct API on the other.
Which Rippling events should trigger enrolment?
Employee created for the hire side and employee terminated for the leaver side. Add department or status change events only if your offboarding moves people between statuses rather than terminating them.
Can we enrol by department or location?
Yes - the filter in step 2 is where that decision lives. Key it on the Rippling department, location or entity you want to enrol and leave everyone else untouched.
What happens to a leaver's training history and Human Risk Score?
The account leaves the active learner list, so the leaver stops counting in completion rates and risk reporting. Clean deactivation is what keeps monthly numbers accurate.
Do contractors without Rippling records break the sync?
No - they simply never generate an event. Enrol contractors the way you do today and let the monthly reconciliation surface anyone both systems missed.
We already sync Microsoft 365 into Cyber Aware. Should we add Rippling?
No - one enrolment feed per tenant. Two live feeds create duplicates and double-reminders. Keep one feed authoritative and let the other system sit behind it.
One last thing
Test the leaver path before the hire path. The new-starter gap shows up as a late enrolment; the leaver gap shows up in an audit - and audits cost more than late enrolments.