Employee data and phishing simulations

The organisation running the simulation decides who is tested, when, and with what scenario. That organisation is responsible for its own employee data and for meeting its obligations to its staff, including under the Australian Privacy Principles where they apply to it.

Cyber Guys processes that data on the organisation’s instruction. Where an IT provider operates the platform for its client, the client organisation remains responsible for its own people — and the approval workflow exists so an MSP cannot launch against a client’s staff unilaterally.

Directory information supplied by the organisation:

• Name and work email address
• Department, job title and office, where the organisation provides them
• Manager’s email address, where provided
• Whether the person is active, on leave, or opted out of simulations

Behavioural data generated by a simulation:

• Whether the message was delivered and opened
• Whether a link was clicked, a QR code scanned or an attachment opened
• Whether a form was submitted — never what was typed into it
• Whether the message was reported as suspicious, and whether that was before clicking
• Whether follow-up training was assigned and completed
• A coarse device category such as “desktop browser”, “mobile” or “mail scanner”

• Anything typed into a simulated form. A simulated sign-in page records that a submission happened. It does not store the password, and the safety scanner blocks any template that asks for card details, a card security code, BSB and account numbers, a tax file number, a Medicare, passport or licence number, or a cryptocurrency key.
• Full user-agent strings. Only a coarse category is retained, which is enough to tell a person from a mail scanner and not enough to fingerprint a device.
• Personal characteristics. Age, gender, ethnicity, tenure, seniority and performance ratings cannot enter the risk model. The list of factors that may influence a score is a closed set in the code, and a test asserts that no prohibited input can be added to it.
• General web browsing. The platform sees interactions with its own simulated messages and landing pages. It is not monitoring what anybody does otherwise.

IP addresses are retained only where the organisation has explicitly opted in, and they are purged on the raw-metadata retention schedule — 30 days by default — independently of the underlying result. Knowing that somebody clicked matters for two years; knowing which network they clicked from does not.

Platform defaults, which an organisation may shorten:

• Raw technical metadata (IP address, device category) — 30 days, then stripped from the event while the outcome is preserved.
• Simulation events (clicked, reported, submitted) — 730 days, then deleted.
• Tracking tokens — deleted 30 days after expiry, because an expired token is useless and a standing liability.
• Campaign reports — retained longer, because they are the evidence an insurer or auditor asks for.

A retention sweep runs on a schedule rather than on request. Where an organisation has placed a legal hold, the sweep skips it — deletion cannot be used to remove evidence during a dispute or investigation.

Only administrators whose role permits it, within the organisation the employee belongs to. Access resolves through the same tenant chokepoint as everything else in the platform, so one organisation’s administrators cannot see another’s people.

Where an IT provider runs simulations for a client, its access is scoped to the client organisations on its plan.

This is a design decision rather than a policy statement, and it is the reason the rest of the page holds up. A simulation programme that becomes a disciplinary instrument stops producing honest reporting within about a month, because people learn that the safe move is to say nothing.

• Risk bands are named constructively — “improvement opportunity”, not “high-risk employee”.
• Reporting a suspicious message always reduces a person’s risk contribution and can never increase it, including when they report after clicking.
• Contributions decay on a half-life and are ignored entirely beyond the decay window, so a mistake does not follow somebody indefinitely.
• Organisation-level reporting is built to surface systemic gaps — a team that consistently does not verify payment changes — rather than to rank individuals.
• Business impact is capped in the model, so somebody cannot be labelled risky simply for holding the authority their job requires.

Any employee can be excluded from every simulation, with a recorded reason. Somebody recorded as on leave is not tested while they are away. These are per-person settings held by the organisation, not exceptions we have to be asked for.

We are not in a position to advise you on your obligations to your employees — that depends on your jurisdiction, your industry and your employment agreements, and it is a question for your own adviser. What we can say is that the organisations who get the most out of simulation programmes tell their staff in advance that simulations happen, explain why, make the reporting route obvious, and are explicit that results are used to direct training rather than to performance-manage anyone.

The general privacy policy covers accounts, training records and everything else. The phishing simulation page describes how the campaigns themselves work, and the security overview covers the platform controls.