Guide for companies

How to run BadgerQuest for a team: getting people in, assigning what they must complete, reading what comes back, and connecting it to the rest of your stack.

Getting your team in

There are three ways people join, and they can be combined:

Route	How it works
Invite by email	Invite from the People tab. They get a link, and joining requires them to be signed in as that exact address. Invites expire after 30 days.
Verified domain	Anyone who signs up on a domain you have verified joins automatically as a member. Your own domain is verified for you when you create the company.
Claiming a domain by DNS	Prove you own the domain with a TXT record and everyone who already has an account on it joins your company too, not just people who sign up later.
SCIM	Point your identity provider at BadgerQuest and let it create, update and deprovision people. See the API guide.

You can also invite in bulk by pasting or uploading a CSV, up to 500 people in one import.

Claiming your domain

Verifying your domain by DNS does three things at once: it brings in the colleagues who already signed up on their own, it makes every future signup on that domain join automatically, and it unlocks single sign-on.

In Settings → Security & sign-in → Domains, add your domain and publish the TXT record it shows you, then press Check DNS:

Record	Value
`_badgerquest-verify.yourdomain.com`	`badgerquest-domain-verification=…`

DNS changes usually publish within a few minutes. The panel tells you exactly what it found, including the case where a record is there but its value does not match, which normally means it was left over from an earlier attempt.

Three kinds of account are deliberately left behind, and the panel names each one. Anyone who already belongs to another company is not moved, because one person belongs to one company and a contractor with an address on your domain may genuinely work elsewhere. BadgerQuest staff accounts are never absorbed into a customer’s roster. And anyone paying us for their own personal subscription is left alone, so they are not billed twice while you also pay for their seat; talk to us and we will sort those out individually.

Everyone who is moved gets an email telling them so, because their account has just become visible to an administrator and they should hear that from us rather than notice it. A domain can be verified by one company only.

Roles

A person’s role belongs to their membership of your company, not to their account. One person belongs to one company.

Role	Can do
`OWNER`	Everything, including billing and plan changes, and granting or removing OWNER.
`ADMIN`	Manage people, author content, view the audit log. No billing.
`AUTHOR`	Author and manage your company's own training content only. No people, no billing.
`MEMBER`	Play. No console.

Assigning required training

Training is assigned as a campaign: a pack of quests with a due date. The Compliance view shows every member against every assigned training, and completion issues a certificate with a serial you can verify.

Evidence only counts from the point someone joined your company. Training completed before their membership began is not credited toward your compliance figures, so a certificate never claims more than it can actually support.

Reading the Human Risk Score

The War Table shows an aggregate score and grade for your team, built from what people actually do: how often they report a forgery, and how often they get the questions right. A person’s own score also carries a small weight for not crying wolf, meaning what they report turns out to be a simulation rather than genuine mail.

Attendance is deliberately not in the score. Turning up is not competence, and a grade a person can lift by logging in is a grade you could not show an insurer. So a team can be here every single day and still have ground to make up, and that is the score working, not a fault in it.

The question attendance actually answers, “who is not doing their training at all?”, is a separate reading shown next to the grade rather than inside it. It has to be separate: somebody who never trains has no measurements, so they have no grade to be bad. A risk score alone would leave your least-trained people invisible.

Check whether there is any activity before you act on the number. With no drills run yet, the score shown is a placeholder rather than a measurement. The API exposes this explicitly as hasActivity, and the console says so too. A score built on nobody’s behaviour is not a low risk, it is no reading.

Members can be excluded from aggregates (contractors, shared accounts) without losing their own progress. Excluded people are counted separately so the denominator stays honest.

Everything on the roster is counted from the day that person joined you. This is the same rule as the compliance evidence above, applied to the score and the numbers beside it. Someone who played BadgerQuest for a year before you hired them, or before you had an account, arrives showing zero, and builds a record with you from there. It means a new joiner reads as new, which is accurate, and it means your readiness score describes your people rather than partly describing somebody else’s.

The Tourney (department against department)

Optional, and off until you switch it on under Settings, Training. For four weeks your departments compete on three things: forgeries reported, verdicts that were right (so a team cannot win by reporting everything), and weekly quests finished. Only rates are shown, never names, and a department appears on the board once it has five people; smaller ones and anyone without a department count as “Everyone else”. The winner is named on the board and its people wear a small flag for the next round. Nothing in it changes anyone’s score, XP or training record. Your people find the board under The Order, and a line on their home screen while a round runs.

Which country’s scams your people practise on

A forged tax-office notice only teaches anything if it impersonates the tax office your staff would actually hear from. So each person has a training market: the country whose banks, tax authority and payment brands appear in the fake messages they are shown.

