Free online trainings
01
Sep
Introduction to Risk & Compliance Use Cases – Advanced

Awareness program (new)

Distribute recurring security awareness training to your organisation, track per-cycle completion, and use it as evidence of policy attestation.

  • Documentation
  • Duration19m 42s
  • LanguagesEN

Quick Introduction

(video embed placeholder - record a short feature demo, same slot as the risk/compliance courses)

Course Introduction

Awareness Programs let you assign mandatory training to selected groups of people and keep evidence of who completed it, when, and with what result. A program can combine four kinds of content - policy attestation, a questionnaire, a video and a disclaimer - into a single flow that participants complete in the Awareness Portal.

Administrators define the audience, the content, the schedule and the notifications. eramba then runs the campaign: it invites participants, reminds the ones who have not finished, closes each round on its deadline, and records the outcome per person.

Before anything else, build the right mental model - it makes every screen in the module obvious.

The Mental Model

The module is built from four objects, and each has its own view (the four tabs at the top of the section):

Object One row means The question it answers
Awareness Program one campaign definition: audience, content, schedule, notifications what campaigns exist and in what state are they?
Awareness Cycle one execution window of a program what percentage of people completed each round?
User Record one participant in one cycle who is (not) compliant, and when did they complete?
Notification one email sent to one participant what did we send to this person, and when?

The relationship is strictly one-to-many downwards: a program creates cycles, a cycle creates one User Record per participant, and every email lands as a Notification row.

Two consequences of this model do most of the explaining:

  • A "Once" program is a program with a single cycle. A "Recurring" program spawns a new cycle every interval, and every cycle gets a fresh set of User Records - that is how annual recertification keeps last year's evidence intact while this year's round runs.
  • Evidence is never overwritten. Completion, failure, missed deadlines and every email sent stay attached to the cycle they happened in.

Typical Scenarios

  • Targeted campaigns: different training for different audiences - IT, developers, sales, contractors, or all staff.
  • Onboarding: a Once program with a dynamic (synced) group. New joiners are invited automatically as they enter the group.
  • Remedial or event-driven training: a Once program with a manually assigned group (for example, after a phishing test or an incident).
  • Annual recertification: a Recurring program. Each period is its own cycle with its own completion evidence.
  • Policy attestation: participants acknowledge existing eramba policies inside the training, creating attestation evidence linked to the policy.
  • Reporting and alerting: reports and warning notifications on top of cycles and User Records highlight low completion or non-compliance.
Scenario Type Audience Typical notifications
Onboarding / continuous Once, no end date Dynamic group, synced over time Invitation on joining, repeating Reminder
Remedial / event-driven Once, with a deadline Static group, assigned manually Invitation, Reminder, Non-Completion
Annual recertification Recurring Dynamic or static group Invitation, Reminder, Non-Completion per cycle
Role or contractor training Once or Recurring Usually static group Per selected type

Use the type to match the goal: Once when the goal is a single assignment (even one that stays open forever, as in onboarding), Recurring when people must complete the training again and again over time.

Supported Versions

Awareness Programs are available in eramba Enterprise. The module requires the Awareness Portal to be enabled under Settings → Authentication Methods before programs can be managed.

Workshops

If you need help designing a training workflow, mapping policies to campaigns or preparing audit evidence, contact eramba support or your implementation partner.

Theory

Module Relationships

Awareness Programs sit on top of several eramba areas:

  • Organization & Access: the audience of a program is one or more eramba groups. Whether a group is "dynamic" (kept in sync from LDAP, SCIM or SAML provisioning) or "static" (members assigned by hand) is a property of how you manage the group - the program does not care, it simply follows the group's membership.
  • Authentication Methods: the Awareness Portal must be enabled (Settings → Authentication Methods → Awareness portal). Participants sign in with the same authentication method as the main application. Each participant's user account must have the Awareness Portal enabled - accounts can be portal-only, with no access to the main application.
  • Security Policies: policies from the Policy module can be added to a program as attestation steps.
  • Notifications / mail: invitations and reminders are sent by email through eramba's mail settings, and every send is logged.
  • Dynamic Status, Views, Reports: programs, cycles and User Records expose operational state you can filter, colour and report on.

Program Lifecycle

A program moves through four statuses:

  • Created - configured but not started. Editable without consequences.
  • Running - the current cycle is open, participants can complete it, notifications go out.
  • Paused - temporarily suspended. No notifications are sent, nothing progresses. Resume to continue.
  • Stopped - permanently ended. Every still-pending User Record is closed as Missed. A stopped program cannot be restarted, only Reset.

Actions per status: Created → Start. Running → Pause, Stop. Paused → Resume, Stop. Stopped → Reset. Reset deletes all generated cycles, User Records and logs and returns the program to Created - use it for cleaning up test runs, not for production evidence.

Two automation rules mean you rarely press Start yourself: a program with Start immediately enabled starts the moment you save it, and a Created program with a start date starts automatically on that date. Similarly, a program whose end date has passed stops automatically.

Schedule Semantics

The Schedule tab defines when cycles exist.

Once - the program runs as a single cycle.

  • Start Date (or Start immediately): when the cycle opens.
  • Completion deadline (optional): the date the cycle closes. Everyone still pending is marked Missed. Leave it empty and the program stays open indefinitely - the natural setup for onboarding.

Recurring - the program repeats.

  • Repeat every + Period: the cycle length (for example, every 12 months).
  • Start Date (or Start immediately): when the first cycle opens. When one cycle ends, the next one starts.
  • End date (optional): when cycles stop being generated. The picker only accepts dates on which a cycle actually ends.

The What will happen box at the bottom of the tab spells out the resulting cycles with concrete dates before you save - read it, it is the schedule's contract.

Content Types

A program needs at least one content item. The four types can be combined freely and ordered on the Portal Settings tab (participants go through them in that order).

  • Policy Attestation - select up to three policies from the Policy module. Participants see each policy (content written in eramba, or a PDF attachment) and acknowledge it. Each acknowledgement is recorded per policy with a timestamp.
  • Questionnaire - a multiple-choice test imported from a CSV file (format in Advanced Configurations). Optional question pool, passing score and attempt limit.
  • Video - an uploaded MP4-compatible file, or a YouTube / direct video URL. The continue button unlocks when the video ends.
  • Disclaimer - an uploaded text or HTML file participants read and accept.

Every content type has its own Continue Button Text - the label of the button participants press to complete that step (for example "I acknowledge").

On the Portal Settings tab you can also enable a Welcome Message (shown before the first step) and a Thank You Message (shown after the last one), both with rich text and macros.

Questionnaire Mechanics

  • Questions come from the uploaded CSV. Re-uploading replaces them.
  • Question Pool (form label: Questions Per Attempt): serve a random subset of the imported questions on each attempt - import 100, show 10.
  • Display Incorrect Answers: after each attempt participants see their score and which of their answers were wrong. Correct answers are only revealed once they pass.
  • Set Passing Score (%): by default every question must be answered correctly. Enable this to set a lower passing score (Minimum Percentage of Correct Answers) and an attempt limit (Attempts, empty = unlimited).
  • A participant who reaches the passing score has passed the step. A participant who runs out of attempts is marked Not Compliant.

Notifications - exactly when each one fires

All program notifications go to participants (administrator alerts are configured separately - see Operations). Subjects and bodies are editable per program, with macros such as %AWARENESSPROGRAM_TITLE%.

Notification When it is sent Repeats Requires
Invitation When the participant's cycle starts. People added to the audience mid-cycle are invited within a couple of minutes of joining. Once per person per cycle -
Reminder (After Start Reminder) First one N days after the cycle starts (First reminder after (days)), to everyone still pending. Then repeats every M days (Reminder Recurrence) until the person completes the training or the cycle ends. Leave the interval empty to send a single reminder. Yes Fits inside the cycle length
Non-Completion Once, when the cycle closes with the training unfinished - the same moment the User Record becomes Missed. No An end date

Note: closing a cycle manually with Finish Cycle marks the pending records as Missed but does not send the Non-Completion notice. Stopping the program, or letting the cycle expire, does send it.

Everything sent is logged in the Notifications view - one row per email per person, with its type and date. That log is your delivery evidence when someone says "I never got it".