This is not the country you are billed from, and keeping them separate matters. A company with a Canadian head office paying on a Canadian card may well have staff in Texas and Munich. One billing address, many working countries. If the two shared a setting, everybody in that company would practise on Canada Revenue Agency notices, including the people who have never filed a Canadian tax return.

You do not have to configure any of it. A new company trains on the country it is billed from, which is the right answer for most companies and needs no decision from you. Change it only where it is wrong.

Set it	Where	Good for
One person	Open them in People and pick a country. Type to search.	The handful of people who work somewhere else.
The whole company	Settings, if your people work somewhere other than where you pay from.	A company registered in one country and operating in another.
A CSV column	A third column on the bulk import, after email and role.	Moving an office without opening five hundred profiles.
Your directory	An SSO claim, refreshed every time somebody signs in.	Letting the directory stay the record, so a transfer follows the person.

Blank means “use the setting above” at every level, which is what lets a re-imported roster leave your existing choices alone: an empty CSV cell never wipes a market an admin set by hand or your directory asserted.

Any country can be chosen. We write content tailored to Canada and the United States today; anywhere else is served the worldwide set, which is most of our library, because a forged invoice or a fake sign-in page works the same in any country. What a person in an untailored market will not see is another country’s tax office, which is the point.

The SSO claim is worth naming precisely, because every provider calls it something different. Microsoft Entra sends usageLocation, Okta sends countryCode, and plenty of tenants emit a custom one, so you tell us the claim name rather than us guessing. A value we do not recognise leaves the person on the company setting rather than being guessed at.

Rolling out without a wave of email

Adding hundreds of people at once means hundreds of emails at once, which is how a rollout becomes an incident. In Settings you can turn off the mail your company causes, for a set period, while you get set up.

Can be silenced	Never silenced
Invitations and joining notices	Password resets
Training reminders and due-date nudges	Email address verification
Weekly digests and engagement mail	Billing correspondence

The split is deliberate and built so it cannot be got wrong by accident. A company may silence mail it causes, never mail the recipient needs. If a company could switch off password resets, it could lock its own staff out of the product it just bought and nobody would work out why. Billing is exempt for a different reason: that correspondence is between us and you, and it is not yours to mute.

The quiet period has an end date, because a switch with no expiry gets left on and then nobody can work out why the reminders stopped.

Your own content

On a paid plan you can author your company’s own quests and simulated messages: emails, texts and calls, written or generated. Your content is yours alone. It is served only to your members, and it can never modify or reach the platform’s own content or another company’s.

You can also choose whether your members see the platform’s generated content, your curated content, or a mix.

Sign-in policy, SSO and SCIM

Any company can require a stronger sign-in for everyone: either two-factor, or a passkey. Members who do not yet meet it are stopped on the way into BadgerQuest and walked through setting it up, rather than being locked out.

Federated sign-in is OIDC-based and self-serve. Accounts provisioned through SSO only ever land in your company when the asserted email is on a domain you have verified, so another tenant’s identity provider cannot claim your people.

Turning SSO on requires a domain verified by DNS, not merely one verified by email. Federating a domain means every assertion your identity provider makes about an address on it signs somebody in, and an inbox is not evidence of owning a domain: every employee has an inbox, only your IT department can publish a DNS record. See Claiming your domain.

If your identity provider is unreachable when someone tries to sign in, they fall back to a password rather than being locked out, and anyone in your directory who arrives during a sign-in surge is admitted rather than turned away at the door.

Pass marks and retakes

You set what counts as a pass. The default is 70%, and you can set anything from 50 to 100 in Settings, either for the whole company or for one course that needs to be stricter.

Changing it applies to work already done. Completion is worked out from people’s answers every time it is read rather than stamped once, so raising the mark can move somebody who had passed back to not complete. That is usually what you want, and it is a surprise if nobody warns you. Certificates already issued are not withdrawn.

You also choose whether somebody who falls short can sit a course again. Leaving retakes on means they can reopen the questions they got wrong straight away, rather than waiting for the course to come round again the following week, which is the difference between fixing it before your deadline and being marked overdue for a week. A retake only reopens what they got wrong: anything already answered correctly stays that way.

Turn retakes off and the first answer to each question is the record, permanently. Some companies want exactly that, and it is the honest way to run a one-shot test. Either way every sitting is counted, so your training record can say a pass took two attempts rather than quietly reporting a pass. There is a limit on attempts by default, because a pass mark stops meaning much if somebody can answer the same question until they guess right.

The policy acknowledgement

This is the yearly confirmation that your people have read your information security policy and agree to work by it. It is off until you switch it on, in Settings.