User Record Statuses

  • Pending - invited, not finished yet.
  • Compliant - completed everything (and passed the questionnaire, if there is one).
  • Not Compliant - ran out of questionnaire attempts without passing.
  • Missed - the cycle closed while the record was still pending.

The counters you see on programs and cycles (Audience, Compliant, Not Compliant, Pending, Missed, Compliance %) are derived from User Record statuses, refreshed by the nightly processing, and every counter is clickable - it drills down to exactly the User Records it counts.

The Awareness Portal

Participants open the portal (from the invitation link, or directly at /portal/awareness-programs) and sign in. They see a card per assigned training with its due date. Start opens the flow: optional welcome page → content steps in the configured order, with a progress bar → thank-you page. Progress is saved per step, so they can leave and continue later. A questionnaire shows remaining attempts, and on submission the score and (if enabled) which answers were wrong.

Demo Mode and the Demo Portal

Testing a training by mailing real users is painful, so every program has a Demo Mode. Enable it from the program's actions and open the Demo Portal (button in the section header): you go through the exact participant experience - steps, questionnaire, attempts, pass and fail - but nothing is written to User Records and no emails are sent. A finished demo run resets when you reopen it. Remember to disable demo mode when you are done. While it is enabled the program is flagged "Demo Mode Active".

The demo list shows programs in any state, so you can preview before starting. The real portal only ever shows Running programs.

Migrated Programs

Programs migrated from the previous awareness implementation are kept as read-only historic evidence - flagged "Migrated", permanently stopped, and excluded from all processing. They cannot be edited, started or reset. Their cycles, User Records and notification logs remain browsable for audits, deliberately unchanged (including records that were still pending at migration time). Their uploaded content (video, questionnaire, disclaimer) can be retrieved with the Download Content action. To continue training, create a new program - the old content download gives you the material to start from.

Implementation

Implementation Stages

  1. Prepare Access Management and portal access.
  2. Define the awareness strategy per audience.
  3. Create a sample program.
  4. Test it end to end in the Demo Portal, then with a dummy account.
  5. Configure views, dynamic statuses and reports.
  6. Roll out accounts and launch production programs.

Access Management

Before creating production programs:

  • Enable the Awareness Portal: Settings → Authentication Methods → Awareness portal.
  • Create one eramba group per intended audience, and connect it to your identity source (LDAP / SCIM / SAML / CSV) if the audience should stay in sync automatically.
  • Confirm participant accounts have the Awareness Portal enabled on their user profile. Participants do not need Main Application access - portal-only accounts are the normal setup for the general workforce.
  • Create one dummy participant account you control, in a test group.

Do not roll out all users until the dummy account has completed a sample training successfully.

Define Your Strategy

For each audience decide:

  • the purpose of the training
  • Once or Recurring
  • the content mix and its order
  • which policies to attest
  • start date, deadline and recurrence
  • reminder timing
  • what reports or warnings the GRC team needs

The scenario table in the Quick Introduction is the shortcut.

Create a Sample Program

Go to Security Operations → Awareness Programs → Add Item and work through the five tabs:

  1. General - title, description, audience groups. The form immediately tells you how many people the selected groups contain, and warns if some of them do not have portal access.
  2. Content - add at least one item: select policies, upload a questionnaire CSV (download the template first), upload a video or paste a YouTube URL, upload a disclaimer. Set the button texts.
  3. Portal Settings - optional welcome and thank-you messages. Drag the content into the order participants should follow.
  4. Schedule - Once with Start immediately is the fastest test setup. Check the What will happen box before saving.
  5. Notifications - review the invitation subject and body. Enable the Reminder and Non-Completion notice as needed.

Saving with Start immediately enabled starts the program right away - invitations to the audience go out at that moment. For a dry run, disable it, save, and use Demo Mode first.

Test the Program

  1. Demo Portal first: enable Demo Mode on the program, open the Demo Portal, and walk through the whole flow - including failing the questionnaire on purpose to see what participants experience. Nothing is recorded and no email is sent.
  2. Then one real record: put the dummy account's group in the audience and start the program. Confirm: the Invitation arrives. The dummy account can sign in and complete the flow. The User Record turns Compliant with the score and timestamps. The Notification log shows the sends.
  3. For Recurring programs: use a short interval in a test environment and confirm each cycle produces its own User Records, invitations and statistics.
  4. Reset the program (Stop → Reset) to wipe the test evidence before production use.