It is a separate thing from finishing training, and auditors treat it that way. Training shows somebody learned the material. An acknowledgement shows they were told your rules and accepted them, which is what matters if you ever have to act on somebody breaking one. PCI DSS asks for one at least every twelve months, and SOC 2 and ISO reviewers usually ask to see them too.

You can use our wording, which fills in your company name, or paste your own. Ours is a starting point for a company that has nothing written down yet: we are not your lawyers and we have not seen your policy, so read it through with whoever owns that before you switch it on. You can also link to your full policy document, and choose how often people confirm: every twelve months by default, or six, twenty-four, or once when they join.

Anyone who has not confirmed is asked the next time they open BadgerQuest, and cannot go further until they do. If it stays outstanding for three weeks, they get one email a week about it. Somebody who joins today is measured from their joining date, not from the day you switched it on, so a new starter is not chased on their first morning.

Changing the wording and asking everyone again are two separate decisions. Fixing a typo or adding a link updates the text without disturbing anybody. Tick Ask everyone to confirm again only when the policy itself has changed: every confirmation on file stops counting and your whole company is asked afresh.

Each confirmation records who, when, which version, and a fingerprint of the exact text they were shown, so editing your policy later cannot change what somebody agreed to. It all appears on the training record you download.

Security questionnaires and insurance forms

Sooner or later a broker, an auditor or a customer’s procurement team sends you a form. Here is what BadgerQuest can evidence, and, just as usefully, what it cannot, so you never have to guess at an answer that somebody may later check.

They ask	What you can say
Do you provide security awareness training to all staff?	Yes, continuously rather than annually. Export completion per person from the Compliance view, with dates.
How often?	Daily practice, a few minutes. Assigned training carries its own due dates.
Can you evidence completion?	Per person, dated, and each certificate carries a serial anyone can verify at its public URL.
Do you track who fails?	Yes, per person, with a readiness score and the sample size behind it. Available in the console, by CSV, or over the API.
Do you run phishing simulations?	See below. Answer it precisely, because the honest answer is not simply yes or no.

The phishing simulation question

Many questionnaires ask whether you run simulated phishing campaigns against your staff. BadgerQuest runs phishing practice inside the app, and deliberately does not send simulated phishing to real inboxes, phone numbers or messaging accounts. That is a stance rather than a gap. An ambush test measures who fell for one message on one day, and it teaches people to distrust their own security team. Labelled practice can do something an ambush cannot: build the judgement to tell a forgery from a genuine message, which is what decides whether the reports reaching your security team are worth their time.

Suggested wording, which is accurate: “Staff complete continuous phishing recognition training in a simulated environment, including email, SMS and voice pretexts, with per-person performance tracked and reported. We do not run deceptive phishing campaigns against production mailboxes.”

If a control specifically requires simulations delivered to production mailboxes, BadgerQuest does not satisfy that control on its own, and we would rather you knew that from us than discovered it at renewal. Tell us if you hit one; it is useful for us to know which frameworks demand it.

What we do not have, stated plainly: no SOC 2, no ISO 27001, and no third-party penetration test. We do not claim any of them anywhere, and we will not imply them on a form. Our security measures are listed in the Privacy Policy, and a Data Processing Agreement is available. Data is hosted in North America but not in Canada, which matters if you have a Canadian data residency requirement; talk to us early if you do. The Privacy Policy names the exact country and providers.

When a reviewer wants more than a yes or no, send them How it is built. It covers sign-in, how companies are kept apart, what happens to API keys and webhooks, and the same list of what we do not have, in enough detail for somebody technical to check rather than take on trust.

Privacy and data

Members can export or delete their own data from their settings. Deleting an account removes the person; your aggregate compliance history is retained without them. Every privileged action in the console is written to an audit log that admins can read and export.

Plans and billing

There are two ways to buy, and they bill differently.

	Team, bought online	Enterprise, bought on a quote
Billed	Per seat, per month	For a whole term, agreed with us, usually a year
Paid	By card, month to month, cancel any time	By invoice with payment terms (commonly Net 30 or Net 60), or by card
Priced	A flat price per person	Per seat, or as one price for the whole organisation
Changing seats	Adding someone mid-month is prorated	Seats added mid-term are trued up on the invoice

Everything is priced and charged in Canadian dollars. A seat is a person in your company. The free trial runs 30 days and covers teams of up to 50 people; if yours is larger, talk to us and we will set you up rather than let you hit a wall halfway through a rollout.

There is no seat minimum. You pay for the people you have, down to one, and one person may buy the paid plan for themselves if they want the Roost.

Managing several companies? See the guide for MSPs.

If a plan lapses, paid surfaces stop serving, including API keys, which re-check the plan on every request rather than only at creation.