Basic Module Configuration

Before rollout:

  • Adjust the default views of all four tabs. Create saved views for pending, not compliant and missed records.
  • Configure Dynamic Status to highlight what matters operationally (for example, low compliance or running-with-demo-mode).
  • Build a report showing cycle compliance and user-level evidence. Schedule it to the GRC or security team with report notifications.
  • Configure warning notifications for administrators (for example, cycles below a compliance threshold) - these are separate from the participant emails inside the program.

Operations

Recurring Tasks

Once programs are live, administrators periodically:

  • Monitor compliance on the active cycles (the Awareness Cycles view is the scoreboard).
  • Review User Records for pending, not compliant and missed participants. Chase or remediate.
  • Check the Notifications view when someone reports a missing email.
  • Pause a program when content needs correction. Resume when fixed.
  • Stop programs that should no longer accept completions. Use Finish Cycle to close a recurring program's current round early (Finish Cycle does not send Non-Completion notices).
  • Export User Records as evidence for audits and policy reviews.

The Four Views in Practice

  • Awareness Programs - the control panel: status, audience size, compliance counters, and all lifecycle actions.
  • Awareness Cycles - one row per round. Per-cycle counters (Audience, Compliant, Not Compliant, Pending, Missed, Compliance %) and the retained history of recurring programs.
  • User Records - the person-level evidence: status, invitation date, first attended, score, attempts, questionnaire/video/disclaimer completion timestamps, policies acknowledged.
  • Notifications - one row per email sent, with type (Invitation / Reminder / Non-Completion) and date.

Every counter is a link - click it to see exactly the records behind the number.

Monitoring a Running Cycle

While a cycle is open, the number to watch is Compliance % on the Awareness Cycles view. Click the Pending counter to see exactly who has not finished yet, and check the Notifications view to confirm they were invited and reminded before you chase anyone personally. Typical interventions:

  • Completion is low and the deadline is near: check the Reminder settings, nudge people through other channels, or move the deadline by editing the end date (for Recurring programs, only another cycle end can be picked).
  • The content itself needs fixing: Pause the program, correct it, Resume.
  • The round should end now: Stop a Once program, or use Finish Cycle on a Recurring one. Remember that Finish Cycle does not send Non-Completion notices.

Evaluating Results

Every closed cycle keeps its final numbers forever, so evaluation is a read-only exercise on top of the Cycles and User Records views:

  • Compliance % is the headline number for management and auditors.
  • The Compliant / Not Compliant / Missed split tells two different stories: Not Compliant means people attended and failed the questionnaire (a knowledge problem), Missed means they never finished (an engagement problem). They deserve different follow-ups.
  • Open the cycle's User Records and sort by Score, Wrong Answers or Attempts to see who struggled and how hard the questionnaire really was. Consistently low scores usually point at the training or the questions, not the people.
  • For Recurring programs, the Cycles view is your trend line: compare Compliance % across cycles to show the program improving over time.

Turning evaluation into action:

  • Follow up on Not Compliant and Missed participants with a short remedial campaign: filter them in User Records, put them into a dedicated group, and target that group with a Once program.
  • Feed the most-failed questions into the next cycle: cover those topics better in the video or disclaimer, or reword ambiguous questions in the CSV.
  • Schedule a cycle compliance report to the GRC or security team, so evaluation happens on a cadence and not on memory.

Audience Changes

Group membership is re-synchronised continuously: people added to an audience group are given a Pending User Record in the active cycle and invited within minutes. People removed lose their pending record. Completed, not-compliant and missed records are historical evidence and are never touched by audience changes.

Daily Processing

A nightly job drives the module: it starts programs whose start date arrived, stops programs past their end date, closes expired cycles (marking pending records Missed and sending Non-Completion notices), opens the next cycle of recurring programs, sends due invitations and reminders, and refreshes the statistics counters. If cycles or reminders seem stale, check that eramba's cron and mail settings are healthy - that is where the module's clock lives.

Advanced Configurations

Questionnaire CSV Format

One row per question:

"Question Title","Question Description",correct_answer_index,"Answer 1","Answer 2","Answer 3"
"What should you do with a suspicious email?","Think before you click",2,"Open it","Report it to the security team"
  • Columns 1-3 are mandatory - including the description, which is shown to the participant as a hint under the question.
  • Answer options start at column 4. Add as many columns as you need. Do not leave blank columns between options - blanks are skipped and the remaining options are renumbered, which shifts the correct-answer position.
  • The correct answer index is 1-based and counts only filled-in options.
  • Download the CSV template (column-by-column instructions in its header) and the example file from the form itself.

Question Pool and Scoring

With the pool enabled, each attempt serves a fresh random subset of your imported questions - the served set is fixed per attempt, so a page refresh does not reshuffle it. Passing score and attempts only exist when Set Passing Score (%) is on. Otherwise participants simply retry until everything is correct. Enable Display Incorrect Answers for learning-oriented training. Disable it for formal testing where answers must not leak.

Video Content

Upload MP4-compatible files, or paste a YouTube link (eramba normalises it to an embeddable form) or a direct video URL - file and URL are mutually exclusive. The form's Preview action shows the video exactly as participants will see it. Upload size is bounded by the server's PHP limits, shown next to the field. For large productions prefer a YouTube (unlisted) or externally hosted URL over huge uploads.

Disclaimer Content

Plain-text files render as simple text. HTML files render as a full page (sandboxed for safety - scripts and forms inside the disclaimer are isolated from eramba). Start from the downloadable txt/html examples.

Common Features

  • Customisation: hide or add fields on the program form. The FieldData labels also drive index columns and exports.
  • Dynamic Status: ships with defaults (Created / Running / Paused / Stopped / Demo Mode Active / Migrated / Legacy). Add your own, e.g. low-compliance flags.
  • Views & Filters: every column of the four tabs is filterable. Saved views per role (program owner, auditor, administrator) pay off quickly.
  • Reports: program- and cycle-level reports for compliance evidence. Schedule them with report notifications.
  • API: programs and their records are available through the eramba API like any other section.

AI Assistance

Every phase of an awareness program has a step where an assistant saves real time. The patterns below work with any capable AI assistant. With the eramba MCP server connected (Claude, or any MCP-capable client), the assistant can read your policies and produce import-ready files directly against your instance.

Generate a Questionnaire

The questionnaire CSV is the highest-value target - writing 20 good distractor options by hand is slow. Give the assistant your source material (a policy text, a training video script, last year's incident themes) and the CSV rules from Advanced Configurations, and ask for the file. A prompt that works:

Generate an awareness questionnaire as a CSV file with columns: question, description (a one-line hint shown to the participant - mandatory), correct answer index (1-based), then one column per answer option. 10 questions, 3-4 options each, exactly one correct option per question, plausible distractors, no trick questions. Base the questions on the attached policy. Output only the CSV.

Review every generated question before uploading - you are attesting people against this content. With the eramba MCP server, the assistant can pull the policy content straight from your Policy module and validate the CSV against the import template.

Generate Content

  • Disclaimer: ask for a single-file HTML disclaimer (inline CSS, no external assets - external requests are sandboxed anyway) in your brand colours. Start from the downloadable HTML example as the style reference.
  • Video scripts: a 3-minute script with scene notes from your policy summary is a five-minute AI task. Record it or feed it to a video generator.
  • Welcome / thank-you texts and notification emails: draft the invitation, reminder and non-completion bodies in your tone of voice. Keep the %AWARENESSPROGRAM_TITLE% macro in place.
  • Translations: portal content is free text - have the assistant produce the questionnaire and disclaimers per language, one program per language.

Evaluate Results

Export User Records (or let an MCP-connected assistant query them) and ask targeted questions: which questions were most often answered wrong (candidates for better training or better wording), which departments lag, what should next cycle's focus be. Wrong-answer clustering across a cycle is exactly the kind of analysis that is tedious by hand and instant for an assistant.

Guardrails

  • Always review generated questions and content before upload - the evidence trail (who attested what) is only as good as the material.
  • Do not paste personal data from User Records into external AI tools unless your data-handling policy allows it. Prefer the MCP integration with your own instance and aggregate exports.
  • Keep generated files in your document store. The program stores the uploaded copy, but you want the source for the next revision.